[CF-Devel] Tileset server

Tue Mar 13 23:44:33 CST 2001

"Pertti Karppinen (OH6KTR)" wrote:
>

     >

      > 1) If the tileserver is down, the game may very well be unplayable (need the

     >

      > images to play).

     >

     >

      Default fallback support in the client, showing ? icons for newly added

     >

      tiles, that were not in the original faalback set.

 but if the tile server is down or missing that tile, it means you will get a ?
for the rest of that play.  Imagine if someone has added a few new monsters and
a quest to go along with it, and yout try it out - all you would see for those
new monsters for the entire time is ? marks.

>

      I agree. But we need to have some way of requesting the fill of cache

     >

      beforastarting to play. It's pretty frustrating to enter an area, meet a

     >

      completely new monster, nicely represented by '?' tiles, and die before ever

     >

      seeing the monster.

 Filling the cache before play is completely unrelated to having a tile server -
that can just as easily be done with the current 'built in' tile server in the
crossfire server.  But more related to this would be my idea where users of the
client would download a tileset for their client - it may still be missing a few
images, but certainly not as many, and downloading the images as one big file is
certainly more efficient than the current method in the server.  I can work on
having the client get all the tile names/images before starting play.

>

     >

      This implies some changes to server. I don't know how the current system

     >

      works, but if the speed of server is related to connection speed of the

     >

      player with the worst round-trip-time, the tile serving has to be split up,

     >

      so one player requesting cache fill won't comatoze the server.

 IT doesn't work that way.  The server uses non blocking i/o on all read/write
requests it does - a slow connection will not affect the server performance.

 Now there can be some game if the server of tiles is split up from the
crossfire server itself, but only if the split is due to the tile server being
on a different network/link to the original server.  That then means people
downloading the tiles won't affect the bandwidth that the server has available. 
But that adds even more complication (how does the client figure/know what tile
server to contact?)

Sebastien Bracquemont wrote:
>

     >

      >1) If the tileserver is down, the game may very well be unplayable (need

     >

      >the

     >

      >images to play).

     >

     >

      Not really, the problem occurs the first time only. Then the client has at

     >

      least one tileset stored locally.

 Once it manages to get that tile.  Scenario above is still valid here- server
adds some new tiles, but the tile server does not have them.  Your screwed.

>

      It's not an obligation. The image server doesn't have to be restarted if

     >

      images are added. It will have to check every x time incoming images.

     >

      perhaps by having an incoming directory.

 True.  IT still does mean that initial setup is harder (need to start two
programs, and potentially open up 2 ports on the firewall or other issues).  And
once again, if the tileserver dies for any reason, players may basically be
screwed.

>

      I don't think so. the real servers don't have to be aware at all of the

     >

      tiles.

 It depends on your definition of aware.

 The only awareness the current server has is that image # XXX is called ZZZZ,
and data DDD is associated with it.

 No matter what, it will still need to have the image # XXX is called ZZZZ
association.  That is because in the files (maps and archetypes), the images are
done by name, but in the protocol, we send image information by number (this
saves a lot of bandwidth in some cases - think of the 11x11 map window with
potentially 200 or so images on it.  With numbers (2 bytes, although really you
need less), that amounts to 400 bytes.  In the case of names, average length is
probably around 10 characters (name.111 is 9 right there - you either need to
include the null terminator or include a length value, and many are longer),
which amounts to 2000 bytes.

 As a partially related point, IMO the arch directory should always have the
images associated with it - if the image server is done, this is of course not
required (the collect scripts could just track what images the .arc files refer
to, and create the bmaps file, either assigning numbers of letting the server do
so), but it seems to me that if the images are in one directory and the other
information is someplace else, this just makes maintainabilty even more
difficult (more hunting to find the appropriate file).  And if images remain
with the arch, then that means if the server decides to rebuild the archetypes,
the images are already there anyways.

 In quick summary:

 If each real server needs and image server, I see no gain.  The image stuff in
the server (the portion that could get moved out) is maybe 250 lines or so.  The
complete server source is around 62000 lines (.c files only) - that is basically
a minimal change, the code works, and the fact that the server always has to be
aware to some extent of images doesn't really mean much.  Maybe there are some
good reasons this could be in a seperate program, but I don't really see
modularity or the amount of code as much of one.

 If image servers are seperate entities, there could be advantages (more
bandwidth for the servers being the only real one I can think of, and the image
server still needs to be set up someplace).  Downsides is that clients now need
to find this image server in some way, and people running servers need to be
able to put images onto the image server in some fashion).  I'm not sure the
complication outweights the benefit.  And there is only benefit if people not
running crossfire servers decide to run image servers - if the same person runs
both on the same system go to paragraph above.