Koszmary z UEFN Session Launch Timeout? Diagnozowanie Unreal Engine Network Drivers

Każdy techniczny deweloper gier zna tę frustrację, gdy przez trzy minuty wpatruje się w ekran ładowania, by na końcu zostać rozłączonym. Naciskasz „Launch Session”, czekasz na zakończenie faz walidacji i przesyłania, siedzisz w creative hub, podczas gdy assety się kompilują, a potem silnik bezceremonialnie wyrzuca Cię z powrotem do edytora z krytycznym komunikatem w logach.

Jeśli budujesz złożone doświadczenia multiplayer, napotkanie UEFN session launch timeout to niemal rytuał przejścia. Log edytora zazwyczaj wypluwa coś identycznego jak to:

LogNet: Warning: UNetConnection::Tick: Connection TIMED OUT. Closing connection.. Elapsed: 30.00, Real: 30.00, Good: 30.00, DriverTime: 151.46, Threshold: 30.00, [UNetConnection] RemoteAddr: 18.156.253.228:15009, Name: IpConnection_0, Driver: Name:IpNetDriver_0 Def:BeaconNetDriver IpNetDriver_0, IsServer:

To nie jest przypadkowy błąd sieci. To bardzo konkretna kolizja architektoniczna między rygorystycznymi progami networkingowymi Unreal Engine a ciężkimi, blokującymi operacjami wymaganymi do kompilacji i synchronizacji custom assetów.

W tej technicznej analizie rozłożymy na czynniki pierwsze znaczenie tego logu, wyjaśnimy, dlaczego stos networkingowy Unreal Engine zachowuje się w ten sposób i jak projektować projekty, aby zapobiegać tym timeoutom — niezależnie od tego, czy pracujesz w ograniczeniach UEFN, czy budujesz własne dedicated servers w UE5.

Dekonstrukcja logu UNetConnection Timeout

Aby naprawić problem, musisz najpierw zrozumieć telemetrię, którą dostarcza Unreal Engine. Przeanalizujmy zmienne w tym ostrzeżeniu LogNet:

• Elapsed: 30.00: To krytyczny wskaźnik. Oznacza, że minęło dokładnie 30 sekund, odkąd klient ostatnio otrzymał ważny pakiet sieciowy (lub heartbeat) od serwera.
• Threshold: 30.00: To zakodowany na sztywno limit zdefiniowany przez zmienną ConnectionTimeout w konfiguracji network drivera silnika. Gdy Elapsed osiągnie Threshold, połączenie jest bezlitośnie zrywane.
• DriverTime: 151.46: Network driver działa łącznie przez około 2,5 minuty. Mówi nam to, że początkowe połączenie powiodło się, ale kolejna operacja blokująca spowodowała 30-sekundową ciszę.
• Def:BeaconNetDriver: To jest kluczowy dowód. Unreal Engine używa BeaconNetDriver do obsługi lekkiej komunikacji przed połączeniem — jak rezerwacja slotu gracza czy sprawdzanie kompatybilności wersji — przed przejściem do głównego IpNetDriver dla rozgrywki.

Gdy projekt UEFN przesyła custom assety na serwer live edit, klient łączy się przez beacon. Jeśli jednak Twoja lokalna maszyna lub zdalny serwer są całkowicie obciążone kompilacją nieoptymalnych shaderów lub walidacją ciężkiego kodu Verse, główny wątek (main thread) zostaje zablokowany. Jeśli wątek blokuje się na ponad 30 sekund, pakiety keep-alive nie są wysyłane. Beacon uznaje, że klient uległ awarii i zrywa połączenie.

Dlaczego Live Edit pogarsza sprawę

Architektura Live Edit w UEFN to cud nowoczesnego projektowania silników gier, ale działa pod ogromnymi ograniczeniami. Kiedy uruchamiasz sesję, edytor musi spakować zmodyfikowane assety, przesłać je do instancji hostowanej przez Epic, a następnie nakazać lokalnemu klientowi Fortnite połączenie się z tą instancją.

