SendReliable Expectations

brunko

Hello,

I was wondering if there are any predictable expectations with using the sendReliable flag on an operation. For instance, if I have a Move operation that is sent unreliably and a Chat operation that is sent reliably (on the same channel) and they are sent on the same frame, can I predictably expect that the Move operation will not reach the server? Or that it may reach the server but will be sent after the Chat operation? Do these expectations change if they are on separate channels?

Kaiserludi

- For unreliable you can only predict, that the client tries to send it (, although under normal network-quality conditions you can assume, that most unreliable stuff will successfully be sent).
- For reliable data you can expect, that either the data will successfully be sent or you will get a timeout disconnect, if the client can't get an acknowledgement, that the server received that data, before reaching either the maximum retries or the maximum retry time (both values can be changed by you, if the defaults does not suit your game).
- Furthermore for reliable data you can expect, that if a packet does not get trough, all other packets (also unreliable ones) in that channel will be left in the clients outgoing queue and not been sent, until that reliable packet successfully got received by the server.
In general the data will be sent in the order, in which you have put it in the outgoing queue of the channel.
- An unreliable operation will be treated as reliable, if it is to big for a single packet.
- data in different channels will be treated as independent from each other, meaning data in channel 0 has not to wait for reliable data in channel 1, which might get resent.
- priority of channels is lowest to highest, meaning if you sendOutgoingCommands() is called, then the Photon Client will first check in channel 0, if there is anything, which can be sent, then channel 1, then channel 2, and so on, until the maximum packet size is reached, which means, the rest of the data has to wait for the next call to sendOutgoingCommands()
- if an unreliable command can't not get out with the first call to sendOutgoingCommands(), as there is no room anymore in the packet, then it will stay in the clients local outgoing queue and not get lost, same as a reliable one does not get lost. Reliability is only relevant for retries in case, that a command successfully gets out, but never gets received by the server.
- if on the one hand you have data, which has to get out quickly, before it is outdated and can be sent unreliable as the next update will come very soon anyway, like position updates, and on the other hand you have data, which isn't that time-sensitive and can wait a few hundred ms, if it have to, but should not get lost, like chat-data, then I would recommend to send that unreliable postion-updates in channel 1 and that reliable chat-messages in channel 1.