Est-il un moyen pour plusieurs processus partagent une socket d'écoute?

la Plupart des autres ont fourni les raisons techniques pour lesquelles cela fonctionne. Voici du code python que vous pouvez utiliser pour le démontrer par vous-même:

import socket
import os

def main():
    serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    serversocket.bind(("127.0.0.1", 8888))
    serversocket.listen(0)

    # Child Process
    if os.fork() == 0:
        accept_conn("child", serversocket)

    accept_conn("parent", serversocket)

def accept_conn(message, s):
    while True:
        c, addr = s.accept()
        print 'Got connection from in %s' % message
        c.send('Thank you for your connecting to %s\n' % message)
        c.close()

if __name__ == "__main__":
    main()

notez qu'il y a en effet deux écouteurs de process id:

$ lsof -i :8888
COMMAND   PID    USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Python  26972 avaitla    3u  IPv4 0xc26aa26de5a8fc6f      0t0  TCP localhost:ddi-tcp-1 (LISTEN)
Python  26973 avaitla    3u  IPv4 0xc26aa26de5a8fc6f      0t0  TCP localhost:ddi-tcp-1 (LISTEN)

Voici les résultats de l'exécution de telnet et du programme:

$ telnet 127.0.0.1 8888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Thank you for your connecting to parent
Connection closed by foreign host.
$ telnet 127.0.0.1 8888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Thank you for your connecting to child
Connection closed by foreign host.
$ telnet 127.0.0.1 8888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Thank you for your connecting to parent
Connection closed by foreign host.

$ python prefork.py 
Got connection from in parent
Got connection from in child
Got connection from in parent

on dirait que cette question a déjà reçu une réponse complète de MarkR et zackthehack mais je voudrais ajouter que Nginx est un exemple du modèle d'héritage de socket d'écoute.

Voici une bonne description:

• http://zimbra.imladris.sk/download/src/GNR-601/ThirdParty/nginx/docs/IMPLEMENTATION

         Implementation of HTTP Auth Server Round-Robin and
                Memory Caching for NGINX Email Proxy

                            June 6, 2007
             Md. Mansoor Peerbhoy <mansoor@zimbra.com>

...

flux d'un processus d'ouvrier de NGINX

après le processus NGINX principal lit le fichier de configuration et les fourches dans la configuration du nombre de processus de travail, chaque processus de travail entre dans une boucle où il attend les événements sur son un ensemble de prises de.

chaque processus ouvrier commence avec seulement les prises d'écoute, puisqu'il n'y a pas encore de connexion disponible. Par conséquent, l'événement descripteur pour chaque processus de travail commence avec l' les sockets d'écoute.

(NOTE) NGINX peut être configuré pour utiliser n'importe lequel de plusieurs événements les mécanismes d'interrogation: aio/devpoll/epoll/eventpoll/kqueue/sondage/rtsig/sélectionnez

Lorsqu'une connexion arrive sur les sockets en écoute (POP3 / IMAP / SMTP), chaque processus de travail émerge de son sondage, depuis chaque processus NGINX worker hérite de la socket d'écoute. Puis, chaque processus NGINX worker tentera d'acquérir un mutex global. L'un des processus ouvriers acquerra la serrure, tandis que le d'autres retourneront à leurs boucles de sondage respectives.

pendant ce temps, le processus ouvrier qui a acquis le mutex global va examiner les événements déclenchés, et créera la file d'attente de travail nécessaire les demandes pour chaque événement a été déclenché. Un événement correspond à un descripteur de socket simple de l'ensemble des descripteurs que le travailleur a été regarder pour les événements d'.

si l'événement déclenché correspond à une nouvelle connexion entrante, NGINX accepte la connexion à partir de la socket d'écoute. Ensuite, il associe une structure de données contextuelles avec le descripteur de fichier. Ce contexte contient des informations sur la connexion (si POP3/IMAP / SMTP, si l'utilisateur est encore authentifié, etc). Puis, cette nouvelle socket est ajoutée dans le jeu de descripteurs d'événements pour ce processus de travail.

l'ouvrier abandonne maintenant le mutex (ce qui signifie que tout événement qui sont arrivés sur d'autres travailleurs peuvent procéder) , et commence à la transformation chaque demande qui a été mise en file d'attente plus tôt. Chaque demande correspond à un l'événement qui a été signalé. De chaque descripteur de douille qui a été signalé, le processus de travail récupère le contexte correspondant la structure des données qui était auparavant associée à ce descripteur, et puis appelle le rappel correspondant fonctions qui remplissent actions fondées sur l'état de cette connexion. Par exemple, dans le cas D'une connexion IMAP nouvellement établie, la première chose que NGINX va faire est d'écrire le standard IMAP message de bienvenue sur le

prise connectée (*OK IMAP4 prêt).

par et par, chaque processus de travailleur achève le traitement de la file d'attente de travail entrée pour chaque événement exceptionnel, et retourne à son événement boucle d'interrogation. Une fois que tout la connexion est établie avec un client, le les événements sont généralement plus rapides, car chaque fois que la prise connectée est prêt pour la lecture, l'événement de lecture est déclenché, et le des mesures correspondantes doivent être prises.

