Czy istnieje sposób na współdzielenie gniazda nasłuchowego przez wiele procesów?

Większość innych podała techniczne powody, dla których to działa. Oto kod Pythona, który możesz uruchomić, aby zademonstrować to sobie:

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()

Zauważ, że rzeczywiście istnieją dwa procesy ID nasłuchujące:

$ 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)

Oto wyniki z uruchomienia telnetu i programu:

$ 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

Wygląda na to, że na to pytanie odpowiedzieli już MarkR i zackthehack, ale chciałbym dodać, że Nginx jest przykładem modelu dziedziczenia gniazd nasłuchowych.

Oto dobry opis:

• 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 <[email protected]>

...

W związku z tym, że NGINX nie jest w stanie sprostać wymaganiom klientów, nie jest w stanie sprostać ich wymaganiom.]}

Po głównym procesie NGINX odczytuje plik konfiguracyjny i widły do skonfigurowanej liczby procesów roboczych, każdy proces roboczy wchodzi w pętlę, w której czeka na wszelkie zdarzenia na swoich zestaw gniazd.

Każdy proces roboczy zaczyna się od samych gniazd nasłuchowych, ponieważ nie ma jeszcze żadnych połączeń. W związku z tym wydarzenie zestaw deskryptorów dla każdego procesu roboczego rozpoczyna się od gniazda nasłuchowe.

(Uwaga) NGINX można skonfigurować tak, aby używał dowolnego z kilku zdarzeń ankieta mechanizmy: aio / devpoll / epoll/eventpoll/kqueue/poll/rtsig / select

Gdy połączenie dociera do któregokolwiek z gniazd nasłuchowych (POP3/IMAP/SMTP), każdy proces roboczy wyłania się z ankiety zdarzeń, ponieważ każdy proces roboczy nginx dziedziczy Gniazdo nasłuchowe. Wtedy, każdy proces nginx worker będzie próbował zdobyć globalny mutex. Jeden z procesów roboczych uzyska blokadę, podczas gdy inni wrócą do swoich pętli wyborczych.

Tymczasem proces pracownika, który nabył globalny mutex, będzie zbadaj wywołane zdarzenia i utworzy niezbędną kolejkę roboczą żądania dla każdego zdarzenia, które zostało wywołane. Zdarzenie odpowiada deskryptor pojedynczego gniazda z zestawu deskryptorów, które pracownik obserwował wydarzenia z.

Jeśli wywołane zdarzenie odpowiada nowemu połączeniu przychodzącemu, NGINX akceptuje połączenie z gniazda nasłuchowego. Wtedy to kojarzy kontekst struktura danych z deskryptorem pliku. To context przechowuje informacje o połączeniu (czy POP3/IMAP/SMTP, czy użytkownik jest jeszcze uwierzytelniony, itp.). Wtedy, to nowo zbudowane gniazdo jest dodawane do zestawu deskryptorów zdarzeń dla tego procesu pracowniczego.

Pracownik rezygnuje teraz z mutexu (co oznacza, że wszelkie zdarzenia który przybył na innych pracowników może procedeed), i rozpoczyna przetwarzanie każde żądanie, które było wcześniej w kolejce. Każde żądanie odpowiada zdarzenie, które zostało zasygnalizowane. Z każdego deskryptora gniazda, który był sygnalizowane, proces worker pobiera odpowiedni kontekst strukturę danych, która wcześniej była powiązana z tym deskryptorem, oraz następnie wywołuje odpowiednie funkcje call back, które wykonują działania oparte na stanie tego połączenia. Na przykład, w przypadku z nowo utworzonego połączenia IMAP, pierwszą rzeczą, którą NGINX zrobi to napisanie standardowej wiadomości powitalnej IMAP na
podłączone Gniazdo (*OK IMAP4 ready).

By and by, każdy proces roboczy kończy przetwarzanie kolejki pracy wpis do każdego wyjątkowego wydarzenia i wraca do swojego wydarzenia pętla Wyborcza. Po nawiązaniu jakiegokolwiek połączenia z klientem, zdarzenia są zwykle szybsze, ponieważ gdy podłączone Gniazdo jest gotowy do odczytu, wyzwalane jest Zdarzenie read, a należy podjąć odpowiednie działania.

Chciałbym dodać, że gniazda mogą być współdzielone na Unix/Linux poprzez gniazda AF _ _ UNIX (gniazda między procesami). Wydaje się, że tworzony jest nowy deskryptor gniazda, który jest w pewnym sensie aliasem do oryginalnego. Ten nowy deskryptor gniazd jest wysyłany przez gniazdo AFUNIX do innego procesu. Jest to szczególnie przydatne w przypadkach, gdy proces nie może fork() udostępniać swoich deskryptorów plików. Na przykład podczas korzystania z bibliotek, które zapobiegają temu z powodu problemów z wątkiem. Powinieneś Utwórz Gniazdo domeny uniksowej i użyj libancillary do wysłania przez deskryptor.

