Multiple Tx Packets can not share a socket

[dwhite65]

If two or more Tx Packets are configured with the same IP Address and Port, the UDP Open will throw Error 60 when deployed because the engine calls UDP Open for each Tx Packet and the UDP Open reports that the socket is already in use.
Users should be able to define multiple Tx Packets that share the same IP Address and source port.
An additional requirement is to allow for a mix of Tx Packets that share the same IP Address and other Tx Packets on alternative ports while managing the UDP Open correctly for these combinations.
There are two ways this could be improved:

1. Execution only: Create a session manager wrapper around the UDP Open and UDP Close that keeps track of the used IP Address and Port settings along with the connection ID reference from UDP Open. If UDP Open is subsequently called with an already claimed IP Address and Port, simply return the existing connection ID reference instead of trying to open a new socket.
2. Handle multiple Tx Packets with the same settings in a similar manner to the Duplex handling when an Rx Packet and Tx Packet share the same settings. The Find Duplex.vi searches for matching Tx Packet and Rx Packet IP Address and Port settings and creates a Duplex Packets structure with the matches. This is used during execution to skip the call to UDP Open and reuse the Connection ID. Multiple Tx Packets with the same IP Address and Port could be handled in a similar manner. This option would allow a user interface confirmation that the user intended to reuse the existing socket which may not be necessary.

[ryanvallieres]

@dwhite65

Thank you for the feedback and suggestions! I agree that this is a useful feature set to have, however I haven't run into it in requirements for test/simulation before. If I had to pick, I'd do something akin to the duplex methodology and avoid any changes needed to the configuration side of things. However, this kind of feature brings a few questions to mind that may be important to consider:

• Due to the highly parallel nature of the UDP Custom Device, I've tried to reduce cases where the arbitration of blocking resources can occur. When there is two different sending thread trying to use one socket, there may be additional jitter in some application designs that was unintended. It may be necessary to warn the user about this.
• With multiple senders on a single socket, it's almost certain that someone will want to assert the order each of these packets are sent in. While not impossible, the present architecture does not allow for this easily. Is this something you had in mind for longer term support?
• Having multiple readers on a single socket is probably never going to happen. Too many race conditions can occur in the present implementation and it's difficult to ensure any given reader is looking at the correct receive data without coupling the packet definition to the contents of the payload.

Thoughts? I won't be able to implement this quite yet, but when it does come around, I'll likely be handling a few other edge cases at the same time. Of most note is cases where a socket is not yet available on a system (the cable is not attached, but the physical NIC is configured).

[dwhite65]

-I agree with the idea of doing is similar to duplex and not requiring the user configuration to change. Keep in mind that I needed multiple tx packets and one rx packet (duplex) all on the same port.
-Good points about conflicting transmits and sequencing. In my use case, two messages were configured for one-shot to start and stop the session and a third message was set for periodic transmission but in Toggle mode and only enabled after the start was sent. I can imagine a use case where multiple tx packets would need to be sent at different rates but would hope they could be asynchronous.
-With respect to multiple readers, I actually had a use case for this. I consider it 'multiplexing' where one channel (message ID) in the 'header' of the rx data determines the definition (data type and receive channels) of the remaining data in the packet. The existing CD doesn't allow for this but it if we ever added that, I think it would be one UDP Read in the engine that would dispatch to one of many rx channel definitions based on the 'message ID' channel.