Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: images & caching.

On Mar 8,  7:11pm, Scott Wedel wrote:
> Subject: Re: CF: images & caching.
> 
> If we assume that clients can cache and provide a reasonable means for
> a client to update local cache so that local cache is complete then
> there is no bandwidth issue.  Image size using bandwidth is an issue
> only because the current caching scheme is ineffective at updating the
> cache.  If there was a scheme where upon client connect initialize that
> a few messages were sent back and forth to verify client had all images
> (and if not then received any new images) then image size is largely
> irrelevant.

 Easy to add - I am sure preloading the image cache will be added sometime
soon.

 However, bandwidth is still at least some of a consideration - after all,
the images still need to be transferred down.  So if we look at
the current xpm set, which is around 3 MB, compared to a compressed
image set (probably aroudn 500K), there is certainly a good amoutn of
time savings in the actual download.  Assuming you are at the end of
a reasonably fast link, the 3 MB might not be an issue - but for 28.8K
player, I believe a 3 MB file has a download time around 10-15 minutes?
500K is 3 minutes?  Granted, this download only needs to be done once,
but a lower time is certainly nice.

> 
> Seems to me that the biggest issue is to develop a method which client
> can quickly and efficiently verify it has a complete local cache and
> get whatever updates of whatever missing images.

 Easy enough to add something like:

C->S: RIN 0 500	(Request Image Names, 0->500)
S->C: face <num><name>	(already there - although not especially
	efficient for 500 images - maybe something like:
S->C FN 0 500 face0 face1 face2,....

 Client then checks to see if it has the image in local cache.  IF not,
it uses the existing mechanism to request the face from the server.



-- 

-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: