맨위로가기

XMODEM

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

XMODEM은 1970년대 후반에 개발된 초기 파일 전송 프로토콜로, 주로 모뎀을 통한 통신에 사용되었다. 128바이트 데이터 패킷을 사용하며, 헤더, 블록 번호, 데이터, 체크섬 또는 CRC 부호로 구성된다. XMODEM은 오류 검출을 위해 체크섬 또는 CRC를 사용하고, 수신자가 ACK 또는 NAK 신호를 보내는 방식으로 전송된다. XMODEM은 전송 효율이 낮고, 파일 정보 전송 기능이 제한적이라는 단점이 있어, XMODEM-CRC, XMODEM-1K, YMODEM, ZMODEM과 같은 다양한 변형 프로토콜이 개발되었다.

더 읽어볼만한 페이지

  • PC통신 - 전화 접속
    전화 접속은 공중 교환 전화망을 통해 모뎀과 전화선으로 인터넷에 연결하는 방식으로, 1980년대부터 사용되었으나 광대역 인터넷의 등장으로 2000년대 이후 사용이 줄어 현재는 제한적으로 사용되며 사라지는 추세이다.
  • PC통신 - 전자우편
    전자우편은 컴퓨터 네트워크를 이용하여 편지와 메시지를 주고받는 시스템으로, 시분할 메인프레임 통신에서 시작하여 @ 기호 주소 체계 도입 후 아파넷을 통해 대중화되었으며, 다양한 형식의 파일 첨부와 스팸 등의 문제에도 불구하고 널리 사용되는 통신 수단이다.
  • 네트워크 프로토콜 - UUCP
    UUCP는 유닉스 시스템 간 파일 복사, 원격 명령 실행, 이메일 및 유즈넷 뉴스 전송을 위한 프로토콜 및 프로그램 모음으로, 초기 인터넷 확장에 중요한 역할을 했으나 TCP/IP 기반 서비스 보편화로 사용이 감소했다.
  • 네트워크 프로토콜 - 프레임 릴레이
    프레임 릴레이는 LAN 간 또는 WAN 종단점 간 데이터 전송을 위한 고속 패킷 교환 방식 통신 프로토콜로, X.25 프로토콜을 간소화하여 속도를 높이고, 영구 가상 회선을 통해 안정적인 연결을 제공하며, 서비스 품질 설정을 통해 프레임 우선순위를 지정할 수 있었으나, 현재는 다른 기술에 밀려 사용이 감소하고 있다.
XMODEM
XMODEM 개요
종류파일 전송 프로토콜
개발자워드 크리스텐슨
발표일1977년
기반해당 없음
영향YMODEM, 기타 다수
OSI 모델해당 없음
포트해당 없음
RFC해당 없음
하드웨어모뎀

2. 패킷 구조

XMODEM은 기본적으로 128바이트 또는 1024바이트 크기의 데이터 패킷을 사용하며,[1] 오류 검출에는 8비트 체크섬 또는 16비트 CRC 부호를 이용한다.[1]

헤더데이터 블록 번호데이터 블록 번호의 1의 보수데이터체크섬 또는 CRC 부호
8비트8비트8비트128바이트 또는 1024바이트8비트 또는 16비트


  • 헤더: 데이터의 크기를 나타낸다. 128바이트인 경우 SOH, 1024바이트인 경우 STX를 설정한다.
  • 데이터 블록 번호: 블록 번호를 설정한다. 1부터 시작하여 1씩 증가하며, 255 다음은 0이 된다.
  • 데이터 블록 번호의 1의 보수: 블록 번호의 1의 보수(모든 비트를 반전시킨 것)를 설정한다.
  • 데이터: 전송할 데이터를 128바이트 또는 1024바이트 단위로 설정한다. 전송할 데이터가 128바이트 또는 1024바이트에 미치지 못할 경우 EOF로 패딩한다(남은 부분을 채운다).
  • 체크섬 또는 CRC 부호: 8비트 체크섬 또는 16비트 CRC 부호를 빅 엔디안으로 설정한다.

2. 1. 기본 구조 (128바이트)

초창기 XMODEM은 CP/M 플로피 디스크에서 사용된 블록 크기인 128바이트 데이터 패킷을 사용했다. 각 패킷은 SOH영어 문자, 1-255 사이의 "블록 번호", 블록 번호의 "반전" 값(255 - 블록 번호)을 포함하는 3바이트 헤더로 시작한다. 블록 번호는 0이 아닌 첫 번째 전송 블록부터 1로 시작한다. 헤더 뒤에는 128바이트의 데이터와 단일 바이트 체크섬이 따른다. 체크섬은 패킷 내 128바이트 데이터의 모든 합을 256으로 나눈 나머지 값이다. 따라서 전체 패킷은 128바이트의 페이로드 데이터를 포함하여 총 132바이트였으며, 전체적인 채널 효율은 약 97%였다.[1]

