Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: network send/growing buffers
Home

[Freeciv-Dev] Re: network send/growing buffers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: network send/growing buffers
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Wed, 1 Aug 2001 23:02:19 -0400 (EDT)

> First of all sorry for the long reply, but i've replied to all your
> comments and explain the rationale of the current code. :-)

   That's quite alright.  I discovered most of what you discovered with
the help of gdb. :)

> > connection flushing.  Namely that the return value of write_socket_data is
> > never checked (lines 240 and 250).  Shouldn't this value propagate back up
> > to send_connection_data, especially since the timeout value in the select
>
> It makes no difference.

   I know this is kind of of moot point (at least for the context this
function is used in), but even fflush and bdflush return a value.  It
should be up to the caller to choose to ignore the return value.

> Actually this happens alot because the client is very slow at displaying
> updates. The server can send tiles much faster than the client can process
> them and draw for e.g.

   I've noticed.  Well perhaps it would make more sense to do the
buffering at the client?  Ten clients with a 512Kb buffer server-side
leads to a lot of memory at the server, but a half-meg won't strain each
client that much more.

> I may have been overzealous on setting the default values for these
> variables, but the only way to know that for sure is to test it on real
> games. I suggest on the next game you participate you increase the
> 'netwait' variable and see if you still get disconnected due to a huge
> send buffer.

   Actually the games where I'd get disconnected were ones where it was
myself (AI'ed) versus several other AI players.  The server and the client
are on the same machine; an SMP machine, no less, so one would think I'd
get decent bandwidth, low latency, and have one processor per process.
Unless the interrupt overhead was killing me (which is quite possible).

> In my opinion on a strategy game like freeciv we can't lose packets and
> get into a state that is completely different from the one on the server.
> This can be done. But it would require a total rewrite of the
> network code and its way of doing things. And you must make a much bigger
> effort to ensure coherency between the server and the clients.

   Players with significant lag are already at a disadvantage.  Again,
what's your opinion about larger client-side buffers?  On one hand it
removes a small amount of control the server has over the synchronization
of the game.  OTOH, once a packet is in a buffer it doesn't really matter
if it's pending client-side or server-side, it's still blocked.

> Thanks for reading this longwinded reply,

   No problem. :)

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx



[Prev in Thread] Current Thread [Next in Thread]