I'll just leave this here…

The latest TinTin++ release (1.99.1 ) supports MSSP (telopt 70). To use it type after launching: #config {debug telnet} on, #ses <sessionname> <address> <port>.

So you have completely settled on the idea of using telnet options, have you?

I uploaded a mud telopt handler snippet, it's available here:

http://www.mudbytes.net/index.php?a=file...

It's written as a merc-ish mini codebase and compiles, so it's possible to make it more like your own mud before actual implementation, in which case you can re-release it as a codebase specific snippet, which would be much appreciated. If you execute the binary it performs an internal MSSP negotiation and prints the information through the client side implementation in client.c - mud servers obviously won't need to worry about the client.c file.

There are two servers up and running that support MSSP at slackhalla.org:4321 and slackhalla.org:6464 The mud at port 6464 avoids packet fragmentation which should make initial debugging easier.

As mentioned previously, tintin++ can be used to debug server side MSSP by using: #config debug on, and connecting to your mud with #ses x <host> <port>

Also, can an article be created for MSSP in the articles root -> protocols section?


Yes, TMC has shown interest, and from what I gathered kiasyn is adding support for it to the mudbytes crawler with the intention to create 3 hourly updates of the amount of online players for MUDs supporting MSSP.

Players and uptime are being reported on my dev game, if any would like to test it. Maybe I'll add more tomorrow – it's late for me now and it works and replys well from what I can tell using cMUD debugger.

home.gotr00t.us:3000

Checks out with tintin reporting PLAYERS UPTIME CODEBASE CONTACT CREATED HOSTNAME PORT and WEBSITE. Totally sweet!

Yeah, I slipped those in quickly since it's so easy to add more vars :)

Side note: I connected to your port 6464 and notice you send IAC GA after the MSSP sequence: is this proper? Should I be doing this? I currently don't. This is my first foray into Telopt land :)

IAC GA is used to mark a line that doesn't end with \r\n so mud clients can check for packet fragmentation.

It's probably a bug that it gets send along and isn't required for MSSP to work.

Edit: It's auto prompt detection & marking that's causing it. It shouldn't throw a good crawler off since quite a few MUDs mark the login prompt.

I have implemented MSSP support into the MUD I run - Cruentus Apocalypsis.

Can connect at:
cruentus.genesismuds.com:7070

It says 'LOCATION America' This probably should be USA since that's what TMC uses in its selection list.

Maybe adopt ISO 3166 ? http://www.iso.org/iso/english_country_n...

That would be a much better location description. It was late and wasn't thinking hard on it. It is changed to USA now.

Alright so I'm interested in putting this in my MUD too. I glanced over the initial thread and something about if you have MCCP it's easy to install. I don't have MCCP though.

Haven't really attempted it yet though.

You can have a look at the telopt handling snippet I wrote:

http://www.mudbytes.net/index.php?a=file...

It's a public domain mini codebase that compiles, and I think easiest is to transform it to be more compatible with your own codebase before actually trying to plug it in so you don't have errors all over the place. It adds MCCP, MSSP, TTYPE, and NAWS.

Basically you find in comm.c the part that does "size = read()" from the socket, then you parse whatever is read through translate_telopts() which returns a string that has all telnet stuff stripped out. I think it strips '\r's for your convenience as well. There's more detailed information in the doc/merc.txt file. It's not gonna be a breeze, but the telnet handler is pretty solid and can be easily expanded.

Your handler is actually how I got MSSP in, so thanks! I use the main loop function and rewrote it and the rest to fit my game. I tried MCCP but must have borked something cuz it would compress, error, core on a double free, and leave a stack trace deep in nowhere land lol.

Going to look at other MCCP implementations and try to hook and adapt it, though.

edit: Oh, I also wrote some funcs to output MSSP data char/int similar to what elanthis(?) suggested and a func to announce all supportes telopts on connect. If anyone is interested just say so and I will post them when I get home.

MCCP can be tricky, maybe the following info will help:

Adding MCCP:

1. When booting up the mud you should allocate the memory of mud->mccp_buf.
 
mud->mccp_buf = calloc(sizeof(char), COMPRESS_BUF_SIZE); 

2. Call send_will_mccp() when there is a new connection in comm.c before the
   greeting.

void new_descriptor(void)
{
        send_will_mccp(dnew);
}
 
3. When closing a socket make sure to call end_compress()

void close_socket( DESCRIPTOR_DATA * dclose )
{
        if (dclose->mccp)
        {
                end_compress(dclose)
        }
}

4. In write_to_descriptor() Add the following call:

bool write_to_descriptor( int desc, char *txt, int length )
{
        if (d->mccp)
        {
                write_compressed(d);
                return;             
        }
}

Stuff send with write to descriptor is written to the socket right away, so you'll likely end up with packet fragmentation if you send out 30+ vars line by line, which will throw of poorly written crawlers.

There's nothing described in the protocol to announce all supported telopts, and if you think about it, if you send out all variables you might as well send out the values while at it, which is what the protocol currently does.

Is there a standard implementation of this on common MUDs that does that? My implementation stuffs it into the output buffer, and only attempts a non-blocking send if the buffer fills. Sending directly is pretty bad for multiple reasons, not least because then a hung socket could cause the whole MUD to hang when send() blocks.

If you actually use write_to_descriptor, yes, it is sent right away. But most people don't do that, and use the methods that instead buffer input until the next network update (e.g. send_to_char). I'm not really sure why the direct method is being discussed since it's not used in the vast majority of cases.

No no, I didn't mean this in relation to MSSP, but rather telopts in general :). Just a single func to send out what my server supports on connect (MCCP, MSSP, MXP, etc) instead of a handful of hacks in different places.

I guess that'd be a bit cleaner. Also, you need to make sure to flush the output buffer after sending IAC SB MCCP IAC SE, before making d->mccp non zero. So if you used write_to_buffer for that it'd explain a compression error.



The indirect method is named write_to_buffer() in merc 2.2 - On my own mud it evolved into a high level routine, so that's why I didn't use it for raw data.