UDP Stream API changes

  • 1
  • Idea
  • Updated 2 years ago
  • Implemented
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.
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 678 Posts
  • 205 Reply Likes

Posted 2 years ago

  • 1
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
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
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 678 Posts
  • 205 Reply Likes
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).
Photo of John G3WGV

John G3WGV

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