Maybe just punt on the whole thing and list it as just "normal" if it's not in some kind of testing phase. Everybody knows what that means, and we don't have these soon-to-be-quite-ridiculous debates on how to ontologize the release cycle of MUDs (if such a thing exists). :rolleyes:

The Death Star was "fully operational," and look what happened to it.

I thought it was fully armed and operational :tongue:

The death star was a poor design to begin with…

With the technological resources available, they could have easily made that an unmanned, remotely controlled station and reduced their risk of casualties by a considerable margin.

So, just to clarify, we're talking about, for example:

"UPSINCE: 1230434401\r\n"
"ROOMS: auto-generated\r\n"
"PEOPLE: {{john} {paul} {george} {ringo}}\r\n"
"WHO: {{Johnny} {Apauled} {\"Gorgeous\" George} {Lord of the Ringos}}\r\n"
"SCRIPTLINES: N/A\r\n"
"STATUS: almost there!\r\n"

How's that look?

-Crat
http://lpmuds.net/not_funny_you_guys.jpg

Hey, looks like Tcl. :wink:

Why do you have quotation marks escaped? Looks like you have them around each line, but not sure why – I don't think they need escaping if braces are the string delimiter.

I decided to simplify the protocol so it's fully compatible with MCCP2 implementations and doesn't take much effort to implement on a mud that already supports MCCP or something of that nature. I guess this is pretty much the final version.

Server Commands

IAC WILL MSSP indicates the server supports MSSP, and is willing to send server
status data.
IAC   SB MSSP IAC SE indicates the server is sending MSSP variables and values.

Client Commands

IAC   DO MSSP indicates the client is willing to receive server status data.
IAC DONT MSSP indicates the client doesn't support MSSP.

Handshake
  
When a client connects to a server the server should send IAC WILL MSSP.
The client should respond with either IAC DO MSSP or IAC DONT MSSP.
If the server receives IAC DO MSSP it should respond with IAC SB MSSP
MSSP_VAR "variable" MSSP_VAL "value" MSSP_VAR "variable" MSSP_VAL "value"
IAC SE. 

MSSP definitions

MSSP            70

MSSP_VAL         1
MSSP_VAR         2

/* Example MSSP handshake */

server - IAC WILL MSSP
client - IAC   DO MSSP
server - IAC   SB MSSP MSSP_VAR "ROOMS" MSSP_VAL "15000" MSSP_VAR "PLAYERS" MSSP_VAL "52" MSSP_VAR "ALPHA" MSSP_VAL "1" IAC SE


/*
        Official MSSP_VAR values:
*/

"CODEBASE"           Name of the codebase, eg "Merc"
"CONTACT"            Email address for contacting the MUD.
"CREATED"            Year the MUD was created.
"HOSTNAME"           Current or new hostname.
"ICON"               URL to 32x32 256 color icon in bmp, gif, or jpg format.
"IP"                 Current or new IP address.
"LANGUAGE"           Name of the language used, eg "German" or "English"
"LOCATION"           Name of the location of the server, eg "France" or "USA"
"MINIMUM AGE"        Current minimum age requirement, use "0" if not applicable.
"NAME"               Current or new name of the MUD.
"PORT"               Current or new port number.
"PREROGATIVE"        Name of the prerogative codebase, eg "DikuMUD" or "Custom"
"WEBSITE"            URL to MUD website.

"GENRE"              "Adult", "Fantasy", "Historical", "Horror", "Modern", "Science Fiction"
"STATUS"             "ALPHA", "CLOSED BETA", "OPEN BETA", "LIVE"
"SUBGENRE"           "BDSM", "LASG", "Medieval Fantasy", "High Fantasy", "World War II", "Western", "Frankenstein", "Dracula", "Cyberpunk", "Post Apocalyptic", "Harry Potter", "Dragonlance", "Etc"
"GAMEPLAY"           "Adventure", "Educational", "Hack and Slash", "Player versus Player", "Roleplaying", "Social", "Strategy"
"GAMESYSTEM"         "d20", "D&D", "Etc". Omit or use "Custom" if using a custom gamesystems.

"BANDWIDTH"          Current average bandwidth per month in Megabytes.
"PLAYERS"            Current number of players online, if multi-playing is allowed report unique IPs instead.
"UPTIME"             Unix time value of the startup time of the MUD.

/*
        The following values should be generated at boot time, use "0" or omit if not applicable.
*/

"AREAS"              Current number of areas.
"HELPFILES"          Current number of help files.  
"MOBILES"            Current number of unique mobiles.
"OBJECTS"            Current number of unique objects.
"SCRIPTLINES"        Current number of world related script lines.
"WORLDS"             Current number of worlds.

"CLASSES"            Number of classes, omit or use "0" if classless.
"LEVELS"             Number of levels, omit or use "0" if leveless.
"RACES"              Number of races, omit or use "0" if raceless.
"ROOMS"              Number of rooms, omit use "0" if roomless.

/*
        All boolean values are assumed to be "0" if omitted. Use "1" for yes, "0" for no.
*/

"ANSI"               Supports ANSI colors ?
"MCCP"               Supports MCCP ?
"MCP"                Supports MCP ?
"MSP"                Supports MSP ?
"MXP"                Supports MXP ?
"PUEBLO"             Supports Pueblo ?
"VT100"              Supports VT100 interface ?   
"XTERM 256 COLORS"   Supports xterm 256 colors ?

"PAY TO PLAY"        Pay to play ?
"PAY FOR PERKS"      Pay for perks ?

"HIRING BUILDERS"    Game is hiring builders ?
"HIRING CODERS"      Game is hiring coders ?

It helps me to compare these two approaches by characterizing one as in-band (command) and the other as out-of-band (telnet) with respect to the normal stream of server input and output.

The command approach is simpler to implement, but I wouldn't want to impose usage restrictions like it having to be the first bytes received on accepting the connection. The MSSP request should be accepted at any time, and the MSSP response should be delimited so that it can be easily extracted from any other server output that came before or after it. The telnet approach is cleaner as it does keep the MSSP stream separate from the normal input and output stream. But it is more complicated to implement.

A third option is to put MSSP on a separate port. A connection is accepted, the MSSP data is dumped to it, and the connection is closed. At this point, there is no need to specify a MSSP protocol because there is no request/response exchange. Rather, a MUD markup language is needed for the key::value pairs of data (as would be the case for the command option discussed earlier).

What use case do you predict for using two bands of communication here?


This is likely to make the protocol 'dead on arrival' because opening a separate port is not an option for very many MUDs.

QFT. My interest in this thread has been largely focused
on the awesomeness of the intent of this protocol…which
necessarily includes making it as convenient to adopt/use
as possible, since surveying is the point.

Anything that adds roadblocks of any kind should be used
only when unavoidable. The vast majority of muds I think
can probably use/beg-for/connive an extra port for this.
But it's an extra step that means fewer muds would buy in.

We want buy in. We want participation. We have to think
in terms of population, and not in terms of individual
muds doing it, since this project is exactly about measuring
and categorizing population.

I am not against people specifying a dedicated port for
this. It does not interfere with the mission. But I would
argue against making a dedicated port the mandatory and
default proposition.

For example, one idea I heard was to make a MSSP server that
muds wouod connect to, and report themselves. That's a great
idea for muds able to make outbound network connections.
But again, this serves to winnow down a membership that we
should be trying to expand instead. Should this be an option?
Why not! But it oughtn't be the expected default.

We all know we can count on muds to definitely do at least
one thing reliably: accept plain text on a telnet connection
and respond in plain text with processed output. That's the
one common denominator we know we can count on, and I
propose we stick with what we know will work in every case,
in order to amplify the protocol's uptake (and thus its value).




Makes sense.

-Crat
http://lpmuds.net

