summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/message.txt
blob: 04b6cfb3a36eddc5796d5a42b963a7c16da3059a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
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