QueueOutgoingReliableWarning?

void.pointer

When connected to the photon socket server (which uses mostly the MMO demo server code), after a while I get a IPhotonPeerListener.PeerStatusCallback with a return code of "QueueOutgoingReliableWarning". Why would this happen? The error alone doesn't make much sense.

Boris

It's a warning that says that there are many outgoing reliable messages queued, including package ACKs.
This can have several causes:
1) not calling service() often enough, maybe because of a slow frame rate
2) connection issues: earlier reliable packages were not acknowledged, so the lib refuses to send more until the previous packages are received and more and more operations are queued
3) too many incoming reliable events that cannot be acknowledged fast enough

The default settings of the server allows sending up to 1 Mbit/s.
With the MMO demo the warning might occur if there are a few hundred clients and then you suddenly increase or decrease the interest area and get all the reliable itemsubscribed events at once. This is nothing you will want to allow in a real game.
You can set a lower speed limit with the setting "PerPeerTransmitRateLimitKBSec".
On the downside this might introduce lags because the server will just queue the reliable packages and send them later.
I wouldn't worry about the warning too much if the warning occurs just once, but if it keeps happening you might want to reduce the number of reliable events that are being sent in a very short time - either by lowering PerPeerTransmitRateLimitKBSec, or by changing the causing business logic.

void.pointer

Thanks for the help Boris.

I double checked on all of your points but I am still unable to figure out what's wrong. Basically we're sending Move operations from the client about 20 times every second (I even tried only sending 2 per second). Over time, I start getting that QueueOutgoingReliableWarning. It's almost as if the operations aren't being sent at all.

After the client has been connected for a while (probably like 2-3 minutes) I also get this in the client in unity:

Session.DebugReturn: tcp run() error receiving! Exception: System.Net.Sockets.SocketException: Connection reset by peer
at System.Net.Sockets.Socket.Receive (System.Byte[] buf, Int32 offset, Int32 size, SocketFlags flags) [0x00000]
at ExitGames.Client.Photon.TConnect.Run () [0x00000]

Not sure what's going on.

Boris

mh, that's indeed weird. so you use TCP, not UDP?
I was referring to UDP, so this is different.
Tobias knows more about the client lib, so let's wait for what he says...

Boris

by the way.. 20 updates per second over tcp seems a bit too much.
Why don't you use UDP?

void.pointer

Sorry for the confusion, but I found the reason for the QueueOutgoingReliableWarning. We indeed were not calling service() because we accidentally were destroying objects in unity that called that on a regular basis. Now that this is fixed, can we address the "tcp run()" exception I'm getting? I believe we received this way before this regression.

Also, we will use UDP in the future but right now we're just doing R&D to test out how Photon works and to learn it. We're not too worried about optimizations right now. But thanks for the advice. I changed it to send 2 move updates per second and the clients can just lerp the items to make movements look smooth.

void.pointer

Boris wrote:

by the way.. 20 updates per second over tcp seems a bit too much.
Why don't you use UDP?

Also, I thought "Reliable" stood for Photon's implementation of reliable UDP. I recall reading in the documentation that you do have a reliable UDP implementation in Photon. Maybe I'm mistaken? It would be nice to use UDP for the whole game, since mixing TCP & UDP can cause latency issues from what I hear.

dreamora

To send reliable UDP messages, you choose to not use TCP in the init of the connection and send it as reliable in the OpRaiseEvent for example.

Boris

the mmo demo uses 10 updates/sec, that's usually a good number to show a smooth movement.
as dreamora says here, with UDP you can choose for each operation to send it reliable or unreliable.
Movement updates are ok to send unreliable because it doesn't matter if you lose one package in between.