Steam Datagram Relay (SDR) to prywatna, wirtualna sieć gamingowa firmy Valve. Korzystając z naszych interfejsów API, możesz nie tylko przekierowywać ruch ze swojej gry za pomocą sieci szkieletowej Valve przeznaczonej dla zawartości gry, ale także zyskać dostęp do naszej sieci przekaźnikowej. Przekierowywanie ruchu w grze zabezpiecza twoje serwery i graczy przed atakami DoS, ponieważ adresy IP nie zostają nigdy ujawnione. Cały ruch w grze jest uwierzytelniony, zaszyfrowany i posiada ograniczoną częstotliwość. Ponadto dla zaskakująco dużej liczby graczy jesteśmy w stanie znaleźć szybszą trasę przez naszą sieć, co poprawia czas pingu graczy.

Ta sieć przekaźnikowa może być używana dla ruchu peer-to-peer oraz dedykowanych serwerów.

Ogólne wymagania i wskazówki związane z portowaniem istniejącego kodu sieciowego

Poniżej znajdują się ogólne rzeczy mające zastosowanie zarówno do połączenia typu P2P, jak i z serwerem. Pamiętaj o nich.

Po pierwsze, każde miejsce identyfikujące hostów sieci po publicznym IP (prawie zawsze ma to miejsce w przypadku serwerów gier) będzie musiało zostać zmienione, by używało innego identyfikatora. Można to zrobić na wiele sposobów:

• Dla klientów i serwerów gier logujących się do Steam zazwyczaj użyjesz ID Steam.
  
• Jeżeli twój serwer gry nie loguje się do Steam i używasz schematu uwierzytelniania opartego na tokenach, możesz użyć dowolnego innego identyfikatora, który ma dla ciebie znaczenie. Sprawdź SteamNetworkingIdentity.
  
• W niektórych bazach kodu normą jest założenie, że hosty sieci i serwery gier są identyfikowane poprzez adres IPv4. Zmiana tego założenia to sporo pracy. API Steamworks ISteamMatchmaking i ISteamMatchmakingServers mają tę właściwość, podobnie jak niektóre z naszych gier, np. Team Fortress 2. W tym przypadku możesz użyć systemu FakeIP Steamworks. FakeIP (fałszywe IP) to taki adres IP, który wygląda jak prawidłowy adres IPv4 dla większości zastosowań, ale pochodzi z zarezerwowanej przestrzeni adresowej, która nie jest używana w internecie. Przypisując serwerowi fałszywy adres IP, nadal można połączyć się z twoim serwerem przy pomocy adresu IPv4 i niemal wszystko będzie „po prostu działać”. Systemy ISteamNetworkingSockets i ISteamMatchmakingServers są w stanie rozpoznać te specjalne IP i podjąć odpowiednie działania. Adresy nie są zaś rutowalne i nie działają w ogólnym zastosowaniu w internecie (np. nie da się ich pingować). Zobacz ISteamNetworkingSockets::BeginAsyncRequestFakeIP, aby uzyskać więcej informacji.

Po drugie, musisz zmodyfikować wszelki niskopoziomowy kod gniazda, by używał jednego z API Steamworks do łączności z internetem.

• Najlepiej byłoby użyć jednego z API ISteamNetworkingSockets skupionych na łączności i zwracających wartość HSteamNetConnection.
  Pamiętaj, że te API wspierają także zwykły transport UDP, co jest bardzo pomocne przy testowaniu. Istnieje także wersja open source.
  
• Niektóre bazy kodu są napisane bardziej w stylu UDP, gdzie pakiety mogą być przesyłane ad-hoc do każdego zdalnego hosta w dowolnym czasie, i nie wszystkie komunikaty są przesyłane do ustalonego „połączenia”. W sytuacjach tego typu mogą przydać się dwie funkcje Steamworks.
  
  • Użyj ISteamNetworkingMessages do komunikowania się z hostami identyfikowanymi poprzez SteamNetworkingIdentity, np. ID Steam.
    
  • Użyj ISteamNetworkingFakeUDPPort do komunikowania się z hostami identyfikowanymi po fałszywym IP.

Korzystanie z SDR na innych platformach i w innych sklepach

Rozwiązanie polegające na korzystaniu z API sieciowych i ochrony przed atakami DDoS w grach wieloplatformowych jest bezużyteczne, jeżeli działa ono tylko na jednej platformie. W większości wypadków twoi gracze na innych platformach i w innych sklepach mogą uzyskać dostęp do sieci przekierowującej, jeśli twoja gra spełni kilka podstawowych warunków.

