GNet timeout?

BlitzMax Forums/BlitzMax Programming/GNet timeout?

Arska(Posted 2015) [#1]
Hello!

I was programming with my low end laptop and i encountered problem with gnet. Looks like server is little bit trigger happy to remove player when it takes too long to get in game and sync GNet. Any way to get around this? GNet timeout is not the case.

My game loads every entity's info from server and there might be over 1000 of these. Slow computer takes little bit more time to do this, so server kicks out. Little bit more means 1-3 seconds longer, but it's enough for gnet to throw out.

This is not happening with high-end PC:s even though FPS is same in-game with both computers. (Static 60)

Any ideas?


Derron(Posted 2015) [#2]
Gnet itself does not seem to have "timeouts" set.

The only "time out" they use is in "enet_host_service()". They use "0", which means that only currently available events (enet is event driven) are returned. If you replace that 0 with 100 it will wait 100ms for incoming events. But this seems not to be the timeout you are searching.

I assume the "timeout" above is used to "gently" disconnect peers (give enough time for packets still on their travel between host/peer).


Ok ... let's check other timeouts:
pub.mod/enet.mod/enet.h: Line 175
   ENET_PEER_TIMEOUT_LIMIT                = 32,


pub.mod/enet.mod/protocol.c is using this variable
       if (outgoingCommand -> roundTripTimeout == 0)
       {
          outgoingCommand -> roundTripTimeout = peer -> roundTripTime + 4 * peer -> roundTripTimeVariance;
          outgoingCommand -> roundTripTimeoutLimit = ENET_PEER_TIMEOUT_LIMIT * outgoingCommand -> roundTripTimeout;
       }


Problematically it seems to do the calculation this way:
"if noOtherTimeGiven then time = ENET_PEER_TIMEOUT_LIMIT * peerRoundtriptime"

Means: the slow computer normally responds fast enough - which makes his roundtriptime low enough, now you run into your "big load loop" - roundtrip time increases above "problematic value".


Ok .. you have 3 options (I can think of):
a) increase ENET_PEER_TIMEOUT_LIMIT (Maybe adjustments to roundTripTimeout are equal in this case) - but what if the computer is even slower?
b) update enet/gnet while loading -> after loading something, update gnet (even if no packet was received meanwhile)
c) use threading and do networking in a separate thread which is not blocked by resource loading


Just for simplicity: try variant b). It will work as long as you do not have a single resource of some gigabytes getting loaded. In that case even your resource loader must be changed to do it "chunk by chunk" and inbetween run the network update code (or a general "system update code").


bye
Ron


Arska(Posted 2015) [#3]
Thanks for very detailed answer, Derron. I'll try that our when i get myself to slower computer.


Derron(Posted 2015) [#4]
Just add a "delay(xxx)" in your load-ressource to emulate that problem.


bye
Ron