I have a simple question about the overhead of Nakama’s message. When a user sends a match state message, does it include the userID? And when a match broadcasts a match message with a non-empty sender?
In the case of Darkrift, their ClientID only takes 2bytes. But Nakama uses 32bytes UserID. So I am just curious about Nakama’s overhead.
Hello @mautoan11, is there a specific network bandwidth concern regarding the messages?
The UUID length is usually neglegible, we’ve used this pattern at scale in production for a number of Heroic Cloud customers without issue, the important thing is to keep the data payload of the messages as slim as possible.
Also worth noting that if you use Nakama’s authoritative multiplayer feature you can omit the message sender user ID entirely, or use your own shorter one - even a single bit if you’re building a 2-player game.
Ultimately the default message structure you probably see when using Nakama’s relayed multiplayer is intended to work across many thousands of matches and a large cluster of nodes, uniquely identifying users and matches in a massive concurrent usage scenario. This is something DarkRift and similar solutions aren’t suited to, they’re optimised for dedicated headless server instance use cases.
Thank you very much for your replies!
By the way, could you provide the full overhead of a matchstate message?
Sorry, I want to check it because currently, my payload has only 12bytes. I want to measure the overhead.