06 Jan, 2013, Telgar wrote in the 41st comment:
Votes: 0
Scandum said:
Telgar said:
Jumping into this fun thread. Having just implemented MTTS support, I now believe it isn't really a great idea to send the MTTS options last. This requires looping through all terminal types by the server, then in addition, it requires looping back through the types again to select the terminal type actually requested by the server. You may have to loop back through the types again for terminals which get progressively dumber at each terminal type switch. This could be fixed by sending the MTTS settings first; no sane terminal program will accept them (and it should pose no parsing problem for proper clients, it is legal for terminal types to contains spaces, as the ttype is closed by the IAC SE command).

I think the only client that uses TTYPE to select the terminal types is Windows Telnet. One of its modes is somewhat screwy, and I'm not exactly sure how many requests you need to send to select this mode.

So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

What I did for my server is to send 3 TTYPE requests at once. I store the first response as the client name, and the routine keeps an eye out for an MTTS response.

It's not an option to send MTTS first as many server will only request TTYPE once and expect the client name.


Well first off, I don't care about having fancy-dancy VT100 support for Windows Telnet users. I hear the client is broken with respect to SGA and echo. Bah, shucks. So Immos can't login over raw telnet sessions from Windows boxes and have access to OLC. That's actually a good thing. Immos should be logging in over ssh.

However, I have every intention of respecting the telnet standard. And no, Windows is not the only client that does terminal type negotiation. One of my Linux boxes send XTERM-COLOR and alternately, NXTERM. I've no idea what mode NXTERM corresponds to, so I do the proper thing and reset the terminal type back to XTERM-COLOR. And lo and behold, the client actually supports this properly.

[ :j: Input: 255 ]
[ :j: Input: 251 ]
[ :j: Input: 0 ]
[ :j: Input: 255 ]
[ :j: Input: 251 ]
[ :j: Input: 24 ]
[ :j: Handling command: 251 ]
[ :j: BINARY ]
[ :j: Handling command: 251 ]
[ :j: TTYPE ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 24 ]
[ :j: Input: 0 ]
[ :j: Input: 88 ]
[ :j: Input: 84 ]
[ :j: Input: 69 ]
[ :j: Input: 82 ]
[ :j: Input: 77 ]
[ :j: Input: 45 ]
[ :j: Input: 67 ]
[ :j: Input: 79 ]
[ :j: Input: 76 ]
[ :j: Input: 79 ]
[ :j: Input: 82 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Handling command: 250 ]
[ :j: SB command: 14 bytes ]
[ :j: TTYPE: XTERM-COLOR ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 24 ]
[ :j: Input: 0 ]
[ :j: Input: 78 ]
[ :j: Input: 88 ]
[ :j: Input: 84 ]
[ :j: Input: 69 ]
[ :j: Input: 82 ]
[ :j: Input: 77 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Handling command: 250 ]
[ :j: SB command: 9 bytes ]
[ :j: TTYPE: NXTERM ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 24 ]
[ :j: Input: 0 ]
[ :j: Input: 78 ]
[ :j: Input: 88 ]
[ :j: Input: 84 ]
[ :j: Input: 69 ]
[ :j: Input: 82 ]
[ :j: Input: 77 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Handling command: 250 ]
[ :j: SB command: 9 bytes ]
[ :j: TTYPE: NXTERM ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 24 ]
[ :j: Input: 0 ]
[ :j: Input: 88 ]
[ :j: Input: 84 ]
[ :j: Input: 69 ]
[ :j: Input: 82 ]
[ :j: Input: 77 ]
[ :j: Input: 45 ]
[ :j: Input: 67 ]
[ :j: Input: 79 ]
[ :j: Input: 76 ]
[ :j: Input: 79 ]
[ :j: Input: 82 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Handling command: 250 ]
[ :j: SB command: 14 bytes ]
[ :j: SETTTYPE: XTERM-COLOR ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 251 ]
[ :j: Input: 31 ]
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 31 ]
[ :j: Input: 0 ]
[ :j: Input: 81 ]
[ :j: Input: 0 ]
[ :j: Input: 58 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Input: 255 ]
[ :j: Input: 251 ]
[ :j: Input: 39 ]
[ :j: Handling command: 251 ]
[ :j: NAWS ]
[ :j: Handling command: 250 ]
[ :j: SB command: 6 bytes ]
[ :j: Handling command: 251 ]
[ :j: ENVIRON ]
[ :j: Awaiting user variables ]

