On 09/10/14 19:55, J. Lewis Muir wrote:
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.
There is now way for an application to generate a
"TCP packet with a zero length data payload"
and deliver that to the receiver.
Other protocols can do this, but not TCP.
Note that TCP is a stream protocol, when the sender runs
send(socket, buff, 5, 0);
send(socket, buff2, 3, 0);
The receiver runs
recv(socket, buff, sizeof(buf), 0);
and may receive either the 5 bytes or the 8 bytes.
Knowing this, a
ret = send(socket, buff, 0, 0);
yields ret == 0 on my Mac OS X box, but the spec doesn't mention it as a valid operation.
And I would treat anything not mentioned as "not portable", avoid it.
In the same sense as we avoid to pick up the phone and order 0 pizzas somewhere ;-)
The same thing applies for
ret = recv(socket, buf, 0, 0);
What should the function return ?
0 because you asked to receive 0 bytes ?
-1 because this is illegal ?
A different thing is when
ret = recv(socket, buf, sizeof(buf), 0);
we find ret == 0.
Then this is an EOF indicator, saying that the peer has shutdown his write side, or closed the connection
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.
It depends if the socket is blocking or none-blocking.
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.
http://www.gnugk.org/keepalive.html
Lewis
- Replies:
- Re: TCP connection status : drvAsynIPPort J. Lewis Muir
- 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
- Re: TCP connection status : drvAsynIPPort J. Lewis Muir
- Navigate by Date:
- Prev:
PCASpy 0.5.1 Xiaoqiang Wang
- Next:
RE: Fanout to Sub Records in a Different IOC Causes Core Dump Poff, Mark A
- 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 Mark Rivers
- Next:
Re: TCP connection status : drvAsynIPPort J. Lewis Muir
- 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
|