[Serveur]Multithreading obligatoire pour un serveur ?

Bonjour,

voilà, je me confronte à un problème. J'ai entrepris la programmation d'un serveur. Il comporte différents modules (gestion de connexion, gestion de discussions privées, gestion de discussions publiques,...).

Je voulais savoir si le passage par le multithreading était indispensable ou si l'élaboration d'un programme normal était suffisante ?

Si je désire intégrer un système de transfert constant (son entre deux clients parmi tous les autres par exemple), le multithreading devient-t-il obligatoire ?

Merci d'avance pour vos réponses.

Bonjour,

Le multithreading est préférable (je ne me rappel plus si on peut l'éviter).
Car normalement, l'attente sur le socket de connexion est bloquant, du coup, si on bloque notre serveur sur les attentes de connexion, on ne va pas pouvoir renvoyer les messages que les clients ont voulus échanger.
Après, je crois aussi (je peux me tromper car mon dernier combo client/serveur était en Java) qu'il faut un thread par client.

Tout dépend du nombre de clients, et de l'importance des calculs à faire pour chaque calcul. Il existe d'autres approches que les approches par thread, genre le multiplexage. Tu devrai regarder du côté de boost::asio pour une librairie bas-niveau d'I/O asynchrone qui permet facilement d'écrire un serveur multithréadé ou pas (il y'a différents exemples d'implémentation de serveur http). Une autre ressource intéressante, c'est netlib qui se base aussi sur boost::asio.

1 client / thread, c'est globalement à prohiber, ça scale mal.

Tout d'abord, merci pour vos réponses.

Cependant, j'avais oublié de préciser un petit quelque chose : j'utilise le Framework Qt.

Donc je pense qu'en utilisant les signaux et les slots, je ne devrais pas avoir de problème mais je peux me tromper. Surtout que les clients n'ont pas besoin d'une réponse à la milliseconde près.

Qu'en pensez-vous ?

Bonjour Artifice,

Je ne sais pas quel est l'avancement de votre projet, mais au vu de vos questions, faites un tours du coté des démos de Qt fournis avec le framework (qtdemo.exe), rubrique networking : il y a pas mal d'exemples simples et assez bien foutu.

La rubrique de Qt sur développez est également très riche... n'hésitez à faire un tour.

Citation:

---

Envoyé par zul

Tout dépend du nombre de clients, et de l'importance des calculs à faire pour chaque calcul. Il existe d'autres approches que les approches par thread, genre le multiplexage. Tu devrai regarder du côté de boost::asio pour une librairie bas-niveau d'I/O asynchrone qui permet facilement d'écrire un serveur multithréadé ou pas (il y'a différents exemples d'implémentation de serveur http). Une autre ressource intéressante, c'est netlib qui se base aussi sur boost::asio.

1 client / thread, c'est globalement à prohiber, ça scale mal.

---

Je profite un peu de la discution: que veux-tu dire par "ça scale mal"? Le serveur monte en charge trop vite?

Citation:

---

Envoyé par seeme

Je profite un peu de la discution: que veux-tu dire par "ça scale mal"? Le serveur monte en charge trop vite?

---

Non, juste que ça n'est absolument pas rentable. Il faut confier à un thread un certain nb de clients.
C'est un peu comme si à chaque nouvelle tâche dans une boite tu assignais un employé. Et que tu engageais un employé quand t'en as plus de disponible. Non, tu vas plutôt donner N tâches à faire à chaque employé.

Pour les serveurs, aujourd'hui on utilise pas mal l'approche basée sur epoll & compagnie sinon, mais c'est l'approche bas niveau ça. L'alternative principale, c'est je pense les work stealing queues (je te laisse googler pour en savoir plus).

Citation:

---

Envoyé par Alp

Non, juste que ça n'est absolument pas rentable. Il faut confier à un thread un certain nb de clients.
C'est un peu comme si à chaque nouvelle tâche dans une boite tu assignais un employé. Et que tu engageais un employé quand t'en as plus de disponible. Non, tu vas plutôt donner N tâches à faire à chaque employé.

Pour les serveurs, aujourd'hui on utilise pas mal l'approche basée sur epoll & compagnie sinon, mais c'est l'approche bas niveau ça. L'alternative principale, c'est je pense les work stealing queues (je te laisse googler pour en savoir plus).

---

aujourd'hui il me semble que ce soit les socket asynchrones non bloquant qui sont principalement utilisés voir AIO sous linux ou I/O completion port sous windows