X모뎀

XMODEM
X모뎀
통신 프로토콜
목적파일 전송 프로토콜
개발자워드 크리스텐슨[1][2]
서론1977년; 45년 전 (연방)
영향받은YMODEM 외 다수
하드웨어모뎀

XMODEM은 Ward Christensen이 1977년 모뎀에 사용하기 위해 빠른 해킹으로 개발한 간단한 파일 전송 프로토콜입니다.ASM 터미널 프로그램양쪽이 모뎀을 사용했을 때, 유저는 컴퓨터간에 파일을 송신할 수 있었습니다.Keith Petersen은 항상 "quiet mode"를 켜도록 마이너 업데이트를 했고 그 결과를 XMODEM이라고 [3]불렀습니다.

대부분의 파일 전송 프로토콜과 마찬가지로, XMODEM은 수신자가 패킷이 올바르게 수신되었는지 여부를 판단할 수 있도록 추가 정보와 함께 수신자에게 전송되는 일련의 "패킷"으로 원본 데이터를 나눕니다.에러가 검출되면, 수신측은 패킷의 재발송신을 요구합니다.일련의 부정한 패킷에 의해, 전송이 중단됩니다.

XMODEM은 구현이 간단했기 때문에 초기 게시판 시스템(BBS) 시장에서 큰 인기를 끌었다.또한 매우 비효율적이었으며 모뎀 속도가 증가함에 따라 이 문제는 성능을 향상시키거나 프로토콜의 다른 문제를 해결하기 위해 많은 수정 버전의 XMODEM을 개발하게 되었습니다.Christensen은 원래 XMODEM이 "컴퓨팅 [4]역사상 가장 수정된 프로그램"이라고 생각했습니다.

Chuck Forsberg는 그의 YMODEM 프로토콜에 많은 공통적인 수정사항을 수집했지만, 구현 불량으로 인해 나중에 그의 ZMODEM 프로토콜에 의해 다시 통합되기 전에 더 많은 조각이 발생하였습니다.ZMODEM은 큰 인기를 끌었지만, BBS 시장에서 XMODEM을 완전히 대체하지는 못했습니다.

패킷 구조

원래의 XMODEM에서는 CP/M 플로피 디스크에서 사용되는 기본 블록 크기인 128바이트의 데이터 패킷을 사용했습니다.패킷에는 문자, 0 ~255의 '블록 번호' 및 '역' 블록 번호(255 - 블록 번호)를 포함한 단순한3 바이트 헤더가 프리픽스 되어 있습니다.블록 번호는 0이 아닌 처음 전송된 블록에 대해 1로 시작합니다.헤더 뒤에 128바이트의 데이터, 그리고 싱글바이트의 체크섬이 이어집니다.체크섬은 패킷모듈로 256 내의 모든 128 데이터 바이트의 합계입니다.따라서 전체 패킷의 길이는 132바이트로 128바이트의 페이로드 데이터를 포함하며 총 채널 효율은 약 97%였습니다.

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

전송내역

파일이 한 번에 한 패킷씩 전송되었습니다.수신했을 때, 패킷의 체크섬은 수신기에 의해서 계산되어 패킷의 마지막에 송신자로부터 수신된 체크섬과 비교됩니다.2 개의 패킷이 일치하면, 수신측은 송신자에게 메세지를 반송해, 송신자는 다음의 패킷을 순서대로 송신합니다.체크섬에 문제가 있는 경우는, 수신측은 대신에 를 송신했습니다.가 수신되었을 경우, 송신자는 패킷을 재발송신해, 전송을 중단하기 전에, 통상은 10 회까지 몇 회(통상은 10 회) 계속 시행합니다.

또, 문자가 없기 때문에, 수신측이 데이터를 기다리고 있을 때에, 10 초 이내에 유효한 패킷을 수신하지 않은 경우에도, A 가 송신되었습니다.패킷 내에서도 7초의 타임아웃이 사용되어 미드패킷의 접속이 끊어지는 것을 방지합니다.

또한 오류를 확인하기 위한 간단한 방법으로 블록 번호를 조사했습니다.패킷이 정상적으로 수신되면 다음 패킷은 1보다 큰 번호가 됩니다.대신에 같은 블록 번호를 수신했을 경우, 이것은 중대하다고는 생각되지 않습니다.는 송신자에 의해서 수신되지 않고, 그 후 패킷을 재발송신했을 가능성이 있습니다.그 외의 패킷 번호는, 패킷이 없어졌음을 나타냅니다.

전송은 수신기에 의해서 행해졌습니다.송신기는 수신기에 의해서 초기값이 송신될 때까지 데이터를 송신하지 않습니다.이것은, 유저가 리모트에 있는 송신 머신과 상호 작용한 논리적인 결과입니다.사용자는 송신기계에서 요청된 파일로 이동하여 해당 머신에 전송하도록 요청합니다.이 명령어가 발행되면 사용자는 로컬소프트웨어에서 명령을 실행하여 수신을 시작합니다.리모트 시스템에 파일 요구와 로컬명령어 수신까지의 지연은 알 수 없기 때문에 XMODEM은 수신자가 데이터 패킷에 대한 요구를 발행하기 시작할 때까지 최대 90초를 허용합니다.

문제

XMODEM은 1982년 기자가 파키스탄에서 미국으로 Osborne 1과 어쿠스틱 커플러로 질 나쁜 전화선을 [5]통해 기사를 전송할 수 있을 정도로 강력했지만, 프로토콜에는 몇 가지 결함이 있었다.

사소한 문제

XMODEM은 CP/M 머신용으로 작성되었으며 해당 운영체제의 마크가 여러 개 붙어 있습니다.특히 CP/M 상의 파일은 항상 128바이트의 배수이며, 그 끝은 블록 내에서 문자로 표시되었습니다.이러한 특성은 XMODEM에 직접 이식되었습니다.그러나 다른 운영체제는 이러한 특성을 모두 갖추지 못했고, 1980년대 초에 MS-DOS가 널리 보급되면서 XMODEM을 a 또는 파일 끝 마커로 업데이트해야 했습니다.

수신측으로부터의 전송을 용이하게 중단하기 위해서, 또는 가 아닌 문자 송신을 서포트하는 것이 추천되고 있습니다.마찬가지로, 송신자가 전송 취소를 희망하고 있는 것을 대신한 수신자가 수신했습니다.단, 이 문자는 단순한 노이즈 관련 오류로 쉽게 "작성"할 수 있습니다.이 문제를 피하기 위해 이중화를<CAN> 제안했지만 이것이 널리 구현되었는지 여부는 분명하지 않습니다.

주요 문제

XMODEM은 다른 파일 전송 프로토콜에 대한 지식이 거의 없이 단순함을 추구하도록 설계되었습니다. 어쨌든 매우 드물었습니다.이 단순성 때문에 전송 실패 또는 더 나쁜 결과를 초래하는 매우 기본적인 오류가 다수 발생했으며 이는 프로토콜에 의해 인식되지 않았습니다.이는 대부분 오류 수정에 단순한 체크섬을 사용했기 때문입니다.이 체크섬은 2비트가 반전될 경우 데이터 내에서 오류가 누락될 수 있습니다.이 경우 노이즈의 짧은 버스트가 발생할 수 있습니다.또한 헤더 또는 체크섬에 유사한 손상이 있으면 데이터 자체가 손상되지 않은 경우 전송에 실패할 수 있습니다.

많은 저자가 이러한 문제 및 기타 문제에 대처하기 위해 XMODEM에 확장을 도입했습니다.많은 사람들이 이러한 확장을 새로운 XMODEM 표준의 일부로 포함하기를 요청했습니다.그러나 Ward Christensen은 이러한 기능이 정확히 부족하고 이를 지원하기 위한 관련 코딩이 필요하기 때문에 XMODEM의 광범위한 사용을 거부했습니다.그가 설명했듯이:

