Probleme de read() bloquant sur un socket.

Version imprimable

Voir 40 message(s) de cette discussion en une page

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:

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.

Je pense qu'il te manque le traitement de fermeture du socket

Code:

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;

14/04/2008, 10h03
Médinoc

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().
14/04/2008, 12h48
gregb34

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.
14/04/2008, 12h51
loufoque

Ç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...
14/04/2008, 13h22
gregb34

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() ?
14/04/2008, 13h34
loufoque

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.
14/04/2008, 13h45
gregb34

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.
14/04/2008, 15h42
loufoque

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
14/04/2008, 16h04
gregb34

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.
14/04/2008, 17h11
ram-0000

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.
14/04/2008, 17h18
gregb34

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.
14/04/2008, 18h25
ram-0000

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
14/04/2008, 19h08
gregb34

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...
14/04/2008, 19h11
ram-0000

Dans le GET non mais dans la réponse au GET faite par le serveur : si
14/04/2008, 19h34
gregb34

Mon problème depuis le debut, concerne le traitement du GET envoyé par le client...

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:

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

14/04/2008, 22h46
gregb34

Je vais regarder de plus pres cette longueur max... car sinon, je vais encore me retrouver dans une situation bloquante lors du lire().
14/04/2008, 22h54
gregb34

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.
15/04/2008, 01h23
loufoque

Citation:

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.

Voir 40 message(s) de cette discussion en une page