PhotonServer.config for UDP

retroactive

Hi,

i tried to modify our PhotonServer.config so that our S2S connection (UDP!) won't disconnect so easily.
Could you help me with these parameters:

* MaxQueuedDataPerPeer <- why is it only possible to change this globally not per UDPListener?
* RecvBufferSize & SendBufferSize <- Descriptions says "See TCPListener" but for TCP this means TCP window size.
Does this describe the Buffer for R-UDP in Photon?

Malte

[Deleted User]

Hey Malte,

first, I'd like to ask why you are using UDP for S2S-connections. In general, UDP is great for unreliable communication. For S2S, where you usually want to have reliable data transfer, we recommend to use TCP, it's in general more efficient than UDP in these cases.

Second, the settings you mentioned will probably not fix any disconnect issues. Rather then "playing around" with these settings, you need to have a closer look why your connections break down.

Please check your log files on the "sending" and the "receiving" Photon instance. What is the reason for disconnects? I assume you have timeout disconnects on one side and client disconnects on the other side.

This would mean that your connection is so "overloaded", that ACKs are not received in time -> this causes a timeout & disconnect. This won't be fixed by the settings you mentioned. Please review how to reduce / distribute the data over time.

Another option is that "flow control" kicks in. Flow control is a mechanism that should prevent Photon from "overloading" a client. If Photon sends more data than a client can receive (either a "game client" or a receiving end of a S2S connection), these settings define how much data Photon can buffer, until it raises a "SendBuffer full" event. The default behavior for a "SendBufferFull" is a disconnect. Please have a look at your log files: if you see "SendBuffer full" disconnect messages, there are several options:

You *can* increase some config parameters (especially: you mentioned, but it only means that Photon buffers more data, which gives the receiving side a bit more time to recover & process the data. The values that affect UDP flow control would be:
- PerPeerMaxReliableDataInTransit
- PerPeerTransmitRateLimitKBSec
- MaxQueuedDataPerPeer

You could (and should) also override the OnSendBufferFull method and "pause" the sending for a while, until you receive a call to "OnSendBufferEmpty".

Both will only help if the receiving side "catches up" after a short time. If you frequently send more data than the receiving side can process, you definitely need to find a way to reduce the amount of data you are sending. And, as I said, it would only help if you actually see disconnects for SendBufferFull.

I can probably give more advice if you let us know a few more details about your setup, amount of sent data, etc. - or create a performance counter log of the Photon performance counters and send it to me, so that I can have a look what the problem is, ideally together with some log file snippets that show the disconnect (on both ends).

retroactive

hi nicole,

sorry i should have provided more info. i am a colleague of david who asked about a tcp disconnection problem here:
viewtopic.php?f=5&t=3393

i just changed the s2s connections to UDP as suggested. When we were still using TCP we got a "ClientDisconnect" on BOTH ends.
I guess the whole connection between datacenters is gone for a few seconds. We haven't had a disconnect with UDP yet. But these disconnects only occur every few days. As your UDP is reliable i guess you can already define your own timeouts and number of pakets stored in buffers etc. That's why I aksed how to increase those to make sure the servers can handle some secs without response.

It's not about load, every server was just idling.

"The values that affect UDP flow control would be:
- PerPeerMaxReliableDataInTransit
- PerPeerTransmitRateLimitKBSec
- MaxQueuedDataPerPeer"

Is it possible to change these values per peer/listiner? I don't want to change these for the normal GameCients.

Malte

[Deleted User]

Hey Malte,

thanks for the explanation.

There is no benefit for your setup if you change any of these settings. They are all related to high traffic or burst traffic scenarios.

The only thing that might make your S2S connection more stable is the MinimumTimeout / MaximumTimeout setting (the max. value is 1 minute there). Unfortunately, that is "per instance" as well and not per listener... when we originally designed that, we did not plan to do any S2S-UDP at all, so we thought that it was sufficient to have one timeout for all UDP connections. So the downside is that it would take you longer to notice if game clients are gone.

We'll need to have an internal discussion here if we want to make these settings "per listener". I agree that this might be useful.

Sorry that I could not give you any better answers right now.

David

Does this mean anything to you:

ServerDisconnect CCallbackTimerWheel::CalculateTimeout() - Timeout is too long. Max is: 120000 tried to set: 192534526 (192534513) - now = 4102432783 m_currentTime = 4102432770

Both applications are running on the same machine (!) using S2S UDP.