I'm spawning this to the MSSP sub-forum since MSSP and MSDP are closely related protocols.


The ATCP specification is oddly written, I get the feeling they never took a close look at how NEW-ENVIRON or TELNET in general works. As far as I can tell it'll be fairly easy for a server to send IAC DO MSDP IAC WILL MSDP. I must admit that I can't think of a good practical example of where this behavior is actually useful. The best thing that comes to mind is that a server wants to use MSDP for sending data, but use a different protocol (plain text for example) for receiving data.


Not necessarily, but it's important to standardize things somewhat so scripts won't need too much adjustment to work across servers.


To keep a consistent tone and point of reference I strongly prefer: SEND, REPORT, and EXECUTE. Otherwise you go from telling the server what to do (SEND), to telling the server what the client is doing (OBSERVE), to what your data is (INPUT).


Same story as above, how about: IAC SB MSDP VAR "LIST" VAL "COMMANDS" IAC SE upon which the other party responds with: IAC SB MSDP VAR "COMMANDS" VAL "SEND" VAL "REPORT" VAL "EXECUTE" VAL "LIST" IAC SE


I'll go ahead and make some changes. If you're reading this Tyche, your feedback would be appreciated, and for that matter from anyone else who is interested.


I think many people on MudStandards would feel threatened by MSDP, not understanding that MSDP is not in competition with ATCP (or ZMP for that matter). MSDP is intended as a server->client_user data protocol, and ATCP more so as a server->client_developer master/slave protocol with package that define how the client should respond to the server.

I also think I'll get much more done discussing this with a handful of interested individuals rather than spending most of my time refuting baseless arguments/accusations by people who aren't really all that interested, or have conflicting interests. Also, MSDP specifically caters to the environment independent needs of TinTin++, and with me in charge of the specification there are the limitations of my objectivity, reasoning, and intelligence.

The plus side is that the actual protocol is very simple, and all the variables are merely suggestions.

Well, that's certainly an interesting statement, and explains a lot.

I went ahead and updated the specification.

1. Two way MSDP communication negotiation is now clearly defined, with additional restrictions that should prevent infinite telnet loops.

2. If several values are reported for one variable it's called a 'list' in the specification.

3. I removed a few variables that were not generic enough and changed a few variables. I had a separate "LIFE" variable to contain a percentage, then I figured it'd be easier for the server to report "MAX HEALTH" as 100, and from then on report "HEALTH" as a value between 0 and 100 to simulate a percentage. I'm trying to avoid using Diku specific variable names that aren't common in other families, please let me know if that's the case though.

4. I defined two client side commands, "COMMAND" : "<list of supported commands>", "VARIABLES" : "list of supported variables"

5. I defined four server side commands, "EXECUTE" : "<list of user commands to execute>" (not sure if this is really needed?), "LIST" : "<COMMANDS|VARIABLES>", "REPORT" : "<list of variables client will observe>", "SEND" : "<list of variables client wants sent>".

6. Added the first MSDP server *discos*

7. Added some extra room variables to aid auto mappers. I still have to double check that they're compatible with the unfinished MMP draft. As far as I'm concerned it's alright to provide similar data sets using different interfaces, as is the case with MSSP telnet and MSSP plaintext.

Server: IAC WILL MSDP
Client: IAC DO MSDP
Server: IAC DO MSDP
Client: IAC WILL MSDP

That really doesn't look right to me. I thought it was fine the first time:

Server: IAC WILL MSDP (I understand MSDP)
Client: IAC DO MSDP (I also understand MSDP)

Then you'd proceed like this:

Client: IAC SB MSDP MSDP_VAR "LIST" MSDP_VAL "COMMANDS" IAC SE

Server: IAC SB MSDP MSDP_VAR "COMMANDS" MSDP_VAL "EXECUTE" MSDP_VAL "REPORT" MSDP_VAL "SEND" IAC SE

Client: IAC SB MSDP MSDP_VAR "LIST" MSDP_VAL "VARIABLES" IAC SE

Server: IAC SB MSDP MSDP_VAR "VARIABLES" MSDP_VAL "HEALTH" MSDP_VAL "MANA" MSDP_VAL "CAKE" IAC SE

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "HEALTH" IAC SE

Server: IAC SB MSDP MSDP_VAR "HEALTH" MSDP_VAL "500" IAC SE

As far as I can see the server never sends anything without the client first asking for it - even in the case of REPORT, the client explicitly tells the server to keep it updated.


Then you might want to rename the "LIST" command to something else.


As long as they're optional. I don't need most of those, but I'll need plenty of others.