je voudrais ajouter que les sockets peuvent être partagés sur Unix/Linux via des sockets AF__UNIX (inter-process sockets). Ce qui semble se passer, c'est un nouveau descripteur de socket est créé, qui est en quelque sorte un alias à l'original. Ce nouveau descripteur de socket est envoyé via la socket AFUNIX à L'autre processus. Ceci est particulièrement utile dans les cas où un processus ne peut pas bifurquer() pour partager ses descripteurs de fichiers. Par exemple, lors de l'utilisation de bibliothèques qui empêchent contre cela en raison de problèmes de threading. Vous devrait créer une socket de domaine Unix et utiliser libancillary pour envoyer le descripteur.

voir:

• https://www.linuxquestions.org/questions/programming-9/how-to-share-socket-between-processes-289978/

Pour créer les Sockets AF_UNIX:

• http://docs.sun.com/app/docs/doc/817-4415/portmapper-51908?a=view

exemple de code:

• http://lists.canonical.org/pipermail/kragen-hacks/2002-January/000292.html
• http://cpansearch.perl.org/src/SAMPO/Socket-PassAccessRights-0.03/passfd.c

Je ne suis pas sûr que cela soit pertinent pour la question d'origine, mais dans le noyau Linux 3.9 il y a un patch qui ajoute une fonctionnalité TCP/UDP: le support TCP et UDP pour l'option socket SO_REUSEPORT; la nouvelle option socket permet à plusieurs sockets sur le même hôte de se lier au même port, et est destiné à améliorer les performances des applications de serveur réseau multithread sur les systèmes multicore. plus d'informations peuvent être trouvées dans le lien LWN LWN SO_REUSEPORT dans le noyau Linux 3.9 comme mentionné dans le lien de référence:

L'option SO_REUSEPORT n'est pas standard, mais disponible sous une forme similaire sur un certain nombre d'autres systèmes UNIX (notamment, le BSDs, d'où vient l'idée). Il semble offrir une alternative utile pour extraire les performances maximales des applications réseau fonctionnant sur des systèmes multicore, sans avoir à utiliser le modèle de fourche.

ont une seule tâche dont la seule tâche est d'écouter les connexions entrantes. Quand une connexion est reçue, elle accepte la connexion - cela crée un descripteur de socket séparé. Le socket accepté est passé à un de vos travailleurs des tâches, et la tâche principale remonte à l'écoute.

s = socket();
bind(s);
listen(s);
while (1) {
  s2 = accept(s);
  send_to_worker(s2);
}

à partir de Linux 3.9, vous pouvez configurer le SO_REUSEPORT sur une socket et ensuite avoir plusieurs processus non liés qui partagent cette socket. C'est plus simple que le schéma prefork, plus de problèmes de signal, fuite de fd vers les processus enfants, etc.

Linux 3.9 introduit une nouvelle façon d'écrire les serveurs socket

l'option socket SO_REUSEPORT

une autre approche (qui évite beaucoup de détails complexes) dans Windows si vous utilisez HTTP, est d'utiliser HTTP.SYS . Cela permet à plusieurs processus d'écouter des URLs différentes sur le même port. Sur le serveur 2003/2008 / Vista / 7 c'est ainsi que fonctionne IIS, vous pouvez donc partager des ports avec lui. (Sur XP SP2 HTTP.SYS est supporté, mais IIS5.Je ne l'utilise pas.)

autres API de haut niveau (y compris WCF) utilisent HTTP.SYS.

sous Windows (et Linux) il est possible pour un processus d'ouvrir une socket et de passer ensuite cette socket à un autre processus tel que ce second processus peut également utiliser cette socket (et la transmettre à son tour, s'il le souhaite).

l'appel de fonction crucial est WSADuplicateSocket().

cette structure contient des informations sur une socket existante. Cette structure est ensuite, via un mécanisme IPC de votre choix, transmise à un autre processus existant (note je dis existant-lorsque vous appelez WSADuplicateSocket (), vous devez indiquer le processus cible qui recevra les informations émises).

le processus de réception peut alors appeler WSASocket(), passer dans cette structure d'information, et recevoir une poignée à la socket sous-jacente.

les deux processus tiennent maintenant une poignée à la même prise sous-jacente.

il semble que ce que vous voulez est un processus d'écoute pour les nouveaux clients et ensuite passer la connexion une fois que vous obtenez une connexion. Faire cela à travers les fils est facile et dans. Net vous avez même le BeginAccept etc. méthodes pour prendre soin de beaucoup de la plomberie pour vous. Transférer les connexions au-delà des limites du processus serait compliqué et n'aurait pas d'avantages sur le plan du rendement.

alternativement vous pouvez avoir plusieurs processus liés et l'écoute sur le même socket.

TcpListener tcpServer = new TcpListener(IPAddress.Loopback, 10090);
tcpServer.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
tcpServer.Start();

while (true)
{
    TcpClient client = tcpServer.AcceptTcpClient();
    Console.WriteLine("TCP client accepted from " + client.Client.RemoteEndPoint + ".");
}

si vous démarrez deux processus en exécutant chacun le code ci-dessus, il fonctionnera et le premier processus semble obtenir toutes les connexions. Si le premier processus est tué, le second reçoit alors les connexions. Avec le partage de socket comme ça, Je ne sais pas exactement comment Windows décide quel processus obtient de nouvelles connexions, bien que le test rapide indique que le plus vieux processus les obtient en premier. Quant à savoir si elle partage si le premier processus est occupé ou quelque chose comme ça je ne sais pas.