MOSS/Notes

This page just holds various notes about running a MOSS server.

Questions

I can't really call this a FAQ until the questions have been asked frequently.

How do I add a user?

How do I change the Python?

Start with the source Cyan has generously provided us under the GPL. To compile that source you'll have to add in the glue. Maybe there is a tool do that in the CWE source. Make your changes. After compiling and creating the .pak (another tool?), copy the .pak to the correct server directory and encrypt it. Make a new .mbam file.

How do I add a new age?

Copy the encrypted .pak to the correct server directory, add the file to the Python.txt, and make a new .mbam file. Copy any SDL files to the auth SDL directory and encrypt them. Copy unencrypted SDL files to the correct server directory. Note if you have more than one SDL file for your age, or the file is not named the same as the age, you'll need to put the age's SDL file(s) in a directory named after the age. Copy the unencrypted .age file to the game server directory.

Why would I use --enable-fork?

This is primarily useful for testing. It's easier to debug a non-threaded process.

What resource limitations are there (file descriptors, memory, etc.)?

This is a question that's not obvious to answer. But here is what is known:

Currently MOSS uses about 5 file descriptors when idle. It uses about 10 per connected user. (4 are for the game server, so if the user links around a lot, it will be more, and if you have multiple users in one age it will be less.) If you are running a large shard, you may need to adjust per-process file descriptor limits (see the "ulimit" command) or even kernel (global) limits. If you adjust the global limit, pay attention to FD_SETSIZE. See the select() man page.
Currently MOSS uses 7 big buffers for network data per connected user. The buffer size is set by BUFSIZE in constants.h. The default is 64k, so a total of 448k per user. If you have enough users that your moss processes grow too large you can reduce the BUFSIZE.
There is not a lot of disk I/O, except for whatever the database has to write. If you set the log levels very low (DEBUG or worse, MSGS) then there will be a lot of I/O for log files.

Does MOSS work on my Power PC?: It is supposed to! Testing of big-endian systems was done, but not a full, complete run-through of all game mechanics and multiplayer testing. If it does not work, it's a bug.
Does MOSS work on Windows? OS X?: Not Windows. There is a fair bit of porting work to do. OS/X theoretically works but nobody has tried yet. (If you try and it works, fix this!)
What is the "status" server type?: MOSS will provide the status string normally fetched from a web server. You do have to make the client send the HTTP request to port 14617 or it won't do much good. This is a feature that perhaps only the author wants.

Warnings

Please note: The MOSS vault is as insecure as MOUL's. (I don't know what was done to MOULagain.) The MOSS server is almost as trusting of the client as MOUL's. (Or maybe more, in other ways; for example, there is no server-side profanity filter.) This is because a MOUL server was implemented, not some other server. Doing better is definitely possible. But to do it right is a very big project, because the entire system was designed with this trust model. You can't always change just one part of it to get where you want to be.

Don't change the .mbm or file server files while you have clients doing File transactions. Doing so will give everything indigestion.

I'm sure the same applies for .mbam and auth server files.

