prev| toc| next

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:

  1. 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.

  2. 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 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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