Member Discussions

As everyone is aware, the original Zoggsoft MSP spec is more than a little underspecified. Because AA's sound system is designed with intent that the sounds be downloaded as needed, we ran into more than a little trouble with figuring out how to do it properly. Eventually, I sat down and wrote some implementation notes for MSP client programmers working on AA clients.

The first draft of this document can be found at:

http://alteraeon.com/articles/alter_aeon_msp_protocol.html

However, implementation notes are not sufficient to cover all cases. In particular, the behaviour of the P= option is problematic, and the lack of version information when downloading audio files prohibits effective use of the U= option. This document proposes a new interpretation for the P= tag and also proposes a new R= tag for revision information to address these issues.

I'd like to ask if anyone sees any obvious problems with these proposals. So far, existing clients appear to tolerate the new, unknown option without issue, and the semantic change to the P= tag seems likely to be backwards compatible, even though it specifies new behaviour.

While this document is AA specific, it occurs to me that some of these notes and clarifications may be of value to the broader community. The spec has been completely unmaintained for many years, and if it makes sense to do so, I would be willing to take it over and release updated versions with implementation notes, clarifications, and the proposed R= tag.

Thanks,

-dentin

Alter Aeon MUD
http://www.alteraeon.com

To be honest, the MSP protocol is a mess. The only reason to keep using it is that the basic functionality is widely supported; effectively any client that supports triggers and lets you play sound files can use it.

You can't use negotiation to automatically enable sound, because they may not have the soundpack or the ability to download sounds, and even if they do they may not want to play sound. Nor can you use negotiation to restrict the usage, or identify support, because many clients can use the sound triggers but don't support negotiation. So the negotiation is pretty much just a waste of a telnet option.

Your extensions make sense, but they won't be much use to other muds unless other clients add support - which seems pretty unlikely, considering practically nobody uses any of the existing extensions. You'd probably be better off creating your own sound protocol, and then using basic MSP as a fallback for older clients (this is also what I do in my protocol snippet).

Sorry for the negativity. I do think a better sound protocol is a great idea, perhaps as part of a more modern protocol, or something separate like Kaz's MSP2 proposal. But the original MSP should be left to rot in peace.

While I would love to live in a more modern world, one where disasters like SIP and SDP have also been replaced by protocols that suck less, I have two major problems with Kaz's proposal:

1) Nobody implements it.

2) It doesn't address any of the issues I'm trying to cover.

I'm pretty sure I understand the reason for MSP2, and it looks to me like nothing more than use of a different transport for the original, flawed MSP. If anything, I'm guessing a proper approach here would be to add MSP2 negotiation as a suboption for normal MSP. That would allow the actual 'protocol' part to remain the same, regardless of how the "spam.wav P=6 V=85" string got to the server.

I do not, however, understand why you consider the option useless because of the enable/disable issue. I would expect that clients have an 'enable/disable sounds' menu option, which should enable or disable playout, in addition to sending MSP DO/DONT telnet codes if the server initially indicated support. The code sent from the server on initial connect simply says, 'hey, I support this, use it if you want'.

What am I missing?

-dentin

Alter Aeon MUD
http://www.alteraeon.com

dentin wrote:
I do not, however, understand why you consider the option useless because of the enable/disable issue.

You mean my comment about "the negotiation is pretty much just a waste of a telnet option"?

Because the only thing the telnet option is used for is negotiation, and you can't do anything with the response. You can't assume people want sound just because their client indicates support, nor can you assume they don't want sound just because their client doesn't indicate support.

So regardless of how the client responds (if at all), you still need to have an in-game command for switching sound on and off. There's not actually any benefit in using the MSP telnet option, all of the useful information is sent in the regular text stream.

Server: Do you support MSP?
Client: Yes, I do!

Or:

Server: Do you support MSP?
Client: No, I don't.

Or sometimes even:

Server: Do you support MSP?
Client:

All three cases might support sound. None of them necessarily support sound, or want it even if they do. The telnet option hasn't actually helped you at all, the response (or lack thereof) is meaningless, and there's no way to ask for further clarification. You might as well just stick with the in-game command and the sound triggers, and ignore the telnet option entirely.

Here's how my snippet handles it through MSDP:

Server: Do you support MSDP (or if not, ATCP)?
Client: Yes, I do!
Server: Great, here's my server ID.
Client: I want you to send me sounds.
Server: Sure, here they come!

The downside is that MSDP and ATCP are not as widely supported by clients (which is why I use basic MSP as a fallback).

But if you're extending MSP, you're going to have exactly the same problem.

KaVir,

While the spec explicitly says "sent by the server to detemine if the client supports MSP", I assumed this was a typo (because it doesn't make any sense.) I understood the spec to mean this instead:

Server: yo, I support MSP
Client: do nothing/enable it/disable it

It never even occurred to me that the negotiation would be the reverse, with the server asking the client for its support, because that case didn't (and still doesn't) make sense based on what I understand. I think the assumption of 'misworded spec' is fair.

With that interpretation in mind, I think it makes more sense - the client is, as it should be, fully in control. If it doesn't support MSP, there is no response and the server should do nothing. If the client sends DO MSP, turn it on. If the client sends DONT MSP, turn it off.

If the client is too brain damaged to do this properly when the user enables or disables sound from the client configuration or menu system, I can't really say that it's a problem with the spec.


-dentin

Alter Aeon MUD
http://www.alteraeon.com

All three cases might support sound. None of them necessarily support sound, or want it even if they do. The telnet option hasn't actually helped you at all, the response (or lack thereof) is meaningless, and there's no way to ask for further clarification. You might as well just stick with the in-game command and the sound triggers, and ignore the telnet option entirely.

This is not correct. The first case does negotiates MSP support. The negotiation is no different than Kaz's MSP2, regardless of Zugg's inability to express a specification coherently.

The server sends WILL MSP to express a desire to enable the MSP option (send sound triggers). Only if the client agrees with it via DO MSP is the MSP option is enabled, and the server is free to send sound triggers. The client can ask the server to stop sending sound triggers with DONT MSP or to start sending triggers with DO MSP.

dentin wrote:
It never even occurred to me that the negotiation would be the reverse, with the server asking the client for its support, because that case didn't (and still doesn't) make sense based on what I understand

It's kind of both. The server is obviously announcing that it supports the protocol, but that also serves as a query; it's expecting either an "I do too" or "I don't" response from the client. There's no handshake if the client just sits there with its hands in its pockets.

dentin wrote:
With that interpretation in mind, I think it makes more sense - the client is, as it should be, fully in control. If it doesn't support MSP, there is no response and the server should do nothing. If the client sends DO MSP, turn it on. If the client sends DONT MSP, turn it off.

The client should always respond, either with IAC DO MSP or IAC DONT MSP. It should never simply ignore the negotiation (the clients that do so have a broken telnet implementation - I'm looking at you, GMud).

Tyche wrote:
The first case does negotiates MSP support.

Yes, I phrased that last part poorly. The first case indicates that the client supports MSP to some extent, but it doesn't indicate whether the mud can or should use that support. Does the client have the soundpack? No idea. Is it able to download sound files on the fly? No idea. Is it able to play the audio file format used by the mud? No idea. Does the player actually want to play sound? No idea. You shouldn't automatically start throwing sound triggers at any client that responds IAC DO MSP, or you'll have people complaining about their computers making strange beeping sounds (the response used by some clients to indicate a missing sound file).

If the client just sits there with its hands in its pockets, by definition the server should do nothing. It might not be correct telnet, but there's definitely a 'correct' behavior for the server.

What I'm getting out of this is "the spec is bad because most of the clients with MSP support are broken". While I can understand that being a legitimate concern for something like SIP, where the protocol itself is too complex to ever implement correctly, I fail to see how it's a problem here.

If we're going to be talking about abandoning dumb, broken things, perhaps a better place to start would be with broken clients, not specs that fill a specific need.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

KaVir: The client should always respond, either with IAC DO MSP or IAC DONT MSP. It should never simply ignore the negotiation (the clients that do so have a broken telnet implementation - I'm looking at you, GMud).

Not always and never though. They MUST ignore a request for an option which has already been enabled/disabled unless the request changes the status quo.

For example...
Server: IAC WILL MSP
Client: IAC DO MSP
Server: IAC WILL MSP
Client: no response

GMud doesn't claim to support or attempt to implement telnet at all. That's like saying Chrome's telnet implementation is broken. ;-)
But it does appear you could implement MSP without telnet via script triggers if you follow the specifications suggestion that the server support manual activation of MSP.

KaVir: Yes, I phrased that last part poorly. The first case indicates that the client supports MSP to some extent, but it doesn't indicate whether the mud can or should use that support.

Well the specification says that the server can begin to send sound triggers. It goes on to detail where it should look for files and valid fName/url parameters. It does suggest that clients may not support certain parameters. A reasonable implementation should obviously ignore parameters and formats it doesn't support, as well as files it doesn't have. It does say the implementation should support .wav and .mid files. It does suggest alternative ways to enable sound triggers. I agree the spec is poorly written, but it can be reasonably implemented.

You shouldn't automatically start throwing sound triggers at any client that responds IAC DO MSP

Yes, you should. The specification does say that.

KaVir: you'll have people complaining about their computers making strange beeping sounds (the response used by some clients to indicate a missing sound file).

I would consider that a poor client implementation. After all the spec does suggest that a client SHOULD be able to turn sound on or off manually on it's own end.


(Comment added by Tyche on Tue Jul 10 11:13:14 2012)

Yes, you should. The specification does say that.

Rather... Yes, you can or may.

dentin wrote:
If the client just sits there with its hands in its pockets, by definition the server should do nothing. It might not be correct telnet, but there's definitely a 'correct' behavior for the server.

Yup, I was just responding to the "if it doesn't support MSP, there is no response" point. That (lack of) response indicates broken telnet support, not a lack of MSP support.

dentin wrote:
What I'm getting out of this is "the spec is bad because most of the clients with MSP support are broken".

That's true too, but I was mostly complaining about the specification being poorly thought-out, and failing to take a lot of factors into consideration. It works, but it could have been done so much better.

Tyche wrote:
KaVir: The client should always respond, either with IAC DO MSP or IAC DONT MSP. It should never simply ignore the negotiation (the clients that do so have a broken telnet implementation - I'm looking at you, GMud).

Not always and never though. They MUST ignore a request for an option which has already been enabled/disabled unless the request changes the status quo.

Right, but I was specifically talking about the client's response to the initial server request. The client should always respond to "IAC WILL MSP" with either "IAC DO MSP" or "IAC DONT MSP".

Tyche wrote:
GMud doesn't claim to support or attempt to implement telnet at all. That's like saying Chrome's telnet implementation is broken. ;-)

Except that GMud is a mud client specifically designed for playing telnet-based muds.

Tyche wrote:
But it does appear you could implement MSP without telnet via script triggers if you follow the specifications suggestion that the server support manual activation of MSP.

Yes, I believe that's actually how most clients handle it. I don't know of any muds that don't have a command for manual activation.

Tyche wrote:
You shouldn't automatically start throwing sound triggers at any client that responds IAC DO MSP

Yes, you should. The specification does say that.

And yet the server has no idea whether the recipent wants sound, has the sound files, can download them if not, or can play the specified audio format. All of this stuff could have been handled automatically through subnegotiation, providing a seamless experience for the player.

Even protocols like MXP and MCCP (which are fully integrated into the client and therefore don't have to rely on any external files which may or may not exist) differentiate between support and active use. Yet MSP, which has numerous points of failure, automatically assumes that every client that supports the protocol must have the appropriate sound files and wish to play them.

Tyche wrote:
KaVir: you'll have people complaining about their computers making strange beeping sounds (the response used by some clients to indicate a missing sound file).

I would consider that a poor client implementation. After all the spec does suggest that a client SHOULD be able to turn sound on or off manually on it's own end.

Hearing repeated beeps is annoying (and not conductive to a newbie-friendly experience), even if the client has an option for switch sound off - which isn't a requirement of the specification. And passing the blame isn't really going to help the mud owner, the newbie doesn't care who's fault it is, all they know is that their experience sucks.

MSP is usable, but it could have been so much better. Rather than extending it, I'd far rather see a proposal for a better alternative.

KaVir wrote:
... Sorry for the negativity. I do think a better sound protocol is a great idea, perhaps as part of a more modern protocol, or something separate like Kaz's MSP2 proposal. But the original MSP should be left to rot in peace.

I don't like the change from "P=100" to "P 100" that appears to be proposed in the MSP2 spec that you mentioned.

Also, I don't see why the telnet negotiation can't merely be used to enquire as to whether it is supported. I have to wonder, should no response or an IAC DONT MSP have any effect on whether a command like 'set msp on' has any effect. I would think that doing that after the negotiations result in it not being used would spit out something like "MSP not supported by client", maybe an override argument to the command would be useful?

I think we can all agree that sound should not be sent unless the client supports it AND it is intentionally requested.

There does appear to be some conflict in that IAC DO MSP ought logically to result in automatic enabling of MSP. So, either it needs to be an exception or clients that don't want it (supported or not) should say IAC DONT MSP I guess.

KaVir wrote:
And yet the server has no idea whether the recipent wants sound, has the sound files, can download them if not, or can play the specified audio format. All of this stuff could have been handled automatically through subnegotiation, providing a seamless experience for the player.

Even protocols like MXP and MCCP (which are fully integrated into the client and therefore don't have to rely on any external files which may or may not exist) differentiate between support and active use. Yet MSP, which has numerous points of failure, automatically assumes that every client that supports the protocol must have the appropriate sound files and wish to play them.

Well, then maybe a discussion on subnegotiation options is in order?

Ideally, the client would ignore the messages or discard them if any of those points of failure are an issue, and hopefully report some of those details to the user. It wouldn't be perfect, but at least the end user would know. A mud with sound really should offer it's sound files as a downloadable archive file, preferably in multiple formats.

Perhaps a change to the spec that removes the need to indicate a file extensions where it is implied the client should select what type to use if it has one with that name?

KaVir wrote:

Tyche wrote:
GMud doesn't claim to support or attempt to implement telnet at all. That's like saying Chrome's telnet implementation is broken. ;-)

Except that GMud is a mud client specifically designed for playing telnet-based muds.

No it was designed to play muds, not telnet-based muds. GMud's last release was in 1995. It supported sound before the MSP specification was even written. I am aware of only one publicly available mud server that even supported telnet option negotiation prior to 1995, and that was MudOS. CircleMud, ROM, Smaug merely issued telnet WILL/WONT ECHO commands, and ignored the client response. A few muds at the time issued GoAhead commands in their prompts.

Here's a historical list of mud server code and when they first implemented a working telnet protocol stack:

LPMuds
-------
MudOS 0.9.18+ 1994
Amylaar 3.2.1+ 1996
LPMud-CD 3.3.1+ 1996
DGD 1.1 1996
LDMud 3.2.9+ 2000

TinyMuds
--------
MUQ 1997
PennMush 1.7+ 1997
FuzzballMuck 6.0+ 2002
TinyMux 2.4+ 2004

DikuMuds
--------
SmaugFUSS 1.7+ 2004

Mud servers were not by any stretch of the imagination "telnet-based" in 1995. And I seriously doubt that even half of the running muds today support telnet.

KaVir wrote:

And yet the server has no idea whether the recipent wants sound...

Sure it does. If the client doesn't want sound triggers sent it responds IAC DONT MSP.

KaVir wrote:

, has the sound files, can download them if not, or can play the specified audio format. All of this stuff could have been handled automatically through subnegotiation, providing a seamless experience for the player.

Even protocols like MXP and MCCP (which are fully integrated into the client and therefore don't have to rely on any external files which may or may not exist) differentiate between support and active use. Yet MSP, which has numerous points of failure, automatically assumes that every client that supports the protocol must have the appropriate sound files and wish to play them.

When you negotiate MXP and MCCP, the server is free to start sending MXP commands and compressed data respectively. This is exactly how MSP works. I don't see the difference.
While MSP2 is better written and uses subnegotiation, you still are going to ask the same questions to which I think have common sense answers:
* If you don't have the file, you don't play it,
* If you don't support .mid or .wav then you don't play it.
* If you don't support download, then you can't very well download it.
* If you don't support one of the parameters, you ignore the parameter.

Tyche wrote:

KaVir wrote:

Tyche wrote:
GMud doesn't claim to support or attempt to implement telnet at all. That's like saying Chrome's telnet implementation is broken. ;-)

Except that GMud is a mud client specifically designed for playing telnet-based muds.

No it was designed to play muds, not telnet-based muds.

You're arguing symantics. GMud was specifically intended for playing the same muds that were designed to be played with telnet clients, not muds that were designed to be played with web browsers. Chrome wasn't designed to play muds.

Tyche wrote:
GMud's last release was in 1995. It supported sound before the MSP specification was even written. I am aware of only one publicly available mud server that even supported telnet option negotiation prior to 1995, and that was MudOS. CircleMud, ROM, Smaug merely issued telnet WILL/WONT ECHO commands, and ignored the client response. A few muds at the time issued GoAhead commands in their prompts.

I know GMud is old, and I'm not suggesting it should support modern protocols. However it should reply with DONT/WONT to unrecognised telnet options. Not only does it not respond, it actually tries to display the negotiation sequences in the text window (at least the printable parts). Ever connected to a mud using GMud and had it display "V", "Z" and "[" at some random point in the login sequence? Those are the printable characters in the MCCP, MSP and MXP negotiations respectively.

Even if you think such an implementation is justified due to GMud's age (which I don't), the fact still remains that it causes problems with muds that support modern protocols - and GMud is just one example. Zugg's opinion that old clients should just "die" is fine if you're a client developer, but if you're running an active mud like Alter Aeon and potential players are using older clients to connect, what then? Do you throw out the baby with the bath water?

Tyche wrote:
When you negotiate MXP and MCCP, the server is free to start sending MXP commands and compressed data respectively. This is exactly how MSP works. I don't see the difference.

MSP:

Server: Do you support MSP? (IAC WILL MSP)
Client: Yes, I do (IAC DO MSP)

MCCP:

Server: Do you support MCCP? (IAC WILL MCCP)
Client: Yes, I do (IAC DO MCCP)
Server: Okay, everything after now will be compressed (IAC SB MCCP IAC SE)

MXP*:

Server: Do you support MXP? (IAC WILL MXP)
Client: Yes, I do (IAC DO MXP)
Server: Okay, I'm now using MXP (IAC SB MXP IAC SE)
Server: So, tell me which MXP features you support... (<SUPPORT>)
Client: I support bold, italics and colour (<SUPPORTS +B +I +COLOR>)

* Note that I've linked to Nick Gammon's MXP description, as Zugg's specification doesn't actually describe the negotiation at all - this is why some servers send WILL and others DO, and some clients expect DO while others expect WILL.

KaVir,

Actually, on Alter Aeon, the server does just toss out the various telnet sequences on startup. Specifically, we send WILL MSSP and WILL MSP. If we get responses back for these, then great - but if we don't get anything, it's pretty much implied that no further action is necessary.

Later on, we send WILL/DONT TELOPT_ECHO and DO/WONT TELOPT_ECHO sequences to turn off echo when entering passwords. The server doesn't even bother to track transaction state, and ignores responses (if any, because there's no point.)

Yes, it's invalid telnet. No, it doesn't appear to matter, and we have quite a few people (including some gods) using GMud.

So while I understand your complaint that older clients will be broken, the breakage appears to be easy to tolerate on the server side, and players certainly don't seem to be bothered by it.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

KaVir wrote:

Tyche wrote:


No it was designed to play muds, not telnet-based muds.

You're arguing symantics. GMud was specifically intended for playing the same muds that were designed to be played with telnet clients, not muds that were designed to be played with web browsers. Chrome wasn't designed to play muds.

I'm not arguing semantics; I'm arguing against reasoning backwards. Telnet clients were designed to work with stupid devices like teletypes, terminals, printers and brain dead software.... like text streams produced by local and remote programs (i.e. muds). Most Telnet clients were also cleverly designed to not make a peep about their telnet protocol when connecting to services that implemented other protocols that ran over TCP that also did not understand the telnet protocol. They could be used to debug FTP, Gopher, HTTP, and POP mail servers. It wasn't the other way around, because design requires intention and forethought. There very little evidence that mud server authors had any knowledge of the telnet protocol, let alone how to implement it. Rather they were aware Telnet happened to a program that allowed one to send text back and forth over a socket. They were not "telnet-based" servers.

KaVir wrote:
I know GMud is old, and I'm not suggesting it should support modern protocols. However it should reply with DONT/WONT to unrecognised telnet options. Not only does it not respond, it actually tries to display the negotiation sequences in the text window (at least the printable parts).

My position is that it is rather disingenuous to insist that someone ought to have written a client to conform to the telnet protocol when they wrote the software to communicate with servers that were incapable of understanding the telnet protocol. Why would Gmud, Tinytalk or any of the half dozen other contempory mud clients implement any part of the telnet protocol when none of the muds they communicated with ever sent them anything but a text stream over a TCP socket? So yes, it is like bashing Chrome, if suddenly some web server author up and decides to implement telnet and Chrome doesn't understand it. That's my point.

KaVir wrote:

Tyche wrote:
When you negotiate MXP and MCCP, the server is free to start sending MXP commands and compressed data respectively. This is exactly how MSP works. I don't see the difference.

MSP:

Server: Do you support MSP? (IAC WILL MSP)
Client: Yes, I do (IAC DO MSP)

MCCP:

Server: Do you support MCCP? (IAC WILL MCCP)
Client: Yes, I do (IAC DO MCCP)
Server: Okay, everything after now will be compressed (IAC SB MCCP IAC SE)

MXP*:

Server: Do you support MXP? (IAC WILL MXP)
Client: Yes, I do (IAC DO MXP)
Server: Okay, I'm now using MXP (IAC SB MXP IAC SE)
Server: So, tell me which MXP features you support... (<SUPPORT>)
Client: I support bold, italics and colour (<SUPPORTS +B +I +COLOR>)

* Note that I've linked to Nick Gammon's MXP description, as Zugg's specification doesn't actually describe the negotiation at all - this is why some servers send WILL and others DO, and some clients expect DO while others expect WILL.

Well I knew MCCP2 was screwed up as I pointed out on mudstandards.org, but I had no idea from reading the MXP specification that it was also screwed up. Issuing empty subnegotiations like IAC SB MXP IAC SE is lame and meaningless.

MCCP would have been correctly implemented as IAC SB MCCP escaped compressed data IAC SE or with the server immediately sending escaped compressed data after successfully negotiating MCCP.

Understanding and implementing how the negotiation works (should work) for MSP, is understanding how ECHO and BINARY are done.

Server: IAC WILL ECHO Do you want me to echo back what you send?
Client: IAC DO ECHO Yes, start echoing.
Client: foobar
Server: foobar

Server: IAC WILL BINARY Do you want me to send 8-bit binary
Client: IAC DO BINARY Yes, start sending me binary.
Server: 50¢ for a banana and £1 for the brass monkey.

Kaz's MSP2 specification that use subnegotiation is also a rational specification that works the same way.

The Telnet RFC (854) says:

   "The basic strategy for setting up the use of options is to have
   either party (or both) initiate a request that some option take
   effect.  The other party may then either accept or reject the
   request.  If the request is accepted the option immediately takes
   effect; if it is rejected the associated aspect of the connection
   remains as specified for an NVT. "

and

      WILL (option code)  251    Indicates the desire to begin
                                 performing, or confirmation that
                                 you are now performing, the
                                 indicated option.
      WON'T (option code) 252    Indicates the refusal to perform,
                                 or continue performing, the
                                 indicated option.
      DO (option code)    253    Indicates the request that the
                                 other party perform, or
                                 confirmation that you are expecting
                                 the other party to perform, the
                                 indicated option.
      DON'T (option code) 254    Indicates the demand that the
                                 other party stop performing,
                                 or confirmation that you are no
                                 longer expecting the other party
                                 to perform, the indicated option.

It's never been "Do you support XXX?", it's "Will you start doing XXX?"

Subnegotiations are requests to perform certain commands, set or receive more information relevant to option that both sides have already agreed to "perform" like....

IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE
IAC SB TERMINAL-TYPE SEND IAC SE
IAC SB TERMINAL-TYPE IS ... IAC SE
IAC SB MSSP MSSP_VAR "PLAYERS" MSSP_VAL "52" MSSP_VAR "UPTIME" MSSP_VAL "1234567890" IAC SE

Empty subnegotiations as a request to "turn on" the option already turned on is both lame and redundant. And it doesn't even support an answer the questions you asked in your previous post... for example:

Server: IAC WILL MXP Do you support MXP?
Client: IAC DO MXP Yes, I do.
Server: IAC SB MXP IAC SE Turn it on.
Client: No? I thought before you were just asking if I supported it. Zugg said so. How do I say no to you using it? I really don't want to turn it on!
Server: <!ELEMENT bwahaha>
Client: Stupid MXP.

Tyche wrote:
My position is that it is rather disingenuous to insist that someone ought to have written a client to conform to the telnet protocol when they wrote the software to communicate with servers that were incapable of understanding the telnet protocol. Why would Gmud, Tinytalk or any of the half dozen other contempory mud clients implement any part of the telnet protocol when none of the muds they communicated with ever sent them anything but a text stream over a TCP socket?

As you yourself pointed out, it was relatively common even back then for muds to send IAC WILL ECHO and IAC WONT ECHO. It seems unlikely that the developer of GMud didn't encounter those sequences during testing. If you were developing a new client and frequently encountered a strange sequence of bytes when connecting to muds, would you try to find out what that sequence meant and how to deal with it? Or would you just try and display it in the text window?

Tyche wrote:
Well I knew MCCP2 was screwed up as I pointed out on mudstandards.org, but I had no idea from reading the MXP specification that it was also screwed up. Issuing empty subnegotiations like IAC SB MXP IAC SE is lame and meaningless.

I won't defend the empty subnegotiation implementation, but do I think it is useful in many cases to distinguish between supporting a feature and using that feature, particularly in cases where usage depends on additional factors (such as with MSP relying on external sound files).

I'd actually rather see it work more like MSDP or ATCP, with commands for selecting file formats, activating sounds by category, verifying file versions, and so on. But talk is cheap, perhaps I should just build this functionality into the next version of my snippet.

Just to clarify what I mentioned above, the AA server doesn't even try to do proper telnet negotiation - because there's simply no point. We're compatible with telnet clients going all the way back to the old school VAX at UAFCS in alaska, and they were nowhere near sane.

Turning off local echo is a good example of this. We don't ask politely that the client turn off echo; we issue a DONT command and a WILL command. To turn it back on, we issue a DO/WONT pair. We don't listen for responses, we just send these back to back. The broken clients don't respond anyway, and working clients will do something intelligent. And yes, you have to send both sets of sequences to cover all the clients we work with.

I think it's a huge stretch to say that muds are a telnet based system at this point. Sure, it's a usable protocol, but a server can implement virtually none of it and still be completely functional. In fact, you have to implement a broken version of it simply to be compatible with existing clients.

At any rate, based on what I've seen so far, I may try my hand at clarifying the MSP spec and integrating the MSP2 transport into it. I'm starting to believe that a lot of the problems with existing MSP implementations is because the original spec was too vague, and everyone took away their own incompatible ideas of how it was supposed to work.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

Why would you repeat that you intentionally ignore parts of the telnet protocol, yet in the next paragraph, explain how you may want to clarify the MSP spec because its too vague?

A statement like this simply makes no sense to me. At our mud, we do the best we can to follow the specs/protocols and add in additional hacks ( which I greatly despise ) for the older clients.

Why should people follow an improved spec for MSP when, for the most part, the telnet protocol is pretty well put together and you, yourself say you don't follow it because there "is no point"?

Shouldn't we be encouraging people to follow some protocols, and if not, why bother spending time "clarifying" MSP?

Don't get me wrong, I hate coding around older clients, especially gmud but I really feel we should do the best we can to follow those protocols which greatly enhance our games...

KaVir wrote:

As you yourself pointed out, it was relatively common even back then for muds to send IAC WILL ECHO and IAC WONT ECHO. It seems unlikely that the developer of GMud didn't encounter those sequences during testing. If you were developing a new client and frequently encountered a strange sequence of bytes when connecting to muds, would you try to find out what that sequence meant and how to deal with it? Or would you just try and display it in the text window?

If I didn't have any interest in Telnet, I'd eat it and ignore it. If I was to investigate it further I'd discover the most mud servers then and even now ignore my response anyway. It's 2012, and muds are still not implementing Telnet negotiation correctly.

And for what it's worth, your MSDP snippet doesn't respond to client negotiations either. I did a test login to Godwars 2 with PuTTY and it completely ignores the client's requests like ... IAC WILL NEW_ENVIRON, IAC WILL SUPGA, IAC DO SUPGA, and it still ignores IAC DO ECHO and IAC DONT ECHO.

Dentin wrote:
Turning off local echo is a good example of this. We don't ask politely that the client turn off echo; we issue a DONT command and a WILL command. To turn it back on, we issue a DO/WONT pair. We don't listen for responses, we just send these back to back. The broken clients don't respond anyway, and working clients will do something intelligent. And yes, you have to send both sets of sequences to cover all the clients we work with.

Sending DO ECHO is a request to echo the servers output back to it. Almost every Telnet client will refuse this request. I'm not sure if it still does, but BSD Telnet would graciously agree to this request and start echoing back everything the serve sends.

What happens is this:

> say hi
You say "hi"
> You say "hi"
Huh?
> > You say "hi"
Huh?
> > > You say "hi"
Huh?
Huh?

Until shortly the player blows the input buffer and gets sent a Stop spamming message and is disconnected.

Why would you ever send IAC DO ECHO to a client?

Sending DO ECHO is a request to echo the servers output back to it. Almost every Telnet client will refuse this request.

Actually, DO ECHO means 'echo back what's typed into the terminal locally', which is the default. If BSD implements it the way you mentioned, BSD is broken.

Basically, the ECHO feature is simply which side echoes what's typed into it; sending WILL/DONT from the server means "The server will echo typed characters, so you dont have to". DO/WONT is "You need to echo typed characters, because I won't". Both of these are needed, because some clients only respect WILL/WONT, while other clients only respect DO/DONT.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

We ignore large parts of the telnet protocol because there's no point. It's simple request/response, and we only use an extremely limited subset of it: echo on/off, MSP negotiation, and MSSP negotiation. There's not really anything else we need to do, as clients don't request anything else without the server indicating support.

Shouldn't we be encouraging people to follow some protocols, and if not, why bother spending time "clarifying" MSP?

Because there's no substitute for MSP that works as well as it does, and MSP itself is very badly specified.

If we're going to be encouraging people to follow protocols like MSP, then they should be promoted to being actual protocols, with specs that are implementable in a fashion that can be used consistently across all muds that support it.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

dentin wrote:

Sending DO ECHO is a request to echo the servers output back to it. Almost every Telnet client will refuse this request.

Actually, DO ECHO means 'echo back what's typed into the terminal locally', which is the default. If BSD implements it the way you mentioned, BSD is broken.

Basically, the ECHO feature is simply which side echoes what's typed into it; sending WILL/DONT from the server means "The server will echo typed characters, so you dont have to". DO/WONT is "You need to echo typed characters, because I won't". Both of these are needed, because some clients only respect WILL/WONT, while other clients only respect DO/DONT.

-dentin

Alter Aeon MUD
http://www.alteraeon.com

[Docs] [txt|pdf]

STANDARD

Network Working Group                                          J. Postel
Request for Comments: 857                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 15390                                            May 1983

                           
TELNET ECHO OPTION



This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.

1. Command Name and Code


   ECHO       1

2. Command Meanings


   IAC WILL ECHO

      The sender of this command REQUESTS to begin, or confirms that it
      will now begin, echoing data characters it receives over the
      TELNET connection back to the sender of the data characters.

   IAC WON'T ECHO

      The sender of this command DEMANDS to stop, or refuses to start,
      echoing the data characters it receives over the TELNET connection
      back to the sender of the data characters.

   IAC DO ECHO

      The sender of this command REQUESTS that the receiver of this
      command begin echoing, or confirms that the receiver of this
      command is expected to echo, data characters it receives over the
      TELNET connection back to the sender.

   IAC DON'T ECHO

      The sender of this command DEMANDS the receiver of this command
      stop, or not start, echoing data characters it receives over the
      TELNET connection.

3. Default


   WON'T ECHO

   DON'T ECHO

      No echoing is done over the TELNET connection.

4. Motivation for the Option



Postel & Reynolds                                               [Page 1]

 
RFC 857                                                         May 1983


   The NVT has a printer and a keyboard which are nominally
   interconnected so that "echoes" need never traverse the network; that
   is to say, the NVT nominally operates in a mode where characters
   typed on the keyboard are (by some means) locally turned around and
   printed on the printer.  In highly interactive situations it is
   appropriate for the remote process (command language interpreter,
   etc.) to which the characters are being sent to control the way they
   are echoed on the printer.  In order to support such interactive
   situations, it is necessary that there be a TELNET option to allow
   the parties at the two ends of the TELNET connection to agree that
   characters typed on an NVT keyboard are to be echoed by the party at
   the other end of the TELNET connection.

5. Description of the Option


   When the echoing option is in effect, the party at the end performing
   the echoing is expected to transmit (echo) data characters it
   receives back to the sender of the data characters.  The option does
   not require that the characters echoed be exactly the characters
   received (for example, a number of systems echo the ASCII ESC
   character with something other than the ESC character).  When the
   echoing option is not in effect, the receiver of data characters
   should not echo them back to the sender; this, of course, does not
   prevent the receiver from responding to data characters received.

   The normal TELNET connection is two way.  That is, data flows in each
   direction on the connection independently; and neither, either, or
   both directions may be operating simultaneously in echo mode.  There
   are five reasonable modes of operation for echoing on a connection
   pair:


                <----------------

      Process 1                   Process 2
                ---------------->
                 Neither end echoes


                <----------------
                   \
      Process 1    /              Process 2
                ---------------->
             One end echoes for itself






Postel & Reynolds                                               [Page 2]

 
RFC 857                                                         May 1983



                <----------------
                             \
      Process 1              /    Process 2
                ---------------->
          One end echoes for the other


                <----------------
                   \         /
      Process 1    /         \    Process 2
                ---------------->
          Both ends echo for themselves


                <----------------
                   \ /
      Process 1    / \            Process 2
                ---------------->
           One end echoes for both ends

   This option provides the capability to decide on whether or not
   either end will echo for the other.  It does not, however, provide
   any control over whether or not an end echoes for itself;  this
   decision must be left to the sole discretion of the systems at each
   end (although they may use information regarding the state of
   "remote" echoing negotiations in making this decision).

   It should be noted that if BOTH hosts enter the mode of echoing
   characters transmitted by the other host, then any character
   transmitted in either direction will be "echoed" back and forth
   indefinitely.  Therefore, care should be taken in each implementation
   that if one site is echoing, echoing is not permitted to be turned on
   at the other.

   As discussed in the TELNET Protocol Specification, both parties to a
   full-duplex TELNET connection initially assume each direction of the
   connection is being operated in the default mode which is non-echo
   (non-echo is not using this option, and the same as DON'T ECHO, WON'T
   ECHO).

   If either party desires himself to echo characters to the other party
   or for the other party to echo characters to him, that party gives
   the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes)
   for acceptance of the option.  If the request to operate the
   connection in echo mode is refused, then the connection continues to
   operate in non-echo mode.  If the request to operate the connection
   in echo mode is accepted, the connection is operated in echo mode.


Postel & Reynolds                                               [Page 3]

 
RFC 857                                                         May 1983


   After a connection has been changed to echo mode, either party may
   demand that it revert to non-echo mode by giving the appropriate
   DON'T ECHO or WON'T ECHO command (which the other party must confirm
   thereby allowing the connection to operate in non-echo mode).  Just
   as each direction of the TELNET connection may be put in remote
   echoing mode independently, each direction of the TELNET connection
   must be removed from remote echoing mode separately.

   Implementations of the echo option, as implementations of all other
   TELNET options, must follow the loop preventing rules given in the
   General Considerations section of the TELNET Protocol Specification.
   Also, so that switches between echo and non-echo mode can be made
   with minimal confusion (momentary double echoing, etc.), switches in
   mode of operation should be made at times precisely coordinated with
   the reception and transmission of echo requests and demands.  For
   instance, if one party responds to a DO ECHO with a WILL ECHO, all
   data characters received after the DO ECHO should be echoed and the
   WILL ECHO should immediately precede the first of the echoed
   characters.

   The echoing option alone will normally not be sufficient to effect
   what is commonly understood to be remote computer echoing of
   characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD option
   will normally have to be invoked in conjunction with the ECHO option
   to effect character-at-a-time remote echoing.

6. A Sample Implementation of the Option


   The following is a description of a possible implementation for a
   simple user system called "UHOST".

   A possible implementation could be that for each user terminal, the
   UHOST would keep three state bits: whether the terminal echoes for
   itself (UHOST ECHO always) or not (ECHO mode possible), whether the
   (human) user prefers to operate in ECHO mode or in non-ECHO mode, and
   whether the connection from this terminal to the server is in ECHO or
   non-ECHO mode.  We will call these three bits P(hysical), D(esired),
   and A(ctual).

   When a terminal dials up the UHOST the P-bit is set appropriately,
   the D-bit is set equal to it, and the A-bit is set to non-ECHO.  The
   P-bit and D-bit may be manually reset by direct commands if the user
   so desires.  For example, a user in Hawaii on a "full-duplex"
   terminal, would choose not to operate in ECHO mode, regardless of the
   preference of a mainland server.  He should direct the UHOST to
   change his D-bit from ECHO to non-ECHO.

   When a connection is opened from the UHOST terminal to a server, the


Postel & Reynolds                                               [Page 4]

 
RFC 857                                                         May 1983


   UHOST would send the server a DO ECHO command if the MIN (with
   non-ECHO less than ECHO) of the P- and D-bits is different from the
   A-bit.  If a WON'T ECHO or WILL ECHO arrives from the server, the
   UHOST will set the A-bit to the MIN of the received request, the
   P-bit, and the D-bit.  If this changes the state of the A-bit, the
   UHOST will send off the appropriate acknowledgment; if it does not,
   then the UHOST will send off the appropriate refusal if not changing
   meant that it had to deny the request (i.e., the MIN of the P-and
   D-bits was less than the received A-request).

   If while a connection is open, the UHOST terminal user changes either
   the P-bit or D-bit, the UHOST will repeat the above tests and send
   off a DO ECHO or DON'T ECHO, if necessary.  When the connection is
   closed, the UHOST would reset the A-bit to indicate UHOST echoing.

   While the UHOST's implementation would not involve DO ECHO or DON'T
   ECHO commands being sent to the server except when the connection is
   opened or the user explicitly changes his echoing mode, bigger hosts
   might invoke such mode switches quite frequently.  For instance,
   while a line-at-a-time system were running, the server might attempt
   to put the user in local echo mode by sending the WON'T ECHO command
   to the user; but while a character-at-a-time system were running, the
   server might attempt to invoke remote echoing for the user by sending
   the WILL ECHO command to the user.  Furthermore, while the UHOST will
   never send a WILL ECHO command and will only send a WON'T ECHO to
   refuse a server sent DO ECHO command, a server host might often send
   the WILL and WON'T ECHO commands.























Postel & Reynolds                                               [Page 5]


Html markup produced by rfcmarkup 1.101, available from http://tools.ietf.org/tools/rfcmarkup/ 

The BSD Telnet client I mentioned IS NOT broken.
The GNU Telnet client IS NOT broken.
Both follow the specification above.
The difference is the GNU Telnet program refuses to agree to the DO ECHO request from a server because it doesn't believe the other end really wants to do that. The BSD Telnet client agrees to do exactly what the server asked.
If any mud client responded WILL ECHO to a mud that sent DO ECHO to it, and then started echoing back everything that the server sent it in the fashion I described earlier, it would also be following the ECHO specification as well.

The problem is that your implementation of ECHO is broken.

For a correct implementation of a telnet protocol stack see:

https://github.com/elanthis/libtelnet

Also see AweMud or my own TeensyMud.

As a followup, here is a session between PuTTY and Alter Aeon accompanied by constructive criticism.

Just after connect AA sends:
IAC WILL MSSP
IAC WILL MSP

It is followed by the welcome screen and the prompt asking the user if they would like to create a character.
Note: AA uses \n\r for end of line processing, while the Telnet specification defines that \r\n or \r\0 be used to denote an end of line. [1][2][3]

PuTTY responds:
IAC DONT MSSP
IAC DONT MSP

The user typed yes.

AA responds with:
IAC DO ECHO - a request to the client to start echoing back everything the server sends to it.
IAC WONT ECHO - an announcement that it will now stop echoing for the client.
Note: AA doesn't follow the telnet specification here because the current state of session is that AA is not
echoing for the client.[5]
IAC GA - See notes on Go Aheads [6],[7],[8]


PuTTY responds:
IAC WONT ECHO - Note this is the response to ill-advised request that PuTTY echo back every AA sends.
Note that PuTTY does not respond to the AA's WONT ECHO request because that is the current state of the session.
Ignoring a request to enter a state that we are already in is a proper response. [4]

AA goes on to ask a series of questions and finally comes to the point where is asks for a password, where is sends:
IAC WILL ECHO - an offer to echo back what the client sends.
IAC DONT ECHO - a demand that the client not echo back what the server sends.
Note: AA doesn't follow the telnet specification here because the current state of session is that PuTTY is not
echoing back what the mud server sends.[5]
IAC GA

PuTTY responds:
IAC DO ECHO - PuTTY accepts the offer from the server to echo back what it sends
IAC WILL SUPGA - PuTTY requests permission to begin supressing of go aheads.
IAC DO SUPGA - PuTTY requests that the server not send go aheads.

The session continues. AA never acknowledges PuTTY's requests to suppress Go aheads.[5][7][9]


[1] "Note that "CR LF" or "CR NUL" is required in both directions (in the default ASCII mode), to preserve the symmetry of the
NVT model. ... the protocol requires that a NUL be inserted following a CR not followed by a LF in the data stream.
- TELNET PROTOCOL SPECIFICATION - RFC 854
[2] "A User Telnet MUST be able to send any of the forms: CR LF, CR NUL, and LF. A User Telnet on an ASCII host SHOULD have a
user-controllable mode to send either CR LF or CR NUL when the user presses the "end-of-line" key, and CR LF SHOULD be the
default." - Requirements for Internet Hosts -- Application and Support - RFC 1123 section 3.3.1
[3] "An end-of-line is transmitted as the 2-character sequence CR (carriage return) followed by
an LF (linefeed). We show this as \r\n. A carriage return is transmitted as the 2-character
sequence CR followed by a NUL (byte of 0). We show this as \r\0." - TCP-IP Illustrated Vol 1. W. Richard Stevens, 26.4 Telnet Protocol
[4] "If a party receives what appears to be a request to enter some mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the negotiation. It is required that a response be sent to requests
for a change of mode -- even if the mode is not changed." - TELNET PROTOCOL SPECIFICATION - RFC 854 - General Considerations 3.
[5] "Parties may only request a change in option status; i.e., a party may not send out a "request" merely to announce what mode it
is in." - TELNET PROTOCOL SPECIFICATION - RFC 854 - General Considerations 3.
[6] TELNET SUPPRESS GO AHEAD OPTION - RFC 858
[7] "A User or Server Telnet MUST always accept negotiation of the Suppress Go Ahead option." -
Requirements for Internet Hosts -- Application and Support - RFC 1123 section 3.2.2
[8] "Half-duplex.
This is the default mode, but it is rarely used today. The default NVT is a halfduplex
device that requires a GO AHEAD command (GA) from the server before
accepting user input. The user input is echoed locally from the NVT keyboard to the
NVT printer so that only completed lines are sent from the client to the server.
While this provides the lowest common denominator for terminal support, it doesn't
adequately handle full-duplex terminals communicating with hosts that support fullduplex
communications, which is the norm today. RFC 857 [Postel and Reynolds
1983c] defines the ECHO option and RFC 858 [Postel and Reynolds 1983d] defines
the SUPPRESS GO AHEAD option. The combination of these two options provides
support for the next mode, character at a time, with remote echo." -
TCP-IP Illustrated Vol 1. W. Richard Stevens, 26.4 Telnet Protocol
[9] A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option.
- Requirements for Internet Hosts -- Application and Support - RFC 1123 section 3.2.1

The problem is that your implementation of ECHO is broken.

I stand corrected.

Thanks, Tyche.

-dentin

Alter Aeon MUD
http://www.alteraeon.com