protocoles de communication dans UDP

Question

Après plusieurs heures, j'ai découvert que le serveur a besoin udp donné les étapes suivantes pour une communication réussie:

1- Envoyer « Démarrer un message » sur un port donné
2- Attendez de recevoir du serveur sur un port
3- Ensuite, le port dédié à vous envoyer des données supplémentaires sur le serveur est égal au port que vous avez reçu à ce sujet + 1

Je demande donc si ce genre est un protocole connu/handshaking, ou est-ce seulement spécial à ce serveur ??

PS: Tout ce qui précède la communication étaient en prises udp en C#
PS: associés à une question précédente: About C# UDP Sockets

Merci

Answer 1

Il n'y a pas "poignée de main" spécial pour UDP - chaque UDP service, s'il en a besoin, spécifie le sien. Généralement, cependant, un serveur ne s'attend pas à ce que le client puisse écouter simultanément tous ses ports. Si vous voulez dire que le client attend un message de n'importe quel port sur le serveur, sur le port duquel le client a envoyé le message de démarrage, cela est beaucoup plus logique - et est très proche du fonctionnement de TFTP. (La seule différence que je vois à ce jour, est que TFTP ne fait pas le "+ 1".)

Answer 2

Le serveur écoute effectivement sur un «port bien connu», puis commute les communications suivantes vers un port dédié par client. Exiger que le client envoie au port + 1 est un peu étrange

Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 5050 
Client 192.168.0.1 - port 12121 <------------------------ Server 192.168.0.2 - port 23232 
Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 23232 + 1 
            <------------------------ Server 192.168.0.2 - port 23232 
            ------------------------> Server 192.168.0.2 - port 23232 + 1 

Le serveur ne peut-être cela pour que cela ne doit pas démultiplexer les données client entrantes basées sur une adresse/port du client. Le faire de cette façon est un peu plus efficace (en général) et présente également certains avantages, en fonction de la conception du serveur, car sur le serveur il y a une socket dédiée, ce qui signifie que s'ils font des E/S superposées alors le socket reste le même pour toute la période de communication avec vous, ce qui peut rendre plus facile et plus efficace l'association de données avec le socket (de cette façon ils peuvent probablement éviter les recherches ou le verrouillage pour traiter chaque datagramme). Quoi qu'il en soit, assez de cela (voir here, si vous voulez savoir pourquoi I le faire de cette façon).

De votre point de vue en tant que client (et je suppose que les prises async ici), vous devez d'abord Bind() votre prise locale (il suffit d'utiliser INADDR_ANY et 0 pour permettre à l'OS de choisir le port pour vous) émettre alors un RecvFrom() sur le socket (il n'y a donc pas de course entre vous envoyant des données au serveur sur cette socket et il vous renvoie des données avant d'émettre un recv). Ensuite, émettez un SendTo() au «port bien connu» du serveur. Le serveur vous renverra alors des données et votre RecvFrom() vous renverra les données et l'adresse que le serveur vous a envoyées. Vous pouvez ensuite prendre cette adresse, en ajouter une au port, stocker cette adresse et ensuite émettre SendTo() s à cette nouvelle adresse d'envoi tout en continuant à émettre RecvFrom() s pour lire les données du serveur; ou vous pouvez faire quelque chose de malin avec Connect() pour lier l'extrémité distante du socket à l'adresse 'send to address' du serveur et simplement utiliser Write() et RecvFrom() à partir de là.