Mudlet 3.0.0-delta (preview #4)

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman »

Hi,

As I mentioned before, I did try doing the WILL/DO TTYPE handshake before sending the TTYPE sub-negotiation, but that also had no effect on Mudlet 3.0.0delta. The client never responded. And why would the server need to send " IAC SB TTYPE SEND IAC SE" multiple times? Is the client hard of hearing? :)

In the end, since no other mud client requires WILL/DO handshaking in order to respond to the TTYPE sub-negotiation, and since there is no "will/shall" directive about it in the relevant RFC, and since requiring the handshake for one client adds extra connection time for all clients, and since some clients respond DONT to the handshaking and yet still responds to the sub-negotiation (windows telnet!), I won't keep a requirement for the handshake in there.

What I will do is wait for the MXP bug fix. I have done my civic duty and reported the bug. Hopefully the dev who works on such things will hear the plea of his or her users.

- Bo

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

Well, as I seem to be the sole active coder at present (I hope I am wrong *looks around for Vadi or Chris to contradict him* ;) ) and I am not strong in my knowledge of that area of the application I need to get up to speed on it.

My understanding is that according to Telnet protocol rules the Server must assume that the Client is in a WONT state for ALL sub-options on connection start up and must activate/negotiate each one that it wants to use. Some of those can be enable/disabled by the user for a particular profile with various setting (GMCP, MCCP and MXP come to mind on that score) but nothing should be activated until the Server and the Client (in our case the Mudlet application) have both agreed to use them with a DO/WILL or WILL/DO as per RFC854:
In RFC854 it was wrote:...In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgements; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON'T and WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, 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.
and THEN "Sub-negotiation" about the particular option must be undertaken IF that particular option is known about by BOTH parties AND the option has additional details, e.g. parameters, etc. that NEED to be exchanged between them.

As per RFC855 this means that for an option that one party does not understand (acknowledged with a WONT/DONT as appropriate), it can safely ignore anything that the other sends in an attempt to Sub-negotiate that option (by sending a sequence beginning with "IAC SB <option number>...") by just looking for the terminating "... IAC SE" and forgetting anything in between. Now, if Mudlet is not playing by those rules, it would seem to be a bug (and, sadly, those are not unheard of in it :oops: ) and someone (I guess I'm drawing the only straw at the moment so I can't tell if it is the short one) will need to take a look at it...

Option 24 Terminal Type is one that is supposed to be negotiated as the client sends successively more generic responses as per RCF930 and the server is supposed to record all of them until it gets two identical ones in succession which indicated the end of the list. This was extended in RCF1091 in that for clients that can change their terminal characteristics upon request they must adopt those characteristics AT THE POINT where they return the relevant terminal type. The server, having got to the point where a response is repeated, may then send one or more TTYPE sub-negotiations which causes clients that support the later RFC to wrap around the list and return to the first(probably most detail/functional) TTYPE mode and proceed to step through them again until the Server stops on the one it wants to use. Clients that do not support RCF1091 (including Mudlet at present) will just ignore this and repeatedly return the most generic (or only TTYPE) they report.

Mudlet does only return a single string as it is currently coded but that will change in the future as it is something I have had on my to-do list for some time. That was since I found all the places where Mudlet presents a version string and changed all the hard-coded string literals to be a compile time constant set in just one (actually two - but only one is used at a time) places. :geek:

The reason for reporting the version in the TTYPE is to help the MUD Server coder to know exactly what type of (Mudlet?) client they are talking to and (we hope) to help them accommodate any issues that older versions might have or use new shiny features that have been lovingly bolted on. If this is not working for a Server then we (the Mudlet "Makers") do want to know about it and I would like to thing we could work with the Server coders to try and resolves things - so please don't think I'm trying to be dismissive - I just want to know where the problem lies and to fix things if the problem is with the Mudlet part of the system; sadly, just because another client does something one way, it may not be the "correct" way but it might indicate that something is not as clearly defined as one might hope... :?

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman »

Dude, I just noticed that mudlet is on git and is open source. I'm an idiot for not knowing this.

By perusing the code, I've already come up with the server-side fix for the MXP problem: Tell the client to go into MXP Locked mode. This is basically what the client should do anyway as soon as Mudlet sends DONT MXP to the server. I see in the code that it raises an event when DONT MXP replies are sent to WONT MXP from the server. If it has access to the TBuffer object at that place in the code, then it should also set TBuffer.mMXP = false at that time, to reset it from the MXP-Secure state it was in.