• Musisz dystrybuować swoją grę na Steam.
  
• Zgadzasz się na aktualizowanie gry w ciągu racjonalnego przedziału czasu (np. kilku miesięcy) kiedy o to poprosimy, gdy będziemy musieli wydać poprawki błędów lub aktualizacje bezpieczeństwa.
  
• Miej na uwadze, że niestety nie jesteśmy w stanie zagwarantować stałej dostępności tej usługi dla graczy spoza Steam. W mało prawdopodobnym przypadku, gdybyśmy musieli obniżyć poziom usługi, zrobimy wszystko, co w naszej mocy, aby podjąć z tobą współpracę w celu uniknięcia zakłóceń korzystania ze strony graczy, włączając w to danie ci czasu na stworzenie planu. SDK posiada wbudowane mechanizmy umożliwiające nam poinstruowanie klientów, by rezerwowo korzystały z bezpośredniego połączenia UDP lub próbowały dziurkować NAT, ale ty też powinieneś mieć taką możliwość na uwadze.
  
• Posiadaj pewnego rodzaju usługę wyszukiwania gier (SDR odnosi się do tego jako twojego „koordynatora gry”), która jest w stanie wydać dane uwierzytelniające. Dla tego celu posiadamy osobne SDK – zobacz niżej.

Skontaktuj się z nami, by uzyskać odpowiednie SDK i by porozmawiać o szczegółach. Nadal pracujemy nad szczegółami dystrybucji tego kodu i w tej chwili możemy nie być w stanie udostępnić obsługi międzyplatformowej wszystkim partnerom i wszystkim grom.

Poniżej znajdziesz więcej informacji technicznych na temat implementacji SDR na innych platformach i w innych sklepach.

Jeżeli nie spełniasz powyższych kryteriów, skorzystaj z wersji API typu open source do dowolnego pożądanego przez ciebie celu. Zwróć uwagę, że kod open source nie obsługuje dostępu do sieci przekaźnikowej.

Gry z połączeniem typu peer-to-peer

W przypadku ruchu sieciowego typu peer-to-peer na Steam wystarczy użyć API takich jak ISteamNetworkingSockets::CreateListenSocketP2P i ISteamNetworkingSockets::ConnectP2P w celu wykorzystania SDR, a Steam zajmie się wszystkim innym. W przypadku innych platform i sklepów przeczytaj więcej o dodatkowych wymaganiach technicznych poniżej.

Serwery dedykowane w znanych centrach danych

API peer-to-peer działają w porządku nawet wtedy, gdy jeden z „peerów” jest dedykowanym serwerem! Jednak istnieje jeden ważny haczyk: jeżeli twój dedykowany serwer nie znajduje się blisko jednego z centrów danych, gdzie używane są przekaźniki, to najlepsza przekierowana trasa może być wolniejsza od domyślnej trasy IP i przynajmniej część graczy doświadczy opóźnień większych niż zwyczajowe.

Dla optymalnych rezultatów korzystania z dedykowanego serwera powinien on być uruchomiony w znanym centrum danych, które jest częścią sieci SDR. Dbamy o to, by przekierowania przebiegały w pobliżu oraz nie były znacznie wolniejsze od domyślnej trasy IP. Serwery uruchomione w tych znanych centrach danych łączą się za pomocą specjalnego API. Ten przypadek użycia został określony w SDK jako „Hosted Dedicated Server” (hostowany dedykowany serwer). Pamiętaj, że nie oznacza to koniecznie, że Valve hostuje serwery lub przekaźniki – może być to centrum danych firmy zewnętrznej, z którą nawiązaliśmy partnerstwo, i jest ono rozpoznawane przez system Steam Datagram Relay.

Jeżeli posiadasz działające serwery u dużego dostawcy i interesuje cię korzystanie z SDR, skontaktuj się z nami. Spróbujemy nawiązać współpracę z twoim dostawcą usług hostingowych, by przekaźniki były uruchomione w centrum danych. Jest to najlepsze rozwiązanie, ale nawet jeśli nie będzie to możliwe, to być może będziemy w stanie dodać centrum danych do naszego systemu konfiguracji sieci i po prostu użyć przekaźników Valve, które są w pobliżu.

