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?