Argonne National Laboratory

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  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 
<== Date ==> <== Thread ==>

Subject: Re: TCP connection status : drvAsynIPPort
From: "J. Lewis Muir" <jlmuir@imca-cat.org>
To: Torsten Bögershausen <torsten.bogershausen@esss.se>, Mark Rivers <rivers@cars.uchicago.edu>, "'Patel Jignesh'" <Jignesh.Patel@iter.org>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: "'Eric Norum'" <wenorum@lbl.gov>
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 
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 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·