Re: Server List?? and questions

["Mark Wedel" <mwedel@pyramid.com>]

On Jul 31,  4:10pm, Michael B. Martin wrote:
> Subject: Server List?? and questions
> Now, a question addressed to Mark, Brian, and the others (whose names
> I forget at the moment) who know about this stuff: what exactly is
> involved in setting up a server?  (Well, before I get flamed for not
> RTFM, I am asking for info other than what is included in the docs
> already.)  My impression is that the eutl package is not required but
> is a more sophisticated option for the client/server code.  Is this
> correct?  What are its benefits/drawbacks (as opposed to just using
> "crossclient" etc.)?  Just how much hardware (especially RAM) is
> needed to run a modest server?  Also, I like to use the pixmaps and
> sounds since I have the appropriate libs/hardware.  I recall reading
> in the docs somewhere that the server does not currently support
> "exporting" the pixmap data to a client, so each client would have to
> have their own copy of the pixmaps (and sounds) if they want to use
> them, right?  (I would think it would be too much of a load to export
> that stuff anyway.)  Just how much load (I am mostly concerned about
> RAM, which I won't have the money to upgrade for a few months at
> least) does a client add?  Does it depend on whether the clients are
> using pixmaps and/or sounds?  Can I reasonably expect to run a modest
> server (say, up to 4 people at once) on a 16 MB machine (about 13 MB
> of "usuable" memory after kernel, daemons, gettys, shells, etc. are
> loaded)?
>
> -Michael
>
>
>-- End of excerpt from Michael B. Martin


 Setting up a server is quite easy.  It is little more than compiling the
server program (and that should be pretty easy), and unpacking all the maps.

 The eutl program is needed for the new client/server model.  This is not quite
complete, the main deficiency that I know of is that that the new client will
only use XPM images, and does not support the magic mapping command.  There are
also some issues that do need to be worked out (what to do on lost connections,
what to do when the socket data overflows, etc.)  The benefits of the new
client will hopefully be it using less bandwidth, and just a separation of the
graphics code from the server.

 The normal client (which really isn't a client, it is just a front end), can
use either font, pixmap, or xpm images.)  The 'benefit' of this is that it is
quite simple, and is well tested.

 Hardware:  You probably need about 30 megs or so of disk space (to compile and
for the maps.  Maps right now are about 14 megs if you store then
uncompressed.) I wouldn't run a server on anything less than 16 megs of ram,
but I suppose you could run it on 8.  I would probably have at least 30 megs of
swap also.

 The current client/server model will send xpm/pixmap over the line - if this
is a modem line, it can take 20-30 minutes to transfer xpm data at 14.4.
 However, each time a player starts, this needs to be resent.  Hopefully, at
some point in the future, the new client will actually buffer/store this
information for future use.  One advantage of the new client is that it starts
up much quicker (sends xpm images as needed.)

 Sounds are not sent, so if someone wants to play with sounds, they will need
to have local copies (however, if that person has rplayd set up properly, that
is not totally true)

 Sounds really don't add much to ram requirements to the server.  I am not sure
how much each player adds - it is not a simple answer for this reason:
 Normally, the server will swap out maps that people are not on.  If you have
several people playing, it is much more likely that several maps will be in use
at the same time, and this is what will increase the space.  At some point, you
probably reach a saturation level (several people will be on the same map.)
 The server does have a 'malloc' command, which tells you how much memory it is
using.


-- 
 --Mark