Jeśli masz firmę specjalizującą się w usługach hostingu serwerów dedykowanych i chcesz dołączyć do naszej sieci, aby twoi klienci mogli korzystać z SDR, skontaktuj się z nami! Nie udostępniliśmy jeszcze przekaźników żadnej firmie zewnętrznej specjalizującej się w usługach hostingu, ale jesteśmy zainteresowani taką możliwością.

Prosty schemat połączenia z dedykowanym serwerem bez koordynatora gry

Jeżeli nie posiadasz własnej centralnej usługi wyszukiwania gier i logowania (czasem nazywamy to „koordynatorem gry”), która przypisuje graczy do serwerów, lub po prostu chcesz wszystko uprościć do granic możliwości, to możesz połączyć się z dedykowanym serwerem w znanym centrum danych za pomocą ISteamNetworkingSockets::CreateListenSocketP2P i ISteamNetworkingSockets::ConnectP2P. W tym przypadku połączenie rozpoczyna się u klienta tak jak zwykłe połączenie P2P. Komunikaty rendez-vous są przesyłane przez Steam, więc jeżeli gracz lub serwer utraci połączenie ze Steam, to połączenie nie może zostać nawiązane. Dodatkowo Steam nie ogranicza, kto może się podłączyć. Weryfikuje jedynie, że gracz jest zalogowany do Steam i posiada grę.

Schemat połączenia z serwerem oparty o tokeny

Jeżeli posiadasz swoją własną usługę koordynatora gier, to zalecamy użycie schematu połączenia opartego na tokenach. Wymaga on zazwyczaj tylko nieco więcej nakładu pracy w stosunku do połączenia w stylu P2P i oferuje dwie ważne korzyści:

• Przyznajesz tokeny tylko graczom, którzy powinni mieć możliwość podjęcia próby połączenia, więc niechciane próby połączenia nawet nie docierają do twojego serwera.
  
• Gdy gracz ma już token, to może połączyć się z serwerem, nawet jeśli utracił połączenie ze Steam, serwer utracił połączenie ze Steam lub komputer doznał nieoczekiwanego zamknięcia i zrestartował się itp. Stworzenie solidnej możliwości ponownego łączenia się z serwerem gry w przypadku tak pospolitych problemów jest szczególnie ważne w grach, które karzą graczy za opuszczanie gier.

Połączenie oparte na tokenach z serwerem dedykowanym przez SDR działa w następujący sposób:

• Gdy serwer gry zaloguje się do koordynatora gry, wysyła swój SteamDatagramHostedAddress, który jest nieprzezroczystym blobem zawierającym informacje o fizycznym trasowaniu (zobacz ISteamNetworkingSockets::GetHostedDedicatedServerAddress). Pamiętaj również, że mamy kilka narzędzi, które mogą pomóc ci w uzyskaniu uwierzytelnionego dostępu do twojego koordynatora gry.
  
• Serwer rozpoczyna nasłuchiwanie przekierowanego ruchu z użyciem ISteamNetworkingSockets::CreateHostedDedicatedServerListenSocket.
  
• W pewnym momencie twój klient chce wyszukać grę lub połączyć się z serwerem.
  
• Klient może użyć metod dostępnych w interfejsie ISteamNetworkingUtils w celu uzyskania czasów pingu do centrów danych i sprawdzania łączności. Prawdopodobnie również przyda ci się to, by klient wysyłał te informacje do twojego koordynatora gry, by ten drugi mógł podjąć odpowiednią decyzję o tym, w jaki sposób przypisać graczy do centrów danych.
  
• Gdy twój koordynator gry będzie gotowy do upoważnienia klienta do połączenia z serwerem, wygeneruje on SteamDatagramRelayAuthTicket i podpisze go twoim tajnym kluczem. Wspomniany token upoważnia konkretnego klienta do komunikacji z konkretnym serwerem gry przez ograniczony czas oraz zawiera zaszyfrowane informacje o trasowaniu. Następnie koordynator gry przesyła token do klienta.
  
• Klient przechowuje token w lokalnej pamięci podręcznej. Zobacz ISteamNetworkingSockets::ReceivedRelayAuthTicket, by dowiedzieć się więcej, w tym informacje opisujące, dlaczego dodatkowe skomplikowanie pamięci podręcznej jest przydatne.
  
• Klient korzysta z ISteamNetworkingSockets::ConnectToHostedDedicatedServer, żeby połączyć się z serwerem. Aby dowiedzieć się więcej na temat wysyłania i otrzymywania komunikatów, zobacz ISteamNetworkingSockets.

