Reliable network event overflow in FiveM: Finde das Script und behebe es

Ein Spieler wird aus dem Server geworfen, oder der ganze Server startet zu tim out, mit einer Nachricht wie dieser:

Reliable network event overflow

FiveM hält eine begrenzte Queue von zuverlässigen Netzwerk-Events für jede Verbindung. Wenn ein Script sie schneller füllt, als die Verbindung senden kann, wird der Spieler abgebrochen. Die Ursache ist fast immer eine Ressource. Hier ist, wie man sie findet und behebt.

#Was passiert

Jedes TriggerClientEvent und TriggerServerEvent ist eine zuverlässige Nachricht: sie muss ankommen, in Reihenfolge. Wenn du viele von ihnen sendest, oder sehr große, wächst die Queue für diesen Spieler. Wenn sie überläuft, wird die Verbindung unterbrochen.

Die üblichen Muster:

• Eine große Tabelle, die in einem Event gesendet wird: eine vollständige Liste von Fahrzeugen, Items, Spielern, oder eine ganze Config.
• Eine Schleife, die ein Event auf jedem Tick oder alle paar Millisekunden triggert.
• Ein Event, das an alle (-1) viele Male pro Sekunde gesendet wird.
• Ein Script, das die gleichen Daten wieder und wieder sendet, wenn sich nichts geändert hat.

-- bad: sends everything, to everyone, every 100 ms
CreateThread(function()
    while true do
        Wait(100)
        TriggerClientEvent('myscript:update', -1, GetAllData())
    end
end)

#Finde die Ressource

Die Fehlermeldung nennt das Script nicht, also musst du messen.

1. Schaue auf die Server-Konsole um die Zeit der Kicks. Viele identische Event-Namen, oder eine Ressource, die kurz vor den Problemen startete, ist ein Hinweis.
2. Verwende den Profiler. Der eingebaute Profiler zeichnet eine kurze Sitzung auf und lässt dich sie in einem Viewer öffnen. In der Server-Konsole:

profiler record 500
profiler view

Überprüfe die genauen Befehle für deinen Server-Build, da sie sich zwischen Versionen ändern können. Die Aufzeichnung zeigt, welche Ressourcen und Events Zeit brauchen, und hilft dir, die schwere zu finden.

3. Stoppe Ressourcen nacheinander auf einem Test-Server. Wenn die Kicks aufhören, nachdem du eine Ressource stoppst, hast du sie gefunden.
4. Suche den Code nach TriggerClientEvent und TriggerServerEvent in Schleifen, und für Events, die mit -1 gesendet werden.

Tipp: Das Problem beginnt oft, nachdem du ein neues Script hinzufügst, oder nach einem Script-Update. Überprüfe, was zuerst geändert wurde.

#Behebung 1: sende kleinere Payloads

Sende nur, was sich geändert hat, nicht den ganzen Datensatz.

-- bad: the whole table
TriggerClientEvent('shop:sync', src, allShops)

-- better: only the changed entry
TriggerClientEvent('shop:updateOne', src, shopId, shops[shopId])

Entferne Felder, die der Client nicht braucht, sende IDs anstelle ganzer Objekte, und lass den Client Details anfordern, wenn es sie braucht.

#Behebung 2: sende weniger oft

Trigger Events, wenn etwas passiert, nicht auf einem Timer. Wenn du einen Timer brauchst, mache ihn langsamer und überspringe ihn, wenn sich nichts geändert hat.

local last = nil

CreateThread(function()
    while true do
        Wait(2000)
        local data = GetData()
        if data ~= last then
            last = data
            TriggerClientEvent('myscript:update', -1, data)
        end
    end
end)

Sende an die Spieler, die es brauchen, nicht an -1, wenn nur einige Spieler kümmern.

#Behebung 3: latente Events für große Daten

Wenn du wirklich viele Daten senden musst, wie eine große Config oder ein Bild, verwende ein latentes Event. Es sendet die Daten im Hintergrund mit einer Geschwindigkeit, die du setzt, in Bytes pro Sekunde, anstatt die normale Queue zu füllen.

-- server -> client, 50 KB/s
TriggerLatentClientEvent('myscript:bigData', src, 50000, bigTable)

-- client -> server
TriggerLatentServerEvent('myscript:bigData', 50000, bigTable)

Das Event kommt später an, also verwende es nur für Daten, die nicht zeitkritisch sind. Wähle eine Geschwindigkeit, die die Verbindung des Spielers nicht sättigt.

#Behebung 4: State Bags für gemeinsamen Zustand

Wenn die Daten der Zustand einer Entity oder eines Spielers sind (ein Flag, ein Wert, ein Status), ist eine State Bag oft besser als Events. FiveM repliziert Änderungen für dich, und sendet nur, was sich geändert hat.

-- server
Player(src).state:set('isCuffed', true, true)

-- client, anywhere
local cuffed = LocalPlayer.state.isCuffed

State Bags sind für kleine Werte, nicht für große Tabellen. Lese FiveM State Bags erklärt, um wie sie funktionieren, und Client und Server Events in FiveM für die Grundlagen von Events.

#Wenn du das Script nicht bearbeiten kannst

Wenn das Script eine bezahlte oder geschützte Ressource ist, kannst du ihren Code nicht ändern. Melde das Problem dem Autor mit dem Profiler-Ergebnis und der Zeit der Kicks. Sie werden wissen, welches Event zu groß ist. Bis dahin ist das Stoppen der Ressource oder das Senken ihrer Aktualisierungsrate in ihrer Config, wenn sie eine hat, der einzige Workaround.

#Checkliste