Uruchamianie serwera i klienta w ramach tego samego procesu

Pytanie

Właśnie zacząłem pracować z Lidgrenem i siecią po raz pierwszy i doszedłem do wniosku, że możliwe jest uruchomienie zarówno serwera, jak i klienta w ramach tego samego procesu.

Czy z jakiegoś powodu ta praktyka jest odradzana?

Kontekst

Powodem, dla którego pytam, jest teoria, że ​​ta koncepcja może pozwolić mi traktować zarówno tryby dla jednego gracza, jak i dla wielu graczy jako jeden i ten sam, co byłoby bardzo pomocne.

Zgodnie z moim tokiem myślenia, oto rozkład, który miałem na myśli:

• Tryb jednego gracza - 1 serwer + 1 klient w tym samym procesie. Jak szybka jest komunikacja?
• Tryb dla wielu graczy - taki sam jak dla jednego gracza dla hosta + 1 dodatkowy klient dla każdego innego gracza.

Wykonywany przeze mnie przepływ wykonywania polega na tym, że klienci otrzymują informacje od użytkowników i wysyłają powiadomienie do serwera. Następnie serwer sprawdza poprawność i rozgłasza akcję do wykonania przez wszystkich klientów. Nie powinno mieć znaczenia, czy jest tylko jeden klient (tj. Gra jednoosobowa) czy wielu klientów (tj. Gra wieloosobowa).

Jest to w zasadzie pytanie o proces w porównaniu do wątku, oba nie są zbyt różne, czasem wątki nazywane są procesami lekkimi. Największą różnicą jest to, że osobny proces ma własną przestrzeń adresową, ale istnieją inne różnice (1):

Na proces

• przestrzeń adresowa
• Zmienne globalne
• Otwórz pliki
• Procesy potomne
• Oczekujące alarmy, przerwania i procedury obsługi sygnałów

Na wątek

• Licznik programu
• Rejestry
• Stos
• Stan

Na podstawie tych różnic przydatne może być posiadanie wątku serwera i klienta w tym samym procesie, aby można było współużytkować uchwyty plików i zmienne globalne. Byłby to argument za podejściem „w tym samym procesie”, innym (małym) argumentem byłoby otrzymanie tylko jednego okna podręcznego „Zapora systemu Windows” na proces. Argumentem za podejściem „innego procesu” byłoby to, że dana osoba może obsługiwać wiele serwerów bez konieczności uruchamiania wielu klientów. Byłoby to idealne rozwiązanie dla dedykowanego hosta, takiego jak konfiguracja, i jest to podejście, które zwykle widzimy w strzelankach FPS.

Jeśli chodzi o pomysł posiadania procesu serwera lub wątku, nawet do gry offline (a może nawet dla jednego gracza), jest to świetny pomysł, który jest często stosowany w praktyce. Możesz powiedzieć, że wiele gier to robi, patrząc na ekran ładowania, rozdadzą go małe podpowiedzi, takie jak „odbieranie”. Logiczne jest to zrobić, ponieważ jeśli zamierzasz stworzyć tryb dla wielu graczy, większość zasad gry będzie rządzonych przez serwer, więc dlaczego by nie zarządzać nimi dla jednego gracza? Zmniejsza to kod, który musisz napisać, i zapewnia wyraźniejsze oddzielenie klienta od „gry”, co poprawi jakość twojego kodu.

A co powiesz na komunikację między procesami i wątkami? Komunikacja między procesami może odbywać się na wiele sposobów, (nazwane) potoki, pamięć współdzielona, ​​COM, to naprawdę zależy od używanej technologii. Jeśli jednak tworzysz serwer, prawdopodobnie będziesz chciał wybrać wariant sieciowy wykorzystujący gniazda i coś w rodzaju TCP, to oczywiście LIDGREN się przyda.

Wiele z tych technik dotyczy również komunikacji krzyżowej. Ale to zależy jeszcze bardziej od stosowanych technik. Możesz znów przejść na TCP, ale być może jeszcze prostszym systemem byłyby zdarzenia i trochę marshalling, chociaż może to spowodować, że twoja pętla gry nie będzie deterministyczna (2).

Źródła

1. Projektowanie i wdrażanie systemów operacyjnych (książka MINIX), 3. wydanie autorstwa Andrew S. Tanenbauma
2. Napraw swój timepep według Glenna Fiedlera: http://gafferongames.com/game-physics/fix-your-timestep/