Zobacz:

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

Do tworzenia gniazd AF_UNIX:

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

Na przykład kod:

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

Nie wiem, jak istotne jest to dla pierwotnego pytania, ale w jądrze Linuksa 3.9 jest łatka dodająca funkcję TCP / UDP: obsługa TCP i UDP dla opcji so_reuseport so_reuseport; nowa opcja socket pozwala wielu gniazdom na tym samym hoście wiązać się z tym samym portem i ma na celu poprawę wydajności wielowątkowych aplikacji serwerowych działających na systemach wielordzeniowych. więcej informacji można znaleźć w linku LWN LWN SO_REUSEPORT w jądrze Linuksa 3.9 jako wymienione w odnośniku:

Opcja SO_REUSEPORT jest niestandardowa, ale dostępna w podobnej formie na wielu innych systemach uniksowych(w szczególności na BSD, gdzie powstał pomysł). Wydaje się być użyteczną alternatywą dla wyciskania maksymalnej wydajności z aplikacji sieciowych działających w systemach wielordzeniowych, bez konieczności używania wzorca fork.

Mają jedno zadanie, którego jedynym zadaniem jest nasłuchiwanie połączeń przychodzących. Gdy połączenie jest odbierane, akceptuje połączenie - tworzy to oddzielny deskryptor gniazda. Zaakceptowane gniazdo jest przekazywane do jednego z dostępnych zadań workera, a główne zadanie wraca do nasłuchu.

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

Począwszy od Linuksa 3.9, możesz ustawić SO_REUSEPORT na gnieździe, a następnie mieć wiele niezwiązanych procesów współdzielących to gniazdo. To prostsze niż schemat prefork, koniec problemów z sygnałem, wyciek fd do procesów potomnych itp.

Linux 3.9 wprowadził nowy sposób zapisu serwerów socket

Opcja so_reuseport

Innym podejściem (które pozwala uniknąć wielu skomplikowanych szczegółów) w systemie Windows, jeśli używasz HTTP, jest użycie HTTP.SYS . Pozwala to wielu procesom nasłuchiwać różnych adresów URL na tym samym porcie. Na serwerze 2003/2008 / Vista / 7 tak działa IIS, dzięki czemu można z nim współdzielić porty. (NA XP SP2 HTTP.SYS jest obsługiwany, ale IIS5.1 go nie używa.)

Inne interfejsy API wysokiego poziomu (w tym WCF) wykorzystują protokół HTTP.SYS.

Pod Windows (i Linuksem) jest możliwe, że jeden proces otworzy gniazdo, a następnie przekaże je innemu procesowi, tak że ten drugi proces może również użyć tego gniazda (i przekazać je dalej, jeśli zechce).

Kluczowym wywołaniem funkcji jest WSADuplicateSocket ().

To zapełnia strukturę informacjami o istniejącym gnieździe. Ta struktura następnie, za pośrednictwem mechanizmu IPC do wyboru, jest przekazywana do innego istniejącego procesu (Uwaga mówię istniejący - po wywołaniu WSADuplicateSocket () należy wskazać proces docelowy, który otrzyma emitowaną informację).

Proces odbierający może następnie wywołać WSASocket (), przekazując tę strukturę informacji i odbierając uchwyt do gniazda bazowego.

Oba procesy trzymają teraz uchwyt do tego samego gniazda.

Wygląda na to, że chcesz, aby jeden proces nasłuchiwał nowych klientów, a następnie przekazywał połączenie po uzyskaniu połączenia. Aby to zrobić w różnych wątkach jest łatwe i w. Net masz nawet BeginAccept itp. metody dbania o wiele hydrauliki dla Ciebie. Przekazanie połączeń ponad granicami procesu byłoby skomplikowane i nie miałoby żadnych zalet wydajności.

Alternatywnie możesz mieć wiele procesów połączonych i nasłuchujących na tym samym Gniazdo.

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 + ".");
}

Jeśli odpalisz dwa procesy, każdy wykonujący powyższy kod będzie działał i pierwszy proces wydaje się uzyskać wszystkie połączenia. Jeśli pierwszy proces zostanie zabity, drugi otrzyma połączenia. Z socket sharing w ten sposób nie jestem pewien dokładnie, jak Windows decyduje, który proces dostaje nowe połączenia, chociaż szybki test wskazuje na najstarszy proces dostaje je pierwszy. Co do tego, czy dzieli się, czy pierwszy Proces jest zajęty, czy coś w tym stylu, Nie wiem wiedzieć.