파일은 마지막 블록을 보낸 후 EOT영어 문자를 보내 "완료"로 표시했다. 이 문자는 패킷 안에 포함되지 않고 단일 바이트로만 전송되었다. 파일 길이는 프로토콜의 일부로 전송되지 않았기 때문에, 마지막 패킷은 삭제될 수 있는 "알려진 문자"로 채워졌다. 원래 명세서에서는 이 문자가 SUB영어 또는 10진수 26으로 기본 설정되었으며, CP/M은 자체 디스크 형식 내부에서 파일 종료 마커로 사용했다. 표준에서는 패딩에 어떤 문자든 사용할 수 있다고 제안했지만, ''프로토콜 내에서'' 변경할 방법은 없었다. 구현이 패딩 문자를 변경하면 동일한 구현을 사용하는 클라이언트만 새로운 패딩 문자를 올바르게 해석할 수 있었다.[1]

헤더데이터 블록 번호데이터 블록 번호의 1의 보수데이터체크섬
8비트8비트8비트128바이트8비트


  • '''헤더''': 데이터의 크기를 나타낸다. 128바이트인 경우 SOH영어를 설정한다.
  • '''데이터 블록 번호''': 블록 번호를 설정한다. 1부터 시작하여 1씩 증가하며, 255 다음은 0이 된다.
  • '''데이터 블록 번호의 1의 보수''': 블록 번호의 1의 보수(모든 비트를 반전시킨 것)를 설정한다.
  • '''데이터''': 전송할 데이터를 128바이트 단위로 설정한다. 전송할 데이터가 128바이트에 미치지 못할 경우 EOF영어로 패딩한다(남은 부분을 채운다).
  • '''체크섬''': 8비트 체크섬을 설정한다.

2. 2. 확장 구조 (1024바이트, XMODEM-1K)

XMODEM-1K는 패킷 크기를 1024바이트로 늘려 처리량 문제를 개선한 프로토콜이다. 9600 bit/s에서 처리량은 81%이다.

XMODEM-1K는 XMODEM-CRC의 확장 버전으로, 패킷을 SOH영어 대신 STX영어 문자로 시작하여 송신자에서 더 긴 블록 크기를 나타낸다. XMODEM-1K 전송은 반대편에서 XMODEM의 모든 구현으로 시작하여 필요에 따라 기능을 축소할 수 있었다.

XMODEM-1K는 원래 척 포스버그가 YMODEM 프로토콜에서 도입한 여러 개선 사항 중 하나였다. 포스버그는 다양한 개선 사항이 선택 사항이며, 소프트웨어 제작자가 가능한 한 많은 개선 사항을 구현할 것으로 예상했다. 그러나 일반적으로 최소한의 기능만 구현되어 호환성이 떨어지는 구현이 많았고, 결국 "YMODEM"이라는 이름은 "XMODEM-1K"와 다양한 YMODEM으로 분리되었다. XMODEM-1K는 실제로 YMODEM보다 나중에 나왔지만, 널리 사용되었다.

XMODEM-1K는 1024바이트 데이터 패킷을 사용하며, 데이터 부분을 제외한 나머지 구조는 기본 구조와 동일하다.

헤더데이터 블록 번호데이터 블록 번호의 1의 보수데이터체크섬 또는 CRC 부호
8비트8비트8비트1024바이트8비트 또는 16비트


  • '''헤더:''' 데이터의 크기를 나타낸다. 1024바이트인 경우 '''STX'''를 설정한다.
  • '''데이터 블록 번호:''' 블록 번호를 설정한다. 1부터 시작하여 1씩 증가하며, 255 다음은 0이 된다.
  • '''데이터 블록 번호의 1의 보수:''' 블록 번호의 1의 보수(모든 비트를 반전시킨 것)를 설정한다.
  • '''데이터:''' 전송할 데이터를 1024바이트 단위로 설정한다. 전송할 데이터가 1024바이트에 미치지 못할 경우 '''EOF'''로 패딩한다(남은 부분을 채운다).
  • '''체크섬 또는 CRC 부호:''' 8비트 체크섬 또는 16비트 CRC 부호를 빅 엔디안으로 설정한다.

3. 전송 절차

XMODEM은 수신자 주도 방식으로 동작하며, 정지-대기(Stop-and-Wait) ARQ 프로토콜을 기반으로 한다. 송신자는 수신자로부터 또는 메시지를 받아야 다음 동작을 수행할 수 있기 때문에 속도가 느린 경향이 있었다.

기본적인 전송 절차는 다음과 같다.

수신측송신측
NAK(전송 요구)→
←블록 1
ACK(긍정 응답)→
←블록 2
ACK→
(중략)
←최종 블록
ACK→
←EOT(전송 종료)
ACK→
(통신 종료)



1. 수신측이 송신 요구로 '''NAK'''를 송출한다. XMODEM/CRC 또는 XMODEM/1k에서는 '''NAK'''가 아닌 '''C'''를 송출한다.

2. 송신측이 첫 번째 데이터 블록을 송출한다.

3. 수신측은 블록 번호, 체크섬 또는 CRC 부호를 확인하고, 수신한 데이터에 오류가 없음을 확인한 후에 '''ACK'''를 송출한다. Flying-XMODEM에서는 데이터 블록을 다 받기 전에 '''ACK'''를 송출한다.

4. '''ACK'''를 받은 송신측은 다음 데이터 블록을 송출한다. 모든 데이터를 송출할 때까지 이를 반복한다. 모든 데이터를 송출한 경우에는, 송신해야 할 데이터가 종료되었음을 나타내는 '''EOT'''를 송출한다.

5. 수신측이 '''ACK'''를 송출하고, 통신을 종료한다.

3. 1. 기본 흐름

파일은 한 번에 한 패킷씩 전송되었다. 패킷을 수신하면 수신자는 패킷의 체크섬을 계산하여 패킷 끝에서 보낸 사람으로부터 받은 체크섬과 비교했다. 두 값이 일치하면 수신자는 보낸 사람에게 ACK|승인 문자영어 메시지를 다시 보냈고, 그러면 보낸 사람은 시퀀스에서 다음 패킷을 보냈다. 체크섬에 문제가 있으면 수신자는 대신 NAK|부정 승인 문자영어를 보냈다. NAK|NAK영어가 수신되면 보낸 사람은 패킷을 재전송하고 전송을 중단하기 전에 일반적으로 10번 정도 여러 번 시도했다.[1]

수신기가 EOT영어 문자가 없어 데이터를 계속 예상하는 동안 10초 이내에 유효한 패킷을 수신하지 못한 경우에도 NAK|NAK영어가 전송되었다. 패킷 내에서 7초의 시간 초과도 사용되어 패킷 중간에 연결이 끊어지는 것을 방지했다.

블록 번호도 오류를 확인하기 위해 간단한 방식으로 검사되었다. 패킷을 성공적으로 수신한 후 다음 패킷은 1씩 증가한 번호를 가져야 했다. 대신 동일한 블록 번호를 수신한 경우 이는 심각한 것으로 간주되지 않았고, ACK|ACK영어가 보낸 사람에게 수신되지 않아 패킷을 다시 보낸 것으로 추정했다. 다른 패킷 번호는 패킷이 손실되었음을 알렸다.

전송은 수신자 주도 방식이었다. 전송기는 수신자가 초기 NAK|NAK영어를 보낼 때까지 데이터를 전송하지 않았다. 이는 사용자가 원격으로 위치한 전송 시스템과 상호 작용하는 방식의 논리적인 결과였다. 사용자는 전송 시스템에서 요청된 파일로 이동한 다음 해당 시스템에 파일을 전송하도록 요청했다. 이 명령이 실행되면 사용자는 로컬 소프트웨어에서 명령을 실행하여 수신을 시작했다. 원격 시스템에 파일을 요청하는 것과 수신을 시작하는 로컬 명령을 실행하는 시간 지연을 알 수 없었기 때문에 XMODEM은 수신기가 데이터 패킷 요청을 시작하는 데 최대 90초를 허용했다.

제어 코드 SOH, STX, EOT, ACK, NAK, CAN의 6개와 문자 'C'(43h)를 사용하여 통신 제어를 수행하며, 후술할 데이터 블록 단위로 데이터를 전송한다.

3. 2. 오류 처리

수신자는 데이터 블록에 오류가 있거나, 블록 번호가 예상과 다를 경우 NAK를 보내 재전송을 요청한다. 송신자는 일반적으로 10회 정도 재전송을 시도하고, 실패하면 전송을 중단한다.[14][15] 수신자가 일정 시간(일반적으로 10초) 이내에 유효한 패킷을 수신하지 못하면 NAK를 전송한다.

패킷을 성공적으로 수신한 후 다음 패킷은 1씩 증가한 번호를 가져야 한다. 동일한 블록 번호를 수신한 경우, ACK가 송신자에게 수신되지 않아 패킷을 다시 보낸 것으로 간주한다. 다른 패킷 번호는 패킷이 손실되었음을 의미한다.