These shouldn't even really be necessary though, as the client can use "VARIABLES" to find out which options are available. Having said that, I guess it might be useful to have a common variable set for people moving between similar muds, so that the same plugin will work in multiple places.


Presumably in response to "LIST"? It might be worth breaking the commands into server and client categories.

As far as I can tell MSDP now works in the same way as NEW-ENVIRON in this regard: http://www.faqs.org/rfcs/rfc1572.html though that entire rfc is kind of obscure.


It hasn't been agreed upon however that the server supports the LIST command, that's a minor inconvenience though as the server can simply ignore it.

What use cases do you envision for the EXECUTE command? Keep in mind that it's easy for a mud client to send "<any kind of command>\n" to a server at any point in time. To me it seems redundant.


Can't think of a better variable name. Might be better to stick with calling multiple MSDP_VAL calls an array.


In my experience the average person is going to need a basic example script to work from, so re-use is key to success. If you end up making your own mini-spec with variables for gw2 I'd like to add a link to it on the spec so other developers can duplicate your variable names.


It'd indeed be in response to "LIST". I'll go ahead and split it up as it's somewhat cluttered looking currently.

There are always four possible negotiations. They are all significant if the option is bidirectional.



This is correct. These are the two negotiations to enable MSDP in both possible directions assuming the server starts negotiation.
There are also two complementary negotiations where the client starts the negotiation. These aren't specified.



Rather both the client and server should implement a method that doesn't cause infinite loops, like the Q method in RFC 1143.

Aside:
I attempted to make this point over in the MDCP+ discussion.
http://www.mudstandards.org/forum/viewto...
I got the distinct impression the author doesn't think it worthy of correcting. ;-)

This is somewhat confusing. I'd just strike it in preference to your next section which I quoted above.

RFC 1143 gives me a headache every time I try to read it. As far as I can tell it proposes that every state change (using DO DONT etc) needs to be confirmed, but, don't confirm the same thing twice to avoid loops.

As far as I can tell the TELNET protocol doesn't demand confirming each state change, the receiver of a state change only needs to abide by it. So RFC 1143 is a patch for protocols that demand pointless handshaking. I think the pro state machine crowd will agree with me, unless they prefer two state machines above one state machine, or disagree with me just to make a statement.

I could change the spec to state the client should only respond to an IAC D/W request once to communicate its state to the server, but that would require storing an additional state. The current approach is easier as the client can respond with the same message to an IAC DO MSDP and IAC DONT MSDP request, and the overhead is minimal, especially if you assume that in most cases neither the server nor the client will change states.

So what you quoted as confusing simply describes what state is communicated, there is no confirmation of states in MSDP.

With the whole handshake thing, how about an unofficial way to confirm that variables are received correctly?

KaVir chats: IAC SB MSDP VAR "TEST" VAL "CUCUMBERS ARE GREEN" IAC SE
Scandum chats: IAC SB MSDP VAR "CONFIRM" VAL "TEST" VAL "CUCUMBERS ARE GREEN?" IAC SE
KaVir chats: IAC SB MSDP VAR "RECONFIRM" VAL "TEST" VAL "NO QUESTION MARK!" VAL "REMEMBER, DEFAULT VALUE LAST!" VAL "CUCUMBERS ARE GREEN" IAC SE
Scandum chats: IAC SB MSDP VAR "CONFIRM" VAL "TEST" VAL "My bad!" VAL "CUCUMBERS ARE GREEN!" IAC SE
KaVir chats: IAC SB MSDP VAR "TEST" VAL "*sigh*" IAC SE IAC WONT MSDP IAC DONT MSDP
Scandum chats: IAC SB MSDP VAR "COMMANDS" VAL "NEVERTOOOLDTOPICKUPYOURTOYSANDGOHOME" IAC SE
Scandum chats: IAC SB MSDP VAR "TEST" VAL "HELLO?!?!!" IAC SE
[/humor][/offtopic]

Looks complex.

Sorry quoting broken on my end, reverting to

@scandum - RFC 1143 gives me a headache every time I try to read it. As far as I can tell it proposes that every state change (using DO DONT etc) needs to be confirmed, but, don't confirm the same thing twice to avoid loops.

Yes it gave me a headache as well. Regardless I recognize its value and it is indeed exactly what I implemented in the Teensymud telopt handler by reading the section: 7. Example of Correct Implementation while coding it. I even used the same terms in the sample state machine as variable names and symbols.

@scandum - As far as I can tell the TELNET protocol doesn't demand confirming each state change, the receiver of a state change only needs to abide by it. So RFC 1143 is a patch for protocols that demand pointless handshaking.

