Où puis-je trouver des repères sur les différentes architectures de réseau ?

Question

Où puis-je trouver des repères sur les différentes architectures de réseau ?

Je joue avec les douilles / filets / fourches et j'aimerais savoir ce qui est le mieux. Je me disais qu'il doit bien y avoir un endroit où quelqu'un a déjà expliqué tous les avantages et les inconvénients des différentes architectures pour un service de socket, avec une liste de benchmarks avec du code qui fonctionne.

En fin de compte, j'aimerais exécuter ces différentes configurations avec mon propre code et voir laquelle fonctionne le mieux dans différentes circonstances.

De nombreux interlocuteurs me disent que je devrais me contenter d'utiliser le single threaded select. Mais je vois un argument en faveur des threads lorsque l'on stocke des informations d'état dans le thread pour garder un code simple. Quel est le compromis entre l'écriture de ma propre structure d'état et l'utilisation d'une architecture thread éprouvée ?

On m'a aussi dit que la bifurcation est mauvaise... mais quand vous avez besoin de 12000 connexions sur une machine qui ne peut pas augmenter la limite de fichiers ouverts par processus, la bifurcation est une option ! La bifurcation est également une bonne option pour la stabilité lorsque vous avez un processus qui doit être redémarré, cela ne perturbe pas les autres.

Désolé, c'est l'une de mes plus longues questions... tant de variables sont laissées vides.

Merci, Chenz

Answer 1

Il est très difficile de répondre à cette question, car tout dépend de ce que fait réellement votre service. Doit-il interroger une base de données ? lire des fichiers dans le système de fichiers ? effectuer des calculs compliqués ? aller parler à un autre service ? De plus, quelle est la durée de vie des connexions client ? Les connexions peuvent-elles avoir une interaction sémantique avec d'autres connexions, ou sont-elles toutes traitées comme indépendantes les unes des autres ? Pourriez-vous penser à équilibrer la charge de votre service sur plusieurs serveurs plus tard ? (Si c'est le cas, il serait utile d'y penser dès maintenant afin que toute aide nécessaire puisse être conçue dès le départ).

Comme vous l'indiquez, la machine de service peut avoir des limites qui interagissent avec les différentes techniques, vous orientant vers une réponse ou une autre. Vous avez une limite de descripteur de fichier par processus, mais n'oubliez pas que vous pouvez aussi avoir une table de processus de taille fixe ! De toute façon, à combien de clients simultanés vous attendez-vous ?

Si votre service ne cesse de tomber en panne et que vous devez sans cesse le redémarrer, ou si vous pensez avoir besoin d'un modèle multiprocessus pour que les connexions soient isolées les unes des autres, vous vous y prenez probablement mal. La stabilité est extrêmement importante dans ce genre de contexte, ce qui implique de bonnes pratiques et une hygiène de la mémoire, tant en général que face à des attaques basées sur le réseau.

Rappelez-vous l'histoire... fork() est bon marché dans le monde Unix, mais la création de nouveaux processus est relativement coûteuse sous Windows. Par ailleurs, les threads de Windows sont légers, alors que le threading a toujours été un peu étranger à Unix et ne s'est répandu que relativement récemment.

Answer 2

Edit : voici le lien que je cherchais, qui est un article complet répondant à votre question. http://www.kegel.com/c10k.html

Il existe des serveurs web conçus selon les trois modèles (fork, thread, select). Les gens aiment évaluer les serveurs web.

http://www.lighttpd.net/benchmark

Libevent a quelques repères et des liens vers des documents sur la façon de choisir un modèle select() ou threadé, généralement en faveur de l'utilisation du modèle libevent. http://monkey.org/~provos/libevent/