In the Beginning: The History and Evolution of Device Servers

Lantronix PremierWave EN dual band WiFi device server

In the beginning (well the 1980s), there were terminal servers. And they were good. These devices allowed for dozens of ‘dumb’ terminals to be connected to a mainframe or minicomputer over a single wired Ethernet connection. They were widely deployed at banks, automotive dealerships and insurance companies - anywhere a concentration of computer users was to be found. One of the main benefits was not having to run yet another cable all the way from the main computer to the new terminal location. As these terminal servers advanced, they allowed for another level of authentication to be implemented, via local username and password. Savvy administrators started finding ways to also connect printers to these servers and ultimately, terminal server designers added direct support for print queuing. This was a substantial timesaver, as now the printer could be placed near the user without a dedicated drop. Since some printers were installed remotely without associated terminals, it was a natural extension to create a terminal server dedicated to attaching printers to the network. With this, the print server was born.

With the explosive growth of microcontrollers in products, a plethora of equipment that had serial connectivity began to emerge. Asynchronous serial was a well-established means of communicating with a computer and with the addition of a UART and line driver, it became easy for a designer to allow a way to interface with their new products. The problem then was that serial only worked well over 50-100 feet, depending on data rate. Someone came up with the idea of using a terminal server to connect these products (alarm panels, industrial equipment, medical devices, etc.) to the network. Most of the available terminal servers had high port counts (16, 32) so it was rather expensive to use a terminal server on the shop floor to hook one or two machines to the network. Lantronix solved this problem by creating 1-, 2-, and 4-port ‘serial servers’ as they were first branded, later coining the term ‘device servers’.

Initially, device servers were external ‘box’ products consisting of a small plastic or metal enclosure, which contained the serial-to-Ethernet conversion circuitry, regulated power supply, led indicators, Ethernet connector (RJ45) and the requisite RS232 connectors. Over the years, these boxes have shrunk in size and added additional interface types, including RS422 and RS485. Originally, the software enabled basic serial-to-Ethernet conversion (often called ‘tunneling’). As technology advanced, the firmware became much more configurable and for some applications, became protocol-aware. This was important because if data was not properly packed into a TCP (network) packet, it could become fragmented when arriving at the other end of the connection. This fragmentation could cause timeouts and other bad behavior from products and software used to having a direct connection.

In the late 1990s, web servers were added to device servers, giving them a new way of being configured and for data presentation. At this time, OEM manufacturers inquired about embedding device server functionality onto their main boards. Small products specifically designed for being embedded were created. These dispensed with the power supply regulation and serial interface circuitry. They were ideal for integrating to a main board, requiring only logic level power and signals. True to device server technology, they handled all of the tasks associated with getting a machine on to the network. It made networking easy for an OEM. In 2002, Lantronix changed the face of embedded device servers when they came out with the ultra-miniature XPort. This was a complete serial-to-Ethernet device with web server in a standard sized RJ45 jack (about the size of two sugar cubes). Millions of these devices have been deployed worldwide.

The next logical step was to branch out to additional transport types including wireless 802.11. Both embedded and external device servers have been produced utilizing the ever improving 802.11 standards. 802.15.4 and Zigbee have also benefited from the creation of embedded modules.

While many additional customer interface standards have been created, asynchronous serial is still the most common way device servers are connected to equipment, both in embedded and external applications. More recently, SPI has become interesting for high-speed transfers from an OEM main board to an embedded device server, as well as 802.3 wired Ethernet (“bridging” to 802.11 wireless).

Where are device servers headed? Physical size reduction is always foremost on the list. Also having faster ways to interface to an embedded device (i.e. SPI, USB, etc) to improve overall bandwidth. It has been imperative to add additional compute power and memory resources for tackling increasingly complex encryption and authentication methods. This extra ‘horsepower’ has obviated the need for a main processor in some embedded applications. It’s funny to think that just eight years ago, a device server might be able to execute 30 million instructions per second. Now it is upwards of 400 million! Additional I/O capabilities allow a wider variety of sensors and other peripherals to be attached to a device server. And of course, keeping up with the latest standards in wired and wireless communications is a must. Device servers have come a long way, but the goal remains the same: Handle all communication tasks from A to Z, whether wired or wireless, and provide a very easy-to-implement solution that keeps the customer focused on their core business and gives them a huge time-to-market advantage.