28 Jun, 2011, KaVir wrote in the 1st comment:
Votes: 0
Last year, donky wrote a proposal for client identification. The underlying problem is that if you negotiate with windows telnet (in any way at all) it switches off echo. This is obviously undesirable, even though it already occurs on the majority of muds (because most muds negotiate echo when you enter your password).

A further extension to this problem is that if you use cyclic TTYPE on windows telnet, it ends up using the VTNT terminal type, which effectively causes the client to freeze completely, for reasons described here by Kaz.

Following donky's proposal, I therefore implemented the following:

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

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

[b]Step 3[/b]: If I didn't detect windows telnet after the 2nd second, I attempt to negotiate TTYPE. If the client either accepts or declines TTYPE, I negotiate all of the remaining protocols. If TTYPE is accepted, I perform a cyclic TTYPE query to look for extended colour support.

[b]Step 4[/b]: On the 3rd second, I display the welcome screen and allow the user to enter input.

This works fine for me*, however I've also had a couple of people ask if I could add it to my protocol snippet, and I'm wondering how that'll work in conjunction with MSSP.

MSSP crawlers connecting to my mud only ever seem to use the plain text version (I support both) - they don't like to wait. But my snippet doesn't support the plain text version (yet at least).

Because most muds switch off echo (with the "password" prompt) the moment you enter your name, it would be necessary to block/delay input for a few seconds until the negotiation was complete. However every crawler I've encountered seems to drop its connection almost instantly.

One possibility would be to have a separate state during negotiation which prevents you from logging on, but does allow other input. However that would also prevent clients from autoconnecting, as it would be necessary to parse the input rather than pause - and as I discovered first hand, players can get grumpy when their autoconnect stops working.

The only way around it that I can think of is to queue up the input [i]unless[/i] it's "MSSP-REQUEST". That would require some changes to the way input worked, and I'm not sure how easy it would be without a codebase-specific solution - something I really want to avoid for my snippet.

I suppose the other way would be to try and persuade the crawlers to wait a few seconds. But would they bother, if it was just a handful of muds using this approach? Probably not.


[i]* Although TinTin++ sometimes adds the escape code response to the input buffer instead of sending it to the mud - it appears to be related to the use of linewrap.[/i]
28 Jun, 2011, Scandum wrote in the 2nd comment:
Votes: 0
A better way to go about this is as following:

1) Get the terminal type and store the first response, this will be ANSI for windows telnet. Probably best to support MTTS while at it and request the terminal type 3 times and be on the lookout for known terminal types and an MTTS response, then send IAC DONT TTYPE which should reset the TTYPE state for Windows telnet and possibly other clients.

2) Negotiate NEW-ENVIRON and request SYSTEMTYPE (code for this is available in my public domain MTH) snippet, which Windows will respond with with WIN32 (not sure if this can be WIN64 on 64 bit systems). As far as I know only Windows telnet responds with WIN32 to the SYSTEMTYPE request so this will unique identify Windows telnet, but probably safest to double check by using the ANSI ttype response as well.

3) As you now have Windows telnet uniquely identified and you know it's in character mode you need to handle remote echo, which is fairly easy. You'd want to set some kind of remote echo flag, and after filtering out the telnet codes you'd do something along these lines:

d->intop += translate_telopts(d, bufin, nRead, d->inbuf + d->intop);

if (IS_SET(d->comm_flags, COMM_FLAG_REMOTEECHO))
{
for (nSkip = nCurr ; nSkip < d->intop ; nSkip++)
{
switch (d->inbuf[nSkip])
{
case 8:
case 127:
d->inbuf[nSkip] = '\b';
write(d->descriptor, "\b \b", 3);
break;

case '\n':
write(d->descriptor, "\n\r", 2);
break;

default:
write(d->descriptor, d->inbuf + nSkip, 1);
break;
}
}
}
28 Jun, 2011, KaVir wrote in the 3rd comment:
Votes: 0
I don't want to switch to character mode, I've always hated it - it feels so laggy. It's frustrating enough using it when connected to my shell account, trying to use it in the heat of combat would drive me nuts.

