[MUD-Dev] Hosting questions
Mike at mxac.com.au
Tue Jun 28 18:23:13 New Zealand Standard Time 2005
In the somewhat far future, I'll need to run a beta. My server will
use more CPU, memory, and bandwidth than a text MUD (Text MUD = 1
mHz/user, 80 bytes/sec/user), but less than a MMORPG (MMORPG = 20-40
mHz/user, 1000 bytes/sec/user). (That's about as precise as I can
guestimate at this moment.) While in beta, I need to test with
several hundred concurrent players, and expect frequent
crashes... of course.
Here's the problem:
The easiest system for me to maintain and debug is a computer
residing at my home-office. ADSL isn't supported this far out of
town, and I wouldn't want to use it anyway because a lightning
strike might incinerate the entire cable. (My house was struck by
lightning 3 times last year. Anyone need good audio recordings of
thunder?) I can get fibre optic, but it'll be expensive running a
3 km long fibre. Plus, the local telco's bandwidth costs are more
expensive than in the US.
It's infinitely cheaper for me to hire a server someplace in the
US, and monitor it remotely. (Anyone have suggestions on ISPs?
I've been exploring ICUServices and Wolfpaw.) However, if/when the
server crashes, debugging is much more difficult, if not
Alternatively, I could get a server set up in town, but that only
makes debugging marginally less nasty; since if the server crashes
I have to do the hour's drive to town and see how it crashed.
Any suggestions on how to deal with the debugging problem? Some
solutions that I've already come up with:
- I can set up monkey stress-tests over a LAN and theoretically
test high server loads before alpha/beta. (Although theory !=
- I can set up a temporary service with my satelite, but it maxes
as 128 kbit upload, which means max 16-200 users, depending upon
my bandwidth usage. This would work for alpha, the "crash-iest"
- My server code is almost entirely script, which means GP faults
are unlikely, and I can (if necessary) program remote debugging
into my scripting language. I'm not sure what form it will take,
since traditional run-time debugging of a game with hundreds of
players may not be possible with any debugger because debugging
usually involves the suspension of all threads... and hence all
- Tons of logging, of course. For example: I can create an
auxiliary process that logs everything the server (and scripting
language) is doing for the last N minutes, so I have a trace if
there is a GP fault.
- Once I get past the crashing stage, remote servers are much less
scary. (Assuming I can eliminate all the GP faults, or at least
the ones that aren't covered up by a nightly/weekly reboot.)
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev