The reason this is so much longer for telnet is that some clients can't be pinged, and our telnet support is mostly geared toward the lowest common denominator. There might be a way to ask telnet clients which ones support pings and go from there, so perhaps we could at least support faster disconnects for clients that can handle such a thing.

One thing I can tell you for sure is that we used to have a lower timeout across the board, and games that relied on telnet a lot were reporting dropped connections--such as Chatters--because the server couldn't tell an idling telnet connection from a broken one. If we can improve on this that would definitely be good, but it's good to know there isn't a bug in play.
Maybe a simple workaround rather than arbitrarily including a list of telnet clients and their features would be to try to ping the client on connection, and if you receive incoming activity after the initial handshake and ping, but not pong, assume that the client is a type that doesn't support pinging. That way, very few telnet connections would just hang out on the server. Only those that disconnected before the handshake was complete. At which point, you could just terminate them anyway, because the handshake failed, so why do we need to assume that they are even there?
In response to Ter13
Ter13 wrote:
Maybe a simple workaround rather than arbitrarily including a list of telnet clients and their features would be to try to ping the client on connection, and if you receive incoming activity after the initial handshake and ping, but not pong, assume that the client is a type that doesn't support pinging.

I was actually thinking of just using the appropriate telnet protocols to ask the client about its capabilities, but failing that a ping test works too. (Although, one can safely assume any client that doesn't respond to a request for its capabilities won't respond to a ping either.) There's no way we could keep an arbitrary list of clients because nothing in the connection protocol would tell us which client was connecting anyway.
In response to Lummox JR
Lummox JR wrote:
Ter13 wrote:
Maybe a simple workaround rather than arbitrarily including a list of telnet clients and their features would be to try to ping the client on connection, and if you receive incoming activity after the initial handshake and ping, but not pong, assume that the client is a type that doesn't support pinging.

I was actually thinking of just using the appropriate telnet protocols to ask the client about its capabilities, but failing that a ping test works too. (Although, one can safely assume any client that doesn't respond to a request for its capabilities won't respond to a ping either.) There's no way we could keep an arbitrary list of clients because nothing in the connection protocol would tell us which client was connecting anyway.

Ah. Touche. It's been a LONG time since I've touched telnet. Probably ~7 years now. Never much got the hang of the capabilities. Putty always flipped out on me whenever I tried.
In response to Lummox JR
Lummox JR wrote:
The reason this is so much longer for telnet is that some clients can't be pinged, and our telnet support is mostly geared toward the lowest common denominator. There might be a way to ask telnet clients which ones support pings and go from there, so perhaps we could at least support faster disconnects for clients that can handle such a thing.

One thing I can tell you for sure is that we used to have a lower timeout across the board, and games that relied on telnet a lot were reporting dropped connections--such as Chatters--because the server couldn't tell an idling telnet connection from a broken one. If we can improve on this that would definitely be good, but it's good to know there isn't a bug in play.

Thanks for taking the time to look into this.

Hopefully in the future it can be improved on.

BYOND should implement a feature that allows us to ping clients.
You can, actually. Send them a browser window with a JS function and a hidden link in it. Send a request via JS with a Topic() link attached to a display:none element, and wait for onload to trigger your callback. If the specified timeout is reached, drop them manually.
In response to Ter13
Doesn't apply to telnet. Good idea for a client-based ping though.
In response to Lummox JR
Lummox JR wrote:
Doesn't apply to telnet. Good idea for a client-based ping though.

Oh sorry, I meant to say that it wouldn't work for a telnet client... You know, no interface, no browser and all.
Yeah, right now DS clients are killed after 15 minutes (at most) of inactivity, so that's set; the issue is really that telnet lasts longer, largely because it's expected that the client will be inactive for long periods in something like a chat.
In response to Lummox JR
Lummox JR wrote:
Yeah, right now DS clients are killed after 15 minutes (at most) of inactivity, so that's set; the issue is really that telnet lasts longer, largely because it's expected that the client will be inactive for long periods in something like a chat.

Maybe you could make it a world setting so people can configure the timeouts.
Page: 1 2