Le serveur concurrent
Les quatre modèles de serveur (itératif, un processus par client, un thread par client ou une réserve de threads, multiplexage avec select), la récolte des fils, la fermeture des descripteurs et les limites de chaque modèle.
- 32 cartes
- 5 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Sur la frise
- Mises en situation
Quelques cartes du deck
Serveur itératif : de quoi s'agit-il ?
Voir la réponse
Serveur qui traite un client de bout en bout avant d'accepter le suivant, les autres attendant dans la file.
Il est le plus simple à écrire :
accept, servir,close, recommencer. Un client lent ou silencieux bloque tout le monde.Un serveur itératif sert un premier client, qui reste connecté sans rien envoyer. Un second client se connecte. Que constate-t-il ?
- Sa connexion aboutit, mais le serveur ne lui répond qu'après le départ du premier
- connect échoue aussitôt avec « Connection refused », puisque le serveur est déjà occupé
- Le serveur sert les deux clients à tour de rôle
- Le second client prend la place du premier
Voir la réponse
Sa connexion aboutit, mais le serveur ne lui répond qu'après le départ du premier
Le noyau termine la poignée de main et range la connexion dans la file de
listen. Mais le programme n'appelleacceptqu'après avoir fini le premier client : le second attend. Voilà la faiblesse du modèle itératif.Dans un serveur à un processus par client, le fils ferme la socket d'… et le père ferme la socket ….
Voir la réponse
Dans un serveur à un processus par client, le fils ferme la socket d'écoute et le père ferme la socket du client.
Chacun ferme ce qu'il n'utilise pas. Sinon le père accumule les sockets des clients jusqu'à « Too many open files », et la connexion d'un client ne se termine jamais vraiment.
Serveur concurrent : de quoi s'agit-il ?
Voir la réponse
Serveur qui prend en charge plusieurs clients à la fois, sans attendre qu'un client ait fini avant de répondre à un autre.
Trois façons de l'obtenir : plusieurs processus, plusieurs threads, ou un seul fil qui surveille tous les clients. Chacune a un coût et une limite.
Après quelques heures, un serveur à un processus par client répond « accept: Too many open files ». Quelle est la cause probable ?
- Trop de zombies ont saturé la table des processus du système
- Le père ne ferme jamais la socket du client après le fork
- La valeur de backlog passée à listen est trop grande
- Les clients ne ferment pas leur propre socket
Voir la réponse
Le père ne ferme jamais la socket du client après le fork
Chaque
acceptcrée un descripteur dans le père, qui reste ouvert tant que le père ne le ferme pas, même quand le fils a fini. La limite par processus (souvent 1024) finit par être atteinte. Des zombies feraient échouerfork, nonaccept.