블록 번호가 이상하거나, 체크섬 또는 CRC 부호와 데이터 사이에 모순이 있는 경우, 수신 측은 ACK 대신 NAK (부정 응답)을 송출한다. NAK을 수신한 송신 측은 다시 같은 데이터 블록을 송출한다.

블록 8에서 오류가 발생한 경우
수신 측송신 측
←블록 7
ACK→
←블록 8
(블록 8에 어떤 오류가 있었음)
NAK (재전송 요구)→
←블록 8 (다시 같은 블록을 송출)
ACK→
←블록 9


3. 3. 전송 중단

수신자 또는 송신자는 CAN|캔슬영어 (Cancel) 문자를 전송하여 전송을 중단할 수 있다. 일정 시간 동안 응답이 없거나, Flying-XMODEM 전송 중에 오류가 발생하는 등 어떠한 사정으로 인해 전송을 중단하고 싶을 때는 '''CAN'''을 보낸다. 이는 수신 측, 송신 측 어느 쪽에서 보내도 된다.

4. XMODEM의 종류 및 발전

XMODEM은 전송 효율과 기능을 개선하기 위해 다양한 변형 프로토콜이 개발되었다. 주요 변형 프로토콜은 다음과 같다.

프로토콜설명
XMODEM-CRC기존 XMODEM의 체크섬(Checksum) 대신 16비트 CRC를 사용하여 오류 검출 능력을 향상시켰다. CRC는 패킷의 데이터뿐만 아니라 위치도 인코딩하여 체크섬이 놓칠 수 있는 비트 대체 오류를 감지할 수 있다.[14][15] XMODEM과의 하위 호환성을 위해 수신자는 `C` 문자를 사용하여 XMODEM-CRC 지원 여부를 알린다.
XMODEM-1K척 포스버그가 YMODEM 프로토콜에서 도입했던 개선 사항 중 하나로, 패킷 크기를 1024바이트로 늘려 처리량을 개선했다. 패킷 시작 문자를 ``로 변경하여 더 긴 블록 크기를 나타낸다.
WXModem (Windowed Xmodem)피터 보스웰이 개발. 높은 레이턴시 환경에 최적화된 프로토콜이다. 최대 512바이트 블록 크기를 지원하며, 슬라이딩 윈도우 프로토콜을 사용하여 효율성을 높였다. X.25 네트워크 등에서 유용하다.[16]
MODEM7MODEM7 배치 또는 배치 XMODEM이라고도 불리며, XMODEM 프로토콜의 최초 확장이다. 8.3 파일이름 형식으로 파일 이름을 전송하여, 수신측에서 해당 이름으로 파일을 저장할 수 있도록 개선되었다.[7]
TeLink톰 제닝스가 개발. FidoNet 메일러에서 사용되었다. 파일 이름, 크기, 타임스탬프 등의 정보를 담은 "제로 패킷"을 추가하여 MODEM7의 문제점을 해결했다.[1]
SEAlinkFidoNet용으로 개발. WXmodem과 유사한 슬라이딩 윈도우 개념을 사용하며, "제로 패킷"을 지원한다. 반이중 링크를 위한 "오버드라이브" 모드를 제공한다.[1]
NMODEM1990년에 L. B. 닐이 개발. 2048바이트의 더 큰 블록을 사용하는 XMODEM-CRC의 변형이다.[1]
Flying-XMODEM데이터 블록 수신 완료 전에 미리 ACK를 보내는 (플라잉) 방식으로 전송 속도를 향상시킬 수 있다. YMODEM에서 공식화되었다. 규약 위반이며, 특성상 오류가 발생해도 복구할 수 없다.


4. 1. XMODEM (기본)

초창기 XMODEM은 CP/M 플로피 디스크에서 사용된 블록 크기인 128바이트 데이터 패킷을 사용했다. 패킷 앞부분에는 SOH 문자, 1-255 사이의 "블록 번호", 블록 번호의 "반전" 값(255 - 블록 번호)을 포함하는 간단한 3바이트 헤더가 붙었다. 블록 번호는 첫 번째 전송 블록부터 1로 시작한다. 헤더 뒤에는 128바이트의 데이터와 단일 바이트 체크섬이 따른다. 체크섬은 패킷 내 128바이트 데이터의 모든 합을 256으로 나눈 나머지 값이었다. 따라서 전체 패킷은 128바이트의 페이로드 데이터를 포함하여 총 132바이트였으며, 전체적인 채널 효율은 약 97%였다.[1]