W tej chwili uwierzytelnianie oparte na tokenach nie jest dostępne w połączeniu z systemem FakeIP.

SDK koordynatora gier

„Koordynator gier” to termin używany przez nas na usługi twojego back-endu/wyszukiwania gier. Istnieje oddzielne, małe SDK, które można połączyć z koordynatorem gry w celu:

• wystawiania tokenów, aby dać klientom dostęp do serwerów gier hostowanych za SDR,
  
• parsowania z użyciem stringów PingLocation_t i obliczania czasu pingu między tymi obiektami,
  
• wydawania certyfikatów tożsamości dla graczy na innych platformach i sklepach,
  
• korzystania z niektórych innych zaawansowanych funkcji.

SDK jest dostępne tutaj.

Uwierzytelnianie z użyciem SDK koordynatora gier

SDR korzysta z dwóch mechanizmów uwierzytelniania:

• Tokeny hostowanych serwerów są wystawiane przez koordynatora gry i przez ograniczony czas upoważniają klienta do komunikowania się z określonym serwerem dedykowanym. Tokeny przekaźników są używane tylko w przypadku serwerów dedykowanych. Zobacz SteamDatagramRelayAuthTicket.
  
• Certyfikaty są wykorzystywane w tradycyjny sposób do uwierzytelniania i wymiany kluczy z użyciem protokołu Diffiego-Hellmana w celu ustanowienia zaszyfrowanego kanału komunikacji. Certyfikaty to założenia całościowe i można z nich korzystać do wszystkich form komunikacji z użyciem SteamNetworkingSockets, wliczając w to UDP czy P2P. Zobacz SteamDatagram_CreateCert z SDK koordynatora gier oraz ISteamNetworkingSockets::GetCertificateRequest.

Do uwierzytelniania klientów i serwerów korzystamy z własnej infrastruktury klucza publicznego (PKI). Gracze otrzymują osobne, krótkoterminowe certyfikaty przypisane do ich tożsamości gracza i tym procesem zajmuje się sam Steam. W przypadku serwerów gier zazwyczaj korzystamy z certyfikatów działających nieco dłużej, które upoważniają całe centrum danych do uzyskania dostępu do konkretnego ID aplikacji. Odpowiedzialność za wystawianie tych certyfikatów spoczywa na tobie.

Przed wystawieniem tokenów lub certyfikatów musisz wygenerować parę kluczy i przesłać nam swój klucz publiczny. Opublikujemy certyfikat podpisany przez nasz uniwersalny klucz CA, który oznacza twój klucz jako zaufany dla twoich aplikacji. Następnie korzystając z naszego narzędzia certyfikacji, musisz, bez korzystania z sieci, wygenerować certyfikat dla każdego centrum danych, w którym chcesz uruchomić serwery, i podpisać go za pomocą swojego klucza prywatnego. Będziesz rozprowadzać te certyfikaty do swoich serwerów gier za pośrednictwem bezpiecznego kanału, przekazując je do swojego serwera w środowisku (patrz poniżej).

Użyjesz również swojego klucza do generowania tokenów za każdym razem, gdy gracz łączy się z serwerem.

Pamiętaj, by dbać o bezpieczeństwo twojego prywatnego klucza CA i prywatnych kluczy twoich certyfikatów! Jeżeli twój klucz zostanie ujawniony, to będzie musiał zostać unieważniony i zastąpiony, co może spowodować dezorganizację.

Implementacja SDR na innych platformach i sklepach

Twoi klienci na innych platformach i w innych sklepach nie będą logować się do Steam, więc będziesz musiał zapewnić tym graczom kilka usług, które Valve już zapewnia graczom na Steam.

Inicjalizacja koordynatora gry

• Usługa wyszukiwania gier (zwana także „koordynatorem gry”) będzie musiała zostać połączona z SDK koordynatora gry. Więcej informacji znajduje się w pliku nagłówkowym steamdatagram_gamecoordinator.h. SDK koordynatora gry używa API w zwykłym C, więc integracja z innymi językami powinna być stosunkowo łatwa.
  
• Pobierz konfigurację sieci w momencie inicjalizacji i sprawdzaj dostępność aktualizacji mniej więcej raz na godzinę. (zobacz SteamDatagram_GameCoordinator_GetNetworkConfigURL i SteamDatagram_GameCoordinator_SetNetworkConfig). Konfiguracja sieci jest zachowana w małym pliku JSON – w chwili pisania tego tekstu ma około 26 KB (9 KB po skompresowaniu). Ten adres URL jest szerokodostępny, ale jeśli chcesz być przygotowany na awarię, możesz użyć ostatnio pobranej wersji.
  