[]>
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 39 ]
[ :j: Input: 0 ]
[ :j: Input: 0 ]
[ :j: Input: 85 ]
[ :j: Input: 83 ]
[ :j: Input: 69 ]
[ :j: Input: 82 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Input: 255 ]
[ :j: Input: 250 ]
[ :j: Input: 39 ]
[ :j: Input: 0 ]
[ :j: Input: 3 ]
[ :j: Input: 73 ]
[ :j: Input: 80 ]
[ :j: Input: 65 ]
[ :j: Input: 68 ]
[ :j: Input: 68 ]
[ :j: Input: 82 ]
[ :j: Input: 69 ]
[ :j: Input: 83 ]
[ :j: Input: 83 ]
[ :j: Input: 255 ]
[ :j: Input: 240 ]
[ :j: Handling command: 250 ]
[ :j: SB command: 8 bytes ]
[ :j: GOT ENVIRON STRING ]
[ :j: Handling command: 250 ]
[ :j: SB command: 13 bytes ]
[ :j: GOT ENVIRON STRING ]
[ :j: Finished negotiation ]


If that lagged 99% of my users, then they are totally going to be pissed by the follow up, where they get asked two questions, one to determine if ANSI color works (even if "supported" by the client, this could be forwarded to a monochrome display), and the second to see if Unicode text works (as the channel may not be 8-bit clean, fonts may not be installed, etc..).

Also, if you note carefully, by where the input is chunked, I've piggy-backed the negotiations such that BINARY and TTYPE options are sent together, and the NAWS and NEW ENVIRON negotiation are also sent together. So doing a full, protocol proper exchange is:

Server -> Client IAC DO BINARY, IAC DO TTYPE
Client -> Server IAC WILL/WONT BINARY, IAC WILL TTYPE
Server -> Client IAC SB TTYPE SEND IAC SE
Client -> Server IAC SB TTYPE IS XTERM-COLOR IAC SE
Server -> Client IAC SB TTYPE SEND IAC SE
Client -> Server IAC SB TTYPE IS NXTERM-ZOMG-WTF-IS-THIS IAC SE
Server -> Client IAC SB TTYPE SEND IAC SE
Client -> Server IAC SB TTYPE IS NXTERM-ZOMG-WTF-IS-THIS IAC SE

And I don't like that ttype so I keep negotiating
Server -> Client IAC SB TTYPE SEND IAC SE
Client -> Server IAC SB TTYPE IS XTERM-COLOR IAC SE

This is the only safe way to conclude the terminal is back in a known mode.

After that, I can finish:

Server -> Client IAC DO NAWS, IAC DO NEW ENVIRON
Client -> Server IAC WILL NAWS, IAC SB NAWS (window size) IAC SE, IAC WILL NEW ENVIRON

Server -> Client IAC SB NEW ENVIRON SEND VAR USER VAR IPADDRESS IAC SE

Course the client cheats the server out of getting environ information, and sends back null strings, but can't do much about that. Some clients even report the user name correctly, making this a second identity check.

All in all, proper use of the telnet protocol is pretty useful.
06 Jan, 2013, Telgar wrote in the 42nd comment:
Votes: 0
KaVir said:
Scandum said:
So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation, but if you can't be bothered to do that there's also the workaround I used in my protocol snippet: if the first terminal type is "ANSI", don't cycle.

Scandum said:
It's not an option to send MTTS first as many server will only request TTYPE once and expect the client name.

Exactly, I'd estimate that only around 10-15% of those that detect TTYPE actually cycle through them.

But you need to cycle anyway if you want to detect xterm-256-color. While you can also get that information from MTTS, I think only TinTin++ supports it - if someone is using BlowTorch, for example, you need to check the second TTYPE for a "256-color" postfix.


Ugh. So broken clients have inspired broken servers to be lax and now proper servers have to work around broken server behavior designed to work with broken clients.

I actually detect xterm-256-color as a preferred terminal type and renegotiate to that, if possible.

I'll have to look further into this windows telnet / linemode bug at some point in time when I have a Windows VM to play with, thanks for the tips on detection.
06 Jan, 2013, Telgar wrote in the 43rd comment:
Votes: 0
quixadhal said:
\EOA is the usual sequence for up-arrow when the keypad is in "application mode", if I remember right.
http://www.braun-home.net/michael/info/m...

Because vt100 compatible terminals have that concept of a "normal" and "application" mode, you either have to set the terminal to the mode you want to use, or find the termcap/terminfo sequences for both modes. Curses does this for you, but.. you can't always use curses :(


Cool, thanks, I will read up on that. I've half a mind to re-implement curses in Javascript. Properly.

