On 10/10/14 3:37 AM, Torsten Bögershausen wrote:
> There is now way for an application to generate a "TCP packet with a
> zero length data payload" and deliver that to the receiver.
Hi, Torsten.
I stand corrected. I tried yesterday on Mac OS X Mavericks using the
write function on a socket file descriptor, and it didn't send anything.
It didn't report an error but just returned 0. So, if anything, the
behavior might be classified as undefined. But you're probably 100%
right that there's no way to send a TCP packet with zero length from a
send or write function call. (A small side of me still wonders if there
might be some crazy TCP implementation out there somewhere that does,
but probably not.) I wish this were specified explicitly somewhere,
though. That is, I wish some documentation said that trying to write
data of length 0 on a TCP socket will return an error. Or, if not an
error, will return 0 and not write anything.
> 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 ;-)
Right, well, I was just noting it doesn't say it's invalid either. It
just doesn't say anything about this case, unfortunately.
> 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 ?
I would guess it would return 0, but I don't know.
> 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
Right, and that's what I noted would make it impossible to differentiate
a connection close from a 0 length TCP send. But again, I see now that
a 0 length send is likely not even possible on any TCP implementation.
Of course, there is probably software that will let one construct a
special TCP packet with data of length 0 and send it, but that's not
what we're worried about here.
Regards,
Lewis
- Replies:
- 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
- Re: TCP connection status : drvAsynIPPort J. Lewis Muir
- Re: TCP connection status : drvAsynIPPort Torsten Bögershausen
- Navigate by Date:
- Prev:
RE: Fanout to Sub Records in a Different IOC Causes Core Dump Poff, Mark A
- Next:
Re: TCP connection status : drvAsynIPPort Torsten Bögershausen
- 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 Torsten Bögershausen
- 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
|