파일은 마지막 블록을 보낸 후 EOT 문자를 보내 "완료"로 표시했다. 이 문자는 패킷 안에 포함되지 않고 단일 바이트로만 전송되었다. 파일 길이는 프로토콜의 일부로 전송되지 않았기 때문에, 마지막 패킷은 삭제될 수 있는 "알려진 문자"로 채워졌다. 원래 명세서에서는 이 문자가 또는 10진수 26으로 기본 설정되었으며, CP/M은 자체 디스크 형식 내부에서 파일 종료 마커로 사용했다. 표준에서는 패딩에 어떤 문자든 사용할 수 있다고 제안했지만, ''프로토콜 내에서'' 변경할 방법은 없었다. 구현이 패딩 문자를 변경하면 동일한 구현을 사용하는 클라이언트만 새로운 패딩 문자를 올바르게 해석할 수 있었다.[1]

4. 2. XMODEM-CRC

원래 프로토콜에 사용된 체크섬은 매우 단순하여 패킷 내 오류를 감지하지 못할 수 있었다. 이로 인해 존 번스(John Byrns)가 '''XMODEM-CRC'''를 개발했는데,[14][15] 이는 8비트 체크섬 대신 16비트 CRC를 사용한다. CRC는 패킷의 데이터뿐만 아니라 위치도 인코딩하여 체크섬이 놓칠 수 있는 비트 대체 오류를 감지할 수 있다.

XMODEM-CRC는 XMODEM과의 하위 호환성을 갖도록 설계되었다. 이를 위해 수신자는 전송을 시작하기 위해 `` 대신 `C` (대문자 C) 문자를 보냈다. 송신자가 패킷을 보내는 것으로 응답하면 송신자가 XMODEM-CRC를 "알고" 있다고 가정하고, 수신자는 계속해서 `C`를 보냈다. 만약 패킷이 전송되지 않으면, 수신자는 송신자가 프로토콜을 모른다고 가정하고, "전통적인" XMODEM 전송을 시작하기 위해 ``을 보냈다.

하지만 이러한 하위 호환성 시도는 단점을 가지고 있었다. 최초의 `C` 문자가 손실되거나 손상될 수 있으므로, 전송을 시작하려는 첫 번째 시도가 실패하더라도 수신자가 XMODEM-CRC를 지원하지 않는다고 가정할 수 없었다. 따라서 수신자는 `C`로 전송을 세 번 시도했으며, 각 시도 사이에 3초를 기다렸다.

일반 사용자에게 XMODEM-CRC는 "두 번째 프로토콜"처럼 취급되었다. 그러나 CRC가 모든 TeLink 전송의 표준으로 정의된 FidoNet 메일러는 그렇지 않았다.

4. 3. XMODEM-1K

XMODEM-1K는 처리량 문제를 해결하기 위해 패킷 크기를 1024바이트로 늘린 방식이다. XMODEM-1K는 XMODEM-CRC의 확장 버전으로, 패킷을 <SOH> 대신 <STX> 문자로 시작하여 ''송신자''에서 더 긴 블록 크기를 나타낸다.

XMODEM-1K는 원래 척 포스버그가 그의 YMODEM 프로토콜에서 도입한 XMODEM에 대한 많은 개선 사항 중 하나였다. 하지만, 소프트웨어 제작자들이 최소한의 기능만 구현하여 호환성이 떨어지는 구현들이 많아졌고, 결국 "YMODEM"이라는 이름이 "XMODEM-1K"와 다양한 YMODEM으로 분리되었다. 따라서 XMODEM-1K는 실제로 YMODEM보다 나중에 나왔지만, 널리 사용되었다.

4. 4. WXModem (Windowed Xmodem)

'''WXModem'''("Windowed Xmodem"의 준말)은 피터 보스웰(Peter Boswell)이 개발한 높은 레이턴시 데이터 링크에 최적화된 Xmodem 파일 전송 프로토콜의 한 종류이다.[16] 최대 512 바이트의 블록 크기를 지원한다. Xmodem은 정지 및 대기 프로토콜을 사용하는 반면 WXModem은 슬라이딩 윈도우 프로토콜을 사용한다.

WXModem은 공중 전화망보다 훨씬 높은 지연 시간을 가지는 공공 X.25 시스템 및 PC Pursuit와 같은 환경에서 사용하기 위해 개발되었다. 이러한 높은 지연 시간은 XMODEM에서 매우 낮은 효율성을 초래했다. 또한, 이러한 네트워크는 종종 제어 문자를 흐름 제어에 사용하는데, 특히 XON/XOFF는 데이터 흐름을 중지시킨다. WXModem은 이러한 문제를 해결하기 위해 XMODEM-CRC를 채택했다.

