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

Re: CF: hello

On Sep 6,  7:15pm, Christian Stieber wrote:
> Subject: Re: CF: hello
> Anthony Thyssen (anthony@cit.gu.edu.au) wrote:
> 
> > | This makes it a bit slow while it is first downloading the images & building
> > | the cache, but at some certain point, things run pretty decently.
> > | 
> > Hmm. anyway to just tell the client where the crossfire server library
> > is instead? Presuming it is on the same machine.
> 
> Not yet. I'm not sure whether this a good idea (right now the images
> are stored differently in the server and the X client), and it is
> complicated anyway. First of all "on the same machine" is not quite
> what you want --- there are things like NFS mounted directories. Also,
> my own server is installed with all files only readable for me, to
> prevent the easy cheating by just studying the lib/ stuff (now people
> have to download the stuff to cheat...). So chances are one would have
> to "download" the images even if the server directory is accessible
> via NFS or some such.

 Correct.  It would not be that hard to write a perl script to convert
the images from how they are stored in the arch directory to how
the client caches them.

 The bigger gain for caching images is systems where conversion from
xpm to native format is quite slow.  In that case, it would probably make
sense for the client to convert them once, and have the cache in native
image format.

> 
> Also, single uer machines should not have a problem "downloading" the
> images in the first place; they probably don't need -cache either. Also,
> as a wild guess, if the server directory is NFS mounted, it probably
> doesn't make much of a difference whether the images are transferred
> via NFS or via crossfire --- in both cases they have to go through
> the net. Unless, of course, crossfire itself gets the lib/ stuff via
> NFS (as my server does...).

 If on a single system, using -cache is still some gain.  The handling of
images isn't totally optimized - even without -cache, it stores the
image data to a file (in /tmp I believe), and then creates the image
from that file.  I will look at creating the image from memory, as that
should be a bit more of a gain.

 But there are certainly cases where caching/not caching has advantages.

 Caching would be an advantage if the cache directory (by default home
directory) is faster than the link to the server.  This typically means
local disk, but if you were playing over a t-1 connection, caching to nfs
would probably still be faster than downloading the images.

 As a note about the server - by default, it pretty much loads most all
data into memory.  Very little stuff in the lib directory gets used
once crossfire is up and running (I think some files get examine each
time the, like the ban file or dm file, but the images the server sends
to the client are loaded into memory).  Obviously, the maps and player
saves are also loaded as needed.  But most everything else is loaded
once.

 This would in effect mean that having the crossfire lib nfs mounted might
not be such a performance his as expected.  And in fact, if the clients
are connected to the same speed as the nfs mounted home partition, running
without cache might actually be faster.

 The main disadvantage is that the image data is included with the data
stream with other client data.  With fast connectins, not a big deal, but
with marginally slower connections, a local cache may still be some gain
in that you effective have 2 different connections now (client/server,
and nfs).





-- 

-- Mark Wedel
mark@pyramid.com
Follow-Ups: References: