MSSP (Mud Server Status Protocol)
 

A couple of weeks ago I posted a RFC on MudBytes regarding the creation of a protocol for Muds to automatically report their info to mud crawlers. Since then a lot has happened. I set up an official protocol specification and created a snippet that adds basic telnet handling for MCCP, MSSP, NAWS, and TTYPE. I also added MSSP support to TinTin++ so it can be used to debug server side MSSP support. So far four Muds (and one codebase) have implemented the protocol, the MudBytes crawler has added support for it and plans to integrate it into their mud directory, and both TMC and TMS have shown interest in adopting the protocol though they'll probably want to see it kick off first.

For a quick look at what MSSP entails see my output.

Feedback and comments are welcome, keep in mind that the protocol only defines a brief set of official variables, Mud listings can maintain a list of additional variables they support. If you implement MSSP and want to be added to the crawler give me a yell.

Links:



Client for debugging:
(Requires using '#config {debug telnet} on' to display MSSP output from a MUD server.)

Codebases supporing MSSP:
(As of version 4.4.0.)

MUD Crawlers supporing MSSP:



Discussion forum for MSSP (on MydBytes)


Server supporting MSSP:
azereth.game-host.org:6400
cruentus.genesismuds.com:7070
home.gotr00t.us:3000
slackhalla.org:4321

MSSP Snippets:
- Handles MCCP, MSSP, NAWS, and TTYPE.

Re: MSSP (Mud Server Status Protocol)
 

Wouldn't it be better to allow the MUD to define what a player means? Given that multiple people may be playing behind NAT'ed firewalls, IPs may undercount drastically.

Come to think of it, my MUSH has a policy that no one is to know who may be multiplaying, so that may be problematical, as identifying how many players are on may give it away when the population is low.

Re: MSSP (Mud Server Status Protocol)
 

If a MUD has a better way of reporting the actual player count I don't see a problem with that.

As you already said yourself, IPs may undercount drastically regardless of multi-playing, so one would never be sure.

If push comes to shove the mud can only allow MSSP requests from trusted IPs.

Re: MSSP (Mud Server Status Protocol)
 

Just a quick correction, azereth.game-host.org:6464 instead of port 6400

Re: MSSP (Mud Server Status Protocol)
 

I accidentally used the website's port, it's fixed now.

Update: The NakedMud codebase will support MSSP as of version 3.8.

Re: MSSP (Mud Server Status Protocol)
 

Two more muds added MSSP bringing the total to 6:

kingdomsofahln.com:7777
patrickmn.com:5000

Also updated the mssp crawler to make the crawler page look a bit neater.

Re: MSSP (Mud Server Status Protocol)
 

I'd include this functionality in NiMUD, how do you join the network?

Re: MSSP (Mud Server Status Protocol)
 

Listings on MudBytes should automatically be crawled, though MudBytes is currently not doing anything with the data, and if someone gives me the host and port of a MSSP supporting Mud I'll manually add it to my crawler.

Re: MSSP (Mud Server Status Protocol)
 

Actually, I downloaded the MSSP snippet. I'm attempting to install it, but I wonder how to report to a crawler?

BTW, it complains about signedness several times, though some of these seem intentional. Here are my compilation warnings:


telopt.c: In function 'translate_telopts':
telopt.c:123: warning: pointer targets in assignment differ in signedness
telopt.c:124: warning: pointer targets in assignment differ in signedness
telopt.c:134: warning: pointer targets in assignment differ in signedness
telopt.c: At top level:
telopt.c:447: warning: no previous prototype for 'send_will_mssp'
telopt.c:524: warning: no previous prototype for 'zlib_alloc'
telopt.c:530: warning: no previous prototype for 'zlib_free'
telopt.c: In function 'write_compressed':
telopt.c:618: warning: pointer targets in assignment differ in signedness
telopt.c: In function 'write_to_descriptor':
telopt.c:752: warning: pointer targets in passing argument 2 of 'debug_telopts' differ in signedness
telopt.c:756: warning: pointer targets in passing argument 1 of 'recv_sb_mssp' differ in signedness
gcc -O -g -g3 -ggdb3 -DMALLOC_DEBUG -D_GNU_SOURCE -o nimud alias.o admin.o admin_edit.o admin_info.o bit.o board.o client.o combat.o config.o def.o door.o edit.o events.o load.o functions.o furn.o grammar.o graphics.o handler.o html.o disease.o interpreter.o language.o lists.o magic.o map.o mem.o money.o mount.o nanny.o net.o imc.o info.o move.o props.o parser.o save.o shop.o skills.o social.o string.o tips.o translate.o track.o update.o worldgen.o xrand.o mssp_client.o mssp_tables.o telopt.o -lcrypt -lz

