Comprendere il protocollo ZMODEM

Question

Ho bisogno di includere file di base-invio di file e la ricezione di routine nel mio programma, e ha bisogno di essere attraverso il protocollo ZMODEM.Il problema è che sto avendo difficoltà a capire la spec.

Per riferimento, ecco le specifiche.

La specifica non definisce le varie costanti, quindi ecco un file di intestazione da Google.

Mi sembra che ci sono un sacco di cose importanti sinistra non definito nel documento:

• Esso si riferisce costantemente a ZDLE di codifica, ma che cosa è? Quando esattamente lo uso, e quando non lo uso?
• Dopo un ZFILE frame di dati, metadati del file (nome del file, data di modifica, dimensione, etc.) sono trasferiti.Questo è seguito da una ZCRCW blocco e quindi un blocco, il cui tipo è definito secondo la specifica.Il ZCRCW blocco presumibilmente contiene CRC a 16-bit, ma la spec non definire su quali dati il CRC viene calcolato.
• Non definire il CRC polinomio si utilizza.Ho scoperto per caso che il CRC32 poly è lo standard CRC32, ma ho avuto tanta fortuna con il CRC16 poli. Nevermind, ho trovato attraverso tentativi ed errori.Il CRC16 poly è 0x1021.

Ho guardato in giro per il codice di riferimento, ma tutto quello che posso trovare sono illeggibili, prive di documenti C file dai primi anni ' 90.Ho anche trovato questo set di documenti da MSDN, ma è dolorosamente vago e contraddittorio test che ho eseguito: http://msdn.microsoft.com/en-us/library/ms817878.aspx (potrebbe essere necessario visualizzare che attraverso Google cache)

Per illustrare la mia difficoltà, ecco un semplice esempio.Ho creato un file di testo semplice, sul server che contiene "Ciao mondo!", e si chiama helloworld.txt.

Io avviare il trasferimento dal server con il seguente comando:

sx --zmodem helloworld.txt

Questo richiede che il server invia il seguente ZRQINIT telaio:

2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30   **.B000000000000
30 30 0D 8A 11                                    00.Š.

Tre problemi con questo:

• Sono i byte di riempimento (0x2A) arbitrario?Perché ci sono due qui, ma in altri casi c'è solo una, e, a volte nessuno?
• La spec non parlare del [CR] [LF] [XON] alla fine, ma l'articolo di MSDN fa.Perché è lì?
• Perché il [LF] hanno po 0x80 set?

Dopo questo, il cliente deve inviare una ZRINIT telaio.Ho ricevuto questo da l'articolo di MSDN:

2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65   **.B0100000023be
35 30 0D 8A                                       50.Š

Oltre al [LF] 0x80 bandiera problema, ho due problemi:

• Perché non è [XON] incluso questo momento?
• È il CRC calcolato su dati binario o ASCII hex dati?Se e ' per dati binari ho 0x197C, e se è in ASCII hex dati ho 0xF775;nessuno di questi sono ciò che in realtà è la cornice (0xBE50). (Risolto;segue qualunque sia la modalità che si sta utilizzando.Se siete in BIN o BIN32 modalità, è il CRC di dati binari.Se siete in ASCII hex modalità, è il CRC di ciò che è rappresentato dall'ASCII caratteri hex.)

Il server risponde con un ZFILE telaio:

2A 18 43 04 00 00 00 00 DD 51 A2 33               *.C.....ÝQ¢3

OK.Questo ha senso.Se calcolo il CRC32 di [04 00 00 00 00], ho davvero ottenere 0x33A251DD.Ma ora non abbiamo [CR] [LF] [XON] alla fine.Perché è questo?

Subito dopo questa cornice, il server invia anche i metadati del file:

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Ó.ñ.

Questo anche se non ha una testa, salta direttamente ai dati.OK, posso vivere con questo.Tuttavia:

• Abbiamo il nostro primo misteriosa ZCRCW telaio:[18 6B].Quanto è lungo questo telaio?Dove è il CRC di dati, ed è CRC16 o CRC32?Essa non è definita ovunque spec.
• L'articolo di MSDN specifica che il [18 6B] dovrebbe essere seguita da [00], ma non è così.
• Poi abbiamo un telaio con un tipo indefinito:[18 50 D3 0F F1 11].È questo un frame separato o è parte di ZCRCW?

Il client deve rispondere con un ZRPOS telaio, ripreso dall'articolo di MSDN:

2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38   **.B0900000000a8
37 63 0D 8A                                       7c.Š

Stessi problemi con il ZRINIT telaio: il CRC è sbagliato, il [LF] ha po ' 0x80 set, e non c'è [XON].

Il server risponde con un ZDATA telaio:

2A 18 43 0A 00 00 00 00 BC EF 92 8C               *.C.....¼ï’Œ

Stessi problemi ZFILE:il CRC è tutto bene, ma dov'è la [CR] [LF] [XON]?

