Aide Socket C#

Aujourd'hui je suis au milieu de mon projet et il avance plutôt bien pour la partie client.

Je veux donc mettre au point un jeu flash de gestion de petit personnages et d'espace (tel qu'une ville, ect...) mais en plus vivant avec des petits bonhommes à déplacer. (Style Habbo, mais en mieux).

La partie Flash est faite, j'ai tout mes systèmes qui fonctionnent et tout le reste.

Il y a donc nécessité de "dialogue intensif" avec un serveur socket, en C# ainsi qu'une gestion de "paquet" (référencement des actions). Il me faut donc un serveur pouvant gérer beaucoup de connectés en simultanée, quelque chose pas forcément léger et 100% optimisé mais qui marche. Qui marche plutôt bien !

Quelqu'un aurait des idées à me faire parvenir ? Des script déjà tout fais ? (Voilà 2 semaines que je patoges, je m'en sort pas avec les Async... truc)

Merci de votre aide futur :D

y'a tcplistner

TcpListener n'est pas obsolète ? Oo

à mes connaissance non, les Sockets ne sont pas un très très bonne idée, personnellement j'opte pour les web services. Pour ton cas un Web Service Rest /JSon une bonne idée, tu peux même faire des TCP/IP avec WCF et toujours avec le format de données de ton choix (bytes ).

plus de details ca peux aider.

Ces méthodes la, je n'y accroche pas vraiment et je veux juste me servir du C#.

En tout cas merci de tes réponses !

Citation:

---

Envoyé par azstar

à mes connaissance non, les Sockets ne sont pas un très très bonne idée, personnellement j'opte pour les web services. Pour ton cas un Web Service Rest /JSon une bonne idée, tu peux même faire des TCP/IP avec WCF et toujours avec le format de données de ton choix (bytes ).

plus de details ca peux aider.

---

Tu devrais suivre son conseil :D.

Un webservice ne serait pas une bonne idée pour un jeu en temps réel.

Tu devrais plutôt te poser la question : packets TCP ou UDP ?

Si tu veux un code tout fait , tu peux prendre un peu n'importe quel type de serveur , la structure reste la même :

Code:

---

1 2	Un thread qui écoute les connexions entrantes. Un thread qui update et communique avec les connexions existantes.

---

Tu peux aussi découpé la communication en plusieurs threads mais cela dépends de la puissance de la machine ou sera le serveur.

TcpListener est une bonne option si tu pars sur TCP , ce que je te recommanderai pour ce type de jeu. Tu gardes en mémoire une liste de TcpClient , qui représente tes joueurs et tu leur envoies ce qu'il faut , quand il faut.

Citation:

---

Envoyé par PixelJuice

Un webservice ne serait pas une bonne idée pour un jeu en temps réel.

Tu devrais plutôt te poser la question : packets TCP ou UDP ?

Si tu veux un code tout fait , tu peux prendre un peu n'importe quel type de serveur , la structure reste la même :

Code:

---

1 2	Un thread qui écoute les connexions entrantes. Un thread qui update et communique avec les connexions existantes.

---

Tu peux aussi découpé la communication en plusieurs threads mais cela dépends de la puissance de la machine ou sera le serveur.

TcpListener est une bonne option si tu pars sur TCP , ce que je te recommanderai pour ce type de jeu. Tu gardes en mémoire une liste de TcpClient , qui représente tes joueurs et tu leur envoies ce qu'il faut , quand il faut.

---

Ha bon et en quoi en web service ne serais pas une bonne idée?

Tu ne confondrais pas : moyen d’héberger, protocole et transport?

On peut faire du tcp/ip, udp, pipe en wcf, qu'il soient hébergé par un service local ou en WAS, qui plus est tu peut faire du duplex (websocket par exemple )

Si tu part sur un TCP listener tu réinvente la roue, car WCF te permet de t'abstraire non seulement de la façon d’hébergé, mais également du protocole et moyen de transport, c'est juste la moitié du temps de dev gagné.

Je sis ça, je dis rien.

Citation:

---

Envoyé par PixelJuice

