sockets asynchrones

Version imprimable

24/07/2006, 13h54
narkotik

UDP/TCP multithreading/sockets asynchrones

voila je me lance, je bosse actuellement sur un projet de jeu video et j'apprends la programmation en C++ win32 avec les sockets et TCP et UDP

voila j'ai pas mal de question à poser par rapport à ce que j'ai remarqué

1/ si je créé 2 instances d'un meme programme qui fait envoie et reception de messages en UDP avec le meme port par ex 1234 et la meme IP donc 127.0.0.1 et en utilisant 1 thread pour les envois et un thread pour les receptions, en gros dans chaque thread y'a une boucle while(1), pourquoi une de mes instances receptionne ses propres messages et ceux envoyés par l'autre, et pourquoi l'autre instance n'arrive pas à recevoir ses propres messages et ceux de la première? (j'ai malheureusement pas de 2ème pc sous la main la)

2/ les threads c'est bien gentil mais ca me pompe toutes mes ressources processeur, y a-t-il un moyen de coder ca de maniere a ce que ca "bouffe" moins? comme un MSN ou un jeu réseau(ex: half-life, quake3 et compagnie, ...) comment c'est gérer dans ces programmes?

3/ j'ai vaguement lu sur les sockets asynchrones, ca a l'air intéressant car ca "bouffe" beaucoup moins de puissance processeur, vu que c'est un evenement windows qui dit quand un message a été recu et qu'il faut le traiter. ok ! mais j'ai aussi vu sur gamedev que des fois y'a un mini-plantage et que ca renvoit une erreur et qu'il faut attendre en moyenne 750ms avant de pouvoir réenvoyer ou rerecevoir, quelqu'un a des infos dessus? des expériences ? j'ai cru ainsi comprendre qu'il fallait mieux faire un systeme de threads sur le serveur et de sockets asynchrones sur le client, mmh si ca marche si bien que ca pourquoi ne pas le faire sur les 2? les sockets asynchrones sont-elles utilisables aussi avec UDP(j'ai testé TCP et ca marche)?

4/ il me faut un systeme ou je peux actualiser mes positions de joueurs par UDP toutes les 30ms (40ms=la perception de l'oeil donc c'est impec) et qui envoie par TCP les informations importantes(ex: un objet qui a été ramassé). handicap, il faut que ca prenne le moins de ressources processeur possible et que ce soit fiable, des idées? conseils? expériences? quelqu'un sait comment marche le systeme sur tel ou tel jeu?
24/07/2006, 14h04
Médinoc

Eh bien, les sockets asynchrones sont très intéressants, et je ne sais rien sur le coup des 750ms, mais pour moi, l'inconvénient des sockets asynchrones est qu'ils ne peuvent pas (du moins, je ne sais pas faire) être asynchrones en réception et bloquants en envoi. Résultat, je ne crois pas qu'on puisse envoyer en asynchrone des données plus grandes que le buffer d'envoi du socket (8 ko sur les versions de Windows que j'avais testées).
Bref, tu ne devrais pas avoir de problème pour un t'chat, mais pour quelque chose de gros j'ai des doutes.
24/07/2006, 16h38
narkotik

+1
rien de plus les gens ?
24/07/2006, 22h06
loufoque

L'utilisation de sockets asynchrones est mieux mais rend plus compliqué le code.

Regarde du côté de asio (qui sera disponible dans boost 1.35)
C'est conçu pour les sockets asynchrones, et tu peux en plus utiliser du multithreading.
25/07/2006, 11h35
hansaplast

Citation:

Envoyé par narkotik

1/ si je créé 2 instances d'un meme programme qui fait envoie et reception de messages en UDP avec le meme port par ex 1234 et la meme IP donc 127.0.0.1 et en utilisant 1 thread pour les envois et un thread pour les receptions, en gros dans chaque thread y'a une boucle while(1), pourquoi une de mes instances receptionne ses propres messages et ceux envoyés par l'autre, et pourquoi l'autre instance n'arrive pas à recevoir ses propres messages et ceux de la première? (j'ai malheureusement pas de 2ème pc sous la main la)

Le port sert a indiquer a quel programme windows doit envoyer les données recues, il ne peut les envoyer a deux programme (ou 2 instances d'un meme programme), meme s'ils partagent lememe port.
la solution : si tu ne peut que passer par le localhost, et bien choisit deux ports differents par instance.

Citation:

2/ les threads c'est bien gentil mais ca me pompe toutes mes ressources processeur, y a-t-il un moyen de coder ca de maniere a ce que ca "bouffe" moins? comme un MSN ou un jeu réseau(ex: half-life, quake3 et compagnie, ...) comment c'est gérer dans ces programmes?

aucune idée, mias plus que les trheads, ca doit etre ton programme qui bouffe toutes les ressources. regarde, preque n'importe quel jeu "recent" monte l'utilisation du CPU a 100%

Citation:

3/ j'ai vaguement lu sur les sockets asynchrones, ca a l'air intéressant car ca "bouffe" beaucoup moins de puissance processeur, vu que c'est un evenement windows qui dit quand un message a été recu et qu'il faut le traiter. ok ! mais j'ai aussi vu sur gamedev que des fois y'a un mini-plantage et que ca renvoit une erreur et qu'il faut attendre en moyenne 750ms avant de pouvoir réenvoyer ou rerecevoir, quelqu'un a des infos dessus? des expériences ? j'ai cru ainsi comprendre qu'il fallait mieux faire un systeme de threads sur le serveur et de sockets asynchrones sur le client, mmh si ca marche si bien que ca pourquoi ne pas le faire sur les 2? les sockets asynchrones sont-elles utilisables aussi avec UDP(j'ai testé TCP et ca marche)?

un systeme de trhead coté serveur te permet de gérer plusieures connexions clientes de facon tres aisée, si ton serveur n'accepte qu'une seule connection, ce n'est peut etre pas la peine de t'embéter (la gestion des thread complexifie le programmation : mutex et autre...)

les socket asynchornes permettent, entre autre, de ne pas bloquer ton GUI, lorsque tu est en attente de paquets. (du moins sous WxWidgets)

Citation:

4/ il me faut un systeme ou je peux actualiser mes positions de joueurs par UDP toutes les 30ms (40ms=la perception de l'oeil donc c'est impec) et qui envoie par TCP les informations importantes(ex: un objet qui a été ramassé). handicap, il faut que ca prenne le moins de ressources processeur possible et que ce soit fiable, des idées? conseils? expériences? quelqu'un sait comment marche le systeme sur tel ou tel jeu?

heu... en LAN, c'est peut etre gérable, mais, sur internet, le ping (la latence, et donc, le temps de reception) monte souvent au dessus de 100... c'est donc a rpendre en compte.

enfin, pour ce qui est du format de l'envoi de donnée, a toi de voir, analyse ce que tu doit envoyer :
la taille des paquets est elle fixe?
peut tu codifier certaines données sur un BIT (et donc en envoyer un max par buffer)
...

bonne chance, et, sache que je suis un peu noob, donc, ce que 'jai dit n'est pas forcement juste... dsl :'(