Re: MSSP (Mud Server Status Protocol)
 

Scandum:

nimud.divineright.org 5333

I have not yet fully implemented it though. Is there a MUD I can meet you on to ask questions?

Re: MSSP (Mud Server Status Protocol)
 

I'm not actively hanging out on any mud.

You can use tintin in telnet debugging mode for debugging, and look at the mth snippet as an example of a server side implementation.

I tested your mud but am getting the following response:

Feel free to PM me with specific questions.

Re: MSSP (Mud Server Status Protocol)
 

I did use mth. I am using files, renamed:
mud.h -> mssp.h
telnet.h -> telnet.h
telopt.c -> telopt.c
table.c -> mssp_table.c
client.c -> mssp_client.c

I am using your write_to_descriptor only for your code, since I use something called "write_to_connection"

I am using translate_telopts(), zlib, etc.

I added the content, verbatim, to DESCRIPTOR_DATA (called CONNECTION_DATA here):

msouttop
msoutbuf

these are not used at all actually.

Well, the preface to this is that NiMUD uses character mode, not line mode.

There has been a slight issue during login prior to this where it gets stuck waiting for something, and then a few code characters show up in the buffers from the remote client.

NiMUD simulates local echo by receiving characters from the remote host and then printing the characters that pass through a filter, discarding unwanted characters (sometimes telnet codes). This happens after the call to translate_telopts, however.

It seems what is happening now that I have inserted your translate_telopts() is that during the first few lines it at first is set the same way (or close to properly for character mode) and then after one line of text, something is switching it back into line mode. I'm trying to figure out where you are sending those codes inside the telopt.c client.c etc... but I have not yet found this issue. Ideally, it would properly manage character mode, then switch into line mode only if MSSP needs it, then return the connection to character mode.

