Serial Device Servers and TCP Streams: Why Reads Split or Combine Messages

FCTEL Original Technical Article · FCTEL Technical Team
First published: 2026-10-04 · Last modified: 2026-10-04

After an RS232 or RS485 device is connected to Ethernet, the data returned by one read is not necessarily one complete message from that device. Splitting and combining messages often reflects different boundaries at the serial, network, and application layers rather than lost data. Understanding these layers makes it possible to build a reliable parser and locate the actual cause of a fault. This article explains general mechanisms. Supported modes, buffer behavior, and parameter ranges for a particular FCTEL product must be checked in its manual.

UART frames characters; the application protocol defines messages

A UART normally starts a character with a start bit, sends the agreed number of data bits, optionally adds parity, and finishes with a stop bit. The receiver reconstructs the character using its configured baud rate and format. Baud rate, data bits, parity, and stop bits must match. Incorrect levels, noise, or sampling errors can therefore cause character errors before networking becomes relevant.

With 8N1, an eight-bit byte also requires one start bit and one stop bit: ten bit times in total. At an illustrative 9,600 bit/s, a character occupies about 1.04 ms. This is a calculation example, not a product performance specification. It explains why useful byte throughput is lower than the nominal bit rate and why a buffer must accept arriving characters.

RS232, RS422, and RS485 describe different electrical interfaces and connection arrangements; UART describes character timing. None defines an application message by itself. A temperature query may contain several bytes. The equipment must separately define its message boundary through a length, delimiter, fixed format, or protocol-specified timing interval.

How a serial device server connects the two mechanisms

In the receiving direction, the serial interface first reconstructs bytes from electrical signals. Bytes enter a FIFO or software buffer. Packetization logic then submits a portion to the network stack according to its implemented length or waiting conditions. In the other direction, bytes leave the network receive buffer and are transmitted character by character by the UART. Each direction has its own buffering and scheduling.

An application message can span several serial receive batches, and one batch can contain multiple messages. Packetization trades waiting time against transmission efficiency; it does not automatically understand every higher-layer protocol. FCTEL public serial server documentation includes TCP server and TCP client operating modes. Whether a particular framing strategy exists, and the names and ranges of its settings, must be checked in the relevant model manual.

If a serial source continues sending while the uplink is blocked, buffer occupancy grows. TCP backpressure can limit network transmission, but cannot make a serial source without suitable flow control stop. Buffer capacity, supported hardware or software flow control, source behavior, and disconnection policy must be assessed together. Reliable TCP transport does not imply unlimited loss-free operation under arbitrary congestion.

TCP preserves byte order, not individual send boundaries

TCP presents a connection as an ordered byte stream. Sequence numbers identify byte positions; acknowledgments, retransmission, and flow control manage transport. A TCP segment is a network transport unit, while a business message belongs to the application protocol. One sender call does not require the receiver to obtain that same amount through one read.

Suppose equipment generates a six-byte message A followed by a four-byte message B. Successful transfer delivers the same ten bytes in the same order. The program might first read the first two bytes of A, then the remaining eight bytes, or read all ten at once. These are often called splitting and combining messages. By themselves, neither indicates corrupted data when the bytes are complete and ordered.

A read length depends on available data, receive buffering, thread scheduling, and interface arguments. Network segmentation also depends on the path and stack. An application cannot infer a business message length from a captured TCP segment length or treat every read return as one device response. When a connection closes, it must still handle complete received data and identify a trailing partial message.

A robust parser keeps state across reads

Maintain a persistent byte buffer. Each read appends data. The parsing loop first checks whether the header is available, then applies the protocol length or termination rule. Only a complete message should be validated and delivered to the business layer. Keep incomplete bytes for the next read; parse multiple complete messages individually without discarding the remainder.

For a custom protocol containing a synchronization marker, length, payload, and checksum, specify whether length includes the header, byte order, maximum permitted size, and checksum coverage. The diagram uses a fictional explanatory format, not a FCTEL protocol. Use the actual equipment protocol in a deployment, bound buffer growth, and reject impossible lengths. Define resynchronization after validation fails so that one bad byte does not misalign all following messages.

Delimiter-based protocols must handle escaping or delimiter values inside binary payloads. Fixed-length protocols must account for message types with different lengths. For timing-based serial protocols, distinguish an interval observed on the serial wire from the arrival time seen by a network application. Buffering and scheduling can change those intervals; the gap between TCP reads is not automatically the original serial inter-frame gap.

What packetization waiting time changes

A longer wait may combine more serial bytes before submission and reduce small-transfer overhead, but can delay the first byte. A shorter wait may forward bytes earlier and expose more partial messages to the application. Neither replaces correct parsing. Optimize business latency and integrity instead of demanding one message per read.

For request-response communication, consider device processing, serial transmission, server buffering, network round-trip time, and application scheduling separately. Set timeouts to cover these stages using controlled tests. Retry behavior must respect business semantics: determine whether write or action commands are safe to repeat rather than blindly resending indefinitely after a timeout.

Acceptance testing must cover content, timing, and recovery

Use recognizable sequence numbers and lengths in controlled tests. Cover isolated messages, back-to-back messages, fragmented input, long payloads, and short pauses. Run the same parser with deliberately different read sizes and verify the final message count, order, payload, and validation results. This provides stronger evidence than a terminal window that merely looks normal. Record examples as test inputs, not customer measurements.

Then test mismatched serial formats, uplink interruption, congestion, and reconnection separately. Distinguish serial character errors from network retransmission, buffer overflow from normal splitting, and business timeout from integrity failure. Record input byte counts, parsed messages, residual buffer contents, error causes, and recovery times; preserve the time references used for packet captures and serial logs.

When selecting a FCTEL serial device server, check its real interfaces, operating modes, flow control, and disconnect behavior. The key engineering distinction is that the server connects and transports data, the application protocol defines messages, and the parser reconstructs them across reads. Clear responsibilities prevent normal stream behavior from being mistaken for a hardware fault.

Technical references: IETF RFC 9293, TCP byte-stream service. Related FCTEL resources: Technical Articles and serial device server product documentation (Chinese).