Experiencing disconnections (error 1040)
Options
Hey,
We're using the Android NDK library for our game.
Lately we've started experiencing many disconnections during gameplay (getting ERROR 1040). Tests were performed on devices using both WIFI and 3G connections.
I'd like to know if there's any good way to diagnose this issue?
Specifically i think of a few potential issues that may cause this:
1. Time being calls to service() - i couldn't find anything in the docs related to the frequency needed to call this function. I've seen that some of our code seems to be doing "too much work" in the context of calling this function, which causes this to be called too infrequently (need to measure exactly how infrequently - seems to be in the range of hundreds of ms.).
2. Sending too much data -- we are using unreliable UDP for our communications. Also, some of our packets tend to be very large (around ~ 3k - 5.5k). This leads to fragmentation, however i couldn't find anything in the documentation to suggest that this will lead to disconnections.
3. Looking in the logs produced by Photon (by the native lib) -- does it give any warnings regarding upcoming "potential" disconnections? (e.g: you're sending too much data? or not calling service() enough, etc)
Any suggestions on how to diagnose this issue will be helpful!
Thanks
Lior
We're using the Android NDK library for our game.
Lately we've started experiencing many disconnections during gameplay (getting ERROR 1040). Tests were performed on devices using both WIFI and 3G connections.
I'd like to know if there's any good way to diagnose this issue?
Specifically i think of a few potential issues that may cause this:
1. Time being calls to service() - i couldn't find anything in the docs related to the frequency needed to call this function. I've seen that some of our code seems to be doing "too much work" in the context of calling this function, which causes this to be called too infrequently (need to measure exactly how infrequently - seems to be in the range of hundreds of ms.).
2. Sending too much data -- we are using unreliable UDP for our communications. Also, some of our packets tend to be very large (around ~ 3k - 5.5k). This leads to fragmentation, however i couldn't find anything in the documentation to suggest that this will lead to disconnections.
3. Looking in the logs produced by Photon (by the native lib) -- does it give any warnings regarding upcoming "potential" disconnections? (e.g: you're sending too much data? or not calling service() enough, etc)
Any suggestions on how to diagnose this issue will be helpful!
Thanks
Lior
0
Comments
-
Hi lior.
1.
You should normally call service() several times a second / every few frames.
Depending on how much data you send and receive it may make sense to call it much more often in certain situations (or to do additional direct calls to dispatchIncomingCommmands() and sendOutgoingCommands() (service() internally also just calls those 2 + serviceBasic())).
2.
When sending bigger operations, please keep in mind, that udp packets are limited in size. You should usually calculate with a bit over 1kb of payload data per udp packet. If your operations are bigger than that, then Photon has to split them up into several fragments. As all the other fragments of the same operation get useless, when only one fragments gets lost on its way, Photon always sends fragmented operations reliably, even if you have specified to send an operation unreliably. This also implies that if one packet can't get trough before the timeout or the max amount of retries triggers, then Photon will assume that you are not longer connected, although you have specified to send that operation unreliably.
If you send really big operations (dozens of kb per operation) or if you send those 3k-5.k operations quite often, then you should definitely monitor your queues on sending and receiving side, to make sure that your data isn't queuing up too much on either side, because you may not call sendOutgoingCommands() or dispatchIncomingCommand often enough a you should for those amounts of data.
3.
You will get a warning message each time when a queue reaches its warning threshold (100 elements).
You will also get an info message each time when a command needs to get repeated.0