Jeśli pracujesz z dużymi importowanymi meshami, masywnymi tablicami tekstur lub złożonymi ścieżkami audio, faza „Czekaj w creative hub na kompilację” staje się wąskim gardłem. Serwer oczekuje, że klient szybko przejdzie z huba do stanu gry live. Gdy klient utknie na lokalnej kompilacji 4000 shaderów, network tick zostaje zagłodzony.

To lokalna wersja szerszego problemu silnika. W rzeczywistości, jeśli zmagasz się z synchronizacją przestrzenną po dużym obciążeniu, możesz zapoznać się z naszym przewodnikiem How To Fix Player Location Desync In Uefn And Unreal Engine Multiplayer.

Naprawa Timeoutu w Standardowym Unreal Engine 5

Podczas gdy UEFN uniemożliwia edycję niskopoziomowych plików konfiguracyjnych silnika, zrozumienie, jak rozwiązać ten problem w standardowym Unreal Engine 5, jest obowiązkowe dla deweloperów planujących przejście na własne dedicated servers.

W standardowym projekcie UE5 możesz bezpośrednio manipulować wartością Threshold, która spowodowała błąd. Domyślnie Unreal Engine ustawia network timeouty bardzo agresywnie, aby zapobiec zużywaniu pamięci serwera przez martwe połączenia.

Aby zwiększyć ten próg, musisz zmodyfikować plik DefaultEngine.ini. Oto dokładna konfiguracja potrzebna, aby dać klientowi więcej swobody podczas ciężkiej kompilacji assetów:

; DefaultEngine.ini

[/Script/OnlineSubsystemUtils.IpNetDriver]
; Increase standard connection timeout to 120 seconds
ConnectionTimeout=120.0
; Give the initial connection phase even more time (150 seconds) for heavy map loads
InitialConnectTimeout=150.0

[/Script/Engine.NetDriver]
ConnectionTimeout=120.0
InitialConnectTimeout=150.0
KeepAliveTime=0.2
MaxClientRate=100000
MaxInternetClientRate=100000

Zwiększając timeout z 30 do 120 sekund, pozwalasz klientowi zakończyć operacje blokujące (jak kompilacja shaderów czy ładowanie assetów przy seamless travel) bez zrywania połączenia przez serwer.

Dynamiczna regulacja Timeoutu przez C++

Ustawienie na sztywno 120-sekundowego timeoutu w pliku INI to mało precyzyjne narzędzie. 2-minutowy timeout oznacza, że jeśli gracz rzeczywiście ulegnie awarii, serwer trzyma jego aktora i zasoby sieciowe w pamięci przez pełne 120 sekund, marnując cykle CPU i RAM. Aby dowiedzieć się więcej o tym, jak marnowane zasoby serwera wpływają na koszty, sprawdź naszą analizę Architecting Zero Waste Servers The Fortnite Server Optimization Hibernation Proposal Analyzed.

Znacznie lepszym podejściem dla gier UE5 jest dynamiczne dostosowywanie progu timeoutu tylko wtedy, gdy wiesz, że nastąpi ciężka operacja blokująca (np. ładowanie ogromnej mapy open-world).

Oto implementacja C++ pokazująca, jak uzyskać dostęp do UNetConnection i tymczasowo wydłużyć timeout podczas fazy ładowania:

#include "Engine/NetConnection.h"
#include "GameFramework/PlayerController.h"

void AMyPlayerController::PrepareForHeavyMapLoad()
{
    // Retrieve the active network connection for this player
    if (UNetConnection* NetConnection = GetNetConnection())
    {
        // Store the original timeout to restore later
        float OriginalTimeout = NetConnection->GetTimeoutValue();
        
        // Temporarily boost the timeout to 180 seconds to survive heavy asset compilation
        NetConnection->SetTimeoutValue(180.f);
        
        UE_LOG(LogTemp, Warning, TEXT("Adjusted connection timeout from %f to 180s for loading phase."), OriginalTimeout);
        
        // TODO: Bind a delegate to the map load completion to restore OriginalTimeout
    }
    else
    {
        UE_LOG(LogTemp, Error, TEXT("Failed to retrieve UNetConnection. Player may already be disconnected."));
    }
}