다른 사람들과 소통하고 싶은 개인적인 욕구를 충족시키기 위해 계획되지 않은 매우 빠른 해킹이었습니다.단지, 8/77에 완성되었고, 제가 그것을 즉시 공개했다는 사실만이 그것이 표준이 되었습니다...
...'전이중', '복수의 미결 블록', '복수의 대상' 등과 같이 프로토콜에 상당한 변경을 가할 것을 제안하는 사람들은 프로토콜의 놀라운 단순성이 프로토콜이 살아남은 이유 중 하나라는 것을 이해하지 못합니다.

배치 전송

XMODEM의 또 다른 문제는 자동이 아닌 사용자 주도 전송이 필요하다는 것입니다.통상, 유저는, 송신측의 시스템으로 이동해, 필요한 파일을 선택한 후, 커맨드를 사용해 그 시스템을 「전송 준비」모드로 합니다.그런 다음 단말 에뮬레이터에서 명령을 사용하여 끝에서 전송을 트리거합니다.사용자가 다른 파일을 전송하려면 이 프로세스를 다시 반복해야 합니다.

두 사이트 간의 자동 전송을 위해, XMODEM 프로토콜에 대한 많은 추가 기능이 시간이 지남에 따라 구현되었습니다.이것들은 일반적으로, 송신측이 파일을 계속 송신하는 것을 전제로 하고 있습니다.수신측은, 다음의 파일을 송신하는 것에 의해서 트리거 하려고 합니다.NAK이체 시작 시 정상적으로 동작합니다.언제?NAK타임아웃이 되었습니다.파일이 없어졌거나 링크가 끊겼다고 가정할 수 있습니다.

모뎀7

모뎀7 배치 또는 배치 XMODEM으로 알려진 모뎀7은 XMODEM 프로토콜의 첫 번째 알려진 확장입니다.통상의 XMODEM 파일 전송은, 리시버가 싱글을 송신하는 것으로 개시됩니다.NAK송신자에게 문자를 송신하면, 1 개의 문자가 송신됩니다.SOH데이터 시작 및 데이터 패킷을 나타냅니다.

모뎀7은 파일명을 8.3 파일명 형식으로 송신함으로써 이 동작을 약간 변경했을 뿐입니다.각 문자는 개별적으로 송신되어 에러 수정의 형태로 수신측에서 에코 할 필요가 있었습니다.비인식 XMODEM 구현의 경우 이 데이터는 단순히 무시되고SOH이 경우 문자가 에코되지 않고 구현이 기존 XMODEM으로 돌아갈 수 있습니다."aware" 소프트웨어를 사용하면 파일 이름을 사용하여 파일을 로컬로 저장할 수 있습니다.전송은 다른 전송과 계속할 수 있습니다.<NAK>각 파일은, 수신자에게 송신되는 이름으로 보존됩니다.

Jerry Pournelle은 1983년에 모뎀7을 "아마 현존하는 가장 인기 있는 마이크로컴퓨터 통신 프로그램"[6]이라고 묘사했다.

TeLink

Modem7은 파일명을 통상의 텍스트로서 송신했습니다.즉, XMODEM이 회피하려고 하고 있던 것과 같은 문제로 인해 파일이 파손될 가능성이 있습니다.이것은 오리지널 FidoNet 메일러의 저자인 Tom Jennings의 TeLink의 도입으로 이어졌다.

TeLink는 원본 파일에 대한 정보를 포함하는 새로운 "제로 패킷"을 표준화함으로써 모뎀7의 문제를 피했습니다.여기에는 파일 이름, 크기 및 타임 스탬프가 포함되며 일반 128바이트 XMODEM 블록에 배치됩니다.한편, 통상의 XMODEM 전송은, 송신측이 「블록 1」을 송신하는 것으로 개시됩니다.<SOH>헤더, TeLink 헤더 패킷은 "block 0"으로 라벨이 붙여져 있습니다.<SYN>패킷에는 파일 생성 날짜와 시간, 파일 이름 최대 16자, 파일 크기 4바이트 값 및 파일을 [7]보내는 프로그램 이름이 포함되어 있습니다.

통상의 XMODEM 실장에서는, 패킷 번호가 파손되어 있는 것을 전제로 하고, 단순히 패킷을 폐기합니다.다만, 송신측은, 수신측이 응답했는지 아닌지를 확인할 수 없었기 때문에, 패킷이 폐기되었을 경우, 시간 지연이 발생할 가능성이 있습니다.<NAK>제로 패킷을 이해하지 못했거나 전송 오류가 있었기 때문입니다.일반적으로 TeLink는 FidoNet 표준의 일부로서 FidoNet 소프트웨어에서만 사용되었기 때문에 양끝이 항상 이 [7]표준을 지원하므로 실제 문제는 발생하지 않았습니다.

기본 "블록 0" 시스템은 FidoNet 커뮤니티에서 표준이 되었고 SEAlink 및 YMODEM과 같은 많은 미래 프로토콜에 의해 재사용되었습니다.

XMODEM-CRC

원래 프로토콜에서 사용된 체크섬은 매우 단순했으며 패킷 내의 오류는 알아차리지 못할 수 있습니다.그 결과 John [8][9]Byrns에 의해 XMODEM-CRC가 도입되어 8비트 체크섬 대신 16비트 CRC가 사용되었습니다.CRC는 패킷 내의 데이터뿐만 아니라 그 위치도 인코딩하므로 체크섬에서 놓칠 수 있는 비트 교환 오류를 알 수 있습니다.이를 통해 통계적으로 16비트 길이의 99.9969% 미만의 오류를 검출할 수 있으며, 긴 오류 비트 [10]문자열의 경우 더 높은 오류를 검출할 수 있습니다.

XMODEM-CRC는 XMODEM과 하위 호환되도록 설계되었습니다.이것을 실시하기 위해서, 수신자는 전송을 개시하기 위해서, a 대신에(대문자 C) 문자를 송신했습니다.송신측이 패킷을 송신하는 것으로 응답했을 경우, 송신측은 「knew」XMODEM-CRC 로 간주해, 수신측은 의 송신을 계속했습니다.패킷이 송신되지 않는 경우, 수신자는 송신자가 프로토콜을 모르는 것으로 간주하고,를 송신하고, 「기존의」XMODEM [10]전송을 개시합니다.

유감스럽게도 이전 버전과의 호환성에 대한 이 시도에는 단점이 있었습니다.최초의 문자가 없어지거나 파손될 가능성이 있기 때문에, 최초의 전송 트리거 시도가 실패했을 경우, 리시버가 XMODEM-CRC 를 서포트하고 있지 않다고는 생각할 수 없습니다.따라서, 수신측은 와의 전송을 3회 개시하려고 하고, 각 시행 사이에 3초간 대기합니다.즉, 사용자가 의도한 대로 XMODEM과 통신하려고 할 때 XMODEM-CRC를 선택했을 [10]경우 전송이 시작되기 전에 10초의 지연이 발생할 수 있습니다.

지연을 피하기 위해서, 송신측과 수신측은 일반적으로 XMODEM-CRC를 XMODEM과 별도로 리스트 합니다.이것에 의해, 송신측이 명시적으로 리스트 하고 있지 않은 경우, 유저는 「기본」XMODEM 을 선택할 수 있습니다.일반 사용자에게 XMODEM-CRC는 본질적으로 "세컨드 프로토콜"이었고 그렇게 취급되었습니다.그러나 CRC가 모든 TeLink [7]전송의 표준으로 정의된 FidoNet 메일러에는 해당되지 않습니다.

높은 스루풋

XMODEM 프로토콜은 송신자가 정지하고 수신자로부터 또는 메시지를 기다려야 했기 때문에 매우 느린 경향이 있었습니다.300비트/초 모뎀 시대에는 132바이트 패킷 전체가 3.5초를 조금 넘는 시간(바이트당8비트+1시작비트+1 스톱비트)/300비트/초)을 필요로 했습니다.수신자가 송신자에게 복귀해, 다음의 패킷이 수신자에게의 타격을 개시하는 데 0.2초가 걸린다고 가정하면(양방향 0.1초), 1 패킷의 전체 시간은 3.7초로, throughput의 92%를 약간 웃돌고 있습니다.

