Files
OpsLog/internal/rotator/dcu1
rouggy c293cc1391 fix(rotator): one held TCP session for a DCU-1 controller
The DCU-1 client opened a connection per command and closed it again,
"mirroring the gs232/pst/rotgenius idiom". That idiom is right for the
UDP backends beside it and wrong over TCP to an embedded serial server,
which is what an RT-21's Ethernet option is: the heading is polled every
500 ms while the antenna turns, GoTo sends two commands (AP1 then AM1),
Stop sends two more — each its own connect and close. Modules of that
class commonly accept a SINGLE session and need a moment to release it,
so the churn on its own looks like a controller ignoring half of what it
is told.

The socket is now kept between calls, one mutex serialises every
exchange — which also stops the poll and an operator command from
holding two sessions at once — and a write or read error drops it so the
next call redials. One retry after a redial, because a kept socket's
first write succeeds long after the far end has gone. Serial keeps
open-per-call: a COM port has one owner, and holding it would lock out
the controller's own software.

Keeping a session only helps if the client survives the call, and
dcu1Client built a fresh one every time, so it is cached per controller
identity. Two rotors on the same box share one client, which is the
point when one session is all there is. SaveRotators drops the cache:
a client left over from the previous host would hold the very session
its replacement needs.

Three tests against a fake controller that accepts one session at a
time: four commands share one session, a dropped session is redialled
exactly once, and a failed dial leaves nothing behind.
2026-09-10 22:42:34 +02:00
..