It [rfc 1143] describes the problems that lead to option negotiation loops. If implemented, there isn't any additional negotiation or pointless handshaking. I don't think any of the telnet protocols demand extra handshaking but it is a given that broken implementations of them can engage in it.

@scandum - I think the pro state machine crowd will agree with me, unless they prefer two state machines above one state machine, or disagree with me just to make a statement.

Yeah I implement Telnet protocol as a state machine and Telnet option negotiation as the Q state machine within that state machine. I also implement VT100 protocol on top of it as another state machine. So I'm a three state machine guy. I simply view it as a necessary and obvious implementation, not just to be disagreeable or anything. It works. No headaches. No assumptions.

@scandum - So what you quoted as confusing simply describes what state is communicated, there is no confirmation of states in MSDP.

I thought it confusing as the context isn't explicit until the next section, because…
IAC DO can be a response to a senders offer.
and
IAC DO can be a request that receiver do something.

When we get to this…


Suddenly it makes sense… except it doesn't because certainly when the server offers…
IAC WILL MSDP
the above might be construed to for the server to ignore..
IAC DO MSDP
from the client.

When clearly you don't really mean that. You really mean to accept client DO as an answer to serve WILL… but not DO as a client request. If you think tracking the state of whether this occurred or not is just overhead, then I don't know what to suggest to you other than some sort of …err… …umm… I don't know what to call it… maybe "state machine"? >:->

From reading the spec it looks like the old version of MSDP (the one I mentioned above) works in the same way as NEW-ENVIRON:

"Once the two hosts have exchanged a WILL and a DO, the sender of the DO NEW-ENVIRON is free to request that environment variables be sent. Only the sender of the DO may send requests (IAC SB NEW-ENVIRON SEND IAC SE) and only the sender of the WILL may transmit actual environment information (via the IAC SB NEW-ENVIRON IS … IAC SE command)."

A couple of examples from random googling:

Example 1: http://old.honeynet.org/scans/arch/scan6...

SENT WILL NEW-ENVIRON
RCVD DO NEW-ENVIRON
RCVD IAC SB NEW-ENVIRON SEND
SENT IAC SB NEW-ENVIRON IS

Example 2: http://www.net-tex.de/net/telnet.html

SENT WILL NEW-ENVIRON
RCVD DO NEW-ENVIRON
RCVD IAC SB NEW-ENVIRON SEND
SENT IAC SB NEW-ENVIRON IS VAR "USER" VALUE "stefan"

Compare this with the old proposal:

SENT WILL MSDP
RCVD DO MSDP
RCVD IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "HEALTH"
SENT IAC SB MSDP MSDP_VAR "HEALTH" MSDP_VAL "500"

I can't find any examples of a host sending both DO and WILL (for the same protocol) and receiving both in return. Even in Tyche's ECHO example, only one host WILL ECHO for the other at a time (for obvious reasons).

Or did I misunderstand your proposal? Are you suggesting it should work like this:

Server: IAC WILL MSDP
Client: IAC DO MSDP

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "CONFIG:BLANK" IAC SE
Server: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "0" IAC SE

Client: IAC DONT MSDP
Server: IAC WONT MSDP
Client: IAC WILL MSDP
Server: IAC DO MSDP

Client: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "1" IAC SE

Client: IAC WONT MSDP
Server: IAC DONT MSDP
Client: IAC DO MSDP
Server: IAC WILL MSDP

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "CONFIG:BLANK" IAC SE
Server: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "1" IAC SE

Or like this:

Server: IAC WILL MSDP
Client: IAC DO MSDP
Server: IAC DO MSDP
Client: IAC WILL MSDP

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "CONFIG:BLANK" IAC SE
Server: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "0" IAC SE

Client: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "1" IAC SE

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "CONFIG:BLANK" IAC SE
Server: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "1" IAC SE

I.e., do the server and client switch their roles back and forth (like with ECHO), or do they agree in advance on two-way communication?


But if the client sends "<any kind of command>\n", won't the text of that command echo in the client window? I also wonder if it might be worth having an option that returns the output of an EXECUTE.

I think I'll clearly state that state changes don't need to be confirmed, and that the client should only answer back on the first negotiation to make the server aware of the client state. For things like echo it makes sense to push each other around in order to ensure agreement, but I don't see the practical value for MSDP.


I think you're right, looks like NEW-ENVIRON is a one way street that can be switched around. I doubt many people would want to implement that for MSDP.


My current view is that they should agree once in advance. They can change their state in the middle of the connection, and the other party should respect it without sending a confirmation. I'll try to update the specification to reflect this.

Well the ECHO RFC is somewhat different because it implies that the default un-negotiated mode is to not echo ones own input. So there are 6 possible modes, but only 5 are reasonable. However, there are still only 4 possible telnet negotiations. One of them is unreasonable, both echoing each others input.
The BINARY RFC would have probably been a better example to illustrate that MDSP can be switched on, on both ends. None of the four MDSP possible negotiations could would be considered unreasonable, IMO.

Of course the problem in just saying that the client should never begin negotiations, doesn't mean that it won't.

I'll take a look at the binary rfc. Still haven't gotten around to updating the spec page.


With tt++ you can use the #send command to send commands, and it won't be echoed to the terminal. I think it's reasonable to assume that any client capable of scripting MSDP is capable of sending commands quietly.

For function like behavior something like: VAR "FUNCTION NAME" VAL "ARG1" VAL "ARG2" VAL "…" could be used, and the server would respond with VAR "FUNCTION NAME" VAL "THE RESULT"

Then add VAR "LIST" VAL "FUNCTIONS" to get a list of functions. So the client would call a function with args, and the server would return the function's name as the variable holding the returned data.

Okay, I didn't realise that. But either way, MSDP is flexible enough to support an EXECUTE command without it being explicitly defined in the standard, so should there be the need for some obscure client there's no reason why a mud couldn't add the command.

Updated the spec, hopefully it's not too confusing.

I went ahead and removed the restriction in MSSP and MSDP to not use SE within variables or values. I believe that makes both protocols UTF-8 compatible. Not sure if it's worth adding some kind of way to identify client side UTF-8 capabilities.

Doing UTF-8 state handling the MSSP way the server would send: MSDP_VAR "UTF-8" MSDP_VAL "1" then the client would send MSDP_VAR "UTF-8" MSDP_VAL "1" which should be enough for developers to take it from there.

Okay so we've got:

Server: IAC WILL MSDP = The server wants to send data
Client: IAC DO MSDP = The server can now send data
Server: IAC DO MSDP = The server wants to receive data
Client: IAC WILL MSDP = The server can now receive data

This confused me for a while, and I could easily see it confusing other people as well, particularly if they copy and convert their MSDP script/plugin from something else (like ZMP). So what about clients that want to communicate in both directions but forget to respond to both requests?

Scenario 1:

Server: IAC WILL MSDP
Client: IAC DONT MSDP
Server: IAC DO MSDP
Client: IAC WILL MSDP
Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "CONFIG:BLANK" IAC SE

Scenario 2:

Server: IAC WILL MSDP
Client: IAC DO MSDP
Server: IAC DO MSDP
Client: IAC WONT MSDP
Client: IAC SB MSDP MSDP_VAR "CONFIG:BLANK" MSDP_VAL "1" IAC SE

In the above two scenarios, the client has only agreed to one-way communication, but it has explicitly requested communication in the other direction. This is obviously broken, but the intent is clear, and this is the sort of thing I could easily see happening due to the script/plugin writers having to add their own MSDP support.

I'm sure I've read about at least one protocol that permits the host to assume an implicit negotiation if you send it a subnegotiation sequence. On the other hand, it's also perfectly valid to ignore it - but that's not really very "friendly", and I'm adding this support to make life easier for people.

Another option could be to send the player an in-game notification that their client has a broken protocol, perhaps even directing them to an in-game dynamic help file that shows what they've done and what they still need to do. I'm currently favouring this option, but I'd still need to decide what to do next - either ignore the subnegotiation (other than a warning the first time it occurs), or assume an implicit negotiation.

Thoughts?

I think it wouldn't confuse people who aren't familiar with telnet, but probably more so those who are - who are most likely to implement it. Probably best to stick with a simple Server: IAC WILL MSDP, Client: IAC DO MSDP, and assume two way communication enabled.

I was thinking last night, and how does a MSDP_VAR "LIST" MSDP_VAL "PROTOCOLS" option sound to exchange a list of supported protocols? Mostly for UTF-8 and anything else that might become an option.

One thing I worry about is that things will become overly complex.

The problem then is that a client which correctly implements the protocol won't work - it'll be waiting for the server to send IAC DO MSDP before it sends any requests of its own.

Thus the server really does need to at least send IAC WILL MSDP IAC DO MSDP - the question is only how it should respond to subnegotation requests without both handshakes. Is each server allowed to decide for itself, or should it be explicitly defined in the spec?


MSSP already includes fields for most mud protocols, if you want to include other protocols I'd suggest adding them there.