Il me semble qu'UDP est en effet tout indiqué pour ce genre de protocole. La plupart des jeux l'utilisent, la plus notable exception étant il me semble WoW, que les spécialistes confirment. Son principal défaut (et également avantage au final) étant qu'il n'assure pas l'ordre d'arrivée des paquets, ni même le fait qu'ils arrivent tout court. À partir de là, deux approches s'imposent :
- Gérer à la main (bas niveau) les paquets. Si le jeu envoie x mouvements du joueur par seconde, ajoute un horodatage au paquet : peu importe qu'ils arrivent (ou pas) dans l'ordre, le serveur ignore les paquets antérieurs au dernier reçu. Peu importe qu'il en manque, c'est l'avantage principal d'UDP face aux problèmes de lag qui font de TCP un protocole peu adapté. Par contre, pour les informations importantes qui ne peuvent être ignorées (discussion pendant une partie par exemple), tu peux mettre en place un système ou le client renvoie les données tant qu'il n'a pas reçu d'accusé de réception. Je crois me souvenir que Quake 2 (lu dans le code de Warsow) fonctionnait comme ça, avec des reliable commands. Tu peux peut-être t'inspirer de http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0(...) . Sinon qui sait, tu pourrais peut-être coder le serveur en Erlang ;-).
- La solution facile selon certains, sage pour d'autre : réutiliser une des multiples bibliothèques pré-existantes. Tu n'as que l'embarras du choix, du plus bas au plus haut niveau : http://jonatkins.org/SDL_net/ SDL_net, http://www.opentnl.org/ OpenTNL, http://www.hawksoft.com/hawknl/ HawkNL ou encore http://www.rakkarsoft.com/ RakNet. En moins orienté jeu, il y a aussi le mastodonte (intéressant, mais un peu overkill pour quelque chose de plus petit qu'un MMOG) : http://zeroc.com ICE. J'avais regardé les uns et les autres, et je pense que dans ton cas RakNet serait approprié.
# this is not a title
Posté par super_mario . En réponse au journal Rendre un jeu jouable en réseau. Évalué à 10.
- Gérer à la main (bas niveau) les paquets. Si le jeu envoie x mouvements du joueur par seconde, ajoute un horodatage au paquet : peu importe qu'ils arrivent (ou pas) dans l'ordre, le serveur ignore les paquets antérieurs au dernier reçu. Peu importe qu'il en manque, c'est l'avantage principal d'UDP face aux problèmes de lag qui font de TCP un protocole peu adapté. Par contre, pour les informations importantes qui ne peuvent être ignorées (discussion pendant une partie par exemple), tu peux mettre en place un système ou le client renvoie les données tant qu'il n'a pas reçu d'accusé de réception. Je crois me souvenir que Quake 2 (lu dans le code de Warsow) fonctionnait comme ça, avec des reliable commands. Tu peux peut-être t'inspirer de http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0(...) . Sinon qui sait, tu pourrais peut-être coder le serveur en Erlang ;-).
- La solution facile selon certains, sage pour d'autre : réutiliser une des multiples bibliothèques pré-existantes. Tu n'as que l'embarras du choix, du plus bas au plus haut niveau : http://jonatkins.org/SDL_net/ SDL_net, http://www.opentnl.org/ OpenTNL, http://www.hawksoft.com/hawknl/ HawkNL ou encore http://www.rakkarsoft.com/ RakNet. En moins orienté jeu, il y a aussi le mastodonte (intéressant, mais un peu overkill pour quelque chose de plus petit qu'un MMOG) : http://zeroc.com ICE. J'avais regardé les uns et les autres, et je pense que dans ton cas RakNet serait approprié.