stange TCP timeout

[Neil.Pate]

Hi there,

I am noticing some strange behaviour with the TCP Open Connection VI. For some reason it is totally ignoring any timeout value (including the default unwired state of 60000 ms) and giving an error after approx 1 second (Error 63: network connection refused).

I dont actually have a listener waiting, but surely it should only give the error message after the timeout period is over? My question is not how to get it working, but rather why does this error occur after 1 s?

Any one experience similar behaviour, or am I misinterpreting the LabVIEW help?

ps: am using LabVIEW 7.0 for Win32

[rolfk]

nrp wrote:

> Hi there,
>
> I am noticing some strange behaviour with the TCP Open Connection VI.
> For some reason it is totally ignoring any timeout value (including
> the default unwired state of 60000 ms) and giving an error after
> approx 1 second (Error 63: network connection refused).
>
> I dont actually have a listener waiting, but surely it should only
> give the error message after the timeout period is over? My question
> is not how to get it working, but rather why does this error occur
> after 1 s?

TCP/IP is a 3-way handshake protocol eventhough you do not see that on
the application level. You are most probably trying this out on a local
machine or a local network only. What happens in the TCP/IP socket
driver on the other side when you try
to connect is that it checks its
internal tables and then when no listener has been registered it sends
back a negative acknowledgment informing the requesting socket that no
connection could be established. This certainly is very fast and happens
in less than a second unless you are connected over a very slow dialup
line and trying to reach a similar slow remote site on the other side of
the world or have some serious network overload problems.

Once the socket receives the connection rejection message LabVIEW
correctly decides to not wait any longer and returns the error you see.

Rolf Kalbermatter

[Neil.Pate]

Rolf,

thanks for your input. I was actually just testing using localhost, and your description fits what is happening. This is not the ideal behaviour for my app, but I suppose I can work around it now that I know what's happening!

Thanks again
Neil

[Ben]

Very nice explanation Rolf!

I have seen this error many times and have come to understand that it was an issue with the target, but that was as far as I could guess.

This explanation also fits with those times when a RT target runs out of memory and returns the same error.

Thank you Rolf!

Ben