I was wondering if it might be an idea to create a generic server status protocol so a mud directory can gather information about MUDs.

Information that could be retrieved would be:

1. Uptime (epoch value).
2. Current number of players online.
3. Number of areas. (To deal with wilderness stuff)
4. Number of rooms.
5. Number of unique mobs.
6. Number of unique objects.
7. Number of help files.
8. Number of script lines.
9. Average bandwidth per month in MB.

Am I missing anything?

Format wise I was thinking of the following:

Defines:

MSSP 70 /* free telopt value */

MSSP_GIVE 1
MSSP_TAKE 2
MSSP_SKIP 3

MSSP_UPTIME 1
MSSP_PLAYERS 2
MSSP_AREAS 3

 Client: IAC DO MSSP
Server: IAC WILL MSSP

Client: IAC SB MSSP MSSP_GIVE MSSP_UPTIME IAC SE
Server: IAC SB MSSP MSSP_TAKE MSSP_UPTIME 1235024422 IAC SE  /* Current time(NULL) value */

Client: IAC SB MSSP MSSP_GIVE MSSP_PLAYERS IAC SE
Server: IAC SB MSSP MSSP_TAKE MSSP_PLAYERS 2 IAC SE /* decimal value */

Client: IAC SB MSSP MSSP_GIVE MSSP_AREAS IAC SE
Server: IAC SB MSSP MSSP_SKIP MSSP_AREAS IAC SE /* Server hasn't implemented MSSP_AREAS or refuses to answer */

Rules:

MSSP_GIVE should be followed by a value between 1 and 244.
MSSP_TAKE should include a string of digits representing a positive decimal number.

The 0 and 255 byte should be avoided at all cost.

I think that'd be the easiest to implement. After finding IAC SB MASSP MSSP_TAKE you grab the option, then copy digits till you run into IAC SE. Avoiding the 0 byte avoids strlen and related issues and avoiding the 255 byte avoids having to double 255 to follow the telnet protocol and all the screwyness that follows from that.

I like the idea in general. i do not like the straitjacketed categories.
Some of those things just don't apply for a lot of muds.

I would like a "other" field, in the manner of a table, with locally-definable
categories and values.

-Crat
http://lpmuds.net

So reporting 0 players would be reported as a SKIP instead?

Why not use RFC 1572 to do it?

client - IAC DO NEW-ENVIRON
host - IAC WILL NEW-ENVIRON
client - IAC SB NEW-ENVIRON SEND USERVAR IAC SE
host -IAC SB NEW-ENVIRON IS USERVAR "ROOMS" VALUE "15000" USERVAR "PLAYERS" VALUE "52" USERVAR "OBJECTS" VALUE "12345" IAC SE

Tyche, did you actually think most MUD programmers even know how the base TELNET protocol works, much less any kind of interesting extensions? If they did, ZMP would have actually been as easy to implement in existing MUDs as I figured it would be when I designed it. Most MUDs and clients don't even _try_ to handle TELNET properly, unfortunately.

I'm honestly (pleasantly) surprised that Scandum even knew about the sub-negotiation capabilities of TELNET. :p

Yknow I was kind of wondering about this.

It just so happens that I'm ever so slightly unignorant enough that I might be
able to implement this functionality for the network subsystem of the driver
of the lib I maintain. Assuming I understand what I'm looking at here, which
admittedly, I may not.

I think that using this sort of thing is probably cool and efficient and etc, probably
saves pandas, too, and sea kittens. But I wonder…if the idea is wide adoption of
this standard…perhaps making it higher level, though inelegant for some, might
best serve the intent?

Perhaps a known query string at the telnet connection for the mud's port that
can be string parsed and string replied to, then dropped?

-Crat
http://lpmuds.net

I see no real reason to make this telnet subnegotiation instead of some kind of higher-level RPC type of protocol.

I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.


No, you'd use '0' instead of '\0' there.


Hadn't thought of that. It has the 0 byte issue, but other than that it would do the trick. I wonder if string based options ("UPTIME" instead of 1) are preferable?


I actually briefly considered ZMP, but it's a somewhat silly protocol and comes with too much bloat.

Oh joy, another !!MSP cludge?