WXModem은 다음과 같은 주요 변경 사항을 포함한다.

  • 소규모 제어 문자 집합(DLE, XON, XOFF 및 SYN)을 이스케이프하여 제어 문자가 데이터 흐름에 영향을 주지 않도록 했다.
  • 모든 패킷은 SYN 문자로 시작하여 오류 발생 시 SOH가 패킷 헤더로 혼동될 가능성을 줄였다.
  • 슬라이딩 윈도우를 사용하여 고 지연 링크의 처리량을 개선했다. ACK 메시지 뒤에는 ACK 또는 NAK하는 패킷 번호가 따라왔다. 수신기는 1개에서 4개 사이의 패킷을 ACK할 수 있으며, 네 번째 패킷 시퀀스 번호가 있는 ACK는 네 개의 모든 패킷을 ACK하는 것으로 간주된다.


WXModem은 네 개의 패킷마다 ACK를 요구하여 시스템이 5,120억의 패킷 크기를 갖는 것처럼 작동하지만, 오류의 경우 일반적으로 1,280억만 다시 전송하면 되도록 설계되었다. 이는 일반적인 모뎀의 전이중 작동에서는 큰 장점이 아니지만, 한 방향으로 19 kB의 속도와 반환 채널에서 75 비트/s의 속도를 가진 Telebit 모델과 같은 반이중 시스템에서는 중요한 개선이었다.

4. 5. MODEM7

MODEM7은 MODEM7 배치 또는 배치 XMODEM이라고도 하며, XMODEM 프로토콜의 최초 확장으로 알려져 있다. 일반적인 XMODEM 파일 전송은 수신자가 전송자에게 단일 NAK 문자(NAK영어)를 보내는 것으로 시작하며, 전송자는 데이터 시작을 나타내기 위해 단일 SOH(SOH영어)를 보내고 데이터 패킷을 전송한다.

MODEM7은 SOH(SOH영어) 전에 8.3 파일이름 형식으로 파일 이름을 전송하여 이 동작을 약간 변경했다. 각 문자는 개별적으로 전송되었으며 오류 수정의 한 형태로 수신자에 의해 에코되어야 했다. 이를 인식하지 못하는 XMODEM 구현의 경우, 이 데이터는 SOH(SOH영어)가 도착할 때까지 기다리는 동안 단순히 무시되므로 문자가 에코되지 않으며 구현은 기존의 XMODEM으로 되돌아갈 수 있다. "인식하는" 소프트웨어를 사용하면 파일 이름을 사용하여 파일을 로컬로 저장할 수 있다. 전송은 다른 NAK(NAK영어)로 계속될 수 있으며, 각 파일은 수신자에게 전송되는 이름으로 저장된다.

제리 푸르넬은 1983년에 MODEM7을 "아마도 현존하는 가장 인기 있는 마이크로컴퓨터 통신 프로그램"이라고 묘사했다.[7]
MODEM7은 파일 이름을 일반 텍스트로 전송했는데, 이는 XMODEM이 피하려 했던 문제로 인해 손상될 수 있음을 의미했다. 이로 인해 원래 FidoNet 메일러의 저자인 톰 제닝스에 의해 '''TeLink'''가 도입되었다.[1]

TeLink는 원본 파일에 대한 정보를 담은 새로운 "제로 패킷"을 표준화하여 MODEM7의 문제를 피했다. 여기에는 파일 이름, 크기 및 타임스탬프가 포함되었으며, 이는 일반적인 128바이트 XMODEM 블록에 배치되었다. 일반적인 XMODEM 전송은 발신자가 헤더와 함께 "블록 1"을 보내는 것으로 시작하지만, TeLink 헤더 패킷은 "블록 0"으로 표시되었고 으로 시작되었다. 이 패킷에는 파일 생성 날짜 및 시간, 최대 16자 길이의 파일 이름, 4바이트 값의 파일 크기 및 파일을 보내는 프로그램의 이름이 포함되었다.[1]

일반적인 XMODEM 구현은 단순히 패킷을 버릴 것이며, 패킷 번호가 손상되었다고 가정했다. 그러나 수신자가 제로 패킷을 이해하지 못했거나 전송 오류가 발생했기 때문에 으로 응답했는지 발신자가 알 수 없었기 때문에 패킷이 삭제되면 잠재적인 시간 지연이 발생할 수 있었다. TeLink는 일반적으로 FidoNet 표준의 일부로 이를 요구하는 FidoNet 소프트웨어에서만 사용되었으므로 양쪽 모두 항상 이 표준을 지원했기 때문에 실제 문제로 나타나지 않았다.[1]

기본 "블록 0" 시스템은 FidoNet 커뮤니티에서 표준이 되었으며, SEAlink 및 YMODEM과 같은 여러 후속 프로토콜에서 재사용되었다.
FidoNet 시스템용으로 당시 인기 있었던 .arc 데이터 압축 형식의 제작자가 작성한 최초의 서드파티 메일러 중 하나인 '''SEAdog'''에는 WXmodem과 동일한 슬라이딩 윈도우 개념을 기반으로 개선된 전송 프로토콜인 SEAlink가 포함되어 있었다.[1] WXmodem과는 대부분 세부 사항에서 차이가 있었다.

