TCP Wait On Listener - will not timeout.

[Iron_Scorpion]

I have a VI that communicates TCP.
It starts by jumping to a 'listen' case where it creates a TCP listener on port 7777, then uses the TCP Wait On Listener. If it finds an IP, it jumps to a read case.
The TCP Wait on Listener has the listener ID passed directly to it from the create listener VI, resolve Remote address is left unwired (T), and the timeout is currently set to 100ms (I have tried numbers ranging 1ms-20s).
I have been tracing communications with wireshark.

If there is no device to connect to, the listener runs in 99-101ms.
When a device is connected; wireshark shows tcp acks/syncs happening immediately after creating the listener. The device immediately sees the open connection and sends a TCP data packet. The wait on listener Vi will hang for around 16 seconds, then return the packet and an error 66 (peer closed connection).  The error 66 is expected because the device has a response timeout and kills the connection on its side. The listen VI does not finish until the connection is closed by the peer.

Why is the wait on listener Vi:
1) not seeing the connection immediately when wireshark sees it as open
2) if it doesn't kick when wireshark sees the connection, then why not when it receives the tcp data packet?
3) when there is actually data, why is it not timing out at 100ms?

The only help I found online was  https://forums.ni.com/t5/LabVIEW/TCP-Client-Not-writing-until-connection-is-closed/td-p/3576135?profile.language=en
This is sort of what’s going on, only the roles are reversed. LV wasn’t sending till it closed the connection.  He added an EOL to fix it. The problem I have with this is that my device doesn't use EOL (CR LF), each TCP is a concise complete message.

If I make a simple Vi that sends TCP data packet (a copy/paste of the wireshark hex stream of the device), the program works great. LV may be adding the CR/LF or some EOL?
If this is on track of the issue, Is there a way to not wait for EOL?

 

Running LV17.0.1f3 64-bit

Thanks everyone. 

Edited December 18, 2019 by Iron_Scorpion

[infinitenothing]

Check out the example at examples\Data Communication\Protocols\TCP\Simple TCP\ It uses the TCP primitives without EOL.

[Rolf Kalbermatter]

17 hours ago, Iron_Scorpion said:

I have a VI that communicates TCP.
It starts by jumping to a 'listen' case where it creates a TCP listener on port 7777, then uses the TCP Wait On Listener. If it finds an IP, it jumps to a read case.
The TCP Wait on Listener has the listener ID passed directly to it from the create listener VI, resolve Remote address is left unwired (T), and the timeout is currently set to 100ms (I have tried numbers ranging 1ms-20s).
I have been tracing communications with wireshark.

If there is no device to connect to, the listener runs in 99-101ms.
When a device is connected; wireshark shows tcp acks/syncs happening immediately after creating the listener. The device immediately sees the open connection and sends a TCP data packet. The wait on listener Vi will hang for around 16 seconds, then return the packet and an error 66 (peer closed connection).  The error 66 is expected because the device has a response timeout and kills the connection on its side. The listen VI does not finish until the connection is closed by the peer.

Why is the wait on listener Vi:
1) not seeing the connection immediately when wireshark sees it as open
2) if it doesn't kick when wireshark sees the connection, then why not when it receives the tcp data packet?
3) when there is actually data, why is it not timing out at 100ms?

The only help I found online was  https://forums.ni.com/t5/LabVIEW/TCP-Client-Not-writing-until-connection-is-closed/td-p/3576135?profile.language=en
This is sort of what’s going on, only the roles are reversed. LV wasn’t sending till it closed the connection.  He added an EOL to fix it. The problem I have with this is that my device doesn't use EOL (CR LF), each TCP is a concise complete message.

If I make a simple Vi that sends TCP data packet (a copy/paste of the wireshark hex stream of the device), the program works great. LV may be adding the CR/LF or some EOL?
If this is on track of the issue, Is there a way to not wait for EOL?

 

Running LV17.0.1f3 64-bit

Thanks everyone. 

It probably is seeing the arriving connection but with your resolve Remote address (T) left unwired it will start a DNS query to resolve the assiciated IP address to a domain name and if your DNS setup is not up to snuff that can hang until it eventually will timeout. And that timeout for the DNS resolution is unfortunately not timeout controllable by the caller but inherent in the socket library.

Do you need a domain name or is the IP address enough? Try to set this input to false and see then.

The Wait for Listener is NOT waiting for any data to arrive on the incoming connection. It accepts() the connection, which sends the ack and then because you told it to resolve the remote address does start a DNS resolution inquiry for the IP address and that is where it hangs for you. It of course can only return after the DNS resolution has returned control to the routine, successful or not. The data your remote side sends will have to be handled by a TCP Read that gets the refnum returned from Wait for Listener.

Edited December 19, 2019 by Rolf Kalbermatter

[Iron_Scorpion]

Thanks infinitenothing, I am familiar with that example.
Since it uses the white TCP Listen.vi whereas I use the tan create listener and wait on listener directly, I just changed the port number on the server example VI and ran it to see what would happen.
Same results. Right as the White VI starts the device tells me it made TCP connection and I see TCP syn/acks on wireshark as well as a packet of data from the device. Then the device gets no response, so it disconnects and reconnects. All while LV is still running inside the white VI. After a few second pass and multiple messages from the device, the white VI finally finishes and data gets pulled inside the loop (with error 66). Again at this point the device has timed out and disconnected.

Edited December 19, 2019 by Iron_Scorpion

[Iron_Scorpion]

38 minutes ago, Rolf Kalbermatter said:

It probably is seeing the arriving connection but with your resolve Remote address (T) left unwired it will start a DNS query to resolve the assiciated IP address to a domain name and if your DNS setup is not up to snuff that can hang until it eventually will timeout. And that timeout for the DNS resolution is unfortunately not timeout controllable by the caller but inherent in the socket library.

Do you need a domain name or is the IP address enough? Try to set this input to false and see then.

The Wait for Listener is NOT waiting for any data to arrive on the incoming connection. It accepts() the connection, which sends the ack and then because you told it to resolve the remote address does start a DNS resolution inquiry for the IP address and that is where it hangs for you. It of course can only return after the DNS resolution has returned control to the routine, successful or not. The data your remote side sends will have to be handled by a TCP Read that gets the refnum returned from Wait for Listener.

Rolf.
Fantastic, you were right. Setting the resolve false makes it recognize the connection at the same time the device does. The program is running smooth now.
Thank you, thank you.
Such a simple change never dawned on me to try. 

I suppose my next step is to look into my DNS setup, and what changed. Oddly this issue popped up on 2 separate PCs at the same time.

 

Thank you again.