(plc4x) 01/02: doc(plc4j/eip): say what is actually known about correlating an EIP response

[sr...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

sruehl pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/plc4x.git

commit dc9e40cdd4567f28a41be7c87e891c4b9140abd4
Author: Sebastian Rühl <sr...@apache.org>
AuthorDate: Tue Aug 25 09:08:19 2026 +0200

    doc(plc4j/eip): say what is actually known about correlating an EIP response
    
    The note on the Correlator claimed the senderContext field exists to carry a
    correlation value. That is not something this repository establishes anywhere: the
    mspec declares it as eight bare bytes, no documentation mentions it, and no driver in
    any language reads it back - so whether a device returns it unmodified has never been
    relied on here. Keying correlation on it would want confirming first, because a device
    that does not echo it would fail every request where send order works today.
    
    It also left out the other candidate, which is the more solid of the two: connected
    sends already carry a sequence count per request and already increment it, and the
    count that comes back is simply never looked at.
    
    And it implied one of them would be enough. Reads and writes run unconnected in two of
    their three modes, so the connected sequence count would leave those two exactly as
    they are.
    
    No behaviour change; the note now says what is known and what is assumed, since the
    next person to pick this up would otherwise start from a claim this repository cannot
    support.
---
 .../org/apache/plc4x/java/eip/base/EipTcpConnection.java  | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/plc4j/drivers/eip/src/main/java/org/apache/plc4x/java/eip/base/EipTcpConnection.java b/plc4j/drivers/eip/src/main/java/org/apache/plc4x/java/eip/base/EipTcpConnection.java
index ae39fb346f..38c692fc00 100644
--- a/plc4j/drivers/eip/src/main/java/org/apache/plc4x/java/eip/base/EipTcpConnection.java
+++ b/plc4j/drivers/eip/src/main/java/org/apache/plc4x/java/eip/base/EipTcpConnection.java
@@ -422,10 +422,17 @@ public class EipTcpConnection extends PollingSubscriptionConnectionBase<EIPConfi
      * that request's, nothing is lost. When it was the next request's, that request times out -
      * which is a failure someone is told about, rather than a number they trust.</p>
      *
-     * <p>Telling the two apart needs a correlation value the device echoes back. The senderContext
-     * field exists for exactly that and is currently the same eight bytes on every request; using
-     * it properly means changing what goes on the wire, and the scripted driver testsuites assert
-     * those bytes.</p>
+     * <p>Telling the two apart needs a value that comes back with the response, and there are two
+     * candidates, both of which this driver sends and then ignores. Connected sends carry a
+     * sequence count in their ConnectedDataItem, incremented per request; the response's count is
+     * never looked at. Unconnected sends have only the eight-byte senderContext, which is the same
+     * bytes on every request - and whether a device returns it unmodified is not something anything
+     * here has ever relied on, so it would want confirming before correlation is keyed on it.</p>
+     *
+     * <p>Both would be needed to cover this: reads and writes run unconnected in two of their three
+     * modes, so the connected sequence count alone would leave the other two as they are. Either
+     * way it changes what goes on the wire, and the scripted driver testsuites assert those bytes
+     * with no way to exempt a single field.</p>
      */
     static final class Correlator {