Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: (PR#4111) Client-side AI
Home

[Freeciv-Dev] Re: (PR#4111) Client-side AI

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#4111) Client-side AI
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Sat, 3 May 2003 07:58:14 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Fri, May 02, 2003 at 09:29:04PM -0700, rwetmore@xxxxxxxxxxxx wrote:
> 
> Raimar Falke wrote:
> [...]
> > Yes it is possible that server summarizes data before it sends
> > it. However it is possible that than a certain AI want another
> > information. Example: the server sends you infos like "player 1 has 20
> > archers total". Now the AI however can't do anything with this because
> > it rather want to estimate how many archers are in the region around
> > its city London. If the server summarizes data the summarization can
> > have the wrong point of view.
> 
> I think you have a confused notion of how a request/response API or in
> simpler terms a function call works, or that code executed in the client
> somehow magically is different than the same code executed in the server.
> The results returned by a client library function or server RPC call
> should not be any different. It shouldn't matter where you handle such
> things except from a data availability/security or performance standpoint.
> 
> So a server would not "send you infos" unless you requested them any more
> than a client called function would return values unless it was called.
> And if you called the wrong function or didn't understand its return
> result, then that is just a programming error.

So are you saying that for example that after a client has got the
see-all-tiles cheat it has to ask the server for every tile it doesn't
naturally know?

> >>Afterall, what is a CMA but a crutch for a human who can't do the
> >>complex computations nearly as quickly. CMA in the server or CMA in
> >>the client makes no practical difference to its computed result or
> >>way in which it is used.
> > 
> > Here you forgot one fundamental advantage: flexibility. If you change
> > the CMA you don't have to update the servers. If for example the
> > support for unhappy cities is added you don't have to update all
> > servers at pubserver. You only have to update the clients. If CMA was
> > a server thing you would have to update both server (obviously) and
> > client (add another button or scale to the GUI).
> 
> Have you forgotten reality? There are many, many more clients in the world
> to update than servers, so updating the servers is always less effort.

I agree iff a server update would also update the client GUI. While
this is possible I don't think it will happen in the next time (read
years).

> If the server implementation is upgraded with bugfixes or better
> algorithms then *no* client need to be changed for everyone to have
> the benefit.

I agree that such changes could be done server-only.

> Only if you update the shared API, as in adding a new client CMA action
> where you need new data requests or packet operations, do you need to
> update both.
> 
>  >    Raimar
> 
> There is no absolute advantage in doing client or server code, only
> different tradeoffs. Thin client systems gain by having a lot of shared
> and easily maintained centralized code and data with minimal network
> latency and bandwidth problems. Thick clients gain by allowing for
> parallel processing that offloads the server CPU bottleneck by shipping
> data to a client for processing and in some cases more flexibility (aks
> code duplication) for localized customization in processing higher layers.
> 
> It may help to think of the overall program as a layered stack from
> top of the client application down through the lowest level of the
> server code. At any point in the stack you can turn function calls
> into RPCs with no real change to the basic operation of the program.
> One only observes performance and security issues across the RPC
> boundary.
> 
> Obviously one wants to localize code on either side of this boundary
> so they make as few calls across it with as little raw data transmission
> as possible for optimal performance. But apart from that, there are
> many ways to do this that are only different in minor tradeoffs.
> 
> For a Freeciv AI, the server advantages are far more important in
> simulating a challenging opponent. Only when AI research develops to
> the point where you can easily build a sophisticated Freeciv memory
> and intuition engine will the advantages in parallel processing make
> a client AI even remotely competitive.

I always assume that the client AI can get all the data that the
server AI also has and that the client AI wants. The way is controlled
cheating.

> But for human helper functions like CMA that are just brute force
> computations and summaries, there isn't much to choose between client
> or server side APIs, so either location for the code is fine.

How would a server API cope with the task that the user want to test
certain parameters? This would increase the network usage. And it
would also increase the CPU usage at the server. Especially the latter
may be a problem if you have multiple players in a game which use CMA
and if you have multiple games on the server.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "Real Users find the one combination of bizarre
   input values that shuts down the system for days."




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