UDP Parallel Read/Write

[gt8860a]

I have an application where I am trying to receive and transmit data using UDP on the same port.  Ideally, I'd like to have this functionality separated out into separate loops so that sending out data is not dependent on receiving data and vice versa.  The code I have written works fine on my RT system (cRIO VXWorks) and is able to execute these task in parallel but fails on my Windows XP machine.  I have attached a highly simplified version to illustrate the issue.

On the Windows machine, the UDP Read VI will terminate execution (even with a timeout of -1) if the UDP write VI is called and return error 66.  On my RT system, the UDP Read VI will continue to wait until it receives data (as expected), even if the UDP write VI is called.  Is this expected?  Anyway to get the code to execute the same way on my Windows machine?

Thanks,

Damien

PS. I've tried it on both LabVIEW 8.6.1 and 2011.

[Bob_Schor]

I was not aware you could use a single port for both sending and receiving!  Indeed, your example has two ports, but you only establish a single "Connection ID" for the local port.  Try setting up a connection ID for the remote port, and using one ID for "sending" and one for "receiving".

[gt8860a]

Hey Bob,

Thanks for the response.  I realize that a separate port can be used for read and write operations but in this case, the device I am communicating with requires a response from the same port it sent a message to, so this is not an option.

I also know that I could put the read and write vis in the same "while loop" and perform the operations serially.

My real question is: "Why am I able to perform these operations in parallel on my VXworks target but not on my Windows machine?"

[Bob_Schor]

---

@gt8860a wrote:

Hey Bob,

Thanks for the response.  I realize that a separate port can be used for read and write operations but in this case, the device I am communicating with requires a response from the same port it sent a message to, so this is not an option.

---

However, this is not what your code does!  It writes to "Remote port", yet reads from Local Port.  If you delete Remote Port and connect Local Port to the writer, it will work like a charm (or at least without error).

[gt8860a]

Hey Bob,

Thanks again for the response. I'm not truly concern about what the attached code does. Like I said in the original post, this is a simplified version of the code.

Have you run it on an RT target and windows target? If so, explain why one returns an error and the other doesn't.

Thanks.

[nathand]

---

@gt8860a wrote:
Have you run it on an RT target and windows target? If so, explain why one returns an error and the other doesn't.

---

Probably an implementation difference between Windows and VxWorks.  Seems somewhat reasonable that you can't listen and receive on the same UDP connection simultaneously; in this case, the write terminates the read operation.  It looks like the Windows call to open a UDP port includes a "Reuse Address" parameter, which would allow you to open two connections on the same port, but LabVIEW doesn't expose it.  I haven't found the right search terms to get a definite answer, but some internet searching did turn up other people having a similar issue in other programming languages, for example "the program throws an error when it tries to send to the same multicast IP/Port combination as it is listening to for hailing." (from http://forums.techguy.org/software-development/984644-udp-listen-send-simultaneously-alternative.htm...

One possibility is simply to ignore error 66 - don't halt the while loop when it occurs.  Performing the operations serially will also work.  If you have the port open, you won't lose messages sent to it, even if your code is not actively listening at the time the message is received.  The operating system will queue the message and the next UDP read will return immediately with the received message.

[gt8860a]

Hey Guys,

In case any of you are interested or if anyone else is experiencing the same issue, I finally had an oppurtunity to dig into this issue a little deeper.  The issue is more basic than just trying to read and write data in parallel using the UDP primitives.  See attached VI, run with highlight execution.

The attached VI represent a client application which uses "UDP write" to send a message to a server and "UDP read" to read a response from that server (it is actuallu a slightly modified version of a NI example).  Now, lets say the server goes down and the client is still trying to communicate.  The client should still send out its message using the "UDP write".  This operation does not return an error since UDP is connectionless and it doesn't care if anyone is listening.  The next function, UDP read, should wait for the full timeout and then return error 56.  However, if you run the code, you will see that it does not wait for the full timeout but rather it immediately returns errror 66.  This is the cause of the bug.  I have confirmed that LabVIEW running on a realtime system (VXworks) and running on MacOS does not exhibit this behaviour but rather both function properly, returning error 56 only after waiting for the full timeout period.  This bug is what causes my original code to error out even though a -1 is wired to the timeout of the UDP read (it just happens to be in parallel with the UDP write).  There is something wrong with the UDP read function on Windows system.  NI support has acknowledged this error on Windows systems and they are filling a corrective action request.  I'll post that number once I get it.

(Just for fun, disable the write operation and watch that the read function will wait for the timeout?)

[J.Harv]

I am about to implement this same thing.  The server module I'm communicating requires send/recieve on the same port.  I am hesitant to do this serially because I don't want to read to block the write and vice versa.  Seems the same logic the orginal poster had.

So I'm curious

--Does anyone know what the NI CAR number refered to here is?  I'd like to followup on the status.

--Did parallel communication on the same port ever work on Windows? Has anyone else done this?

--If done serially, is it true data coming in will queue until the read happens?  This would enable me to do it serially if needed.

Anybody reading this (not just gt8860a) with any related UDP experience, please chime in!

[nathand]

---

J.Harv wrote:

--If done serially, is it true data coming in will queue until the read happens?  This would enable me to do it serially if needed.

---

My comments in an earlier post are correct and applicable. Is there some reason you're doubting this? It's easy to test.

[J.Harv]

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.