Tu mélanges allègrement couche 4 et couche 7. Toute communication réseau est point à point et client/serveur (on oublie le multicast on est sur Internet). La couche transport, TCP ou UDP, te permet juste d'envoyer des données d'un point A à un point B. Y'en a un des deux qui initie la connexion, le client, et l'autre qui écoute, le serveur. Après c'est de la logique applicative de savoir si tu fais du p2p ou du client/serveur mais tes communications sont toujours pap et client/serveur.
Tu confonds aussi checksum et offset couche transport et applicative.
Pour du transport de donnée les services qu'offrent TCP sont très adaptés: contrôle de flux, contrôle de congestion, connexion fiable. Tu as besoin de ces mécanismes et tu n'arriveras pas à égaler 1/10 de la qualité de TCP tant au niveau design qu'implémentation. Pour faire très simple on passe en UDP quand on se fou de la fiabilité ou qu'on préfère l'assurer au niveau applicatif (streaming, jeux vidéos etc.).
Bref fais quelque chose de très simple par ce que tu semble partir de très loin en réseau. De plus les algorithmes applicatifs de P2P c'est un tout autre domaine qui n'a aucun rapport à la programmation réseau, et ça n'a rien de trivial (il y a de très bon papier sur l'analyse et le fonctionnement du protocole bittorrent par exemple) .
[^] # Re: Pourquoi UDP ?
Posté par ckyl . En réponse au journal Application de P2P moderne. Évalué à 4.
Tu mélanges allègrement couche 4 et couche 7. Toute communication réseau est point à point et client/serveur (on oublie le multicast on est sur Internet). La couche transport, TCP ou UDP, te permet juste d'envoyer des données d'un point A à un point B. Y'en a un des deux qui initie la connexion, le client, et l'autre qui écoute, le serveur. Après c'est de la logique applicative de savoir si tu fais du p2p ou du client/serveur mais tes communications sont toujours pap et client/serveur.
Tu confonds aussi checksum et offset couche transport et applicative.
Pour du transport de donnée les services qu'offrent TCP sont très adaptés: contrôle de flux, contrôle de congestion, connexion fiable. Tu as besoin de ces mécanismes et tu n'arriveras pas à égaler 1/10 de la qualité de TCP tant au niveau design qu'implémentation. Pour faire très simple on passe en UDP quand on se fou de la fiabilité ou qu'on préfère l'assurer au niveau applicatif (streaming, jeux vidéos etc.).
Bref fais quelque chose de très simple par ce que tu semble partir de très loin en réseau. De plus les algorithmes applicatifs de P2P c'est un tout autre domaine qui n'a aucun rapport à la programmation réseau, et ça n'a rien de trivial (il y a de très bon papier sur l'analyse et le fonctionnement du protocole bittorrent par exemple) .