The SDL mechanism depends on all servers in the shard having synchronized time. Use NTP if you have more than one server. (You'll also need to NFS mount the game/state directory on all the servers so the age SDL is available to all.)

Setup Choices

Disabling the client<->server encryption is NOT recommended. However, if you subscribe to the shortsighted idea that protecting your users is not important, go ahead. But be warned, there are code paths in MOSS that are completely untested when all encryption is disabled. You'll have to fix any bugs. (The Wireshark plugin does support decrypting connections when you have the key, so you can use encrypted connections during development/testing.)

MOSS supports using RSA for key negotiation. The client contribution to the session key is RSA-encrypted with the server public key and then sent to the server, which decrypts the message. Ironically, this actually is less crypto work, while using a non-modified standard encryption technology. And it has the same pseudo-authentication properties as the Cyan-style modified Diffie-Hellman. The assembler changes required for this are astonishingly small, but there's not much value in using RSA. Nonetheless, there's no need to remove working server support for it...

While Running the Server

You can change age SDL state server-side by modifying the state saved in files in the game/state directory. Keeping backups is advised. You may modify the files with the "sdl_reader" program (which you need to build separately using "make sdl_reader"). This is a very simple command-line program. Use the -l option to specify a saved file to read. When in the program, use the "h" command to see the help. Saving this file while a game server for that age is running is pointless; the new version won't be read and it will be overwritten when the server exits.

Client Bug Workarounds

MOSS works around a few client bugs.

MOSS "fixes" the KI light bug. It is a bug in the PRP files. MOSS has an extra check for determining whether SDL state is avatar-related, instead of relying on the flag that says whether to keep the SDL state around. That check covers the KI light, so the light SDL is tossed along with the rest of avatar SDL when a person leaves an age.

MOSS may "fix" the footstep region bug. This bug is when you get the wrong footstep sound stuck, like that wooden bridge you left long ago clumping around while you're on stone. Everyone in the age hears the wrong footstep sounds. I believe that in normal play (that is, without things like /spawn) it is due to a race with the exclusive locking mechanism used to keep things like multiple button presses from being processed at the same time. Why footstep regions take a server-side exclusive lock is beyond me**, so MOSS grants all footstep region lock requests. This should make the problem occur less frequently, if at all (depending on how the client actually responds to receiving the lock after leaving the region). MOSS decides you are asking for a footstep region lock by looking for the word "Footstep" in the object name. Do not name buttons, door regions, or whatever with "Footstep" in your new ages. I suggest you do name footstep regions with "Footstep". The special case can be removed by removing #define GRANT_ALL_FOOTSTEPS from GameState.cc and recompiling.

**In fact, as a friend of mine pointed out, why are footstep sounds decided by the represented avatar's client and propagated to everyone else in the first place? It should be a purely local decision based on the location of each avatar as seen by that client. That would save on traffic and always be accurate, never mind the race with locking on the region since there would be no need to coordinate anything for a purely local decision.

Quab game Python is not really complete. The first person to link to the age becomes the "owner" of the quab game. The Python sort of attempts to handle the situation where the game owner leaves the age while there are still quabs around, but it does not actually handle it. If the server attempts to pass ownership to someone else, that client will break. And the current MOULagain client even crashes. So MOSS works around the problem by intentionally breaking the whole game when the owner leaves the age and quabs are still present. All the quabs will remain frozen in place until the age has been cleared of all players. The age does not have to restart to revive the game, just be empty.

The client supports two kinds of passwords, depending on the format of the username. If the username has the format x@x.x it uses algorithm 1 (a more secure one but also one with a fencepost error), and otherwise algorithm 2. Unfortunately the /changepassword command does not know about algorithm 2 and if you logged in with algorithm 2, it will try to change your password hash to the one for algorithm 1. This would result in you being unable to log in. So MOSS rejects requests to change the password if the username does not have the x@x.x format.

Server Non-Bugs

These are problems with Cyan's server that MOSS does not have.

MOSS does not have the infamous "zero seconds remaining" bug. Thus it is possible to do the auth downloads without the server waiting for acks from the client. This speeds up the download substantially as now the bandwidth can be fully utilized. (The --enable-fast-download configure option turns this on.)

The MOUL server has a bug with quabs in Ahnonay. If you are the first person who linked into the age, the quabs are associated with your ID. When you link out of the age, the server is supposed to send a LoadClone message telling other clients to unload your clone (the avatar). The MOUL server sends the message, but it says to unload one of the quabs with your ID in it instead of the player avatar. Oddly, the client seems just fine with that. MOSS does not have this bug.

You should see less client hitching while moving around with MOSS. The MOUL server sends a ton of node update messages for the (unchanged) city AgeInfo node. Each node update causes the client to fetch your pellet scores. The client is frozen during this (and most any) vault transaction. The MOSS server does not send all those useless updates. Interesting note: One measurement during MOUL was approximately 400 pellet score fetches an hour. That is the client freezing every 9 seconds regardless of what age you are in or how many people are in it or on your buddy list. (The pellet score fetch itself can probably be fixed in the Python but you'd still be wasting time on the city node.)

The pellet score freeze can be further reduced by #defining PELLET_SCORE_CACHE, which does what it sounds like: it caches the client's pellet score in the Auth server to cut out the round-trip time to the DB. However, there's little value to it without the city node update problem; when you open the KI it fetches the score but it's also fetching other vault nodes. Plus you aren't trying to move at the time so the freeze is less obvious. So PELLET_SCORE_CACHE is undefined by default, and in fact it is untested.

In Memoriam: Tai'lahr