Description technique du protocole BBT version 2.2 -------------------------------------------------- a) D‚tection de r‚ception ou d'envoi d'un fichier b) Le paquet d'entˆte c) La r‚ponse au paquet d'entˆte d) Envoi d'un paquet de donn‚es e) R‚ponse … un paquet de donn‚es f) Resynchronisation dans un fichier g) Fin de transfert h) Acquittement de fin de transfert i) Envoi de fichier au serveur (Upload) APPENDIX A) Description technique sur l'encodage/d‚codage de paquet en version 1.3 APPENDIX B) Calcul du CRC utilis‚ par BBT. (CRC-16 du CCITT) Description technique du protocole BBT au niveau 2.2 Par convention le caractŠre "\r" dans les textes suivants, repr‚sente le caractŠre ASCII dont la valeur en hexad‚cimal est 0x0d. a) D‚tection de r‚ception ou d'envoi d'un fichier Une d‚tection automatique de la r‚ception ou de la demande d'envoi d'un fichier est r‚alisable par la r‚ception d'une chaŒne de caractŠres. "\r@@!@@\r" pour la r‚ception d'un fichier. "\r!!@!!\r" pour la demande d'envoi d'un fichier. b) Le paquet d'entˆte: ENVOI de : "\r@@!@@\rSSSSSS FILENAME DDDDDDDD PPP VV C M XXXX\r" SSSSSS: Taille du fichier en d‚cimal (c'est un long en C) au niveau ASCII la longueur de la taille n'est pas constante. FILENAME: Nom du fichier en ascii (sans espace), il est pr‚f‚rable de ne pas mettre de chemin d'accŠs dans ce champ. En effet certaines impl‚mentations de BBT pourraient ne pas du tout appr‚cier. Je vous conseille aussi de faire attention … la taille des fichiers envoy‚s ! Sous MS-DOS le maximum est "XXXXXXXX.EXT" 8 caractŠres pour le nom et 3 caractŠres pour l'extension. Vous pouvez toutefois ˆtre un peu plus large... Le standard POSIX normalise la taille des noms de fichiers … 14 caractŠres. DDDDDDDD: Date et heure du fichier. Cette date est un 'long' en hexad‚cimal. Ce 'long' repr‚sente le nombre de secondes ‚coul‚es depuis le 01/Jan/70. Ceci est une convention sous Unix. PPP: Permission d'accŠs au fichier (3 digits d‚cimal). C'est un nombre constitu‚ par un OU logique (OR) entre les ‚l‚ments suivants: 400 Lecture par le propri‚taire 200 Ecriture par le propri‚taire 100 Ex‚cution par le propri‚taire 040 Lecture par le groupe 020 Ecriture par le groupe 010 Ex‚cution par le groupe 004 Lecture par les autres 002 Ecriture par les autres 001 Ex‚cution par les autres VV: Num‚ro de version de BBT. Ceci permet de faire tourner toutes les versions de BBT entre elles, mˆme si elles ont des niveaux d'impl‚mentation complŠtement diff‚rents. Ce num‚ro est sur deux digits en hexad‚cimal. Num‚ro des valeurs de version envoy‚s par BBT en fonction des impl‚mentations de BBT: BBT V1.0 : version originale BBT V1.1 : version date + perm BBT V1.2 : version slide window BBT V1.3 : version CRC BBT V1.4 : version (source ‚clat‚) et de nouvelles opts BBT V1.4b: version avec un nouvel encodage BBT V1.5 : version o— le nouveau CRC en asm est valid‚ BBT V1.6 : version (Alpha Tourne sous Qterm) BBT V1.7 : version Crash Recovery + Pack BBT V1.8 : 1.7 + jolie pr‚sentation sous MS-DOS BBT V2.1 : Contr“le de validit‚ d'acquittement BBT V2.2 : Mode 8bits & CRC header BBT V2.3 : CRC sur reply header et synchro VV = 0 = 1.0, 1.1, 1.2 VV = 1 = 1.3 VV = 2 = 1.4, 1.5, 1.6 VV = 3 = 1.7, 1.8 VV = 4 = 2.1 VV = 5 = 2.2 VV = 6 = 2.3 C: Ce parametre n'est plus utilise dans la version 2.2 M: Mode 8 bits (on/off) XXXX: CRC-16 sur l'entete Sur certaines trŠs vieilles versions, les ‚l‚ments tels que Date Permission et Version peuvent ne pas ˆtre pr‚sents dans le paquet d'entˆte. c) La r‚ponse au paquet d'entˆte: ENVOI de : "!VV SSSSSSSSS PPPP CCCC\r" VV: Num‚ro de version du BBT qui va recevoir le fichier. Ceci permet entre autres au serveur de se mettre au niveau du r‚cepteur. Ce num‚ro est sur deux digits en hexa. (Il peut ne pas ˆtre pr‚sent sur d'anciennes versions) SSSSSSSSS: Si le r‚cepteur a d‚j… un fichier du nom de celui que l'on cherche … lui envoyer, ce dernier considŠre qu'il y a eu une interruption lors d'un pr‚c‚dent transfert et il renvoit la taille du fichier existant en local. Ceci permet au serveur de reprendre l'envoi du fichier aprŠs ce qui a d‚j… ‚t‚ re‡u. Si SSSSSSSSS n'existe pas ou est ‚gale … z‚ro dans ce cas le transfert n'est pas une reprise sur un fichier qui n'a pas ‚t‚ transf‚r‚ complŠtement. PPPP: Taille maxi des paquets support‚e par la version de BBT qui re‡oit. CCCC: CRC-16 (4 digits en hexa) Si CCCC est mauvais abandonne immediatement le telechargement par l'envoi d'un "#BREAK#\r". d) Envoi d'un paquet de donn‚es: ENVOI de : "LLLLDDDDD.....DDDDCCCC\r" LLLL: Est la longueur en d‚cimal si VV<5 ou en hexa avant encodage du paquet qui va ˆtre re‡u. Elle ne doit JAMAIS ˆtre sup‚rieure … 3072 octets. (Lors de l'envoi du dernier paquet de donn‚es la plupart des impl‚mentations de BBT donnent une longueur inexacte. Le calcul de la longueur doit donc s'effectuer de la maniŠre suivante afin d'‚viter tout problŠme en fin de fichier: si ( position_dans_le_fichier_re‡u + taille_du_paquet_re‡u > taille_du_fichier_…_recevoir ) alors taille_du_paquet_re‡u = ( taille_du_fichier_…_recevoir - position_dans_le_fichier_re‡u ) DDDD: Ce sont les donn‚es par elles-mˆmes encod‚es en 7 bits par l'un des deux algorithmes int‚gr‚s … BBT. Dans le cas o— la version est < … la 1.5 l'encodage est celui utilis‚ par uuencode/uudecode des systŠmes d'exploitation unix. (On encode 3 octets 8 bits en 4 octets 7 bits) Dans le cas o— la version est > a la 1.4 l'encodage est propre … BBT ou l'on encode 4 octets 8 bits en 5 octets 7 bits) CCCC: C'est un CRC-16 CCITT ou un Checksum sur 4 digits en hexa. Dans le cas o— la version est < a la 1.3, CCCC est un checksum sinon c'est un CRC-16. (Ce type de CRC est trŠs r‚pandu dans de nombreux protocoles, xmodem, ymodem, zmodem, etc.) e) R‚ponse … un paquet de donn‚es: Dans le cas o— le paquet a ‚t‚ bien re‡u : ENVOI de : "!H\r" Dans le cas o— le paquet n'a pas ‚t‚ re‡u correctement : ENVOI de : "?H\r" Dans le cas o— 8 acquittements cons‚cutifs seraient mauvais le programme doit arrˆter le transfert. f) Resynchronisation dans un fichier Dans le cas de la version 2.1 ou ult‚rieure, si l'acquittement d'un paquet de donn‚es n'est pas conforme … l'une des r‚ponses d‚finies pr‚c‚demment le serveur doit envoyer en version 2.1 ou 2.2 "+SSSSSSSSS\r" … la place du paquet de donn‚es suivant et en version 2.3 ou > "+SSSSSSSSS CCCC\r". SSSSSSSSS: repr‚sente une position de resynchronisation dans le fichier … envoyer. (Ceci permet au protocole serveur et servi de repartir sur une position identique dans un transfert) CCCC: CRC-16, si le CRC le mauvais le programme doit provoquer une autre demande de synchronisation, ceci peut etre realise par un acquitement qui n'est ni "!H\r" ou "?H\r". Utilise "/H\r" semble un bon choix. g) Fin de transfert: Pour toutes les versions de BBT, le transfert se finit toujours de la maniŠre suivante : ENVOI de : "@@!@@\r" h) Acquittement de fin de transfert: Pour toutes les versions de BBT, l'acquittement de fin de transfert se fait toujours de la maniŠre suivante : ENVOI de : "#" dans le cas o— le transfert se finit tout-…-fait normalement. ENVOI de : "#BREAK#\r" dans le cas o— le transfert se finit pour cause anormale. ex: Demande d'abandon de l'utilisateur, trop de r‚-‚missions cons‚cutives, etc. i) Envoi (Upload) de fichier: Dans le cas d'upload de fichier vers un serveur. Le protocole du serveur ‚mettra la chaŒne "\r!!@!!\r" puis passera en attente de r‚ception du paquet d'entˆte du BBT qui envoie. A noter qu'il n'y a pas de temps de r‚action … respecter pour l'envoi du paquet d'entˆte. La d‚marche … suivre peut donc ˆtre la suivante lors d'un envoi: - R‚ception de "\r!!@!!\r" - Retournement du PAVI (Point d'AccŠs VId‚otex) ou modem en cas de RTC (R‚seau T‚l‚phonique Commut‚) r‚alis‚ par le logiciel. Si l'on se trouve en 3614/3615/etc. Il est important de ne jamais avoir une taille de paquet > … 1024 octets sous peine de lib‚ration du PAVI pour cause de saturation. - Demande du nom du fichier … envoyer. - Envoi du paquet d'entˆte. Voir APPENDIX C de a) … g) dans la documentation du protocole. APPENDIX A) Description technique sur l'encodage/d‚codage de paquet en version 1.3 C'est le mˆme principe que pour les programmes uuencode/uudecode (utilitaire unix) Le principe est de coder 3 octets 8 bits en 4 octets 7 bits d'ascii visualisables. D‚codage d'un PAQUET 7 bits de BBT: Les paquets de donn‚es ont le format suivant : TAILLE_DU_PAQUET + DONNEES_EN_7_BITS + (CRC ou CHECKSUM) Comment d‚coder un paquet ? - Voici un exemple de d‚codage de 4 octets de donn‚es 7 bits re‡us. Phase 1: l'on retire 32 d‚cimal ou 0x20 hexad‚cimal … chacun des 4 octets recus. Phase 2: l'on obtient 4 octets dans lesquels le codage des donn‚es utiles est explicit‚ ci-dessous. soit 'a' le 1er octet 8 bits … d‚coder, soit 'b' le 2Šme octet 8 bits … d‚coder, soit 'c' le 3Šme octet 8 bits … d‚coder. 12345678 12345678 12345678 12345678 Octet en 7 Bits 00aaaaaa 00aabbbb 00bbbbcc 00cccccc Phase 3: Passer au format 3 octets.8 bits 12345678 12345678 12345678 Octet en 8 Bits aaaaaaaa bbbbbbbb cccccccc En langage C cela produit le code suivant: recu1 -= ' '; recu2 -= ' '; recu3 -= ' '; recu4 -= ' '; r8_1 = (recu1 << 2) | ((recu2 >> 4) & 0x3); r8_2 = (recu2 << 4) | ((recu3 >> 2) & 0xf); r8_3 = (recu2 << 6) | recu4; La mˆme chose en langage math‚matique ‡a donne quelque chose comme: - On retire 32 aux 4 octets re‡us, - Le 1er octet 8 bits est ‚gal au (1er octet re‡u * par 4) OU (logique) le ( (2Šme octet re‡u / par 16) ET (AND) 3 ) - Le 2Šme octet 8 bits est ‚gal au (2Šme octet re‡u * par 16) OU (logique) le ( (3Šme octet re‡u / par 4) ET (AND) 15 ) - Le 3Šme octet 8 bits est ‚gal au (3Šme octet re‡u * par 64) OU (logique) le ( 4Šme octet re‡u ) APPENDIX B) Calcul du CRC utilis‚ par BBT. (CRC-16 du CCITT) Suite … de nombreuses demandes, voici un exemple de calcul de CRC-16 CCITT. BBT exploite en effet ce CRC qui est utilis‚ par bon nombre de protocoles comme par exemple: Xmodem, Ymodem, Zmodem... Le polyn“me utilis‚ pour le calcul est le suivant : (X16 + X12 + X5 + X0) En pratique en langage C le calcule de CRC est effectu‚ par une fonction comme celle qui suit et qui provient de la documentation sur du protocole Ymodem. int calcrc(ptr, count) char *ptr; int count; { int crc, i; crc = 0; while( --count >= 0 ) { crc = crc ^ (int)*ptr++ << 8; for (i = 0; i < 8; ++i) if (crc & 0x8000) crc = crc << 1 ^ 0x1021; else crc = crc << 1; } return (crc & 0xFFFF); }