Because most muds have some kind of telnet subnegotiation support given the popularity of MCCP. This would be relatively easy to add, while an extensible negotiation protocol would be 1) too much work 2) unmanageable.

I disagree. I very much support the intent, but locking in
categories like this imo is not necessary and limits extension.
Again, if wide adoption is the idea, I would suggest more
flexibility, rather than one size fits all. Fixing/mitigating
unnecessarily-limiting specs in old systems/protocols/langs
is just what we already have enough of.

I don't think "well then, let's just make sure we think of
everything and don't miss anything" is a reasonable approach.




If the idea here is a spec that is to be widely useful and adopted, then I think
it is necessary to entertain the notion that your favorite ultra efficient method
may not actually achieve the goal of being widely used, and should be reconsidered.

-Crat
http://lpmuds.net

Using a predefined value is mainly done for ease of implementation, then again, without a c implementation snippet it won't be adopted anyways, so I guess a more open ended option would indeed be a plus.

Don't underestimate the appeal of an elitist protocol.

I think the open endedness of the environment variables has the added bonus of querying or sending information that one thinks is useful.
Surely you don't think lines of script is more important than getting back USERVAR "BDSM" VALUE "Y" USERVAR "FURRY" VALUE "Y" USERVAR "LASG" VALUE "Y"? ;-)
As a matter of fact one could send one's entire mud listing in the form of variables.
Wouldn't that make updating one's mud listing… other than domain name/IP/port sort of an automatic process?

I'm not convinced it's any more work than trying to exhaustively list all categories while at the same time maintaining open-endedness. I'm also not sure what would be so unmanageable about it. It would only be a question-answer protocol, with nothing happening other than: "what is your value for X", followed by "abc" or "not-applicable".

I'm clueless what LASG stands for? And as a matter of fact, I find the number of script lines more important than the number of rooms, I like interactive worlds.


It would, even the IP address could be set automatically.

Isn't there sort of a chicken and egg problem here? If you don't know the address, how do you connect to it to get the updated address? (If you have the hostname, why can't you get the IP address yourself using plain ol' DNS?)

I guess an option should be there to give a new dns / ip, and port, for muds that have the luxury to leave the mud up wizlocked for a week on the old host.


Isn't that what I said?

It didn't seem so to me. Tyche said you could update everything other than connection info, you replied that you could do the IP automatically as well using this protocol. It seems to me that either this is pointless because you already have the domain name, or this is impossible because you don't know which MUD to talk to in order to get the IP in the first place. (This is different from having a dummy server up saying that the game has moved. That didn't seem to be what you were talking about.)

So that'd make:

NEW-ENVIRON     39

IS               0
SEND             1

VALUE            1
USERVAR          3

/* Example */

client - IAC   DO NEW-ENVIRON
server - IAC WILL NEW-ENVIRON
client - IAC   SB NEW-ENVIRON SEND USERVAR IAC SE
server - IAC   SB NEW-ENVIRON   IS USERVAR "ROOMS" VALUE "15000" USERVAR "PLAYERS" VALUE "52" USERVAR "OBJECTS" VALUE "12345" IAC SE

/* USERVAR values: */

"UPTIME"       Linux time value of the startup time of the MUD.
"HOSTNAME"     Current or new hostname.
"IP"           Current or new IP address.
"PORT"         Current or new port number.

"PLAYERS"      Current number of players online.
"BANDWIDTH"    Current average bandwidth per month in Megabytes.

"AREAS"        Current number of unique areas.
"ROOMS"        Current number of unique rooms.
"MOBILES"      Current number of unique mobs.
"OBJECTS"      Current number of unique objs.
"SCRIPTLINES"  Current number of unique world related script lines.
"HELPFILES"    Current number of help files.

"CODEBASE"     Name of the codebase.
"PREROGATIVE"  Name of the prerogative codebase, ie "DikuMUD" or "Custom"
"LANGUAGE"     Name of the language used, ie "German" or "English"

"MCCP"         Supports MCCP ? if yes use "1" : if no use "0" ("y" / "n" preferable?"

/* etc */

Might want to specify that the time is in UTC or something like that.

I'm also not sure how several of your fields are defined, like what exactly makes something unique, what exactly a "world related script line" is (esp. on MUDs already written in scripting languages).

"ie" should be "eg".