Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: images & caching.
On Mar 9, 7:15pm, Scott Wedel wrote:
> Subject: Re: CF: images & caching.
>
> A far better solution is to use checksum to determine if both have
> matching data. So client would ask for checksum of image name to
> numbering file and only if client doesn't already have that file
> (presumably stored in some directory with the checksum being it's name)
> then client asks for a new copy. That way server hosts and such can
> change and client only gets a new copy if it doesn't already have this
> info.
This might be reasonable - sure, 60K needs to be downloaded. And provided it
is an option with the client, people could choose not to use it, and get the
mappings as the game is played.
Note that if the game is run with this (-verifycache?), the new file needs to
be downloaded before play can start (as the client needs the mappings).
>
> Then if client discover from the numbering-name that there are image
> names unknown to client then client can request those images as a
> background job when there is available bandwidth in order to preload
> them before needed.
It can be difficult for the client to predict bandwidth usage, however. For
example, a room can be empty with little changing (low bandwidth), but the
second a fireball goes off, high bandwidth. Now this is an extreme case, but
similar situations if players change maps can arise.
Now we could add something to the server, which basically is something like
'send image 350 when you have time'. The server could look at the output queue
length, and if nothing there, and nothing pending, send that image.
It may not be a bad idea to add various outgoing queues to the server - ie,
outgoing map queue, outgoing stats queue, outgoing image queue (there are
others that could be added). But in the basic example, if data to the client
is getting backed up, you may only want to send one full map update instead of
several partial updates. Same for the stats - rather than sending 5 stat
commands, sending 1 with everything may be more efficient. And likewise, some
things could be prioritized (stat and map updates are probably more important
than things like messages or sounds). Probably not worth the work - at least
for now.
>
> I do not understand why generating and passing the checksum of a
> numbering->name file is anything other than simple. Here's the code
> for Adler-32 checksum. Also, any decent checksum detects swapped bytes
> and such so a previous comment saying a checksum won't catch same names
> in different positions was incorrect. The point of a checksum is by
> passing minimal info to determine whether two things are the same.
You original scheme had an idea of trying to narrow down the new images, which
was not especially simple, or efficient.
The above method of just checksumming the file is reasonable - client can then
request it if it wants it, or use normal scheme (ie, doesn't want to download
it all now, just give me the image name->num translations as needed.) This
gets the advantage that the client can have a local set of the mappings and use
those if they match, otherwise do something else. Doesn't add much complexity
to the protocol, and is fairly easy to implement on both client & server side.
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups:
References: