TCPListen Connection Poblem

[Rokot]

We have an application on an ECU that sends data via TCP (client 192.168.0.1). The LabVIEW application on the PC (server 192.168.0.128) listens with TCP listen and reads data after the connection setup.
Problem: The connection is not built directly in the VI, see Wireshark image.
The # 1 client SYN -> # 2 Server ACK / SYN -> # 3 Client ACK is fine, but it then teh TCP buffer is slowly cleared.
The buffer is full after 2.8 seconds at # 306. After a further 2 seconds, a stable connection is established from # 348, so that it is read correctly.
In the VI comes also from that time a connection ID out of the TCP Listen out and is read with TCP Read continuously.
What can cause TCPListen not to reveal the connection directly?

LabVIEW 2012 SP1 32bit on Windows 7 64bit

[nathand]

The problem is not with TCP Listen, but with TCP Read. You are asking to read 300 bytes, but probably not sending that many. The Timeout input defaults to 25000ms when not wired, and you haven't wired it. As a result, your code waits up to 25 seconds to read 300 bytes, and at the end of 25 seconds, it returns whatever data is available if there are not yet 300 bytes. Then the loop repeats, same thing happens again.

If you are sending less than 300 bytes, you should either set the length to the actual amount of data you expect to read, or use a shorter timeout or a different TCP Read mode, depending on what is appropriate for the data you expect to receive.

[Rokot]

No, the time of 4.7 seconds is the time that the TCP Listen needs to connect, see this pictures .

[nathand]

The code in your picture proves nothing, because TCP Listen waits forever by default. You could start it up and wait several hours before opening a connection to it from the remote system. Your test code would then tell you that TCP Listen takes several hours to complete; would you believe that?

[Rokot]

Of course, but that ist not the point. The ECU sends the SYN before. When I start the Read.vi the we see at #34 35 36 SYN->SYN/ACK-ACK, but the Listen takes up to 5 seconds to get the connection id although the tcp buffer is written.

[nathand]

Try changing the number of bytes to read to 1, or the mode to immediate, and see if it makes a difference. I realize you don't believe me that the problem isn't the TCP Listen, and I could be wrong, but try making those minor changes (one at a time, not at the same time) to your test program and see if it helps.

[Rokot]

I tested it on an other PC and there is the time of 100ms-400ms. (the same vi)

It depends on some propertiew of Windows.

[nathand]

Ah, so not a LabVIEW issue. Sorry, I don't have any good suggestions on what setting it might be in Windows, but see if there's any difference between the two computers in firewall or antivirus settings. It wouldn't surprise me if there was a firewall doing something that delayed connection setup. Please do post back when you find the issue, in case someone else has a similar problem.

[Rokot]

It seems to have something to do with LabVIEW. With Python it works.

LabVIEW

Python

[nathand]

Can you post your Python code for comparison? LabVIEW, like Python, calls the underlying operating system functions for opening a TCP connection, so there shouldn't be anything different between the two.