lilyCore Login Process

This is a crude flowchart, but its a start:

Login process:

open cxn to server
<- Welcome to ....
   
   login:
-> #$# options ...
<- %options ...
-> username password (incorrect)
<- Login in the wrong.
-> username password (correct)
<- *** Connected ***
   <banner>
   (last login...)
(if connect)
   Please choose a name...
   >>>> "foo", "bar"
   %prompt -->
-> name
(end if)
   Please enter a blurb
   %prompt -->
-> <blurb>
(if error)
<- (That looks like your password! ...
   %prompt -->
(end if)
<- <slcp-sync data>
   Welcome to ...
(if reconnect)
   %prompt You were detached...
-> n
<- Type "Review detach" to see what you missed
   %connected attach
(else)
   %connected entry

2 November 1994, email to lily-dev@rpi.edu

The action-flow of lily for the typical user is actually fairly simple, though it has unique twists and turns significant to MOO. The first stage is actually one of Maker's original hacks. When a user connects to a MOO it calls #0:do_login_command() and passes it whatever the user types, the first invocation the parameters are {} (the empty list, or no parameters). The server displays a welcome message whenever that occurs, which is why you see repeated welcome messages if you hit <return> at the login prompt. Each time you supply information (login or password) the verb calls #0:get_login_state() and and #0:set_login_state to record the progress of your login. There are special cases in the code for Prisoner's WWW hack and consulting. Just as a cheeky note, pay attention to the character at the end of "Login in the wrong" it actually secretly tells you what was wrong with the login attempt. Once both login and password are complete and correct the verb returns the object number of the user associated with that login/password. Until we return a valid object number MOO will regard the connection as only partially logged in.

Now that the #0:do_login_command has returned a valid user object, MOO continues on its way. If the object is already connected then the other instance is told it has been redirected away and #0:user_reconnected() is called. That verb just forces the user to "detach by accident", though their connection is never dropped, and calls #0:user_connected. In this way we have made redirecting a more useful concept in lily terms. Regardless, #0:user_connected is called and the user object is passed as argument one. If user is a client, then the client object's confunc() is called and the verb returns. Normally, however, the verb proceeds showing the banner, last login, and voting status. Then it calls the player's confunc() which sets the name and blurb (though more verb calls), changes the user's state, updates the state caches, and announces the user's presence on the system. Back into the #0:user_connect verb we go, welcoming the user to lily. Then, if appropriate, we join the user to the default discussion and join them to any discussions they were in if they "/bye"ed. The 2.0 Core releases added a prompt to review detached output if the player was detached. This is configurable with /set

At this point the user, WWW hack, and client merge paths again as both have all their commands interpretted by #0:do_command (this is a MOO necessity). lily simply passes through #0:do_command for performance reasons and calls the object's version of the do_command verb. The performance concern was that #0:do_command used to be terribly complex because it special cased admins, programmers, the WWW hack, clients, regular users, etc... It was terrible! The solution was to take a logical backstep and allow the object itself to manage parsing, visible command-set issues vanished. Now there is no concern that something will go wrong and clients will get regular lily commands since their parser would not know how to invoke them. We reuse the $sset data structure for command parsing since it delivers a ten times performance increase over the old method of parsing.

Since it is now time to go. I'll stop here. Tomorrow I will pick up with an indepth look at parsing, messaging, and the player object.

to top