Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: images & caching.
On Mar 9, 7:46pm, Brian Thomas wrote:
> Subject: Re: CF: images & caching.
>
>
> > The real issue/discussion seems to be coming down on how to handle client
> initialization that wants to verify it has all the images before doing
anything
> else.
>
>
> Hmm. Why not have each image archive have a verion number? Have
> "blessed" image and map archives that have version numbers stamped
> on them. So this way, server powers up, loads the first map (city
> map) from the archive and reads in the image archive version needed.
Assuming the collect.pl script can generate versioning information, this could
work. However, versioning information needs to also include some unique host
information or something. Otherwise, lets take the simple example of 0.94.0
distribution (and image archive is 0.94.0)
Server 1 gets some new images, genrates a new archive. collect.pl scripts see
it is still 0.94.0, so calls the new version 0.94.0.001 or something.
Server 2 gets some new images, but different from server 1. IT rebuilds, and
likewise it gets called 0.94.0.001.
Client connects to server 1. Sees different imaging version, gets the
changes. IT now believes it has a valid version of 0.94.0.001 (so future
connects to server 1 are fast and easy.)
Client then decides to play on server 2. IT compares version - they match, so
it thinks it is OK. Doesn't work, as we have different images.
> Since, as you point out, the ordering of the images can change,
> option 3 seems pretty icky, considering *every* needed image would
> then have to be transmitted (and bandwidth out the window :P ).
> This is especially true if from one version to the next, an
> early image is removed, and all the ordering has changed. (BTW,
> how do you detect that??).
I will note that the protocol already has mechanism in the cache to only
transmit images requested from the client. And the client already has a
mechanism to cache images locally, and only request images from the server that
it does not have. Both of these mechanisms are highly efficient and very
simple.
What the client does not have is a way to verify it has all the images. AT
current time, the client does not store num->name translation locally, so they
are unstable and gain little - server transmitting them as it needs to (only
once for each number) works, and in the course of gameplay, at worst sends
probably 100k of data to the client.
So the question is really how does the client get/find the num->name
translations in simple and efficient method. Many of the methods might have
hit 1 of the 2 above. Sending all the name->num translations is simple, but
not especially efficient. Sending checksums (or even name->num translations)
for some of the images with client narrowing down changes, is efficient but not
particular simple. Versioning falls into the efficient, but maybe not simple.
Remember - we want a client to be able to play on any server - a client should
not be tied to a particular server with a particular set of images. Also, it
is likely that the Protocol will stabilize, at which point, people probably
won't download new clients or images sets - they will keep playign the the old
client.
Personally, I would rather go simple and not especially efficient. After all,
if there are missing images, it will take a while to download them, so an
incredibly short download on image names may still result in waiting a couple
minutes as it downloads the new images.
If you are confident your client is up to date (ie, download all the images
last week), then you just run without specifying verify before start - you
might download a couple during gameplay, but is shouuldn't be so many that it
is a problem.
>
>
> -b.t.
>
>-- End of excerpt from Brian Thomas
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: