UDP Parallel Read/Write

[gt8860a]

Hello J.Harv,

As far as I know, the issue has not been fixed.  the CAR number was 350706.  Maybe an NI moderator could check on the status for us.

[nathand]

---

@J.Harv wrote:

Nathand - Really more curious about the CAR and parallel reads/writes and what is the best way to do that.  It makes more sense for the application....but thanks for the reply anyway.

---

Depends on your application. If you need to wait until the UDP data arrives in order for execution to continue - for example, the UDP data is a command to execute - then I would wrap the UDP Read in a VI that ignores error 66 and goes back to waiting for data if that error occurs. The downside to this is that if you close the UDP reference somewhere else in order to terminate the read, then you'll need some other way to indicate that the connection is closed so that you don't continue trying to read. You could do this with a notifier.

If you application only needs to check for new UDP data periodically, then just do a UDP read in that particular spot in the code and let the operating system buffer the received packets.

[Prickly_Pear]

I check the CAR ID. The report says that our R&D staff investigated the problem, but they were not able to consistently reproduce error 66 in Windows 7 or Windows Vista. Because of that, they stopped the investigation. It is likely that the problem is more complicated that just operating system behavior.

I think that the advice given by nathand is very good.

Jeremy P.

[gt8860a]

Hello Jeremy,

I appreciate you taking the time to investigate the status of the CAR.  While Nathand does provide possible work arounds in his post, he also does point out that there are limitations to the workaround, the big one being how to detect when an expected error 66 occurs versus an unexpected error 66.

When I originally posted to the forum, I was mainly looking for confirmation of the bug, not ways to workaround it.  If it didn't come off that way I apologize. 

In my opinion, work arounds are great when the bug is identified in a current release of LabVIEW.  But when it has been 2 years and 2 LabVIEW releases later, it's disappointing that we still have to use a workaround.

Also, if the code you are using will be deployed to multiple different platforms (Windows, Pharlap, VxWorks, Mac OS), it is inefficent to have to maintain two different versions of code in source control just to handle this bug on the windows implementation. 

[J.Harv]

Hello everyone-

I coded up parallel read/writes in different loops, split the open wire to each loop, etc.  and I didn't see any errors.  I think I got spooked reading the forum before I tried it, or maybe I'm not doing what the original poster was trying....? 

If anyone is interested, my test code is attached (LabVIEW 2013).  Basically, data starts in "1" gets sent to "2" and on to "3".  For the final code, my app will be man in the middle between 2 other systems and two types of data, 1ea. going in a particular direction.  Requirement is 3/server will send back to the same port it received from.  That's where the parallel write/read on one port comes from. 

Thanks for the help here.

-JH

[gt8860a]

Run attached.  On my PC, in LabVIEW 2013, I still get an error.  Why?

I already went through this with Bill Everson back in 2012.  Is it possible for you to get his notes. 

Perhaps it would also be more appropriate to take this conversion offline from the forums.

[J.Harv]

gt8860a-

This may have been addressed already, but I see some problems with your code (and I do see the LabVIEW bug). 

You are using port 0 with UDP which will assign a random port, and then you're writing to a specific port, which isn't likely the same one.  Addressing either of those will allow the code to run without error.

If you assign a specific port to open and then write to that port, no problem.  The write in the posted example was to port 64324, so use that in the open. 

Alternatively, if you make the write go to whatever the random port that gets opened with 0, that works too.  I don't know how to programmatically determine which port an open with 0 will assign though.  I used Start>cmd>netstat -a -n to determine which port was being opened, put a breakpoint in the code, then made the write port a control and adjusted it based on what I saw from netstat.  This also worked, no errors.

