Discussion :

[docteur_re]

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

[Spoutnik]

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.

Est ce que la garantie d'arrivée des paquet est importante ? Est ce que le client est capable de positionner "l'emmetteur" même si il n'a pas la position précédente. Si oui, tu t'en "fout" de la garantie de livraison(si faible perte )

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.

je percute pas trop ce que tu veux faire

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 ?

ca s'appelle du TCP (+/-). à toi de répondre à la question du 1) : est ce que tu as BESOIN d'être sur que tes paquets sont bien arrivés ou est il plus important que le transfert soit le plus rapide possible quitte à avoir de la perte au passage.

++ et bon courage, c est pas facile ces pb de temps réel.

[Matthieu Brucher]

Je pense que la première stratégie est la meilleure, mais ce n'est que mon avis.

[zul]

Dans la partie 2, je pense qu'il veut faire du polling. Attendre d'avoir recu un certain nombre d'evenement / un certain temps avant d'envoyer toutes ces informations en une seule fois. A mon avis, une solution peu pertinente pour un "temps reel".

Comme dit precedemment, le probleme de 1 est qu'on n'est pas sur que les evenements arrivent et / ou qu'ils arrivent dans l'ordre ( ce qui peut-etre embetant ) On peut se retrouver "hors terrain" si les deplacements n'ont pas lieu dans le bonne ordre.

La solution 3 ressemble a celle utilisé dans des jeux tel que q3. C'est je pense un bon compromis mais il faut une bonne implémentation ( donc difficile ).

[pier*]

Au passage je crois qu'une partie du netcode de quake 3 est open source.

[fearyourself]

C'est un faux problème. Passe en TCP et regarde si le réseau n'arrive pas à le supporter. Généralement, cela marchera correctement et tu auras plus de temps pour programmer ton jeu...

Si c'est bien programmer, le jeu ne saura pas ce qui se passe dans le module Réseau donc le passage TCP -> UDP pourra se faire sans que cela change quelque chose dans le reste du programme...

Mais sinon, je pencherais aussi pour le 1
Jc