[MFC] Thread bloquant et sockets

Bonjour,

Je vous explique mon problème :
J'ai une application en c++ non managé utilisant les MFC. Cette application peut, sous certaines conditions, instancier des client ou serveur tcp/ip (qui dialogue avec d'autres appli en c# ou c++). Avec le client, aucun problème, les threads se lancent, et le dialogue avec le serveur(en c# ce coup-ci) se fait bien.
Par contre, lorsque je créé un serveur, l'affichage de l'application se fige... impossible d'avoir une intéraction avec, alors que si je reçoi un mesage sur le reseaux, il sera traité!

pour bien clarifier tout ça, je vous donne quelques détails d'implémentation du serveur :

mon serveur utilise les winsock en mode connecté. après le new pour créer un nouvel objet serveur, j'appel la méthode start(). Cette derniere lance le serveur (tcp/ip, socket(), puis bin(), puis listen() ) et lance un thread qui attend les connexions des clients (avec la fonction accept() ). Pour chaque client qui se connecte, je créé un autre thread qui lui sera dédié. Ce nouveau thread lance un nouveau serveur qui se me en attente de la connexion du client, puis envoi le numéro de port du nouveau serveur au client, qui s'y connecte.

Bref, c'est compliqué comme fonctionnement, mais je l'ai déjà fait en c# et cela fonctionne très très bien, le multithread me permet d'avoir une appli qui supporte des montées en charge énorme.... par conter en c++ l'affichage ne répond plus dès que mon thread contenant le accept() du serveur principal est lancé.

une explication? Que la, j'ai vraiment plus d'idée... j'ai m^me essayé d'utiliser le composant serveur (en c#) via une dll COM. Ca me fait le m^me problème, l'affichage se fige :'(

please, HELP!

J'ai du mal à comprendre.
Qu'appelles tu "se met en attente de la connexion du client" ?
Juste "faire un recv() bloquant" ou bien repartir sur une attente de connexion ?

Que fais-tu après avoir lancé ton thread qui fait les accept ?
Es-tu sûr de ne pas lui avoir passé de pointeur malheureux vers un objet du thread principal, un objet qui ne serait pas fait pour le multithread?

PS: Si j'ai bien compris, ton application utilise MFC mais pas les sockets MFC?

attente de connexion d'un client => accept()

sinon, j'utilise les winsocks, parce que ça se fait facilement. Le problème, c'est que mon accept() bloque l'affichage de mon application...
La méthode qui appel mon thread se termine juste après le lancement du thread, et c'est une méthode d'un objet serveur créé dans mon XXXview.cpp de mon appli principale.

Attends, tu es en train de me dire que tes nouveaux threads lancés pour chaque client font eux aussi des accept() ?? 8O

Oui... moi aussi j'ai du mal à comprendre....

On dirait que wogkiller crée un nouveau socket (et un nouveau thread) pour chaque connection entrante !
Donc.... 1000 clients = 1 socket (listen) + 1000 sockets (tcp-connect du accept principal) + 1000 threads + 1000 sockets (listen des nouveaux threads) + 1000 sockets (tcp-connect des nouveaux threads) ?

Je ne vais rien dire sur les threads, tant qu'on est pas vraiment critique au niveau rapidité de réponse, on peut éventuellement penser à créer un thread par connection, même si la solution du pool est nettement plus adaptée.
Par contre question socket, je comprends vraiment pas... Qu'est ce qui empêche d'utiliser le tuyau initial ?

Sinon... oui accept() est bloquant (puisqu'il doit créer/renvoyer le nouveau tuyau). Mais il est possible de vérifier qu'une connection est en attente de la même manière qu'on vérifie que des données sont en attentes dans un tuyau...

je fais effectivement un thread par client, mais il utilise le socket principal pour dialoguer.
Par contre, tu pourrais m'expliquer vite fais le pool stp? Que je vois pas bien ce que tu entends par là.

merci

J'ai du mal à comprendre ton programme et le raisonnement derrière.
Normalement, les threads client n'ont pas besoin d'appeler la fonction accept() !

les threads client n'appellent pas accept... c'est le thread qui attend les connexions qui le fait.

Il faut savoir ce que tu dis alors.
Tu confirmes donc qu'il n'y a qu'un seul thread qui attend des connexions, contrairement à ce que tu as dit plus haut?
Les autres threads ne font qu'attendre des données sur des connexions existantes?