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

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

On Mon, 10 Mar 2003, ue80@xxxxxxxxxxxxxxxxxxxxx wrote:
> On Mon, Mar 10, 2003 at 08:23:59AM -0800, Raimar Falke wrote:
> > On Sat, Mar 08, 2003 at 12:25:56PM -0800, ue80@xxxxxxxxxxxxxxxxxxxxx wrote:
> > >
> > > Hi,
> > >
> > > duriing the time the server needs to seen all infomrmation to 1 client
> > > (especially while reconnection) the server doesn't react. No chatline,
> > > no moves from units ...
> > > That is really bad especially when playing with many players.
> >
> > I'm not sure where the server blocks for the writes. Every client
> > socket at the server is non-blocking. And write_socket_data tests for
> > the socket's ability to write to it. I also didn't found a loop which
> > tries to empty the connection buffer.
>
> I don't know how flush_buffer really works but i think that it waits
> until the all data is sended before going back.

It is probably flush_packets() which is blocking. This is necessary
because sending the whole game state takes a lot of time during which the
client does not respond fast enough because it is stuck doing updates or
waiting for the data to arrive.

If flush_packets() didn't exist that client would be disconnected, per the
current code, and probably might never get to reconnect.

It is not really bad when playing with many players because the number of
times flush_packets() is called has nothing to do with the number of
players.

If you don't like this waiting time change the 'netwait' server variable.


Why is this code like that in the first place? Sending the whole game data
takes several hundreds of KB or even MB of data. Consider it: all the map,
units and cities. Few people have fast enough connections for that.

Since in Freeciv all clients must be synchronized we can't lose data.

We buffer unsent data but the fact is this stuff piles up. After 30
minutes you are already in the region of 8 MB (per player).
Server memory is not infinite. There is a point where we must give up and
disconnect the lagging player. We have client response time and buffer
size limits.

However we cannot afford to keep disconnecting players everytime they
can't keep up. This is especially critical on whole map sends. Hence
flush_packets().
That function basically tries for upto 'netwait' seconds to send as much
buffered data as it can to *all* players. It has been sprinkled in critical
places of the code.


I realize this isn't a perfect solution but it is a vast improvement over
the previous one before I got to change that code. I.e. blocking sockets
where the server could block upto 30 minutes when a single player was on a
really flaky connection.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa