****************************************************************************** * Description officielle complŠte des ‚changes sur l'Inter-RTC v1.0 * * Protocole mis au point par Olivier Marcoux (Wizard de Pulsar RTC) * ****************************************************************************** Pr‚sentation G‚n‚rale ------------------------------------------------------------------------------ Cette documentation contient tout ce qu'il faut savoir pour comprendre comment fonctionnent le r‚seau Inter-RTC et les interactions entre les serveurs qui le constituent Vous y trouverez la d‚finition complete de la version 1.0 du protocole utilis‚ sur le r‚seau : le protocole InterRTC v1.0 Le but de cette documentation est de permettre au plus grand nombre de serveur de pouvoir se r‚lier au r‚seau en adaptant leur logiciel-serveur. Le r‚seau Inter-RTC a ‚t‚ mis en place afin de permettre l'‚change de donn‚es entre plusieurs serveurs. Il a ‚t‚ sp‚cifiquement ‚tudi‚ pour prendre en compte les sp‚cificit‚s des serveurs RTC mais peut ‚galement ˆtre adapt‚ pour des serveurs BBS. Rappelons au passage qu'un serveur RTC est un serveur convivial proposant un systŠme de messagerie et auquel on peut acc‚der avec un Minitel. Les donn‚es qui transitent entre les serveurs du r‚seau sont principalement des messages textes … destinataire unique (que l'on appelera des E-mail, comme sur Internet) ou des messages publics dans le cadre d'un forum de discussion sur un thŠme donn‚ (que l'on appelera des Newsgroups, comme sur Internet) mais le protocole n'est pas restrictif et permet de pouvoir faire transiter tout type de donn‚es. La base du protocole r‚side dans l'‚tablissement de maniŠre assez reguliŠre d'une connexion entre les serveurs. (Par exemple, tous les soirs, un serveur en appelle un autre, et ces deux serveurs se transmettent des informations) Le protocole permet ‚galement une gestion dynamique de ces liaisons, c'est … dire qu'un serveur n'est pas contraint quant au serveur auquel il doit se relier r‚gulierement et peut facilement changer, l'acheminement des messages n'en sera pas affect‚. 1. D‚roulement d'une connexion entre 2 serveurs ------------------------------------------------------------------------------ Nous allons prendre le cas d'un serveur AAA et d'un serveur BBB Les sysops (responsables) de ces serveurs doivent tout d'abord convenir d'une date et heure … laquelle leurs serveurs vont se relier de maniŠre reguliŠre. Ce choix sera sp‚cifique … la liaison entre les 2 serveurs. Imaginons par exemple que les sysops ait choisi la convention suivante: Un jour sur deux, le serveur AAA appelle le serveur BBB … 05h05 Le jour suivant, le serveur BBB appelle le serveur AAA … 05h05 Dans ce cas, voici le d‚roulement des op‚rations lorsque AAA appelle BBB: - … 05h00, le serveur AAA pr‚pare le paquet d'information qu'il va transmettre au serveur BBB (c'est ce que l'on appelera le packet), et le serveur BBB fait de mˆme en pr‚parant le packet pour le serveur AAA - … 05h05, le serveur AAA appelle et se connecte au serveur BBB - une fois connect‚, le serveur AAA attend environ 5 secondes (pour laisser passer les eventuels parasites de debut de connexion) - le serveur AAA envoie alors une chaine de caractŠres sp‚cifique au serveur BBB lui faisant reconnaitre que c'est un serveur qui l'appelle et qu'il s'agit du serveur AAA (cette chaine pourra ˆtre convenue entre les 2 sysops) Par exemple, pour les serveurs sous AutoServ, ce sera quelquechose comme [Annulation] I R T C [RC] A A A [RC] - le serveur BBB ayant reconnu cette chaine doit alors envoyer dŠs que possible la chaine [Cls] [RC] ! ! @ ! ! [RC] (code ascii de [Cls]: $0C) - dŠs la reception de [RC] ! ! @ ! ! [RC], le serveur AAA doit envoyer le packet avec le protocole BBT (ou un autre protocole accept‚ par les logiciels serveurs et convenus entre les 2 sysops) - lorsque le transfert est termin‚, le serveur BBB envoie le code de retournement des minitels (si la connexion est effectu‚e entre 2 minitels) et le serveur AAA attend 5 secondes (pour laisser passer les eventuels parasites d– au retournement) - le serveur AAA envoie alors [Cls] [RC] ! ! @ ! ! [RC] - … nouveau, dŠs la reception de [RC] ! ! @ ! ! [RC] le serveur BBB envoie son packet avec le mˆme protocole de transfert que pr‚c‚demment. - lorsque le transfert est termin‚, le serveur AAA attend 5 secondes puis se deconnecte. Remarques: -les delais d'attente peuvent ˆtre r‚duit pour les connexions de bonne qualit‚ ou … grande vitesse -si l'un des 2 transferts s'est mal pass‚ et s'est interrompu, les ‚tapes d‚critent si dessus sont tout de mˆme valable mais l'envoyeur du packet mal transmis doit faire le menage dans ses fichiers et garder les donn‚es qui n'ont pas pu ˆtre transmis pour la prochaine connexion. Le receveur du packet doit bien sur ignorer ce qu'il a pu recevoir -si le transfert s'est bien pass‚, le receveur peut le traiter et l'envoyeur peut mettre a jour ses fichiers et ses tables pour indiquer quels messages ont ‚t‚ transmis.. 2. Format du packet ------------------------------------------------------------------------------ Le packet transf‚r‚ entre 2 serveurs est une archive ZIP dont le nom peut-ˆtre quelconque (on preferera un nom identifiant le serveur envoyeur) Cette archive ZIP contient deux fichiers: CONTROL.DAT et MESSAGES.DAT Nous prendrons dans la suite le cas ou il s'agit du packet transf‚r‚ de AAA vers BBB 2.1 Format du fichier CONTROL.DAT ------------------------------------------------------------------------------ Le fichier CONTROL.DAT du packet est un fichier texte qui donne des informations sur le serveur appelant, sur le gestionnaire InterRTC (la door) utilis‚ et sur le paquet transmis. Il est compos‚ d'une suite d'‚galit‚s, le membre gauche indiquant la nature et le membre droite indiquant la valeur Remarque: Quelque soit le systŠme de fichier employ‚ par AAA ou BBB, la fin d'une ligne dans ce fichier texte sera cod‚ par le caractŠre [RC] (de code ASCII $0D) contrairement au [RC] [LF] du DOS sur PC Voici les lignes qu'on pourra trouver dans le fichier: DoorVersion= represente les formats de packet que la door de AAA est capable de generer. LA COMPATIBILITE DOIT ETRE ASSUREE AVEC LES VERSIONS INFERIEURES ex: DoorVersion=3 indique que AAA peut generer des packets de format 1, 2 ou 3 (remarque: pour l'instant il n'y a qu'une seule version du format des packets le format 1, qui est d‚crite dans cette documentation) PktVersion= represente le format du packet transmit c'est … ce nombre que BBB devra se r‚ferer pour savoir quel version du protocole employer pour decoder le packet transmit (ce nombre est donc forcement inferieur ou egal … DoorVersion...) ex: PktVersion=1 PktDate=, est de la forme JJ/MM/AAAA est de la forme HH:MM:SS ils indiquent la date & heure de creation du packet ex: PktDate=19/06/1995,05:00:14 ServerID= donne l'identificateur du serveur appelant l'identificateur est unique pour UN serveur sur tout le reseau, il est compos‚ uniquement de caractŠre ASCII compris entre 32 et 127 et ne doit pas commencer ni finir par un ou des espaces ex: ServerID=AAA Remarque: - les 2 premiŠres ‚galit‚s doivent toujours apparaitre en premier dans le fichier. Les autres ‚galit‚s peuvent apparaitrent dans n'importe quel ordre - toute autre type d'‚galit‚ rencontr‚e sera ignor‚ 2.2 Format du fichier MESSAGES.DAT ------------------------------------------------------------------------------ Le fichier MESSAGES.DAT est un fichier binaire contenant tous les messages en partance pour les autres serveurs (bal, forum, request) chaque message est mis l'un apres l'autre sous la forme: indique la nature du message: (2 bytes) Type Nature Propagation 0..63 E-mail Transite jusqu'au serveur destinataire 64..127 Request Transite jusqu'au serveur destinataire 128..191 Short Request Transmit … un serveur-lien donn‚ 192..255 General Request Transmit … tous les serveurs 256..65535 Conference Msg Transmit … tous les serveurs abonn‚s indique la taille en octets de la zone de (2 bytes) reserv‚ (doit valoir 0 pour l'instant!) (2 bytes) est constitu‚ d'une succession de donn‚es dependant de la nature du message. Chaque donn‚es commence par 1 byte indiquant la longueur de la donn‚e suivi de la donn‚e elle-meme. (comme le format de stockage des chaines en Pascal) La derniere donn‚e de l'ensemble n'est pas introduite par 1 byte comme les precedentes, sa taille est deduit … partir de la difference entre et la taille totale des donn‚es deja lues (la derniere donn‚e peut donc d‚passer 255 caractŠres) (g‚n‚ralement cette derniere donn‚e contient un texte avec des retour … la ligne mais elle peut contenir n'importe quel texte ou fichier) ÉÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º type ³ description ³ format de donn‚es ³ action si reception º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º 0..63 ³ E-mail et ³³ù si on est le serveur º º ³ extensions ³ ³ destination, faire ce º º ³ futures ³eventuellement d'autres ³ qu'il faut (selon le º º ³ de l'E-mail ³donn‚es selon le type ³ type d'E-mail) º º ³ ³d'E-mail ³ù sinon, "faire passer"º º ³ ³ ³ en mettant le message º º ³ ³ ³ dans la queue d'envoi º º ³ ³ ³ du bon lien (donn‚ parº º dont: ³ ³ ³ SERVERS.LNK) º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 0 ³ Email standard ³³ù si on est le serveur º º ³ ³ ³ destination, poster leº º ³ ³ ³ message en BAL (even- º º ³ ³ ³tuellement via POSTMSG)º º ³ ³ ³ù sinon, faire passer º º ³ ³ ³ º º ³ ³ ³ º º ³ ³puis le texte du message ³ º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º 64..127³ Request ³ ³ù si on est le serveur º º ³(format donn‚es ³ ³ destination, renvoyer º º ³ non d‚finitif) ³eventuellement d'autres ³ … l'origine la reponseº º ³ ³donn‚es selon le type ³ au request (cf type) º º ³ ³de request ³ù sinon, faire passer º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º128..191³Short Request ³les donn‚es dependent du ³Faire l'action indiqu‚eº º dont: ³ ³type de request ³ par le type º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 128 ³D‚but abonnement³num‚ro de conf‚rence ³Marquer dans FORUMS.LNKº º ³ ³ (sur 2 bytes) ³ que le lien s'abonne º º ³ ³ ³ … cette conference º º ³ ³ ³(on devient alors son º º ³ ³ ³ fournisseur) º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 129 ³Fin d'abonnement³num‚ro de conf‚rence ³Marquer dans FORUMS.LNKº º ³ ³ (sur 2 bytes) ³ que le lien resilie º º ³ ³ ³ cette conference º º ³ ³ ³(on ne fourni plus) º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º192..255³General Request ³les donn‚es dependent du ³Faire l'action indiqu‚eº º ³ ³type de request ³ par le type et les º º ³ ³ ³ donn‚es º º ³ ³ ³Et remettre le message º º ³ ³ ³ dans la queue d'envoi º º dont: ³ ³ ³ vers les autres liens º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 192 ³Message … tous ³ ³Poster le message dans º º ³ les SysOp ³ ³ la bal du SysOp º º ³ ³ ³ º º ³ ³ ³ º º ³ ³ ³ º º ³ ³puis le texte du message ³ º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 193 ³Message … tous ³ ³Poster le message dans º º ³ les connect‚s ³ ³ toutes les bals du º º ³ ³ ³ serveur º º ³ ³ ³ º º ³ ³ ³ º º ³ ³puis le texte du message ³ º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 200 ³Nouveau lien sur³³Ajouter les nouveaux º º ³ le reseau ³³ serveurs reli‚s dans º º ³ ³³ SERVERS.LST, indiquer º º ³ ³³ que ce lien est leur º º ³ ³³ chemin de destination º º ³ ³ etc... ³ dans SERVERS.LNK º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 201 ³Lien d‚truit sur³ ³Retirer les serveurs º º ³ le r‚seau ³ ³ perdus par ce lien de º º ³ ³ ³ SERVERS.LST ainsi que º º ³ ³ etc... ³ de SERVERS.LNK º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º 202 ³Nouveau forum ³num‚ro de conf‚rence ³Marquer dans FORUMS.LNKº º ³ sur le r‚seau ³ (sur 2 bytes) ³ que si on s'abonne … º º ³ ³ ³ cette conference c'estº º ³ ³ ³ ce lien qui fournira º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º >= 256 ³Message dans une³00 (sur 1 byte) ³Poster ce message dans º º ³ conf‚rence ³ ³ le forum correspondantº º ³ ³ ³Et remettre le message º º ³ ³ ³ dans la queue d'envoi º º ³ ³ ³ vers les autres liens º º ³ ³ ³ abonn‚s … ce forum º º ³ ³puis le texte du message ³ º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º >= 256 ³Le fournisseur ³01 (sur 1 byte) ³Le fournisseur resilie º º ³ ne va plus nous³ ³ la conf‚rence et ne vaº º ³ fournir la ³ ³ donc plus pouvoir nousº º ³ conf‚rence ³(le serveur conseill‚ est³ la fournir (ni aux º º ³ ³ le nom du serveur auprŠs³ autres liens abonn‚s º º ³ ³ duquel notre fournisseur³ dont nous sommes le º º ³ ³ ‚tait lui-mˆme fourni) ³ fournisseur) º ÈÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Remarques: ù les dates doivent ˆtre de la forme: JJ/MM/AAAA ù les heures doivent ˆtre de la forme: HH:MM:SS ù dans les messages, le passage … la ligne est indiqu‚ par RC (0D) quelquesoit le systeme d'exploitation employ‚ -- 3. Fichiers g‚r‚s par le Gestionnaire Inter-RTC pour PC Le Gestionnaire Inter-RTC pour PC (INTERRTC.EXE) utilise des fichiers qui doivent ˆtre plac‚ dans un sous-r‚pertoire INTERRTC (dans lequel INTERRTC.EXE ne doit PAS ˆtre plac‚) Si vous developpez votre propre Gestionnaire Inter-RTC, vous pouvez vous baser sur la maniere de fonctionner de celui-ci. 3.1 Fichier INTERRTC\INFO.SRV Ce fichier donne au gestionnaire les informations sur le serveur dont il s'occupe. Le format du fichier est similaire … celui du CONTROL.DAT du ZIP et certaines de ces donn‚es sont utilis‚e pour le g‚n‚rer. Dans des futures versions du format, ces donn‚es risquent d'ˆtre exigibles via des requests. ServerID= donne l'identificateur du serveur appelant l'identificateur est unique pour UN serveur sur tout le reseau, il est compos‚ uniquement de lettres majuscules ex: ServerID=AZIMUT SysOp= indique le pseudo du sysop du serveur appelant sous lequel il peut etre joint par un message en BAL ex: SysOp=BENOUILLE Name= indique le nom en langage clair du serveur appelant ex: Name=Azimut Location= indique en langage clair la position geographique du serveur ex: Location=Paris, France Dial= ... indique les numeros auxquels on peut se connecter au serveur appelant indique la liaison maximale possible sur le qui suit, au format ITU (ex-CCITT) chaque et doivent etre s‚par‚ entre eux par un espace ne doit pas contenir d'espace et doit etre utilisable par la fonction ATDT d'un modem hayes ex: Dial=v23 42-40-11-11 indique que le serveur peut etre appel‚ au 42-40-11-11 avec un minitel ou un modem acceptant le v23 (1200/75) Dial=v22bis 45-45-45-45 v34+ 46-46-46-46 indique que le serveur peut etre appel‚ au 45-45-45-45 avec un modem acceptant le v22bis (2400bps) ou bien au 46-46-46-46 avec un modem acceptant le v34+ (33600bps) Soft= indique le nom et la version en langage clair du logiciel serveur du serveur appelant ex: Soft=AutoServ v1.3 3.2 Fichier INTERRTC\LINKS.LST Ce fichier texte contient la definition des serveurs-liens Pour chaque lien, il y a 3 lignes: -l'ID du serveur-lien -sa DoorVersion (version max du format des packets accept‚e) -le num‚ro d'appel pr‚c‚d‚ du type de liaison 3.3 Fichier INTERRTC\SERVERS.LST Ce fichier texte contient la liste de tous les serveurs sur le reseau Chaque ligne represente un ID de serveur. Le votre ne doit pas s'y trouver 3.4 Fichier INTERRTC\SERVERS.LNK Ce fichier binaire contient pour chaque serveur du reseau le num‚ro du lien qui permet de l'atteindre … partir de votre serveur. A chaque ligne de SERVERS.LST correspond un word (2 bytes) de SERVERS.LNK Imaginons la configuration suivante, les fichiers d'AZIMUT seront alors: LINKS.LST ³ SERVERS.LST ³ SERVERS.LNK P U L S A R ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ / ³ \ PULSAR ³ PULSAR ³ 0001 AZIMUT OCTOBER CASTLE 1 ³ CASTLE ³ 0001 (via PULSAR) ³ ³ v43 45-45-65-33 ³ GRAAL ³ 0002 GRAAL STACC GRAAL ³ OCTOBER ³ 0001 (via PULSAR) 1 ³ STACC ³ 0001 (via PULSAR) v23 ??-??-??-?? ³ ³ 3.5 Fichier INTERRTC\FORUMS.LNK Pour chaque forum du reseau un word (2 bytes) donne des informations sur la propagation de celui-ci. (le 1er word du fichier correspond au forum 256) Le Lo-Byte indique le numero du lien qui est le fournisseur du forum Le Hi-Byte est un champ de flags, un flag … 1 indiquant que le lien correspondant est abonn‚ (ou fournisseur) du forum Les bits d'un word allant de 0 … 15, le bit nø8 du word correspond au bit nø0 du Hi-Byte de ce word et correspond au lien nø1. Le bit nø9 correspond au lien nø2, etc... 3.6 Fichier INTERRTC\MESSAGES.DAT Comme son nom l'indique, la structure de ce fichier binaire est identique … celle du fichier MESSAGES.DAT du ZIP La seule difference reside dans le fait qu'ici, le champ est utilis‚ Il s'agit d'un word dont on distingue le Lo-Byte et le Hi-Byte qui joue des r“les diff‚rents. On distinguera, dans le tableau suivant, 4 ‚tapes de l'etat du champ des messages du fichier INTERRTC\MESSAGES.DAT: -ADD lorsque le message est ins‚r‚ (ajout‚) au fichier INTERRTC\MESSAGES.DAT -MAKE aprŠs que le message ait ‚t‚ trait‚ par la pr‚paration d'un packet ZIP -NAK lorsque le transfert du packet s'est mal d‚roul‚ ou qu'il n'y a meme pas eu de connexion entre les serveurs -ACK lorsque le transfert du packet s'est bien d‚roul‚ ÉÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º type ³ fonctions du Lo-Byte ³ fonctions du Hi-Byte º ÌÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º 0..127³ ADD: vaut 0 ³ vaut toujours 0 º º ³ MAKE: vaut le num‚ro du bon ³ º º ³ lien acheminant au serveur du ³ º º ³ destinataire ³ º º ³ NAK: est remis … 0 ³ º º ³ ACK: le message est retir‚ du fichier INTERRTC\MESSAGES.DAT º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º128..191³ ADD: vaut le num‚ro du lien ³ ADD: vaut 0 º º ³ auquel le short request est ³ º º ³ destin‚ ³ º º ³ MAKE: ne change pas ³ MAKE: vaut comme le Lo-Byte º º ³ NAK: ne change pas ³ NAK: est remis … 0 º º ³ ACK: le message est retir‚ du fichier INTERRTC\MESSAGES.DAT º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º192..255³ champ de bits repr‚sentant les ³ champ de bits repr‚sentant les º º ³ liens pour lesquels on pr‚pare ³ liens qui ont recus le message º º ³ l'envoi du message ³ (… 1 = envoy‚) º º ³ ADD: vaut 0 ³ ADD: vaut 0 si on est l'origine º º ³ ³ du general request. sinon le º º ³ ³ bit correspondant au lien qui º º ³ ³ nous l'a transmis est mis … 1 º º ³ MAKE: le bit correspondant au ³ MAKE: ne change pas º º ³ lien pr‚par‚ est mis … 1 ³ º º ³ NAK: le bit est remis … 0 ³ NAK: ne change pas º º ³ ACK: le bit est remis … 0 ³ ACK: le bit correspondant au º º ³ ³ lien envoy‚ est mis … 1 º º ³ Si tous les liens ont recu le message, il est retir‚ du fichier º ÇÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º >= 256 ³ identique … 192..255 sauf qu'on ne pr‚pare/envoi le packet que º º ³ pour les liens abonn‚s (tel qu'indiqu‚ par les Hi-Byte du fichier º º ³ INTERRTC\FORUMS.LNK). Le message est retir‚ du fichier lorsque º º ³ tous les liens abonn‚s ont recu le message º ÈÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ -- 4. Fichiers g‚r‚s par les couches de compatibilit‚ logicielles (paragraphe decrivant les specificit‚s du Gestionnaire InterRTC pour PC qui peut interagir avec differents logiciels serveurs grƒce … sa couche de compatibilit‚) Actuellement 2 couches de compatibilit‚ existent pour le Gestionnaire PC: -pour le logiciel serveur AutoServ -pour le logiciel serveur Onyx -- 5. Glossaire serveur-lien de A....serveur directement reli‚ au serveur A (c'est … dire qu'il est appel‚ reguliŠrement par A ou que A l'appelle) Byte: un entier de 0 … 255 Word: un valeur entiere de 0 … 65535 qui est stock‚e sur 2 bytes Lo-Byte: dans le Word 1234h le Lo-Byte vaut 34h Hi-Byte: dans le Word 1234h le Hi-Byte vaut 12h dans MESSAGES.DAT, les Word sont stock‚s sous la forme: Lo-Byte PUIS Hi-Byte 6. Contacts Pour me contacter, connectez-vous sur Pulsar RTC (01-45-45-65-33) et ‚crivez en bal Wizard Ou par E-Mail: wizard@pulsar.eu.org