Half-duplex Telnet - negotiation options

Question

Our embedded system requires a Telnet interface (via a serial interface), since the hardware / legacy system works on half duplex communication (RS485). Yes, I know - no, we cannot change it, the industry likes it so much.

The problem is that while we send screen text to the terminal, the user can press buttons and send data back to the wire.

Telnet supports the IAC-> GA (Go Ahead) command to signal to the user that he can start sending data, but there is no information in any of the RFCs that I read about telling the user terminal to stop sending data so that we could update the screen.

Unfortunately, all RFCs outside of 1973 suggest that the SGA ( Suppress Go Ahead ) mode will be used, so it mentions very little. Unfortunately, there does not seem to be a single RFC or other document that actually covers the entire protocol.

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

RE-Edit: Why is closing this programming question “off topic”? Telnet is the OSI model layer 7 that you know ...

Answer 1

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

The definition of GA is broken (see http://tools.ietf.org/html/rfc596 ), but should be good for implementing a consistent line, because there is no packet decay.

What you are asking for is a “back break”:

Reverse gap is a means by which a computer connected to a terminal using a half-duplex path can restore track control to the next type after it has been abandoned before.

By its very nature, a “break” (reverse or otherwise) must be out-of-band in a half-duplex connection, as it must be able to be sent at any time.

EDIT: new chat information: however, if you do not expect the actual transfer to be interrupted ( RFC393 , bit-break “b”), and the side with the “good” marker does not switch the hardware to “transfer” mode, unless actually is transmitted (RS-485 cannot receive when in this mode, even if no data is sent), and a random damaged / truncated transmission is permissible, and telnet correctly implements this rather unusual corner case, then sending this code within the range may be acceptable.

Another way I can think of is to hack the client side Telnet program to periodically send the go packet to the server, even if it has nothing more to send. This will allow the server to perform the upgrade and do a "go-ahead" in return; it is somewhat reminiscent of a marker ring. You don’t even have to linger - upon receiving the “good”, send all the pending data (maybe not), and then return the “good”.

Possible alternative solution:

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

• server sends STX data stream ETX

• client sends STX data stream ETX

• repeat without delay

If both sides do not have data in their data buffer, then this is just a STX ETX pair, effectively telling the other side to "go ahead." If nothing happens on the other side within 250 ms, send ETX

You can even extend this to have error detection by going to STX data stream ETX CRC1 CRC2 with a NAK response (instead of STX ... ) in the event of an error being detected and causing a retransmission of the entire last packet.