EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  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  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: TCP connection status : drvAsynIPPort
From: "J. Lewis Muir" <[email protected]>
To: Torsten Bögershausen <[email protected]>, Mark Rivers <[email protected]>, "'Patel Jignesh'" <[email protected]>, "[email protected]" <[email protected]>
Cc: "'Eric Norum'" <[email protected]>
Date: Thu, 09 Oct 2014 12:55:27 -0500
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
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/send.html
>
> 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.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/recv.html
[2] http://man7.org/linux/man-pages/man2/recvmsg.2.html
[3] http://netbsd.gw.com/cgi-bin/man-cgi?recv

>>> 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

Replies:
RE: TCP connection status : drvAsynIPPort Mark Rivers
Re: TCP connection status : drvAsynIPPort Torsten Bögershausen
References:
TCP connection status : drvAsynIPPort Patel Jignesh
RE: TCP connection status : drvAsynIPPort Mark Rivers
RE: TCP connection status : drvAsynIPPort Patel Jignesh
RE: TCP connection status : drvAsynIPPort Mark Rivers
Re: TCP connection status : drvAsynIPPort Torsten Bögershausen

Navigate by Date:
Prev: Re: MCA and WAN connection J. Lewis Muir
Next: RE: TCP connection status : drvAsynIPPort Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: TCP connection status : drvAsynIPPort Torsten Bögershausen
Next: RE: TCP connection status : drvAsynIPPort Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024