-
Notifications
You must be signed in to change notification settings - Fork 19
/
TODO
149 lines (112 loc) · 6.9 KB
/
TODO
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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
Erk1) Setup a messageBuffer pool in order to
minimize realloc when creating
Message/NetworkMessage sub-classes instance
Erk2) Use visitor pattern for RTIG processing
Erk3) Use proper constructor and getter/setter for NetworkMessage
and avoid public shared field between different kind of message
... in progress ...
Erk5) Remove all kind of:
AnswerAssumption->exception = e_NO_EXCEPTION
Erk7) Clean-up PrettyDebug mess
Erk8) Suppress copy in ValueArray = req->getAttribValueArray();
Warning: this is an old file, many file/class names have changed, some
problems are probably solved or handled differently.
-------------------------------------------------------------------------------
1. Utiliser des pipes pour les communications Federe - RTIA, ce qui
permettra de ne plus avoir de problemes de fichiers qui existent deja.
>> Attention, je ne sais pas si on peut faire un select sur un pipe !
9. Utiliser la liste de Federes Abonnes pour une instance d'objet,
afin de limiter l'usage des BroadcastList. (voir CObject.hh)
11. Si un federe fournit un nom d'instance lors du RegisterObject, alors
ce nom doit etre unique (sinon exception "ObjectInstanceNotUnique").
>> Pour l'instant on ne peut pas fournir de nom d'instance.
17. Quand on fait un subscribe ou un unsubscribe alors que des instances
sont declarees dans la classe, faire des discover/remove object.
>> Fait pour le subscribe.
>> Attention pour le subscribe dans le cas des KillFederate. Tester par
exemple un SecurityServer->GetSocket avant de renvoyer une liste.
18. Si le RTIA recoit un message UAV pour un objet qu'il ne connait pas,
il le vire sans planter, car il peut tout simplement avoir fait
passer un RemoveObject avant les UAV en attente.
On peut penser a la meme chose pour le RemoveObject, mais dans ce cas,
c'est quand meme un autre probleme.
23. Dans GetInteractionName de la LibRTI, on utilise dans le CMessage
le champ ObjectHandle et pas la champ InteractionHandle. Ca doit chier
quelque part. Je n'ai pas regarde comment le RTIa decodait le CMessage,
c'est a dire s'il lit vraiment le champ ObjectHandle.
24. CRead devrait verifier la longueur des chaines qu'il lit, et de meme
pour les interactions et classes d'objets. Commencer par faire les
verifs dans les classes, puis dans CRead.
25. Ca pourrait etre une bonne idee, si on dispose d'une bibliotheque
de cryto, de calculer la signature du fichier FED pour verifier que
tout le monde a bien lu le meme. Il m'est arrive de lancer le RTIP
dans le mauvais repertoire, qui possedait un fichier Test.fed bien nomme
mais avec un contenu different de celui lu par le RTIA.
26. Probleme avec les exceptions Network Signal : elles ne figurent pas
dans la liste des exceptions renvoyees par les methodes qui utilisent
le reseau (comme les DiscoverObject, etc.).
Pour l'instant, on a jamais eu le cas ou l'exception NetworkSignal
etait renvoyee. Elle est censee etre interceptee par le RTIP, mais
en fait elle fera surement tout planter avant, vu qu'elle n'est pas
prevue (chaque methode declare les exceptions qu'elle peut renvoyer,
et les methodes utilisant le reseau comme UAV ne le font pas pour Network
Signal.).
27. Pendant que l'on lit le fichier FED, on ne verifie pas les doublons,
par exemple deux classes avec le meme nom, ou deux attributs/parametres
homonymes. (voir aussi les niveaux de securite).
28. Les "reason"s des Exceptions levees sur le RTIP ne parviennent pas
au RTIA. Faudrait quand meme voir si c'est possible. Envisager un systeme
equivalent a celui de la LibRTI ou on appelle TraiterException pour la
recpetion au niveau du RTIA.
29. Pour eviter la duplication des noms de classes ou d'attributs, il faut
verifier que les noms sont bien uniques, apres la lecture de l'arborescence
complete. En effet, cela sera beaucoup plus dur a faire au fur et a mesure
de la lecture, car les classes sont inserees dans l'arborescence avant
meme d'etre nommees. Peut-etre pourrait-on seulement les inserer lorsqu'on
trouve le nom, ce qui eviterait du meme coup d'inserer des classes
non-nommees.
30. Verifier le point suivant : quand un federe quitte une federation,
est-ce qu'on met bien dans le serveur de socket ses references a 0 ?
Cela a deux consequences : si elles sont mises a zero, l'entree ne sera
pas gardee apres le CloseConnection, mais la federation cherchant a lui
communiquer qquechose levera une FederateNotExecutionMember, au lieu
d'une RTIinternalError pour les Killed Federates. Est-ce gere ?
Si elle n'est pas mise a zero, l'entree est gardee eternellement...
31. Un probleme rencontre par Afiff : Si un federe n'est pas regulateur,
la federation ne l'attend pas pour avancer. Du coup, il peut se
retrouver noyer par les messages en provenance du RTIP.
Explication : Dans GCom::LireMsg, on choisit systematiquement les
messages venant du RTIP d'abord, donc si il y en a toujours, le RTIA
ne lit pas ceux du Federe.
Solution : Mettre en place un systeme d'alternance 1 message du RTIP
puis un Message du Federe etc... Ca me parait le plus simple et le
plus efficace pour des cas pas trop tordus.
32. La libRTI, dans son destructeur, devrait attendre la mort de son fils
RTIA, par un appel systeme a wait(). Cela pose encore le probleme dans
le cas ou le fils refuse de mourir parce qu'il est createur d'une
federation et qu'il attend de pouvoir la detruire, mais quand meme ca
permettrait de regler certaines choses.
De plus, le federe n'a pas a faire de Wait, puisque ca veut dire que ca
depend de l'implementation du RTI.
33. Pour permettre l'echange facile des moyens de communications, c'est-a-dire
passer facilement d'un socket TCP a un socket UDP entre le RTIP et le
RTIA, faire ceci :
- Migrer les socket UNIX vers un heritage de CSocket. (pour l'instant,
c'est completement independant).
- Sur le RTIA, CGestionCom ne doit plus heriter des deux classes
CSocketUN et CSecureTCPSocket, mais juste garder deux pointeurs
CSocket, qui est rapelons-le, une classe virtuelle. Ces deux
pointeurs seront SocketFed et SocketRTIP. Les objets pointes,
qui representeront en fait des protocoles, seront alloues dans le
constructeur, en se servant de noms de classes definis dans
RTI_config.hh. Par exemple, on peut avoir :
#define HLA_RTIP_RTIA_SOCKET_CLASS CSecureTCPSocket
#define HLA_FED_RTIA_SOCKET_CLASS CSocketUN
Cela permet ainsi de pouvoir facilement changer un type de socket
par un autre.
- Des amenagements similaires sont a prevoir dans la libRTI et sur le
RTIP, plus specialement au niveau du serveur de socket qui alloue
les nouveaux objets sockets.
Ca pourrait meme permettre d'utiliser des pipes, non ? Non pas forcement,
parce que ca demande quand meme des initialisations differentes de celles
des sockets.