Discussion :

[mamad88]

Bonjour à tous,
Je veux réaliser un service de messagerie avec les sockets en C++ décrit ci dessous:
Un Client envoie un message au serveur et le serveur renvoie ce message à tous les autres clients qui sont dans le même canal de communication .
Ceux ci est à faire en utilisant le protocole UDP.
Comment le serveur pourrait savoir les clients qui utilisent un même canal de communication sachant que je suis en UDP?
Dois je utiliser le Multicast?
Cordialement!

[Bousk]

Salut,

UDP ou pas, il te faut "juste" faire un "vrai" serveur, et son code.
Si par channel tu entends les canaux de discussion, c'est à toi de gérer applicativement où se trouve les clients.

[skeud]

Je rejoinds un peu 'lavis de mamad88, si on est en UDP, comment le serveur connait-il les clients qui sont connectés?

si j'ai bien compris l'UDP, la socket ouverte pour la communication lors de l'envois du client vers le serveur est à sens unique et périssable non?
Donc le serveur ne connait que les clients qui se sont connectés, et ne peut communiquer avec eux en retour non?

[Iradrille]

Je rejoinds un peu 'lavis de mamad88, si on est en UDP, comment le serveur connait-il les clients qui sont connectés?

si j'ai bien compris l'UDP, la socket ouverte pour la communication lors de l'envois du client vers le serveur est à sens unique et périssable non?
Donc le serveur ne connait que les clients qui se sont connectés, et ne peut communiquer avec eux en retour non?

Çà se gère au niveau applicatif : quand un client envoi un message (au sens large, ça peut être une demande pour rejoindre un channel par exemple), son IP et le port utilisé sont communiqués au serveur. Çà suffit à l'identifier et à lui répondre.
Maintenant vu qu'il n'y à pas de connexion en UDP, on peut imaginer un système de keep-alive : les clients envoient toutes les x sec un message indiquant qu'ils sont toujours là.

[Bousk]

On appelle ça "connexion virtuelle" http://jeux.developpez.com/tutoriels...connexion-UDP/
Le mode connecté du TCP s'émule de façon très correct, c'est typique en jeu-vidéo.

En gros c'est du keep-alive (1/s) pour garder le port ouvert de part et d'autre.

Btw, un serveur de chat en UDP c'est pas la meilleure idée, à fortiori si on maîtrise pas UDP. UDP c'est pas anodin et directement beaucoup de travail en plus, pour gérer les (dé)connexions entre autre.

[skeud]

ah ok, donc en gros, on simule la connexion TCP via un système de keep alive en envoyant un message toute les X milliseconde afin de garder le port de connexion ouvert vers le serveur. Ce qui permet au serveur de pouvoir répondre sur cette socket tant que le client lui notifie qu'il vit.

@mamad88, le fait de faire un serveur de chat de cette manière ressemble un peu à un exercice de cour, tu confirmes?

@Bousk:
De mémoire, dans le jeu vidéo, on utilise deux connections:
_ Une pour les messages de haute importance en TCP (action de tir, notification de mort ...).
_ Une pour les messages de moindre importance en UDP (maj des positionnement, chat ....).
Tu confirmes?

De la même manière on pourrait imaginer un serveur de chat fonctionnant sur ce principe, l’envoi des message en UDP et la notification de changement de salon/connexion/déconnexion en TCP non?

[Bousk]

ah ok, donc en gros, on simule la connexion TCP via un système de keep alive en envoyant un message toute les X milliseconde afin de garder le port de connexion ouvert vers le serveur. Ce qui permet au serveur de pouvoir répondre sur cette socket tant que le client lui notifie qu'il vit.

Oui, envoyer un message permet de garder le port ouvert pour recevoir la réponse, en "floodant" suffisament, mais pas trop pour ne pas encombrer la bande-passante, on garde une "connexion".

@Bousk:
De mémoire, dans le jeu vidéo, on utilise deux connections:
_ Une pour les messages de haute importance en TCP (action de tir, notification de mort ...).
_ Une pour les messages de moindre importance en UDP (maj des positionnement, chat ....).
Tu confirmes?

