1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: TCP connection status : drvAsynIPPort |
From: | Mark Rivers <[email protected]> |
To: | "'Patel Jignesh'" <[email protected]>, "[email protected]" <[email protected]> |
Cc: | "'Eric Norum'" <[email protected]> |
Date: | Wed, 15 Oct 2014 15:51:25 +0000 |
> So in case of above situation, can I use any methods of asynOctet which will close the connection and establishes new ..or it will done automatically if I have enabled
autoconnect in IPPort driver.. autoconnect does not do anything about disconnecting. It only means that if the port is disconnected when pasynManager->queueRequest is called then asynManager will automatically
call pasynCommon->connect(). Mark From: Patel Jignesh [mailto:[email protected]]
Hi Mark, Thanks to you and others for providing inputs... Below are the final test and observations from my side, 1. In case of two way communication channel, after cable disconnection, the socket disconnection is done by system around 15 minutes only after last failed write, Which is also reported by isConnected...this is justified by the tcp_retries1 and tcp_retries2 in /proc/sys/net/ipv4. 2. If we keep the communication in receive mode, the socket is not destroyed by the system..(I have waited for more than 2 hours..!) So for the two way communication channel, where PLC sends states at regular interval I have option to timeout in application and close the connection. I am using
pasynCommonSyncIO->disconnectDevice , and I have enabled autoconnect,
this works well for the cable disconnection problem. I understand that while doing autoconnect, it get the status from the low level IPPort driver about the 'no cable connection'..is it ?
as if my PLC is connected and if it don’t send the States deliberately than application timeouts and above disconnectDevice method gives INVALID COMM but still the socket
connection remains live….and on new states arrival application receives the same successfully. So in case of above situation, can I use any methods of asynOctet which will close the connection and establishes new ..or it will done automatically if I have enabled autoconnect
in IPPort driver.. Thanks for your support. Best regards, Jignesh
Jignesh PATEL Control Systems Integration Technician CODAC Section ITER Organization, Building 72/286, CHD, Control System Division Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex - France Phone: +33 4 42 17 84 72 Get the latest ITER news on
http://www.iter.org/whatsnew -----Original Message----- Hi Lewis, > I wouldn't think just reading would work. If it's just blocking
> indefinitely in a read, and the hardware it's communicating with is
> then powered off, for example, I don't think the blocking read will
> detect that. I'm not sure I understand this. asyn does reads either using poll with a timeout or setting a socket timeout. If the device is powered off then the recv() will initially
timeout return an error like "Device is temporarily unavailable", but if the read is done repeatedly then after some system-dependent period of time the OS will disconnect the socket, and asyn will mark the port as disconnected. The problem as I understand it is that some ports on his PLC are "write only", so he is not allowed to do a read. We wants to do a write that has no side-effects except
seeing if the device is connected. The best way to do this probably to assume that if one of the read ports is disconnected, then the device is not available, and not try to do it for the write-only ports
at all. Of course, Jignesh you could try modifying drvAsynIPPort.c to allow a 0-length read and see what you observe. Mark -----Original Message----- From: J. Lewis Muir [mailto:[email protected]] Sent: Thursday, October 09, 2014 12:55 PM To: Torsten Bögershausen; Mark Rivers; 'Patel Jignesh';
[email protected] Cc: 'Eric Norum' Subject: Re: TCP connection status : drvAsynIPPort On 10/8/14 11:03 PM, Torsten Bögershausen wrote: >> I don't know what the rules are about sending a 0-length message with
>> send(). Is it allowed, and is the behavior well-defined for all
>> platforms? > > To my knowlegde the answer is no. > Neither this page > > > nor the man page of Debian Linux nor the man page My Mac OS X box
> mention send(0 bytes) as a valid function call. > > My conclusion is that send() with zero bytes length is unportable. Hi, Torsten. Well, they don't actually say that a zero length send is invalid, do they? It seems they just don't mention that case, so it's hard to say. However, some recv function documentation [1][2][3] says that when a stream socket peer performs an orderly shutdown, recv returns 0. In this case, there would be no way
to distinguish a TCP packet with a zero length data payload from an orderly peer shutdown. So, maybe it's not really a good idea for TCP. >>> Now I want to monitor this channel connection status in case of
>>> disconnection or failure from PLC side. > > You could define a "dummy command" which does nothing in the PLC,
> (Other people may call it "no operation command" or NOP) and send that
> every minute or so to the PLC. > > Having some activity on the connection ASYN.isConnected() should work
> as expected. > > Or simply stick to the dummy read, if that does the job for you. Right, some simple no-op command with an acknowledgment (e.g. query firmware version) could be used. I wouldn't think just reading would work. If it's just blocking indefinitely in a read, and the hardware it's communicating with is then powered off, for example, I don't
think the blocking read will detect that. Another possibility (albeit requiring software development) might be for Asyn to support a keep-alive option for TCP connections. This would get passed down as an SO_KEEPALIVE
option on the socket. It would also need options for setting the idle time, the keep-alive probe retransmit interval, and the keep-alive probe retransmit count. These would correspond to TCP socket options like TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT.
(I don't know whether these are standardized.) Then I think a blocking read would return with an error if the keep-alive mechanism determined the connection was broken. Lewis |