[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implementation question...
>Most MUD server have two states for a given connection: not logged in yet
>(at the login screen) and logged in...
>Should the MCP dialog start when the connection of the client reach the
>server before the login? or after?
It's up to you, and it depends in part on the sorts of applications
you plan to run. According to the spec, the server initiates MCP
negotiation. So if you don't want to deal with MCP messages before
login, you can just not send the initial message until after login.
If you choose to do this, there may be some issues around the welcome
message and login sequence. Some systems, for example, might want to
do login via MCP; but if they can't negotiate MCP until the user is
logged in, this might be difficult.
FWIW, in MOO, as you know, it may be more convenient to wait until
after login because you don't get a real object associated with the
connection until that point. I've thought about adding to the server
a primitive to allow reconnection, so you could log the connection
into a "login" object immediately, and then reconnect to a "player"
object after you get a name and password. However, another solution
if you're up for some radical core hacking is to separate the roles of
"connection" and "player" into two separate objects. Log a connection
into a connection object as soon as it arrives, and make the
connection object point to a player object once the connection is
As yet another tangent, in our client, the traditional "MUD window" is
not popped up until we receive a non-MCP line to put in it. This
means that we can write applications that run entirely over MCP that
may not look like MUDs at all. It also means that the MUD window in
these applications becomes a debugging tool, as it doesn't make an
appearance until an uncaught traceback or other debugging info is
sent without MCP to the connection.
Anyway, to return to your actual question: It's up to the server