tcp open connection problem while parallel tcp communication

[joernheit]

I have a problem with TCP Open connection while running another TCP transfer.

While I run the Simple Data Client/Server example (..NI\LabVIEW 2010\examples\comm\TCP.llb) I would like to open another TCP connection according this simple VI attached. This runs on another port than the running Client/Server example. When the address of the PC to be connected to, is known to the network (IP/Name) all is fine, when the address is a name unknown to the network, than a significant delay in the datatransfer of the client/server example occures. Hope that anybody can reproduce/explain this behaviour.

Network setup here is Gigabit ethernet/ DHCP / Windows XP Prof. SP3/ LV 2010 / LV 8.6.1

Jörn

[joernheit]

Giving this a kick to the top because I am still struggling with it. Anybody is able to reproduce this behaviour ?. Every comment is highly appreciated.

Jörn

[Mark_Yedinak]

If your primary issue with the open is that it is slow when using a name rather than an IP address then your issue has nothing to do with LabVIEW itself. The delay you are experiencing is the DNS lookup and the response time for that lookup is determined by your network infrastructure. You may be trying several DNS servers in serial to resolve the address. Your DNS server could be on a remote machine that has a slow connection between it and you. Your DNS server may be overloaded. Other things could effect the lookup. If you want this to open as quickly as possible then use the IP address rather than the name of the machine. If you are doing this repeatedly and must do the name lookup then do it once in the beginning of the application and use the address throughout.

[joernheit]

Thanks for the reply. I will try out the idea to resolve the names once and working with the ip addresses afterwards.

[Ben]

I followed an undocumented link for the Bug thread to here.

1) It sounds like mark proposed a viable explanation for what you have posted about.

2) Where did that CAR come from and what does it have to do with?

Thank you,

Ben

[joernheit]

The primary issue is the blocking problem on the connection on the other port during the open and not the delay of the open itself. Unfortunately I have no direct influence of the IT infrastructure of our customers where the application is running thus it is complicated to im prove the DNS behaviour. I reported the problem to NI Germany some weeks ago and the guys there contacted the R&D in the US (that is at least what I know) which come back with CAR 292476.

Sorry for the confusion,

Jörn

[Mark_Yedinak]

Are you trying to run both ends of the connection on the same computer and have each end of the connection establish a connection using the same "remote" port? If so, you can only have one listener on the computer accepting connections for a specific port. What is actually accepting the connections that you are talking to?

I would also recommend that you only do the name lookup once. Get the IP Address once when you initialize using the computer's name and then use the IP address in all other cases. Name lookups can and do take time. Why take the hit on that lookup every time? Servers will very rarely change their IP addresses. You will open the connections must faster and therefore eliminate any blocking that may occur.

Can you explain in more detail what you mean by "blocking problem"?  I am not sure what exactly the issue is that you are having oter than the dealy in establishing the connection. Can you explain your application in more detail or post the code that you are seeing the problem with besides the very simple example already posted. What exactly is being blocked?

[joernheit]

I really appreciate your comments,

to make sure that we do see the same effects let me exactly explain what I see: I open the example vi's : Data Client/Server example (..NI\LabVIEW 2010\examples\comm\TCP.llb. You can open it localy that means on one PC or open one  on another PC. To make it simple for the first try open it localy and run both vi's according the example instructions. On the Data Client.vi I see now the samples updating many times per second (should be every 25 ms, because the server produces these in this intervall). All is like expected. Now open the TCP_Open_blockingproblem.vi from above and let it run unmodified (except you have an PC named 'DataServer0'). What I see now in the Data Client.vi : The samples update came nearly to an halt (this is why I called it 'blocking'). Updates only every 6 seconds (here in my network setup). Now stop the TCP_Open_blockingproblem.vi. The DataClient.vi is running on the same speed as before. Now modify the 'DataServer0' to a pc name existing in your network and start again. This time the sample speed is not degraded. Can you confirm this behaviour ?.

I did recognise the effect for the first time while I desigend an appliaction  based on the STM library and posted the effects I saw, here : http://forums.ni.com/t5/Components/Simple-TCP-Messaging-STM/td-p/583438/page/5. Like Christian Loew supposed there is a bunch of code around. It is a multi tier application receiving TCP traffic on some ports and distributing on others. So I decided to isolate the problem from STM and my own code and came to the simplest code which I thought it was possible where the problem still occures which I described above.

Your suggestion to lookup the names once in the beginning of the application is a possible way, but I must say with the experience now I am still very uncertain of more unexpected future side effects during lookup, especially on network setups at customersites where I have no direct access. So I decided to give an UDP registration mechanism a try, like it is realised in the STM Examples of HostReceiver.vi and Target Sender.vi.

Thanks for following so far,

Jörn

[rolfk]

Most likely the TCP Open holds a semaphore during connection establishment to avoid updates to internal data structures by other threads, and all TCP functions go through that semaphore at some point. You could call this a bug and it is certainly not nice, but there are sometimes situations where you can't avoid semaphores, eventhough the underlaying socket API really is multithreading safe.

I guess the only possibility would be to try to release the semaphore before starting the name resolution or whatever it is that blocks for so long, and reacquire it afterwards. That or rewriting the entire network internal manager in LabVIEW to be fully reentrant and multithreading safe, which I'm guessing is a very major project of its own, that I won't hold my breath for and could just as well be for LabVIEW 2040.

Or you could wait for my update to my network library on lavag.org and try it with that. The current release won't work with actual SP Windows versions due to some security tightening in network name resolution between when I wrote that code and now.

[Mark_Yedinak]

It may not even be LabVIEW's fault. It could be the underlying stack that is the issue. I still think you should go with the approach of only resolving the name once. Your explanation does lend support to the name resolution blocking things.

You could potnetially run into the same issue if you use UDP. If you use name resolution the underlying name resolution may block both TCP and UDP. They both ultimately funnel into the Winsock library which could be what is causing the blocking.