Un webservice ne serait pas une bonne idée pour un jeu en temps réel.

Tu devrais plutôt te poser la question : packets TCP ou UDP ?

Si tu veux un code tout fait , tu peux prendre un peu n'importe quel type de serveur , la structure reste la même :

Code:

---

1 2	Un thread qui écoute les connexions entrantes. Un thread qui update et communique avec les connexions existantes.

---

Tu peux aussi découpé la communication en plusieurs threads mais cela dépends de la puissance de la machine ou sera le serveur.

TcpListener est une bonne option si tu pars sur TCP , ce que je te recommanderai pour ce type de jeu. Tu gardes en mémoire une liste de TcpClient , qui représente tes joueurs et tu leur envoies ce qu'il faut , quand il faut.

---

Voilà !! Tu as absolument tout compris ! :D
Merci aussi aux autres ! ;)

Par contre juste une question: Tu parles bien de ça http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx ??
Si oui, comment mettre en place l'enregistrement des utilisateurs ? :)

Salut

avec les sockets (TCP ou UDP), le principe est simple:

Sur le serveur:

Un thread qui écoute les demandes de connexion et qui sur reception d'une demande, créer un thread de communication avec celui ci.
Un thread (crée lors d'une demande de communication) qui gère la communication entrant avec le client connecté...

Une liste des personnes (IP/ login joueur) connecté..

Ensuite, l'enregistrement (login) du joueur, peut se faire via les échanges que tu fais avec des trames TCP...

Il y a une librairie qui pourrait grandement t'aider... lidgren tcp library... (à chercher sur google)... je pense que cette librairie
te facilitera grandement le taff.


Après, à la question : pourquoi pas les Web services...

Je réponds : parce que le web service n'est pas dans les deux sens... donc, soit le client fait du pooling pour tout le temps demander si il y a des
actions à prendre en compte... soit dans l'appel du web service, on envoie info et on récupère données de suite...

Mais je pense qu'en terme de performance, le web service est un peu plus lent que TCP car les requêtes sont encapsulés avec les données
échangés dans le contrat du web service d'ou beaucoup plus d'info émises sur le réseau que réellement nécessaires..

Citation:

---

Envoyé par theMonz31

Salut


Après, à la question : pourquoi pas les Web services...

Je réponds : parce que le web service n'est pas dans les deux sens... donc, soit le client fait du pooling pour tout le temps demander si il y a des
actions à prendre en compte... soit dans l'appel du web service, on envoie info et on récupère données de suite...

Mais je pense qu'en terme de performance, le web service est un peu plus lent que TCP car les requêtes sont encapsulés avec les données
échangés dans le contrat du web service d'ou beaucoup plus d'info émises sur le réseau que réellement nécessaires..

---

Moi je rebondissait surtout sur le fait d'utiliser WCF.
En WCF tu peux faire du duplex donc communication dans les deux sens.

Ensuite concernant les performances, effectivement même en "tunnant" au maximum WCF tu ne pourra pas atteindre le niveau d'un transport de type pipe, mais vu que de toute façon il va passer par le réseau, donc cet argument n'est pas valide, le plus couteux est surtout la sérialisation et désérialisation ainsi que le cout inéluctable de l'appel (mais ça se joue à 50ms près sur ce dernier point).

Après qu'il fasse du WAS ou local service, qu'il fasse du http, tcp ect.... c'est a lui de choisir, c'est une question de trois lignes de code et d'un Binding WCF.

Et pour être plus crédible je te renvois à la MSDN

Certains jeux font du TCP et de l'UDP.
Utilise TCP pour les données dont il est indispensable de n'avoir aucune perte( données qui sont envoyées de maniere événementielle par exemple)
Utilise UDP pour les données envoyées périodiquement , avec en tête l'idée que ton client ne vas pas en recevoir parfois. Mais comme c'est périodique, il v les récupérer dans quelques demis secondes.

Par exemple si tu fais un FPS tu peux transmettre les couples (position vitesse) des personnes toutes les 300 mes par udp et utiliser TCP pour le chat et les tirs de munition