[Hamlib-developer] [Fwd: An alternative to the hamlib/xmlrpc-c++ modificatlion]

[Nate B. <n0...@n0...>]

----- Forwarded message from w1hkj <w1...@gm...> -----

Date: Sat, 22 Aug 2026 08:36:42 -0500
From: w1hkj <w1...@gm...>
To: "Joseph A. Counsil" <jos...@gm...>,  Nate Bargmann
 <n0...@n0...>
Subject: An alternative to the hamlib/xmlrpc-c++ modificatlion

I directed ChatGPT to create an alternative to the proposed fix for the
latency issue with JS8Call.

"*Yes. I think it is worth having a credible legacy-preserving alternative
ready for exactly that reason.*

*I reviewed the 4.7.2 legacy path again, and there are three weaknesses
that stand out. First, read_transaction() reads the HTTP response
line-by-line and decides the response is complete when it happens to
encounter </methodResponse>; second, write_transaction() unconditionally
calls rig_flush() on the persistent network socket before each request; and
third, flrig_transaction() explicitly ignores the return value from
read_transaction() and continues parsing anyway.*

*That is a fragile combination for a persistent TCP connection. Hamlib's
lower-level read_string() is itself timeout- and packet-arrival-sensitive,
and the source even contains a special FLRig-specific experiment for
</methodResponse>, suggesting response framing had already been recognized
as unusual.*

*I prepared an experimental legacy hardening patch that keeps the existing
socket/XML implementation rather than replacing it:*

*Download the Hamlib 4.7.2 legacy hardening experiment*

*The proposed change does four main things:*

   -

   *reads the HTTP headers and uses Content-Length to consume exactly one
   complete XML-RPC body;*
   -

   *removes the unconditional rig_flush() before every request, because
   once responses are consumed precisely, that flush is unnecessary and can
   race late-arriving bytes;*
   -

   *propagates read_transaction() timeout/I/O/protocol errors instead of
   ignoring them;*
   -

   *does not automatically retransmit a failed RPC, because a setter such
   as PTT may already have executed.*

*The basic model becomes:*

*write request
     ↓
read HTTP status + headers
     ↓
parse Content-Length
     ↓
read exactly N body bytes
     ↓
validate XML-RPC terminator
     ↓
parse result*

*rather than:*

*flush socket
write request
read line
read line
read line
...
hope </methodResponse> appears
ignore read error*

*I would be careful how we present this to Nate: this is a reasoned repair,
not yet a proven fix. The xmlrpc-c++/Curl implementation has the real
FT-817 validation. This legacy patch needs the same Joe stress/recovery
test before we can claim equivalence.*

*If it passes, however, the committee would have a very attractive choice:
retain Michael Black's original architecture, but harden its HTTP framing
and error handling; or use the already validated xmlrpc-c++ transport as
the preferred path. That would make the upstream discussion much less
binary."*

Joe and I need to test this independently before it is ready as an
alternate path for the maintainer-list's consideration.

The patch is attached.  Joe, please apply to a fresh hamlib-4.7.2, and use
the JS8Call-improved / instrumented executable to discover any timing
issues.

73, David



----- End forwarded message -----

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819