RE
Salut,
En fait, je pense que tu n'as compris ni ma réponse, ni le problème de notre ami. C'est pas très grave, je vais réexpliquer, je suis là pour ça après tout.
(1) TCP, UDP et IP
Le problème est de faire un simulateur du protocole RIP. RIP envoie des trames UDP, d'accord. Là, on fait de la simulation. Qui dit simulation dit répétabilité.
La répétabilité c'est quoi ? C'est le fait de pouvoir rejouer exactement la même simulation et d'obtenir le même résultat. Ça veut dire que ta simulation doit être fiable, et que tu dois pouvoir la contrôler. Si des paquets sont perdus (ce qui peut arriver dans un réseau), tu veux que ça soit le simulateur lui même qui décide, et non pas les conditions de l'ordinateur exécutant la simulation.
Répétabilité et fiabilité, ça veut dire TCP. En gros, je préconise l'utilisation de TCP pour simuler du UDP et du IP (et même de l'ARP ou n'importe quoi d'ailleurs).
(2) Absence d'acquittements
Il n'y a pas de rapport entre le fait que TCP acquitte le flux et le fait que les routeurs RIP n'acquittent pas les paquets RIP. Explication ? Voici un petit schéma :
Routeur 1 <=UDP=> Routeur 2
Routeur 1 et Routeur 2 communiquent en UDP. Il n'y a pas d'acquittement et des paquets peuvent être perdus. Ok.
Routeur 1 <=TCP=> Réseau <=TCP=> Routeur 2
Routeur 1 et Réseau communiquent en TCP. Il y a des acquittements et pas de paquets perdus. Réseau et Routeur 2 communiquent en TCP. Idem. Par contre, les pertes (éventuelles) sont gérées au niveau du programme Réseau. Pour Routeur 1 et Routeur 2, c'est transparent et ça se passe comme dans le cas du dessus.
(3) Broadcast, multicast et unicast
Unicast : one-to-one (point à point)
Broadcast : one-to-all (diffusion)
Multicast : one-to-many (point à multipoint)
Je ne comprends pas ta terminologie de "mode inverse", mais je suppose que c'est juste ta façon de voir les choses. Ok.
Bon mais le problème de compréhension là c'est la différence entre "comportement logique" et "comportement effectif".
Comportement logique : on est au niveau fonctionnel là. Un paquet broadcasté sur un réseau est reçu par toutes les stations du réseau ("réseau" peut être remplacé par lien, sous-réseau, etc).
Comportement effectif : là on parle d'implémentation. C'est quoi le réseau ? C'est quoi le lien ? Si j'ai trois "programmes routeurs" qui tournent sur ma machine, on va dire A, B et C, comment je fais pour savoir à qui A est connecté ? A est forcément connecté à B et C ? Non.
Vu que l'information de la topologie du réseau ne peut pas être déduite, il faut qu'elle soit quelque part. Soit elle est stockée à part (dans le "serveur réseau" que je proposais (cas 1) ou bien chaque "programme routeur" maintient une table de ses liens (cas 2)).
(3.1) Si les connexions entre "programmes routeurs" sont faites en UDP (même si c'est mal)
Ok, donc on va dire qu'on a des clients-serveurs UDP. Donc j'ai toujours mes trois programmes A, B et C et quand A broadcaste, je veux que seulement B reçoive (parce que la topologie est comme ça, admettons). Comment je fais un broadcast UDP vers un sous-ensemble de ports ? Euh... Ah ben c'est pas facile en fait. Problème.
(3.2) Si les connexions entre "programmes routeurs" sont faites en TCP
Même problème ici, on peut pas faire de broadcast TCP vers un sous-ensemble des ports. Hmmm... Mais que faire ?
(3.3) Solution : transformer du broadcast en du multi-unicast
Bon ben voilà une solution. Je sais que A veut envoyer un broadcast. Je regarde quelles sont les machines qui vont être atteintes. Je trouve B (et D allez). J'envoie un paquet unicast à B (et un autre à D). L'intérêt d'avoir du unicast c'est que je passe par mes liens TCP déjà établis.
(4) Google et RIP
En fait, je pense que ta dernière remarque est un peu hors sujet. Deux réponses possibles :
- ce n'est pas à moi de lire la doc de RIP mais à celui qui pose la question initiale, non ?
- jette un coup d'oeil sur Google, tu trouveras pleins d'articles sur la simulation de protocoles réseau :)
(5) Conclusion
C'est plus clair à présent ? Ça m'embête un peu d'avoir à me justifier quand même, surtout quand c'est pas la personne posant la question.
===
Une autruche ne se cuit pas aux petits lardons 