Z모뎀

ZMODEM
Z모뎀
통신 프로토콜
목적파일 전송 프로토콜
개발자척 포스버그
서론1986년, 36년 전(연장)
포트없음.
하드웨어모뎀

ZMODEM은 1986년 Chuck Forsberg에 의해 개발된 파일 전송 프로토콜로, X.25 네트워크상의 파일 전송을 개선하기 위해 Telenet에 의해 자금이 지원되었습니다.ZMODEM은 이전 프로토콜에 비해 성능이 획기적으로 향상되었을 뿐만 아니라, 재시작 가능한 전송, 송신자에 의한 자동 시작, 확장된 32비트 CRC 및 8비트 클린 전송을 지원하는 제어 문자 견적을 제공하여 제어 문자를 전달하지 않는 네트워크에서 사용할 수 있도록 했습니다.

게시판 시스템(BBS)을 위해 개발된 대부분의 전송 프로토콜과 달리, ZMODEM은 XMODEM에 직접 기반하거나 XMODEM과 호환되지 않았습니다.XMODEM의 많은 변종들은 하나 이상의 단점을 해결하기 위해 개발되어 왔으며, 대부분은 하위 호환성을 유지하고 "클래식" XMODEM 구현으로 성공적으로 전송을 완료하였다.이 목록에는 Forsberg 자체 YMODEM이 포함됩니다.

ZMODEM은 획기적으로 개선된 프로토콜을 생산하기 위해 하위 호환성을 피했습니다.XMODEM의 고성능 종류 중 어느 것과도 같거나 더 나은 성능을 발휘했으며, X.25와 같이 이전에 전혀 작동하지 않았거나 Telebit 모뎀과 같이 성능이 떨어졌던 링크에서도 마찬가지였습니다. 그리고 다른 프로토콜에는 거의 또는 전혀 없는 유용한 기능이 포함되었습니다.ZMODEM은 1990년대 초에 게시판 시스템(BBS)에서 매우 인기를 끌었고, XMODEM이 그랬던 것처럼 널리 보급된 표준이 되었다.

개선점

스트리밍

일반적으로 파일 전송 프로토콜은 파일을 일련의 패킷으로 분해한 다음 한 번에 하나씩 수신자에게 보냅니다.패킷의 주요 부분인 payload는 전송되는 파일의 특정 바이트 수입니다.payload 후에 payload가 올바르게 수신되었는지 여부를 판단하기 위해 사용할 수 있는 체크섬 또는 Cyclic Redundancy Check(CRC; 순회 용장검사)가 실행됩니다.패킷이 올바르게 수신되었을 경우, 수신측은, 다음의 주소를 송신합니다.ACK 메시지와 송신측은, 다음의 패킷의 송신을 개시합니다.

전화 시스템은 지연이라고 불리는 작은 지연을 발생시켜 이 프로세스를 방해합니다.수신측이 ACK 를 곧바로 송신해도, 전화 회선의 지연에 의해, 송신측이 ACK 를 수신해 다음의 패킷을 송신할 때까지, 항상 시간이 걸립니다.모뎀 속도가 증가함에 따라 이 지연은 지연 중에 전송될 가능성이 있는 패킷의 수가 점점 증가하여 채널 효율이 저하됩니다.

XMODEM은 128바이트의 페이로드와 3바이트의 헤더 및 1바이트의 체크섬을 사용하여 패킷당 합계 132바이트를 사용했습니다.300 bps 모뎀 시대에는 패킷 전송에 약 4초가 걸렸고, 일반적인 지연은 다음과 같습니다.1µ10초이므로 퍼포먼스 오버헤드는 크지 않습니다.속도가 증가함에 따라 문제가 더욱 심각해집니다.2400 bps에서는 패킷의 송신에 약1µ2 가 소요되기 때문에 사용 가능한 대역폭의 약1µ5 가 ACK 를 기다리는 동안 낭비됩니다.9600 bps에서는 패킷의 송신에 필요한 시간은 0.13초뿐이므로 대역폭의 약 1⁄2가 낭비됩니다.

이 문제의 해결 방법 중 하나는 슬라이딩 윈도우를 사용하는 것입니다.이러한 프로토콜은 ACK를 기다리지 않고 송신자가 다수의 패킷을 계속 송신할 수 있도록 함으로써 지연에 대처합니다.계속할 수 있는 패킷의 수는, 「창」입니다.대부분의 실장에서는, 통상은 2 ~16 패킷이었습니다.1980년대 초에 슬라이딩 윈도우를 지원하는 다수의 새로운 버전의 XMODEM이 등장했습니다.

슬라이딩 윈도우는 기존 전화 회선에서의 XMODEM의 경우와 같이 여러 패킷 길이의 지연에 도움이 됩니다.그러나 해외전화나 PC Purset와 같은 X.25 서비스(지연시간이 1초 이상인 경우)에서 발생하는 더 긴 지연시간을 해결하는 것만으로는 충분하지 않습니다.Telebit 모뎀이나 US Robotics 모뎀과 같이 리버스 채널이 송신 채널보다 훨씬 느린 경우에는 적은 수의 ACK로도 리턴 채널이 과부하가 되어 전송이 일시 정지될 수 있습니다.

ZMODEM은 ACK의 필요성을 전혀 배제함으로써 이러한 문제에 대처하고, 수신측이 에러를 검출하지 않는 한, 송신측은 데이터를 계속 송신할 수 있게 되었습니다.문제가 있는 경우에만 NAK만 전송하면 됩니다.ZMODEM 은, X.25 와 같이 에러 수정 기능이 짜넣어진 링크상에서 자주 사용되고 있기 때문에, 수신측은 송신자에게 메세지를 1 개도 송신하지 않는 경우가 많습니다.그 결과, 시스템은 파일 전체를 연속 스트림으로 전송하며, ZMODEM은 자신을 "스트리밍 프로토콜"이라고 불렀다.

