Gérer correctement l'UDP

[Crone123]

Bonjour,
Voilà, donc j'ai un problème un peu ennuyeux, j'ai un jeu qui utilise TCP et UDP sur un port défini.
Le problème, c'est que ça empêche la possibilité de créer plusieurs serveurs sur une seule machine.
J'ai donc rajouté la possibilité de choisir le port.
En TCP, aucun problèmes.
J'ai donc essayé de me passer de l'UDP, mais impossible, la masse de donnée (a raison de 1Socket toutes les 0.2 ou 0.5s seulement) fait complètement planter le jeu, et les échanges TCP qui fonctionnaient jusque là se retrouvent buggués.
Exemple, en combat tour par tour, l'échange de donnée prends beaucoup de temps alors que je suis en local et que ça prends normalement moins d'une demi seconde et les clients répetent plusieurs fois la même action parce qu'ils ne reçoivent plus correctement les données, et pour finir a la fin du combat je découvre qu'un des 2 joueurs ne peut même plus échanger de données (en rapport avec le problème de socket dont j'ai déjà parlé? Surcharge? → J'ai bien trouvé un bug là dessus pourtant dans mon précédent sujet..).
Bref.

Donc voici mon problème:
Je voudrais ouvrir un port UDP fixe sur le serveur de jeu, jusque là, pas de problèmes.

Ensuite, le problème est du coté client: J'aimerais que le client puisse recevoir des données en UDP sans que j'aie besoin d'ouvrir de ports sur le routeur (comme en TCP). Je suppose que c'est possible puisque les jeux comme Red Eclipse ou Nexuiz (et tous les autres quelque soit l'OS) doivent utiliser l'UDP vu la masse de données qu'ils ont a envoyer et sans avoir besoin de configurer de ports sur le routeur, c'est pas pratique pour le joueur.

J'ai regardé du coté de l'UPNP si c'était faisable, mais je n'arrive pas a l'utiliser et j'ai l'impression de me tromper de voie puisque les jeux comme Red Eclipse ne l'utilisent pas. (Source: Panneau de config de ma Freebox)

Est ce que quelqu'un pourrait m'expliquer comment permettre au client de récupérer des données sans ouvrir de port sur son routeur?
Existe t-il un moyen de se connecter a un serveur comme en TCP pour ne pas avoir besoin de faire ça?
Est t-il possible de recevoir des données coté client sans écouter de port (comme en TCP coté client)?
Merci

[Laurent]

A ma connaissance ce n'est pas possible, pour UDP il faut forcément ouvrir le port au niveau du routeur, que ce soit manuellement ou automatiquement avec uPnP.

Ce n'est pas seulement une question d'ouvrir/fermer : tous les ordinateurs de ton réseau local ont la même adresse IP publique, il faut donc que le routeur sache vers quel PC en particulier router les paquets qui arrivent, et ceci s'effectue grace au port. Avec TCP il n'y a pas de problème car il y a une connexion qui est explicitement ouverte par le client ; une fois que c'est fait le "tuyau" est ouvert dans les deux sens.

[Crone123]

La SFML ne permet pas d'ouvrir un port UPNP?
Merci

[Laurent]

Non.

[Crone123]

OK, je vais faire mes tests.
Et je vais aussi essayer le réseau sur d'autres bibliothèques (Qt ou boost) pour voir si j'ai les mêmes erreurs qu'avec la SFML, si j'ai les même erreurs le problème viens de moi, si j'ai pas d'erreurs ou pas les mêmes c'est qu'il y a des bugs dans la SFML.
Je vous tiens au courant

→ Parce que ça m'étonne quand même que Nexuiz et Red Eclipse (pour ne citer qu'eux) fassent passer tout le jeu par TCP uniquement et que moi quoi que je fasse avec le module réseau de la SFML j'ai a chaque fois des surcharges ou des plantages complets.

[Laurent]

Il n'y a pas de bug connu dans cette partie de SFML. Si tu as des surchages c'est que tu transfères trop de données, si tu as des plantages c'est que ton code est buggé

[Crone123]

C'est bizzare pourtant, j'ai des surcharges en transférant moins de 3ko/s en TCP et le socket qui ne fonctionne plus pour n'importe quelle raison. (TCP ou UDP)
Mon code est peut être buggué je ne dis pas, mais je sais par expérience (et par ce que j'ai montré dans un autre sujet) que en fonction des PC on ne peut pas transférer beaucoup de données d'un coup avec un sf::Packet, exemple, mon ordi (pourtant puissant), si le socket dépasse env 8ko le socket plante. (Il ne transfère plus aucune données et est pourtant connecté)
Mon autre ordi, c'est env 40ko si mes souvenirs sont bons.

Je vais faire des tests pour voir, mon code est peut être effectivement buggué si j'ai les mêmes problèmes sur une autre bibliothèque c'est que le problème viens a coup sur de mon code, mais j'en ai pas encore la preuve....

[Crone123]

J'ai trouvé un truc intéressant:
J'apprends a utiliser boost en plus de la SFML, ça pourra toujours me servir.
Et j'ai connecté un socket de boost sur mon serveur de jeu utilisant les sf::Packet.
Donc, je peux voir la quantité de données envoyée au client par le serveur en fonction de ce que je fais en jeu.
(et par hasard, parce que mon programme boost ne "sait" que récupérer des données et les afficher [je ne sais pas vraiment faire plus avec boost])
Il considère le sf::Packet comme une suite de trame non finie, une chance donc puisque je peux récupérer les trames et compter leurs taille, les données ne sont affichées dans mon terminal qu'à la fermeture du serveur.)
Je me répète, mais c'était pas prévu a la base, c'est un pur hasard, je ne pensais même pas que la communication fonctionnerais puisque les sf::Packet ont leurs propre moyen de communication non standard.

Bref.
J'ai donc vu que lorsque qu'un client entrait en combat sur un serveur il créait un bug et envoyait en continu sa position sur le serveur alors qu'il ne doit normalement pas.
Conclusion: La surcharge était bien due a un bug de ma part (oubli de reset d'un sf::Clock et ça bug..)
Maintenant je n'ai pas testé si j'ai d'autres bugs, mais le bug venais a priori de là.
Donc, fausse alerte pour la surcharge, si j'ai d'autres problèmes de ce type avec le réseau je posterais toujours on ne sait jamais (et de toutes façons mes erreurs postées sur le forum pourront toujours servir a quelqu'un d'autre)
Merci

[christophedlr]

En fait c'est parfaitement logique. Les sf::Packet on leur propre fonctionnement mais c'est un fonctionnement interne. Au final, c'est toujours l'API du système qui est utilisé, donc la base est commune.

Ensuite comme c'est une communication réseau, c'est toujours des communications de socket à socket, donc au final c'est dans le respect des protocoles standard (ici l'UDP), donc tu peux tout à fait avoir un fonctionnement interne d'un côté, et un fonctionnement interne différent de l'autre cela ne gène pas.

C'est comme si tu fais un programme client en Delphi, un serveur en C++ ou même l'inverse. La structure interne est différente, mais le protocole est identique donc ça fonctionne nickel.

En fait la seule exigence entre client et serveur, c'est que chacun utilise les même Data Package. C'est à dire que si l'un transmet des données suivant un format et un codage, il faut que l'autre soit capable de décoder les données et puisse à son tour coder et transmettre suivant le format attendu par le premier c'est tout.