De la même manière on pourrait imaginer un serveur de chat fonctionnant sur ce principe, l’envoi des message en UDP et la notification de changement de salon/connexion/déconnexion en TCP non?

Il n'y a aucune règle absolue, mais c'est une mauvaise idée de vouloir mélanger TCP et UDP, et surtout de vouloir utiliser les deux en même temps http://jeux.developpez.com/tutoriels...-UDPvsTCP/#LIX

[Iradrille]

Il n'y a aucune règle absolue, mais c'est une mauvaise idée de vouloir mélanger TCP et UDP, et surtout de vouloir utiliser les deux en même temps http://jeux.developpez.com/tutoriels...-UDPvsTCP/#LIX

J'ai entendu dire que mélanger TCP et UDP était une mauvaise idée en particulier pour les problèmes de congestions : TCP prend ça en compte, pas UDP. Est-ce la raison de perte de packets ? Ou le problème vient d'autre part ?

@skeud, si jamais tu mélanges TCP et UDP, les notifications de tirs doivent à priori être transmises par UDP. Si on utilise pas TCP c'est pour la latence, et clairement les notifications de tirs ne peuvent pas attendre.
TCP serait plus pour les échanges d'objets entre joueurs (ou entre NPC et joueurs) par exemple ou éventuellement une confirmation pour les notification de tirs; mais généralement si on utilise UDP soit osef des packets perdus (streaming) , soit on implémente un système de validation des données et on renvois les packets perdus -> dans ce cas TCP est inutile; on implémente seulement ce qu'on à besoin de TCP.

[Bousk]

J'ai entendu dire que mélanger TCP et UDP était une mauvaise idée en particulier pour les problèmes de congestions : TCP prend ça en compte, pas UDP. Est-ce la raison de perte de packets ? Ou le problème vient d'autre part ?

Regarde la série d'articles que j'ai citée, ceux déjà traduits abordent ça, et en particulier le dernier lien direct que j'ai mis.
La perte c'est aléatoire, incontrôlable. Ca vient de la ligne, de la machine, de la carte, j'en sais rien, de partout, mais c'est là. On estime ~5% de perte en général.
Les problèmes de congestion sont pas vraiment liées à la perte. Mais la perte peut être une conséquence de la congestion. C'est ta carte qui refuse d'envoyer plus d'infos, ou d'en recevoir plus. TCP le gère en interne, et entraîne de la latence, UDP le gère pas du tout, et se contente de drop le paquet.

[Iradrille]

First, we focused on the case in which only TCP connections use all of the bandwidth of the network. In particular, when network delays of connections are the same, all TCP congestion window sizes change in a synchronized manner (i.e., TCP synchronization). In these cases, the queue length of bottleneck node buffer evolves in a periodic way, and can stay full or almost empty for a relatively long duration.

Second, we treated the case in which UDP streams are added to the TCP synchronization case. UDP packet loss occurs more often and successively in the TCP synchronization case. This is because the TCP synchronization can make the node buffer full for a relatively long duration repeatedly and periodically. Even if the node is filled with packets, UDP packets are still transmitted constantly and must be dropped successively. Therefore, the UDP stream suffers harmful effects of the TCP synchronization.

Donc ça serait lié au fait que TCP a tendance à remplir les buffers et donc à forcer la suppression des packets UDP (pas de place pour les recevoir).
C'est pas lié directement à l'évitement de la congestion du coup.

[mamad88]

Il s'agit d'un projet semestriel à rendre ,on nous demande de le faire just avec UDP.
J'ai des soucis sur la manière dont le serveur va renvoyer un message déjà reçu aux autres du canal;

[ternel]

En as-tu discuté avec tes professeurs?
Ils ne vous ont tout de même pas abandonnés sur le problème, ca serait un manque cruel de pédagogie.

[Bousk]

J'ai des soucis sur la manière dont le serveur va renvoyer un message déjà reçu aux autres du canal;

Il le fait exactement comme pour le reste et toutes les appli réseau du monde : en utilisant send/sendto