fix(vxi11): resolve Core port via TCP/111 portmapper GETPORT (#20)#55
Merged
Conversation
Physical VXI-11 instruments (e.g. Kikusui PWR801L) publish their portmapper on TCP/111 and assign the Device Core to a dynamic port. The client previously connected straight to a fixed port (1024) and timed out against such instruments. OpenAsync now issues a real PMAPPROC_GETPORT over TCP/111 to learn the Core port, falling back to the fixed port when no portmapper answers (e.g. ivi-cli's co-located gateway, which does not listen on 111). The GETPORT request/reply codec is extracted to a shared Vxi11Portmapper helper, reused by the broadcast scanner to remove duplication.
Verified against a real Kikusui PWR801L: its portmapper accepts TCP connections on 111 but never answers GETPORT there — it replies only over UDP/111. Switch ResolveCorePortAsync to a unicast UDP datagram (matching the broadcast scanner's transport) and parse the reply with the shared TryParseGetportReply. Unicast UDP is routed normally, so this also works across subnets.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Physical VXI-11 instruments publish their portmapper and assign the VXI-11 Device Core to a dynamic port. The client backend connected straight to a fixed port (
1024), which is closed on such instruments, sovisa queryagainst a::inst0::INSTRresource timed out.Change
OpenAsyncnow performs a realPMAPPROC_GETPORTover UDP/111 to resolve the Core port, then connects there. When no portmapper answers within a short probe window — e.g. ivi-cli's own gateway, which co-locates portmapper + Core on a single bind port and does not answer GETPORT on 111 — it falls back to the fixed port, preserving the existing gateway pairing (backward compatible).Transport note: a real Kikusui PWR801L was used to validate. Its portmapper accepts TCP on 111 but answers GETPORT only over UDP/111 — so the resolver uses unicast UDP (matching the broadcast scanner). The shared GETPORT request/reply codec is extracted into
Vxi11Portmapperand reused byVxi11BroadcastScanner(removing duplicated RPC code).Tests (TDD)
New
Vxi11PortmapperResolveTests:ResolveCorePortAsyncreturns the Core port from a UDP GETPORT reply.ResolveCorePortAsyncthrows when the portmapper is unreachable (refused/timeout).OpenAsyncconnects to the portmapper-resolved port (fallback intentionally dead).OpenAsyncfalls back to the fixed port when the portmapper is unreachable.Existing
Vxi11BackendTests/Vxi11EndToEndPairingTestsstay green (fixed-port constructor → portmapper disabled).Full suite green (
Category!=Integration), csharpier + analyzers clean.Docs
ADR 0029 §2 updated in-place: the "portmapper-at-111 deferred to v2" item is now marked shipped (UDP/111).
Closes #20.