/<NAK> 프로세스의 시간은 모뎀의 퍼포먼스가 아니라 기본 통신 네트워크의 고정 함수입니다.모뎀 속도가 증가함에 따라 고정 지연은 패킷 전송에 필요한 시간에 비례하여 증가했습니다.예를 들어 2400비트/초에서는 패킷 전송에 불과 0.44초밖에 걸리지 않았습니다.따라서 /<NAK>가 사용자의 머신으로 되돌리는 데 0.2초가 걸리면 throughput은 60% 미만으로 떨어집니다.9600 bit/s에서는 30% 미만입니다.패킷의 송신에 필요한 시간보다 회신을 기다리는 시간이 길어집니다.

이러한 문제에 대처하기 위해 다수의 새로운 버전의 XMODEM이 도입되었습니다.이전 확장과 마찬가지로 이러한 버전은 원래 XMODEM과 하위 호환성이 있는 경향이 있으며, 이러한 확장과 마찬가지로 사용자의 터미널 에뮬레이터에서 XMODEM이 더욱 세분화되었습니다.결국 수십 가지 버전의 XMODEM이 등장했습니다.

WXModem

WXmodem은 "Windowed Xmodem"의 줄임말로 1986년 Peter Boswell에 의해 개발된 XMODEM의 변형으로, 특히 공공 X.25 시스템과 PC Pursue에서 사용하기 위해 개발되었습니다.이것들은 일반적인 전화 서비스보다 훨씬 높은 지연 시간을 가지고 있기 때문에 XMODEM의 효율이 매우 저하됩니다.또한 이러한 네트워크에서는 흐름 제어 및 기타 작업에 제어 문자를 사용하는 경우가 많습니다.특히 XON/XOFF는 데이터 흐름을 정지합니다.마지막으로, 재발송신할 필요가 있는 에러의 경우, 경우에 따라서는, 이 에러의 유무를 알기 어려운 경우가 있었습니다.SOH패킷 인디케이터 또는 노이즈 이상입니다.WXmodem은 이러한 [10]문제에 대처하기 위해 XMODEM-CRC를 채택했습니다.

한 가지 변경 사항은 작은 제어 문자 세트를 이스케이프하는 것입니다.DLE,XON,XOFF그리고.SYN이것들은 1개의 칩을 삽입하여 탈출한 것입니다.DLE그 앞에서 64로 XOR을 해서 캐릭터를 수정하는 거죠.이론적으로는 패킷이 원래 이스케이프가 필요한 문자로만 구성되어 있다면 패킷의 길이는 264바이트에 달할 수 있습니다.이러한 삽입 및 수정된 문자는 CRC 계산의 일부가 아니며 CRC [10]계산 전에 수신측에서 제거 및 변환됩니다.

또, 모든 패킷에 프리픽스가 부가되어 있습니다.SYN즉, 패킷의 리드인은SYNSOH표류자가 다른 사람의 목숨을 빼앗을 가능성을 줄이다.SOH는, 다양한 에러의 경우, 패킷헤더에 혼동을 일으킬 가능성이 있습니다.탈출하지 않은 사람SYN패킷 본문에서 발견된 [10]오류입니다.

WXMODEM의 주요 변경사항은 슬라이딩 윈도우를 사용하여 지연 시간이 긴 링크의 throughput을 향상시킨다는 것입니다.그러기 위해서는ACK메시지 뒤에 패킷 번호가 표시됩니다.ACK또는NAK수신자는 다음 명령을 수행할 필요가 없습니다.ACK모든 패킷, 즉ACK1 ~ 4 패킷의 임의의 번호.안ACK4번째 패킷시퀀스 번호는ACK4개의 패킷 모두에러가 원인이 되어NAK그 번호로부터의 모든 패킷과 재발송신 [10]후에 즉시 송신됩니다.

