Je dois implémenter un serveur de jeux en C qui gère plusieurs clients et échange continuellement des informations avec eux. Le client peut ne pas envoyer d'informations à tout moment. Dois-je assigner un thread avec un socket non bloquant ou utiliser appel select().Appel non-bloquant vs select()
Lequel est le meilleur?
Les deux fonctionneront tout aussi bien dans la plupart des cas. Notez que la version du thread utilisera des sockets bloquantes et que la base select utilise des sockets non bloquantes. Dans le cas d'un serveur, vous pouvez estimer que les événements pour les données reçues sont un bon modèle.
La version threadée aura l'en-tête mémoire d'allouer une pile pour chaque thread (souvent la taille d'une page), mais vous pouvez programmer comme si vous n'aviez qu'un seul client.
La version événementielle doit maintenir l'état entre les rappels, ce qui peut être plus de travail, mais encore une fois, dans les serveurs, cela semble assez naturel.
select() est la solution, c'est ce à quoi elle est destinée. Si vous optez pour l'approche thread non bloquante, vous devrez mettre en place un sleep après chaque tick ou le thread utilisera tout le temps de CPU disponible. Ainsi, le temps de réponse le plus défavorable, si un client envoie des données, est votre valeur de sommeil. Vous pouvez également implémenter un thread par socket et le bloquer, mais en fonction du nombre de sockets que vous avez, cela sera beaucoup plus lourd. Avec select(), vous pouvez regarder toutes les prises en même temps (qu'elles soient bloquantes ou non, par exemple) et ne doivent traiter que celles qui sont actives.
Si vous êtes sur Linux un avoir de nombreuses prises pour regarder, vous pouvez jeter un oeil à epoll()
Mon serveur doit traiter avec 4 clients en même temps, que dois-je utiliser? – sahil
le plus simple est d'utiliser select et un seul thread. Mais, si le serveur a beaucoup de choses à calculer avant d'envoyer une réponse, vous pouvez penser à une solution multi-thread – derhoch
Notez que sur Linux, en raison d'un bogue dans le noyau qu'ils refusent de réparer, vous devez ** définir ** le socket en mode non bloquant même si vous utiliserez 'select', s'il s'agit d'un socket UDP. La raison est que le noyau réveille le processus de 'select' quand il reçoit un paquet sans vérifier la somme de contrôle sur le paquet, donc si la somme de contrôle était invalide, votre processus se réveillera puis bloquera quand il essayera réellement de lire, introduisant un vulnérabilité majeure DoS contre votre serveur. –