Multiple Applications using UDP Multicast Open (Read-Only) on same port

[TimS.]

Hello All,

I'm currently trying to build a system that has the following architecture:

RF Server = "A/D 1-9" -> "UDP Multicast (Write-Only) 1-9"

Operator Workstation = "QTY(N) Data Display Apps that all need to independently access one of 9 UDP multicasts at a time"

Essentially, I have 9 antenna elements that all get digitized and broadcast via separate UDP multicast addresses/ports. On the receiving end I need to be able to have N number of Data Display applications where each one can select the antenna element that it wants to get data from. My current goal for N is 7 and the worst case scenario for data throughput is 3.75 MSps IQ rate to each display.

My question is whether or not it is possible to have multiple "UDP Multicast Open (Read-Only)'s" open on the same port but one per Data Display application? Also, are there any limitations with this.

On my local machine I've somewhat tested this with the "UDP Multicast Sender.vi" and "UDP Multicast Reciever.vi" example. I created a "UDP Multicast Reciever2.vi" as another application that is listening on the same Multicast Address/port as the original receiver. No errors are thrown when running both receivers and both receivers get the data string sent by the sender at the same time. Is this reliable proof that I can send A/D data from "PC" -> "Ethernet Router" -> "PC with N UDP receivers"? If so, that's great since it would be relatively easy to implement. Btw, I'm not concerned with occasional loss of data which happens with UDP.

If it does work, I'm also curious as to what takes care of data duplication. For example, does two apps subscribing to the same Multicast address/port make the router send two copies (thus increasing network traffic)? Or, does the Windows OS get a single UDP packet on the port and replicate it to the two independent applications?

Below (or attached) are the two methods that I was thinking about. If the multiple UDP readers doesn't work then I was thinking of doing a DataSocket "Data Distribution Layer" between the incoming UDP sockets and Data Display applications on the workstation. This would add quite a bit of memory/cpu utilization to the workstation PC but I know that the NI DataSocket Server can handle a single sender multiple receiver architecture.

 

Thanks,

Tim S. 

[charris]

Hello Tim!

I'm honestly not sure about the theoretical limitations of how many applications can simultaneously read data from one UDP port. How many readers do you foresee using?

As far as data duplication goes, you won't be increasing network traffic, since the broadcaster is completely independent from the receiver. Any duplication of data will occur on the client machine.

I'm not terribly familiar with how mulitple programs interact when accessing one UDP port, so someone jump in if this is off the mark, but I think your first implementation will probably work.

[TimS.]

Hi Caleb,

I actually spoke with an engineer here that took some Network communications training and he said that it should be possible. Like what you mentioned, the broadcaster is different than the receiver in that the router/switch that I will be using will just be forwarding packets onto the workstation at the workstations IP address and some dynamically assigned port. It will be the job of the OS's Networking code to take that incoming packet and serve it up on the UDP multicast port that I defined and to the number of apps requesting it.

So, the first implementation using UDP only should work but I'm still unsure about a limit on the number of apps getting data off the same UDP multicast port number. My goal is actually 7 apps but if I could do more then that would be great. I think with the worst case of 3.75 MSps IQ rate, I'll hit a memory or cpu bottleneck before the UDP limit.

Thanks for chiming in!

Regards,

Tim S.

[charris · Accepted solution]

Hi Tim,

The number of simultaneous apps getting data off of the same UDP port is likely going to be an OS limitation as well. If I had to guess, I'd say 7 applications should work fine. In fact, the memory/CPU bottlenecks probably are the limit on how many simultaneous readers we can have, especially since the capablities of PC hardware differ from computer to computer. I doubt that the OS has a hard limit.

[GSinMN]

Hello All,

  I realize this is a very old thread, but in the interest of not duplicating topics, I thought I would reopen it.

  I have a question about UDP multicasting, related to the ports.  If I have multiple embedded controllers, that all need to communicate with each other (there is no single sender) how would I set up the ports?  Would each controller have an individual local port, but use the same "send to" ports?  According to the multicast sender and receiver examples, this is not the case (but the examples may have not had this intended purpose).  Or, is UDP multicasting not the correct solution for this implementation?  Please advise. 

Working with Labview 2012, Veristand 2012Beta and PXIe8133 controllers.

Thanks,

GSinMN         

[TimS.]

Hello GSinMN,

I don't have a good answer for an N:N communication method but UDP would still be good for 1:N or N:1 as stated in this tutorial: http://www.ni.com/white-paper/12079/en. So...UDP can be used to create your own N:N archeticture. In my application I had a 1:N topology replicated 7 times (i.e. 7 multicast senders each on a different port with the potential for N receivers for each sender). My initial thought would for you to have each embedded controller be a sender on a specific port and also UDP read on every port but it's own. It could read it's own port as well but just ignore it. This would make the code the same for each controller and thus more portable.

I'd be interested in hearing any alternatives out there though!

Regards,

Tim Sileo

[GSinMN]

Good Morning Tim,

  Thanks for the response, and glad to see the original submitter is still around. 

  My initial thought was to have all controllers transmit to the same port number (similar to what you attmpted in your initial post), but after having experimented with some simple custom devices, I don't think that will work.  At first glance, it looks like Labview gets confused at the receive end, because it can't properly decipher the data.  I'm still in the preliminary stages with this though, and only sending simple numeric data.  Perhaps if I were to append the data with some type of identifier, the receiver may be able to differentiate between data from each controller.

  That being said, I was not aware you could listen to more than one port on a Multicast/UDP read at one time.  I'm curious to know how this is accomplished.  Do you have to set up a seperate refnum/session for each port, or can it all be done on the same refnum? 

Thanks,

GSinMN

[TimS.]

It's been a while since I worked on this and researched the UDP functionality. This was at my previous company.

If I remember correctly, I actually had a difference port for each sender but in my case it happened to be on the same PC. So, one PC with 7 asynchronous senders. In your case it would be one sender per PC but still multiple senders. My application on the receive end had the ability to launch multiple UDP readers that allowed for simultaneous connections to any sender (i.e. one connection to each of the 7 senders or even multiple connections to the same sender in addition to being able to connect to all 7).

You have to create a separate UDP connection for each port but like my app did you can still have multiple UDP readers connected to the same port on a single PC. The Network and OS Layer will take care of replicating packets and distributing them to all process ID's connected to that port. If I have the chance to do an example for you I will try but no guarantees. Wish I had the code from this application but that wasn't something I could take with me when leaving that position ;-).

-Tim

[GSinMN]

Hello Tim,

  It sounds like my best bet is to indeed setup a separate UDP connection for each port on the receiver.  Based on our application, the number of controllers will be predetermined, so I can have a fair amount of it hard-coded.  I think I should be able to make it work.

Thanks for all of your assistance. 

GSinMN 

[TimS.]

Hi GSinMN,

Had that chance at lunch time to do up a quick example. I've attached a LV2012 version. The example contains three senders on different ports in the "Main - Multiple Senders" VI. I made a launcher to spawn reentrant receivers that can be connected to various multicast ports configured prior to launching. Just run the Main Sender VI and the Launcher VI, configure readers to launch, launch them, and watch data fly in! Stopping the Sender VI will shutdown the readers. I also tossed in a title bar modification for each reader so that you can easily tell from the Windows Taskbar which front panels are connected to specific ports. If you have any questions about the code just ask.

I've run the sender(s) on my embedded controller, across a router, and to the receivers running on my laptop. In the below image they are all running localhost for testing:

-Tim