[Freeciv-Dev] Re: multiplayer mode is all that counts

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

It is always possible to design inefficient ways of doing things,
but this doesn't rule out the possibility that there may be quite
reasonable algorithms for handling the same problem.

First, I doubt whether one would seriously add a text based protocol
on top of the network protocol that just passed through the same 
data unmodified without some sensible reason.

The appropriate thing is to have the "stub" client implement a
flavour of data cache that in fact was something like the server
in-memory version of all the game data. In general map and terrain
information is updated only at the end of the turn, moreover it is
probably quite reasonable to mark tiles with a turn "timestamp"
that guarantees anyone asking for tile updates only gets changed
values if in fact thare is a performance problem. Units and other
elements that can change position at any time may need to be dealt
with differently by some sort of event queue, or sent to a different
client AI processing element as they arrived, say by having a city
or unit set a "shoot on sight" trigger that registered for certain
events at certain tile positions.

But a client AI that needed to compute a goto route could just as
easily send its move_cost data to the client stub to be processed
in a standard warmap algorithm as have the stub send batched terrain
information to the client AI if one way was "better". And then there
is always the shared memory trick if you want a group of cooperating
processes to perform different actions based on in-memory game data.

In general I would expect that in addition to requests for raw
data, there would be a fair number of helper functions exposed by
the client stub for any really performance intensive or common
actions.

And since a client AI need not necessarily concern itself with data
or updates that are not germane to the action it currently wants to
execute, it can be coded a lot more simply, and run quicker or more 
efficiently. The stub takes care of all the network and nitty gritty
processing stuff in the background.

Cheers,
RossW
=====

At 10:19 AM 01/09/21 +0200, Raimar Falke wrote:
>On Thu, Sep 20, 2001 at 08:03:16PM -0400, Ross W. Wetmore wrote:
>About text based protocol and separate processes: nice idea and the
>unix way. However there are some performance issues here. Consider
>code which implements a goto functionality. It has to fetch the
>terrain type of a lot of tiles. This will be expensive. Especially as
>the goto code has refetch all information every time because it
>doesn't know if something changed. Now you may think of caching the
>information and that the common code may sent updates to the cache of
>the goto code. However this just reimplements the network protocol a
>second time.
>
>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "Your mail could not be delivered to the following Address:
>  VTCMC.VTLPR@xxxxxxxxxxxxx        ** Unassigned error message **"