ZMODEM의 성능은 이전의 일반적인 프로토콜보다 매우 향상되어 일반적으로 오류 수정이 전혀 포함되지 않은 YMODEM-g와 같은 특별한 프로토콜도 대체하였고 대신 모뎀에 의해 유지되는 오류 없는 링크에 의존하였다.YMODEM-g는 더 빨랐지만, 재시작 가능한 전송과 같은 다른 기능이 없기 때문에 매력적이지 않았습니다.

다시 시작

XMODEM 및 이에 기반한 대부분의 프로토콜은 데이터에 1~255의 패킷 번호를 부가함으로써 패킷 순서를 관리했습니다.윈도우 버전에서는 이 패킷 번호를 사용하여 올바르게 수신된 패킷을 나타내거나 수신되지 않은 패킷을 지정합니다.패킷의 길이는 128바이트이므로 패킷 번호가 롤오버되기 전에 전송할 수 있는 최대 데이터량은 32kB였습니다.

ZMODEM은 패킷 번호를 파일 내의 실제 위치(32비트 번호)로 대체했습니다.이것에 의해, 파일의 길이에 관계없이, NAK 메시지를 송신해, 전송의 장해를 재발송신 할 수 있게 되었습니다.이 기능은, 전송이 실패했을 경우, 또는 의도적으로 중단되었을 경우, 전송을 재기동하기 위해서도 사용되었습니다.이 경우, 수신측은 이전에 수신한 데이터의 양을 확인한 후, 그 로케이션과 함께 NAK 를 송신해, 자동적으로 송신측이 그 포인트로부터 개시하도록 트리거 합니다.

자동 기동

송신 머신이 전송을 개시할 수 있도록 하는 것으로, 관리의 심플화를 자동 개시합니다.이전에는 사용자가 먼저 파일을 송신자에게 요청하여 "대기" 상태로 만든 후 로컬 프로그램으로 돌아가 전송을 시작하는 명령을 실행해야 했습니다.자동 전송에서는, 파일을 요구하기만 하면, 송신자는 자동적으로 유저의 프로그램에서 전송을 개시합니다.

바리에이션

다수의 ZMODEM 수정 버전이 등장했습니다.ZedZap은 고속 모뎀에서 더 나은 성능을 위해 8kbyte 블록을 가진 ZMODEM의 변형입니다.LeechZmodem은 BBS 다운로드 쿼터를 속인 장난스러운 ZMODEM 변형(유사한 XMODEM 및 YMODEM 파생 모델 중 하나)입니다.32kbyte 및 64kbyte 블록 길이를 가진 ZMODEM의 하위 호환성 확장은 ISDN이나 TCP/IP 네트워크와 같은 고속 오류 없는 연결 성능을 향상시키기 위해 ADONTEC에 의해 2002년과 2007년에 작성되었습니다.

가장 주목할 만한 ZMODEM 구현은 Chuck Forsberg의 Omen Technology, Inc.에서 제공한 것입니다.여기에는 DSZ(DOS Send ZMODEM), GSZ(Graphical Send ZMODEM), 유닉스용 유비쿼터스(l)rzz 등이 포함됩니다.

현재 Synchronet 개발자들은 Windows 및 Unix에서 네이티브로 실행되는 zmtx/zmrx 패키지에 대략적으로 기반하여 긴 파일 이름과 더 빠르고 안정적인 데이터 전송을 지원하는 SEXYZ라는 최신 X/Y/ZMODEM 구현을 개발했습니다.SEXYZ의 ZMODEM 실장은 SyncTERM 프로젝트에도 포함되어 있습니다.Synchronet, SLEXYZ 및 SyncTERM은 모두 오픈 소스 크로스 플랫폼 BBS 중심의 프로젝트입니다.

Forsberg 본인은 ZMODEM-90에 대한 많은 개선사항을 수집했습니다.그 중 첫 번째는 MobyTurbo로 성능을 더욱 향상시키기 위해 제어 견적을 삭제했습니다.제어 문자를 「먹는다」는 네트워크에서도, ZMODEM-90은, 가능한 모든 문자가 아니고, 네트워크가 실제로 먹는 문자만을 인용하도록 커스터마이즈 할 수 있습니다.이와 비슷한 개선으로 ZMODEM-90은 7비트 네트워크에서 동작할 수 있게 되었지만, 이전의 프로토콜(Kermit 제외)은 모두 8비트를 1도 또는 그 이상으로 요구했습니다.마지막으로 ZMODEM-90은 비압축 파일에서의 성능을 더욱 향상시키기 위한 기본적인 런렝스 부호화 압축 시스템을 포함한다.

제한 사항

  • 일부 ZMODEM 패킷(예: 잭, ZRPOS)은 32비트 부호 없는 정수로 전송된 파일 내에 바이트 오프셋을 포함합니다.이 설계에서는 ZMODEM이 크기가 4GB 미만인 파일만 안정적으로 전송할 수 있는 가능성을 제한합니다.
  • 프로토콜이 이를 허용할 수 있더라도 참조(l)rzz 구현은 telnet 및 ssh와 같은 TCP/IP 연결 프로그램에서 클라이언트 측 "터미널 이스케이프" 문자로 자주 사용되는 임의의 비제어 문자(예: '~')를 인코딩할 수 없습니다.이러한 종류의 링크(ssh - e none user@hostname 등)를 통해 신뢰성 높은 전송을 실현하려면 터미널 이스케이프 기능을 비활성화해야 합니다.

레퍼런스

외부 링크