• Będziesz potrzebować uwierzytelnionej pary kluczy dla swojej gry. Wyślij nam klucz publiczny i zainicjalizuj SDK koordynatora gry przy pomocy swojego klucza prywatnego. Zobacz SteamDatagram_SetPrivateKey_Ed25519, by dowiedzieć się więcej.

Logowanie klienta

• Klient wywoła ISteamNetworkingSockets::GetCertificateRequest, by pobrać obiekt blob i wysłać go wraz z komunikatem żądania logowania do twojego koordynatora gry.
  
• Gdy koordynator gry otrzyma komunikat żądania logowania, wygeneruj certyfikat dla klienta, używając SteamDatagram_CreateCert.
  
• Wyślij wygenerowany certyfikat do klienta w odpowiedzi na żądanie logowania. Klient powinien zainstalować swój certyfikat używając ISteamNetworkingSockets::SetCertificate.
  
• Stanowczo zaleca się, by równocześnie przesyłać klientom także konfigurację sieci. Klient zastosuje ustawienia sieci, używając SteamDatagram_SetNetworkConfig.

Certyfikaty mają swój okres ważności i zalecamy, by wygasały one po 48 godzinach. Jeśli połączenie klientów będzie trwało dłużej niż 48 godzin, konieczne będzie okresowe odnawianie certyfikatu. Nowy certyfikat można wystawić w dowolnym momencie, więc jeśli chcesz wystawiać certyfikaty częściej, na przykład na początku każdej rozgrywki, to nie ma z tym problemów.

Każdy klient musi posiadać unikalną tożsamość. Jeśli to możliwe, używaj tożsamości specyficznych dla danej platformy (jest to obowiązkowe dla klientów Steam). Jeśli jest to niemożliwe, możesz użyć tożsamości opartej o „generyczny łańcuch tekstu”, która ma znaczenie dla twojego systemu dobierającego gry. Sprawdź SteamNetworkingIdentity.

Gry z połączeniem typu peer-to-peer

Połączenia typu P2P wymagają usługi „sygnalizującej”. Jest to niewrażliwy na opóźnienia optymalny kanał o niskim zużyciu łącza zdolny do przekazywania okazjonalnych komunikatów o rendezvous do ustalania routingu. Wymaga to od klientów nieustannego połączenia z twoją usługą wyszukiwania gier (np. przez protokół WebSocket lub połączenie TCP), by możliwe było wysyłanie im komunikatów. Jeżeli klienty komunikują się z koordynatorem gry wyłącznie przy użyciu żądań i odpowiedzi, np. http, to nie będzie to działać. Musisz jedynie zaoferować „optymalny” transfer, co oznacza, że ​​biblioteka toleruje wielokrotne odrzucanie lub dostarczanie wiadomości.

• Aby zainicjować połączenie, użyj ISteamNetworkingSockets::ConnectP2PCustomSignaling. Musisz zaimplementować podklasę ISteamNetworkingConnectionSignaling, a po wywołaniu SendSignal klient powinien wysłać wiadomość do twojego back-endu. Twój back-end powinien dołożyć wszelkich starań, by dostarczyć wiadomość peer-to-peer. Po utworzeniu połączenia po raz pierwszy z reguły następuje wymiana od 4 do 10 wiadomości. Później może pojawić się wywołanie, by dostarczyć sygnał dla ustanowionego połączenia, jeśli zmienią się warunki trasowania.
  
• Gdy klient otrzyma sygnał, wywołaj ISteamNetworkingSockets::ReceivedP2PCustomSignal. Biblioteka zdekoduje wiadomość. Jeśli sytuacja dotyczy istniejącego połączenia, sygnał zostanie przetworzony wewnętrznie. Jeśli sygnał dotyczy nowego połączenia, to zostanie wywołane ISteamNetworkingSignalingRecvContext::OnConnectRequest.

Aby poznać szczegóły, sprawdź: steamnetworkingcustomsignaling.h.

Uruchamianie serwerów w znanych centrach danych

Poniższa sekcja zawiera informacje techniczne dotyczące uruchamiania dedykowanych serwerów w znanych centrach danych.

Zmienne środowiskowe

Serwer dedykowany pobiera swoją konfigurację ze zmiennych środowiskowych. Zwróć uwagę na to, że w centrach danych Valve wszystkie wartości są ustawiane dla ciebie automatycznie.