As for the error 66, I do think there is a bug in LabVIEW (maybe Jeremy P can either explain what's happening or pass along to R&D by re-opening the CAR with new notes). Even if I set the read timeout to -1 or a really high number, it will error out immediately with error 66 which says the system closed the port  (according to KB linked below). I'd have expected it to wait there for data in the system read buffer. The weird thing is that even after the read and error, I can verify the port is open using netstat....? 

http://digital.ni.com/public.nsf/allkb/D90C4F99C1EF3F6A86256E4A0080A120

Hope that help.

-JH

Edit:  I am using Win 7 - 64bit. 

[gt8860a]

Hello J. Harv,

I appreciate you looking into this issue.  I will try to address some of your comments below.

---

@J.Harv wrote:

You are using port 0 with UDP which will assign a random port, and then you're writing to a specific port, which isn't likely the same one.  Addressing either of those will allow the code to run without error.

---

 This is completely acceptable practice.  The port wired to the UDP open.vi and the UDP write.vi are rarely the same port number.  Wiring a 0 to the UDP open vi tells the operating system to open a UDP port for communication but that you do not care which port, just any available port.  The applciation will then use that port to communicate with other applciations or computers.  The UPD Open port is the port that the local machine machine (or application A) will use to talk to a remote machine (or application B).  The port number wired into the UDP write block is port number the the remote machine (or application B) is listening on.  For example, Computer A calls the open UDP.vi with a 0 wired to it and the operating system provides it with port 45678.  Computer A then uses port 45678 to communicate with Computer B.  Computer B has an IP address 1.1.1.1 and has port 54321 open for communication.  When applciation A uses the write UDP data.vi, it will wire 1.1.1.1 to the IP address and 54321 to the port.  That says to use the previously opened port on computer A (45678) to communicate to the machine at 1.1.1.1 at port 54321.

---

@J.Harv wrote:

If you assign a specific port to open and then write to that port, no problem.  The write in the posted example was to port 64324, so use that in the open. 

Alternatively, if you make the write go to whatever the random port that gets opened with 0, that works too.  I don't know how to programmatically determine which port an open with 0 will assign though.  I used Start>cmd>netstat -a -n to determine which port was being opened, put a breakpoint in the code, then made the write port a control and adjusted it based on what I saw from netstat.  This also worked, no errors.

---

Specifying a specific port number to the UDP open.vi does not resolve the error, the UDP read.vi still terminates immediately rather than waiting.  Don't get hung up on the fact that is 0 is wired to the open UDP.vi.  That is accepatble practice.  (as an aside, if you desire to programatically know which port was opened when a 0 is wired to the UDP open, wire an indicator to the terminal labeled "Port" on the right side of UDP open.  It will return the port that was opened).

[gt8860a]

---

@J.Harv wrote:

As for the error 66, I do think there is a bug in LabVIEW (maybe Jeremy P can either explain what's happening or pass along to R&D by re-opening the CAR with new notes). Even if I set the read timeout to -1 or a really high number, it will error out immediately with error 66 which says the system closed the port  (according to KB linked below). I'd have expected it to wait there for data in the system read buffer. The weird thing is that even after the read and error, I can verify the port is open using netstat....? 

http://digital.ni.com/public.nsf/allkb/D90C4F99C1EF3F6A86256E4A0080A120

Hope that help.

-JH

Edit:  I am using Win 7 - 64bit. 

---

Sorry, I hit post too accidently.  Please don't get caught up in the fact that the example I submitted has a 0 wired to it.  This is completely acceptable practice.  I do not know what type of services are running on your machine so if I had hard wired a port number, it is possible that that port would have already been in use on your machine.  That is why you wire a 0.  The entire problem circles around the fact that the UDP read errors out rather than waiting for the timeout wired to it. 

[J.Harv]

I understand the intention now.  My suggestions do fix the code if you were intending that VI to be stand-alone/self contained loop back.... i.e. write out and read same data back all within that VI.  However, in a larger application it's likely you want to write out somewhere else and then wait for them to read the data and source from the header  and send something back to that port.  Hence needing read to wait, but it doesn't work due to the bug.  I don't see what else can be done.  The more I think about this, I may run into this same thing shortly.  Hope not, but we'll see once I get into implementation and testing. I hope NI has some answers to help.

-JH