For the TTYPE, that one is still puzzling me. I see that you actually do require the WILL/DO handshake before it will respond to the subnegotiation (that's actually unusual for a client, despite what the RFC says), but I still can't seem to get the message no matter what I try. For what it's worth, when I turn on GMCP in the client, I can get the version info through the Core.Hello :)

- Bo

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

Dude, I just noticed that mudlet is on git and is open source. I'm an idiot for not knowing this.
I am not going to comment! ;)
By perusing the code, I've already come up with the server-side fix for the MXP problem: Tell the client to go into MXP Locked mode. This is basically what the client should do anyway as soon as Mudlet sends DONT MXP to the server. I see in the code that it raises an event when DONT MXP replies are sent to WONT MXP from the server. If it has access to the TBuffer object at that place in the code, then it should also set TBuffer.mMXP = false at that time, to reset it from the MXP-Secure state it was in.
I'm not that familiar with MXP (other than that the specification is a little unclear ;) ) - Mudlet should not be assuming it is actually active at the commencement of a session - but IIRC it does have a user control that (should) say "use it if the server offers it". When you say "to reset it from the MXP-Secure state it was in" I am not clear what that means - does it mean MXP "is off now and to stay off"? Also IIRC there are MXP commands to permanently, (rather than line-by-line as MXP normally operates) - but I thing we are broken in implementing that - which are the "lock" commands, see: bug 1380455.

As for the current handling of TTYPE sub-negotiation I will make it the next thing I look at when I finish the current (major) task I'm on - so can you give me a week or two...? {Are you a (or, rather the) CoffeeMUD server developer - Bo Zimmerman? You might want to add the website to your profile page here! :D} I'll try and login to coffeemud.net:23 and see what gives. (Hell I can PM you with a specific version name that a test Mudlet version will try and you can place anyone using it into a safely padded room away from harm/other players... :lol:)

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman »

So, MXP has a telnet handshake to turn it on and off. After it is turned on, MXP has another special negotiation to set its Mode (Open, Secure, or Locked). CoffeeMud turns MXP on immediately after connection (if the client allows) in order to show fancy pictures and stuff. Then later, after login, CoffeeMud will turn MXP off again if the user has said they do not want to use it in their player profile.
So, the following happens:

1. Server: WILL MXP
2. Client: DO MXP
3. Server: MXP mode: Secure
4. .... user logs in ... and user has MXP turned OFF in their profile
5. Server: WONT MXP
6. Client: DONT MXP

Since the Mudlet code ONLY checks the MXP Mode boolean flag to determine whether to parse MXP tags, my fix was to add a new server step 4.5: Server: MXP Mode Locked. That way, I am asking the client to turn off MXP parsing both at the Mode level, and then, at the TELNET level.

My suggestion for improvement was to have Mudlet also go BACK to a Locked Mode automatically whenever MXP is disabled with WONT/DONT, making my 4.5 step unnecessary. In the Mudlet cpp code, the MXP Mode Flag is in TBuffer.h and called mMXP.

It's kinda complex.. I hope that's clearer? You are correct that the MXP Locked Mode is called "permanent", but it's only "Permanent" until it is explicitly turned off. One way to turn it off is to do as I did in step 4.5 and request a new mode. Another way to turn it off SHOULD be to disable MXP altogether with WONT/DONT. This last is what's broken.

Thanks for your help with all this. I will adjust my profile as you requested.

- Bo

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

Sorry that I have not got back to you on this before now - I am up to my eyeballs at the moment - but looking at your last post and as where I am currently poking around in the code-base at the moment (near to the Telnet sub-option processing) is on this topic I would point out that your suggestion to do:

1. Server: WILL MXP
2. Client: DO MXP
3. Server: MXP mode: Secure
4. .... user logs in ... and user has MXP turned OFF in their profile
5. Server: WONT MXP
6. Client: DONT MXP

may be problematic - if the Client responds at step 2 with: DONT MXP how are you going to proceed? The reason I ask is because, If the user has set Mudlet to forcibly disable MXP it is (or should be) respected before it gets to attempt to connect to the Server - so it will (or should) respond like that at that point.

Any attempt to send MXP data after that point would (or should) be ignored as MXP data and will likely end up as on-screen garbage as a client that does not have the capability to handle MXP would - indeed by returning DONT MXP Mudlet is telling the server that it won't/can't handle it (as it has the right to do so)! :geek:

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman »

Hi!
You are correct, if, in Step 2, the Client responds with DONT MXP, then not only is MXP turned off on the server side, but it is also ignored in the user profile when they log in. If the Client says DONT MXP, it is respected.

Post Reply