Un serveur est-il une boucle infinie s'exécutant en tant que processus d'arrière-plan?

Question

Un serveur est-il essentiellement un processus d'arrière-plan exécutant une boucle infinie en écoute sur un port? Par exemple:

while(1){ 
    command = read(127.0.0.1:xxxx); 
    if(command){ 
     execute(command); 
    } 
} 

Quand je dis serveur, je ne parle pas de toute évidence à un serveur physique (ordinateur). Je fais référence à un serveur MySQL ou Apache, etc.

divulgation complète - Je ne l'ai pas eu le temps de fouiller dans le code source. Les exemples de code réels seraient super!

Answer 1

qui est plus ou moins ce que le logiciel serveur fait généralement.

Habituellement, cela devient plus compliqué parce que la boucle infinie "seulement" accepte la connexion et chaque connexion peut souvent gérer plusieurs "commandes" (ou peu importe dans le protocole utilisé), mais l'idée de base est à peu près ceci.

Answer 2

En quelques parler, oui. Un serveur est simplement quelque chose qui "boucle pour toujours" et sert. Cependant, généralement, vous constaterez que les "démons" font des choses comme ouvrir STDOUT et STDERR sur des handles de fichiers ou/dev/null avec des doubles fourchettes entre autres choses. Votre code est un "serveur" très simpliste dans un sens.

Answer 3

Il existe trois types de « serveurs » - qui bifurquent, filetage et filetés simple (non-blocage). Chacun d'entre eux boucle généralement la façon dont vous montrez, la différence est ce qui se passe quand il y a quelque chose à entretenir.

Un service de fork est juste que. Pour chaque requête, fork() est appelée en créant un nouveau processus fils qui gère la requête, puis se ferme (ou reste actif, pour gérer les requêtes suivantes, selon la conception). Un service de threading est comme un service de forking, mais au lieu d'un tout nouveau processus, un nouveau thread est créé pour servir la demande. Comme les fourches, les threads restent parfois pour gérer les demandes suivantes. La différence de performance et d'empreinte est simplement la différence entre les threads et les fourches. En fonction de l'utilisation de la mémoire qui est et non pour un client (et susceptible de changer), il est généralement préférable de ne pas cloner l'intégralité de l'espace d'adressage. La seule complexité ajoutée ici est la synchronisation.

Procédé serveur unique (aka seul thread) se bifurquer une seule fois à daemonize. Il ne générera pas de nouveaux threads, il ne générera pas de processus fils. Il continuera à interroger() le socket pour savoir quand le descripteur de fichier est prêt à recevoir des données, ou si des données sont disponibles pour être traitées. Les données pour chaque connexion sont conservées dans sa propre structure, identifiée par différents états (écriture, attente de ACK, lecture, fermeture, etc.). Cela peut être une conception extrêmement efficace, si cela est fait correctement. Au lieu d'avoir plusieurs enfants ou threads qui bloquent en attendant de travailler, vous avez un seul processus et des demandes de service de boucle d'événements lorsqu'elles sont prêtes. Il existe des cas où les services à un seul thread génèrent plusieurs threads, mais les threads supplémentaires ne fonctionnent pas pour traiter les demandes entrantes, on peut par exemple configurer un socket local dans un thread qui permet à un administrateur d'obtenir un statut de toutes les connexions. Une petite recherche sur google pour un serveur http non bloquant donnera d'intéressants serveurs Web roulés à la main écrits comme des défis de golf de code.

En bref, la différence est ce qui se passe une fois que la boucle sans fin est entré, non seulement la boucle sans fin :)