Parallel TCP connections on same port

[downwhere]

Hi

 

Some background:

 

I have a LabVIEW client application that has created 10 TCP Connections to 10 different servers on the network. Each TCP connection is on the same TCP port and each of the TCP connections is running in its own loop parallel to each other. I have created a subVI that is reentrant and set to ”preallocated clone reentrant execution” and have a TCP connection as parameter and is called from each of the loops.  The subVI is responsible for making a TCP write to the server and then do a TCP read to wait for the response from the server. The response time for each of the servers is 2ms.

 

Im not a TCP/IP expert but I was expected that the communication to each of the servers would be done independently of each other in parallel. So the execution time would be around 2-3ms since the response time is 2ms. But instead I get a total execution time around 10ms indicating that the TCP read seems to be serialized in some way. I have gone through my code several times but I can't see anything that is causing this except that the TCP read is "blocking" each other until the response from server is received.

 

Is that how TCP works if you have several TCP read executing in parallel waiting for data on the same port or should it be able to handle these 10 TCP connections in parallel when the same port is used on all TCP connections? I mean the socket that is created is unique for each TCP connection should handle it or am I misunderstanding something?

 

Best regards

Downwhere

[Tim_S]

I don't think 2-3 msec is unreasonable under the right conditions.

 

There's other factors to consider besides TCP. There's the physical network and it's components; a heavy traffic network will slow down everyone's communication, hubs are less efficient than switches, and the number of hops you have to make will slow you down.There's other applications on your computer; for example, do you have a very aggressive anti-virus that monitors everything that goes in and out of the PC? Then there is your program; Is your program loading down the computer unnecessarily? Are you spamming the network? How big are the messages that you're sending (ideally, a 100k message would take ~10 msec on a 10M network)?

 

I would recommend stepping back to a client that consists of an open, write and read, and a server that consists of a listen, read and write. If you're still getting longer times, I'd try pinging the servers.

[ned]

What makes you think it's the TCP port? I assume by "same port" you mean that all the servers listen on the same port. On the client side, the operating system assigns each connection a different random port when the connection opens. You would see the same behavior even if all the servers were on different ports.

 

My guess is either that you're running out of threads to handle all the instances of the reentrant VI, or at some much lower level access to some part of the TCP/IP system is serialized. Can you try a few experiments? First, try doing all the writes first, then doing all the reads once all the writes have completed. Or, add a short wait after the write such that when you call the read the data should have already arrived. Also try using threadconfig to increase the number of threads in the execution subsystem in which your re-entrant VIs run.

[ShaunR]

If you want to test to see what the interface can handle. You can benchmark (and open lots of connections) with Dispatcher.

[LogMAN]

Besides your algorithm there is also a issue for systems since Windows VISTA where Microsoft changed some parts of the underlying networking behaviour. In my applications I commonly have a seperate network interface which I use for PLC communication on a 1ms timebase. But the system (Windows 7) could only handle ~10ms or slower.

Anyway, if you use a Windows system newer than XP, try following batch command:

 

netsh interface tcp set global autotuning=disabled

 

For me this already solved the problem...

[downwhere]

Thanks for the feedback =)

 

I'll be away the next week so I can't do some experiements until week 10 so I let you guys know how it is working out when im back at work week 10.