BTW, the root cause of being unable to do user multiplexing with curses turns out to be rather silly. Terminfo capabilities have this nifty little feature:

A delay in milliseconds may appear anywhere in a string capability,
enclosed in $<..> brackets, as in el=\EK$<5>, and padding characters
are supplied by tputs to provide this delay.

Hence, tputs and other functions need to be able to sleep the main thread… so because of a feature we don't care about anymore, the library is written to assume a single screen paradigm. Talk about driving with blinders on!
06 Jan, 2013, Scandum wrote in the 44th comment:
Votes: 0
quixadhal said:
Enabling local echo lags 99% of your players???

Are you running your mud on a Commodore 64? Or is your connection TCP/IP over carrier pigeon?

I was referring to KaVir's implementation that makes the user wait 2 or 3 seconds trying to detect Windows Telnet using VT100 before starting telnet negotiations.
06 Jan, 2013, KaVir wrote in the 45th comment:
Votes: 0
Telgar said:
Well first off, I don't care about having fancy-dancy VT100 support for Windows Telnet users.

While Windows Telnet has its problems, it actually offers pretty good ANSI/VT100 terminal s... - far better than most mud clients. Of course the whole concept is seriously outdated, I doubt you'd see many modern muds bothering with it when it's so easy to have proper graphics.

Telgar said:
If that lagged 99% of my users, then they are totally going to be pissed by the follow up, where they get asked two questions, one to determine if ANSI color works (even if "supported" by the client, this could be forwarded to a monochrome display), and the second to see if Unicode text works (as the channel may not be 8-bit clean, fonts may not be installed, etc..).

You can assume they support ANSI colour, I don't think I've seen a client since the 90s that didn't (and that was some dodgy emulator). You can detect Unicode support using CHARSET.

Telgar said:
I actually detect xterm-256-color as a preferred terminal type and renegotiate to that, if possible.

If you're already using a cyclic TTYPE to detect xterm-256-color, what would be the advantage in putting MTTS first?

You should also be aware that the above solution won't detect 256 colour support in most mud clients. You'll have to use a variety of different approaches.

Scandum said:
I was referring to KaVir's implementation that makes the user wait 2 or 3 seconds trying to detect Windows Telnet using VT100 before starting telnet negotiations.

The user doesn't have to wait to log on, they just have to wait for negotiation to start (the login screen doesn't appear until afterwards, but there's nothing stopping them from logging on immediately if they wish).
06 Jan, 2013, Telgar wrote in the 46th comment:
Votes: 0
/////////////////////////////////////////////////////////////
// VT100 TERMINFO
/////////////////////////////////////////////////////////////