SEAlink는 TeLink에서 도입한 "제로 패킷"을 지원했는데, 이는 헤더가 예상되는 FidoNet 시스템에서 TeLink를 드롭인 교체로 작동하기 위해 필요했다. `ACK` 및 `NAK`는 세 바이트 "패킷"으로 확장되었으며, 원래 XMODEM 패킷 헤더와 동일한 방식으로 `ACK` 또는 `NAK`, 패킷 번호, 패킷 번호의 보수로 시작되었다. 윈도우 크기는 일반적으로 6개의 패킷으로 설정되었다.[1]

SEAlink는 X.25 또는 유사한 링크를 통해 작동하도록 설계되지 않았으므로 이스케이핑을 수행하지 않았다. 이는 제로 패킷이 제대로 작동하기 위해 필요했으며, 이 표준은 WXmodem이 재사용했던 `SYN` 문자를 사용했다.[1] 이러한 변경 사항 외에도 반 이중 링크를 위한 "오버드라이브" 모드를 추가했는데, 이는 성공적으로 전송된 패킷에 대한 ACK를 억제하여 사실상 무한 크기의 윈도우를 만들었다. 이 모드는 제로 블록의 플래그로 표시되었다.[1]

SEAlink는 나중에 여러 가지 다른 개선 사항이 추가되었으며 유용한 범용 프로토콜이었다. 그러나 FidoNet 세계 밖에서는 드물게 사용되었으며 사용자 대상 소프트웨어에서는 거의 보이지 않았다.

4. 8. NMODEM

NMODEM은 1990년에 L. B. 닐이 개발한 파일 전송 프로토콜이다. NMODEM은 XMODEM의 128바이트 블록과는 달리 2048바이트의 더 큰 블록을 사용하는 XMODEM-CRC의 변형이다.[1]

IBM PC 호환 기종 컴퓨터를 위해 터보 파스칼 5.0으로 작성된 별도의 프로그램으로 구현되었다.[1] 블록 크기는 당시 하드 드라이브의 MS-DOS FAT 파일 시스템의 일반적인 클러스터 크기에 맞춰 데이터를 버퍼링하여 쓰기를 더 간단하게 만들었다.[1]

4. 9. Flying-XMODEM

신뢰할 수 있는 연결을 통해, 데이터 블록 수신 완료 전에 미리 '''ACK'''를 보내는 (플라잉하는) 방식으로 전송 속도를 향상시킬 수 있다. 이를 "프로토콜 스푸핑"이라고도 한다. 이 방식은 YMODEM에서 공식화되었다. Flying-XMODEM은 규약 위반이며, 특성상 오류가 발생해도 복구할 수 없다.

5. XMODEM의 한계 및 문제점

XMODEM은 1982년 파키스탄에서 미국으로 오스본 1과 음향 결합기를 사용하여 열악한 전화선으로 기사를 전송하기에 충분히 견고했지만,[6] 몇 가지 결함이 있었다.

XMODEM은 CP/M 머신용으로 작성되었으며, 해당 운영 체제의 몇 가지 특징을 나타낸다. 특히 CP/M의 파일은 항상 128바이트의 배수였으며, 파일의 끝은 문자를 사용하여 블록 내에서 표시되었다. 그러나 다른 운영 체제에는 이러한 특징이 없었으며, 1980년대 초 MS-DOS의 광범위한 도입으로 인해 XMODEM은 파일 종료 표시자로 ''또는'' 를 인식하도록 업데이트해야 했다.

XMODEM은 단순성을 위해 설계되었지만, 전송 실패 또는 더 심하게는 프로토콜에서 감지되지 않은 잘못된 파일이 생성될 수 있는 몇 가지 기본적인 오류가 있었다. 이는 오류 수정을 위해 간단한 체크섬을 사용했기 때문이며, 이는 적절한 짧은 노이즈 버스트로 인해 ''두'' 비트가 반전된 경우 데이터의 오류를 놓치기 쉽다. 또한 헤더 또는 체크섬에 유사한 손상이 발생하면 데이터 자체가 손상되지 않은 경우에도 전송이 실패할 수 있었다.

