Network bottleneck

[aart-jan]

Hi all,

I noticed that functions such as "File/Directory Info" and "get file size" can stall seriously if a network path (e.g. \\192.168.3.1\share\file.txt) does not exist, because that particular machine is down.

Does someone know of a faster way of determining if a remote machine is up, other than pinging with system exec?

Thanks!

Aart-Jan

[Kevin Boronka]

Hi all,

I noticed that functions such as "File/Directory Info" and "get file size" can stall seriously if a network path (e.g. \\192.168.3.1\share\file.txt) does not exist, because that particular machine is down.

Does someone know of a faster way of determining if a remote machine is up, other than pinging with system exec?

Thanks!

Aart-Jan

I've noticed the same issue.

I worked around this problem by pinging the remote machine before trying open a file.

[crelf]

I worked around this problem by pinging the remote machine before trying open a file.

I've got to agree - I found that it was Windows searching and searching and searching, so the pinging was the best solution. It's actually pretty elegant - you can't get much lower down than a ping, so it's a neat and efficient method to see if a remote PC is accessable before really trying to do any work with it.

[Rolf Kalbermatter]

I've got to agree - I found that it was Windows searching and searching and searching, so the pinging was the best solution. It's actually pretty elegant - you can't get much lower down than a ping, so it's a neat and efficient method to see if a remote PC is accessable before really trying to do any work with it.

At least if ping hasn't been disabled for that computer. Nowadays with security concerns all over the place this is not something uncommon to happen.

Rolf Kalbermatter

[jpdrolet]

I have not tried the technique but you could try to open TCP connections to NetBIOS ports 139 and 445 of the remote computer to see if it is serving files. If one of the connections open without error then most probably the computer is online for filesharing. You can then close the connection and open the file. When the computer is not online, you have control on the timeout input of _TCP Open Connection_ to set how long is too long to wait.

Alternatively, you could call the file function in a VI spawned in parallel to your main code and if the VI doesn't resume with valid data after some delay (shorter than the network timeout) resume the main code letting the spawned VI running until the file function times out.