[Freeciv-Dev] Re: server i/o patch

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

On Wed, 9 Aug 2000, Lauri Tarkkala wrote:

> On Wed, Aug 09, 2000 at 02:34:32AM +0100, Vasco Alexandre Da Silva Costa 
> wrote:
> > On Wed, 9 Aug 2000, Lauri Tarkkala wrote:
> 
> If you carefuly consider what happens, if a client has a low throughput
> connection..
> 
> write_socket_data() runs in a for(start=0;start<buf->ndata;) loop,
> and yes, it waits at most 2 seconds before _EACH_ write(). As
> the socket is in a non-blocking mode, then the write() may
> very well only send part of the data to be written, and return,
> after which the loop waits another 2 seconds. 
> 
> So basically a scenario like this is possible:
> 
> 0. socket_write_data().. buffer contains N kilobytes of data..
> 1. select()
> 2. select() waits 1 < x < 2 s and returns, FD_ISSET(pc->sock,&writefs)
> 3. write() manages to write a fraction of the buffer
> 4. select() waits 1 < x < 2 s and returns, FD_ISSET(pc->sock,&writefs)
> 5. write() returns EWOULDBLOCK
> 6. select() waits 1 < x < 2 s and returns, FD_ISSET(pc->sock,&writefs)
> 7. goto 1 untill buffer finished
> 
> .. and so on, ad nauseaum. 

Yes.  And i suppose if sucessive timeouts decremented the original 2sec
timeout would prevent this but it's not portable to read the resulting
timeout value after select() continues.

> Anyway, I feel using an asynchronous flushing of the write
> queues is more cleaner, and less disruptive to the gameplay.

Most games use that yes.

> the server a feeling of how lagged  a player is.  I do not
> exactly know how the IRC protocol works, but if the pings
> are client-oriented, i fear they may not be of much use
> in poor network conditions.
> 
> A better method (than simply having the client send "pings"
> at certain intervals) would be for the server to send an ACK request, 
> and then the client to send an ACK reply. This would allow
> a neat synchronization feature at "ends-of-turn" between
> all clients.

Actually this is what IRC does.  The IRC server regularly sends a "ping"
packet to which the client must reply with a "pong" packet.  If it doesn't
(within a certain time interval) it's disconnected.

> Another question is, if a player wishes for an AI to take over ;-)

It would be neat if the AI ran in a separate process (or processes), but
that raises all kinds of portability problems...

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