XMODEM 프로토콜은 송신자가 수신자로부터 또는 메시지를 기다리기 위해 정지해야 했기 때문에 속도가 느린 경향이 있었다. 300 bit/s 모뎀 시대에는 전체 132바이트 패킷을 전송하는 데 4.4 초가 걸렸다(132바이트 * (바이트당 8비트 + 1 시작 비트 + 1 정지 비트) / 초당 300비트). 수신자의 가 송신자로 다시 돌아오고 다음 패킷이 수신자에게 도달하는 데 0.2 초가 걸린다고 가정하면(양방향 모두 0.1 초), 하나의 패킷에 대한 전체 시간은 4.6 초가 되며, 이는 채널 효율성이 92%를 조금 넘는 것이다.

모뎀 속도가 증가함에 따라 고정 지연 시간은 패킷을 전송하는 데 필요한 시간에 비례하여 증가했다. 예를 들어, 2400 bit/s에서는 패킷을 전송하는 데 0.55 초밖에 걸리지 않으므로, /가 사용자 컴퓨터로 다시 돌아오는 데 여전히 0.2 초가 걸린다면, 효율성은 71%로 떨어진다. 9600 bit/s에서는 40% 미만으로, 패킷을 전송하는 데 필요한 시간보다 응답을 기다리는 데 더 많은 시간이 소요된다.

이러한 문제를 해결하기 위해 XMODEM의 여러 새로운 버전이 도입되었다.

XMODEM의 주요 한계 및 문제점은 다음과 같다:


  • 낮은 전송 효율: 정지-대기(stop-and-wait) 프로토콜을 사용하기 때문에 전송 효율이 낮다. 특히 고속 통신 환경에서는 성능 저하가 심각하다.
  • 단일 파일 전송: 한 번에 하나의 파일만 전송할 수 있다.
  • 제한적인 파일 정보: 파일 이름, 크기, 타임스탬프 등의 정보를 전송하는 기능이 없다.
  • 파일 손상 가능성: 파일 끝이 EOF 문자(1Ah)일 경우, 데이터 블록의 패딩 문자와 구별되지 않아 파일 손상을 초래할 수 있다.
  • 제어 코드 처리: 제어 코드에 대한 별도 처리(쿼트, 대체)를 하지 않아, XON/XOFF 문자에 의한 흐름 제어를 사용하는 환경에서 문제가 발생할 수 있다.
  • 단순한 오류 검출: 초기 버전의 체크섬 방식은 오류 검출 능력이 떨어진다. (XMODEM-CRC에서 개선)[14][15]
  • 프로토콜 스푸핑 취약점: 신뢰할 수 있는 연결에서 프로토콜 스푸핑을 통해 성능을 향상시킬 수 있지만, 이는 보안 문제를 야기할 수 있다.

6. YMODEM, ZMODEM

YMODEM과 ZMODEM은 XMODEM의 낮은 효율을 개선하기 위해 개발되었다. YMODEM은 XMODEM-1K를 기반으로 여러 파일을 전송하거나 파일 정보를 전송하는 등의 기능을 추가하였다. ZMODEM은 전송 중단 후 이어받기, 더 효율적인 오류 검출 등 다양한 기능을 제공하며, 대한민국의 PC 통신 환경에서 널리 사용되었다.[1]

참조

[1] 서적 Telecommunications: XMODEM: A Standard Is Born https://books.google[...] PC Mag 1984-04-17
[2] 간행물 In Focus: History lesson: Ward Christensen's free free-exchange software https://books.google[...] InfoWorld 1982-11-01
[3] 문서 Memories http://www.bbsdocume[...] 1992-11-25
[4] 간행물 The ABCs of X-, Y-, and ZMODEM https://archive.org/[...] 2024-10-08
[5] 웹사이트 The Virtual Community http://www.well.com/[...]
[6] 뉴스 Osborne—Behind Guerrilla Lines https://archive.org/[...] 2016-02-15
[7] 뉴스 Interstellar Drives, Osborne Accessories, DEDICATE/32, and Death Valley https://archive.org/[...] 2016-08-28
[8] 웹사이트 NMODEM 1.12 program and source code https://web.archive.[...] 2020-02-13
[9] 웹사이트 NMODEM documentation https://web.archive.[...] 2020-02-13
[10] 서적 Telecommunications: XMODEM: A Standard Is Born https://books.google[...] PC Mag 1984-04-17
[11] 간행물 In Focus: History lesson: Ward Christensen's free free-exchange software https://books.google[...] InfoWorld 1982-11-01
[12] 문서 Memories http://www.bbsdocume[...] 1992-11-25
[13] 웹인용 The Virtual Community http://www.well.com/[...]
[14] 웹인용 XMODEM Protocol Overview http://techheap.pack[...] 2017-10-02
[15] 웹인용 XMODEM/YMODEM PROTOCOL REFERENCE http://techheap.pack[...] 2017-10-02
[16] Github WXmodem 4 program and source code https://github.com/c[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com