Reprise du message précédent :
supposons qu'il aura traduit de lui même

ok merci pour ces precisions, je vais me renseigner sur poll !
 
et oui je suis sur windows   mais bon je v chercher la doc sur google !
 
sinon pour info si je rajoute un SDL_Delay de 20 ms ou meme de 1s ca ne me mange plus du tout le processeur  

utilise select. Mettre des delay ça fonctionne, sauf que si tu reçois des données, tu dois attendre la fin du délai, là ou select va se réveiller tout de suite.

les delays c'est le mal

pour avoir programmer des applications réseaux, je ne comprends pas déja pkoi tu utilises le mécanisme de sérialisation JAVA, c'est bcp plus lent, donc de ce coté la, je me démerderait pour envoyer des bytes sur le réseaux afin de ne pas le surcharger.  
 
Ensuite, au niveau de ton C++, je ne comprends pas trop pkoi ton accept n'est pas blocant, pas défaut il l'est, je suppose donc que tu as surement reconfigurer la socket pour qu'ellene le soit pas. Regarde donc de ce coté la.

C'est bizare le coup du lag réseau en Java. Mais une régle d'or en développement client/serveur, c'est de n'envoyer que ce qui est utile. Même si je n'ai jamais vérifié la taille d'un objet java sérialisé, je suis sur que c'est beaucoup plus grand que 5 int (les 4 int normaux plus le cinquiéme pour envoyer les deux boulléen en un octet)
 
De plus, l'utilisation d'un buffer en arrivé ou en sortie de flux peut faire perdre plusieurs secondes. Dans ma premiére applis réseau en java, je regardais le nombre d'octet disponible dans le buffer du flux réseau ce qui était une erreur vu que la fonction n'en indiquait qu'une fois le buffer sufisament remplis. (la lecture directe dans le flux avec un timeout a corrigé complétement le probléme)
 
Autre erreur à éviter : l'utilisation d'une fonction bloquante d'envoie de donnée à l'intérieur d'une boucle d'envoie. Si t'envoie normalement toutes les 20 ms et que tu as un ping de 60 ms, tu risques de te retrouver à n'envoyer les données que toutes les 80 ms.
Autre détail, le serveur ne devrait pas envoyer des données aux clients quand il en recoit, mais devrait en envoyer à intervale régulier en plus des envois servant à répercuter les changements. Ca permettra aux clients de se remettre à jour s'il y a eu un coupure temporaire dans le reseau (un paquet est si vite perdu des fois)