Discussion :

[deripaske]

Bonjour, je développe une application de vidéo conférence en c++.
La communication entre le client et le serveur se fait en utilisant UDP.
J'aimerais savoir comment est il possible pour un serveur d'identifier un client avec le protocol UDP vus qu'en UDP il n'y a pas d'établissement de connection?
Car la tache du serveur c'est d'envoyer un flux aux clients via la socket en utilisant UDP, alors le serveur doit savoir à qui envoyer les données, genre addresse ip et port des clients.
Quelqu'un a t-il une idée comment faire cela en utilisant le protocole UDP?

[Melem]

- Le serveur est censé toujours être à l'écoute des clients.
- Chaque client est censé connaître l'adresse du serveur
- Un client peut envoyer un message tel que "Bonjour" (à adapter selon ton protocole) au serveur pour informer celui-ci de sa présence.
- La communication peut démarrer

[deripaske]

Un client peut envoyer un message tel que "Bonjour" (à adapter selon ton protocole) au serveur pour informer celui-ci de sa présence.

Après avoir eu le Bonjour d'un client, j'aurai l'addresse IP et le PORT de ce client, mais le hic est que l'addresse et le port en question pourraient être aussi celui d'un pare feu qui a traduit l'addresse et le port d'origine du client(translation NAT). Alors je me demande si le client ne sera pas obligé d'envoyer un "Bonjour" au serveur à chaque fois qu'il veut recevoir des données, ce qui dans mon cas sera quand même dramatique coté performance.

[ram-0000]

Ton serveur recoit les information d'adresse IP et de port qui proviennent de la pile IP de ta machine. Cette adresse et ce port sont éventuellement modifié par un firewall/NAT.

Ton serveur parlera à l'adresse publique de ton client et le firewall/NAT fera l'inverse et remettra l'adresse et le port privé, pas de problème, c'est comme cela que ca marche.

Par contre, il ne faut ABSOLUMENT pas que tu inscrive dans ton protocole applicatif (au dessus de UDP donc) des information d'adresse Ip ou de numéro de port. Car si tu fais cela, le dispositif de translation ne connaissant pas ton protocole ne fera pas de translation applicative.

regarde le chapitre 5 de Introduction aux réseaux TCP IP, j'en parle un peu.

[Mac LAK]

En dehors de l'adresse IP elle-même, tu peux aussi identifier les clients via leur port source (le port destination étant bien entendu fixe et imposé par le serveur) : lors de la réception d'une trame de "connexion" (le "bonjour", si tu préfères), le serveur mémorise le port et l'adresse IP pour alimenter le client, et lui retourne si besoin les informations nécessaire à la réception des données.

Une autre solution, mais qui n'est utilisable que sur un LAN, est de passer tes trames UDP en diffusion (broadcast ou multicast) : dans un tel cas, le serveur diffuse les informations et ce sont les clients qui sont à l'écoute sur un port donné. Toutefois, ça peut éventuellement plomber sévèrement le réseau d'entreprise, et tu te doutes bien qu'on ne peut pas faire un broadcast UDP sur Internet...

Ma solution préférée est hybride : on établit deux connexions parallèles. La première, en TCP/IP, ne sert qu'à connecter un client, servir de keep-alive et éventuellement de circuit de contrôle. C'est par cette connexion que tu vas transmettre les informations nécessaires à la communication UDP, et tu maintiendras la connexion active en envoyant régulièrement une trame bidon juste pour dire que t'es vivant. Pour ma part, j'aime bien envoyer des stats en guise de keep-alive, cela permet aussi de détecter les stalls de communication et de vérifier la qualité des transmissions. De plus, suivant la complexité du protocole (ou la tolérance aux pannes) que tu veux implémenter, tu peux également te servir de la connexion TCP/IP pour modifier à la volée la configuration de la connexion, comme par exemple le codec utilisé ou des indicateurs de présence / absence des divers participants.

Le flux "lourd" est alors bien sûr transmis par UDP tel que tu l'as déjà prévu.

Avantage : on sait directement quand un client se connecte, et surtout, quand il se déconnecte (évite de laisser le serveur envoyer des données pour rien).
Inconvénient : il faut maintenir deux sockets par client et les synchroniser. Je ne saurais trop te conseiller d'encapsuler tout ça dans une structure de communication dédiée, qui ouvrira directement les sockets nécessaires et ne retournera à l'appelant (côté serveur comme côté client) qu'une fois les DEUX connexions établies et vérifiées.

En gros, pour prendre une analogie avec un driver, les read / write sont faits via UDP, tandis que les ioctl et le open/close sont faits via TCP/IP.

[khelifa19]

dans ton cas le ieux est d'utiliser un serveur STUN et un NAT (non symetrique)
ca devrai marché tu aura tjrs les infos sur le serveur et le client enregistré