[Freeciv-Dev] Re: [RFC] Attaching information to objects

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 13, 2001 at 05:46:28PM +0100, Falk Hueffner wrote:
> Brian Olson <locke@xxxxxxx> writes:
> 
> This would suffice if it weren't for disconnects. You'd probably want
> to have the server know all of your extra data at each point of time
> in case your client crashes. This sounds like a lot more network
> traffic, but since you need only transfer the *changes*, it might even
> be less.
> 
> I've another suggestion: it might suffice to submit just a single
> 32-bit int to the server as a key.
> 
> A client would usually have just a few "jobs", like worklist, or
> gotos, or the mentioned tile improvement plan. So it could mangle the
> job ID in 1 byte and the unit ID/tile coord/etc. into the lower 24
> bits. The server would then only need a single hash table for each

To quote D. E. Knuth: "Premature optimization is the root of all
evil." It is IMHO insubstantial if the packet payload is 4 , 8 or even
20 bytes.

> player, where it would stuff the key directly into the void* of the
> hash_bucket. The client would cache it in the same format. Very easy
> to implement. The client would have some convenience functions like
> 
> enum client_data { CD_PUBLIC_WORKER, CD_TILE_IMPROVEMENT };
> 
> /* cache attribute and send it to the server */
> void set_attrib(enum client_data type, int id, int len, const char *data);

It is needed in the client and the server to lookup based the compound
key <object type/class (city, tile, unit, player), id, object type
special subkey>. If I understood you correctly you want to a lookup
based on <client_data, id> where client_data contains information
about object type and the object type special subkey. However we have
a hopefully fast lookup for <object type/class (city, tile, unit,
player), id>: the normal *_find_* methods. Only the last step (looking
up the object type special subkey) is additional and can be implement
easy (static array) if this subkey space is dense and the total amount
known.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Sit, disk, sit. Good boy. Now spin up. Very good. Here's a netscape
  cookie for you. Fetch me some data. Come on, you can do it. No, not that
  data. Bad disk. Bad." 
    -- Calle Dybedahl, alt.sysadmin.recovery