Ten kod zapewnia, że gracze przetrwają ekran ładowania bez trwałego pogarszania zdolności serwera do szybkiego usuwania faktycznie utraconych połączeń.

Najlepsze praktyki zapobiegania Timeoutom sesji

Jeśli pracujesz w UEFN i nie możesz edytować DefaultEngine.ini, musisz rozwiązać problem poprzez optymalizację payloadu, a nie wydłużanie timeoutu. Oto pięć praktycznych wskazówek:

1. Usuń nieużywane assety przed uruchomieniem: UEFN będzie próbował walidować i przesyłać assety znajdujące się w katalogu projektu, nawet jeśli nie są umieszczone na poziomie. Przenieś nieużywane meshe high-poly i tekstury 4K poza folder projektu.
2. Wymuś prekompilację shaderów: Jeśli używasz custom materials, upewnij się, że są w pełni skompilowane lokalnie przed uruchomieniem sesji. Częstą przyczyną 30-sekundowego timeoutu jest zamrożenie lokalnego klienta w celu kompilacji shaderów dokładnie wtedy, gdy serwer oczekuje network heartbeat.
3. Optymalizuj limity wykonywania kodu Verse: Ciężkie pętle OnBeginPlay w Verse mogą wstrzymać inicjalizację po stronie serwera. Rozbijaj masywne pętle inicjalizacyjne za pomocą Sleep(0.0), aby oddać wykonywanie do głównego wątku.
4. Zmniejsz złożoność kolizji: Złożone custom collision meshe wymagają znacznie więcej czasu na walidację w backendzie. Używaj prostych prymitywów typu box lub capsule tam, gdzie to możliwe.
5. Monitoruj przepustowość wysyłania (upload): Wskaźnik DriverTime tyka, podczas gdy klient przesyła zmiany. Jeśli masz łącze o niskiej przepustowości wysyłania (poniżej 20 Mbps), wypchnięcie 500 MB aktualizacji projektu prawie na pewno wywoła timeout.

Czynnik infrastruktury Backend

Kiedy przechodzisz z UEFN do budowania własnych samodzielnych gier multiplayer w Unreal Engine, przejmujesz odpowiedzialność za zarządzanie infrastrukturą backendową, która dyktuje te zasady sieciowe.

Obsługa session timeouts, load balancing dedicated servers i zarządzanie matchmakingiem wymaga wdrożenia menedżerów floty, takich jak Agones, lub pisania własnych warstw orkiestracji w Kubernetes. Samodzielne zbudowanie tego wymaga skonfigurowania database sharding, zarządzania certyfikatami SSL i routingu międzyregionowego — to łatwo 4 do 6 tygodni wyczerpującej pracy DevOps, zanim w ogóle zaczniesz pisać logikę gry.

To właśnie tutaj horizOn zmienia postać rzeczy. Dzięki horizOn te złożone usługi backendowe są wstępnie skonfigurowane specjalnie dla deweloperów gier. Zamiast zmagać się z orkiestracją serwerów i connection timeouts na AWS, otrzymujesz w pełni zarządzany Backend-as-a-Service, który automatycznie obsługuje skalowanie dedicated servers.

Podsumowanie

Napotkanie UEFN session launch timeout to frustrująca przeszkoda, ale także cenna lekcja tego, jak nowoczesne silniki gier obsługują stan sieci. Silnik po prostu wykonuje swoją pracę: agresywnie usuwa połączenia, które wydają się martwe, aby chronić stabilność serwera.

Gotowy, by przestać martwić się o infrastrukturę serwerową? Wypróbuj horizOn za darmo lub zajrzyj do dokumentacji API, aby zobaczyć, jak łatwo możesz dziś wdrożyć gotowe do produkcji serwery gier.