[Sockets/Thread] Comment faire passer une trame reçue vers un autre thread ?

Bonjour,

Tout d'abord, excusez moi si c'est le nième post du même sujet que je poste là...

La situation est la suivante : j'ai un serveur recevant et émettant des trames via les sockets. Je ne vais pas entrer dans les détails sur le contenu de ces trames. Ce que je souhaite est que le serveur traite la trame qu'elle reçoit en parrallèle de la réception d'une autre trame. Bref, un serveur capable d'être multitâche quant à la réception et au traitement de données.

Le problème est que je n'arrive pas à fabriquer un thread externe qui boucle sur la réception et qui envoie la trame reçue au programme qui le traite.

Le programme, dès son lancement, initialise le socket qui se met à boucler pour lire. Au moment où une trame arrive, ce thread le redirige vers le programme MAIS au lieu de continuer sa boucle, le thread est bloqué jusqu'à la fin du traitement ! Comment couper ça ? Existe-t-il une possibilité de passage de paramètres inter threads ?

En vous remerciant de votre aide qui me servirait :)

Regarde du côté de la méthode ThreadPool.QueueUserWorkItem. Elle te permet de créer un nouveau thread qui exécutera la méthode indiquée en paramètre. Si ton problème se limite à la création de threads cela devrait suffir :)

Sinon fait une petite recherche sur le forum, il y a eu pas mal de sujet sur les threads ces 6 dernières semaines.

il n'y a pas de vrai paramètrage au thread, sauf en utilisant les delegate paramètrés mais dans ce cas adieu la pool de thread...

Le mieux est de faire une classe qui effectue le traitement. Dans cette classe tu prend en paramètre du constructeur la trame à traiter, et ce constructeur va soit créer un thread indépendant

Code:

---

1 2 3 4 5 6 7 8 9 10 11

... Thread thd = new Thread(Traitement); thd.Start(); ...   private void Traitement(void) { ... } ...

---

soit sur le meme principe tu prend un thread de la pool pour fair le job.
disons que l'intérêt des threads de la pool c'est qu'ils sont générallement déjà créés au moment où tu les appels ce qui fait que tu gagne du temps... maintenant si nombre de trames arrivent simultannément tu peux te retrouver dans un effet de "famine" si tous les threads de la pool sont occupés, ce qui peut te polluer plus qu'autre chose... (il est possible de règler la pool pour avoir plus de thread préconstruit/initialisés)

c'est à toi de voir...

ensuite, générallement il n'est pas souhaitable qu'un serveur soit en attente blocante sur la socket d'écoute. Il est donc conseillé de la mettre elle meme dans un thread séparé ou d'utiliser les méthodes asynchrones des classes sous jacentes, celles ci utilisent des threads pour résoudre le probleme de l'attente blocante.
cela permet à ton programme principal de faire autre chose pendant que l'écoute est faite et que les trames sont traitées.
tout dépend de ce que fait ton serveur, de ce que tu peux rencontré comme cas ...

Si tu prend un serveur sur le modele de protocole que j'ai développé, bloquer le thread principal sur l'écoute est impossible, car le serveur doit de lui meme prendre l'initiative d'appeler d'autres serveurs, faire le ménage dans sa mémoire, profiter d'un manque d'activité, pour faire le ménage dans ses caches et virer ce qui ne lui sert plus, refaire d'autre calculs, sauvegarder son état mémoire régulièrement pour éviter les mauvaises surprises et faciliter la séquence de redémarrage ...

Ensuite, il est générallement pour un serveur plus "logique" d'en faire un service windows, qui n'a pas de vrai thread principal, car il est peut probable que ton service fasse toujours quelque chose... quand il attend une connexion, il ne fait rien, il dort... le système le reveille quand une activité sur la socket est détectée.
là l'utilisation de Timers (System.Timers.Timer de préférence plutot que System.Threading.Timer et surtout pas System.Windows.Form.Timer)
est pratique, pour lui dire de faire d'autres opérations de maintenance... de controles...


Tu les initialisent dans le OnStart() et tu met également toute lé mécanique