Discussion :

[blabla33]

Bonjour,

je voudrais savoir quel serais le type de socket qui serai le plus adapter
à un partie serveur capable en théorie de supporter 1000 connecté.

Je comptai aussi faire un thread par client, est ce une mauvaise idée ?

Merci d'avance de vos réponses.

En vous remercient.

[Pol63]

system.net.sockets.*
ou wcf
ou .net remoting

les 3 doivent supporter des milliers de connexions
un thread par client moi ca me choque pas ...
sur les socket de base de toute façon il y a des méthodes asynchrones qui doivent correspondre à un thread en attente

[kzrystof]

1 Thread par client ? Ne crée pas explicitement un Thread à chaque client qui se connecte car je crois me souvenir que ça prends quelque chose une stack de 1MB par Thread. Si c'est le cas, fais le calcul: 1000 threads = 1000 MB = 1GB.

J'imagine que tu pourrais avoir quelques Threads utilisés pour le traitement (nouvelle connexion, réception et envoi de messages). Le reste proviendra des Threads IO du ThreadPool grâce aux méthods asynchrones de la classe Socket (BeginWrite, BeginRead).

[cs_ntd]

1MB par Thread ca parait beaucoup, mais c'est certain qui suivant la machine, ca pourra prendre pas mal de ressources, mais je voyais plutot ca du coté du CPU...

Pour savoir quoi faire, il faut déja savoir si les Clients ont besoins d'etre en interraction permanente avec le serveur, ou si au contraire, il est possible de les mettres en attente, et de mettre en place un systeme de Queue, de file d'attente.

[kzrystof]

Voici l'article:
http://msdn.microsoft.com/en-us/libr...74(VS.85).aspx

[cs_ntd]

En effet

Ceci, dit on est d'accord sur le fait que, éviter 1000 threads d'un coup, c'est mieux . Problème, on a pas toujours le choix...

[Pol63]

je viens de faire une appli qui créé 500 threads, elle prend 30Mo de ram
sans le démarrage des threads je suis à 8Mo de ram
donc certes ça prend un peu de ram, mais ca reste ridicule ...

[swif79]

Question ça ne risque pas d'être couteux en CPU (basculement de context) ?

[Pol63]

tout dépend ce qu'on fait avec les threads et comment on gère les pauses

m'enfin je ne suis pas sur qu'il y a débat à faire ici, ca reste à vérifier car je n'ai pas appronfondi les sockets en .net mais ce que j'ai cru en comprendre, c'est que quand un client se connecte, il faut créé un nouveau listener, donc avoir un listener par client
et sur un listener pour avoir de l'asynchrone on fait .beginreceive en fournissant un callback qui tombera sur un thread séparé

ce qui voudrait donc dire que même si on ne fait pas un thread par socket soit même le framework le fait de toute façon ...