Re: [Freeciv-Dev] Patch: Server end for client data saving

[Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>]

Marko Lindqvist <caz@xxxxxxxxxxxxxxxx> writes:

> On 22 Aug 1999, Falk Hueffner wrote:
> > But I think your implementation is a bit too complicated. I think 1
> > byte as basic unit is even more manageable than 12 bytes.
> 
>  More manageable yes, but data/header ratio would be much worse. Someone
> was already worried about used bandwith when there was some discussion
> about implementing client data saving.

For the bandwidth use, the header is not that important, and if for
example you want to save 1 or 13 bytes, you have more overhead with
your idea.

For fog of war, the client would probably use the tile position as key 
and the tile content as value. That would be pretty easy to implement.

> > - a packet PACKET_CLIENT_DATA, which has two strings, the key and the
> > data, with the only restriction that the sum must not be larger than
> > the maximal packet size. If, for example, somebody implements
> > Auto-Elvis in his client, the client could send packets with key
> > "AUTO-ELVIS Tenochtitlan" as key and "1" as value (or use an internal
> > id and the city-id to save space). If value is empty, the server
> > removes the key to save space.
> 
>  Well, I think this comes to question flexible and complicated versus
> simple. With my implementation this would be done just by sending one row
> with using first couple of chars as id for "AUTO-ELVIS" and rest for
> city-id. What I mean by flexibility is that this is not the only way to
> use it.

The client would have much more work to remember all the offsets etc,
and the resulting package would even be larger (header+12 byte with
your approach, header + 2 string length + 2 city id + 1 value)

This example reminds me of another problem: While the client is
disconnected, the city might be destroyed and the id
reassigned. Probably there should be a possibility to assign data to
cities, units etc. explicitly. Considering this, I notice about all
uses I can come up with are tagged to a city, a unit, or a tile. So a
new suggestion for PACKET_CLIENT_DATA:

1 byte code enum:
 0 - tag to nothing
 1 - tag to unit
 2 - tag to city
 3 - tag to tile
2 bytes unit id/city id/tile
2 bytes key length
n bytes key
n bytes data

>  Your version does not require client to know in which order data is
> stored, when my implementation does. On the other hand, my client does not
> require server to search for id's (except if saving places are used as
> id).

Well the server can easily save the values in a hash table. Oops,
there are no hash tables in C :) Well I guess our list code would
do. Or does somebody know a decent hash library? Would be really
useful for some other things, too. I wish we could use the STL...

> > - a packet PACKET_RECALL_CLIENT_DATA, which has one string, the key,
> > and would the server make send a PACKET_CLIENT_DATA packet.
> 
>  This is something my implementation not yet perform, but if it's really
> needed it's easy to add as some kind of command (as I suggested when
> sending my patch).

Probably it isn't needed. We should leve this out at first, could be
implemented if needed.


        Falk