Dopo questo, il server invia il file payload.Dal momento che questo è un breve esempio, si inserisce in un blocco (di dimensione massima di 1024):

48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A            Hello world!.

Da che cosa l'articolo sembra accennare, carichi sono fuggiti con [ZDLE].Allora, come faccio a trasmettere un carico di byte che corrisponde con il valore di [ZDLE]?Ci sono anche altri valori come questo?

Il server termina con queste cornici:

18 68 05 DE 02 18 D0                              .h.Þ..Ð
2A 18 43 0B 0D 00 00 00 D1 1E 98 43               *.C.....Ñ.˜C

Sono completamente perso il primo.Il secondo ha senso tanto quanto il ZRINIT e ZDATA fotogrammi.

Answer 1

Il mio amico chiede se si implementa un tempo macchina.

Non so che posso rispondere a tutte le vostre domande-non ho mai effettivamente dovuto implementare zmodem me -- ma qui ci sono un paio di risposte:

Da che cosa l'articolo sembra accennare, carichi sono fuggiti con la [ZDLE].Allora, come faccio a trasmettere un carico di byte che corrisponde con il valore di [ZDLE]?Ci sono anche altri valori come questo?

Questo è affrontato esplicitamente il documento è collegato al inizio delle vostre domande, che dice:

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.

Esso si riferisce costantemente a ZDLE di codifica, ma che cosa è?Quando esattamente non lo uso, e quando non lo uso?

Nei Vecchi Giorni, alcuni "caratteri di controllo" sono stati utilizzati per controllare il canale di comunicazione (da qui il nome).Per esempio, l'invio di XON/XOFF caratteri potrebbe mettere in pausa la trasmissione.ZDLE è utilizzato per la fuga i caratteri che possono essere problematici.Secondo la specifica, questi sono i caratteri di escape per impostazione predefinita:

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.

Ho guardato in giro per il codice di riferimento, ma tutto quello che posso trovare sono illeggibile, privi di documenti, file C dai primi anni ' 90.

Questo include il codice per il lrzsz pacchetto?Questo è ancora ampiamente disponibile sulla maggior parte delle distribuzioni Linux (e sorprendentemente maneggevole per la trasmissione di file tramite una connessione ssh).

Ci sono un certo numero di altre implementazioni là fuori, tra cui vari software elencati sul freecode, tra cui qodem, syncterm, MBSE, e gli altri.Credo che il syncterm attuazione è scritto come libreria che può essere ragionevole, facile per utilizzare dal proprio codice (ma non ne sono certo).

Si può trovare un codice aggiuntivo se ti facessi un giro vecchie collezioni di Software di MS-DOS.

Answer 2

Non posso biasimare.Il manuale non è organizzato in un modo facile da usare

Sono i byte di riempimento (0x2A) arbitrario?

No, da pagina 14,15:

Un binario di intestazione inizia con la sequenza ZPAD, ZDLE, ZBIN.

Un hex intestazione inizia con la sequenza ZPAD, ZPAD, ZDLE, ZHEX.

.

La spec non parlare del [CR] [LF] [XON] alla fine, ma l'articolo di MSDN fa.Perché è lì?

Pagina 15

* * ZDLE TIPO B F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON .Perché il [LF] hanno po 0x80 set?

Non sono sicuro.Da Tera term ho avuto sia i caratteri di controllo Xor con 0x80 (8D 8A 11)

Abbiamo il nostro primo misteriosa ZCRCW telaio:[18 6B].Quanto è lungo questo telaio?Dove è il CRC di dati, ed è CRC16 o CRC32?Essa non è definita ovunque spec.

Il ZCRCW non è un'intestazione o un tipo di frame, è più come un piè di pagina che racconta il ricevitore cosa aspettarsi next.In questo caso è il piè di pagina dei dati subpacket contenente il nome del file.Sarà una versione a 32 bit di checksum, perché si sta utilizzando un tipo "C" binario di intestazione.

• ZDLE C TIPO F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC 2 CRC 3 CRC-4

.

Poi abbiamo un telaio con un tipo indefinito:[18 50 D3 0F F1 11].È questo un frame separato o è parte di ZCRCW?

Che il CRC per il ZCRCW dati subpacket.Si tratta di 5 byte, perché il primo è 0x10, un carattere di controllo che deve essere ZDLE sfuggito.Io non sono sicuro di quello che 0x11 è.

e non c'è [XON].

XON è solo per Hex intestazioni.Non lo uso per un binario di intestazione.

• ZDLE UN TIPO F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 .Allora, come faccio a trasmettere un carico di byte che corrisponde con il valore di [ZDLE]?

18 58 (AKA ZDLEE)

18 68 05 DE 02 18 D0

Che il piè di pagina di dati di controtelaio.Il prossimo 5 byte CRC (ultimo byte è ZDLE codificato)