Telnet over half-duplex comms link - negotiation parameters

Question

Our embedded system needs a Telnet (over serial) interface, due to hardware / legacy system it's working over a half-duplex link (RS485). Yes, I know - no, we can't change it, the industry likes it that way.

The problem with this is that while we're sending a screenfull of text to the terminal, the user can be pushing buttons and sending data back up the wire.

Telnet supports the IAC->GA (Go Ahead) command to signal to the user terminal it can begin sending data, but there is no info in any of the RFC's I've read about what tells the user terminal to stop sending data so we can refresh the screen.

Unfortunately all of the RFC's beyond about 1973 assume that the SGA (Suppress Go Ahead) mode will be used so it gets very little mention. Unfortunately there seems to be no single RFC or other document that actually covers the entirety of the protocol.

Does anyone have any info / links that document the telnet protocol (or just the Go Ahead behaviour) more fully? I realise some of it is probably written on parchment with green stripes ;)

RE-Edit: Why the "off-topic" closure of this programming question? Telnet is layer 7 of the OSI model y'know...

Answer 1

Ahhh... RS-485... I remember it well! :-)

The GA definition is broken (see http://tools.ietf.org/html/rfc596) but should be okay for a serial-line implementation because there is no break-up of packets.

What you're asking for is a "reverse break":

"Reverse break" is a means by which a computer connected to a terminal by a half-duplex path may regain control of the path for further typeout after previously having relinquished it.

By it's very nature, a "break" (reverse or otherwise) must be out-of-band on a half-duplex connection since it needs to be able to be sent at any time.

EDIT: New info as a result of a chat: However, if you don't expect to be interrupting an actual transmission (RFC393, reverse-break case "b") and the side with the go-ahead token does not switch the hardware to "transmit" mode except when actually transmitting (RS-485 cannot receive when in this mode even if no data is being sent) and an occasional corrupted/truncated transmission is tolerable and the telnet program correctly implements this rather unusual corner-case, then sending this code in-band may be acceptable.

Another way I can think to deal with this would be to hack the client side Telnet program to periodically send a "go-ahead" packet to the server even when it has nothing else to send. This would allow the server to do an update and do "go-ahead" in return; it's somewhat like "token ring". You wouldn't even have to delay -- when receiving "go-ahead", send all pending data (might be none) and then return the "go-ahead".

Possible Alternative Solution:

Since you control the ser->ip device as well, why not simply have a specialized protocol between the server and device?

• server sends STX data stream ETX

• client send STX data stream ETX

• repeat with no delay

If either side has no data in its data buffer, then it's just an STX ETX pair effectively telling the other side to "go ahead". If nothing comes from the other side within 250ms, resend ETX

You could even extend this to have error detection by going STX data stream ETX CRC1 CRC2 with a NAK (instead of STX ...) reply in the case of a detected error, and causing a re-transmit of the entire last packet.