It occurs to me that, when using the command approach, specifying an XML schema to validate an XML encoded MSSP response against, as well as an XSL style sheet to consistently display the response, could promote the uptake of MSSP by MUD aggregation sites since it then becomes simpler to integrate (e.g., there's no need to write a parser). Just be sure to specify a version attribute for extensibility.

Btw, does anyone know what exactly the 'pueblo' protocol is?

Using HTML for rendering output, iirc.

There are really three bands/streams of communication in a Telnet client-server setup. First there is Telnet's out of band communication, the third set of sockets in the select statement. For some unknown reason, it's misunderstood in DikuMuds as some sort of error which it's not. (See the code comment "Kick out the freaky folks" in ROM, probably Merc and others). Basicly OOB is a way to send Telnet commands that have a high priority or in an emergency, like cancelling output, killing a out of control program, etc. Certain socket libraries and socket configuration options will instead include OOB data in band. In any event the differences between how BSD, Unix, and Windows platforms make use of this OOB channel make difficult cross platform and it's probably not very useful in muds anyway.

Second, Telnet commands and subnegotiations are themselves an in stream second band or channel, as they are filtered and processed out of the stream so as not to interfere with normal data the client would see. For example, if you should misconfigure your mud to assume every client is MCCP2 capable; that is, don't bother to negotiate and just start sending MCCP2 streams, what you will see on GMUD is a bunch of garbage because it's not Telnet (nor MCCP2 capable). On GNU Telnet, you should see absolutely nothing, because while it isn't MCCP2 capable, however, it is Telnet capable and filters out/ignores the MCCP2 subnegotiation stream. So in essence, you have 2 bands/streams of data in a Telnet session. That is what was broken with MSP and MSP2 fixes. The driving notion is that not all Mud servers are run in line mode, and protocols that assume that are inherent broken on servers running in character mode. Sure it can be worked around, for each and every new protocol, however there's already a documented and extensible protocol called Telnet.

The "use case" is allowing mud clients to receive the information for their own purposes (several of which have been brought up above in the discussion) without spewing crap all over the mud clients screen.

If you aren't going to use Telnet subnegotiation then there's no need at all for any special protocol to initiate this, because frankly this can be accomplished quite simply by modifying any Diku or LPMud to allow execution of a single command without the need for logging in (just like Mush/Mux/MOOs do). In the nanny function where Name is asked for, or in some cases the ANSI question, or whatever you ask first, simply allow the command STATUS or STATS or WHOAREYOU or whatever to be used, and call a function that barfs out the the info. That certainly provides crawlers the info, or curious players wishing to see it. Done.

As a matter of fact, there's nothing stopping a mud server from implementing one, the other or both. A STATUS command available at the login screen and the NEW-ENVIRON option.

I don't think the point is wondering how many bands of communication there are, but why crawlers need more than one in the first place. The primary use case here is not normal people running MUD clients – it's crawlers. Normal people running MUD clients have been mentioned only in passing, to such a point that I don't think they really even qualify as secondary use cases.

If MUD clients want to provide useful support for this, they need to do some kind of work anyhow. So why not have them implement it using the trigger mechanisms that they already use?

Basically, I think you misunderstood my question: what is the use case that requires out of band communication, that cannot be handled using existing mechanisms?

Clearly I think it has other uses or I wouldn't have mentioned it.



Mud clients, at least those actively maintained, are already using said Telnet mechanisms. The authors already have a much better understanding of implementing those mechanisms than those working on mud servers. I don't believe there is a Telnet competency problem among major client authors.

The use cases already mentioned in prior discussion were:
1) Updating local mud databases (same info as crawler).
2) Setting environment variables for script interface (IS).
3) Allow the server to issue regular update environment variables (INFO).

Not only are 2 and 3 useful for "normal" mud clients, they certainly would be useful for those running robots.

I'll repeat, "As a matter of fact, there's nothing stopping a mud server from implementing one, the other or both. A STATUS command available at the login screen and the NEW-ENVIRON option." The mechanisms can exist quite independently of each other.

I think the point has been made however that there's only so much your average mud developer can handle. I dumbed MSSP down to the point where it's single purpose, but on the other hand it'll make implementation that much easier since it's pretty much a twin of MCCP now.

I've started on a Diku-ish generic telnet handling snippet that should make inclusion as easy as: d->intop += translate_telopts(d, bufin, nRead, d->inbuf + d->intop);

I guess I'm just not seeing how these are useful to the person playing the game. Presumably they already know the vast majority of the information that the MUD will give them because, well, they're already there!
It could be nice to know if the MUD is about to change IP addresses or something but that seems like such a very rare event that the MUD would be making loud noise about it anyhow in MOTDs etc. if they knew about it far enough in advance to stick it into the protocol output data in the first place.
You mention scripting, well, ok, but can you give an example where somebody would use this?

Yep, which is why I'm just concentrating on the one that
seems to me most likely to be useful to the largest number
of people.

Since you and Scandum think that getting mud clients to
implement this as teloptneg is valuable, then that's cool
and I hope it works out.

In the meantime, I'd like some more opinions on the nature
and form of the data.



What do you think would be necessary beyond the examples I gave?

-Crat
http://lpmuds.net

I started having a think about how I'd fill out the list for my own mud, and came up with some questions about some of the fields:

UPTIME: With an exec copyover/hotreboot the mud process restarts, but from a player's perspective the mud is never down (in fact, unless you explicitly tell your players that the mud has rebooted, they might not even notice). Should such a reboot reset the UPTIME?

PORT: Some muds allow you to connect through multiple ports.

LAUNCHED: Is this the first time people could connect? The first time the general public could connect? The year the mud left beta testing?

AREAS: What about areas that are only open for special events (eg Christmas-themed areas)?

HELPFILES: Typing "help stats" and "help statistics" references the same help file - I assume this would count as one help file? Typing "help build" lists one of six different help files depending on your class - I assume this would count as six help files? Certain help files are only accessable internally, not via the "help" command - would they count towards the total? Certain help files are stored, formatted and partially generated by a separate system (eg quest tasks), although they are also accessable via the "help" command and indistinguishable from regular help files from a player's perspective - would they count towards the total?

WORLDS: As with areas, I have a Christmas-themed world which is only there in December. Also, each player has their own "world", but I'm assuming those wouldn't count. What exactly is the definition of a "world"?

RACELESS: Some of my classes are technically also races, but there's no independent concept of "race". I assume that's "raceless"?