zModem 프로토콜을 이해합니다
https://stackoverflow.com//questions/9611000
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
내 프로그램에 기본 파일 전송 및 파일 수신 루틴을 포함해야하며 ZModem 프로토콜을 통해 있어야합니다. 문제는 내가 사양을 이해하는 데 어려움을 겪고 있다는 것입니다.
참조를 위해 여기에 사양이 있습니다 .
사양은 다양한 상수를 정의하지 않으므로 Google의 헤더 파일 .
해당 문서에서 정의되지 않은 중요한 것들이 많이있는 것처럼 보입니다.
- 끊임없이 zdle-encoding을 의미하지만 은 무엇입니까? 정확히 사용하는 경우, 언제 그것을 사용하지 않습니까?
- ZFILE 데이터 프레임 이후에 파일의 메타 데이터 (파일 이름, 수정 날짜, 크기 등)가 전송됩니다. 이는 ZCRCW 블록이 뒤 따른 다음 유형이 지정되지 않은 블록이 지정되어 있습니다. ZCRCW 블록에는 16 비트 CRC가 포함되어 있지만 Spec은 CRC가 계산 된 데이터에 대해 정의되지 않습니다.
-
그것은 사용하는 CRC 다항식을 정의하지 않습니다. CRC32 폴리가 표준 CRC32가 될 가능성이 있지만 CRC16 폴리에 그런 운이 없었습니다. 나는 시운전과 오류를 통해 발견했습니다. CRC16 폴리는 0x1021입니다.참조 코드를 찾아 보았지만 90 년대 초반에서 읽을 수없고 서류 미확인 C 파일을 읽을 수 없게됩니다. 나는 또한 MSDN 에서이 문서 집합을 발견했지만, 내가 실행하는 테스트와 고통스럽게 모호하고 모순됩니다 : http://msdn.microsoft.com/en-us/library/ms817878.aspx ( Google의 캐시 )
내 어려움을 설명하기 위해 간단한 예입니다. "Hello World!"가 포함 된 서버에서 일반 텍스트 파일을 만들었고 HelloWorld.txt라고합니다.
i 다음 명령을 사용하여 서버에서 전송을 시작합니다.
.sx --zmodem helloworld.txt서버가 다음 zrqinit 프레임을 보내도록 메시지를 표시합니다.
.2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30 **.B000000000000 30 30 0D 8A 11 00.Š.이 문제에 세 가지 문제 :
- 는 패딩 바이트 (0x2A) 임의입니까? 왜 여기에 두 개가 있지만 다른 경우에는 하나만 있고 때로는 아무 것도 없습니까?
- 이 사양은 끝에 [CR] [LF] [xon]을 언급하지는 않지만 MSDN 기사가 수행하지 않습니다. 왜 그곳에 있니?
- [LF]가 BIT 0x80이있는 이유는 무엇입니까?
이후, 클라이언트는 Zrinit 프레임을 보내야합니다. 나는 이것을 MSDN 기사에서 얻었습니다 :
.2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65 **.B0100000023be 35 30 0D 8A 50.Š[LF] 0x80 플래그 문제 외에도 두 가지 문제가 있습니다.
- 이번에는 [xon]이 포함되어 있지 않은 이유는 무엇입니까?
-
은 2 진 데이터 또는 ASCII 16 진수 데이터에서 계산 된 CRC입니까? 바이너리 데이터에있는 경우 0x197C를 얻고 ASCII 16 진수 데이터에있는 경우 0xF775를 얻습니다. 이것들 중 어느 것도 실제로 프레임 (0xbe50)에있는 것입니다. (해결; 사용중인 모드를 따르고 있습니다. Bin 또는 Bin32 모드에 있으면 이진 데이터의 CRC입니다. 만약 당신이 RE ASCII 16 진수 모드에서는 ASCII 16 진수 문자로 표시되는 CRC입니다.)서버는 zfile 프레임으로 응답합니다.
.2A 18 43 04 00 00 00 00 DD 51 A2 33 *.C.....ÝQ¢3확인. 이것은 의미가 있습니다. [04 00 00 00]의 CRC32를 계산하면 실제로 0x33A251DD를 얻습니다. 그러나 이제 우리는 끝에 [Cr] [lf] [xon]가 없습니다. 왜 이것이 있습니까?
이 프레임이 직후에 서버는 파일의 메타 데이터를 보냅니다.
.68 65 6C 6C 6F 77 6F 72 6C 64 2E 74 78 74 00 31 helloworld.txt.1 33 20 32 34 30 20 31 30 30 36 34 34 20 30 20 31 3 240 100644 0 1 20 31 33 00 18 6B 18 50 D3 0F F1 11 13..k.PÓ.ñ.이것은 헤더가 없어도 데이터로 똑바로 점프합니다. 좋아, 나는 그걸로 살 수있다. 그러나 :
- 우리는 첫 번째 신비한 ZCRCW 프레임을 가지고 있습니다 : [18 6b]. 이 프레임은 얼마나 걸립니까? CRC 데이터는 어디에 있으며 CRC16 또는 CRC32입니까? 그것은 사양의 어느 곳에서나 정의되지 않았습니다.
- MSDN 문서는 [18 6B] 다음에 [00]이어야하지만 그렇지 않음을 지정합니다.
- 그런 다음 정의되지 않은 유형이있는 프레임이 있습니다 : [18 50 D3 0F F1 11]. 이것은 별도의 프레임이거나 ZCRCW의 일부입니까?
클라이언트는 MSDN 문서에서 다시 ZRPOS 프레임으로 응답해야합니다.
.2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38 **.B0900000000a8 37 63 0D 8A 7c.ŠZRINIT 프레임과 동일한 문제점 :
CRC가 잘못된 의 경우 [LF]는 비트 0x80 세트가 있고 [xon]이 없습니다.서버는 ZDATA 프레임으로 응답합니다.
.2A 18 43 0A 00 00 00 00 BC EF 92 8C *.C.....¼ï’Œzfile과 동일한 문제 : CRC는 모두 괜찮지 만 [CR] [LF] [xon]은 어디에 있습니까?이후 서버는 파일의 페이로드를 보냅니다. 이것은 짧은 예이므로 하나의 블록에 적합합니다 (최대 크기는 1024) :
.48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A Hello world!.기사가 언급하는 것처럼 보이는 것으로 보이는 것으로, 페이로드는 [ZDLE]로 이스케이프됩니다. 따라서 [ZDLE]의 가치와 일치하는 페이로드 바이트를 어떻게 전송합니까? 이와 같은 다른 값이 있습니까?서버는이 프레임으로 끝납니다.
.18 68 05 DE 02 18 D0 .h.Þ..Ð 2A 18 43 0B 0D 00 00 00 D1 1E 98 43 *.C.....Ñ.˜C나는 처음으로 완전히 길을 잃었다. Secon.
해결책
시간을 구현하는 경우 나의 친구의 불가사의 기계.
나는 모든 질문에 대답 할 수 있다는 것을 모른다. 실제로 zmodem을 자신을 구현해야했습니다. 그러나 여기에는 몇 가지 답변이 있습니다 :
기사가 언급하는 것처럼 보이는 것처럼 보이는 것으로 보입니다. [ZDLE]. 그렇다면 일어나는 페이로드 바이트를 어떻게 전송합니까? [ZDLE]의 가치? 이와 같은 다른 값이 있습니까?
이 문서에서 링크 된 문서에서 명시 적으로 해결됩니다. 귀하의 질문의 시작 부분 :
.The ZDLE character is special. ZDLE represents a control sequence of some sort. If a ZDLE character appears in binary data, it is prefixed with ZDLE, then sent as ZDLEE.끊임없이 zdle-encoding을 의미하지만 무엇입니까? 정확히 언제 나는 그것을 사용합니까, 그리고 언제 그것을 사용하지 않습니까?
옛날에는 특정 "제어 문자"가 사용하여 통신 채널 (따라서 이름). 예를 들어 XON / XOFF를 보내는 것입니다 문자가 전송을 일시 중지 할 수 있습니다. 다들은 탈출에 사용됩니다 문제가 될 수있는 문자. 사양에 따르면, 이것들은 기본적으로 이스케이프 된 문자 :
.ZMODEM software escapes ZDLE, 020, 0220, 021, 0221, 023, and 0223. If preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to protect the Telenet command escape CR-@-CR. The receiver ignores 021, 0221, 023, and 0223 characters in the data stream.참조 코드를 찾아 보았지만, 내가 찾을 수있는 것은 읽을 수없고 90 초 초반의 서류 미비 파일이 없습니다.
여기에는 lrzsz 패키지의 코드가 포함됩니까? 이것은 여전히입니다 대부분의 Linux 배포판에서 널리 이용 가능합니다 (그리고 놀랍게도 편리하게 설정된 SSH 연결을 통해 파일을 전송하는 경우).
거기에 여러 가지 다른 구현이 있습니다. freecode Qodem , syncterm , Mbse , 다른 사람. 나는 syncterm을 믿습니다 구현 는 쉽게 합리적 일 수있는 도서관으로 작성됩니다. 자신의 코드에서 사용하려면 (하지만 나는 확실하지 않습니다).
이전 컬렉션을 찌르는 경우 추가 코드를 찾을 수 있습니다. MS-DOS 소프트웨어.
다른 팁
나는 너를 비난 할 수 없다. 사용 설명서는 사용자 친화적 인 방식으로 구성되지 않습니다
패딩 바이트 (0x2A) 임의로?
아니오, Page 14, 15 :
이진 헤더는 시퀀스 ZPAD, ZDLE, ZBIN으로 시작됩니다.
ZPAD, ZPAD, ZDLE, ZHEX에서는 ZPAD, ZPAD, ZDLE, ZHEX로 시작됩니다.
.
사양은 끝에 [CR] [LF] [XON]을 언급하지는 않지만 MSDN 기사가 수행하지 않습니다. 왜 그곳에 있니?
페이지 15
* * Zdle B Type F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CR LF XON ...에 [LF]가 왜 비트 0x80을 설정합니까?
확실하지 않습니다. 테라 용어에서 0x80 (8D 8A 11) 에 모두 제어 문자가 모두 X로졌습니다.
우리는 첫 번째 신비한 ZCRCW 프레임을 가지고 있습니다 : [18 6b]. 이 프레임은 얼마나 걸립니까? CRC 데이터는 어디에 있으며 CRC16 또는 CRC32입니까? 그것은 사양의 어느 곳에서나 정의되지 않았습니다.
ZCRCW는 헤더 또는 프레임 유형이 아니며, 수신자에게 다음을 기대할 것을 알려주는 바닥 글과 같습니다. 이 경우 파일 이름을 포함하는 데이터 서브 패킷의 바닥 글입니다. "C"유형 이진 헤더를 사용하고 있기 때문에 32 비트 체크섬이 될 것입니다.
- zdle c 형식 F3 / P0 F0 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CRC-3 CRC-4
.
다음은 정의되지 않은 유형이있는 프레임이 있습니다. [18 50 D3 0F F1 11]. 이것은 별도의 프레임이거나 ZCRCW의 일부입니까?
ZCRCW 데이터 서브 패킷의 CRC입니다. 첫 번째는 0x10이기 때문에 5 바이트이므로 Zdle 이스케이프가 필요한 제어 문자입니다. 나는 0x11이 무엇인지 잘 모르겠습니다.
[xon]이 없습니다.
XON은 16 진수 헤더입니다. 이진 헤더에는 사용하지 않습니다.
- Zdle A 형 F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 ...에 따라서 [ZDLE]의 값과 일치하는 페이로드 바이트를 어떻게 전송합니까?
18 58 (일명 ZDLE)
18 68 05 DE 02 18 D0
데이터 서브 프레임의 바닥 글입니다. 다음 5 바이트는 CRC (마지막 바이트가 ZDLE 인코딩 된) 입니다.
