LAN-based TCP/IP* and Serial connections are more alike than you might originally imagine.

The HP3000, from its very beginnings, has always promoted the use of "full-duplex" communications. When you're using a full-duplex serial connection, signals are being sent simultaneously in both directions, from the terminal to the host computer and from the computer to the terminal, on two different wires (the send and receive lines). Indeed, to communicate with an HP3000's terminal port, you only need three wires (send, receive and a common ground) running from your PC's COM port to the HP3000.

In a full-duplex serial connection, when you strike a character on the keyboard, that character doesn't go immediately to your terminal's screen. Rather, it is transmitted out to the HP3000 on the send wire, where it is "absorbed" into a growing string of characters in a storage buffer, and, when once received, is re-transmitted (echoed) back to you on the receive wire. Only then do you see the character on your screen.

While this may seem a long route to take, full-duplex has traditionally been by far and away the preferred protocol for communication with a host computer because you have this very strong reassurance that the host did indeed receive the character. The host's retransmission of the character back to you is an explicit verification that it saw and absorbed the character you just typed.

Further, the HP3000 has always operated in a line buffer mode. The HP3000 doesn't make a decision as to what to do with your typed input until it sees a line termination character (most normally, a carriage return). In the earliest HP3000's, every character that was received by an ADCC (asynchronous data communication card) interrupted the CPU to process the incoming character. It was the CPU, and its local memory, that built the incoming text buffers and echoed the characters back out to the terminals. Clearly, this represented a significant bother to the early, slow CPUs.

A substantial advance occurred with the development of the ATP (advanced terminal processor) cards that appeared in the last of the classic HP3000s. The evolution of microprocessors in the late 1970's allowed the buffering and echoing of characters to be moved out onto a terminal I/O card, away from the CPU, thus relieving the HP3000's CPU of a substantial burden that it had previously had to bear. Received characters no longer constantly bothered the CPU as they were received. Rather now, only when a termination character was received, or the inputted line had reached a certain pre-specified length, or a time-out had occurred, did the auxiliary ATP processor transmit the line of text it was buffering to the CPU, as a whole.

With the arrival of the MPE/iX, RISC-based HP3000's in the late 1980's, HP completely dispensed with the requirement that the multiplexed serial communication cards had to be resident within the frame of the HP3000 itself. Rather, they adopted and extended an evolving philosophy that was well underway by the end of the classic HP3000's production life: Network Services/Virtual Terminal (NS/VT) capabilities. NS/VT is an HP-proprietary client/server protocol - but it is also nothing more than a simple and obvious extension of the design philosophy that had begun with the ATP card, where a remote processor transmits a line of text to the HP3000's CPU only when that line of text is complete.

Two ways are commonly available today to use NS/VT-like services. One requires the use of a DTC (data terminal controller), the other a terminal emulator. In both, the function of the original ATP card is being faithfully recreated. When you serially communicate with a DTC, a processor located on the DTC's serial card is absorbing every character you type and echoing it back to you. Only when a termination character is typed, or the line buffer is full, or a time-out occurs, is your line of text transmitted to the HP3000 as a single packet of information via the LAN that connects the DTC to the HP3000.

Because there is only one signal wire in a LAN cable, full-duplex communication isn't possible. All LAN-based communications are, by default, "simplex" (first one way, then back the other), thus two separate messages can never appear on a LAN at precisely the same time. The reason that you don't notice this one-wayness with a DTC or an NS/VT-based terminal emulator is that you are maintaining essentially full-duplex communication with the DTC serial card - or your PC's memory. Every character you type under NS/VT is immediately echoed back to your screen. Only when you strike the carriage return (or the enter key) is your line of text transmitted over the LAN to the HP3000. "Turn-around times" are so quick on a LAN (if it's not too busy) that you don't tend to notice the nature of one-way communication inherent to a LAN.

Telnet is a second, more common TCP/IP-compatible protocol. Telnet was developed within the UNIX community during the 1970's and 1980's when the internet was first being defined. Because of that "ancient" heritage, telnet is now the most ubiquitous internet/LAN serial terminal communications protocol in existence.

