The Evolution of Terminal Servers

The faithful terminal server has been with us for a number of years now. It was born out of the early Unix days as the systems expanded and more and more staff needed access. Before the Terminal Server the way of providing access was by connecting dumb terminals, or ‘green screens’, to multiport serial cards. With these cards the ports all remained in close proximity to the Unix server. This meant that the terminals could only be placed as far away as serial comms allowed. This used to be 15m but with the improved cabling and components used this climbed to around the 100m mark.

To overcome the distance limitation other serial comms methods were sometimes used, namely RS422. By using this, serial lines could be extended up to 1000m.

With the advent of the LAN it was possible to connect between Unix servers using a TCP/IP protocol called Telnet. This allowed one host to make a connection to another as though one was directly connected to the server. From this came the idea of producing a box that was capable of Telnet, but instead of a Unix system, people just used dumb terminals and thus the terminal server was born

They were boxes with a network connection and a number of serial ports. To these serial ports terminals were added and when all powered up the user got a ‘Login’ on their terminal. The login was to gain access to the terminal server and then from there it was possible to Telnet to a remote Unix host on the LAN.

By using these terminal servers it was possible to distribute them around the corporate LAN and then distribute the terminals. Now it was possible to have the server and users in different buildings and, as LANs grew, in different cities.

Printing features were also added to the terminal servers so that they could also act as print servers, again allowing printers to be spread around a LAN.

However, as the popularity of the LAN grew and the networked PC became more popular the need for a terminal server lessened. They are still used in some environments were it is more desirable to put a dumb terminal than a PC, such as workshops or factory floors. Normally in these cases the terminal is used to perform only one function. And, as it is going to get covered in dirt, oil etc, it is cheaper than a PC.

But how does this explain how companies such as Perle Systems find the need Terminal Servers still growing year on year? If we go back to terminal servers for a moment, the connection was always initiated by the terminal server. The Unix server did not know how to connect to the port and hence terminal on its own. All that the server could see was the LAN and could not pin-point specific devices. What was needed was software that could be loaded onto a server that was capable of finding and talking to the terminal servers and their ports. A number of terminal server manufacturers produced this software with varying degrees of functionality.

However, the moment this software was created, the application possibilities for Terminal Servers grew. The reason for this is that now a connection could be initiated from the application server and this created the ability to talk to dumb devices that were not capable of making a connection the host. Such devices include bar code scanners, weigh scales, flow meters and environmental controls.

The software creates what is called ‘fixed TTY’ or ‘fixed COM’ ports, depending on whether Unix or Microsoft O/S is being used. Most variants of this software allow the application to see the port and talk to the attached device but not actually control all the serial port signals. There are a few such as Perle’s TruePort software that actually allow full control of the serial port. There are many applications that demand this kind of control and up until now have had to be content with using multi-port serial cards.

Examples of the use of Terminal Servers include:

• A large music publisher uses terminal servers to control fire doors within one of its corporate headquarters. A serial signal was held high to hold a solenoid closed which in turn keeps a fire door open. In the event of a fire the signal is dropped, the solenoid opens and the door closes
• A Scottish company involved in the oil industry mounts a terminal server in every one of its cabinets that go onto the oil rigs. The serial ports are connected to flow meters which enable accurate measurement of the oil flow instantly.
• A number of customers install terminal servers to monitor various elements of a buildings security system.
• They are used to connect the transponders mounted in the tarmac in race circuits. These are used to detect when a Formula 1 car moves off the line to early or the time they spend in the pits.

The fixed connection software also brought added benefits to the traditional green screen users. Accounts applications which use green screens need to keep track of all transactions, where and who performed them for auditing and recovery purposes. Normally the only way this could be done was to use multi-port serial cards as this was the only way to guarantee where a certain terminal was positioned. If terminal servers were used with Telnet, each terminal came in as a pseudo connection and it was different every session which made it impossible to track. Now with fixed TTY software the application server can initiate the connection and therefore know which terminal it is connecting to every time.

The terminal server market has seen some changes but it is still as healthy as ever due to the increased markets it can go in to. The latest evolution is based on what these products are being called: Terminal Servers, Device Servers, Serial Servers or Console Servers. To learn more about the terminology read this Serial over Ethernet article.

Learn more about Perle’s IOLAN Terminal Servers.