Les serveurs doivent non seulement être en attente continue de connexions de la part de clients potentiels, mais doivent également être en mesure de traiter les demandes simultannées de plusieurs clients. On ne peut génarelement pas se permettre de mettre les clients dans une file d'attente et de traiter leurs demandes les unes après les autres.
Les instructions bloquantes, d'un serveur TCP, (c'est à dire celle qui provoque l'arrêt temporaire de l'exécution du serveur jusqu'à ce qu'un événement spécifié se produise) sont :
La lecture ou bien l'écriture sur le canal d'un client peut donc mettre en attente d'autres opérations de lecture ou d'écriture pour un autre client mais également l'acceptation de nouveaux clients. Pour résoudre ce problème plusieurs solutions s'offrent à nous.
Les solutions multi-tâches consistent à déployer une tâche par client voir même deux tâches si le client peut indifféremment lire et écrire sur le canal à un instant donné (C'est, par exemple, le cas d'un programme de chat qui recevrait les caractères tappés par un client en même temps qu'il transmet à ce client les caractères reçus des autres clients du même groupe conversationnel). Pour déployer le multi-tâche, il existe deux solutions (que l'on peut éventuellement combiner) :
L'autre solution consiste à ne pas exécuter accept(), read() ou write() sans avoir préalablement vérifié que l'événement qu'elles attendent (et qui peut donc les rendre bloquantes) n'est pas déjà arrivé. L'instruction bloquante select() va permettre de surveiller simultannément les 3 types d'événement pour un ensemble de sockets.