COM Port Redirector - Overview

Overview

The purpose of the redirector is to make the virtual COM port exhibit behavior that closely resembles that of a "real" COM port, i.e., a COM port driver for local serial port hardware. A virtual COM port itself is a relatively simple software mechanism that can be implemented by driver software similar to that of a conventional COM port driver. The main challenges arise in two other areas: the network connection to the device server and the behavior of the device server. These issues are described in the Technology section below.

Applications use a COM port redirector through one or more virtual COM ports that the redirector creates, as configured by the user. When the application opens the virtual COM port, the redirector makes an IP network connection to the device server at the specified IP address and TCP/UDP port number that corresponds to the remote device on the server. The COM port redirector then begins relaying the application data stream between the virtual COM port and the device server.

A redirector will typically permit creation of many (at least 256) virtual COM ports, but simultaneous use of hundreds of ports is often practically limited by a number of factors, including the memory and processor requirements of the redirector, limits on operating system resources, and the performance of the network stack.

A redirector for the Windows operating system is typically configured using a control-panel style graphical user interface for creating virtual COM ports, configuring settings for individual COM ports, and configuring global settings affecting all COM ports. The redirector GUI typically also includes displays of virtual COM port activity and various diagnostic aids.

The performance of a COM port redirector is determined by both its implementation and the network it uses to reach device servers. The performance drawbacks of simple redirector implementations can be largely addressed by kernel-level drivers that avoid context switches. Network packet loss or excessive packet times have dramatic effects on redirector operation and must be avoided.

COM port redirector software products have been offered by at least 30 vendors dating back to the early 1990s. Compatible networked device servers are currently available from a large number of manufacturers, with a heavy concentration of revenue in the top players, who are based in the North America and Asia/Pacific regions.

The equivalent software for a Unix/Linux operating system is commonly called a tty port redirector and most of the information on this page also applies to it.

Redirectors address a number of issues related to the network connection, including:

• Network protocol support that is compatible with the device server.

Most device servers are accessed with TCP connections (raw or using the Telnet protocol) to gain reliable delivery of the application's data stream in order of transmission. The majority of server manufacturers use public TCP protocols (raw, Telnet, or Telnet with RFC 2217 extensions). Several of the larger server manufacturers use proprietary protocols in addition to, or instead of, public protocols. Device servers for certain applications, such as those that use wireless networks, use UDP instead of TCP to gain performance at the risk of network reliability.

• Initiating the network connection to a device server and determining that server is ready to relay application data.

• Accepting inbound connections initiated by device servers running in client mode and routing the data stream to a waiting application.

• Flow control of the network data stream to prevent overrun of the server. (This is not the same as hardware/software flow control of the serial device itself.)

• Data rate limiting of the application data stream to provide the performance expected for the baud rate currently in effect on the virtual COM port, which is slower than the maximum speed of the network connection to the server.

• The timing effects of the TCP protocol stack, e.g. network packetization and Nagle's algorithm.

• Network connections through proxy servers.

• Management of the IP routing table to avoid loss of an IP route to the device server.

• Detection and handling of network interruptions, possibly with an automatic attempt to reconnect to the device server to resume application data flow.

Redirectors must also deal with the feature differences of networked device servers related to:

• Visibility and control of serial line signals such as DSR, DCD, CTS, DTR. The redirector may be able to sufficiently emulate these signals.

• Relay of BREAK signals.

• Settings for hardware or software flow control.

• Handling of the network connection when serial devices or modems disconnect.

Because COM port redirectors emulate COM ports on the operating system abstraction level, rather than hardware serial ports, old software which is not written to utilize the operating system, but instead interface directly with a serial microcontroller (hardware ports 0x3F8 to 0x3FF for COM1, for example) will not function with COM port redirectors.