The escape code method already allows you to identify windows telnet without losing echo. The only problem appears to be with MSSP crawlers.

In regard to IAC DONT TTYPE, I already tried that and it didn't seem to work. Nor did window telnet return to the beginning of the terminal list after sending VTNT twice. Perhaps the client had already frozen by that point though.
28 Jun, 2011, Scandum wrote in the 4th comment:
Votes: 0
Delaying the login process and sending obscure codes to detect a client that's been disabled as of Windows Vista seems a little out there however.

Another solution is using telnet detection and instructing people to press ctrl-] and entering: set localecho to enable local echo manually.

As I'm having difficulties handling MUDs closing the connection on a plain text MSSP request, and gotten complaints about hammering MUDs with MSSP-REQUEST I'm going to drop support for plaintext as well, which will further shorten the amount of time the crawler will stick around, and significantly decrease the time it takes to crawl 800 MUDs.
29 Jun, 2011, quixadhal wrote in the 5th comment:
Votes: 0
KaVir said:
In regard to IAC DONT TTYPE, I already tried that and it didn't seem to work. Nor did window telnet return to the beginning of the terminal list after sending VTNT twice. Perhaps the client had already frozen by that point though.


According to RFC884, it's not supposed to.

Quote
In such cases, the sender of the TERMINAL-TYPE IS
command should reply to successive TERMINAL-TYPE SEND commands with
the various names, from most to least specific. In this way, a
telnet server that does not understand the first response can prompt
for alternatives. However, it should cease sending TERMINAL-TYPE
SEND commands after receiving the same response two consecutive
times. Similarly, a sender should indicate it has sent all available
names by repeating the last one sent.


It does not say you're supposed to repeat it once and then loop back, it says you repeat the last one.
[EDIT]In fact, it says the server should STOP sending requests after it gets the same answer back twice in a row, meaning the client isn't even obligated to respond IN ANY WAY once it has indicated it's at the end of the list.

Scandum said:
As I'm having difficulties handling MUDs closing the connection on a plain text MSSP request,


Would those be muds which don't actually support MSSP doing the logical thing and dropping the connection when an unknown user MSSP-REQUEST attempts (and fails) to login?

Scandum said:
and gotten complaints about hammering MUDs with MSSP-REQUEST


How often do you attempt to crawl such games? I wouldn't expect any complaints if you scan your mudlist once a day, and if you skip over failed attempts rather than sitting there retrying them.

Scandum said:
I'm going to drop support for plaintext as well


Way to thumb your nose at the small handful of people who helped you get your protocol off the ground in the first place. Bravo.
29 Jun, 2011, Scandum wrote in the 6th comment:
Votes: 0
quixadhal said:
Would those be muds which don't actually support MSSP doing the logical thing and dropping the connection when an unknown user MSSP-REQUEST attempts (and fails) to login?

No.

quixadhal said:
Way to thumb your nose at the small handful of people who helped you get your protocol off the ground in the first place. Bravo.

I'm sorry if I hurt your feelings.
29 Jun, 2011, KaVir wrote in the 7th comment:
Votes: 0
Scandum said:
Delaying the login process and sending obscure codes to detect a client that's been disabled as of Windows Vista seems a little out there however.

The delay is just a few seconds, and I do have a few players who use windows telnet - generally when connecting from work, where they're unable to use any other clients. Either they use windows telnet, or they don't play.

Losing support for windows telnet was also a deal-breaker for Realms of Despair, although I don't know exactly how many of their players use it. They are considering adding the delay as well, but it's still under discussion. I know of at least two other muds that are also interested in adding it.

Scandum said:
As I'm having difficulties handling MUDs closing the connection on a plain text MSSP request, and gotten complaints about hammering MUDs with MSSP-REQUEST I'm going to drop support for plaintext as well, which will further shorten the amount of time the crawler will stick around, and significantly decrease the time it takes to crawl 800 MUDs.

If you're dropping support for plain text, then why not have the crawler initiate the MSSP request itself? My mud (and snippet) can handle that, and it'll bypass the delay completely.