The reason NiMUD does this is to interpret ansi keyboard codes like \x1b[C

Any ideas how to stop this from happening? It seems once you've logged out, and you log in the second time, something goes awry with the ability to hit return. Weird.

Re: MSSP (Mud Server Status Protocol)
 

For starters, to push a telnet client into character mode you need to send:

IAC WILL SUPPRESS GA
IAC WILL ECHO

For MSSP you need to send on connect:

IAC WILL MSSP

The write_to_descriptor calls should be replaced with whatever function NiMUD uses, so that should probably be write_to_connection.

You won't need client.c which is just for debugging, and the same goes for mud.c.

The call to translate_telopts looks alright.

Re: MSSP (Mud Server Status Protocol)
 

Unfortunately I had to remove that line to translate_telopt() because the number it was returning was messing up my connection. Like I said when I logged back in something was awry the second time and I couldn't hit return. When I removed the translate_telopt line, this problem went way.

I will check into those codes for character mode, but I cannot find where IAC 0 0 is sent or where IAC 34 255 is sent. For now I've removed it until I can spend more time with it. The reason I chose yours is because I didn't know if it was cleaner or something.

When I used the SUPPRESS_GA code, it worked from telnet at a linux prompt but PuTTy still doesn't seem to realize this properly.

The write_* I have is:

Re: MSSP (Mud Server Status Protocol)
 

Looks like write_to_connection does the same like write_to_descriptor does in merc, so it should be safe to use it.

You really wouldn't want to be using functions from mud.c since those are just dummies.

Not entirely sure what's going wrong and if it's related to mth. Other than a clean compile and adding some log calls to check what's going on I don't have any suggestions.

Re: MSSP (Mud Server Status Protocol)
 

I'm not sure either why it would lock up on <enter> What I mean by that is you can type but you can't hit return. My guess is that the number iStart is being set to is the problem. One other inconsistency was that I do not use a static size for the inbuf, which you did.

Also, the signedness issues bring in to question stability. I'd love to use this code and distribute it with my package, but until we can figure this out I haven't got a clue.

Re: MSSP (Mud Server Status Protocol)
 

One thing is that mth strips out the \r character, that might be an issue? If your code checks for \r\n that would break it. So either remove the \r stripping, or change your code to only check for a \n. I'd do the latter since that's a lot easier.

Re: MSSP (Mud Server Status Protocol)
 

It checks for either with an || , why would that matter?

Re: MSSP (Mud Server Status Protocol)
 

Ok I am now sending these I believe.

Does this mean I call announce_support()? This is being done right after the above.

Done.

I cannot call translate_telopt(), and I am not using client.c's stuff either.

When you login to the mud, it writes a Y with two dots at the prompt in PuTTy. This problem existed before, I'm not sure why it was happening, but it apparently is still happening.

I'm using 3 for SUPPRESS_GA.

It seems to only work properly with linux telnet, but the random character appears differently as a ".

Re: MSSP (Mud Server Status Protocol)
 

Seems to be sending out the requests now, but it's not answering.

Other muds haven't had any issues adding mth, so I guess you'll need to do some debugging and figure out what goes wrong.

Re: MSSP (Mud Server Status Protocol)
 

The thing is, you are reading into a static buffer and I don't use a static buffer. I will install this feature, but I have a feeling it will cause crashes when someone overtly spams a connection with > MAX_INPUT_LENGTH characters, possibly causing memory corruption or a crash.

Is there an easy way to modify this so that it doesn't use a static buffer?

EDIT:

The following code was used:

The result was I could not press <enter> after a hotboot, but the other characters made it through. Upon reboot, it would crash the mud upon connection.

Try it now, the above should translate the telopts, but it should be discarding any resulting buffer since it is running parallel (sort of) to the main networking.

UPDATE: Spoke too soon, it's causing crashes. I'm trying to figure out why, but I'm inside translate_telopts() at this point. I don't see anything, so I'm left to wonder what exactly I should do next. I've tried this several ways.

Re: MSSP (Mud Server Status Protocol)
 

Remove the stripping of \\r in telopt.c and see if that makes a difference, it's the lines:
Just remove the entire thing.

Try the following after that:

Re: MSSP (Mud Server Status Protocol)
 

This results with an immediate crash upon connection.

Re: MSSP (Mud Server Status Protocol)
 

Odd, I'm at a loss.

Re: MSSP (Mud Server Status Protocol)
 

You're using calloc instead of malloc, right?

Calloc automatically zeroes the memory, otherwise odd things might happen.

Regardless, I added a non telnet version to the MSSP specification which should be easier to implement.


MSSP Plaintext

Since it's not feasible for every mud to implement telopt negotiations a plaintext alternative is available. Whenever a new connection enters the command: MSSP-REQUEST a Mud supporting MSSP Plaintext should send the following:

\r\nMSSP-REPLY-START\r\nvariable\tvalue\r\nvariable\tvalue\r\nMSS P-REPLY-END\r\n

If a variable has multiple values you can use multiple tabs:

\r\nMSSP-REPLY-START\r\nvariable\tvalue\tvalue\r\nMSSP-REPLY-END\r\n

Re: MSSP (Mud Server Status Protocol)
 

I use malloc()

Maybe you could write a little piece of code that checks for the request in a string and a variant of the MSSP send routine that maps to mud_data, so I can install that.

I manually assign or use memset() to init variables to 0.

Re: MSSP (Mud Server Status Protocol)
 

You'd want to set everything to NULL, notably d->mccp and d->teltop. Also make sure that d->terminal_type is handled correctly.

What you can do as well is to disable negotiating anything but MSSP in tables.c just in case the crash is in one of the other negotiations.

Re: MSSP (Mud Server Status Protocol)
 

I'll try this and let you know. I don't think I'm setting those variables to anything right now.

What do you mean by "disable negotiating anything but MSSP"?

Re: MSSP (Mud Server Status Protocol)
 

The announce_support function looks through the telnet table in tables.c for entries that are flagged to send a WILL or DO request, setting the flag to 0 will disable the auto announce.

Re: MSSP (Mud Server Status Protocol)
 

I tried it by reverting to using translate_telopts() after setting the pointers to NULL and it kicked in my sigsegv monitor, reporting this through the telnet port when I connected:

Re: MSSP (Mud Server Status Protocol)
 

Might be the RESTRING macro call on d->terminal_type while it's NULL. Not sure what you're doing, but if you use it "as is" you'd want to use: d->terminal_type = strdup("");

Should be more obvious if you execute:

telnet
set options
open nimud.divineright.org 5333

Re: MSSP (Mud Server Status Protocol)
 

While using gdb it hung in select() instead of crashing.

Re: MSSP (Mud Server Status Protocol)
 

This was already done as d->terminal_type = &str_empty[0];

Re: MSSP (Mud Server Status Protocol)
 

You should use d->terminal_type = strdup(""); if you're gonna use the macro provided with mth.

Re: MSSP (Mud Server Status Protocol)
 

This fixed the problem, and I am now using translate_telopts with no wierdness. Undefined Behavior beware.

So, please try connecting us to your network. Once connected I will release NiMUD with an announcement at the top of the README about contacting you should someone want to start a NiMUD and join your network.

The specific copy of NiMUD I run is at nimud.divineright.org 5333, but others may join your network someday.

Tintin was the first client I ever used, but I later switched to TinyFugue. Now I just use PuTTy. It would be interesting to see a "lite" version written for use with the standard telnet port instead of stdin, that was easily added to existing MUDs -- one with the ability only to connect with multiple sessions to a default mud address -- as a proxy service. That way MUD admins could set up Tintin on their primary port, with some default settings to auto connect to the MUD, plus the ability to allow players to manage multiple sessions with Tintin on MUDs (like mine) that allow multiplaying.

You know .. it could activate when another client isn't detected, otherwise merely forwarding to the port like tcpxd.

Regards,
Locke

Re: MSSP (Mud Server Status Protocol)
 

It's not working as of yet, I get:

RCVD IAC 0 0
NiM5 Build 12773

<the greeting screen>

What is thy name?
RCVD IAC IAC
RCVD IAC SE 253
ÿú
RCVD IAC IAC
RCVD IAC SE 32
ÿúFNAMEThe Isles: Lands of KltaraPLAYERS62UPTIME24CODEBASENiMUDCONTACT<etc>

Looks like it tries to send out the actual MSSP data, but it gets mangled somewhere.

The debug output in tintin is supposed to look something like the following:

Re: MSSP (Mud Server Status Protocol)
 

There's that wierd character combination, ÿú !!! I have no idea but I will switch to your write_to_descriptor and see if that helps.

Are you related to 121.149.104.1 ? This bot seems to be repeatedly connecting, maybe it's your crawler?

Re: MSSP (Mud Server Status Protocol)
 

I have done this. Please retry.

Re: MSSP (Mud Server Status Protocol)
 

That's a korean IP, not sure who it is.

MSSP is still not working, nor is the mud announcing MSSP support.

I suggest you use tintin++ for debugging it with the following line to connect:

#config debug on;#ses x nimud.divineright.org 5333

If MSSP works you'll automatically get a formatted display of MSSP variables and values as I pasted earlier on.

Re: MSSP (Mud Server Status Protocol)
 

Scandum,


Yet it still does not work. Why?

Re: MSSP (Mud Server Status Protocol)
 

No idea.

Back on topic:

3 more muds added MSSP bringing the total to 9.

I updated my crawler to report average players and average uptime.



And for those who missed the earlier mention, an easier to implement plaintext version of the protocol is described on the specification page.

Re: MSSP (Mud Server Status Protocol)
 

Still unable to figure out why it does not work with your network; it seems to be sending statistics to mudconnect's bot, though.