Why Replies Can Arrive After FIN: TCP Half-Close Explained

A host has sent FIN, yet a capture still shows data coming back. That need not indicate a fault. The two sending directions of a TCP connection can end independently: I have finished sending does not mean you must stop sending too. To understand the result, separate the protocol’s end marker, the application’s reads and the action performed by the serial device.

One connection contains two independently progressing byte streams

Think of two people speaking on a telephone. One finishes speaking while the other still needs to answer. The analogy explains the directions, but TCP actually carries ordered byte streams. It does not understand words, commands or machine actions. Each direction has its own data and end condition; one endpoint’s end is not automatically the disappearance of both directions.

These two directions belong to the transport layer. They do not describe a switch port’s full-duplex or half-duplex configuration. Physical transmission, TCP connection management and application-message recognition are different layers. Similar terminology is not a reason to substitute one layer’s status for evidence about another.

An established connection therefore need not last forever, while an ended sending direction need not immediately disable reception. First establish who ended which direction, which program made that decision and what data have not yet reached the application.

FIN ends new data in its own direction

FIN is a control flag in the TCP header, not a terminating character inside a serial command. During normal closure, it marks an end position in that direction’s sequence. The receiver processes earlier data in order. Observing a segment carrying FIN is not permission to skip earlier bytes that have not yet been recovered.

An acknowledgement of FIN confirms that end position under TCP’s rules. It does not prove a controller executed the command or a serial transmitter finished sending its final character. Buffering, application processing and the field device’s response still separate network acknowledgement from business success.

FIN is not a command to power off the other endpoint, stop its serial port or delete a buffer. Application behavior after FIN depends on software and firmware. This article explains normal TCP semantics rather than promising one closure policy for every serial server.

Why a reply can follow the sender’s FIN

Suppose program A sends a request to program B and then ends only A’s sending direction. B can acknowledge that end, send its remaining reply in the still-open reverse direction and end its own sending direction later. A keeps reading while it waits, so it can receive that reply. This is a useful half-close scenario.

The request and reply illustrate direction, not a recommendation to close after every industrial command. Some applications use end of stream to indicate complete input. Others use lengths, delimiters or protocol fields, and many industrial sessions remain connected. Follow the actual application protocol before choosing a closure strategy.

TCP is a byte stream, and the number of packets is not fixed. Acknowledgement and data can be combined; retransmission and segmentation can also change the capture. Counting four packets mechanically is a poor acceptance test. Trace direction, ordering and each endpoint’s end position instead.

A zero-byte read is different from temporarily having nothing to read

For common connected-stream receive interfaces, with a normal nonzero receive buffer, a successful zero-byte result usually means orderly peer closure has reached the point visible to the application. It is different from no data being available right now. Nonblocking would-block results, timeouts and resets require their own handling according to the interface’s return values and errors.

Earlier data may still be waiting in the receive buffer. The application can read those bytes in one or more calls before observing end of stream. Receiving FIN does not automatically erase otherwise deliverable data. The queue in the illustration is a conceptual model, not the memory layout of a particular operating system.

One read is not guaranteed to return exactly one application reply either. Reconstruct the message according to the application protocol and check its length, sequence or status fields. A successful read does not by itself prove that the entire reply is complete, and EOF is not a universal success indication for every protocol.

Ending sends and releasing the socket are different jobs

Some platforms provide an operation that disables sending alone, such as Windows shutdown with SD_SEND. This has a different responsibility from closesocket, which releases the socket handle. The names help readers compare developer documentation; they are not a universal sequence of instructions for every platform.

Actual closing behavior also depends on the platform, options, unread data and error conditions. Distinguish an orderly end from an RST reset. The former expresses ordered closure; the latter resets the connection. Investigate resets using application errors and equipment logs rather than relabelling them as a normal closing handshake.

A half-closed connection is also different from a half-open one. Half-close can be a consistent state in which one direction has ended normally. Half-open commonly concerns one endpoint having lost connection state while the other has not noticed. A generic connection-fault label does not make all these conditions equivalent.

A serial server adds another link and another processing boundary

The Feichang website lists TCP operating modes for a single-port selectable RS232/422/485 serial server. That is a real product context. TCP support alone does not establish user control of half-close, a buffer-drain interface or the firmware policy illustrated here. Check the exact model, firmware version and documentation.

After network bytes enter a serial server, they may still await buffering, serial transmission and a field-device response. The time when the host stops sending has no automatic one-to-one relationship with completion of the instrument’s action. Network acknowledgement can arrive while the serial business process is still underway.

The reverse direction needs the same scrutiny. If an instrument has produced part of its response, whether the gateway continues forwarding, retains or discards later content depends on its actual session policy. Record observations on both the serial and network sides rather than relying on a single screenshot from one endpoint.

Gather evidence before repeatedly reconnecting

Start with a controlled request and record transmitted content, the expected reply, endpoint logs and capture timestamps. Identify which endpoint sent FIN or RST. Then compare how many bytes the receiving program read, how it interpreted the result and when the serial side received and transmitted data. Perform tests in an approved test environment or maintenance window.

If a read returns only part of a reply, preserve those raw bytes and continue or report incompleteness according to the protocol. Do not arbitrarily join later data from a new connection to the old response. The connection supplies a transport context; the business request also needs its own correlation. Recording both makes later analysis meaningful.

Define a waiting deadline and business-success condition in advance so a peer that never finishes does not cause indefinite waiting. A timeout does not prove that a command was never executed. Blind reconnection and retransmission can repeat a write or action. The protocol, idempotent design and device feedback must determine whether retrying is acceptable.

Remember three boundaries: FIN ends one sending direction; continued reception does not require waiting forever; and transport completion is not device-task completion. These distinctions make captures easier to read, improve communication with software teams and support verifiable acceptance conditions for serial networking.

Translated from the Chinese technical article: Read the original Chinese article.