A serial device server (also called a serial-to-Ethernet converter) connects legacy RS-232, RS-485, or RS-422 serial devices — such as PLCs, barcode scanners, weighing terminals, and SCADA RTUs — to modern Ethernet IP networks, allowing them to be accessed and managed remotely over TCP/IP. ORing serial device servers ([SERIAL_PRODUCT_MODELS]) support four service modes — Virtual COM, TCP Server, TCP Client, and UDP — each designed for a different type of serial-to-IP communication scenario. Selecting the correct mode depends on whether the host application uses COM ports or TCP/IP sockets, whether the serial server initiates or receives connections, and whether guaranteed delivery or real-time throughput is the priority.
Serial service mode comparison
The table below summarises the four modes to help select the right one for your application:
| Mode | Connection direction | Max simultaneous connections | Delivery guarantee | Typical use case |
|---|---|---|---|---|
| Virtual COM | Host connects to serial server (via COM driver) | Up to 5 | ✅ TCP-based | Legacy software requiring COM port interface |
| TCP Server | Host initiates TCP connection to serial server | Up to 5 | ✅ TCP-based | Fixed-IP serial server; host connects on demand |
| TCP Client | Serial server initiates TCP connection to host | 1 (to one host) | ✅ TCP-based | Remote field device pushing data to central server; NAT traversal |
| UDP | Connectionless — unicast or multicast | Multiple (multicast) | ❌ No guarantee | Real-time broadcast, display boards, status updates |
Virtual COM mode
Virtual COM mode maps the serial server's physical serial port to a virtual COM port (e.g., COM3, COM4) on a host computer, making the remote serial device appear as a locally connected serial port to any application running on that host. The Virtual COM driver — installed on the host — establishes a transparent TCP/IP connection to the serial server and handles all data forwarding invisibly.
This mode is the preferred choice when:
- The host application communicates via a Windows COM port (e.g., COM1, COM2) and cannot be modified to use TCP/IP sockets directly
- Legacy SCADA software, HMI software, or custom serial communication programs are in use
- Multiple host computers need to share access to the same serial device simultaneously
Virtual COM mode supports up to 5 simultaneous connections, allowing multiple hosts to send or receive data from the same serial device at the same time. Each host sees the device through its own virtual COM port instance.
TCP Server mode
In TCP Server mode, the serial server is configured with a fixed IP address and a specific TCP port number, and passively waits for incoming TCP connection requests from host computers. The host application — running a TCP/IP socket client — initiates the connection by connecting to the serial server's IP address and port. Once the connection is established, bidirectional data flows transparently between the host's TCP socket and the serial device.
TCP Server mode is suitable when:
- The serial server has a fixed, known IP address accessible from all host computers
- The host application can use TCP/IP sockets directly (no COM port driver required)
- Multiple hosts need to connect to the same serial device — up to 5 simultaneous TCP connections are supported
- Cross-platform compatibility is needed (Linux, Windows, embedded) — no OS-specific driver required
TCP Server mode is generally preferred over Virtual COM mode for new application development because it eliminates the driver dependency and works natively on any platform that supports TCP/IP sockets.
TCP Client mode
In TCP Client mode, the serial server actively initiates a TCP connection to a remote host (typically a data collection server or SCADA system). The serial server acts as the TCP client — it connects outbound to the host's IP address and port, rather than waiting for incoming connections. This reversal of connection direction is important in several scenarios where the serial server cannot accept inbound connections.
TCP Client mode is suitable when:
- The serial server is in a remote field location (e.g., a substation, roadside cabinet, or factory floor) and needs to push serial data to a central server
- The serial server is behind a NAT gateway or firewall that blocks inbound connections — the outbound connection from the serial server traverses NAT naturally
- The serial device is the data source (e.g., a meter, sensor, or RTU) and the server is the data consumer
TCP Client mode supports connection reliability features:
- TCP alive check time — sends periodic keepalive probe packets to verify the connection is still active. If no response is received within the configured period, the serial server disconnects and reconnects, preventing zombie TCP sessions.
- Idle timeout — automatically disconnects after a configurable period of no data activity. This frees server-side resources and ensures the serial server reconnects with a fresh TCP session when data resumes.
UDP mode
UDP mode provides connectionless serial-to-Ethernet data transmission without the overhead of TCP connection establishment, acknowledgement, or retransmission. Serial data received on the serial port is immediately forwarded as UDP datagrams to one or more configured host IP addresses, and UDP datagrams received from hosts are forwarded to the serial port.
UDP mode supports both unicast (one-to-one, single destination host) and multicast (one-to-many, multiple hosts receive the same data simultaneously using a multicast group address). This makes UDP mode the most efficient option for distributing the same serial data stream to multiple hosts without multiple TCP connections.
UDP mode is suitable when:
- Real-time data delivery is more important than guaranteed delivery — for example, live sensor readings, PLC status broadcasts, or display board updates where occasional packet loss is acceptable and retransmission delay would be disruptive
- The same serial data must reach multiple hosts simultaneously (multicast)
- Lowest possible latency is required — UDP eliminates TCP handshake and acknowledgement overhead
- Unidirectional data from a serial device needs to be broadcast to a monitoring system
For applications requiring guaranteed delivery — such as PLC command transmission, configuration data, or transaction records — TCP Server or TCP Client mode should be used instead.
How to choose the right serial service mode
Use the following decision guide to select the appropriate mode for your application:
- Legacy application using COM port (COMx)? → Use Virtual COM mode. Install the Virtual COM driver on the host to present a virtual COM port to the existing application.
- Host application uses TCP/IP sockets; serial server has fixed IP? → Use TCP Server mode. Simplest setup for new applications; no driver required; supports up to 5 simultaneous connections.
- Serial server is in the field, behind NAT, or must push data outbound? → Use TCP Client mode. The serial server initiates the connection to your central server, bypassing inbound firewall restrictions.
- Real-time broadcast, multicast, or lowest-latency is the priority? → Use UDP mode. Supports unicast and multicast; no TCP overhead; ideal for status broadcasting and display applications.
- Reliable delivery of commands or transaction data is required? → Use TCP Server or TCP Client mode — not UDP.
Industrial use cases by mode
Virtual COM — legacy PLC programming software
Many industrial PLC programming environments (such as Siemens STEP 7, Rockwell RSLogix, or older SCADA packages) communicate exclusively via COM ports. By deploying an ORing serial server in Virtual COM mode, a maintenance engineer can connect their laptop to the factory Ethernet network and access a PLC on the production floor as if it were locally connected via a serial cable — without modifying the programming software or its COM port settings.
TCP Server — Modbus TCP gateway
Modbus RTU devices (meters, drives, sensors) connected to a serial server in TCP Server mode are accessible to any Modbus TCP master on the network. The serial server translates incoming Modbus TCP requests to Modbus RTU frames on the serial port and returns the responses — acting as a transparent Modbus RTU-to-TCP gateway. Multiple SCADA workstations can query the same Modbus RTU device simultaneously via separate TCP connections (up to 5).
TCP Client — remote RTU data push to control centre
A water treatment RTU at a remote pump station sends meter readings and alarm status via serial (RS-485) to an ORing serial server. Configured in TCP Client mode, the serial server initiates an outbound TCP connection to the control centre's IP address and port, pushing data through the plant's NAT gateway without requiring inbound firewall rules. If the connection drops, the serial server's TCP alive check automatically re-establishes it.
UDP — real-time display board updates
A warehouse management system sends order picking instructions from a host server to multiple display boards simultaneously. Each display board is connected to a serial server configured in UDP multicast mode. The host sends a single UDP multicast packet to the multicast group address, and all display boards receive the same instruction simultaneously — more efficient than establishing individual TCP connections to each board.
Frequently asked questions
What are the four serial service modes on ORing serial servers?
ORing serial device servers ([SERIAL_PRODUCT_MODELS]) support: Virtual COM (maps serial port to host COM port via driver), TCP Server (waits for incoming TCP connections), TCP Client (initiates outbound TCP connection to host), and UDP (connectionless unicast/multicast). Virtual COM, TCP Server, and TCP Client support up to 5 simultaneous connections.
When should I use Virtual COM mode vs TCP Server mode?
Use Virtual COM when your host application communicates via a Windows COM port and cannot be modified. Use TCP Server when your application can use TCP/IP sockets directly — this eliminates the driver dependency and works on any OS. For new application development, TCP Server mode is preferred.
What is the difference between TCP Server and TCP Client mode?
In TCP Server mode, the serial server waits for the host to initiate the TCP connection. In TCP Client mode, the serial server initiates the connection to the host — useful for field devices behind NAT/firewalls, or when the serial device needs to push data to a central server without accepting inbound connections.
What is TCP alive check time and idle timeout in TCP Client mode?
TCP alive check time sends periodic keepalive probes to verify the connection is active — if no response, the serial server reconnects. Idle timeout disconnects after a configured period of no data activity, freeing resources and ensuring a fresh reconnection when data resumes. Both settings prevent zombie TCP sessions in long-running field deployments.
When should I use UDP instead of TCP?
Use UDP when real-time delivery is more important than guaranteed delivery — sensor broadcasts, display board updates, or multicast distribution of the same data to multiple hosts. For reliable delivery of commands or transaction data, use TCP Server or TCP Client mode instead.
