Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ MXP and Pueblo
➜ MXP Telnet negotiation
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Fwongo
(9 posts) Bio
|
| Date
| Wed 27 Jun 2001 06:33 PM (UTC) |
| Message
| | I've been told by the developer of a MOO display utilities package (I'm assisting him with this project) - and apparently, MUSHclient responds to IAC DO MXP with IAC WONT MXP, no matter what the MXP preferences are set to. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Thu 28 Jun 2001 01:46 AM (UTC) Amended on Thu 28 Jun 2001 01:47 AM (UTC) by Nick Gammon
|
| Message
| The MXP telnet negotiation is described in great detail in this post Telnet negotiation
This conforms to the standard described in RFC 854 and RFC 855, partly reproduced below:
Thus, for option "ABC", which requires subnegotiation,
the formats of the TELNET commands are:
IAC WILL ABC
Offer to use option ABC (or favorable acknowledgment
of other party's request)
IAC DO ABC
Request for other party to use option ABC
(or favorable acknowledgment of other party's offer)
IAC SB ABC <parameters> IAC SE
One step of subnegotiation, used by either party.
Therefore the MUD is incorrectly sending IAC DO MXP, it should send IAC WILL MXP. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fwongo
(9 posts) Bio
|
| Date
| Reply #2 on Thu 28 Jun 2001 03:24 PM (UTC) |
| Message
| So, the guy who I'm helping says:
----
ByteNik says, "Uhm, no."
ByteNik says, "Tell him is way is wrong, and to read the RFC. tell him to come on here if he needs help."
ByteNik says, "zMud won't respond to his way, even. :P"
ByteNik says, "cya"
---
Now if zMud doesn't respond to your way correctly, and zMud is the main implementation, d'you think you should at least support that way? | | Top |
|
| Posted by
| ByteNik
(3 posts) Bio
|
| Date
| Reply #3 on Thu 28 Jun 2001 03:42 PM (UTC) |
| Message
| Since my friend here finds it necessary to quote me exactly instead of writing a message, since the message sounded at least a bit rude, I'll try to explain what I'm seeing.
When I send <IAC><DO><MXP> to zMud, it replies <IAC><WILL><MXP>. When I send <IAC><WILL><MXP> to zMud, it replies with <IAC><DO><MXP>. MUSHclient supports only sending the request the second way. From my understanding of the RFC, the first way is proper and the second way is implemented only for systems who support it incorrectly. If not, I just corrected the author of SimpleMU incorrectly, so the next version is going to have a nice big bug in it. =P
Note the following from RFC854:
WILL (option code) 251:
Indicates the desire to begin performing, or confirmation that you are now 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.
The two sequences seem to be very similar. However, <DO> states that you are requesting the -other- party to begin the indicated option. Since I am the server, I'd be expecting the -client- to do the option MXP. <WILL> states that -you- are either performing or want to perform the indicated option, which coming from the server would mean that the server wishes to start MXPing. Since the option is to determine if the client -supports- MXP, its the client that performs the action and the server that requests it, which seems to indicate that it should send <IAC><DO><MXP> to the client. This seems even more so in MUSHclient, where the client has to perform the action of enabling MXP in it. The server isn't performing any action.
--ByteNik | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Thu 28 Jun 2001 09:23 PM (UTC) Amended on Thu 28 Jun 2001 09:25 PM (UTC) by Nick Gammon
|
| Message
| OK, I'll tell you where I am coming from with this. The MXP spec does not specifically say which exact protocol it uses, however the document lists MXP right next to MCCP (near the end) where it says "You can also use the Telnet option to determine if the client supports the MUD Sound Protocol (MXP) or the MUD Compression Protocol (MCP). "
It seems reasonable that in the absence of an explicit direction in the MXP spec that the protocol would be the same as for MCCP, since they are mentioned in the same sentence. The protocol for MCCP is very specific, and is at: The Mud Client Compression Protocol.
Here the author makes it very clear that the *server* sends IAC WILL COMPRESS and the *client* replies IAC DO COMPRESS. Therefore I implemented it the same way for MXP.
I don't want to get into a big argument about which is right, and I can see your point - maybe MCCP is backwards? In the next release of MUSHclient I will accept either way, I trust that will resolve the issue.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Thu 28 Jun 2001 10:34 PM (UTC) |
| Message
| I would like to also suggest that you amend your server to send the additional sequence to actually start using MXP (same as is done for MCCP).
Otherwise (as currently happens in zMUD) the *query* about whether you support MXP actually turns it on, which is not really desirable. I think that the query about the capability to support, and the request to commence using that feature, should be two separate sequences.
This sequence is:
Server is ready to start sending MXP
(Sent from server to client)
<IAC><SB><MXP><IAC><SE>
which in hex is: 0xFF 0xFA 0x5B 0xFF 0xF0
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Bob
USA (1 post) Bio
|
| Date
| Reply #6 on Tue 13 Aug 2002 10:38 PM (UTC) |
| Message
| Hi,
I'm working on integrating MXP support into LPMud.... What is needed to get MushClient to work with the On Command option of Use Mxp?
Thanks
Bob | | Top |
|
| Posted by
| Kalahn
United Kingdom (138 posts) Bio
|
| Date
| Reply #7 on Tue 13 Aug 2002 11:30 PM (UTC) |
| Message
|
#define IAC_SB (char)IAC, (char)SB
#define SE_NUL (char)SE, '\0'
#define IAC_SE_NUL (char)IAC, SE_NUL
#define WILL_SE_NUL (char)WILL, SE_NUL
#define TELOPT_MXP 91
const char mxp_advertise_buf[]= { IAC, WILL, TELOPT_MXP, '\0'};
const char mxp_start_buf[]= { IAC_SB, TELOPT_MXP, IAC_SE_NUL};
send mxp_advertise_buf[] to the connection
if you receive IAC DO MXP from the connection after this then
send mxp_start_buf[] to the connection
- Kalahn
Developer of the Dawn of Time Codebase
http://www.dawnoftime.org/ |
Kalahn
Developer of the Dawn of Time codebase
http://www.dawnoftime.org/ | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
36,839 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top