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
<2014>
2015
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
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|