Comme précisé un peu plus haut, je n'ai pas forcément de grosses compétences en dev réseau, j'aurais donc quelques questions sur tes suggestions :)
- quel est l'avantage de epoll sur select ? j'avoue ne pas du tout connaitre epoll. "man epoll" m'a juste dit que c'était spécifique linux et que ça avait l'air "moderne".
- au moment du recv, j'ajoute le flag MSG_DONTWAIT pour que justement la lecture ne soit pas bloquante, après il y a surement un moyen de le faire au niveau de la socket directement...
- heu... tu veux dire avec des fork et/ou threads ? sinon je ne vois pas ce que tu entends par "sockets asynchrones"
- pareil qu'à la suggestion précédente, lecture de fichiers asynchrone => fork/thread ? en tout cas, tu as totalement raison, si un client se met à lire un gros fichier, les autres vont pleurer à côté
- pour la dernière suggestion, oui, ça serait en effet mieux que je ne laisse pas le serveur travailler pour rien
Et sinon, oui, j'aimerais bien rester en pur C et sans trop de dépendances, ça donne un côté super viril au truc.
[^] # Re: Suggestions
Posté par Guillaumito . En réponse au journal Gophrier 0.1. Évalué à 4.
- quel est l'avantage de epoll sur select ? j'avoue ne pas du tout connaitre epoll. "man epoll" m'a juste dit que c'était spécifique linux et que ça avait l'air "moderne".
- au moment du recv, j'ajoute le flag MSG_DONTWAIT pour que justement la lecture ne soit pas bloquante, après il y a surement un moyen de le faire au niveau de la socket directement...
- heu... tu veux dire avec des fork et/ou threads ? sinon je ne vois pas ce que tu entends par "sockets asynchrones"
- pareil qu'à la suggestion précédente, lecture de fichiers asynchrone => fork/thread ? en tout cas, tu as totalement raison, si un client se met à lire un gros fichier, les autres vont pleurer à côté
- pour la dernière suggestion, oui, ça serait en effet mieux que je ne laisse pas le serveur travailler pour rien
Et sinon, oui, j'aimerais bien rester en pur C et sans trop de dépendances, ça donne un côté super viril au truc.