summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorhaller2005-12-28 18:50:36 +0000
committerhaller2005-12-28 18:50:36 +0000
commit6273e5acb760a2f0b3ca6d2abd3da2ddf25cb800 (patch)
tree4144c9e755d15386d2d1f86b58a00bad7ef2c483
parent81064cd2b6fbcc7a565a67435ebb15c8c36a3060 (diff)
* Ajout d'une doc sur la tête des messages réseau du simulotron
-rw-r--r--i/simulotron/doc/message.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/i/simulotron/doc/message.txt b/i/simulotron/doc/message.txt
new file mode 100644
index 0000000..04b6cfb
--- /dev/null
+++ b/i/simulotron/doc/message.txt
@@ -0,0 +1,59 @@
+*Title: Les messages réseau
+*Author: Nicolas Haller
+
+*TOC
+
+* Introduction
+
+Le simulotron est un ensemble de programme et de code, des modules, indépendants entre eux. Pour l'instant, l'IPC est basé sur des sockets TCP/IP se qui permet pourquoi pas de mettre l'asserv à Lille, la PC104 en Chine, le Hub à Quantico et le moteur physique chez Jean Klein (cela dit, je pense pas que ca arrive souvent).
+
+Mais pour que ce beau petit monde puisse communiquer, il est necessaire d'instaurer un protocole de communication.
+
+* Le protocole qui en tient, des couches
+
+Pour l'instant, la com se fait en 4 couches avant d'arriver sur le résal
+
+ !----------------------!
+ !n° !couche !
+ !4 !client !
+ !3 !aiguillage!
+ !2 !GS !
+ !1 !TCP/IP !
+ !----------------------!
+
+** La couche client
+
+Alors les données sont constitué d'un champ d'en-tête et des données. Le champ fait 4 octect, contient un int qui correspond à une structure de données ou à un ensemble de valeur particulière. Comme on utilise un numéro, ces structures ou ensembles de données doivent être défini et recevoir un numéro unique. Ce document répertorie toutes ces entités avec leur description et chaque nouvelle entités devrait avoir son entrée ici sous peine de grande claque dans la tête et accessoirement, un risque de conflit en production.
+
+** La couche aiguillage
+
+Le Hub transmet la plupart du temps un message d'un point vers un autre, d'un composant vers un autre. Le hub n'est pas medium et par conséquent, les info d'aiguillage sont contenu dans le message à ce niveau. Il y a donc une nouvelle entête avec deux champs de 8 octects contenant une string avec la source et la destination.
+
+** La couche GS
+
+Une fois toute les infos utiles entrées il faut connaitre la taille du message car les GS n'ont pas de taille fixe. Par conséquent, on a un entier sur 4 octects qui se fait une joie d'indiquer la taille de la GS.
+
+** La couche TCP/IP
+
+Comme je l'ai déjà dit, on utilise les sockets TCP/IP donc une fois la GS constitué, elle est envoyé à travers le réseau. Et ca c'est pas mes ognions c'est celui du kernel.
+
+* La gueule de la GS
+
+Finalement on a ça:
+
+ !--------------------------------!
+ ! 4 ! 8 ! 8 ! 4 ! X !
+ !taille!source!dest!structID!data!
+ !--------------------------------!
+
+Le tableau nest pas à l'echelle, désolé.
+
+* Conclusion
+
+Ceci permet de définir clairement la tête des packet envoyé à travers le réseau. C'est susceptible de changer, ce n'est que la première version mais ce document reflète le fonctionnement actuel du code.
+
+Une dernière chose, n'oubliez pas de regarder en dessous.
+
+* Annexe : Table des structures
+
+Pas de structure pour l'instant