UDP Stream API changes

Eric-KE5DTO

As discussed in another thread (https://community.flexradio.com/flexradio/topics/smart-sdr-packet-loss), we will be changing the UDP Stream API slightly in order to help enforce the idea that each client needs it's own individual UDP port.

The way we have things setup right now, multiple clients can register the same ip/port with the radio and get streaming data (meter, display, audio, etc) sent.  This can cause confusion in the clients which use the packet counts from their own stream to perform network statistics on lost packets, for example.

In order to prevent this port collision, we are headed toward making the following changes:

1. We are going to set the ExclusiveAddressUse flag on the socket we open for streaming data in FlexLib.  This will prevent other processes from being able to bind to the same UDP port (on the same machine).

This means that if you have a program that assumes a port is open and only tries that port once (especially if it is using 4991), it will probably begin getting a socket error if the application is started after SmartSDR for Windows (or DAX or CAT).

Note that in FlexLib, we use logic to try the next port up (4992, then 4993, etc) until we find a port we can use.

2. We are going to change the radio logic so that a UDP port must be specified before any streaming data will come out.  Today, it just sends data out on the default port (4991) if one hasn't been specified.

Note that we will also be optimizing some of the streaming data (meters, I'm looking at you) so that clients that don't need this information won't use the bandwidth unnecessarily.

3. The radio is going to check to ensure that a specified IP/port doesn't match an existing client's ip/port settings.  In other words, we will enforce using different ports on the same machine at the radio.

We look forward to hearing your feedback on this from those that are using the API.

John G3WGV

Hi Eric,

Thanks for engaging with us on this. The changes you are proposing won't cause me any difficulties as far as I can tell and seem very reasonable. Presumably any attempt to subscribe to UDP data streams will get an error response if client udpport has not been sent?

As a thought, could the API server send the next free UDP port to the client somehow? For example in the discovery packet/on request/on initial TCP connection? That would save a bit of messing about testing UDP ports.

73, John

Eric-KE5DTO

We were actually going to handle it separately from the subscription logic, but that is a good question.  I'll talk with the team here about that.

Unfortunately, the radio can't really give a good suggestion for which port to use since that is client specific information.  This depends on the applications running and the platform on which they are being run.  So that really has to be handled by the client (finding an open UDP port and claiming it by binding to it).

John G3WGV

Hmmm good point. You're right of course, the server can't know what UDP ports the client platform is using. Silly me!