LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Read and Write in parallel

Solved!
Go to solution

Hello Everybody,

 

I got a question regarding parallelism in TCP Connections.

 

I know that it is possible to read and write on the same connection ID .

So if will ReadTCP and WriteTCP block each other if using the same TCP connection ID?

Or to ask more specific if I run two while loops in parallel, with one loop calling WriteTCP and the other one calls ReadTCP,

will one of the loops delay (or even block) the other if both loops call their TCP VI at the exact same time?

 

System is Windows 7 and Labview 2012.

 

 

Regards ,

Sebastian

 

 

0 Kudos
Message 1 of 9
(7,332 Views)
Solution
Accepted by SBach

They are perfectly parallel.  Just write into one and read from the other.  There is no conflict.

See my TCP articles for details.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 2 of 9
(7,322 Views)

So if will ReadTCP and WriteTCP block each other if using the same TCP connection ID?

 

The WRITE TCP does not really block - it will take your data and stash it somewhere, until it's ready to be sent.  That's usually only a few microseconds, if the connection is indeed alive.

 

The READ TCP will block only if you tell it to, by using a timeout.  If you ask it to wait for a CRLF, for 1000 mSec, then it will block you.  

 

I quite commonly use a timeout of zero, meaning "just check if the message is there yet", and then treat an error 56 as "no" and error 0 as "yes", and anything else as "error"..

 

But even if you use a timeout of 100000 mSec, you can write to the connection from some other thread while it waits, and the data will go out on the wire.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 3 of 9
(7,318 Views)

In Windows Based TCP system you can have up to six sessions running on one ID at one time.  this mean out side your loops open your sessions, or inside your loops Open, Read/Write, close every time.  I don't know what toolkit you are using to do your TCP communication but they are all pretty much the same nuts and bolts.  the delay function only retries if it is unable to connect not denied so use two session to read/write in parallel loops Mean you need two Open TCP Connections and Two Close TCP connections.  If you are using a SUB VI to do the actually read/writing that is a better practice then just feeding wires through a loop just make sure that you are open and closing your TCP connection in that subVI.  also I am not sure you can run Multiple instances of a the same SUB VI I've never tried so watch for problems there.  

 

 

Always looking to do more with less code,

 

Mark R 

0 Kudos
Message 4 of 9
(7,313 Views)

Thanks Steve,

 

for your quick reply.

 

"There is no conflict"

Thats exactly what I hoped for.

 

Also thanks for yout further explanaitions regarding the timeouts in read and write.

 

Regards ,

Sebastian

 

0 Kudos
Message 5 of 9
(7,302 Views)

Thank you too, Mark.

 

 

Regarding the parallel running of two sub VIs: It is possible if you configure the VI  for reentrant use with prealocated memory.

To do so:

1) right click the VI Symbol in the upper right corner of your Frontpanel

2) choose "properties" from the context menu.

3) Select "execution" from the dropdown menu

4) set the selector on the leftside of the dialog  to "reentrant use with prealocated memory".

5) close with [ok]

 

Now each instance of that Vi has it own junk of memory and runs in parallel to other instances of the same  VI, as long as your system can handle it.

 

Regards,

Sebastian

 

 

0 Kudos
Message 6 of 9
(7,297 Views)

You can read and write in parallel, but in the case where I have a query/response structure in my TCP server, LabVIEW doesn't serialize the write/read for the query/response if I try to do so on the same connection.

 

So I have:

 

TCPOpenConnection

TCPWrite

TCPRead

TCPWrite

TCPRead

...

TCPCloseConnection

 

The TCPReads are not guaranteed to arrive after the previous TCPWrite and there is no way to block the next TCPWrite.

 

I had hoped that wiring either or both the Connection ID and error cluster in series would serialize the execution but it does not.

 

The only way I can see it works is to open and close a new connection for every query/response cycle. This is supremely wasteful, slower, and loads my TCP server (and LabVIEW?) with continuous new threading for each new port connection, e.g.:

 

TCPOpenConnection

TCPWrite

TCPRead

TCPCloseConnection

...

 

Is there not a better way to implement a query/response paradigm using TCP?

 

---

Michael Mc

0 Kudos
Message 7 of 9
(6,210 Views)

Is there not a better way to implement a query/response paradigm using TCP?

 

There's always a better way.  A better way to show what you're talking about is to include a snippet of your code.

 

It's perfectly OK to do a Query/response using TCP.  My favorite way is to use a state machine - then I don't have to tie up a thread waiting on TCP things.  But there are other ways.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 8 of 9
(6,206 Views)

@mmccullo wrote:

You can read and write in parallel, but in the case where I have a query/response structure in my TCP server, LabVIEW doesn't serialize the write/read for the query/response if I try to do so on the same connection.

 

So I have:

 

TCPOpenConnection

TCPWrite

TCPRead

TCPWrite

TCPRead

...

TCPCloseConnection

 

The TCPReads are not guaranteed to arrive after the previous TCPWrite and there is no way to block the next TCPWrite.

 


Then your device is doing something that you don't account for in your TCP Read! Basically on a TCP connection you have two buffers, one outgoing and one ingoing. The outgoing buffers whatever you put on the connection line through TCP Write and the incoming buffers whatever comes from the remote side until you retrieve it with TCP Read.

 

If your device uses for instance CRLF as end indication for a message then you should use TCP Read to read with that mode. And you need of course to read the entire message that the remote side sent after you sent it a command with TCP Write. If you don't the next TCP Read will simply retrieve what is still left in the incoming queue, plus possibly some data that occurred from  your second TCP Write command. It's not that TCP Read doesn't occur in synch with TCP Write, just that whatever your previous TCP Read didn't retrieve from the incoming buffer, will be retrieved with the next TCP Read.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 9
(6,193 Views)