[UDP] temps-réel dans un jeu - stratégie à adopter ?

bonjour a tous,

imaginons le cas de figure suivant :

j'ai 2 programmes, client et serveur.
- le premier écoute les evenements d'un joystick et envoie les coordonées des axes par UDP au second
- le second les reçoit et les utilise.

l'udp est utilisé afin de garantir une transmission temps réèl (comme dans les jeux en réseau style FPS)

mon seul probème est de savoir quelle stratégie adopter pour envoyer ces paquets. Voici celles que j'ai envisagées :

1 - Les envoyer simplement avec un sento() à la suite les unes des autres, à chaque réception d'un evenement joystick. Mais cela ne permet pas de garantir que la dernière coordonnée est arrivée.

2 - Envoyer en permanence avec un sleep de 5 millisecondes les coordonnées joystick. Un peu bourrin et surtout pourquoi 5 millisecondes et pas un autre nombre, cela dépendrait de la qualité du réseau.

3 - Envoyer les coordonées avec un identificateur unique, puis attendre une réponse avec ce meme identificateur pour en renvoyer un autre. Oui mais si la réponse ne reviens jamais, le programme se bloque. On peut alors penser à un timeout à partir duquel les coordonnées sont réémise. Et encore une fois, quelle valeur pour ce timeout ?

voilà, j'ai pas d'autres idées pour le moment. En fait jaimerais bien m'inspirer des jeux existant genre counter-strike, ou ceux open-source pour aller voir comment ils procèdent.
Si certain ont déjà eu l'occasion de travailler sur le problème....

Merci
bye

C'est pour ca que a mon avis, envoyant les coordonnées des axes n'est pas suffisant. Tu peux pas plutot directement envoyer une position ou une donnée mieux définie de facon à ce que meme si une trame disparait, la suivante permet un rafraichissement correcte.

luhtor : dans ce cas je peux très bien renvoyer à intervale régulier les coordonnées des axes, ca reviens au même qu'une position. 2ème choix dans ce que j'ai écris.

Gendal67 : Je connais bien TCP et j'ai d'ailleurs commencé par implémenter ce protocole pour faire ça, mais le problème est que c'est super lent. En fait oui les paquets non-reçus sont automatiquement re-transmis et remis dans l'ordre, de façon transparente. Mais celà implique une entete beaucoup plus longue qu'en UDP, ainsi que de devoir attendre les données pour les classer (et en gros plein d'autres trucs couteux en temps).

J'ai fait des tests là, et en UDP c'est vraiment plus rapide. En fait je dois utiliser un réseau tout pourri (GSM), c'est pourquoi je ne peux pas utiliser TCP pour du temps-réel. Et pour counter-strike les developpeurs ont surement eu le même raisonnement. Enfin de toute façon en règle générale TCP n'est pas prévu pour du temps réel c'est à dire streaming vidéo, audio, jeux temps-réel, etc...
Pour info le DNS fonctionne en UDP car TCP serait bien trop lourd et surchargerait les serveurs.

En tout cas merci pour le lien, jvai lire ça bien à fond et jte tiens au courant de l'évolution, pas de souci ;)

bybye

bon
après une lecture assidu de cet article, super interressant d'ailleurs, j'en ai conclu qu'il faut utiliser la méthode 2, c'est à dire envoyer en permanence toutes les x millisecondes. Cette valeur devant être determinée en fonction de :
1 - la taille de chacun des paquets
2 - la bande passante
de façon a éviter le 'choke' (voir article) c'est à dire qu'un nouveau paquet commence à être envoyé tandis que le précédent n'a pas encore fini d'etre envoyé. (ce qui crée un retard dans les envois qui augmente à chaque fois)

je ne pense pas utiliser la numérotation étant donnée qu'elle ne sais qu'à calculer le nombre de paquets perdus, information peut utile dans mon cas. Quoique ça peut servir si en réception 2 paquets sont inversés, on prend en compte que le premier et on laisse tomber le 2ème.

je part en phase testing ;)