Failing that, you could just have the crawler wait a few seconds before disconnecting.

quixadhal said:
KaVir said:
In regard to IAC DONT TTYPE, I already tried that and it didn't seem to work. Nor did window telnet return to the beginning of the terminal list after sending VTNT twice. Perhaps the client had already frozen by that point though.

According to RFC884, it's not supposed to.

RFC 884 is superseded by RFC 930, which in turn is superseded by RFC 1091. RFC 1091 states:

"When the server (the receiver of the TERMINAL-TYPE IS) receives the same response two consecutive times, this indicates the end of the list of available types. Similarly, the client should indicate it has sent all available names by repeating the last one sent. If an additional request is received, this indicates that the server (the sender of the IS) wishes to return to the top of the list of available types (probably to select the least of N evils)."
29 Jun, 2011, Scandum wrote in the 8th comment:
Votes: 0
KaVir said:
If you're dropping support for plain text, then why not have the crawler initiate the MSSP request itself? My mud (and snippet) can handle that, and it'll bypass the delay completely.

It's not a viable solution for MUD clients looking for updates during the connection process, it'd make telnet mssp as limited as the plaintext version.

Character mode is the cleanest solution that doesn't impact the vast majority of players that do not use windows telnet. After the initial login a configuration option can be used to determine if the user wants to stay in character mode or have it disabled (and presumably manually enable local echoing).
29 Jun, 2011, Rarva.Riendf wrote in the 9th comment:
Votes: 0
Great I just implemented Kavir Snippet…Like probably a lot of people who dont want to mess with protocols as it is not really an interesting part of a game, I will only ask one thing:
Announce what will come out of discussion once it is done and closed so we can come to the choice of:removing the snippet from our code, or have it updated if it can.
29 Jun, 2011, KaVir wrote in the 10th comment:
Votes: 0
Scandum said:
KaVir said:
If you're dropping support for plain text, then why not have the crawler initiate the MSSP request itself? My mud (and snippet) can handle that, and it'll bypass the delay completely.

It's not a viable solution for MUD clients looking for updates during the connection process, it'd make telnet mssp as limited as the plaintext version.

But mud clients will be connected for more than a second, so the server will negotiate with them anyway. It's only the crawlers that don't seem to like hanging around.

Either way, the crawlers have two options - initiate negotiation, or wait a few seconds.

Rarva.Riendf said:
Great I just implemented Kavir Snippet…Like probably a lot of people who dont want to mess with protocols as it is not really an interesting part of a game, I will only ask one thing:
Announce what will come out of discussion once it is done and closed so we can come to the choice of:removing the snippet from our code, or have it updated if it can.

This has no impact on the current version of the snippet, it's an enhancement I'm considering adding. But even if it did have an impact, MSSP is just one tiny part of the snippet - if that's all you wanted it for, there are easier snippets you can use - and it wouldn't take much longer to create your own solution from scratch.
29 Jun, 2011, quixadhal wrote in the 11th comment:
Votes: 0
KaVir said:
RFC 884 is superseded by RFC 930, which in turn is superseded by RFC 1091. RFC 1091 states:

"When the server (the receiver of the TERMINAL-TYPE IS) receives the same response two consecutive times, this indicates the end of the list of available types. Similarly, the client should indicate it has sent all available names by repeating the last one sent. If an additional request is received, this indicates that the server (the sender of the IS) wishes to return to the top of the list of available types (probably to select the least of N evils)."


Oops, my bad. You are correct. I would guess windows telnet probably hasn't been updated to follow the newer (more clarified) RFC.
29 Jun, 2011, Kaz wrote in the 12th comment:
Votes: 0
quixadhal said:
Oops, my bad. You are correct. I would guess windows telnet probably hasn't been updated to follow the newer (more clarified) RFC.


Nope. And, alas, it also means that they're not incorrect. :(
30 Jun, 2011, Scandum wrote in the 13th comment:
Votes: 0
KaVir said:
Scandum said:
KaVir said:
If you're dropping support for plain text, then why not have the crawler initiate the MSSP request itself? My mud (and snippet) can handle that, and it'll bypass the delay completely.