var VT100 = (function() {

var impl = {};

Object.defineConstant(impl, "key_backspace","\x08");
Object.defineConstant(impl, "key_down", "\x1BOB");
Object.defineConstant(impl, "key_enter", "\x1BOM");
Object.defineConstant(impl, "key_f0", "\x1BOy");
Object.defineConstant(impl, "key_f1", "\x1BOP");
Object.defineConstant(impl, "key_f10", "\x1BOx");
Object.defineConstant(impl, "key_f2", "\x1BOQ");
Object.defineConstant(impl, "key_f3", "\x1BOR");
Object.defineConstant(impl, "key_f4", "\x1BOS");
Object.defineConstant(impl, "key_f5", "\x1BOt");
Object.defineConstant(impl, "key_f6", "\x1BOu");
Object.defineConstant(impl, "key_f7", "\x1BOv");
Object.defineConstant(impl, "key_f8", "\x1BOl");
Object.defineConstant(impl, "key_f9", "\x1BOw");
Object.defineConstant(impl, "key_left", "\x1BOD");
Object.defineConstant(impl, "key_right", "\x1BOC");
Object.defineConstant(impl, "key_up", "\x1BOA");
Object.defineConstant(impl, "keypad_local", "\x1B
/////////////////////////////////////////////////////////////
// VT100 TERMINFO
/////////////////////////////////////////////////////////////

var VT100 = (function() {

var impl = {};

Object.defineConstant(impl, "key_backspace","\x08");
Object.defineConstant(impl, "key_down", "\x1BOB");
Object.defineConstant(impl, "key_enter", "\x1BOM");
Object.defineConstant(impl, "key_f0", "\x1BOy");
Object.defineConstant(impl, "key_f1", "\x1BOP");
Object.defineConstant(impl, "key_f10", "\x1BOx");
Object.defineConstant(impl, "key_f2", "\x1BOQ");
Object.defineConstant(impl, "key_f3", "\x1BOR");
Object.defineConstant(impl, "key_f4", "\x1BOS");
Object.defineConstant(impl, "key_f5", "\x1BOt");
Object.defineConstant(impl, "key_f6", "\x1BOu");
Object.defineConstant(impl, "key_f7", "\x1BOv");
Object.defineConstant(impl, "key_f8", "\x1BOl");
Object.defineConstant(impl, "key_f9", "\x1BOw");
Object.defineConstant(impl, "key_left", "\x1BOD");
Object.defineConstant(impl, "key_right", "\x1BOC");
Object.defineConstant(impl, "key_up", "\x1BOA");
Object.defineConstant(impl, "keypad_local", "\x1B[?1l\x1B>");
Object.defineConstant(impl, "keypad_xmit", "\x1B[?1h\x1B=");

return impl;
})();

Namespace.register("VT100", null, VT100, "withVT100");
[/code]

Now we're cookin' with asparagus!!! Sending VT100.keypad_xmit causes the client to behave as expected, giving the key values listed in the terminfo as expected.
08 Jan, 2013, Telgar wrote in the 47th comment:
Votes: 0
Oh, I got a Windows VM running and hit the Windows Telnet bug.

My thoughts on this:
09 Jan, 2013, Kaz wrote in the 48th comment:
Votes: 0
KaVir said:
Scandum said:
So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation, but if you can't be bothered to do that there's also the workaround I used in my protocol snippet: if the first terminal type is "ANSI", don't cycle.


If I recall correctly, you can set the terminal mode within Windows Telnet manually before you log into the server, and this will change the order of the TTYPE responses. Of course, as the saying goes: you can protect against Murphy, but protecting against Machiavelli is harder.

Strangely, I remember that the safest thing to do seemed to be to set the mode explicitly to VTNT. That way, it wouldn't "land" on it and be horrible when the TTYPE cycle ended.

KaVir said:
Telgar said:
Well first off, I don't care about having fancy-dancy VT100 support for Windows Telnet users.

While Windows Telnet has its problems, it actually offers pretty good ANSI/VT100 terminal s... - far better than most mud clients. Of course the whole concept is seriously outdated, I doubt you'd see many modern muds bothering with it when it's so easy to have proper graphics.


*sheepish grin* *innocent whistle*
09 Jan, 2013, Scandum wrote in the 49th comment:
Votes: 0
VT100 would be no different from KaVir's GUI snippet's graphics with a good Unicode font, possibly better as you can easily change the color of drawing symbols opposed to having 10 sets of the same drawing in different colors. The windowing support of VT100 is of course sub par.
09 Jan, 2013, Telgar wrote in the 50th comment:
Votes: 0
Kaz said:
KaVir said:
Scandum said:
So for all intense and purposes I think it's safe to ignore cycling as nobody uses Windows Telnet, except for the occasional troll.

A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation, but if you can't be bothered to do that there's also the workaround I used in my protocol snippet: if the first terminal type is "ANSI", don't cycle.


If I recall correctly, you can set the terminal mode within Windows Telnet manually before you log into the server, and this will change the order of the TTYPE responses. Of course, as the saying goes: you can protect against Murphy, but protecting against Machiavelli is harder.

Strangely, I remember that the safest thing to do seemed to be to set the mode explicitly to VTNT. That way, it wouldn't "land" on it and be horrible when the TTYPE cycle ended.

KaVir said:
Telgar said:
Well first off, I don't care about having fancy-dancy VT100 support for Windows Telnet users.

While Windows Telnet has its problems, it actually offers pretty good ANSI/VT100 terminal s... - far better than most mud clients. Of course the whole concept is seriously outdated, I doubt you'd see many modern muds bothering with it when it's so easy to have proper graphics.


*sheepish grin* *innocent whistle*


There is no way in hell I will support a borken client which violates protocol in this day and age when:

1) It takes the user byzantine efforts just to invoke a command prompt to launch "Telnet"
2) If user went to all of this trouble, they are technically capable enough to install TinTIn.
3) If they have no administrative privileges to install shit, this is obviously not their computer and they are a troll.
09 Jan, 2013, Kaz wrote in the 51st comment:
Votes: 0
Telgar said:
There is no way in hell I will support a borken client which violates protocol in this day and age when:

1) It takes the user byzantine efforts just to invoke a command prompt to launch "Telnet"
2) If user went to all of this trouble, they are technically capable enough to install TinTIn.
3) If they have no administrative privileges to install shit, this is obviously not their computer and they are a troll.


Technically, Windows Telnet isn't actually broken. It just adheres to an older version of the RFC (IIRC, it's RFC 930 instead of RFC 1091.

