[Freeciv-Dev] Re: (PR#3664) Server doesn't react while send_all_info(&pconn->self);

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Raimar Falke wrote:
> On Mon, Mar 10, 2003 at 03:34:22PM -0800, Vasco Alexandre da Silva Costa 
> wrote:
> 
>>[rfalke - Mon Mar 10 19:50:11 2003]:
>>
>>
>>>On Mon, Mar 10, 2003 at 08:40:01AM -0800, ue80@xxxxxxxxxxxxxxxxxxxxx
>>>wrote:
>>>
>>>>I don't know how flush_buffer really works but i think that it waits
>>>>until the all data is sended before going back.
>>>
>>>The loop which I didn't found in the first try is in flush_packets.
>>>
>>>However it looks like flush_packets will wait at most game.netwait
>>>seconds. The default for this is 4s. However flush_packets is called
>>>for every line of map tiles in send_all_known_tiles. So in the default
>>>case send_all_known_tiles can block up to 50*4s = 200s = 3min+. If the
>>>player is slower than this the connection will be cut after these
>>>200s.
>>
>>This analysis is incomplete.
>>
>>Fact is if the player is seriously lagged he will take more than
>>'tcptimeout' seconds (default = 10s) to read incoming data. In that case
>>his connection will be cut and flush_packets will not consider that
>>player any more.
> 
> AFAIK Thomas this (cutting players) isn't what he experienced. So we
> are talking about slow connections.

I suspect tcptimeout is not checked within flush_packets.

In any case if flush_packets waits game.netwait seconds, then it should 
not be called repeatedly without processing incoming packets in between 
(this is the point of the variable, right?).  I would suggest either 
that it be removed from the send_all_known_tiles loop (which may result 
in immediately cutting all players if the connection buffers are too 
small, I think - this is true already but the needed buffer would be 
~80x larger).  Alternately we can just set netwait to 0 by default (or 
possibly just do this for pubserver).

I think the server should never force the game to wait for network 
reasons.  As Raimar says, network usage tends to be clumped, so in most 
cases this waiting is unnecessary.  Players may see performance 
decreases (by the time their client has caught up, their opponents have 
finished the battle and killed all their units), but in a game with 
sufficiently high timeout and large enough connection buffers nobody 
should be unnecessarily disconnected.  (It is possible this can be 
entirely accomplished just by setting netwait to 0.)

A more complicated solution to the problem would extend the (turn) 
timeout when a player was lagging.  So if you play with a 5s timeout and 
one player hasn't fully caught up by this time, the turn continues until 
they do (or they are cut because of pingtimeout or tcptimeout).  The 
implemention would probably be error-prone and potentially abusable, though.

All of this may require making the connection buffers larger.

jason