Broadcast different ways

Runtime Framework
1

Hello again! :slight_smile:

Using the nakama framework in go.

Is there any difference between broadcasting one message containing 10 presences vs broadcasting one message 10 times to 1 presence each?

Cheers!

2

Hi @gruset,

When broadcasting to multiple presences at once, all presences will be validated at once and if any are deemed invalid (e.g. nil or an invalid session id) then the entire broadcast will not occur.

Beyond that the differences are minimal. My advice would be to send to multiple presences at once where possible (i.e. the payload is the same), but it is perfectly reasonable to send to individual presences especially when you need to send players different data.

3

Hello @tom and thanks for the reply.

This gave me comfort in continuing down this path. Ive encountered a tricky problem that needed to be solved by sending sending the message to each individual presence instead of every presences in one broadcast call. Thanks!

1 Like
4

@tom I have additional question on this topic…
If broadcasting message to multiple presences at once will be stopped if any are deemed invalid, then does this makes this function kind-a reduntant vs manually issuing to each presence a message?

My reasoning:

  • Suppose we are playing against 4 people, and we are trying to broadcast a message to all…Suddendly before message was broadcasted and while i was sending a message to the server to broadcast it to all, a one user is disconnected…

  • When this message is attempted to be sent from server, since presence is no longer valid for that one user, the whole message would be discarded, but that sounds like well bad choice to do as rest players are perfectly able to proceed.

  • Maybe this api should be tweeked to behave a bit differently regarding is match is in authorative mode vs relayed, but even in that case in same scenario again it doesn’t make sense to use it.

If we are not gainning any speed, just a potential hidden issue why something is not working which is a bit harder to track and debug aint then better to always use broadcasting to single user same message individually…Forst case if it fails to deliver that message client side , upon returnal of that user, it would fetch new state from the server thus no big loss?

5

Also this is a very good thing to be noted in documentation as it may change some design principles around match loop and broacasting messages.

6

Hi @Eatos,

I think there appears to be some confusion about what an “invalid” presence is here. An invalid presence refers to a presence which is nil or whose Session ID is invalid (i.e. not a valid UUID). It does not refer to a presence that has disconnected.

In the situation you described, where a presence has disconnected as you attempt to BroadcastMessage, that presence will not be deemed “invalid” and therefore the broadcast will continue successfully.

You can look at the actual validation logic in GitHub if that helps.