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

C++ Discussion :

Probleme de read() bloquant sur un socket.


Sujet :

C++

  1. #1
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut Probleme de read() bloquant sur un socket.
    Bonjour,

    Je suis en train de créer un petit serveur HTTP et j'ai un probleme lors de la lecture des requetes des clients...

    J'ouvre bien un thread a la connexion d'un client, dans ce thread, je dois lire la requete effectué par le navigateur.

    Je fais donc un :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
        char buffer[100];
        int lecture;
     
        do{
            lecture = read( _fdClient, buffer, sizeof(buffer));
            if ((int)sizeof(buffer)>lecture){
                buffer[lecture] = 0;
            }
            cout << buffer << endl;
        }
        while(lecture>0);
     
        cout <<"Fin de la requete"<<endl;
    "Le fin de requete" ne s'affiche jamais !!! Pourtant quand le serveur a tout lu, le read devrait me renvoyer 0 et ce n'est pas le cas. Une idée ?

    Merci de votre aide.

    PS : Apres un peu plus de recherche, il semblerait que le read soit bloquant, ne souhaitant pas rendre mon socket non bloquant que faire pour contourner ce soucis ?

    Je pourrais tres bien mettre un char buffer[4096] pour tout lire d'un coup et encore, si la requete est plus grande, je peux pas le gérer....

    Une solution pour gérer tous les cas ? MERCI à vous.

  2. #2
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Par défaut
    Je pense qu'il te manque le traitement de fermeture du socket
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    for(;;)
    {
    char buffer[100];
       int lecture = read( _fdClient, buffer, sizeof(buffer));
       if(lecture == 0)
       {
          // erreur de lecture
          break;
       }
       if(lecture == -1)
       {
          // autre erreur de lecture
          break;
       }
     
       if((int)sizeof(buffer)>lecture)
       {
          // pourquoi pas mais si tu lis exactement 100 octets
          // le caractère 0 final ne sera pas positionné
          // et tu risques d'afficher n'importe quoi
          buffer[lecture] = 0;
       }
     
       // traitement du buffer recu
       cout << buffer << endl;
    }
     
    // traitement de la fin de la requete
    cout <<"Fin de la requete"<<endl;
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

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

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Note: Si jamais tu veux être compatible avec Windows, utilise recv() plutôt que read() sur un socket. Si ton programme est seulement destiné aux systèmes POSIX, tu peux garder read().
    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.

  4. #4
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Merci pour vos précisions, cepdant, cela ne résout pas mon problème.

    Lorsque j'ai lu toutes les données, le read n'a plus rien à lire est devient bloquant en attendant de nouvelles données à lire.

    Je crois que je vais être obligé d'enlever la boucle et de tout lire d'un coup en limitant les requetes a 4096 octets.

  5. #5
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Ça te renvoit 0 quand la socket est fermée.
    Sauf que bon, si tu fais un serveur HTTP, le client t'envoie les données, tu les lis, tu écris la réponse, et ensuite tu fermes la socket (ou pas, si tu fais du keep-alive).

    Bref, lis la RFC avant de vouloir implémenter un protocole...

  6. #6
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Je lis les données et je lui réponds : OK

    Tu as lu mon problème et mes hypotheses non ? Comment veux tu que j'emette une réponse si je reste bloqué par le read() ?

  7. #7
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Il faut que tu apprennes comment HTTP fonctionne.
    Pour savoir où le contenu en entrée se termine, il faut lire l'entête "Content-Length" ou décoder le "Transfer-Encoding: chunked".
    (Le client doit d'ailleurs faire la même chose en keep-alive)

    Vouloir écrire un serveur HTTP alors que tu n'as aucune compréhension de comment fonctionne celui-ci, ou pire, de comment fonctionnent les sockets, est aberrant.

  8. #8
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    J'ai pas la prétention de vouloir ecrire Apache, c'est juste un projet scolaire... Faut se calmer...

    Quand j'affiche la requete d'un client qui se connecte, j'ai que ça, je vois pas les informations dont tu me parles.

    GET / HTTP/1.1
    Host: localhost:8888
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: fr-fr,fr;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive

    A noter que je l'affiche avec un seul read et un buffer[4096] ce qui est lobjet de mon probleme pour l'instant.

  9. #9
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    C'est une requête sans donnée en entrée, comme d'ailleurs toute requête GET. Les données en entrée c'est essentiellement pour POST (PUT et OPTIONS aussi, mais tu t'en fous, tu vas sûrement pas les implémenter).
    Ça ne fournit ici que des entêtes, comme tu peux le constater.

    Le format c'est
    TypeDeRequete Request-URI HTTP/Version<CR><LF>
    Entete-1: valeur1<CR><LF>
    Entete-2: valeur2<CR><LF>
    ...
    Entete-n: valeurn<CR><LF>
    <CR><LF>
    <données, le cas échéant>
    <fin de transmission>

    pour le retour, la première ligne change, elle indique un code de retour. (HTTP/Version Code Texte<CR><LF> il me semble)

    Quand il y a des données, les entêtes doivent donner son type, et éventuellement la taille des données, pour savoir jusqu'où lire avant de répondre. Si la taille n'est pas fournie, le chunked doit être utilisé.
    À noter qu'il n'y a pas de chunked en HTTP 1.0.

    Et ce, que ce soit pour l'entrée ou la sortie.
    Tout cela est clairement expliqué dans la RFC (partie 4), que tu devrais connaître presque par cœur si tu veux faire un serveur HTTP.

    Je te donne le lien, au cas où t'aurais du mal :
    http://www.faqs.org/rfcs/rfc2616.html

  10. #10
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Je te remercie mais la requete reste de taille variable et je comprend pas le lien avec le read(). J'aurais beau lire jusqu'au <CR><LF><CR><LF> qui marquera la fin de la transmission, j'aurais toujours le read() qui sera bloqué en attente de nouvelles données à lire...

    Au stade ou j'en suis, c'est même pas un probleme de protocole, peut importe, j'ai l'impression qu'on se comprend pas. c'est juste d'arriver à lire des données entrantes sur mon socket et une fois que j'ai lu ce qui m'interesse, je passe à autre chose et dans mon code, le read() étant bloquant, je ne peux pas passer à autre chose. Je suis continullement en train d'attendre des données à lire et c'est ça qui me derange.

  11. #11
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Par défaut
    Je pense que ce qu'il veut dire (et je le rejoins) c'est que les données que tu reçois doivent avoir en début de trame un indicateur de la longueur des données à lire.

    Ainsi, quand tu fais ta réception, tu lis d'abord la longueur puis les données à concurrence de cette longueur (ou d'une fermeture de socket) et après, tu traites toutes tes données reçues.

    Ce "protocole" doit être respecté par l'émetteur qui doit préparer la trame à envoyer, émet d'abord la longuer de la trame et ensuite la trame.

    Le format de la longueur de la trame est ton problème, cela peut être du binaire, du texte, ce que tu veux, mais il faut que les deux (émetteur et récepteur) s'entendent.
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  12. #12
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Je veux bien, mais dans le cas présent, je lance mon serveur...

    Je vais sur http://localhost:port/ et je récupère ce que j'ai posté ci-dessus avec un buffer[4096]. C'est pas moi qui crée l'entete, c'est le client, en l'occurence mon navigateur...

    Il y a aucune autres infos... Si je fais un buffer[100] et je boucle sur read(), c'est bloquant et je peux rien faire d'autre.

  13. #13
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Par défaut
    Si, il faut alors que tu respecte le protocole HTTP

    Tu lis tant que tu ne trouves pas le mot clé "Content-Length" et après ce mot clé, tu trouve la longueur des données à lire
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  14. #14
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Dans le cas d'un GET, et lorsque le client envoie une requete, il n'y a pas de Content-length ...

    CF ce que j'ai posté au dessus...

  15. #15
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Par défaut
    Dans le GET non mais dans la réponse au GET faite par le serveur : si
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  16. #16
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Mon problème depuis le debut, concerne le traitement du GET envoyé par le client...

  17. #17
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Par défaut
    OK, je pense que je viens de comprendre ton pb

    Une requete GET est formé par :
    HEADER
    <CR><LF>
    DATA

    HEADER est une succession de lignes non vides terminées par <CR><LF>
    de la forme Nom: Valeur et suivi par une ligne vide aussi terminée par <CR><LF>
    Il est possible de trouver des données supplémentaire après le header. Dans ce cas, il y a un tag Content-Length positionné dans le header

    Maintenant, les RFC 1945 et 2616 doivent quelquepart définir la longeur max d'une ligne. En tout cas, je pense qu'il va falloir que tu les lises et les comprennes

    Donc dans ton cas, un algo ressemblerait à cela
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
     
    header = vide
    for(;;)
    {
       lire socket
       ajouter ligne lue en fin de header
       rechercher si dans header on a marque de fin de header "<cr><lf><cr><lf>"
       si oui, break
       si non, continue
    }
    data = vide
    rechercher dans header si on a tag "Content-Length"
    si oui
       lire data supplémentaires
    fin si
    traiter header et data
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  18. #18
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Je vais regarder de plus pres cette longueur max... car sinon, je vais encore me retrouver dans une situation bloquante lors du lire().

  19. #19
    Membre confirmé
    Inscrit en
    Février 2006
    Messages
    197
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 197
    Par défaut
    Trouvé sur le site Microsoft :

    NOTE: les spécifications HTTP n'indiquent pas la taille maximale des champs de demande, de ligne ou en-tête.

    http://support.microsoft.com/kb/260694

    Et d'apres mes recherches GOOGLE, c'est le serveur qui determine ce qu'il accepte ou pas.

  20. #20
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Je te remercie mais la requete reste de taille variable et je comprend pas le lien avec le read(). J'aurais beau lire jusqu'au <CR><LF><CR><LF> qui marquera la fin de la transmission, j'aurais toujours le read() qui sera bloqué en attente de nouvelles données à lire...
    Ben non.
    Une fois que t'as lu <CR><LF><CR><LF> ben t'as fini de lire les entêtes. Tu les analyses, tu lis les données si y'a des données à lire, puis tu génères ta réponse en conséquence.
    À aucun moment tu dois bloquer. Le protocole est pas si mal conçu que ça, quand même.

    Après, si tu sais pas utiliser tes fonctions de gestion des sockets pour faire ça, c'est autre chose.
    Le plus simple pour ce genre de protocole c'est d'avoir un genre de read until <CR><LF> avec un buffer de taille variable. Ce genre de chose est bien sûr possible avec Boost.Asio.

Discussions similaires

  1. ReadLine bloquant sur un socket
    Par Hellnino18 dans le forum Entrée/Sortie
    Réponses: 12
    Dernier message: 17/03/2009, 10h37
  2. Probleme sur un socket
    Par jerome.fortias dans le forum C#
    Réponses: 3
    Dernier message: 20/08/2008, 13h29
  3. [Socket] Comment casser un read bloquant ?
    Par ramislebob dans le forum Entrée/Sortie
    Réponses: 6
    Dernier message: 01/08/2007, 08h15
  4. Lecture non bloquante sur plusieurs Sockets avec nio
    Par ratakses dans le forum Entrée/Sortie
    Réponses: 9
    Dernier message: 19/04/2007, 16h14
  5. Réponses: 3
    Dernier message: 20/10/2006, 19h50

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