TCP connection inactivity timeout

Is it true that the ACE module has an tcp inactivity timeout of 3600 seconds (1 hour)?

Yes, it is true. These are the default values:
Parameter-map : new
Description : -
Type : connection
   nagle                              : disabled
   slow start                         : disabled
   buffer-share size                  : 32768
   inactivity timeout (seconds)       : TCP: 3600, UDP: 120, ICMP: 2===================HERE IT IS
   embryonic timeout (seconds)        : 5
   ack-delay (milliseconds)           : 200
   WAN Optimization RTT (milliseconds): 65535
   half-closed timeout (seconds)      : 3600
   TOS rewrite                        : disabled
   syn retry count                    : 4
   TCP MSS min                        : 0
   TCP MSS max                        : 1460
   tcp-options drop range             : 0-0
   tcp-options allow range            : 0-0
   tcp-options clear range            : 1-255
   selective-ack                      : clear
   timestamp                          : clear
   window-scale                       : clear
   window-scale factor                : 0
   reserved-bits                      : allow
   random-seq-num                     : enabled
   SYN data                           : allow
   exceed-mss                         : drop
   urgent-flag                        : allow
   conn-rate-limit                    : disabled
   bandwidth-rate-limit               : disabled

Similar Messages

Proper method to reset tcp connection after timeout error

I have a application that I am building that communicates with a Modbus TCP device. If a communications error occurs I would like to be able the reset the TCP communications. What I have is a control that fires a event when pushed. In this event I have a sequence that first closes the tcp connection and then opens a new connection. My applications starts and runs fine. To test the reset function I removed the ethernet cable from the device and waited of a timeout to occur. I plugged the cable back in and pushed my reset control. Occasionally the reset will occur but most times I will get a time out error at the Open TCP vi. After this, the only way I can establish communications is to exit my application, disable and then enable my network device. Then when I restart my application I have communications with my device.
Any help would be appreciated on how I should be resetting my TCP connection.
Thanks
Terry
Solved!
Go to Solution.

Terry S wrote:
I have attached a example vi (LV10) that shows just the TCP connection and Reset. An error will occur when trying to perform the open tcp in the reset event.
As written your code should be fine. There is nothing inherently wrong with it. However depending on the device you are communicating with you may be trying to reestablish the connection too quickly after you closed the connection. The device may not allow multiple connections to it and may require sometime to clean things up on its end after you close a connection. As an experiment trying waiting a short time between the TCP Close and the TCP Open. If possible you may want to try using Wireshark to see what is happening on the network. It can be useful in diagnosing what is going on.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

ACE TCP connection timeout

Hello,
our customer has a problem with correct closing TCP connections on the ACE. TCP session (HTTP protocol) is closed _correctly_ (we can see it in the sniffer output), but 'sh conn' on the ACE shows it as 'established' (session is already closed). TCP timeout is set to default (60min).
Any new connection from the same src port (because many connection to the service) is closed after TCP session is established.
When I try generate 200 concurrent sessions TCP sessions in my lab, this are on the ACE closed correctly. Customer's traffic is around 20-30.000 concurrent session, but I can't generate so much traffic.
SW version on the ACE: 3.0(0)A1(3b)
thx
martin

Thanks Gilles!
The problem occurs only with traffic from WAP nodes (too many short HTTP requests).
We try it upgrade to A1(5b), but I'm not sure, if this is our problem...
Bug description:
Symptom:
With L7 LB configuration, Some times connections do not close.
Conditions:
SYN sent to Real server may result in ACK coming from server. ACE TCP module was not handling this ACK correctly.
...but our traffic is only L4 LB and we have a problem with connection state on the ACE from both sides (client and server). on the client and server side is connection closed properly, but on the ACE module ('sh conn') we can see it in 'established' state. It's closed after TCP timeout and that is not correct.
martin

How to set TCP connection timeout in solaris 9

