When a network connection is first made to the MOO, it is identified by a unique, negative object number. Such a connection is said to be un-logged-in and is not yet associated with any MOO player object.
Each line of input on an un-logged-in connection is first parsed into words in
the usual way (see the chapter on command parsing for details) and then these
words are passed as the arguments in a call to the verb
$do_login_command()
. For example, the input line
connect Munchkin frebblebit
would result in the following call being made:
$do_login_command("connect", "Munchkin", "frebblebit")
In that call, the variable player
will have as its value the negative
object number associated with the appropriate network connection. The
functions notify()
and boot_player()
can be used with such object
numbers to send output to and disconnect un-logged-in connections. Also, the
variable argstr
will have as its value the unparsed command line as
received on the network connection.
If $do_login_command()
returns a valid player object and the connection
is still open, then the connection is considered to have logged into that
player. The server then makes one of the following verbs calls, depending on
the player object that was returned:
$user_created(player) $user_connected(player) $user_reconnected(player)
The first of these is used if the returned object number is greater than the
value returned by the max_object()
function before
$do_login_command()
was invoked, that is, it is called if the returned
object appears to have been freshly created. If this is not the case, then one
of the other two verb calls is used. The $user_connected()
call is used
if there was no existing active connection for the returned player object.
Otherwise, the $user_reconnected()
call is used instead.
Fine point: If a user reconnects and the user's old and new connections are on two different listening points being handled by different objects (see the description of the
listen()
function for more details), thenuser_client_disconnected
is called for the old connection anduser_connected
for the new one.
If an in-bound network connection does not successfully log in within a certain
period of time, the server will automatically shut down the connection, thereby
freeing up the resources associated with maintaining it. Let L be the
object handling the listening point on which the connection was received (or
#0
if the connection came in on the initial listening point). To
discover the timeout period, the server checks on
L.server_options
or, if it doesn't exist, on
$server_options
for a connect_timeout
property. If one is found
and its value is a positive integer, then that's the number of seconds the
server will use for the timeout period. If the connect_timeout
property
exists but its value isn't a positive integer, then there is no timeout at
all. If the property doesn't exist, then the default timeout is 300 seconds.
When any network connection (even an un-logged-in or outbound one) is terminated, by either the server or the client, then one of the following two verb calls is made:
$user_disconnected(player) $user_client_disconnected(player)
The first is used if the disconnection is due to actions taken by the server
(e.g., a use of the boot_player()
function or the un-logged-in timeout
described above) and the second if the disconnection was initiated by the
client side.
It is not an error if any of these five verbs do not exist; the corresponding call is simply skipped.
Note: Only one network connection can be controlling a given player object at a given time; should a second connection attempt to log in as that player, the first connection is unceremoniously closed (and
$user_reconnected()
called, as described above). This makes it easy to recover from various kinds of network problems that leave connections open but inaccessible.
When the network connection is first established, the null command is
automatically entered by the server, resulting in an initial call to
$do_login_command()
with no arguments. This signal can be used by the
verb to print out a welcome message, for example.
Warning: If there is no
$do_login_command()
verb defined, then lines of input from un-logged-in connections are simply discarded. Thus, it is necessary for any database to include a suitable definition for this verb.
Go to the first, previous, next, last section, table of contents.