Comprendre le protocole Zmodem

Question

Je dois inclure les routines de base-d'envoi de fichiers et de réception de fichiers dans mon programme, et il doit être via le protocole Zmodem. Le problème est que j'ai du mal à comprendre la spécification.

Pour référence, Voici la spécification .

La spécification ne définit pas les différentes constantes, voici donc Un fichier d'en-tête de Google .

Il me semble que peu de choses importantes sont laissées indéfinies dans ce document:

• Il fait constamment référence à zdle-coding, mais Qu'est-ce que c'est? Quand est-ce que je l'utilise exactement, et quand je ne l'utilise pas?
• Après une trame de données ZFILE, les métadonnées du fichier (nom de fichier, modification de la date, de la taille, etc.) sont transférées. Ceci est suivi d'un bloc zcrcw, puis d'un bloc dont le type est indéfini en fonction de la spécification. Le bloc ZCrcw contient un CRC 16 bits, mais la spécification ne définit pas sur quelles données le CRC est calculé.
• Il ne définit pas le polynôme de CRC utilise. J'ai découvert par hasard que le CRC32 Poly soit le CRC32 standard, mais je n'ai pas eu de chance de ce type avec le CRC16 Poly. Nevermind, je l'ai trouvé à travers l'essai et l'erreur. Le CRC16 Poly est 0x1021.

  J'ai regardé autour de vous pour le code de référence, mais tout ce que je peux trouver, ce sont des fichiers C illisibles et non documentés du début des années 90. J'ai également trouvé cet ensemble de documents du MSDN, mais il est douloureusement vague et contradictoire aux tests que j'ai couru: http://msdn.microsoft.com/en-us/library/ms817878.aspx (vous devrez peut-être visualiser cela via Cache de Google )

  Illustrer mes difficultés, voici un exemple simple. J'ai créé un fichier en plainte sur le serveur contenant "Hello World!", Et ça s'appelle helloworld.txt.

  J'en initie le transfert du serveur avec la commande suivante:

  sx --zmodem helloworld.txt
  

  Ceci invite le serveur à envoyer le cadre ZRQinit suivant:

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

  Trois problèmes avec ceci:

  • sont les octets de rembourrage (0x2a) arbitraires? Pourquoi y a-t-il deux ici, mais dans d'autres cas, il n'y en a qu'un, et parfois aucune?
  • La spécification ne mentionne pas le [CR] [LF] [xon] à la fin, mais l'article MSDN le fait. Pourquoi est-il là?
  • Pourquoi le [LF] a-t-il un jeu de bit 0x80?

    Après cela, le client doit envoyer un cadre Zrinit. J'ai reçu cela de l'article MSDN:

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

    En plus de la question du drapeau [LF] 0x80, j'ai deux autres problèmes:

    • pourquoi [xon] n'est-il pas inclus cette fois-ci?
    • est le CRC calculé sur les données binaires ou les données HexII Hex? Si c'est sur les données binaires, je reçois 0x197c, et si c'est sur les données hexagonales ASCII, je reçois 0xf775; Aucun de ceux-ci n'est en réalité dans le cadre (0xbe50). (résolu; il suit le mode que vous utilisez. Si vous êtes dans le mode BIN ou BIN32, c'est la CRC des données binaires. Si vous " Re dans le mode hexagonal ASCII, c'est la CRC de ce qui est représenté par les caractères hexagonaux ASCII.)

      Le serveur répond avec un cadre ZFILE:

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

      OK. Celui-ci a du sens. Si je calculez le CRC32 de [04 00 00 00 00 00], j'obtiens bien 0x33a251dd. Mais maintenant, nous n'avons pas de [Cr] [lf] [xon] à la fin. Pourquoi est-ce?

      Immédiatement après cette trame, le serveur envoie également les métadonnées du fichier:

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

      Cela n'a même pas d'en-tête, il saute simplement directement sur les données. Ok, je peux vivre avec ça. Toutefois:

      • Nous avons notre premier cadre mystérieux ZCRCW: [18 6B]. Combien de temps dure cette image? Où se trouve les données CRC, et est-ce CRC16 ou CRC32? Il n'est pas défini nulle part dans la spécification.
      • L'article MSDN spécifie que le [18 6b] devrait être suivi de [00], mais ce n'est pas le cas.
      • Ensuite, nous avons une image avec un type non défini: [18 50 D3 0F F1 11]. Est-ce un cadre séparé ou fait-il partie de zcrcw?

        Le client doit répondre avec un cadre ZRPOS, à nouveau extrait de l'article MSDN:

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

        Mériens identiques que avec la trame Zrinit: Le CRC est faux , le [LF] a le bit 0x80 set, et il n'y a pas de [xon].

        Le serveur répond avec un cadre ZData:

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

        mêmes problèmes que ZFILE: Le CRC est tout bien, mais où est le [CR] [LF] [XON]?

        Après cela, le serveur envoie la charge utile du fichier. Comme il s'agit d'un court exemple, il convient à un bloc (taille maximale est 1024):

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

        De ce que l'article semble mentionner, les charges utiles sont échappées avec [ZDLE]. Alors, comment puis-je transmettre un octet de charge utile qui correspond à la valeur de [ZDLE]? Y a-t-il d'autres valeurs comme celle-ci?

        Le serveur se termine par ces cadres:

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

        Je suis complètement perdu sur le premier. Le secon

d a le plus de sens que les cadres Zrinit et ZData.

Answer 1

mon copain merveille si vous mettez en œuvre un temps machine.

Je ne sais pas que je peux répondre à toutes vos questions - je n'ai jamais effectivement dû mettre en œuvre zmodem moi-même - mais voici quelques réponses:

de ce que l'article semble mentionner, les charges utiles sont échappées avec [Zdle]. Alors comment puis-je transmettre un octet de charge utile qui arrive à correspondre à la valeur de [zdle]? Y a-t-il d'autres valeurs comme celle-ci?

Ceci est explicitement abordé dans le document que vous avez lié à la Début de vos questions, qui dit:

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.

Il fait constamment référence à un codage de ZDLE, mais qu'est-ce que c'est? Quand exactement Est-ce que je l'utilise et quand je ne l'utilise pas?

dans les vieux jours, certains "personnages de contrôle" ont été utilisés pour contrôler la canal de communication (d'où le nom). Par exemple, envoyer XON / XOFF Les caractères peuvent suspendre la transmission. ZDLE est utilisé pour s'échapper caractères qui peuvent être problématiques. Selon la spécification, celles-ci sont Les caractères qui sont échappés par défaut:

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.

J'ai regardé autour de vous pour le code de référence, mais tout ce que je peux trouver sont Des fichiers C non documentés non-documentés du début des années 90.

Est-ce que cela inclut le code de la lrzsz package? C'est toujours largement disponible sur la plupart des distributions Linux (et étonnamment pratiques pour transmettre des fichiers sur une connexion SSH établie).

Il existe un certain nombre d'autres implémentations, y compris Plusieurs logiciels indiqués sur freecode , y compris qodem , SyncTerm , MBSE , et d'autres. Je crois que le SyncTerm La mise en œuvre est écrite comme une bibliothèque pouvant être raisonnable facile à utiliser depuis votre propre code (mais je ne suis pas certain).

Vous pouvez trouver un code supplémentaire si vous fouillez des collections plus anciennes de Logiciel MS-DOS.

Answer 2

Je ne peux pas vous blâmer. Le manuel d'utilisation n'est pas organisé de manière conviviale

sont les octets de rembourrage (0x2a) arbitraires?

Non, de la page 14,15:

Un en-tête binaire commence par la séquence ZPAD, ZDLE, ZBIN.

Un en-tête Hex commence par la séquence ZPAD, ZPAD, ZDLE, ZHEX.

.

La spécification ne mentionne pas la [CR] [LF] [XON] à la fin, mais l'article MSDN le fait. Pourquoi est-ce là?

Page 15

* * ZDLE B de type F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CR LF XON . Pourquoi le [LF] a-t-il un jeu de bit 0x80?

Pas sûr. De Tera Terme, j'ai reçu les deux caractères de contrôle xored avec 0x80 (8D 8A 11)

Nous avons notre premier cadre mystérieux ZCRCW: [18 6B]. Combien de temps dure cette image? Où se trouve les données CRC, et est-ce CRC16 ou CRC32? Il n'est pas défini nulle part dans la spécification.

Le zcrcw n'est pas un en-tête ou un type de cadre, c'est plus comme un pied de page qui raconte au récepteur à quoi s'attendre ensuite. Dans ce cas, il s'agit du pied de page du sous-groupe de données contenant le nom du fichier. Il s'agira d'une somme de contrôle 32 bits car vous utilisez une en-tête binaire de type "C".

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

  .

  Ensuite, nous avons une image avec un type non défini: [18 50 D3 0F F1 11]. Est-ce un cadre séparé ou fait-il partie de zcrcw?

  C'est le CRC pour le sous-vaseau de données ZCRCW. Il est 5 octets car le premier est 0x10, un caractère de contrôle qui doit être échappé à ZDLE. Je ne suis pas sûr de ce que 0x11 est.

  et il n'y a pas de [xon].

  Xon est juste pour les en-têtes hexagonaux. Vous ne l'utilisez pas pour un en-tête binaire.

  • ZDLE A TYPE F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 . Alors, comment puis-je transmettre un octet de charge utile qui correspond à la valeur de [ZDLE]?

    18 58 (AKA ZDLEE)

    18 68 05 DE 02 18 D0

    C'est le pied de page du sous-châssis de données. Les 5 octets suivants sont le CRC (dernier octet est codé ZDLE)