필요한 것은ACK4개의 패킷마다 시스템은 512바이트의 패킷사이즈를 가지는 것처럼 동작합니다만, 에러가 발생했을 경우는, 통상 128바이트만을 재발송신하면 됩니다.또한 역방향으로 흐르는 데이터의 양을 4배까지 줄일 수 있습니다.이것은 일반적인 모뎀의 전이중 동작에는 거의 관심이 없지만, Telebit 모델 등의 반이중 시스템에서 중요합니다.Telebit 모델에서는 한 방향으로 19kB, 리턴 채널에서는 75비트/s의 속도를 가집니다.

SEA 링크

FidoNet 시스템의 첫 번째 서드파티 메일러 중 하나는 SEADog로, 당시 인기 있던 .arc 데이터 압축 형식과 동일한 작성자가 작성했습니다.SEADog은 WXmodem과 [11]동일한 슬라이딩 윈도우 개념을 기반으로 개선된 전송 프로토콜인 SEAlink를 포함한 다양한 개선 사항을 포함했습니다.그것은 대부분 WX모뎀과 세부적으로 달랐다.

한 가지 차이점은 SEALink가 TeLink에 의해 도입된 "제로 패킷"을 지원한다는 것입니다.이는 헤더가 예상되는 FidoNet 시스템에서 TeLink의 드롭인 대체품으로 동작하기 위해 필요합니다. ACK및NAK는 3바이트의 "context"로 확장되어 있습니다.ACK또는NAK패킷 번호, 패킷 번호의 보완은 원래의 XMODEM 패킷헤더와 같은 방법으로 행해집니다.윈도 사이즈는 보통 6 [11]패킷으로 설정되어 있었습니다.

SEA 링크는 X.25 또는 유사한 링크 상에서 동작할 것으로 예상되지 않았기 때문에 이스케이프를 실행하지 않았습니다.이 표준에서는, 제로 패킷이 올바르게 동작하기 위해서도 필요했습니다.SYNWXmodem이 [11]용도를 변경한 문자입니다.이러한 변경에 가세해 반이중 링크의 「오버 드라이브」모드를 추가했습니다.이것에 의해, 정상적으로 전송 된 패킷의 ACK 가 억제되어 사실상 무한대의 사이즈의 창이 됩니다.이 모드는 제로 [11]블록의 플래그로 표시되어 있습니다.

SEAlink는 나중에 많은 다른 개선사항을 추가하였고 유용한 범용 프로토콜이었다.그러나 FidoNet 밖에서는 드물었고 사용자 대면 소프트웨어에서는 거의 볼 수 없었습니다.

XMODEM-1K

throughput 문제를 해결하는 다른 방법은 패킷사이즈를 늘리는 것입니다.레이텐시의 근본적인 문제는 남아 있지만, 문제가 되는 속도는 더 빨라집니다.1024 바이트의 패킷을 가진 XMODEM-1K가 가장 인기 있는 솔루션이었습니다.이 경우 9600비트/초의 throughput은 81%입니다.상기와 같은 전제 조건입니다.

XMODEM-CRC의<>로 패킷을 시작으로, 송신자에 더 오래 블록 크기를 나타냈다 X모뎀-1K는 늘린다.STX>, < 대신 캐릭터들을 말한다.SOH&gt을 말한다.다른 호환이 가능한 XMODEM 확장처럼,-1K 전달 XMODEM의 실행이와 다른 쪽 끝에, 필요 시 기능에서 물러난 시작할 수 있는 위한 것이었다.

XMODEM-1K는 원래 Chuck Forsberg가 YMODEM 프로토콜에서 도입한 XMODEM의 많은 개선 사항 중 하나였다.Forsberg는 소프트웨어 작성자가 가능한 한 많은 개선사항을 구현하기를 기대하면서 다양한 개선사항은 선택 사항이라고 제안했습니다.그 대신 최소한의 실장만을 실시해 준호환성이 풍부한 실장을 실시해, 최종적으로 「YMODEM-1K」라는 이름을 「XMODEM-1K」와 다양한 YMODEM으로 분할했습니다.따라서 XMODEM-1K는 실제로 YMODEM 이후의 실장도 꽤 일반적이었습니다.

