TCP listen takes long time to get connection

[mfitzsimons]

TCP listen does work well in LV 8.0.  The issue is that it takes 45 seconds to make a connection.  I am just giving the function the Port Number to listen on it it returns a reference about 45 seconds latter.  Is there a reson why it takes so long?  Should I be giving it a Net Address?  Is the IP address of the PC or the address of who I am connecting to?

net address specifies on which network address to listen. Specifying an address is useful if you have more than one network card, such as two Ethernet cards, and want to listen only on the card with the specified address. If you do not specify a network address, LabVIEW listens on all network addresses. Use the String to IP function to obtain the IP network address of the current computer.

Thanks!

[.avi file]

Greetings!
    I opened up a simple data simple data client.vi and simple data server.vi. This is part of the example finder programs. If you observe the server VI it contains the TCP Listen VI. Even across the network the TCP listen returned a reference right when it found a client on the network that was active on a specific port that it was listening to. This was about 2 seconds. I would try running the same example program and you could see the behavior. It is very strange that you are seeing the delay. Did you try across a simple cross over cable? Or did you try listening on the port of the localhost (your own system). The IP address what you are mentioning about is of the local system. Did you try disabling all firewalls and any antivirus protection? We need to reproduce this problem with the simplest set up. I tried running the program in LabVIEW 8.2.
Thanks and hope this helps
Avi Harjani

[mfitzsimons]

I will try to simplify the setup and get back to you.  I am using LabVIEW 8.0.1 abd there is Firewall software running and a router.

[.avi file]

Greetings!

   Please let me know if you got a chance to get back to narrowing down the set up?

Thanks
Avi Harjani

[mfitzsimons]

Tried it but no difference.  Disabled Norton and Windows Firewall and directly connected PC to device.  Same result.  Any other program or network settings that could influence the performance of TCP Listen?

[.avi file]

Greetings!

    Can you post the VI you are trying to run? Did you try the example program for TCP Listen? It has good information on how to run the VI in that order. If you got the delay or not running this VI that would be useful information. Do you have two or more network cards in the system? You want to make sure all the other network cards are disabled and only one active and listening on one of the accepted list of port numbers. Have you disabled the resolve remote address Boolean?  Please let me know, I am curious to see if this is an issue or a bug even with LabVIEW 8.2? Do you have 8.2 installed for a quick try? I have not been able to see your behavior in my end,
Thanks and let me know
Avi Harjani

[pabr]

Hi to anyone reading this thread and having the same problem

I know I'm replying in 2007, but I couldn't see any solution to that problem and I got the same problem on a PXI controller runing LabVIEW RT!  I saw another thread with the same problem and no solution, so I thought I could share this info.  For me TCP Listen always took 20 seconds to complete when I wanted to connect.  In the case I don't connect, it timed out properly.  I was amazed to see that it was always 20 seconds, it looked like some fixed delay on the network.  Well, my RT is using fixed IP settings, and I inverted two digit in the DNS Server... so TCP Listen was trying to access a non-existing machine to resolve the remote name of the connected host.  With the right DNS Server address, TCP Listen takes 60msec to complete.

Patrick.

[jdeguire]

I realize that I'm replying to this thread over a year late, but I hope that someone else will find this useful.  I'm working on implementing FTP in LabVIEW and didn't get why FileZilla could get the directory listing so fast when my LabVIEW VI took 5 or 6 seconds to do so.  Wireshark (an ethernet analyser) was showing that the packets were coming in quickly, but LabVIEW was getting stuck on waiting for a listener.

I eventually figured out that I needed to wire False to the Resolve Remote Address input on the bottom of the VI.  The help says that this just calls IP To String, but then I remembered that the function will actually try to resolve the IP (unless you tell it to use the dot notation).  So now it's much faster.  Wire False to the bottom input of the TCP Listen VI unless you actually need to resolve an address (I don't since I'm connecting to a controller board).

Hope someone finds this useful.

[mfitzsimons]

Thanks for some useful information!  I will give it a try next time I have a look at the code.  Even a year late it is still good infromation.

Matt

[ndo]

The J,

Your post fixed my problem!  Thanks for being conscientious!

--NDo