[MUD-Dev] Hosting questions

[Mike Rozak]

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

  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 !=
  reality)

  - 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"
  phase.

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

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

Thanks

Mike Rozak
http://www.mxac.com.au
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev