Client/serveur
cs_tanoura
Messages postés
4
Date d'inscription
mercredi 17 octobre 2007
Statut
Membre
Dernière intervention
21 novembre 2007
-
17 oct. 2007 à 18:38
The_Guardian Messages postés 317 Date d'inscription vendredi 25 mai 2007 Statut Membre Dernière intervention 19 octobre 2007 - 19 oct. 2007 à 18:10
The_Guardian Messages postés 317 Date d'inscription vendredi 25 mai 2007 Statut Membre Dernière intervention 19 octobre 2007 - 19 oct. 2007 à 18:10
10 réponses
DeAtHCrAsH
Messages postés
2670
Date d'inscription
vendredi 25 janvier 2002
Statut
Membre
Dernière intervention
6 février 2013
18 oct. 2007 à 09:32
18 oct. 2007 à 09:32
Salut,
Pourquoi avoir mis le code du client abec celui du serveur ? Par définition le client et le serveur sont des entitées à pat entière.
Pour ce qui est de l'envoie des messages aux gateway, as tu essayé en faisant un broadcast sur le sous réseau ciblé ?
Pourquoi penses tu que cela est due à un problème de port ?
Shell
Pourquoi avoir mis le code du client abec celui du serveur ? Par définition le client et le serveur sont des entitées à pat entière.
Pour ce qui est de l'envoie des messages aux gateway, as tu essayé en faisant un broadcast sur le sous réseau ciblé ?
Pourquoi penses tu que cela est due à un problème de port ?
Shell
The_Guardian
Messages postés
317
Date d'inscription
vendredi 25 mai 2007
Statut
Membre
Dernière intervention
19 octobre 2007
1
18 oct. 2007 à 09:40
18 oct. 2007 à 09:40
Bonjour,
Ok si je comprends bien ton programme, tu veux pouvoir lancer pleins de routeurs RIP, chacun émettant et recevant des messages par TCP
_ si tu fais du TCP, tu dois utiliser des liens point à point
- je vois deux possibilités :
(1) soit tu fais un serveur et pleins de clients, le serveur correspondant au réseau et chaque client à un routeur
(2) soit chaque routeur est un client-serveur, mais dans ce cas là il faut que tu dises manuellement au routeur 1 de se connecter au routeur 2 (par exemple)
Il faut que tu triches un peu donc dans le sens ou :
- (dans le cas 1) c'est le réseau qui transforme chaque paquet "broadcast" en plusieurs paquets "unicast"
- (dans le cas 2) le routeur connaît la liste de ses voisins routeurs donc il peut leur envoyer des infos point à point
Et je préfère le cas 1 en fait, ça permet d'avoir un code de routeur propre, sans verrue. Mais par contre il faut que tu encapsules tes paquets RIP dans un type de paquet plus gros contenant le routeur destination par exemple (qui peut être broadcast ou unicast)
=
Une autruche ne se cuit pas aux petits lardons
Ok si je comprends bien ton programme, tu veux pouvoir lancer pleins de routeurs RIP, chacun émettant et recevant des messages par TCP
_ si tu fais du TCP, tu dois utiliser des liens point à point
- je vois deux possibilités :
(1) soit tu fais un serveur et pleins de clients, le serveur correspondant au réseau et chaque client à un routeur
(2) soit chaque routeur est un client-serveur, mais dans ce cas là il faut que tu dises manuellement au routeur 1 de se connecter au routeur 2 (par exemple)
Il faut que tu triches un peu donc dans le sens ou :
- (dans le cas 1) c'est le réseau qui transforme chaque paquet "broadcast" en plusieurs paquets "unicast"
- (dans le cas 2) le routeur connaît la liste de ses voisins routeurs donc il peut leur envoyer des infos point à point
Et je préfère le cas 1 en fait, ça permet d'avoir un code de routeur propre, sans verrue. Mais par contre il faut que tu encapsules tes paquets RIP dans un type de paquet plus gros contenant le routeur destination par exemple (qui peut être broadcast ou unicast)
=
Une autruche ne se cuit pas aux petits lardons
DeAtHCrAsH
Messages postés
2670
Date d'inscription
vendredi 25 janvier 2002
Statut
Membre
Dernière intervention
6 février 2013
18 oct. 2007 à 10:13
18 oct. 2007 à 10:13
Salut The_Guardian,
Je pense que tu as besoin de quelques précison sur les protocoles réseau, car je remarque quelques incohérence dans tes dires (ou alors j'ai pas compris).
1°) Pour commencer pourquoi parles tu de TCP et de connexion P2P ?
=> Ne pas oublier qu'un message RIP est encapsulé dans un datagramme UDP, et n'attend aucune réponse de la part des autres routeur lors de l'envoie des tables de routages.
2°) Ensuite, tu parles de transformer des paquets broadcast en paquets unicast ....
=> Rien à voir, ca n'a aucune sens, un broadcast est seulement le fait d'envoyer un message sur un réseau sans destinataire précis. Touts les clients receveront se message et le traiteront à leur guise (cf masque de sous réseau).
Je précise, que unicast est le "mode inverse" de multicast", et non broadcast.
Pour le reste jette donc un coup d'oeil sur Google, tu trouveras plein d'articles sur le RIP.
Shell
Je pense que tu as besoin de quelques précison sur les protocoles réseau, car je remarque quelques incohérence dans tes dires (ou alors j'ai pas compris).
1°) Pour commencer pourquoi parles tu de TCP et de connexion P2P ?
=> Ne pas oublier qu'un message RIP est encapsulé dans un datagramme UDP, et n'attend aucune réponse de la part des autres routeur lors de l'envoie des tables de routages.
2°) Ensuite, tu parles de transformer des paquets broadcast en paquets unicast ....
=> Rien à voir, ca n'a aucune sens, un broadcast est seulement le fait d'envoyer un message sur un réseau sans destinataire précis. Touts les clients receveront se message et le traiteront à leur guise (cf masque de sous réseau).
Je précise, que unicast est le "mode inverse" de multicast", et non broadcast.
Pour le reste jette donc un coup d'oeil sur Google, tu trouveras plein d'articles sur le RIP.
Shell
The_Guardian
Messages postés
317
Date d'inscription
vendredi 25 mai 2007
Statut
Membre
Dernière intervention
19 octobre 2007
1
18 oct. 2007 à 10:23
18 oct. 2007 à 10:23
Bonjour DeathCrash
Non je crois que tu as pas compris :p
Je prépare ma réponse et je reviens, pour que ce soit bien concis.
=
Une autruche ne se cuit pas aux petits lardons
Non je crois que tu as pas compris :p
Je prépare ma réponse et je reviens, pour que ce soit bien concis.
=
Une autruche ne se cuit pas aux petits lardons
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
The_Guardian
Messages postés
317
Date d'inscription
vendredi 25 mai 2007
Statut
Membre
Dernière intervention
19 octobre 2007
1
18 oct. 2007 à 10:46
18 oct. 2007 à 10:46
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
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
DeAtHCrAsH
Messages postés
2670
Date d'inscription
vendredi 25 janvier 2002
Statut
Membre
Dernière intervention
6 février 2013
18 oct. 2007 à 11:37
18 oct. 2007 à 11:37
Interressant ce que tu dis, mais ca n'en reste pas moins dénué de sens quant à la question posé par tanoura.
Tu mélanges beaucoup de notion réseaux sans forcément connaitres les spécificités de chacune d'entre elles.
Renseignes toi avant de déblatérrer des inepties. On est pas au pièces ici, on ne répond pas aux questions dans le seul but de faire grimper sa côte dans le top des membres (et j'espere que ce n'est pas le cas)!
Bref pour en revenir a ce que tu dis....
Quant on crée un simulteur, on reproduit toutes les conditions à l'identique de l'équipement.
Donc quand tu parles d'utiliser du TCP pour faire du RIP, tu es déjà hors sujet et tu ne fais que compliquer la compréhension du problème d'ou ma reflexion concernant google :)
On ne résoud pas un problème par un autre problème!
Quote :
" je préconise l'utilisation de TCP pour simuler du UDP et du IP "
=> va vraiment falloir que tu révises te cours de réseau (si tu en as déjà eu ^_^ )
TCP = Connexion persistente (donc une seule connexion possible par couple Port/IP)
UDP = Connexion sans controle de données (donc multiple conenxion par couple Port/IP)
TCP & UDP sont deux protocoles different qui sont encapsulés dans IP.
On en fait pas de la programmation avec des a priori et des connaissance non abouties surtout dans le domaine du réseaux.
Sinon tanoura, je viens de penser à un truc. Netgear met à disposition les codes sources de tout ces firmwares intégré dans les routeurs grand public, tu peux donc essayer de voir sur cette piste pour récuperer ce qui t'interresse concernant le protocle RIP.
Bon courage pour ton projet.
Shell
Tu mélanges beaucoup de notion réseaux sans forcément connaitres les spécificités de chacune d'entre elles.
Renseignes toi avant de déblatérrer des inepties. On est pas au pièces ici, on ne répond pas aux questions dans le seul but de faire grimper sa côte dans le top des membres (et j'espere que ce n'est pas le cas)!
Bref pour en revenir a ce que tu dis....
Quant on crée un simulteur, on reproduit toutes les conditions à l'identique de l'équipement.
Donc quand tu parles d'utiliser du TCP pour faire du RIP, tu es déjà hors sujet et tu ne fais que compliquer la compréhension du problème d'ou ma reflexion concernant google :)
On ne résoud pas un problème par un autre problème!
Quote :
" je préconise l'utilisation de TCP pour simuler du UDP et du IP "
=> va vraiment falloir que tu révises te cours de réseau (si tu en as déjà eu ^_^ )
TCP = Connexion persistente (donc une seule connexion possible par couple Port/IP)
UDP = Connexion sans controle de données (donc multiple conenxion par couple Port/IP)
TCP & UDP sont deux protocoles different qui sont encapsulés dans IP.
On en fait pas de la programmation avec des a priori et des connaissance non abouties surtout dans le domaine du réseaux.
Sinon tanoura, je viens de penser à un truc. Netgear met à disposition les codes sources de tout ces firmwares intégré dans les routeurs grand public, tu peux donc essayer de voir sur cette piste pour récuperer ce qui t'interresse concernant le protocle RIP.
Bon courage pour ton projet.
Shell
The_Guardian
Messages postés
317
Date d'inscription
vendredi 25 mai 2007
Statut
Membre
Dernière intervention
19 octobre 2007
1
18 oct. 2007 à 11:54
18 oct. 2007 à 11:54
Je ne comprend pas ton agressivité DeathCrash, et de me dire que je deblate des inepties, c'est assez méchant de dire cela. Je sais de quoi je parle, tant pis si tu as envie de me casser ici, l'important pour moi est d'aider mon prochain avec mes connaissances, et d'évoluer dans ce sens. Le tout est que notre jeune ami au final arrive à se trouver dans son problème.
Et non qu'on se chamaille inutilement. Ce n'est certainement pas le but recherché ici, et ni le mien.
Bonne journée :p
Une autruche ne se cuit pas aux petits lardons
Et non qu'on se chamaille inutilement. Ce n'est certainement pas le but recherché ici, et ni le mien.
Bonne journée :p
Une autruche ne se cuit pas aux petits lardons
DeAtHCrAsH
Messages postés
2670
Date d'inscription
vendredi 25 janvier 2002
Statut
Membre
Dernière intervention
6 février 2013
18 oct. 2007 à 12:21
18 oct. 2007 à 12:21
Yop,
Ne prend pas ca comme un affront.
Désolé si je t'ai paru agressif, ce n'était pas mon but. Si j'ai pris la peine de répondre c'est uniquement dans le but de faire avancer la discussion. Je suis surement maladroit dans ma manière de dire les choses, mais pas agressif.
Si tu as des doutes sur certaines de tes connaissances, pose plutot la question plutot que d'affirmer sans être sure.
Cela profitera à toutle monde à commencer par toi et moi ;-)
Bref j'espère au moins t'avoir aidé à y voir plus clair sur ce sujet, tout comme à tanoura.
Merci et passe une bonne journée aussi :)
Shell
P.S : J'espère ne pas t'avoir vexé ?
Ne prend pas ca comme un affront.
Désolé si je t'ai paru agressif, ce n'était pas mon but. Si j'ai pris la peine de répondre c'est uniquement dans le but de faire avancer la discussion. Je suis surement maladroit dans ma manière de dire les choses, mais pas agressif.
Si tu as des doutes sur certaines de tes connaissances, pose plutot la question plutot que d'affirmer sans être sure.
Cela profitera à toutle monde à commencer par toi et moi ;-)
Bref j'espère au moins t'avoir aidé à y voir plus clair sur ce sujet, tout comme à tanoura.
Merci et passe une bonne journée aussi :)
Shell
P.S : J'espère ne pas t'avoir vexé ?
cs_rt15
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
13
19 oct. 2007 à 17:38
19 oct. 2007 à 17:38
Salut les gens.
Mais c'est qu'il y a du sang partout ici !
A ce que je comprend, The_Guardian voit ça comme ça :
+----------------------
couche application : Simulation de UDP/RIP.
+----------------------
couche transport TCP
+----------------------
couche réseau : IP
+----------------------
couche liaison de données : ethernet, token ring...
+----------------------
couche physique : cable, fibre...
+----------------------
Solution lourde mais qui permet certe un plus grand contrôle sur ce qui
est échangé entre les différents composants du réseau (Pas de pertes de
paquets).
De son côté DeAtHCrAsH voit ça "normalement" :
+----------------------
couche application : RIP (De préférence compatible avec le vrai RIP)
+----------------------
couche transport UDP
+----------------------
couche réseau : IP
+----------------------
couche liaison de données : ethernet, token ring...
+----------------------
couche physique : cable, fibre...
+----------------------
Cette solution a l'avantage d'espérer permettre un jour au PC de
dialoguer avec un routeur CISCO ou autre. Et même si on cherche pas à
recréer le RIP à l'identique, cette solution est plus simple.
Maintenant, je vais essayer déblatérer des ineptie, de manière à faire augmenter mon rank sur CS.
tanoura utilise certainement des sockets. Supposons que ce soient des
sockets standarts. Supposons que tanoura ai souhaité utiliser la
solution numéro 2.
Il a donc créer des socket en utilsant la constante et SOCK_DGRAM (UDP), et non SOCK_STREAM (TCP).
Pour la config, il faut remplir une structure sockaddr_in. AF_INET, le numéro de port... jusque là tout va bien.
Reste l'adresse IP. Bin là, en théorie pour faire du broadcast, comme
cité plus haut, de manière à joindre tous les hôtes d'un réseau, il
faut utiliser l'adresse de broadcast du réseau en question (Petite
remarque : RIP v2 permet le broadcast, mais aussi le multicast sur
224.0.0.9, c'est à dire que tous les routeurs utilisant RIP v2
considère cette IP comme là leurs).
Déterminer cette adresse de broadcast est pas super trivial si il y a
des sous réseaux. Mais tanoura fait certainement ses tests sur un
réseau privé avec un masque en puissance de 2. On va dire qu'il a des
privés de classe C :
PC1 : 192.168.0.1
PC2 : 192.168.0.2
PC3 : 192.168.0.3
...
Le réseau s'appelle donc : 192.168.0.0, avec un masque 255.255.255.0.
Pour avoir l'adresse de broadcast, il faut faire un... disons un not
binaire du masque, enchaîné avec un or avec le réseau. Dans ce cas :
192.168.0.255.
Voilà. On sait comment configurer la socket en émission. Reste plus qu'à faire du send.
Côté client, je sais encore moins ce qu'il faut faire. Peut être la même chose...
<hr size="2" width="100%" />3ème année en ecole d'ingé d'info cherche stage de 4 mois à partir du 01/04/08
Mais c'est qu'il y a du sang partout ici !
A ce que je comprend, The_Guardian voit ça comme ça :
+----------------------
couche application : Simulation de UDP/RIP.
+----------------------
couche transport TCP
+----------------------
couche réseau : IP
+----------------------
couche liaison de données : ethernet, token ring...
+----------------------
couche physique : cable, fibre...
+----------------------
Solution lourde mais qui permet certe un plus grand contrôle sur ce qui
est échangé entre les différents composants du réseau (Pas de pertes de
paquets).
De son côté DeAtHCrAsH voit ça "normalement" :
+----------------------
couche application : RIP (De préférence compatible avec le vrai RIP)
+----------------------
couche transport UDP
+----------------------
couche réseau : IP
+----------------------
couche liaison de données : ethernet, token ring...
+----------------------
couche physique : cable, fibre...
+----------------------
Cette solution a l'avantage d'espérer permettre un jour au PC de
dialoguer avec un routeur CISCO ou autre. Et même si on cherche pas à
recréer le RIP à l'identique, cette solution est plus simple.
Maintenant, je vais essayer déblatérer des ineptie, de manière à faire augmenter mon rank sur CS.
tanoura utilise certainement des sockets. Supposons que ce soient des
sockets standarts. Supposons que tanoura ai souhaité utiliser la
solution numéro 2.
Il a donc créer des socket en utilsant la constante et SOCK_DGRAM (UDP), et non SOCK_STREAM (TCP).
Pour la config, il faut remplir une structure sockaddr_in. AF_INET, le numéro de port... jusque là tout va bien.
Reste l'adresse IP. Bin là, en théorie pour faire du broadcast, comme
cité plus haut, de manière à joindre tous les hôtes d'un réseau, il
faut utiliser l'adresse de broadcast du réseau en question (Petite
remarque : RIP v2 permet le broadcast, mais aussi le multicast sur
224.0.0.9, c'est à dire que tous les routeurs utilisant RIP v2
considère cette IP comme là leurs).
Déterminer cette adresse de broadcast est pas super trivial si il y a
des sous réseaux. Mais tanoura fait certainement ses tests sur un
réseau privé avec un masque en puissance de 2. On va dire qu'il a des
privés de classe C :
PC1 : 192.168.0.1
PC2 : 192.168.0.2
PC3 : 192.168.0.3
...
Le réseau s'appelle donc : 192.168.0.0, avec un masque 255.255.255.0.
Pour avoir l'adresse de broadcast, il faut faire un... disons un not
binaire du masque, enchaîné avec un or avec le réseau. Dans ce cas :
192.168.0.255.
Voilà. On sait comment configurer la socket en émission. Reste plus qu'à faire du send.
Côté client, je sais encore moins ce qu'il faut faire. Peut être la même chose...
<hr size="2" width="100%" />3ème année en ecole d'ingé d'info cherche stage de 4 mois à partir du 01/04/08
The_Guardian
Messages postés
317
Date d'inscription
vendredi 25 mai 2007
Statut
Membre
Dernière intervention
19 octobre 2007
1
19 oct. 2007 à 18:10
19 oct. 2007 à 18:10
Bonjour,
Effectivement, méthode avec du " non perte de paquets " . Facon propre :p
Mais ensuite, chacun fait à sa manière. Moi à mon école d'ingénieur, c'était ainsi que j'ai appris. Ainsi que mes stages.
rt15, tu cherches un stage dans quel coin ?
Une autruche ne se cuit pas aux petits lardons :p
Effectivement, méthode avec du " non perte de paquets " . Facon propre :p
Mais ensuite, chacun fait à sa manière. Moi à mon école d'ingénieur, c'était ainsi que j'ai appris. Ainsi que mes stages.
rt15, tu cherches un stage dans quel coin ?
Une autruche ne se cuit pas aux petits lardons :p