That given, yes, I would agree in a minimum 99% of cases.
09 Jan, 2013, KaVir wrote in the 52nd comment:
Votes: 0
Kaz said:
Technically, Windows Telnet isn't actually broken. It just adheres to an older version of the RFC (IIRC, it's RFC 930 instead of RFC 1091.

That given, yes, I would agree in a minimum 99% of cases.

I'd estimate that around 3-5% of my active players use Windows Telnet, but as far as I'm aware none of them use it as their primary client, they only use it from locations where they can't run web clients and aren't allowed to install their own software.
09 Jan, 2013, quixadhal wrote in the 53rd comment:
Votes: 0
It should be noted that there is a portable version of Putty, which runs entirely from a USB stick. If your lab/workplace/etc won't let you run programs from a usb stick, maybe you shouldn't be playing games from there?
09 Jan, 2013, KaVir wrote in the 54th comment:
Votes: 0
quixadhal said:
If your lab/workplace/etc won't let you run programs from a usb stick, maybe you shouldn't be playing games from there?

If your lab/workplace/etc lets you play games, but has a policy against using your own software, maybe you should stick with Windows Telnet?
09 Jan, 2013, Vigud wrote in the 55th comment:
Votes: 0
If it lets you play games, it likely lets you browse the Web. That way, you might be able to use one of the web-based mud clients.
09 Jan, 2013, KaVir wrote in the 56th comment:
Votes: 0
Vigud said:
If it lets you play games, it likely lets you browse the Web. That way, you might be able to use one of the web-based mud clients.

I did suggest that to a couple of the players, but they said they couldn't use browser clients - I'm not sure if it was a firewall issue, or because the PC was really old.
09 Jan, 2013, quixadhal wrote in the 57th comment:
Votes: 0
KaVir said:
quixadhal said:
If your lab/workplace/etc won't let you run programs from a usb stick, maybe you shouldn't be playing games from there?

If your lab/workplace/etc lets you play games, but has a policy against using your own software, maybe you should stick with Windows Telnet?


I'd like an example of somewhere so strict that you can't even run (not install, just run) your own software, but that still officially allows you to play games. Circa 2010 onwards please, not in Ye Olden Days when people used mainframes they weren't allowed to touch.
09 Jan, 2013, KaVir wrote in the 58th comment:
Votes: 0
quixadhal said:
I'd like an example of somewhere so strict that you can't even run (not install, just run) your own software, but that still officially allows you to play games. Circa 2010 onwards please, not in Ye Olden Days when people used mainframes they weren't allowed to touch.

External storage devices introduce a number of security risks, as the data doesn't need to pass through the firewall. It's not unheard of for companies to ban or restrict their use.

However it's pretty rare for companies to ban you from playing preinstalled games (such as solitaire or minesweeper) during your lunch break.

The IT policy at my workplace doesn't explicitly mention games, but it does say that the internet can be used for personal things as long as they're legal and it doesn't interfere with your work, and you make up the hours.

The same policy prohibits me from using software that hasn't been authorised by the IT department. I don't recall off the top of my head if it uses the word "install" or "run", but the same security concerns apply to both - if they don't want people installing potentially risky applications, then I doubt they'd be happy about people running those same application from a USB stick. At least browser games go through the firewall.
10 Jan, 2013, Scandum wrote in the 59th comment:
Votes: 0
KaVir said:
A few of my active players use Windows Telnet while playing from work or school, as it's their only option. I used donky's approach for identifying Windows Telnet prior to negotiation

All they have to do is press ctrl-] and type 'set localecho' to fix their local echo problems.

My MSSP crawler is getting a bunch of 'Attempting to Detect Client, Please Wait…' messages instead of a login screen, in my opinion it's an inelegant solution to a minor problem.

I wonder, is the donky ID patch the reason why several MSSP enabled MUDs are being ignored by the MudBytes crawler?
10 Jan, 2013, Tyche wrote in the 60th comment:
Votes: 0
Scandum said:
My MSSP crawler is getting a bunch of 'Attempting to Detect Client, Please Wait…' messages instead of a login screen, in my opinion it's an inelegant solution to a minor problem.
I wonder, is the donky ID patch the reason why several MSSP enabled MUDs are being ignored by the MudBytes crawler?

There's always been a question of just how long should you wait for a client to respond to negotiations.
Not only to identify Windows Telnet, in order to avoid entering character mode, but also to identify the many dumb mud clients.
Anyway, I don't send a message, but there is a several second connection lag in TeensyMud.
40.0/75