// Workers AI · dad joke modeWhat did TD/SMP say to its date? Byte-ing to know you.

TD/SMP, short for Terminal Device/Session Management Protocol, was a terminal multiplexer system introduced by DEC on their VT330/340 terminals in 1987. The terminal-side software was referred to as SSU, for Session Support Utility. TD/SMP allowed data from two separate host sessions to be sent to a compatible computer terminal over a single serial port. Earlier terminals had supported multiple sessions, but using separated physical connections to the host. Using TD/SMP also allowed you to free up any additional serial ports, for running a printer or similar tasks. The format was patented and never described in depth, limiting it to DEC's own terminal servers and terminals. More recently, the protocol has been reverse engineered by retrocomputing programmers.

The system worked by embedding short commands, typically around six bytes long, into a serial connection. Commands started with the DC4 (0x14) character and ending with FS (0x1C), with the commands themselves consisting of a single character followed by, typically, two single-byte parameter values. All of the data was encoded by adding 0x40 to the decimal value to ensure the resulting string was within the printable character range, so a 0 would be sent as @. The exception to this rule were session names, which were encoded as decimal numbers, so session A was encoded as 1. Sessions normally started at 1, and session 0 referred to all sessions, used with RESET and certain other messages. When being used, certain control characters had to be escaped, sending a real DC4 with a DC4 and then the letter T, or Q and S for XON and XOFF.

The system supported multiple named sessions and could switch data flow between them. When a connection was first started, the terminal sent a PROBE message to start the system up, or not do this if it wished to operate like a normal terminal without multiple sessions. If PROBE was sent, the host would respond with a short four-character message stating whether it was opening a new connection or if this user had previous sessions already open that it would want to reconnect. A series of OPEN_SESSION and REQUEST_RESTORE and similar messages were used to reconnect if desired. Once the connections were set up, either end could use SELECT_SESSION, after which any additional data from that end would be sent to that connection. For instance, the host could update multiple sessions by sending SELECT_SESSION, data, and then another SELECT_SESSION in series. Either end could select any open session at any time.

DEC terminals generally lacked hardware flow control and used XON/XOFF. Host machines were often slow to respond to these characters, which risked the possibility of overflowing the buffers in the host or terminal server and losing data. To address this, TD/SMP introduced the concept of "credits" that controlled how much data each side of the connection could send before it was sent. For instance, a terminal server on a host machine might have a 2 kB buffer for any given connection, and during session setup it would send the ADD_CREDITS message to the terminal to something close to 2,000, say 1,800 bytes. This allows the terminal to start sending data, subtracting one from the credits for every character, and stopping if the value ever reaches zero. Similarly, the terminal might send a similar message to the host to add 4,000 credits, giving it room to send several pages of data and allowing the terminal to do local scrolling up and down. It was up to the implementations on both ends of the connection to periodically send ADD_CREDITS messages so the other end did not run out in the middle of a session. For instance, the host might add another 1,000 credits to the incoming connection when it saw the remaining credits had dropped to 800. Either end could force the connection to stop by sending a ZERO_CREDITS message, and enquire using VERIFY_CREDITS.