|
|
5.1 Technical Issues
5.1.1 Selecting a Site
Of the various matters you'll need to consider, selecting a site is
in many ways the easiest. You need a 7 x 24 connection to the Internet
and a stable IP address, for a machine running some version
of UNIX, with permission to run a constant process. This
may reduce the number of options to one or none. If it's one, the
decision is made: go with the site you have. If it is none, and you're
set on running a MUCK, your options are:
- Buy 7 x 24 access, with a stable
IP address. In
most markets, at the current time, this costs about $100 per month.
You will of course also need a computer at the receiving end of that
connection.
- Find someone who will let you run a
MUCK on
their site. This is not impossible. Both requests and offers for
sites appear rather frequently on the rec.games.mud.announce
newsgroup. Bulletin board posts and public shouts on large
M*'s may well turn up altruists: the freeware and
volunteerism ethos remains alive and well in the M*
universe.
If you are in the fortunate position of being able to choose sites,
consider the following factors:
- Connection reliability, connection speed, and sizable
RAM are all more important than processor speed. A
MUCK can be run quite successfully on a `486 under
Linux. A faster CPU is of course nicer, especially if
you do other things on the machine, but in all likelihood, processor
speed is the last bottleneck you'll hit.
- It's hard to judge connection reliability ahead of time. If
you know someone who works on a site you're considering, or at least
through the same
ISP, solicit their feedback.
- Faster connection hardware is, obviously, better than slower
hardware. A 28.8 modem is adequate, but an
ISDN is
better. The new cable modem and ASDN links would work
quite nicely. A T1 or partial T1
connection is also acceptable.
- Hardware is not the only consideration for connection speed.
Some
ISP's simply cannot provide reliably fast
connections. Sometimes this is their own fault (they sold more
bandwidth than they have), and sometimes it's due to factors beyond
their control (the ISP's ISP sold more
bandwidth than they have, or the whole set up is situated
behind some chronic bottleneck). You can get a rough idea of
comparative speeds by doing a traceroute to sites under
consideration. The first hops shown will be those on your end of the
connection, and are less relevant: other user's won't have to make
those hops. The last several hops, however, are telling. If one site
consistently posts better times than another on the last two or
three hops, this is worth taking into consideration. Although the
times you see are in scant milleseconds, final hops of more than 300
- 400 milleseconds may indicate a bottleneck at the server. Also,
try pinging the sites (ping <address>) and comparing
the indicated times. Let ping run for a couple minutes, then stop it
with ctrl-c. You should see a percentage for `packets lost'.
Dropped packets have to be resent, which significantly slows
transmissions between a client and server.
- You need adequate
RAM. MUCK is
memory-based. That is, it keeps the database loaded in
RAM while operating. If this results in a process
larger than available RAM, portions of memory are
frequently swapped to disk (`paged'). This causes a significant
degradation in performance. So, have enough memory: for a small
MUCK, it's not a lot. A dbase with 2500 objects should
create a process of 4 - 4.5 megs.
The ideal is to run the MUCK on a machine that you own:
compiling the server will be considerably easier, and you'll be able to
restart the MUCK quickly in the case of a power outage or
other failure. Console access is also a significant security
consideration: see Section 5.1.4
prev |
toc |
top |
next
|
|