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

[Marko Lindqvist <caz@xxxxxxxxxxxxxxxx>]

On 22 Aug 1999, Falk Hueffner wrote:

> Marko Lindqvist <caz@xxxxxxxxxxxxxxxx> writes:
> 
> 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.

 Let's forget about other headers, but think about those headers strictly
within our own packet. Well, your implementation have almost none, but
mine does have 4 bytes (saving place and command). So, with 1 byte as data
unit there would be 13*(1+4)=65 bytes and for 12 bytes as unit 2*(12+4)=32
bytes when talking about saving 13 bytes. Used memory at server end is
of course only 13 bytes for 1 byte unit and 24 bytes for 12 bytes unit.

> 
> 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.
> 

 Still: What's the advantage of implementing fog of war at client side?

> > > - 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,

 I think this to be biggest problem with my implementation.

> and the resulting package would even be larger (header+12 byte with
> your approach, header + 2 string length + 2 city id + 1 value)
> 

 Yes, fixed data length is a bad thing, I admit that. For some reason I
didn't realise what you were saying in your previous post. Well, if I
change to variable sized data length I would have 6 byte header and data
itself. Also, some things that are inside data, are already sent as
headers in your version. Your new approach seems to have header of 5
bytes. Well, I could make it into 4 bytes by taking command off, and
making new packet for situations where command is something else than
SASP_SET, but anyway in this kind of situation your approach is better.
 But consider sending all tiles. With variable data length I would
send them in a couple of packets of maximal packet size. First packet
would start with some kind of id to tell that n bytes following are tiles
in order. So header is sent only couple of times, and there is only one
headerlike part in the data itself. You are sending header once per every
single tile? Hmm... okay, you can make it tagged to nothing,
unit/city/whatever id set to zero and with key 'tiles'. Similarly you can
always send any kind of more complicated structures just by ignoring your
tagging systems.
 

> This example reminds me of another problem: While the client is
> disconnected, the city might be destroyed and the id
> reassigned.

 It does this? For some reason I thought (hoped) that id's are not
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.

 Well, since you say 'about all', I have to agree.

> 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

 1 byte key length + 1 byte data length, I assume.

> n bytes key
> n bytes data
> 
> 
> 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...

 Yeah, my problem was that I all the time thought that client remembers
data it has sent to server in some organized structure . So hash tables or
whatever could be used at clients end. On the other hand, that information
may be taken from various places and keeping it in organized structure
would mean keeping duplicate entries at clients end.

> 
> > > - 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.
> 

 And when seems to be needed, check your client code. Client should not
just rely on server remembering anything client has sent to it. Client
should remember those things itself too (except when loading saved game of
course)

 Well, to sum it up, it seems to me that our views currently differ just
in that if organising data belongs to server or to client. If it belongs
to srever, one have to give separate key and data fields when sending
data. If client organizes data, it should send only one data field where
are it's internal key and data fields as client likes them to be (you
agree with this?).


 I probably don't read mailinglists for a couple of days now.

 Also server hosting cazaic pages will be down for a while.


 Caz