Hello All,
I am new to solaris. While using oracle, sometimes I face tcp connection timeout.
The timeout happens after a long delay like more than 8 min. I want to reduce the tcp connection timeout to 2 min in solaris.
Please help me to change this setting.
My current configuration is
SunOS testmachine 5.9 Generic_122300-13 sun4u sparc SUNW,Sun-Fire-V440
Thanks
Purushoth

There's a fair amount of tunables. Without known what is timing out (dns, lost packet...), it's hard to say what you want to tweak. The list of parameters can be seen by using ndd:
ndd /dev/tcp \?
or
ndd /dev/ip \?
and can be set by using ndd -set (see ndd(1M) ). Note that anything you set has to be reset on reboot, so you have to stick this in a script somewhere, or know what the variable translates to to stick it into /etc/system.
-r

TCP Connect Timeout

Does anyone know of a way to increase the TCP connection timeout on Linux (RedHat ES 3.0, 2.4.21-9.0.3.ELsmp). We currently always keep a "dead" server in our imqAddressList for failover. The server has nothing listening on the portmapper port, 7676. When I telnet over regular Internet it takes less than a second to get a connection refused response:
telnet: Unable to connect to remote host: Connection refusedWhen I telnet to this server over a low bandwidth satellite connection, I get a timeout after 3 minutes:
[root@client# time telnet server 7676
Trying X.X.X.X...
telnet: connect to address X.X.X.X: Connection timed out
real    3m15.393s
user    0m0.010s
sys     0m0.000sWe currently have 3 servers in our imqAddressList and imqReconnectAttempts is set to 0. However, since one of the 3 servers is dead, 1/3 of the time it takes over 3 minutes to get a connection. I'd imagine that the socket connection from IMQ is exhibiting the same behavior as telnet.
Is there anywhere that I can tweak this timeout?
Thanks,
Aaron

You need to call connect on a socket set to non-blocking mode with fcntl, and then use select with a timeout to limit the amount of time you will wait for the connect to complete. If select returns because you timed out, then close the socket and return an error. If select returns because of an event on the socket, you use getsockopt to determine if the connect succeeded or not.
See Stevens, Unix Network Programming Vol 1 for details. Comments in the code I'm looking at say page 411.
Hope this helps.

Outgoing TCP connections from VM have very low firewall state idle timeout -- how do you adjust?

When I create a TCP connection from a VM to the internet, if I'm idle for more than a few minutes (say a SSH session), the TCP flow is torn down by some AZURE networking element in between.
Incoming connections from the internet in don't seem to be affected.
I assume this is an Azure firewall timeout somewhere.
Is there any way to raise this?

Hi,
Thanks for posting here.
Here are some suggestions:
[1] - You can make sure the TCP connection is not idle. To keep your TCP connection active you can keeping sending some data before 60 seconds passes. This could be done via chunked transfer encoding; send something or you can just send blank lines to keep
the connection active.
[2] - If you are using WCF based application please have a look at below link:
Reference:
http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9
[3] - If you are using TCP Sockets then you can also try ServicePointManager.SetTcpKeepAlive(true, 30000, 30000) might be used to do this. TCP Keep-Alive packets will keep the connection from your client to the load balancer open during a long-running HTTP
request. For example if you’re using .NET WebRequest objects in your client you would set ServicePointManager.SetTcpKeepAlive(…) appropriately.
Reference -
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.settcpkeepalive.aspx
Hope this helps you.
Girish Prajwal

JNDI connection creation timeouts

Hi,
I've a question concerning connection creation timeouts. The Tutorial (http://java.sun.com/products/jndi/tutorial/ldap/connect/create.html) says "By default, this timeout period is the network (TCP) timeout value, which is in the order of a few minutes. " But which exact tcp-value is it? tcp_keepalive_time? I need to know the default value of this.
Thanx for any hints.
Regards,
Ingo

Hi,
Please let me know if you found the answer. I have the same query. Also, is there any way using JNDI to avoid closing the connection due to TCP timeout as a firewall may time-out after a specified period of inactivity.? That is, If a long-running query is established with LDAP server, can the application keep the session active by sending a keep-alive across the connection?
Thanks in advance.

ASA 60 minute inactivity timeout - Poor choice?

Hello Friends!
We had an issue the other day where doing backups through the firewall (don't ask) caused the "control" session to timeout while the backups were still going on over the "data" connection. This broke the backup about two hours into the job. My first thought was that the backup solution vendor should implement some kind of tcp keepalive for the control connection. A packet capture showed they indeed were -- after 2 hours! Ah ha! Busted! How could they choose such a poor choice of TCP keepalive timer for their application that would not be compatible with the 60 minute inactivity timer that so many firewall vendors use (Cisco, Juniper, Checkpoint and Fortinet all use a default 60 minute inactivity timer for TCP)?
Well, a colleague of mine pointed out that there is actually an old RFC that covers this. RFC 1122. It says:
Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours.
Now I know that RFC is old (October 1989), but that's all I could find. Is there something that supercedes that? Maybe common sense perhaps? I understand not wanting to fill up your connection table because of mis-behaving applications, but I'm just looking for ammunition to use against the backup solution vendor. Surely they're going to point to this RFC.
Thanks!
ASA(config)# timeout conn ?configure mode commands/options: 0:0:0 | <0:5:0> - <1193:0:0> Idle time after which a TCP connection state will be closed, default is 1:00:00 <0-0> Specify this value to never time out

Hi,
Certain application behaviour sometimes forces our hand to reconfigure the "timeout" values for certain customer connections. Though this has been pretty rare in my own case atleast.
I would imagine that any kind of keepalive would be something that would be constantly transmitted on the connection that needs to stay up and it would certainly be something that the application handles itself.
I did a quick try on my home ASA to check if this could be corrected by the ASA wihtout globally affecting all connections through the ASA and it seems to work fine
Here is the configuration I did
Where
TIMEOUT = Is simply the name for each configuration (ACL, Class-Map and Policy-Map) that I chose
x.x.x.x = Is the destination IP address for which I want to create these rules for
LAN = Is my ASAs "inside" interface
access-list TIMEOUT extended permit ip host 10.0.1.1 host x.x.x.x
class-map TIMEOUT
match access-list TIMEOUT
policy-map TIMEOUT
class TIMEOUT
set connection timeout idle 3:00:00
service-policy TIMEOUT interface LAN
Output of "show conn long" with 2 connections through the ASA. Other going with default "timeout" values and other matching the configured "timeout" values.
TCP WAN:x.x.x.x/80 (x.x.x.x/80) LAN:10.0.1.1/59074 (y.y.y.y/59074), flags UO, idle 15s, uptime 17s, timeout 3h0m, bytes 2
TCP WAN:a.a.a.a/80 (a.a.a.a/80) LAN:10.0.0.21/57482 (y.y.y.y/57482), flags UIO, idle 13s, uptime 14s, timeout 1h0m, bytes 598
Where
x.x.x.x = Is the destination IP for the connection for which you want to configure its own "timeout" values
y.y.y.y = Is my ASA public IP
a.a.a.a = Is the connection destination IP address for which the global "timeout" values are applied
Theres is also an option called "dcd" in the same "set connection timeout" configuration
Here is the Command Reference section for "set connection timeout"
set connection timeout To specify connection timeouts within a policy map for a traffic class, use the set connection timeout command in class configuration mode. To remove the timeout, use the no form of this command. set connection timeout {[embryonic hh:mm:ss] [idle hh:mm:ss [reset]] [half-closed hh:mm:ss] [dcd [retry_interval [max_retries]]]} no set connection timeout {[embryonic hh:mm:ss] [idle hh:mm:ss [reset]] [half-closed hh:mm:ss] [dcd [retry_interval [max_retries]]]} Syntax Description
dcd
Enables dead connection detection (DCD). DCD detects a dead connection and allows it to expire, without expiring connections that can still handle traffic. You configure DCD when you want idle, but valid connections to persist. After a TCP connection times out, the ASA sends DCD probes to the end hosts to determine the validity of the connection. If one of the end hosts fails to respond after the maximum retries are exhausted, the ASA frees the connection. If both end hosts respond that the connection is valid, the ASA updates the activity timeout to the current time and reschedules the idle timeout accordingly.
embryonic hh:mm:ss
Sets the timeout period until a TCP embryonic (half-open) connection is closed, between 0:0:5 and 1193:0:0. You can also set the value to 0, which means the connection never times out. A TCP connection for which a three-way handshake is not complete is an embryonic connection.
half-closed hh:mm:ss
Sets the idle timeout period until a half-closed connection is closed, between 0:5:0 and 1193:0:0. You can also set the value to 0, which means the connection never times out. Half-closed connections are not affected by DCD. Also, the ASA does not send a reset when taking down half-closed connections.
idle hh:mm:ss
Sets the idle timeout period after which an established connection of any protocol closes. The valid range is from 0:0:1 to 1193:0:0.
max_retries
Sets the number of consecutive failed retries for DCD before declaring the connection as dead. The minimum value is 1 and the maximum value is 255.
reset
For TCP traffic only, sends a TCP RST packet to both end systems after idle connections are removed.
retry_interval
Time duration in hh:mm:ss format to wait after each unresponsive DCD probe before sending another probe, between 0:0:1 and 24:0:0.
Defaults The default embryonic timeout is 30 seconds. The default half-closed idle timeout is 10 minutes. The default dcd max_retries value is 5. The default dcd retry_interval value is 15 seconds. The default tcp idle timeout is 1 hour. The default udp idle timeout is 2 minutes. The default icmp idle timeout is 2 seconds. The default esp and ha idle timeout is 30 seconds. For all other protocols, the default idle timeout is 2 minutes. To never time out, enter 0:0:0.
Source:
http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/s1.html#wp1453113
I can't really say anything else to this other than it seems stupid to me to not have a mechanism to keep the Control connection active with frequent (enough) messages that will keep it active as long as there is data transfer on the actual Data connection. I dont know what kind of keepalive it is that polls at minimum on 2hour interval. Kind of beats the whole purpose of keepalive.
Though then again this is not a subject I could comment on any kind of certainty. Only comment on the way it seems to me.
- Jouni

Router closes TCP connection after 30 minutes

I have recently replaced my D-Link DIR-100 router with a Cisco Linksys RV042, but unfortunately there seems to be a problem with it.
I have an external TCP connection coming in to a local service, and I therefore set up the router to redirect the incoming connection for the given port to the local PC hosting the service. This worked perfectly. I also opened the Firewall access rules to allow all data from WAN2 to be propagated through. This also worked just fine, and I can connect from the internet to the local PC, just like I could with my old router. Unfortunately this is where the simularities stop. When there is no communication on the TCP connection for more than 30 minutes then the router closes the connection automatically. This is NOT what I want. I only communicate on the TCP connection very rarely, but I do not want it closed automatically - at least not after just 30 minutes.
I did some research on line and it appears that there in some routers are a TCP connection timeout, which in the router I read about, defaulted to 1 day. This would be OK. I experimented and found that if there is communication every 30 minutes then it is not close the connection, but if there is 50minutes between communication then it closes the connection.
As I read that this timeout has to do with security I experimented with the firewall and found the following:
1. Disabling the entire router firewall fixes the problem !!!
2. Disabling just DoS has no effect (problem still exists)
3. Disabling SPI means I cannot connect at all !!! (new and much worse problem)
4. Disabling Block WAN Requests has no effect (problem still exists)
Is there a way to solve this problem without disabling the entire firewall, as that is not what I want to do. I have the system set up for Dual WAN (load balancing), and I only want to allow connections to a handful of ports on the one WAN, and block the other WAN entirely.
P.S. I was referred to the Cisco Small Business Support Community by the Cisco Home community, so I hope this is the right place.

Hi Ddb101,
This is a limitation (or feature depending on how you look at it) of the iPhone/iPod touch. 30 minutes after the device locks (usually 5 minutes of inactivity) the network turns off completely to save battery life. You can either turn autolock off globally, or some programs (mine for instance see: http://ootunes.com/app/ ) have an option that disables sleep while the app is running so the stream will keep playing... until your battery dies Only problem is with the screen on the battery actually dies even faster!
Finally, if the device is connected to a constant power source, it shouldn't actually time out. So if you have a way to plug it in, it shouldn't quit after 30 minutes on you...
hope that helps,
also, since there's a link to my site up there, and I sell the app, I should tell you that I might get money if you go to the page and end up buying my app...

Opening and closing Multiple TCP connections issues

Hi all I am having an issue with the TCP VI’s and wondering if anyone has experienced this issue.
My application is required to scan 50-100 IP addresses (statically assigned) and discover if an Ethernet device is connect at that IP address. Currently I am able to achieve this by opening a TCP connection and testing the error cluster to determine if a timeout has occurred (no timeout error means Ethernet device available at the IP address). I then ensure that the TCP connections are closed.
The issue I am have is that I require a 1 second delay between the TCP open and the TCP close which significantly slows down the process. Without the 1 second delay the vi successfully connects to the device once then fails to make any TCP connect regardless of the time delay until the PC is reset.
If anyone has any advice I would be very grateful
David Barr
P.S. I have attached a simplified section of code showing this issue
Attachments:
TCP Open close issue.vi ‏15 KB

smercurio_fc wrote:
If I understand you correctly you want the time delay to be 1 second if there's a successful connection....
While I don't have a specific answer for this problem. I want to clarify for him. I believe the issue is, what if all connections ARE there? That means you keep returning a wait of 1 second 50-100 times so It takes 50-100 seconds just to initialize. I think the user is looking for a way to check for valid connections, but do so in such a way that eliminates the need for a wait which is greatly slowing things down.
CLA, LabVIEW Versions 2010-2013

Anyone else having an issue with TCP connections using iCloud for Windows?

Hi,
Before I asked this question, I did wait to see if any related questions came up, but none did, so I submit it now.
On my admittedly older laptop running Windows 7 64b Home, I've run into difficulties with the iCloud for Windows app to the extent that I had to uninstall it.
It would that, as my laptop was running, in the background, iCloudServices.exe would endlessly iterate TCP connections, which, while not actively sending or receiving any data, after some hours would number over 100 instances, taking up resources, and grinding my laptop's WiFi connection to a grindingly slow pace. I ended up, within the app, turning off everything, iCloud Drive and Photos, (I never used bookmarks), but still this would continue to occur.
I contacted Apple Support, explaining what was going on, and they stated they only dealt with IOS and gave me a Microsoft Support number. When I called Microsoft support, I came more and more to the realization that the issue was specifically with the iCloud for Windows app, as that was the only software that was endlessly creating and not closing TCP connections as it was. How was Microsoft supposed to solve an issue with Apple code?
So I called Apple back, whereupon they insisted it was a Microsoft issue. I explained other cloud services installed on the same computer were not having the same issue, it was unique to ICloudServices.exe. They stated they only dealt with IOS. I stated I purchased an iPad Air less than 7 months ago, and was trying to run iCloud in support of that. They again stated they only dealt with IOS, and suggested I again try Microsoft. I asked them if it was reasonable to expect Microsoft to solve issues with Apple code? They said regardless, there was zero support offered for anything having to do with Windows, and all I could do was uninstall the app, which I did, though that did not feel very satisfactory to me. My thinking is, if Apple writes a Windows app in support of their hardware, they should offer support for it.
Anyway, I was just wondering, is this an issue unique to me? or have others experienced a similar issue? I found this issue by opening the Windows Resource Monitor, looking under the Networking tab, and scrolling through the TCP Connections section to find 100+ concurrent iCloudServices.exe instances listed, whereas even Chrome, with multiple tabs and extensions, topped out at around 20.
My one month old Desktop, DYI, sports a solid Asus 1150 MoBo, i7-4790k cpu, 16GB Ram, and an EVGA GTX 970 video card. I list some specs only to illustrate this computer has no hardware issues in comparison to my long in tooth laptop. On this desktop, running Win 8.1 Pro 64b, at least as many, identifiably Apple, background service TCP connections are created even compared to Chrome, regardless of many tabs being open, many extensions, and even some related apps. Adobe does not even come close, though I run the full CC subscription. On this new computer, running Windows 8.1 Pro 64b, there are currently over 50 TCP connections and loopbacks that do not identify themselves, with just a - for the Image, and PID. With the experience on my laptop, I wonder how many of these are generated by Apple software, if not specifically iCloud software?
The frustrating aspect of these connections is they seem in no way active, While the Chrome and Adobe connections can be seen to be transferring data, as long as I am not running iTunes, or so have my iPad actually plugged in, it seems 99% of the time these iCloudServices.exe connections are just taking up ports, neither sending nor receiving any data discernable to me under the Processes with Network Activity, or Network Activity lists, both displayed in the same window as the TCP Connections in the Windows Resource Monitor.
Though I am fairly ignorant as regards coding, it seems as if there is no call to close a connection, very specifically, iCloudServices.exe, when it is no longer needed, and the next time a connection is needed, a new one is opened, rather than accessing the one previously opened. The only other reason I could imagine this might be occurring is if my Norton Internet Security software might mask and/or block the port after a certain time of inactivity.
Anyone out there have any ideas or advice about this? Thanks in advance.

Thanks jared,
I'm still dealing with this issue through Apple. Some time after I posted this, I contacted Apple again. They did start a case up for me, as I was experiencing the same behavior on two different machines, with two different versions of Windows.
So far it remains unsolved. I've logged iClouds for Windows on my desktop, which is brand new, then logged for awhile after completely uninstalling Norton Security Suite, depending on the Microsoft security for some time, and finally logged after I uninstalled iCloud for Windows, restarted, installed a clean download, and connected using a completely different test account, which Apple set up for me. None of this made any difference. Looking at the logs, it seems every 10 minutes, iCloudServices.exe creates a new TCP connection to confirm I'm using less than 5GB on iCloud, (which I am by a good margin, using less than 2GB), it seems this connection is not closed, and when the next iteration rolls around 10 minutes later, a new TCP connection is created. I come very close to having 6 TCP connections created per hour, until I restart my computer. This works out to... 6 x 24 = 144/day.
Perhaps the article you posted will shed some further light on this. I'm thinking seeing the state of the connection through netstats, at the least, could help.
For the last week, I've been putting a hold on further logging, as Apple wants me to create a new user account on one of my computers, install iCloud for Windows there, and log it running in the other account. This however basically means I cannot use my computer for a fair number of hours, and I've been busy enough with work the past week that I haven't the time or energy to afford to set this up and run it. I've had need of my computers too much for the past week.

TCP connection error when sending MODBUS commands to WAGO 750-881 controller after 113655 bytes of data have been sent

Hi all,
I am new to the world of labview and am attempting to build a VI which sends commands to a 750-881 WAGO controller at periodic intervals of 10ms.
To set each of the DO's of the WAGO at once I therefore attempt to send the Modbus fc15 command every 10ms using the standard Labview TCP write module.
When I run the VI it works for about a minute before I recieve an Error 56 message telling me the TCP connection has timed out. Thinking this strange, I decided to record the number of bytes sent via the TCP connection whilst running the program. In doing so I noticed that the connection broke after exactly 113655 Bytes of data had been sent each time.
Thinking that I may have been sending too many messages I increased the While-loop delay from 10ms to 20, 100 and 200 ms but the error remained. I also tried playing with the TCP connection timeout and the TCP write timeout but neither of these had any effect on the problem.
I cannot see why this error is occuring, as the program works perfectly up untill the 113655 Bytes mark.
I have attached a screenshot of the basic VI (simply showing a MODBUS command being sent every second) and of a more advanced VI (where I am able to control each DO of the WAGO manually by setting a frequency at which the DO should switch between ON and OFF).
If anybody has any ideas on where the problems lie, or what I could do to further debug the program this would be greatly appreciated.
Solved!
Go to Solution.
Attachments:
Basic_VI.png ‏84 KB
Expanded_VI.png ‏89 KB

AvdLinden wrote:
Hi ThiCop,
Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here).
I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is " -# + ").
As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved.
If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing.
Modbus TCP RTU is a binary protocol, as you show in your Basic VI, where you format the data stream using byte values. So you have to interprete the returned answer accordingly with the Modbus RTU spec in hand. Now what is most likely happening is that the connection gets hung after a while since you do NOT read the data the device sends as response to your commands. The TCP/IP stack buffers those bytes and at some point the internal buffers overflow and the connection is blocked by the stack. So adding the TCP Read at strategic places (usually after each write) is the proper solution for this. Is there any reason that you didn't use the NI provided Modbus TCP library?
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to send joystick data over TCP connection

Hi all,
I am a long time Labview discussion forum user for learning, but this is my first time posting a question, I hope somebody can help me!
In the attached VI I am trying to send data from a joystick over a TCP connection. I can send data fine using the TCP examples (in fact the majority of my VI is just a copy of the example). However I am to the point where I do not know how to send all the data necessary (3 axis data, 12 buttons, and the POV data) over TCP. Strings, clusters, and arrays were never my strong suite and converting between them is a nightmare for me.
Basically I am trying to send each axis data (X,Y, and Z), button data (12 buttons), and POV data (the POV data will be calculated to adjust the position of a camera, so the immediate data is not important, I will add functions to add the change in the button movements to write a standing position for two servos [pan and tilt], for which that I will need to send over the TCP connection) over the TCP connection to control various cameras and motors. I don't know if it is posible to send that much data over a TCP connection in one write VI through a string, and also how to separate the string on the other side in order to control the client VI.
Again, the actual TCP communication I get, and can operate fine, just formatting all the data into a string (or whatever is required) so that I can unpack on the other side is the issue here.
Another question I have (not impotant to get the program running just might make it easier on me) is can a TCP server (which sends the data to the client) also recieve data back from the client on the same port ( for example sensor data and digital positions [on,off])? Or do I need to set up two TCP communication loops with the first client acting as the server on a different port than the first, which then sends the data to the original server, which also has a client TCP configuration in another loop? I hope this makes sense...
One final question.....I already have a solution to this but using labview for the entirety of this project would be nice. I use skype to stream 1080p video from a webcam to my computer so I can view live feed. Can labview do this? This would be awesome if so, I am just not sure if the communication protocols in use could support real time (or as close as possible to streaming) for 1080p video.
Thanks all in advance for your help,
Physicsnole
Attachments:
cameraserver.vi ‏24 KB
cameraclient.vi ‏18 KB

Physicsnole wrote:
In the attached VI I am trying to send data from a joystick over a TCP connection. I can send data fine using the TCP examples (in fact the majority of my VI is just a copy of the example). However I am to the point where I do not know how to send all the data necessary (3 axis data, 12 buttons, and the POV data) over TCP. Strings, clusters, and arrays were never my strong suite and converting between them is a nightmare for me.
Well, you cast the axis info cluster to a string, but then you cast it back to an array of DBL. Thatr's not compatible. You should probably cast it back to an "axis info" cluster of exactly the same type. Go the the other VI and right-click the cluster wire to create a constant. Now move that diagram cluster constant to the other VI and use it as type.
Your default ports don't seem to match. You seem to have client and server roles confused. In the sever you create a listener, but then you start sending packets, even though no connection is established. The connection needs to be initiated by the client.
Your client stops the loop the first time a timeout is encountered. Shouldn't that be more permanent? Also, please retain code clarity and avoid unecessary complexities. For example, replace the "not or" with a plain "or" and change the loop to "stop if true"
Physicsnole wrote:
Basically I am trying to send each axis data (X,Y, and Z), button data (12 buttons), and POV data (the POV data will be calculated to adjust the position of a camera, so the immediate data is not important, I will add functions to add the change in the button movements to write a standing position for two servos [pan and tilt], for which that I will need to send over the TCP connection) over the TCP connection to control various cameras and motors. I don't know if it is posible to send that much data over a TCP connection in one write VI through a string, and also how to separate the string on the other side in order to control the client VI.
You can send as much as you want. The casting to/from string is the same as described above.
Physicsnole wrote:
Another question I have (not impotant to get the program running just might make it easier on me) is can a TCP server (which sends the data to the client) also recieve data back from the client on the same port ( for example sensor data and digital positions [on,off])? Or do I need to set up two TCP communication loops with the first client acting as the server on a different port than the first, which then sends the data to the original server, which also has a client TCP configuration in another loop? I hope this makes sense..
The primary function of a "server" is to wait for a connection and then communicate with the client once a conenction is established. An established TCP/IP connection is fully two-way and both sides can send and receive.
LabVIEW Champion . Do more with less code and in less time .

How to prevent a TCP connection being closed when the VI that opened it finishes.

Hello everyone.
I am developing an application based around servers and clients communicating over TCP in LabVIEW 2012.
When the server/client opens a TCP connection ,it launches an asynchronosly running "connection handler", to which it passes the connection reference which then takes over all the communcation. This all works fine.
However - I have a situation where a client's connection handler can be informed of another "new" server. I would like it to open the connection (to see if it is still valid) and then pass this connection reference back to the client's main code to spawn a new connection handler. This prevents me locking up the Client's main code with a long-ish timeout if the "new" server is not actually accepting connections.
The issue is that if the connection handler that opened up the connection to the "new" server is stopped, then it appears to destroy the reference that it opened. This means that the other connection handler that was merrily communcating with the "new" server has its TCP communciations closed (I get an Error code 1 on a write).
I have created an example to demonstrate the issue which should be used as follows:
1. Run server.vi - it will listen for a connection on the port specifed on its BD.
2. Run CH Launcher.vi - it will open a connection to the server and pass the TCP reference to an instance of Connection Handler.vi which it launches.
3. The Connection Handler should send data to the Server
4. Stop the CH Launcher.vi
5. The Connection Handler.vi will error.
Any suggestions would be much appreciated.
Cheers
John
Solved!
Go to Solution.
Attachments:
TCP Test.zip ‏35 KB

John_Neutron escreveu:
In my case I have changes the part of the code that opens the TCP connection to a VI that has the same lifetime as the main VI so that any connections that have been opened will only be closed automatically when the main VI stops.
And what are the effects? You are still facing the same problem or closing the connection only when the whole applicaton stops solved your problem?
Regards
Mondoni

Permanent TCP connection

dear all ,
my server connects to another server using TCP connection. how do i maintain Permanent TCP Connection . There shud be no timeout .
i have not started working on it yet . iam not familiar in socket programming .
kindly help ........
thanks in advance
galaxy

dear all ,
my server connects to another server using TCP
connection. how do i maintain Permanent TCP
Connection . There shud be no timeout .
i have not started working on it yet . iam not
familiar in socket programming .
kindly help ........
thanks in advance
galaxyWhy do you think there is any timeout?
AFAIK the socket never disconnects itself because of some timeout....

TCP connection inactivity timeout

Similar Messages

Maybe you are looking for