• SDR_LISTEN_PORT: port UDP, za którego pośrednictwem do twojego serwera będzie przekazywany ruch z przekaźników. Dedykowany serwer korzysta tylko z jednego gniazda (możesz mieć jednak więcej niż jedno logiczne „gniazdo nasłuchu” dzięki użyciu „portów wirtualnych” – zobacz ISteamNetworkingSockets::CreateHostedDedicatedServerListenSocket). W naszych centrach danych zazwyczaj korzystamy z zakresu 30xxx.
  
• SDR_IP: twój serwer musi posiadać publiczny adres IP, który ma możliwość odbierania „niepożądanego” ruchu z przekaźników. Jeśli serwer ma tylko jeden interfejs z publicznym adresem IP, to właśnie on zostanie użyty. W przeciwnym razie musisz wskazać serwerowi gry, jakiego adresu IP powinien użyć. Gniazdo SDR będzie powiązane z INADDR_ANY, ale ta informacja jest potrzebna do wypełnienia SteamDatagramHostedAddress serwera. Zwróć uwagę na to, że zazwyczaj będzie to musiało zostać ustawione w środowisku programistycznym, gdzie twój serwer jest chroniony firmową zaporą sieciową (zobacz poniżej). Możesz także określić port, jeśli port publiczny różni się od SDR_LISTEN_PORT.
  
• SDR_POPID: 3- lub 4-literowy kod alfanumeryczny (SteamNetworkingPOPID) centrum danych (w produkcji). W środowisku programistycznym pozostaw to pole jako puste.
  
• SDR_PRIVATE_KEY: prywatny klucz z twojego certyfikatu. Jest to blok PEM OpenSSH, który zaczyna się od „-----BEGIN OPENSSH PRIVATE KEY-----”.
  
• SDR_CERT: twój podpisany certyfikat. Jest to nasz własny blok podobny do PEM, który zaczyna się od „-----BEGIN STEAMDATAGRAM CERT-----”.
  
• SDR_NETWORK_CONFIG: pełna ścieżka do lokalnej, najnowszej kopii pliku konfiguracji sieci SDR dla twojej aplikacji. Jeśli ta zmienna nie jest ustawiona, to w celu uzyskania konfiguracji sieci serwer pobierze kopię przy użyciu HTTP podczas uruchamiania. Aby uzyskać optymalną wydajność, możesz okresowo (np. raz na godzinę) pobierać najnowszą konfigurację i zapisywać ją lokalnie, aby zakłócenia sieciowe nie powodowały żadnej dezorganizacji – w ten sposób skonfigurowane są serwery Valve.

Uruchamianie w środowisku testowym

Z racji tego, że ISteamNetworkingSockets obsługuje zwykłe połączenia UDP, z reguły najlepiej jest zacząć od uruchomienia kodu przez ten interfejs za pośrednictwem UDP bez martwienia się o przekierowania.

Zalecamy, aby twój kod serwera używał zmiennej środowiskowej SDR_LISTEN_PORT, aby móc zdecydować, czy twój serwer powinien nasłuchiwać w poszukiwaniu SDR. Możesz użyć ISteamNetworkingSockets::GetHostedDedicatedServerPort, aby pobrać tę wartość.

W środowisku testowym musisz pozostawić zmienną SDR_POPID jako pustą. Gdy SDR_LISTEN_PORT i SDR_POPID są puste, POPID zostanie ustawiony na specjalny, 3-znakowy kod „dev”.

Ogólnie rzecz biorąc, uwierzytelnianie jest wyłączone na serwerach w środowisku testowym z kodem „dev” (zarówno klienty, jak i przekaźniki zezwalają na połączenia z serwerami z kodem „dev” bez podpisanego certyfikatu, o ile posiadają podpisany token). Potrzebny ci będzie inny mechanizm uwierzytelnienia z twoim koordynatorem gry. Z kolei twój koordynator gry musi zachować ostrożność podczas wydawania tokenów wszelkim serwerom uważającym się za posiadające kod „dev”!

Twój serwer musi mieć możliwość odbierania „niepożądanego” ruchu publicznego, co oznacza, że jeśli serwer nie ma publicznego adresu IP, to musisz skonfigurować przekierowywanie portów w swojej zaporze. Ponadto prawdopodobnie musisz ustawić wartość zmiennej SDR_IP na poprawny publiczny adres IP (oraz poprawny port, jeśli różni się od SDR_LISTEN_PORT).