When an older device needs to connect to an Ethernet network, the first question is not how to plug it in but which protocol rule set to use.
A RS485 instrument is connected to a network. Data flows from the instrument through Ethernet cable or Wi-Fi and reaches the host computer or cloud platform. This transport work is handled by a Serial to Ethernet Converter, which forwards bytes from the network side to the serial side and back. It does not decide what format, what protocol, or what channel those bytes should travel on.
Protocol selection comes after the conversion step. Three options are most common: TCP, UDP, and MQTT. They are not a ranking of "which is better." Each fits a different set of conditions.
Two variables determine the choice. Neither lives in the hardware specification. The first is data volume and timing—how big the message is, how often it arrives, how badly a lost packet matters. The second is what the host software or cloud platform expects—Socket stream, Modbus TCP, or MQTT with JSON payloads.
The two variables meet early in the design phase and narrow the field quickly.
In TCP Server mode, the converter listens and waits for the host to connect. Reading from the serial device feels like opening a COM port—bytes arrive in order, every byte gets acknowledged, no missing packets. TCP Client mode reverses the relationship: the converter initiates the connection to the host. This setup suits situations where the host has a public IP and the serial device sits behind NAT or a firewall.
TCP carries a cost: the connection itself. Each handshake, each disconnect and reconnect takes time. A typical converter supports up to 16 concurrent TCP client connections. Beyond that, new clients queue. For a workshop with a few workstations and a handful of instruments, 16 connections is usually sufficient.
UDP skips the handshake. No connection to establish, no acknowledgments to wait for, no retransmission queue. A packet is sent, and if it arrives, great; if not, it is gone. The saving is protocol overhead—every byte on the wire is mostly payload.
The trade-off is straightforward: lost packets are not recovered. If a reading is missed, the next polling cycle will bring a new value. On a site with few instruments and tolerant monitoring software, losing a handful of packets rarely changes the outcome. UDP works when the data rate is high, the loss window is small, and the consequence of a dropped packet is acceptable.
MQTT sits on top of TCP and adds a publish/subscribe layer. The converter does not send data directly to a specific IP address. Instead, it publishes to a Broker, and anyone who has subscribed to that topic receives the message. One piece of data can fan out to three or four systems simultaneously—MES, a cloud dashboard, a notification service—without the converter needing to know about any of them.
This decoupling is the main benefit. Senders do not need to know receivers. Receivers do not need to know senders. Adding a new consumer means only subscribing to the right topic, no code change on the converter side.
MQTT carries complexity. A Broker must be provisioned and maintained. Topics and QoS levels need configuration. If SSL/TLS encryption is required for data security, certificates must be managed. For simple local monitoring with a single host, MQTT adds more moving parts than necessary. For cloud connectivity or enterprise integrations, it becomes the default choice.
When the host application reads raw Socket streams and expects a continuous byte flow, TCP or UDP is sufficient. MQTT introduces an abstraction layer that the host may not need. When the host speaks Modbus TCP, the converter only needs to perform Modbus RTU to Modbus TCP conversion with multi-host polling. TCP serves as the underlying transport; Modbus is the application protocol. When the host connects to a MQTT Broker directly and reads JSON payloads by topic, MQTT is the required path.
Small data volume + host reads Socket streams = TCP Server. The converter waits for connections. Up to 16 workstations can attach simultaneously, which covers a small production line or a single cabinet.
Small data volume + host has no public IP = TCP Client. The converter reaches out to the host, eliminating the need for the host to expose an open port.
High-frequency polling + occasional packet loss is acceptable = UDP. Packets arrive faster with less overhead, and a dropped reading is recovered in the next cycle.
Cloud platform ingestion + multiple consumers = MQTT. Data flows into the Broker in JSON format, and cloud, MES, and reporting tools each subscribe independently from a single serial endpoint.
The selection process starts with three questions: how much data is being transferred, how critical is real-time delivery, and what protocol does the host or cloud expect. Once these are answered, the choice narrows to a single path. Checking the converter datasheet for MQTT support, maximum TCP Server connections, and SSL/TLS capability confirms the final decision.
Serial to Ethernet Converter bridges hardware and network. Which prot
