09 Aug, 2012, Idealiad wrote in the 1st comment:
Votes: 0
Let's say I was writing a mud with a websocket client. Now I can also open another TCP socket, just specifying simple things like how the line terminates but not including anything of the Telnet protocol. I can connect to this with Mushclient and a simple echo server seems to work as expected without anything weird happening.

However my question is, do you know of other clients where something weird willhappen if I just let clients connect on the Telnet-less TCP socket?

The idea is the websocket client will be the 'official' client, but I can let players come in with their mud client for basically no (edit: well, some, but not as much) up front work on my part. Of course I may add Telnet-based functionality down the road, but for starters this seems like it may be a no-brainer. Is this a sound plan?
09 Aug, 2012, quixadhal wrote in the 2nd comment:
Votes: 0
This may be a shock to you, but the vast majority of MUD's out there do NOT support TELNET. Many of them just read data from the TCP socket that connects and assume it's all game data. A few will use a subset of TELNET to negotiate specific things, like NAWS or TTYPE. Very few actually have a proper TELNET state machine to really speak the protocol correctly and handle whatever a TELNET client might choose to send.

As for the something weird…. that entirely depends on what clients connect, and what assumptions they make. If you send a TELNET negotiation and the client doesn't understand it, it may result in some gibberish in the display (IAC is ASCII 255, which often results in a y with two dots over it for many fonts). If you don't support TELNET and the client decides to send some negotation, you may get similar gibberish in your input stream, for example the username might start with non-alphanumeric characters.

There's no penalty for ignoring it completely, although it would be wise for you to explicitly filter out any characters outside the expected range if you don't plan to support TELNET, just to avoid a client sending stuff that you can't deal with.
09 Aug, 2012, Shaitan wrote in the 3rd comment:
Votes: 0
If you're just sending the text the user would see in their terminal over websockets then doing the same thing over tcp for telnet would work, but it seems like there's a big opportunity cost if you're not using websockets to do more interesting out of band things that sending something like json instead would allow.
09 Aug, 2012, Idealiad wrote in the 4th comment:
Votes: 0
@quix thanks, that's about what I expected and that's a good tip to filter the input.

Shaitan, the websocket messages won't be plain text, so it will require a bit of translation work, but not too much so I think it's worth it.