Protocole connecté non fiable
jessica
-
SKZ81 -
SKZ81 -
bonjour, je suis en licence d'info et j'ai un projet de réseau a faire mais je ne sais pas trop comment m'y prendre..
Si vous pouviez m'aider, me conseiller..
Il s'agit d'implémenter un protocole connecté non fiable en se basant sur le protocole UDP pour recevoir et envoyer des paquets a transmettre.
il devra fournir le meme type de services (fction C) que TCP : connect accept, listen, bind read, write close.
une interface socketPCNF a implémenter qui devra jouer le meme role que socket dans le domaine AF_INET.
un adressage par nom de la machine et un port.
La vitesse de transmission des données envoyés par un write doit etre modulable et constante(par défaut 250ko/s) Il doit découper les données en paquet UDP de taille fixée (par défaut 4ko)
Je vous remercie par avance de toutes vos réponses.
Bisous jess
Si vous pouviez m'aider, me conseiller..
Il s'agit d'implémenter un protocole connecté non fiable en se basant sur le protocole UDP pour recevoir et envoyer des paquets a transmettre.
il devra fournir le meme type de services (fction C) que TCP : connect accept, listen, bind read, write close.
une interface socketPCNF a implémenter qui devra jouer le meme role que socket dans le domaine AF_INET.
un adressage par nom de la machine et un port.
La vitesse de transmission des données envoyés par un write doit etre modulable et constante(par défaut 250ko/s) Il doit découper les données en paquet UDP de taille fixée (par défaut 4ko)
Je vous remercie par avance de toutes vos réponses.
Bisous jess
A voir également:
- Protocole connecté non fiable
- Fonctionnement du protocole http - Guide
- Trustpilot est il fiable - Accueil - Services en ligne
- Appareil connecté facebook - Guide
- Qui est connecté sur mon wifi - Guide
- Protocole tcp udp - Guide
3 réponses
Ouais c'est un peu vaste.
Commençons par le début.
Mode connecté : il faut gérer la connexion de deux ordis. En UDP, tu te contente de balancer un paquet sur une adresse, mais tu te fout royalement de savoir s'il a été demandé, s'il est attendu, s'il arrive ou non.
Il n'y a pas non plus de notion de client ou de serveur...
Donc la voie dans laquelle il faut s'engager c'est de réimplémenter la connexion TCP :
- Le client envoie eun paquet de demande de connexion.
- Le serveur renvoie un paquet de confirmation de connexion et ajoute le client dans une liste des clients connecté.
- En TCP mais c'est du à la fiabilité, le client renvoie un paquet de "confirmation de la confirmation", et ajoute le serveur dans la liste des serveurs.
Il se pose le problème de savoir si un client et un serveur peuvent être reliés par plusieurs connexions ou non. Si oui, il faudra pouvoir différencier les connexions (en utilisant un ID par exemple, en TCP c'est un numéro de séquence qui est incrémenté à chaque paquet envoyé).
Fiabilité : pourtant ça c'est pas dur à implémenté. En TCP tu renvoie un p'tit paquet disant "paquet N°XYZ bien reçu !".
>>un adressage par nom de la machine et un port.
Pas de soucis, j'immagine que tu compte quand même réutiliser les sockets POSIX !! Donc c'est presque automatique... En jouant avec gethostbyname().
>>La vitesse de transmission des données envoyés par un write doit etre modulable et constante(par défaut 250ko/s)
La tu n'aura jamais rien de garanti en environnement multitâche.
Tu peux faire mumuse avec les sigaction()/setitimer() (encore du POSIX) pour mesurer le temps qui s'écoule et moduler la vitesse de transmition.
Découper les donnée, faut juste implémenter un buffer, quand il est plein, et que tu reçoit le top syncheo (signal SIGALRM envoyé par le itimer), tu balance le paquet en appelant le write() système.
Voilà, j'espère avoir été clair, n'hésite pas à poser d'autres question, je t'aiderai dans la mesure du possible !
A+ (et merci pour le bisou !)
Commençons par le début.
Mode connecté : il faut gérer la connexion de deux ordis. En UDP, tu te contente de balancer un paquet sur une adresse, mais tu te fout royalement de savoir s'il a été demandé, s'il est attendu, s'il arrive ou non.
Il n'y a pas non plus de notion de client ou de serveur...
Donc la voie dans laquelle il faut s'engager c'est de réimplémenter la connexion TCP :
- Le client envoie eun paquet de demande de connexion.
- Le serveur renvoie un paquet de confirmation de connexion et ajoute le client dans une liste des clients connecté.
- En TCP mais c'est du à la fiabilité, le client renvoie un paquet de "confirmation de la confirmation", et ajoute le serveur dans la liste des serveurs.
Il se pose le problème de savoir si un client et un serveur peuvent être reliés par plusieurs connexions ou non. Si oui, il faudra pouvoir différencier les connexions (en utilisant un ID par exemple, en TCP c'est un numéro de séquence qui est incrémenté à chaque paquet envoyé).
Fiabilité : pourtant ça c'est pas dur à implémenté. En TCP tu renvoie un p'tit paquet disant "paquet N°XYZ bien reçu !".
>>un adressage par nom de la machine et un port.
Pas de soucis, j'immagine que tu compte quand même réutiliser les sockets POSIX !! Donc c'est presque automatique... En jouant avec gethostbyname().
>>La vitesse de transmission des données envoyés par un write doit etre modulable et constante(par défaut 250ko/s)
La tu n'aura jamais rien de garanti en environnement multitâche.
Tu peux faire mumuse avec les sigaction()/setitimer() (encore du POSIX) pour mesurer le temps qui s'écoule et moduler la vitesse de transmition.
Découper les donnée, faut juste implémenter un buffer, quand il est plein, et que tu reçoit le top syncheo (signal SIGALRM envoyé par le itimer), tu balance le paquet en appelant le write() système.
Voilà, j'espère avoir été clair, n'hésite pas à poser d'autres question, je t'aiderai dans la mesure du possible !
A+ (et merci pour le bisou !)
rebonjour!!
je voulais savoir si je pouvais t'envoyer un mail avec mes sources pour que tu jette un ptit coup d'oeil si tu as le tps pour me dire ce ki va, ce ki ne va pas...
merci d'avance..
encore un bizoo!!!
je voulais savoir si je pouvais t'envoyer un mail avec mes sources pour que tu jette un ptit coup d'oeil si tu as le tps pour me dire ce ki va, ce ki ne va pas...
merci d'avance..
encore un bizoo!!!
Bien sûr, qu'il faut que tu utilise UDP !!!
Mon post le laissait entendre !!!
Je n'ai cité TCP que parce qu'il fait ce que tu veux !! C'est une référence, le sujet de ton TP est basé sur ce truc, si tu l'utilise, y'a plus rien à faire !!
-> skizzz@caramail.com
C'est mon adresse "grand publique"...
(Re-merci pour les bizoox)
Mon post le laissait entendre !!!
Je n'ai cité TCP que parce qu'il fait ce que tu veux !! C'est une référence, le sujet de ton TP est basé sur ce truc, si tu l'utilise, y'a plus rien à faire !!
-> skizzz@caramail.com
C'est mon adresse "grand publique"...
(Re-merci pour les bizoox)
j'en ais discuté avec mon prof et il m'a dit que en faite il fallait que je me base absolument sur le protocole udp (c imposé:(
As tu d'autres suggestions sil te plait pour le faire avec la base de ce protocle ?