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

["Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>]

[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.

flush_packets is for the benefit of players on slow connections, not
severely lagged players.

The interactions of all the network configuration variables are subtle.
This was all explained at the time the patch was discussed.
There is help information for these variables: tcptimeout, netwait,
pingtime, pingtimeout.

> No sure about a solution. It seems possible but I'm not sure how many
> problems I overlooked.

Yes that is the worst case of them all. Next in line are the calls in
ai_start_turn(), and end_turn().

I added that call in send_all_known_tiles() because players were getting
disconnected a lot in large map sends. I dislike using ad-hoc solutions
but this one was the best at the time.

We should compress the map data more somehow so players wouldn't get
disconnected due to 'tcptimeout' that easily. Alternatively we could
also make it wait for the buffers to drain.

At the time I thought about making a 'tile row' packet or somesuch since
that would save a lot of bytes. The packet header alone is 3 bytes.

struct packet_tile_info {
  int x, y, type, special, known;
  unsigned short continent;
};

So... 1+1+1+2+1+2 bytes of data plus 3 bytes for the header.

If the map is 200*100:

200*100*11 = 220 KB (SI).

If you are using a slow modem this could take almost a minute to chew.
I'm not even counting with client drawing delays.

If we use the 'tile row' packet:

struct packet_tile_row_info {
  int y;
  int w;
  
  struct info {
    int type, special, known;
    unsigned short continent;
  } row[];
};

With the same 200x100 map:

100*(1+1+200*(1+2+1+2) bytes data + 3 bytes header).

120.500 KB (SI).

How's that for compression? :-)

Since this would make the data sent smaller we could relax the
flush_packets() calls to half as much.

PS: I dislike the idea of using gzip in the Freeciv network protocol.
    However it may be useful for sending the initial world state to a
    client.

    PPP supports compression but unfortunately not all ISPs use it.