Request: Client Detection and Use

[GoogleCodeExporter]

At the moment, Paradice requires a very strict subset of terminal emulators in 
order to be useful (e.g. PuTTY, TeraTerm.) There are plenty of other clients, 
however, some of them with fewer (GMUD) or different (ZMUD, MUSHClient) 
capabilities.

It would be useful if the server differentiated between these types of clients 
and changed the user interface gracefully to account for all of these types.

Therefore, there are a few steps in this proposal:

 * Detect the client.  Even though there is a standard way of detecting a Telnet client (TTERM-TYPE), not all clients are Telnet clients (GMUD), and not all clients abide by that standard way.  However, each client behaves in certain predictable ways.  See KaVir's Protocol Snippet on MudBytes for inspiration.

 * Factor out the interface for hugin::user_interface.  Only heavily-ANSI-compatible clients (PuTTY, TeraTerm, TinTin++) can handle Paradice at the moment.  Many others expect either line-by-line output and possibly other embedded protocol transmissions.  The Munin component set is not suitable for them.

 * Design new user interface sets for other protocols.
    * Plain Ol' Text for GMUD, Windows Telnet, and the like.
    * Plain Ol' Text Plus for MUSHClient, ZMUD, etc.

Original issue reported on code.google.com by matthew....@gmail.com on 21 Jun 2012 at 11:21

• Blocking: #100
• Blocked on: #106

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Blocked on 106.  According to Kavir's snippet, the way to detect PuTTY is to 
wait for *it* to perform the NAWS negotiation.  Naturally, we will want an 
asynchronous way to handle this rather than polling every second or something.

Original comment by matthew....@gmail.com on 29 Jun 2012 at 7:28

• Now blocked on: #106

[GoogleCodeExporter]

See: 
http://posted-stuff.blogspot.nl/2010/03/proposal-mud-client-identification.html 
for an analysis of GMUD/Windows Telnet, etc.

Original comment by matthew....@gmail.com on 29 Jun 2012 at 7:31

[GoogleCodeExporter]

KaVir's follow-up (with corrections for Linux terminals) is at: 
http://clanscw.brinkster.net/godwars/topic.asp?TOPIC_ID=2675

Original comment by matthew....@gmail.com on 29 Jun 2012 at 7:33

[GoogleCodeExporter]

To preserve should the link ever die (which I don't think will be any time 
soon, but still...)

----- 8< -----

As I'm sure you've noticed, the mud now pauses for a few seconds before 
displaying the welcome screen. This was done to improve client detection, 
particularly for the few players who use windows telnet, using a proposal from 
here: 
http://posted-stuff.blogspot.com/2010/03/proposal-mud-client-identification.html

For most clients it's simply a case of negotiating with them and seeing how 
they respond, but if you negotiate with windows telnet (at all) it assumes you 
want full control, and switches off echo - and there's no way to switch it back 
on. Previously I handled this by not negotiating until you'd logged on, and 
offering a command for opting out of negotiation, but that was pretty 
user-unfriendly, and also looked rather klunky now that I'm starting to use 
xterm 256 colours (because they'd be disabled when you first entered the game, 
and you'd see ANSI colours, then you'd type "look" and you'd see the extended 
colours).

However you can also detect windows telnet by sending the "\033[0x" escape 
sequence. The problem is, if you send that to GMud it'll just print it on the 
screen, and there are still quite a few GMud users. There is another escape 
code you can send though - "\033[0c". You can't identify windows telnet from 
that, but GMud will ignore it while windows telnet will give a standard 
response. So you can send that first, then follow up with the other sequence if 
you get a response.

Unfortunately that'll still display the escape sequence if the player is using 
the PuTTY client. But one of the unusal things about PuTTY is that it initiates 
negotiation itself, rather than waiting for the server to ask. So if the client 
initiates negotiation, we can just skip the escape sequences.

GMud doesn't just have trouble with escape sequences though - its entire 
negotiation implementation is broken. If you try to negotiate with it, it 
literally tries to display the sequences to the client. Fortunately it's at 
least smart enough to skip nonprintable characters, so what we can do is send 
TTYPE first. TTYPE has a value of 24, so GMud will just ignore it - we can then 
just wait for a response before negotiating anything else.

Thus from an implementation perspective, it works like this:

Step 1: After the client connects, we wait for 1 second to see if it initiates 
negotiation. If it does, assume it's PuTTY.

Step 2: If the client didn't initiate negotiation, we send it "\033[0c". If we 
get a response, we immediately follow up by sending "\033[0x". We can identify 
windows telnet from the response to the second escape sequence.

Step 3: If we didn't detect windows telnet after the 2nd second, we attempt to 
negotiate TTYPE. If the client either accepts or declines TTYPE, we negotiate 
all of the remaining protocols. If TTYPE is accepted, we perform a cyclic TTYPE 
query to look for extended colour support (this is the only way to detect 
support in the WinTin++ and BlowTorch clients).

Step 4: On the 3rd second, we display the welcome screen and allow the user to 
enter input. We now know what features their client supports, which means 
unicode, MXP links, extended colour, etc, can be included on the welcome screen.

Original comment by matthew....@gmail.com on 29 Jun 2012 at 7:37

[GoogleCodeExporter]

Also investigate using the connecting device's TERMCAP environment variable 
(see RFC 1572) and working with that on the output.

Original comment by matthew....@gmail.com on 15 Jul 2013 at 7:33