[Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 03, 2002 at 05:11:14PM +0200, Reinier Post wrote:
> On Mon, Jun 03, 2002 at 02:59:29PM +0200, Raimar Falke wrote:
> 
> > Or we can think about client side saving of attributes. But this would
> > be hard since the server and all clients have to have consistent
> > state.
> 
> Why does the server needs the state at all, if the client saves it?

This is about general game state (like unit position, hps,
traderoutes,...). And attributes depend on the general state (or the
client view upon it).

> All you need is that whoever is saving the state will save something
> the client will know how to interpret.  This can be accomplished
> by always remembering the state at the moment a save was made,
> and making sure that state is consistent with how it would be
> upon reload (= at the start of a turn).
> 
> > Something like this:
> > 
> >  user request save at the server
> >  server requests save from all clients
> >  all clients reply
> 
> This already defeats the whole purpose of saving at the client side ...
> 
> >  server freeze (no network communication)
> >  server saves
> >  server calcs hash over savegame
> >  server thaw
> >  server sends save-finished with the hash
> >  clients save their current attribute under the given hash
> > 
> > The server has to obviously send the hash of the savegame at the
> > start.
> >
> > This would work but is a lot more complicated.
> 
> I don't think it would be useful.  The point of saving attributes at
> the client side is not having to communicate about them with the server
> at all.

> Do attributes really contain information only the server can compute?

The server don't understand attributes. Attributes are calculated from
the client state.

> In that case, using attributes amounts to heating.

Let me draw the data flow (commands take other paths):
                            
  server state   -------> client state     ------>   attributes
  (some kind of          (a view of the              (depend on the previous 
   master state)          master state;               attributes value, on 
                          not just omissions          the client state and on 
                          but also different          time (i.e. it is 
concurrent))
                          values)

The server state is saved. Upon a reload the client state is
recalculated (easy). And also for all other actions we can expect that
the server and client states are synchronizes.

The easiest for client saved attributes is to freeze this chain, save
the server state in a savegame and the attributes in a file. This can
be done with some control packets as pointed out above. The attributes
will not leave the client in this scenario.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel