Events during a disconnection period

liortal53

Hi,

We are using Photon Cloud (Android/iOS clients).

My question is regarding client disconnections from Photon:

1. How can i determine the time it takes a client to determine it's disconnected from Photon? According to the docs, there are 2 values that control that - SentTimeAllowance and DisconnectTimeout, however the documentation is not very clear (to me).

2. In case of a transient disconnection (very brief, the client succeeds in reconnecting before Photon low-level code realizes it's disconnected). Is such a scenario possible? if so, what happens to events that were sent by some other player, while i was disconnected briefly? will i still get those delivered or not ?

Thanks !
Lior

Kaiserludi

Hi Lior.

2.
This depends on the chosen protocol, the reliability flag of a message and the size of that message.
In TCP all messages are always reliable, so if a message (or parts of it) that you sent, doesn't reach the other side, then TCP will resend the missing data.
UDP, in opposition to TCP, does not have a built-in reliability layer - it does not check, if any peace data has actually ever reached its target destination, so if a UDP packet gets lost on its way, it will not be repeated and never reach the receiver.
Photon however adds its own reliability layer on top of udp (basically an enet fork) -> if you specify true for the reliability flag of a message, then under the hood the receiving side will acknowledge that it has successfully received that message and if that acknowledgement does not arrive in time then the sending side will repeat that message. If a message does not fit into one udp packet, then Photon will split it up into several parts, called fragments. If a message gets sent in fragments, then it will always get sent reliably even if you have specified to send it unreliably, and each fragment will be acknowledged and if needed repeated on its own (which is the reason for why fragments will always be sent reliably: if just one of them is missing, then all other fragments of the same message would otherwise be useless).

So it comes down to this:

used protocol
tcp?

-> reliable

udp?

->

reliability flag
true?

-> reliable

false?

->

message size
> ca. 1kb

-> reliable

< ca. 1kb

-> unreliable

reliable -> your message will get delivered or a disconnect will get triggered
unreliable -> your message can get lost without a disconnect getting triggered



1.
This again depends on the chosen protocol.
If you use TCP, then only the DisconnectTimeout value is relevant -> the Photon client pings the server in intervals that can be controlled via TimePingInterval. If a ping does not get answered by the Photon server/cloud inside the timeframe of DisconnectTimeout milliseconds, then Photon will consider the connection lost and trigger a timeout disconnect.
If you use UDP, then Photon will only send a ping, whenever the time that has past since last reliable message (and not the time past since the last ping like for TCP) is bigger than TimePingInterval, with pings counting as reliable messages. So while with TCP Photon will always send pings, it only needs to send pings with UDP, when you have not sent something else reliably, for some time.
Additionally for UDP the Photon client will count the resends of a message or fragment for which it has not received an acknowledgement and compare that count against the value of SentCountAllowance. A timeout disconnect will be triggered by whatever of those 2 limits gets crossed first - DisconnectTimeout or SentCountAllowance. The client will specify in an error log message, which of both limits has been crossed.

liortal53

Thanks for the detailed response.

Regarding #2 - i already understand that reliability is handled via some ACK message sent back, however with Photon it is not clear who issues that ACK - the clients or your servers?

For example, in a game room with 4 participants, sending some custom event over the wire (reliably) will trigger ACKS for all room participants or from your servers?

If it is the latter, what guarantee do i have that the message actually reached its destination?

Kaiserludi

Its issued by the server and only guarantees that the server has received your message. The server then will get acks from the other clients that they have received the message and the server will resend it to clients, from which it did not receive an ack in time.
If a client doesn't ack at all, then the server will timeout disconnect it after a a short time (5-10 seconds for UDP, for TCP it depends on the OS TCP implementation, but should normally be nearly immediately). In that case the server will also send a leaveRoom message for that client to the other clients in the same room, but the other clients don't get any info if it has been a leave due to a disconnect (or even to what kind of disconnect) or a regular leave. So if your client receives a leave for another client, then that means, that for the last up to 10 seconds there is no guarantee that any message has actually reached that client. For messages for which you absolutely need a delivery guarantee you would have to let each receiving client send back a reliable message to the sender that contains the info that it has successfully received that message.