Discussion :

[narkotik]

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?

[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.

[narkotik]

+1
rien de plus les gens ?

[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.

[hansaplast]

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.

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%

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)

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 :'(