I would say the 'delay' when connecting to a BBS is more likely due to
it resolving your address rather than waiting for telnet commands,
telnet commands can happen at any time throughout the connection and are handled (if they are handled) on the fly, so no need to wait.
Some of the options are negotiated at the very start (window size,
status line, flow, etc) and those are needed before the rest of the session
can continue. In a request/response flow, the only way to be sure all of the client's *initial* options are set is to wait for more being sent.
Since Crystal doesn't do non-blocking IO (yet), I have to set the socket timeout to 1 second and then, if no more data is sent from the client, to assume no more options related to the session's initial setup are needed.
I've seen this kind of "negotiation" timeout in other telnet servers.
For example say someone resizes their terminal while connected, the
telnet protocol must update window size and so on.
Sure, but again that's not necessary for the initial setup of the session.
Also, ansi codes are not related to telnet, they are related to your terminal type and can be sent over any kind of connection, be it telnet ssh, serial connection or just your system console.
Do you mean IAC messages or escape sequences? I mention escape sequences as being maybe familiar to bash prompts and so on, but I might need to emphasize that they're not Telnet related.
Cheers,
--
"I must not fear. Fear is the mind-killer."
--- Mystic BBS v1.12 A31 (Raspberry Pi)
* Origin: Scifi Hangout (21:2/114)