모뎀

NMODEM은 L. B. 닐이 1990년에 개발한 파일 전송 프로토콜입니다.NMODEM은 본질적으로 XMODEM의 128바이트 블록과는 달리 더 큰 2048바이트 블록을 사용하는 XMODEM-CRC 버전입니다.NMODEM은 IBM PC 호환 컴퓨터 제품군을 위해 Turbo Pascal 5.0으로 작성된 별도의 프로그램으로 구현되었습니다.블록 사이즈는, 현재의 하드 드라이브의 MS-DOS FAT 파일 시스템의 공통 클러스터 사이즈에 맞추어 선택되었기 때문에,[12][13] 데이터 기입의 버퍼링이 간단하게 되었습니다.

프로토콜 스푸핑

신뢰성이 높은(에러가 없는) 접속에서는, 보다 일반적으로 「프로토콜 스푸핑」이라고 불리는 기술인 패킷을 「사전 확인」함으로써, 지연을 없앨 수 있습니다.이것은 보통 링크하드웨어, 특히 텔레비트모뎀에서 실행됩니다.이 옵션을 켜면 모뎀은 XMODEM 헤더를 인식하고 즉시 패킷을 전송합니다.ACK이것에 의해, 송신측 XMODEM 프로그램이 즉시 다음의 패킷을 송신해, 무한대의 창과 같이 전송을 계속합니다.또한 모뎀은 이 명령어를ACKXMODEM 소프트웨어에 의해 원단에 송신되어 저속 리턴 채널이 해방됩니다.

시스템은 프로토콜 자체에서도 구현될 수 있으며 XMODEM의 다양한 변형이 이 기능을 제공합니다.이러한 경우, 수신자는, 다음의 정보를 송신합니다.ACKTelebit 모뎀과 같은 방법으로 패킷이 시작되자마자.이 기능은 수신측 동작의 변경일 뿐이므로 송신측 프로토콜의 변경은 필요하지 않습니다.YMODEM이 이 시스템을 공식화했습니다.

이 개념은 SEAlink에서 사용되는 개념과 대조되어야 합니다.SEAlink는 링크 양쪽의 동작을 변경합니다.SEAlink 에서는, 리시버는, 다음의 패킷의 송신을 정지합니다.ACK송신자는, 전혀 기대하지 않게 행동을 바꿉니다.

「 」를 참조해 주세요.

레퍼런스

인용문

  1. ^ 통신: XMODEM: A Standard Is Born By Alfred Glossbrenner, PC Mag, 1984년 4월 17일, 페이지 451-452... 하지만 프로토콜 자체는 오래 전에 그 창안자인 Chicagoan Ward Christensen에 의해 공공 도메인에 배치되었습니다. 1978년 도입된 이후 XMODEM은...
  2. ^ 초점: 역사 수업: Ward Christensen의 무료 교환 소프트웨어, InfoWorld, Michael Swaine, 1982년 11월 1일, 26페이지
  3. ^ Ward Christensen, "Memories", 1992년 11월 25일
  4. ^ "The Virtual Community".
  5. ^ Kline, David (July 1982). "Osborne—Behind Guerrilla Lines". Microcomputing. pp. 42–50. Retrieved 15 February 2016.
  6. ^ Pournelle, Jerry (July 1983). "Interstellar Drives, Osborne Accessories, DEDICATE/32, and Death Valley". BYTE. p. 334. Retrieved 28 August 2016.
  7. ^ a b c 부시 1995, G.1 페이지
  8. ^ 1982년 크리스텐슨
  9. ^ 포르스베르크 1986년
  10. ^ a b c d e f g 보스웰 1986년
  11. ^ a b c d SEALink 1987.
  12. ^ "NMODEM 1.12 program and source code". Archived from the original on 2011-08-07. Retrieved 2020-02-13.
  13. ^ "NMODEM documentation". Archived from the original on 2016-04-09. Retrieved 2020-02-13.

참고 문헌

외부 링크