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

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

On Wed, 1 Aug 2001, Justin Moore wrote:

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

Ah yes. I've thought of that. I even made a small patch once but it didn't
work as i intended because i was using a single process. This would be
easy to solve using threads. One thread only reads input to a buffer
and un-serializes packets and the main thread processes this data.
I've avoided this solution because of portability concerns.
Now you got me thinking about it... glib has threads and those are
supposed to be portable i guess.
Since the gtk+ client uses glib i guess we can use glib threads on it at will.
I'll try doing this whenever i have the time.

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

You were watching the game on a client. If you have smooth unit moves on
(like i said in the previous post) and the server sends, say, 400 AI unit
move updates at you, the client will draw the units moving with a small
delay between frames. This "small" delay probably makes the client take 1
second or so to display ONE unit move. If you take that into account the
client would take 400 seconds just to process that. This makes the
client very unresponsive and it gets cut.

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

True. I guess the main problem is when the client gets spammed with unit
moves like i said. IIRC these packets take way longer to process than
anything else. Maybe the client should have some sort of heuristic that
made unit moves un-smooth so to speak when there are alot of packets to
process.

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