Bon, il faut faire comme on t'as dit. si tes socket son bloquantes en lecture, tu vas devoir lire les données octet par octet et attendre qu'un double retour chariot se présente. une fois détecté, ton serveur pourra interpréter la requête, la traiter, renvoyer la réponse et couper la connection avec le client.
Mais, bon, pour un serveur web, ou tout autre type de serveur d'ailleurs, je te conseille de faire la gestion des entrées sorties en mode non bloquant. premier avantage, tu va pouvoir lire jusqu'à ce que la socket te renvoit un message EAGAIN, et ce que tu as lu, tu le stocke dans un buffer.
Ensuite, il ne te reste plus qu'à lire ton buffer, et trouver un double retour chariot. s'il n'y en a pas, tu devra attendre que d'autres données arrivent... et ainsi de suite...c'est plus performant.
Pour savoir s'il y a quelque chose à lire dans une socket, y a select() (le seul qui soit presque portable), sinon sous linux, je te conseille vivement epoll(), qui fait des merveilles...
[^] # Re: Ben...
Posté par ecyrbe . En réponse au message Les Sockets, et la taille en reception. Évalué à 1.
Mais, bon, pour un serveur web, ou tout autre type de serveur d'ailleurs, je te conseille de faire la gestion des entrées sorties en mode non bloquant. premier avantage, tu va pouvoir lire jusqu'à ce que la socket te renvoit un message EAGAIN, et ce que tu as lu, tu le stocke dans un buffer.
Ensuite, il ne te reste plus qu'à lire ton buffer, et trouver un double retour chariot. s'il n'y en a pas, tu devra attendre que d'autres données arrivent... et ainsi de suite...c'est plus performant.
Pour savoir s'il y a quelque chose à lire dans une socket, y a select() (le seul qui soit presque portable), sinon sous linux, je te conseille vivement epoll(), qui fait des merveilles...