Discussion :

[ixabro]

Bonjour,

pour vous mettre dans le contexte, mon groupe et moi même devons réaliser un jeu vidéo en langage C# dans le cadre d'un projet scolaire. Nous avons décidé d'utiliser XNA.
Les moteurs graphique et physique du jeu sont déjà bien entamés.

Nous voudrions que les joueurs puissent y jouer en réseau. Nous sommes conscients que cela implique un minimum de connaissances dans la programmation réseau.
Pour vous donnez un apercu de ce que nous voulons programmer, disons que nous aimerions réaliser une interface serveur-client où les joueurs pourraient choisir de se connecter à tels ou tels serveurs, chaque serveur réprésentant une map et ayant une capacité de 10 joueurs maximum.
D'après mes recherches sur internet, il faudrait un socket connexion par serveur vu le nombre réduit de joueurs par serveur et un socket écoute unique. Apparement dans le cas d'un MMO il faudrait utiliser un socket par client. A cela s'ajoute les threads dont je pense avoir trouvé assez de documentation la dessus.

De plus, nous avons récément fait la découverte du procédé de sérialisation. Nous comptons utiliser la sérialisation binaire pour faire transiter nos objets (players, etc...) à travers le réseau.
Le soucis c'est que nous sommes totalement débutant dans le domaine du réseau, j'aurais aimé avoir plus de documentation concernant la pratique de la sérialisation binaire + réseau.

Même après avoir lu plusieurs docs, je butte encore au niveau des sockets avec les threads. Je ne sais absolument pas quelle structure de programmation, nous allons suivre pour mener à bien notre interface. Le nombre de sockets qu'il faut utiliser pour celle-ci dans le cas des serveurs et des clients, reste abstrait pour moi.

Enfin, je suis tombé sur des tutoriels threads, sockets et autres mais je n'ai pas trouvé d'articles alliant l'utilisation des sockets&threads dans le cadre d'un jeu.
Où alors je cherche mal. Quoiqu'il en soit si vous pouviez me mettre sur la voix ça serait vraiment une bonne chose pour nous.

Merci à ceux qui lisent ce message.

[Underflow]

Dans le cadre d'un serveur, il faut obligatoirement mettre à disposition autant de sockets que de client connectés, ainsi qu'un socket listener pour permettre au serveur de recevoir les connexions. Le listener va écouter le port, et rediriger les connexions vers un autre socket qui prendra le relais, afin de laisser le listener libre.

Le multithreading est quand à lui nécessaire du fait que les fonctions des sockets (listen, send, ...) sont bloquantes. Si ton programme est mono-thread, lorsque le listenner attend une connexion, rien d'autre ne pourrait s'executer. Ainsi, on dispatche chaque socket sur un thread séparé, ce qui implique nb_connectés + 1 thread.
Le truc cool en l'occurence c'est que .net prémache le truc, et fournit des sockets dits asynchrones, càd où les fonctions ne sont pas bloquantes et s'executent sur un autre thread. Tu n'as pas à te soucier de ce problème.

Pour ce qui est de la serialisation binaire, c'est un moyen pour envoyer les trames réseau mais qui est pas forcement très optimisé (tel que tu l'annonce, tu risque déjà d'envoyer plus d'infos que nécessaire).


Pour la partie client, un socket suffit dans le cas où tu n'as qu'une seule connexion à établir (le chat est souvent décentralisé sur les serveurs de MMO', pour eviter de bouffer les perfs du serveur de jeu).



Le net c'est p'tit en fait...

[gangsoleil]

Le multithreading est quand à lui nécessaire du fait que les fonctions des sockets (listen, send, ...) sont bloquantes. Si ton programme est uni-thread, lorsque le listenner attend une connexion, rien d'autre ne pourrait s'executer. Ainsi, on dispatche chaque socket sur un thread séparé, ce qui implique nb_connectés + 1 thread.

Non.

Oui c'est bloquant, mais non tu n'es pas oblige de passer ton temps a attendre sur chacune, et non, tu n'es pas oblige d'avoir un thread par socket plus un thread pour la master-socket (celle qui ecoute s'il y a de nouvelles connexions). Il est tout a fait possible de faire un serveur mono-thread qui gere plusieurs clients, et ca se fait meme beaucoup.
Et si tu as de tres nombreux clients et que tu multi-thread, tu auras de bien meilleures performances en ayant un pool de sockets dont le nombre est proportionnel a ton nombre de coeurs/processeurs qu'en ayant autant de sockets que de clients.


Il te suffit d'utiliser select() (c'est une fonction C, mais je suis certain qu'il existe un equivalent dans d'autres langages), qui te retourne la liste des sockets sur lesquelles quelque chose est arrive depuis la derniere fois. Si c'est la socket principale, c'est qu'un nouveau client est arrive, et si c'est une autre ,c'est que tu as des donnees a lire dessus, ou bien que la connexion a ete coupee.

[Underflow]

Ah autant pour moi, je viens de découvrir le select. Niveau perfs par rapport au parallélisme ça donne quoi ?

[gangsoleil]

Niveau perfs par rapport au parallélisme ça donne quoi ?

Ca depend du nombre de sockets a gerer, et de la quantite de donnees transferees : pour quelques sockets qui ne transferent que de temps en temps, et un programme qui ne fait pas du calcul intensif, tu ne verras pas la difference.
Et a l'inverse, si tu as un tres grand nombre de connexions, un pool de threads qui s'occupent chacun de plusieurs sockets via le meme principe sera beaucoup plus performant que d'avoir un thread par socket.

[extony]

Bonjour,
qui peut m'aider a trouver une application de gestion pour un réseau adsl svp?
comme gestion de priorité par exemple ou n'importe.

Merci!!!