It's not a viable solution for MUD clients looking for updates during the connection process, it'd make telnet mssp as limited as the plaintext version.

But mud clients will be connected for more than a second, so the server will negotiate with them anyway. It's only the crawlers that don't seem to like hanging around.

It's your snippet and you can do as you please, but I can't justify ordering crawlers to start telnet hammering servers for a non significant amount of Windows telnet users, especially when there's a viable alternative.
30 Jun, 2011, Runter wrote in the 14th comment:
Votes: 0
Scandum said:
KaVir said:
Scandum said:
KaVir said:
If you're dropping support for plain text, then why not have the crawler initiate the MSSP request itself? My mud (and snippet) can handle that, and it'll bypass the delay completely.

It's not a viable solution for MUD clients looking for updates during the connection process, it'd make telnet mssp as limited as the plaintext version.

But mud clients will be connected for more than a second, so the server will negotiate with them anyway. It's only the crawlers that don't seem to like hanging around.

It's your snippet and you can do as you please, but I can't justify ordering crawlers to start telnet hammering servers for a non significant amount of Windows telnet users, especially when there's a viable alternative.


Would it really rise to the term "hammering?" Wouldn't it be relatively trivial?
30 Jun, 2011, Scandum wrote in the 15th comment:
Votes: 0
Sure, lets have everyone make their trivial modifications, I'll add every trivial modification to the specification, and we'll expect crawlers to relatively trivially implement each trivial triviality.

After the hundredth trivial amendment we could have a trivial party.
30 Jun, 2011, Twisol wrote in the 16th comment:
Votes: 0
Where we can play Trivial Pursuit!

(You disappointed me greatly by not ending with that. :cry:)
30 Jun, 2011, kiasyn wrote in the 17th comment:
Votes: 0
Kavir said:
MSSP crawlers connecting to my mud only ever seem to use the plain text version (I support both) - they don't like to wait. But my snippet doesn't support the plain text version (yet at least).


The MUDBytes Crawler supports both, BUT on connection it sends MSSP_REQUEST. Which your server replies to before negotiation is complete and then it kills the connection.

kinda funny actually.
30 Jun, 2011, KaVir wrote in the 18th comment:
Votes: 0
Scandum said:
It's your snippet and you can do as you please, but I can't justify ordering crawlers to start telnet hammering servers for a non significant amount of Windows telnet users, especially when there's a viable alternative.

It's only 3 bytes, and if the mud doesn't support negotiation they wouldn't even know about it. But if you really don't like doing that, why not just wait a few seconds before disconnecting?

If I do add the escape code negotiation to my snippet I'll make it optional, but there are players who still use windows telnet, so I imagine some muds will use the option. Whether the MSSP crawlers choose to ignore those muds or not will be up to them.

kiasyn said:
The MUDBytes Crawler supports both, BUT on connection it sends MSSP_REQUEST. Which your server replies to before negotiation is complete and then it kills the connection.

Yeah but I allow people to skip the login screen if they wish (for autoconnect scripts). Most muds can't really do that, because they toggle ECHO during login (for passwords), so they need to wait for the negotiation to complete before allowing people to log on.
30 Jun, 2011, kiasyn wrote in the 19th comment:
Votes: 0
just explaining why you only get plain text requests :)
01 Jul, 2011, Scandum wrote in the 20th comment:
Votes: 0
KaVir said:
It's only 3 bytes, and if the mud doesn't support negotiation they wouldn't even know about it. But if you really don't like doing that, why not just wait a few seconds before disconnecting?

If a crawler waits an extra 4 seconds, and crawls 900 MUDs, that'll add an hour to the crawl.

KaVir said:
If I do add the escape code negotiation to my snippet I'll make it optional, but there are players who still use windows telnet, so I imagine some muds will use the option. Whether the MSSP crawlers choose to ignore those muds or not will be up to them.

I'm sure it'll work itself out one way or another.
0.0/40