Host-based telnet was introduced onto the HP3000 in MPE/iX 5.5 in 1997. You often hear that telnet is substantially less efficient than is NS/VT. In part, that's true, but it's also important to understand that there are conditions where telnet and HP's NS/VT are equally efficient.

When packets are transmitted back to you from an HP3000, there is absolutely no difference between NS/VT and telnet. The size of the packets are much the same and the load placed on the HP3000 is essentially identical. Quite similarly, when you press the enter key to transmit a screen's worth of block mode-entered material to an HP3000, no appreciable differences exist between telnet and NS/VT's efficiencies. The content of the whole screen is placed in one or two packets and are transmitted to the HP3000 equally efficiently under either protocol.

The real difference between NS/VT and telnet occurs when you type individual characters on your keyboard. Under Telnet, quite unlike NS/VT, every character you type immediately becomes its own packet and is transmitted out over the LAN to the HP3000, where it interrupts the CPU, is put into a growing buffer within the CPU, and is echoed back to you as a new packet. Thus Telnet recapitulates the design of the early ADCC cards - and could easily be described as a 25-year step backwards in time. However, in telnet's favor, HP3000 CPUs have become 50,000% faster during those 25 years. Telnet character interruptions simply no longer seem to be a substantial bother to the new machines.

The truly significant problem with telnet is psychological, especially if the telnet protocol is used over an inter- or intranet of any distance. Under standard telnet, when you strike a character on the keyboard, the character is packetized as a single character packet, transmitted to the distant host where it interrupts the CPU, is added to the buffer, and then echoed back to you. Over thousand-mile distances, where the packets may have to be relayed by dozens of intermediate computers and routers, this leads to very mushy communications that are occasionally so irritating that you can't look at the screen as you type.

To alleviate what can be a truly substantial inutility in telnet, we created two versions of telnet in QCTerm, a "standard" and "advanced" version of telnet. The "advanced" version is nothing more than a reinvention of a thirty-year-old idea: half-duplexed communication. Under half-duplex, QCTerm uses standard telnet commands to suppress character echo in the host computer. In this mode, QCTerm locally echoes all of your keystrokes immediately back onto the screen, much like NS/VT. This not only cuts the number of packets sent and received by half, it makes long distance communication with telnet perfectly psychologically acceptable.

Some UNIX programs depend on full-duplex communications, simply because the characters that these programs return are often not the characters that the user has typed at his keyboard. In these circumstances, the received character is not meant to be faithfully echoed. Rather, the characters are received, interpreted, and often changed to an alternate string of characters before they are transmitted back to the client terminal.

Under these conditions, the immediate local echo of the user-typed key to the terminal's screen associated with the advanced telnet mode may or may not work.

You may also find architectural situations where the "advanced" (half-duplex) telnet mode will not work. One example is where the host you're logged onto is simply relaying all communications to a second host in the background.

An example of this condition is New Mexico State University's library (lib.nmsu.edu), which is running the Virginia Tech Library System on an HP3000, but the gateway for all communications into the university is through a Sun machine running UNIX.

The Sun creates the HP3000 VTLS session as a remote process. Suppressing host echo in this situation only suppresses it in the foreground machine. The echo-suppress information is not being passed onto the HP3000, thus double-echoing (originating both locally within QCTerm and from the HP3000) occurs. The only choice under these circumstances is to use the "Standard" option.

However, it is also important to note that the HP-proprietary NS/VT protocol completely fails in such a situation. A UNIX gateway that is acting as a remote process initiator to an HP3000 will not, in general, recognize or respond to the NS/VT commands. Standard telnet access is the only form of connectivity that will allow you transparent communications to the HP3000.

You need not memorize any of these conditions. It will be perfectly obvious when things are working and when they aren't. Reverting to standard telnet (full-duplex) communications is the solution in almost all cases.


*TCP/IP is an acronym for Transmission Control Protocol/Internet Protocol.