Server Assumptions About the Database
There are a small number of circumstances under which the server directly and specifically accesses a particular verb or property in the database. This section gives a complete list of such circumstances.
Server Options Set in the Database
Many optional behaviors of the server can be controlled from within the database by creating the property
#0.server_options (also known as $server_options), assigning as its value a valid object number, and then defining
various properties on that object. At a number of times, the server checks for whether the property $server_options
exists and has an object number as its value. If so, then the server looks for a variety of other properties on that
$server_options object and, if they exist, uses their values to control how the server operates.
The specific properties searched for are each described in the appropriate section below, but here is a brief list of all of the relevant properties for ease of reference:
| Property | Description |
|---|---|
| bg_seconds | The number of seconds allotted to background tasks. |
| bg_ticks | The number of ticks allotted to background tasks. |
| connect_timeout | The maximum number of seconds to allow an un-logged-in in-bound connection to remain open. |
| default_flush_command | The initial setting of each new connection's flush command. |
| fg_seconds | The number of seconds allotted to foreground tasks. |
| fg_ticks | The number of ticks allotted to foreground tasks. |
| max_stack_depth | The maximum number of levels of nested verb calls. Only used if it is higher than default |
| dump_interval | an int in seconds for how often to checkpoint the database. |
Note: If you override a default value that was defined in options.h (such as no_name_lookup or finished_tasks_limit, or many others) you will need to call
load_server_options()for your changes to take affect.
Note: Verbs defined on #0 are not longer subject to the wiz-only permissions check on built-in functions generated by defining $server_options.protect_FOO with a true value. Thus, you can now write a `wrapper' for a built-in function without having to re-implement all of the server's built-in permissions checks for that function.
Note: If a built-in function FOO has been made wiz-only (by defining $server_options.protect_FOO with a true value) and a call is made to that function from a non-wiz verb not defined on #0 (that is, if the server is about to raise E_PERM), the server first checks to see if the verb #0:bf_FOO exists. If so, it calls it instead of raising E_PERM and returns or raises whatever it returns or raises.
Note: options.h #defines IGNORE_PROP_PROTECTED by default. If it is defined, the server ignores all attempts to protect built-in properties (such as $server_options.protect_location). Protecting properties is a significant performance hit, and most MOOs do not use this functionality.
Server Messages Set in the Database
TODO: Most of these are not yet implemented for the mooR server, but will be in the future.
There are a number of circumstances under which the server itself generates messages on network connections. Most of
these can be customized or even eliminated from within the database. In each such case, a property on $server_options
is checked at the time the message would be printed. If the property does not exist, a default message is printed. If
the property exists and its value is not a string or a list containing strings, then no message is printed at all.
Otherwise, the string(s) are printed in place of the default message, one string per line. None of these messages are
ever printed on an outbound network connection created by the function open_network_connection().
The following list covers all of the customizable messages, showing for each the name of the relevant property on
$server_options, the default message, and the circumstances under which the message is printed:
| Default Message | Description |
|---|---|
| boot_msg = "*** Disconnected ***" | The function boot_player() was called on this connection. |
| connect_msg = "*** Connected ***" | The user object that just logged in on this connection existed before $do_login_command() was called. |
| create_msg = "*** Created ***" | The user object that just logged in on this connection did not exist before $do_login_command() was called. |
| recycle_msg = "*** Recycled ***" | The logged-in user of this connection has been recycled or renumbered (via the renumber() function). |
| redirect_from_msg = "*** Redirecting connection to new port ***" | The logged-in user of this connection has just logged in on some other connection. |
| redirect_to_msg = "*** Redirecting old connection to this port ***" | The user who just logged in on this connection was already logged in on some other connection. |
| server_full_msg Default: *** Sorry, but the server cannot accept any more connections right now. *** Please try again later. | This connection arrived when the server really couldn't accept any more connections, due to running out of a critical operating system resource. |
| timeout_msg = "*** Timed-out waiting for login. ***" | This in-bound network connection was idle and un-logged-in for at least CONNECT_TIMEOUT seconds (as defined in the file options.h when the server was compiled). |
Fine point: If the network connection in question was received at a listening point (established by the
listen()function) handled by an object obj other than#0, then system messages for that connection are looked for onobj.server_options; if that property does not exist, then$server_optionsis used instead.
Checkpointing (or backing up) the Database
The server maintains the entire MOO database in main memory and on disk in a binary format. Restarting the server will always restore the system to the state it was in when the server was last run. However, this binary format is not human-readable, and can change between different versions of the server. Thus, it is important to periodically checkpoint the database, which means writing a copy of the current state of the database to disk in a human-readable format.
This can be done by the server automatically at regular intervals, and can also be done manually by the user.
There are two formats in which the server can write checkpoints: the textdump format and the objdef format. Both are human-readable text formats.
The textdump format is the "legacy" LambdaMOO-compatible format, and the format in which non-mooR "core" files or checkpoints are likely to have been written in. In the past this was the only format available, but it is now deprecated in favor of the objdef format.
The objdef format is a directory oriented format that is more human-readable, and is structured such that each object is stored in its own file, with the object number (or $sysobj-style name). Attributes of the object, as well as its properties and verbs are listed inside the file in a readable and editable way. As such the objdef format is well-suited for use with version control systems such as git, can be effectively used with diff/merge tools, and is the default format for checkpoints in the mooR server.