Protocol Negotiation Issues

that got it... its working exactly like it was before the changes to the code back at the start of this thread.. thanks for looking into it.. i was wondering if it was my mud that was at fault..

Now on input I'm seeing:

IAC WILL 201
IAC WILL 91
IAC WILL TTYPE
IAC SB TTYPE IS mudportal.com IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS XTERM-256color IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS MTTS 141 IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS 69.181.111.151 IAC SE
IAC WILL TTYPE
IAC SB TTYPE IS 69.181.111.151 IAC SE
IAC DO 86

Im still not seeing NAWS or ECHO or SGA negotiation. Should I be?

LO only asks for a TTYPE with a SEND when it gets a WILL TTYPE, and it won't ask for more than one ttype, so I suspect you are sending the WILL TTYPE's gratuitously after sending a TTYPE value instead of waiting for the next request from the server. Is that what is going on? My game can certainly deal with that, but for compatibility, RFC 1091 section 5 says that "Terminal type information may not be sent spontaneously, but only in response to a request."

In Mud Terminal Type Standard , the section on proxies suggests sending the IP address as a NEW-ENVIRON variable named IPADDRESS, rather than appending it as another ttype value. I think that recommendation is a lot easier to parse on the server, and its already how I've implemented address reporting for the LO proxy. Would be cool if mudportal did it that way.

I'm totally going to implement full mtts on the LO server if the mudportal client is using it. Very cool, plamzi.

Sorry man, I should have been more clear. What I meant in my previous post was: "I do not see the client explicitly refusing the server's offer to ECHO and SGA. Did you intend to have the client ignore the offer, or did you intend to refuse it with a DONT? Either way is correct- but I'm not seeing an explicit DONT"

When a server sends WILL ECHO and WILL SGA to a client, the is server trying to tell the client that it can support char-at-a-time mode-- like the mode what happens with a typical telnet or ssh cli shell session. In that mode, user types a character, and the client sends it immediately to the server without displaying it to the user. The server receives the character and decides whether to send it back to the client for display to the user. The server gets every keystroke and completely controls what is displayed back to the user.

Like a lot of (most?) mud servers, the mudportal client operates in a line-at-a-time mode. User enters a line of text, the client takes care of the line editing and character printing, and a complete line is sent up to the server only when the user hits enter. The server isn't supposed to echo the line back to the client for printing, because the client has already taken care of it.

My understanding is that when a server offers to provide ECHO and SGA by sending a WILL for those options, a client like mudportal that wants to stay in line-at-a-time mode has two options- either don't respond at all to either offer because line-at-a-time is supposed to be the default behavior, or respond with a DONT to explicitly refuse the offers.

Having the client respond with a DO ECHO isn't right, because the client has already shown the input line to the user. The server shouldn't try to do it too.


Setting the IPADDRESS variable via NEW-ENVIRON looks like it is working great on my end!

Thanks for the explanation on the TTYPE behavior. I understand now why you are doing it that way, and I'll fix my server side code to be more tolerant.

On NAWS- Its not useless. Muds that support the option use it to determine how many lines to display before sending the "hit return to continue" message in a pager, and some muds use it to decide when to wrap text. For example, LO uses it to decide how big of an ascii graphic map it can send to the user when they ask for one. LO and stock dikumuds default to an 80x24 size when there's no negotiation, so its not a big deal if the client doesn't support NAWS- but it means that paged text has a 'hit return' prompt after every 22 lines. Even if you don't ever want to support vt100 cursor positioning commands, it'd be a nice option to include in the client.

Ok, option negotiation looks good to me. Sweet!

On the NAWS subject- I get what you are trying to do. I'm just saying that as nothing more than a concession to compatibility, It might be a useful thing to negotiate the window size to get the server side pager prompts and line wrapping to happen more reasonably. At least it would be there as a fallback until game devs can utilize the cooler browser functionality.

As a server developer I don't think NAWS is useless, but if its low on the priority list for the client code, so be it.

Hate to say this Plamzi.. but what ever you have done to the mud portal app recently has made background colors no longer show on my mud... nor protocols getting negotiated properly (my mud MAY be down sporadicly... we have some issues we are working though)

I will just say that before the changes you made mudportal app was working fine... apart from being sent random characters when it was negotiating the protocols on connection.

ok then... i take that back.. sorry.. lol... you mustve been mid change when i checked!!

Looks like my TTYPE is showing the IP address since it repeats itself twice. We switched over to use Kavir's protocol snippet, so I can only assume that everyone using it will be seeing the same thing? Looks like everything else is showing up correctly. Any ideas or should we simple capture the first TTYPE given which is actually against the RFC protocol as its supposed to repeat itself?


I am attaching a screenshot of my display.

I was looking over the connection data for one of my players who uses the client here and see something strange with the MTTS PROXY IPADDRESS reporting.

Plamzi, instead of setting the environment variable named {IPADDRESS} to {1.2.3.4}, the client is setting variable { "IPADDRESS" } to { "1.2.3.4" }. Both the variable name and its value are being sent with a surrounding double quote and space. I don't think its supposed to be that way. The quotes and spaces aren't supposed to be sent by the client, are they?

You should lose the spaces too. It was sending the 13 byte variable name {_"IPADDRESS"_}. After you removed the quotes it sends the 11 bytes {_IPADDRESS_}. It should send the nine byte name {IPADDRESS}. I've replaced spaces with _'s to make them stand out.

I agree with you on the RFC. Might have been clear as a bell in 1983, but today it's just confusing.

Beauty. Lookin' great.

Terminal: mudportal.com (80 x 25) (noecho/nosga)
Full TTYPE: mudportal.com, XTERM-256color, MTTS 141, 69.xxx.xxx.151
MTTS Decode: ANSI, UTF-8, 256 COLORS, PROXY
IPADDRESS = 69.xxx.xxx.151