Czy serwer gniazd i serwer gier powinny być osobnymi procesami?

Załóżmy prostą standardową grę klient / serwer. Czy dla serwera warto mieć osobny proces, który nasłuchuje połączeń i wiadomości od klientów i wysyła dane przez lokalne gniazda lub stdin do innego procesu, który uruchamia rzeczywisty serwer gry?

Inną opcją byłoby zrobienie obu rzeczy w jednym procesie. Kolejkowanie wiadomości przychodzących i wykonywanie ich w odpowiedniej kolejności nie powinno powodować problemu z zatrzymaniem.

Zastanawiam się, czy dodatkowe zasoby na oddzielenie dwóch „działań” są tego warte. Jak mam zdecydować? Chciałbym usłyszeć wszelkie zalety / wady.

Z perspektywy projektowania interfejsu API, podejmując decyzję, czy utworzyć wiele oddzielnych programów komunikacyjnych, czy tylko jeden, pytanie brzmi: czy każdy program może działać sensownie bez innych? Odpowiedź będzie się różnić w zależności od projektu i preferencji.

Jeśli nie mogą , nie warto o tym myśleć. Najwyraźniej są tak mocno powiązane, że nie są tak naprawdę odrębnymi procesami.

Jeśli mogą , i zobaczysz, że chcesz upuścić różne komponenty, aby zastąpić je w przyszłości, abstrakcja procesu dostarczona przez system operacyjny może pomóc.

Jak dużo pomaga zależy resztę swojego tech stosie chociaż. Na przykład Erlang wewnętrznie modeluje rzeczy jako procesy, więc nie zyskasz zbyt wiele pojęciowych korzyści z podziału ich na procesy systemu operacyjnego. Chyba że myślisz o przepisaniu tych części serwera w innym języku. Wewnętrzne komponenty programu C ++ są zazwyczaj ściślej sprzężone i dlatego trudniej je wymienić, a zatem podzielenie ich na różne procesy systemu operacyjnego może zaoszczędzić ci pracy później, jeśli możesz przewidzieć takie zmiany.

czy warto mieć osobny proces, który nasłuchuje połączeń i wiadomości od klientów i wysyła dane przez lokalne gniazda lub stdin do innego procesu, który uruchamia rzeczywisty serwer gry?

Aby odpowiedzieć na pytanie, czy warto, najpierw musisz zadać sobie pytanie, na czym polega problem, który próbujesz rozwiązać, dodając dedykowaną usługę kolejkowania. Jeśli rozwiązuje ten problem, to warto; jeśli to nie rozwiąże problemu lub jeśli nie masz problemu na początek, prawdopodobnie tak nie jest.

Zobaczmy kilka powodów, dla których niektóre serwery używają architektury wielowarstwowej:

1. Równoważenie obciążenia - równoważenie obciążenia ma sens, jeśli chcesz rozłożyć obciążenie na wiele komputerów roboczych. Jeśli twój program ma wąskie gardła, które chcesz rozwiązać, po prostu posiadając wiele współbieżnych procesów roboczych na tym samym komputerze, najlepiej w dłuższej perspektywie faktycznie rozwiązać wąskie gardło, ale w krótkoterminowym obejściu, odradzanie procesów roboczych może być praktyczne.
2. Rozdzielenie uprawnień - być może nie chcesz, aby naruszenie bezpieczeństwa na serwerze czatu automatycznie uzyskiwało dostęp do serwera gry i odwrotnie. Jeśli Twój serwer gier jest oddzielny od serwera czatu w grze, możesz skonfigurować serwer gier i serwer czatu, aby działał w oddzielnej domenie bezpieczeństwa (np. Działał jako inny użytkownik, z różnymi uprawnieniami dostępu, różnymi limitami procesów itp.).
3. Zero aktualizacji przestojów - jeśli chcesz osiągnąć zerową aktualizację przestojów, musisz mieć wiele poziomów i skonfigurować system tak, aby po wyłączeniu serwera do obsługi jego żądania były przekierowywane do innych serwerów w tej samej warstwie, aby zapewnić ciągłość usługa.
4. Limit łamania - jeśli osiągniesz limit gniazda, limit deskryptora pliku, globalną blokadę interpretera itp., Możesz być w stanie obejść ten limit, uruchamiając wiele procesów. Innym sposobem rozwiązania tego problemu jest zmiana limitu, ale nie zawsze jest to łatwe, ponieważ konieczne może być ponowne skompilowanie jądra lub może to mieć wpływ na bezpieczeństwo lub wydajność.
5. Ograniczanie wycieku zasobów - chcesz pisać oprogramowanie, które nie wycieka zasobów, ale nawet w językach w pełni zarządzanych przez śmieci jest to wyjątkowo trudne w długotrwałych procesach, a co gorsza, trudne do replikacji w środowisku programistycznym. Architektura wielowarstwowa pozwala zabijać i odradzać serwery gry po określonym czasie lub liczbie żądań ograniczenia szkód spowodowanych wyciekiem zasobów, bez zakłócania usługi.

Zgadzam się z grzechotką. Tak długo, jak masz jeden serwer gier, nie jest to warte kłopotu.

Jednak ta architektura może się przydać, gdy trzeba skalować w poziomie. Gdy jeden serwer gier nie jest już wystarczający i ze względu na wydajność trzeba rozprowadzać grę na wielu serwerach gier, architekturę „serwera gniazd” można bardzo łatwo dostosować do zmiany serwera gniazd w moduł równoważenia obciążenia, który automatycznie kieruje połączenia do jednego z wielu serwerów zaplecza serwer.

Ale jeśli nie masz pewności, czy kiedykolwiek będziesz tego potrzebować, prawdopodobnie w tym momencie nadużyteczne będzie opracowanie dwóch oddzielnych aplikacji serwerowych.

Prawdopodobnie tak nie jest, większość języków ma gniazda asynchroniczne, które pozwalają na korzystanie z wielu połączeń jednocześnie bez blokowania podczas oczekiwania na dane. Powoduje to przeniesienie części „serwera gniazd” do jądra systemu operacyjnego / jądra.

W przypadku jawnego serwera z gniazdami poniesiesz koszt kilku dodatkowych kopii podczas przesyłania danych przez gniazdo lokalne; jedną rzeczą, która zabije skalowalność, są dodatkowe kopie tam, gdzie ich nie potrzebujesz.