06 Sep, 2010, Rudha wrote in the 1st comment:
Votes: 0
I've taken the liberty of collecting the various NM code snippets I'm aware of, from the mailing list/yahoo group/etc and uploading them here to help promote NakedMud and give NM devs a little more easily accessible point to get it from than the yahoo group (which requires a yahoo login) I hope this is okay. I've made sure to give credit as appropriate.

I've gotten the following modules to /socketmud/nakedmud/snippets, in no particular order:
    Persistent, Quest, Dialog, Currency, Act, Webserver, Affects, Object Bonus, MSSP Support, Consumables, and Stats, all by Geoff Hollis and from his site (http://homepages.uc.edu/~hollisgf/nakedm...) The autorun script has been in NM for a few versions, so I thought it would be redundant to include. The bulletin and shell modules are already in there.

    A simple backup script by Tyler Laing aka Drakkonite from the Yahoo groups site. He has also on there "extras.zip" which is supposed to show how to add extra worn spots, however I get errors about the file not being able to be read and couldn't download it.

    MD5Crypt by Patrick M. Nielsen aka thirsteh from the Yahoo groups site which is a package to change the normal crypt() with md5 passwords.

    Automatic Python OLC by Stendec from the Yahoo groups site, which allows editing instance information etc.

    Skills code and Currency/bank system code from Hera of Athens also on the Yahoo groups site. There was a version on the snippets section already for the bank/currency code but it was of a different version.


I also added Stendec's modified version of NakedMud v 3.8.1 with TELOPTs support to /socketmud/nakedmud.

Hopefully that's okay to do. The licensing seems to suggest that it is fine as long as you give credit; so be sure you do if you use them!

I'll disentangle some of my own code and put it up there when I have the inclination. I want to put my own TELOPTs thing there because, frankly, I feel it will offer more than Stendec's does, but I still need to implement a few things before I feel "safe" releasing it, specifically I need to tighten it up to follow RFC 1143 which is currently a problem for me; MushClient gets its self locked in a loop since neither the server nor it is currently adherent.

Maya/Rudha
06 Sep, 2010, Rudha wrote in the 2nd comment:
Votes: 0
A couple I missed from the Yahoo groups I tossed in there too: A simple junk command, and Item stats both by "trinetyrox". It seems I also missed the latest version of Hera's currency scripts, its in there as well, now.

Maya/Rudha
06 Sep, 2010, David Haley wrote in the 3rd comment:
Votes: 0
Quote
MushClient gets its self locked in a loop since neither the server nor it is currently adherent.

If you believe you have found a bug in MUSHclient's telopt handling, you should report it on the MUSHclient site. I've never heard of this bug; plenty of servers get along with MUSHclient just fine. I suspect it's due to a broken server implementation.
06 Sep, 2010, Rudha wrote in the 4th comment:
Votes: 0
I can't say I can rule out either, and I've not had the time to look at it comphrehensibly, but I suspect it's a little bit of both, since other clients seem to work fine. TT++, TinyFugue, and Mudlet all work fine. Don't have zMud or cMud to try those, though; I refuse to pay for a MUD client in this day and age.

Which is to say: I can't say whether it's something I'm doing or MushClient is doing at this point, but MC is the only one that behaves that way, which makes me suspicious.

Either way the server doesn't really check to make sure that it should be receiving multiple queries, so I do need to add some sanity checks there. Some protocols are easy: if we get multiple queries for MSSP they can probably be safely discarded. Other protocols are more difficult, MSDP in particular since it can be entirely legitimate to receive duplicate queries.

Maya/Rudha
06 Sep, 2010, David Haley wrote in the 5th comment:
Votes: 0
MUSHclient has a tendency to actually respect protocols etc., whereas other clients are forgiving or sloppy (depending on your perspective). As a result, this can make MUSHclient seem to be buggy, whereas in reality it's doing exactly as it should be. (See also MXP with MUSHclient vs. Zuggsoft). Again, since I know of a very great deal of servers that can do telopt negotiation with MUSHclient just fine, I'm inclined to believe that it does what it should be doing and something in this code is breaking the protocol sufficiently for it to cause big trouble.
06 Sep, 2010, Rudha wrote in the 6th comment:
Votes: 0
After tossing some simple debugging output in…

TELOPT negotiation for thing should be a simple WILL/WONT and DO/DONT negotiation. MushClient is sending multiple DO calls to a single WILL/WONT negotiation.

TT++'s debug mode - which is really handy by the way, reveals the negotiation:

RCVD IAC WILL EXTEND ASCII
SENT IAC DONT EXTEND ASCII
RCVD IAC WILL TTYPE
SENT IAC DO TTYPE
RCVD IAC WILL MSSP
SENT IAC DO MSSP
RCVD IAC WILL MSDP
SENT IAC DONT MSDP
RCVD IAC WILL MSP
SENT IAC DONT MSP
RCVD IAC WILL 200
SENT IAC DONT 200

This results in the following debug information from my SOCKETS command:

Socket 2 info: DO TERMTYPE, DO MSSP, DONT MSDP, DONT MSP, DONT ATCP

I note that it doesn't seem to catch extend_ascii; that might be it there. But the real problem is that it gives multiple responses to a single WILL/WONT challenge which is confusing the server. It is worth telling the server to discard repetitive information, but determining what's a looping repetitive response instead of a legitimate disabling of a feature is tricky. I may just make it for simplicity's sake discard any extra responses after the original, until I can implement RFC 1143.

The RFC highlights the problems of following normal TELOPT negotiation to the letter of the protocol which both the server and the client are doing:

RFC 1143 said:
Both sides know that the option is on.

On his side:
1 He decides to disable. He sends DONT and disables the option.
2 He decides to reenable. He sends DO and remembers he is
negotiating.
5 He receives WONT and gives up on negotiation.
6 He decides to try once again to reenable. He sends DO and
remembers he is negotiating.
7 He receives WONT and gives up on negotiation.
For whatever reason, he decides to agree with future requests.
10 He receives WILL and agrees. He responds DO and enables the
option.
11 He receives WONT and sighs. He responds DONT and disables the
option.
(repeat 10 and then 11, forever)

On our side:
3 We receive DONT and sigh. We respond WONT and disable the
option.
4 We receive DO but disagree. We respond WONT.
8 We receive DO and decide to agree. We respond WILL and enable
the option.
9 We decide to disable. We send WONT and disable the option.
For whatever reason, we decide to agree with future requests.
12 We receive DO and agree. We send WILL and enable the option.
13 We receive DONT and sigh. We send WONT and disable the option.
(repeat 12 and then 13, forever)

Both sides have followed RFC 854; but we end in an option
negotiation loop, as DONT DO DO and then DO DONT forever travel
through the network one way, and WONT WONT followed by WILL WONT
forever travel through the network the other way. The behavior in
steps 1 and 9 is responsible for this loop. Hence this section's
rule. In Section 6 below is discussion of whether separate states
are needed for "negotiate for disable" and "negotiate for enable"
or whether a single "negotiate" state suffices.


There's some more examples in the RFC, but the point is - there are entirely TELOPT compliant scenarios that can result in loops.

Maya/Rudha
06 Sep, 2010, KaVir wrote in the 7th comment:
Votes: 0
Rudha said:
RCVD IAC WILL TTYPE
SENT IAC DO TTYPE

Unusual - you tell the client that it can ask the server for its terminal type? I wondered if MUSHclient might be following up by sending a subnegotiation request to your server asking it to identify itself, but having tested it that doesn't seem to be the case - MUSHclient simply responds with IAC DONT TTYPE.

Your ATCP request is also WILL - that needs to be DO. However MUSHclient doesn't support ATCP natively, so unless you're using a plugin this shouldn't be a problem.

Rudha said:
But the real problem is that it gives multiple responses to a single WILL/WONT challenge which is confusing the server.

Which one?
06 Sep, 2010, Rudha wrote in the 8th comment:
Votes: 0
Its worth noting that I only have any subnegotiations implemented for two of the protocols - MSDP and MSSP. The other protocols are simply the handshake. I was monkeying with the handshakes to see if I had done them wrong but anyways - I isolated the problem but Im not sure why it's happening.

If a client doesn't support something it ends up doing this negotoiation sequence:

Server: IAC WILL <protocol>
Client: IAC DONT <protocol>
Server: IAC WONT <protocol>
Client: IAC DONT <protocol>

TT++ and TinyFugue correctly remember they've finished negotiating and remember but dont reply to the second WONT - per RFC 1143, but MushClient gets itself stuck in a loop responding and it gets sending IAC DONT <protocol> \ IAC WONT <protocol> - this confuses me since it should be avoiding this case but it obviously isnt, an example:

if (cmd == client_do_termtype):
sockinfo = get_socket_info(sock)
if (("DO TERMTYPE" in sockinfo) or ("DONT TERMTYPE" in sockinfo)):
log_string("WARNING: duplicate request outside of normal negotiation (IAC DO TERMTYPE)")
else:
add_socket_info(sock.uid, "DO TERMTYPE")

if (cmd == client_dont_termtype):
sockinfo = get_socket_info(sock)
if (("DO TERMTYPE" in sockinfo) or ("DONT TERMTYPE" in sockinfo)):
log_string("WARNING: duplicate request outside of normal negotiation (IAC DO TERMTYPE)")
else:
add_socket_info(sock.uid, "DONT TERMTYPE")


As you can see from the code, I removed sending the WONT reply to the DONT reply, which technically makes it non-compliant to the TELOPT RFC, but it solves the loop; this confirms to me the loop is because of that.

Maya/Rudha
06 Sep, 2010, KaVir wrote in the 9th comment:
Votes: 0
Rudha said:
If a client doesn't support something it ends up doing this negotoiation sequence:

Server: IAC WILL <protocol>
Client: IAC DONT <protocol>
Server: IAC WONT <protocol>
Client: IAC DONT <protocol>

You sent the request, the client sent the acknowledgment - why are you responding to the acknowledgment?

RFC854 states that "…all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood". Isn't that exactly what MUSHclient is doing?
06 Sep, 2010, Rudha wrote in the 10th comment:
Votes: 0
This is probably the part that MushClient is having issues with - and the server too, evidently:

RFC 845 said:
b. 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.


The if() conditional there .. should be preventing -any- change of mode, at this point, so why it loops out is eluding me. But the key phrase there "It is required that a response be sent to requests for a change of mode" is why I was responding. Am I misreading that?

Maya/Rudha
06 Sep, 2010, KaVir wrote in the 11th comment:
Votes: 0
As far as I understand it your interpretation is correct for supported options. However the RFC seems to suggest that you can always return a rejection for unknown options. This makes sense IMO, as you probably don't want to keep track of options you don't support.

Therefore in the case of this:

Server: IAC WILL <protocol>
Client: IAC DONT <protocol>
Server: IAC WONT <protocol>
Client: IAC DONT <protocol>

The server sends a request for the protocol, the client sends a rejection, and that should be the end of it. The server should recognise that it was a response to its request, and that there was no change to the option mode, and simply keep quiet. It shouldn't send a WONT unless it is already in the appropriate mode and wishes to change.

Which protocol was this, out of interest?
06 Sep, 2010, Rudha wrote in the 12th comment:
Votes: 0
That it seemed to choke on the negotiation for? I hadnt thought to isolate it but the ones it responded to in such a way were the two I thought it prudent to inform the client not to expect to be sent anymore when a a DONT message is sent: MSP and MSDP; in retrospect ATCP would be prudent as well since it sends out of band data; but perhaps its just as well I didnt do that since it seems to be erroneous.

Rudha/Maya
06 Sep, 2010, Rudha wrote in the 13th comment:
Votes: 0
To clarify, I see these protocols as the server saying it will send this data; the client vasically saying "go ahead" and it doing so, or saying "dont send that data" and the server replying with WONT to say that it will not send the data; i suppose the problematic thing is, as you mentioned, it's respondingto the unknown protocol always with DONT. This seems a little counterintuitive though - one should think it will understand that WONT and the protocol mrans the server wont send data in relation to that protocol.

Maya/Rudha
06 Sep, 2010, KaVir wrote in the 14th comment:
Votes: 0
Rudha said:
To clarify, I see these protocols as the server saying it will send this data;

Sure, but not until the request has been acknowledged. As stated in the RFC, "a. 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."

There is no mode change until you receive the DO/WILL acknowledgement.
06 Sep, 2010, Rudha wrote in the 15th comment:
Votes: 0
Right; and after the initial WILL/WONT that server receives, it should "remember" that, and currently, discard state changes, but it doesn't, and since neither the client nor the server is being sane in its response it loops out.

I'll have to figure out why the state engine isn't "remembering the state". I just keep it in what I think of as an array but I'm sure Python has another name for, that goes "socket UID", "list of protocol messages received"; ie 2, "DONT MSSP, DO ATCP", etc; the conditional right now should be detecting that it has DO or DONT already received for that socket and if it does, discarding the state change.

Hrm. I'll poke through it and see why its not seeming to remember that; if its looping out its definetely getting DONT at least once!

Maya/Rudha
06 Sep, 2010, KaVir wrote in the 16th comment:
Votes: 0
Rudha said:
Right; and after the initial WILL/WONT that server receives, it should "remember" that, and currently, discard state changes, but it doesn't, and since neither the client nor the server is being sane in its response it loops out.

Well let's say MSDP is off, and you want to ask the client if you can switch it on. So you send "IAC WILL MSDP", but the client doesn't recognise that protocol so it responds with "IAC DONT MSDP". You receive the "IAC DONT MSDP", but because MSDP is already off, you don't respond.

If MUSHclient always responds to unknown options with DONT/WONT, as suggested in RFC854, then this shouldn't be a problem as long as negotiation is properly implemented at the server end.
07 Sep, 2010, Rudha wrote in the 17th comment:
Votes: 0
I suppose what Im saying is: If it's responded that it doesn't want to use, or support, the protocol, it really shouldn't respond again. (A corollary is if a server says it wont do a protocol you dont support, you probably dont need to respond at all)

At the same time my state engine is also at fault if it's not "remembering" things, but Im at a loss as to why it's not.

Maya/Rudha
07 Sep, 2010, KaVir wrote in the 18th comment:
Votes: 0
Rudha said:
I suppose what Im saying is: If it's responded that it doesn't want to use, or support, the protocol, it really shouldn't respond again. (A corollary is if a server says it wont do a protocol you dont support, you probably dont need to respond at all)

Except, as I mentioned earlier, RFC854 states that "…all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood".

MUSHclient doesn't support MSDP (without a plugin), therefore it doesn't need to be aware of it. Your optional request isn't understood, therefore it will always reject it with DONT.

I can see why some clients might wish to keep track of unknown protocols as well, but as far as I understand it, they're not required to do so. MUSHclient's behaviour appears to be correct.

Not responding at all would break the RFC though. There are some clients that do this - for example GMud will simply display every printable character and ignore the rest, so if you send it IAC WILL MSDP it'll display the character 'E' to the user, while IAC WILL MSSP will display the character 'F', and so on. This is obviously very broken, but I have players using it, so I have to deal with it.
08 Sep, 2010, hollis wrote in the 19th comment:
Votes: 0
Rudha said:
I've taken the liberty of collecting the various NM code snippets I'm aware of, from the mailing list/yahoo group/etc and uploading them here to help promote NakedMud and give NM devs a little more easily accessible point to get it from than the yahoo group (which requires a yahoo login)


You should come join us on the IRC channel. We're actually talking about doing this at www.nakedmud.org . In fact, I think there's already some stuff up here.
08 Sep, 2010, Rudha wrote in the 20th comment:
Votes: 0
I thought nakedmud.org had bitten the dust; i had disapeared for a bit. I may drop in but no gaurantees; Im usually posting here on the go as is.

Maya/Rudha
0.0/20