EEZ Studio UDP Actions: Account for Socket Reuse by Port Number

Two EEZ Studio UDP actions that specify the same port can share an existing socket in the pinned Dashboard implementation. The reuse lookup is keyed by a port number, while address family and multicast membership are properties of the socket created earlier.

If one action appears to ignore its family or group setting, inspect the socket allocation path before treating the behavior as a network-routing failure. The UDP In and UDP Out documentation describe those settings. The shared registry is visible in udp.tsx at EEZ Studio v0.29.0, commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

This analysis does not establish any deployed socket's exposure, received traffic or operating-system behavior. No network socket was opened for this research.

UDP In creates once and reuses by port

The module maintains udpInputPortsInUse as a map with numeric keys. UDP In evaluates the requested settings and looks up the configured port in that map.

When there is no entry, it creates a socket with the selected udp4 or udp6 type, binds it and applies multicast setup in the relevant branch. It stores the socket and associated fields under the port number. When an entry already exists, it takes the saved server instead of creating a new socket from the later action's requested settings.

The key does not include address family, multicast group or local interface. Those differences therefore do not distinguish entries in this lookup. A second same-port action should not be assumed to create a separate IPv6 socket or add an independent multicast membership merely because its properties differ from the first action's properties.

Reuse also changes what initialization events can mean

After choosing the server, the action attaches error, message and listening handlers. Its seqout is propagated from the listening handler. A reused server may already have emitted its original listening event before the new handler was attached.

Do not infer that every activation will receive a fresh listening notification just because it acquired a server reference. Conversely, attaching another message handler to the same emitter can create more than one consumer of later datagrams. The exact effect needs an installed-build trace, including how often each action is activated.

This gives a useful diagnostic distinction: receiving messages and receiving an initialization continuation are different observations. A missing second continuation is not enough to conclude that the socket never bound, and repeated outputs are not necessarily repeated network packets.

UDP Out uses the same registry

The output action computes a lookup number from outport, then destination port, then zero. If that number is nonzero and present in the shared map, it reuses the stored socket. Otherwise it creates a socket and stores it in the same registry.

That makes the input and output actions coupled through allocation state. A source-port setting and a destination-port setting are not interchangeable network concepts, but this expression can select the destination port as the registry key when no explicit outport is supplied.

Before assuming a random-output configuration creates a new independent socket, inspect that branch and the entries already established by the project. Record both the requested destination and the actual local socket identity. A packet capture that shows the source port can answer a different question from a Flow property displaying the destination port.

Use a local allocation matrix

For a proposed diagnostic, reserve isolated local ports and harmless payloads. Compare a first UDP In activation, a second same-port activation and a separate-port control. Record socket creation versus reuse, effective family, bound address, received message outputs and listening continuations.

Only add multicast after the basic allocation behavior is clear, using an authorized test network. Change one requested setting at a time and verify actual membership rather than assuming property evaluation applied it to an existing socket.

If separate sockets are required, use an arrangement whose allocation identity actually distinguishes them. Do not work around an unexplained reuse issue by disabling host security controls or broadening production network exposure.

The pinned source supplies a precise investigation target: port-keyed reuse. It does not prove that every combination is faulty. It shows why reviewing each action's properties in isolation can miss shared state that determines which socket the action really uses.