Clientside timeout setting
Options
It seems clear enough how to set the server TCP timeout setting from this page. http://doc.exitgames.com/photon-server/ServerConfig/
That page also says "Keep in mind that a client independently monitors a connection and might time it out as well. Both sides should have similar timeouts, fitting your game.".
Where can I find the setting for changing the clientside timeout value?
That page also says "Keep in mind that a client independently monitors a connection and might time it out as well. Both sides should have similar timeouts, fitting your game.".
Where can I find the setting for changing the clientside timeout value?
0
Comments
-
On the client you got even more control via: PhotonPeer.DisconnectTimeout, and PhotonPeer.SentCountAllowance.
DisconnectTimeout is the time in which a reliable command must be acknowledged (and thus no longer repeated). If this time passes for any given command, a timeout is happening.
SentCountAllowance sets how often any reliable command is repeated before it triggers a disconnect. Each subsequent repeat is done with a longer delay (to avoid congestion). A big value here effectively passes control to DisconnectTimeout.0 -
I'm looking for settings that would affect a TCP connection. DisconnectTimeout at least has no effect except on UDP.
Modifying SentCountAllowance seems to me a bit strange, given the large variance in possible round trip times a client could wait a really long or short time for disconnect. Also what happens for the first request? Since this is based on round trip time what would happen then?0 -
For TCP you can't currently control timeout on the DotNet client. We only made sure the client pings the server, which would have to update the remaining players in a room if someone left. On the client side, we don't timeout in TCP except for the default timeout it has.
What do you need? We might be able to add it...
SentCountAllowance might be a bit strange. It has a different angle to disconnecting. We don't want clients to resend stuff any number of times. If something doesn't go through, we want the client to stop instead of making the issue worse by repeating more and more messages.
Yes it depends on the roundtrip times but that's ok. Your RTT defines how fast you can expect something to reach the server, so a low, fixed timeout wouldn't guarantee several repeats.
We have a default RTT of 300 and 10ms variance. It gets immediately updated with the initial ACK (which is usually slower than subsequent ones, so RTT improves a bit).0
