IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

[MFC] Thread bloquant et sockets


Sujet :

Threads & Processus C++

  1. #1
    wogkiller
    Invité(e)
    Par défaut [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!

  2. #2
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    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?
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    wogkiller
    Invité(e)
    Par défaut
    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.

  4. #4
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    Attends, tu es en train de me dire que tes nouveaux threads lancés pour chaque client font eux aussi des accept() ??
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  5. #5
    Expert éminent

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Février 2007
    Messages
    4 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2007
    Messages : 4 253
    Points : 7 618
    Points
    7 618
    Billets dans le blog
    3
    Par défaut
    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...
    N'oubliez pas de cliquer sur mais aussi sur si un commentaire vous a été utile !
    Et surtout

  6. #6
    wogkiller
    Invité(e)
    Par défaut
    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

  7. #7
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    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() !
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  8. #8
    wogkiller
    Invité(e)
    Par défaut
    les threads client n'appellent pas accept... c'est le thread qui attend les connexions qui le fait.

  9. #9
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 519
    Points
    41 519
    Par défaut
    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?
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

Discussions similaires

  1. [MFC] thread : erreur bloquante
    Par Joeleclems dans le forum MFC
    Réponses: 4
    Dernier message: 20/05/2005, 13h58
  2. Réponses: 18
    Dernier message: 13/04/2005, 15h46
  3. [MFC] Thread
    Par romeo9423 dans le forum MFC
    Réponses: 2
    Dernier message: 25/03/2005, 14h20
  4. [MFC] Thread & memory leaks
    Par Racailloux dans le forum MFC
    Réponses: 7
    Dernier message: 15/03/2005, 12h44
  5. Réponses: 3
    Dernier message: 11/02/2004, 12h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo