TCP Open Connection over Satellite?

[Steve257]

Having a strange problem...

I've got a VI that uses the TCP Open Connection to connect to another program (not a VI) running as a server.

Over local networks, and even over the Internet, it works just fine.

However, I have a client that operates the Server app in a remote location, and the connection is made over a satellite link, thus it takes up to 4 seconds to round-trip a message.

We've run into an issue  where when the VI tries to connect to the remote server, it apparently gives-up and re-tries numerous times with the result being that it eventually crashes the Server program

I've tried to get around this problem by increasing the timeout value supplied to the TCP Open Connection from 1000ms to 10000ms, but I notice that when I try to open a connection with no server actually running, the TCP Open Connection exits after only about 1 second, not the 10 seconds I'd requested as a time-out.  I'd think that with the long turn around time over the satellite, the connection attempt wouldn't see the server in only 1 second.

I'm trying to debug this problem without having access to both sides of the satellite feed (in fact, I don't have direct access to EITHER side--my client's in Canada, and I'm in Texas), and I suspect that my VI attempts a connection, and bails out after the 1 second (because there isn't enough time for the connection to be established over the satellite), loops around and re-attempts the connection.  Meanwhile, when the server receives the connection request, it opens a connection.  But then another request comes in and it opens another and round and round we go until the server crashes!

Is there any way to work around the TCP Open Connection not waiting the entered Timeout ms before it bails out?  I've currently got it inside a while loop that waits 1 second between connection attempts.  Would increasing that delay to something that'll handle the satellite response time help out?

[Will_S.]

If you have the TCP Open Connection VI in a while loop, it will send a new connection request with each iteration of the loop. So, putting a 4+ second delay between iterations should limit the number of connection attempts LabVIEW is making. However, one potential catch is if the operating system sends additional connection packets within the time the remote system responds. This is part of the TCP protocol within the operating system and would have to be tested. However, since you are only instructing the OS to create one connection, this shouldn't cause a problem. Is there any way you could conduct a test?

[Will_S.]

Posting your VI or at least a screen shot of your connection portion could help figure out the details as well.

[Knoebel]

One issue we found when communicating with a server over a satellite link using TCP/IP is the amount of time the TCP/IP protocol uses for communication. If a response is not given by the server within (I forget the exact time 256 to 512ms) another request is sent. By the time the server gets a request and responds the sending end has already sent two more request of the same thing. The server then sends the data again because it did not get confirmation from the first send. Needless to say there is a lot of duplicated request being sent back and forth because of the time lag across the satellite. When we were doing this, some companies were discussing encapsulating the TCP/IP into another protocol. This never happened while we were doing this. We just suffered through the lag time and multiple requests because a better solution did not exist. I don't know if anybody has come up with a solution or not. We were doing this three years ago with a different application.

[rolfk]

---

Steve257 wrote:

Having a strange problem...

I've got a VI that uses the TCP Open Connection to connect to another program (not a VI) running as a server.

Over local networks, and even over the Internet, it works just fine.

However, I have a client that operates the Server app in a remote location, and the connection is made over a satellite link, thus it takes up to 4 seconds to round-trip a message.

We've run into an issue  where when the VI tries to connect to the remote server, it apparently gives-up and re-tries numerous times with the result being that it eventually crashes the Server program

I've tried to get around this problem by increasing the timeout value supplied to the TCP Open Connection from 1000ms to 10000ms, but I notice that when I try to open a connection with no server actually running, the TCP Open Connection exits after only about 1 second, not the 10 seconds I'd requested as a time-out.  I'd think that with the long turn around time over the satellite, the connection attempt wouldn't see the server in only 1 second.

Is there any way to work around the TCP Open Connection not waiting the entered Timeout ms before it bails out?  I've currently got it inside a while loop that waits 1 second between connection attempts.  Would increasing that delay to something that'll handle the satellite response time help out?

---

Well, I haven't dealt with low level TCP/IP in a while but what I expect is happening is that the TCP/IP socket library itself has some internal timeout time that bails out after the ACK/NACK response on a connect packet is not received. 1s sounds to me like a reasonable timeout for any but satellite connections for this. This is independant of how LabVIEW handles the connection and something inside the actual socket driver. Also a typical connection request consists of more than one single IP packet being sent out and responded too before the connection is established so this difference does make sense to some extend.

What can you do? Well two possibilities really. Most internal socket parameters can be influenced by setting specific values in the registry. This will influence all TCP/IP connections though. Another possibility is probably to use a setsockopt() API call on the actual socket to change this parameter. For an example of how to change socket parameters on a LabVIEW TCP/IP connection search here on the NI site, either knowledgebase or discussion forum for posts describing how to disable the Nagle Algorithme by setting the TCP_NODELAY socket option.

I'm not really sure however which option you would want to change for this specific problem.

Rolf Kalbermatter

[Steve257]

Will,

Here's a copy of my while structure where I try to make a connection.  The broken wires appeared when I copied/pasted the structure into the image file.  Also, note that I've increased the delay inside the while to 10 seconds (it was 1 second), but haven't been able to actully test this yet.

Does anyone have a suggestion for an emulator that'll allow me to set the communications latency to look like a satellite connection?  That'd sure help debugging this as I don't have the satellite access here at my office, and my customer is in Canada (I'm in Texas), so I can't just drive over to their office and try it.

[Will_S.]

I've found some new information. The TCP Open Connection VI will attempt to create a new connection each time it is called. So, every iteration of your while loop will try to create a new connection. This is probably what is causing your problems. I would suggest pulling the TCP Open Connection VI out of the while loop. This guarantees that you are only making one connection. Increasing the delay between iterations should reduce the number of connection attempts, but there is a possibility that you might end up making additional connections before moving on to the rest of your code.

My understanding of TCP is that it will ignore additional requests for the same connection, but not for new connections. So, the communication delay due to the satellite shouldn't interfere with opening the connection as long as the Open Connection timeout is long enough to compensate for the delay.

[RavensFan]

---

Steve257 wrote:

Will,

Here's a copy of my while structure where I try to make a connection.  The broken wires appeared when I copied/pasted the structure into the image file.  Also, note that I've increased the delay inside the while to 10 seconds (it was 1 second), but haven't been able to actully test this yet.

Does anyone have a suggestion for an emulator that'll allow me to set the communications latency to look like a satellite connection?  That'd sure help debugging this as I don't have the satellite access here at my office, and my customer is in Canada (I'm in Texas), so I can't just drive over to their office and try it.

---

That image has a couple Rube Goldberg's in it. 

Your upper select function doesn't need to be there at all.  True is True.  False is False.  No need for the Select and the 2 constants, just wire it.

The lower select function is just a Not statement.  Also no need for the Select and the 2 constants, just wire it with a Not function in line.

[Will_S.]

As far as testing is concerned, you might be able to download a packet sniffer and monitor packets as they go between your computer and test server. See if you can find a difference between the TCP Open Connection in and out of the while loop.