Discussion :

[Zc]

Je suis actuellement en train de développer un serveur TCP/IP (open source) en C#. J'ai consulté pas mal d'aide, parcouru pas mal de code sources et une grande question me vient: Quel concept opter pour application serveur ?
Je m'explique:
* Le socket qui 'écoute' sync dans un thread ou async ?
* Les sockets clients créés en sync ou async ?
* Un thread qui parcourt tous les sockets clients pour savoir si qqun à qqchose à dire ? (avec les sockets en sync et un timeout à 100ms)
* Les sockets clients créés en async et 'parlent' quand ils veulent
* Les sockets clients sont stockés dans un ArrayList, Hashtable, Queue (avec des 'faux' clients pré-créés)
* ... ?

Bref, pas mal de possibilités ... mais laquelle est la plus performante d'après vous ?!
Merci

[Zc]

ok, je vais pose ma question différemment:
j'ai entendu dire, que lorsque l'on développe un serveur, il n'était pas très performant de créer un Thread par client. Pourquoi ?

[vic]

"Serveur TCP/IP" c'est pour le moins vague comme description ...

La puissance de la fonction select() est très souvent sous estimée, et les programmeurs préfèrent choisir des implémentations lourdingues à base de threads et autre fork ... Un seul select peut faire élégament et efficacement tout ce qu'on croit au premier abord ne pouvoir faire qu'avec des threads. Bon c'est mon avis, ça vaut ce que ça vaut ;o)

Si tu veux un exemple de serveur "TCP/IP" performant regarde du côté des sources d'un serveur irc (exemple : http://bahamut.dal.net/).

vic

[Zc]

"Serveur TCP/IP" c'est pour le moins vague comme description

C'était un peu fait pour
Pour l'instant, l'implémentation du protocol n'est pas très important, je voulais surtout parler du concept d'un serveur TCP/IP

Si tu veux un exemple de serveur "TCP/IP" performant regarde du côté des sources d'un serveur irc (exemple : http://bahamut.dal.net/)

Excellent! C'est exactement ce genre de choses que je cherchais
Merci

[Zc]

La puissance de la fonction select() est très souvent sous estimée

hum ... je la connaissais pas celle-là, mais en effet, elle est excellente!
Par contre, il semblerait que parfois, elle renvoie des sockets qui n'ont pas de données en attente (donc l'appel suivant à Receive bloque). Cela peut être facilement testé par un Poll avant le Receive, mais cela oblige de tester tous les sockets retournés.
T'as une autre astuce ?!

[vic]

Oui : la valeur de retour de la fonction indique le nombre de socket disponibles en lecture.

vic

[Zc]

hum ... je récapitule ce que j'ai compris de cette fonction sur MSDN:
je donne en paramètre une ArrayList (car un simple tableau Socket[] a une taille fixe, et il en veut pas) qui contient tous les sockets que je veux tester. Une fois la fonction appelée, ce même ArrayList ne contient que les sockets qui ont des données en attente. Donc je fais un foreach et un Receive à chaque tour.
Que fais-je du nombre de sockets disponibles en lecture là-dedans ?

PS: rappelle moi à l'ocas de te faire un béco et de te payer une bière, mon serveur est carrément transformé grace à la fonction Select!

[Zc]

la function Select renvoie void sur le framework .Net ... de plus, il n'accepte pas plus de 64 sockets ... valeur modifiable dans le fichier Winsock2.h dixit MSDN ... autrement dit, faites du C++
Quelqu'un connait une astuce pour modifier cette valeur en .Net ?

[vic]

Désolé mais en programmation réseau je n'ai d'expérience que sous linux et apparemment le fonctionnement est légèrement différent avec ".Net", je ne peux donc pas t'aider.

C'est quand tu veux pour la bière, pour le bécot on va attendre un peu ;o)

vic