Débordement d'événement réseau fiable dans FiveM : trouvez le script et corrigez-le

Un joueur est jeté hors du serveur, ou tout le serveur commence à expirer, avec un message comme ceci :

Reliable network event overflow

FiveM garde une file d'attente limitée d'événements réseau fiables pour chaque connexion. Quand un script la remplit plus vite que la connexion ne peut envoyer, le joueur est déposé. La cause est presque toujours une ressource. Voici comment la trouver et la corriger.

#Qu'est-ce qui se passe

Chaque TriggerClientEvent et TriggerServerEvent est un message fiable : il doit arriver, dans l'ordre. Si vous envoyez beaucoup d'entre eux, ou de très grands, la file d'attente pour ce joueur grandit. Quand elle déborde, la connexion est coupée.

Les motifs habituels :

• Une grande table envoyée dans un événement : une liste complète de véhicules, d'articles, de joueurs, ou un config entier.
• Une boucle qui déclenche un événement à chaque tick ou toutes les quelques millisecondes.
• Un événement envoyé à tout le monde (-1) plusieurs fois par seconde.
• Un script qui envoie les mêmes données à nouveau et à nouveau, quand elles n'ont pas changé.

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

#Trouvez la ressource

Le message d'erreur ne nomme pas le script, vous devez donc mesurer.

1. Regardez la console du serveur au moment des expulsions. Beaucoup de noms d'événements identiques, ou une ressource qui a commencé juste avant les problèmes, est un indice.
2. Utilisez le profileur. Le profileur intégré enregistre une courte session et vous permet de l'ouvrir dans une visionneuse. Dans la console du serveur :

profiler record 500
profiler view

Vérifiez les commandes exactes pour votre version du serveur, car elles peuvent changer entre les versions. L'enregistrement montre quelles ressources et événements prennent du temps, et vous aide à repérer le lourd.

3. Arrêtez les ressources une par une sur un serveur de test. Si les expulsions s'arrêtent après avoir arrêté une ressource, vous l'avez trouvée.
4. Recherchez le code pour TriggerClientEvent et TriggerServerEvent à l'intérieur des boucles, et pour les événements envoyés avec -1.

Conseil : le problème commence souvent après que vous ajoutez un nouveau script, ou après une mise à jour de script. Vérifiez d'abord ce qui a changé.

#Correction 1 : envoyer des charges utiles plus petites

Envoyez seulement ce qui a changé, pas tout l'ensemble de données.

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

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

Supprimez les champs que le client n'a pas besoin, envoyez des IDs au lieu d'objets entiers, et laissez le client demander les détails quand il en a besoin.

#Correction 2 : envoyer moins souvent

Déclenchez les événements quand quelque chose se passe, pas sur un minuteur. Si vous avez besoin d'un minuteur, faites-le plus lent et sautez-le quand rien n'a changé.

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)

Envoyez aux joueurs qui en ont besoin, pas à -1, quand seuls certains joueurs se soucient.

#Correction 3 : événements latents pour les gros données

Quand vous devez vraiment envoyer beaucoup de données, comme un grand config ou une image, utilisez un événement latent. Il envoie les données en arrière-plan à une vitesse que vous définissez, en octets par seconde, au lieu de remplir la file d'attente normale.

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

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

L'événement arrive plus tard, utilisez-le seulement pour les données qui ne sont pas critiques pour le temps. Choisissez une vitesse qui ne sature pas la connexion du joueur.

#Correction 4 : sacs d'état pour l'état partagé

Si les données sont l'état d'une entité ou d'un joueur (un drapeau, une valeur, un statut), un sac d'état est souvent mieux que les événements. FiveM reproduit les changements pour vous, et envoie seulement ce qui a changé.

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

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

Les sacs d'état sont pour les petites valeurs, pas pour les grandes tables. Lisez les sacs d'état FiveM expliqués pour savoir comment ils fonctionnent, et les événements client et serveur dans FiveM pour les bases des événements.

#Si vous ne pouvez pas modifier le script

Si le script est une ressource payante ou protégée, vous ne pouvez pas modifier son code. Signalez le problème à l'auteur avec le résultat du profileur et l'heure des expulsions. Il saura quel événement est trop gros. Jusqu'à ce moment-là, arrêter la ressource ou réduire son taux de rafraîchissement dans son config, s'il en a un, est le seul contournement.

#Liste de contrôle