Version imprimable
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!
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.
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.Citation:
Envoyé par skeud
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à.
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.
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?
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".Citation:
Envoyé par skeud
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/#LIXCitation:
Envoyé par skeud
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 ?Citation:
Envoyé par Bousk
@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.
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.Citation:
Envoyé par Iradrille
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.
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).Citation:
Envoyé par http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM
C'est pas lié directement à l'évitement de la congestion du coup.
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;
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.
Il le fait exactement comme pour le reste et toutes les appli réseau du monde : en utilisant send/sendto :weird:Citation:
Envoyé par mamad88