Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #1208 > unrolled thread

Acknowledgement of sent bytes in non-blocking sockets

Back to article view | Back to comp.unix.programmer

Contents

  Acknowledgement of sent bytes in non-blocking sockets ittium <ittium@gmail.com> - 2011-09-04 22:55 +0530
    Re: Acknowledgement of sent bytes in non-blocking sockets Barry Margolin <barmar@alum.mit.edu> - 2011-09-04 14:07 -0400
    Re: Acknowledgement of sent bytes in non-blocking sockets David Schwartz <davids@webmaster.com> - 2011-09-04 15:33 -0700
      Re: Acknowledgement of sent bytes in non-blocking sockets itt ium <ittium@gmail.com> - 2011-09-05 01:59 -0700
        Re: Acknowledgement of sent bytes in non-blocking sockets Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-09-05 13:05 +0100
        Re: Acknowledgement of sent bytes in non-blocking sockets David Schwartz <davids@webmaster.com> - 2011-09-06 10:06 -0700
        Re: Acknowledgement of sent bytes in non-blocking sockets Nobody <nobody@nowhere.com> - 2011-09-07 02:49 +0100
        Re: Acknowledgement of sent bytes in non-blocking sockets Rick Jones <rick.jones2@hp.com> - 2011-09-07 18:28 +0000

#1208 — Acknowledgement of sent bytes in non-blocking sockets

Group,
I have a small doubt. In case of non-blocking socket when send calls (on 
TCP sockets) returns, is it correct to assume that byte equal to return 
value of send call, have been sent and acknowledged or the bytes are 
only copied to send buffer and send returns.
thanks
Ittium

[toc] | [next] | [standalone]

#1209

In article <j40cak$gnt$2@dont-email.me>, ittium <ittium@gmail.com> 
wrote:

> Group,
> I have a small doubt. In case of non-blocking socket when send calls (on 
> TCP sockets) returns, is it correct to assume that byte equal to return 
> value of send call, have been sent and acknowledged or the bytes are 
> only copied to send buffer and send returns.
> thanks
> Ittium

Send returns as soon as they're copied into the send buffer, in both 
blocking or non-blocking mode.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#1210

On Sep 4, 10:25 am, ittium <itt...@gmail.com> wrote:

> I have a small doubt. In case of non-blocking socket when send calls (on
> TCP sockets) returns, is it correct to assume that byte equal to return
> value of send call, have been sent and acknowledged or the bytes are
> only copied to send buffer and send returns.

TCP doesn't provide application-level data acknowledgements. If you
need them, you need to implement them yourselves.

DS

[toc] | [prev] | [next] | [standalone]

#1211

On Sep 5, 3:33 am, David Schwartz <dav...@webmaster.com> wrote:
> On Sep 4, 10:25 am, ittium <itt...@gmail.com> wrote:
>
> > I have a small doubt. In case of non-blocking socket when send calls (on
> > TCP sockets) returns, is it correct to assume that byte equal to return
> > value of send call, have been sent and acknowledged or the bytes are
> > only copied to send buffer and send returns.
>
> TCP doesn't provide application-level data acknowledgements. If you
> need them, you need to implement them yourselves.
>
> DS

This means, if TCP stack failed to send any packets (because of
retransmission  attempt exhaust),  their is no way for application to
know dropped bytes. And these dropped byte are likely to corrupt the
byte stream.

[toc] | [prev] | [next] | [standalone]

#1213

itt ium <ittium@gmail.com> writes:
> On Sep 5, 3:33 am, David Schwartz <dav...@webmaster.com> wrote:
>> On Sep 4, 10:25 am, ittium <itt...@gmail.com> wrote:
>>
>> > I have a small doubt. In case of non-blocking socket when send calls (on
>> > TCP sockets) returns, is it correct to assume that byte equal to return
>> > value of send call, have been sent and acknowledged or the bytes are
>> > only copied to send buffer and send returns.
>>
>> TCP doesn't provide application-level data acknowledgements. If you
>> need them, you need to implement them yourselves.
>
> This means, if TCP stack failed to send any packets (because of
> retransmission  attempt exhaust),  their is no way for application to
> know dropped bytes.

TCP provides an ordered bytestream and this implies that it has a
property the SCTP RFC calls 'head of line blocking': After the sending
TCP has transmitted as much data as will fit into the so-called
'window' of the receiver, no new data will be sent until old data has
been acknowledged. Also, retransmission timeouts are fatal errors and
an application will be informed about them. 

[toc] | [prev] | [next] | [standalone]

#1223

On Sep 5, 1:59 am, itt ium <itt...@gmail.com> wrote:

> > TCP doesn't provide application-level data acknowledgements. If you
> > need them, you need to implement them yourselves.

> This means, if TCP stack failed to send any packets (because of
> retransmission  attempt exhaust),  their is no way for application to
> know dropped bytes. And these dropped byte are likely to corrupt the
> byte stream.

If what you said makes any sense at all, I can't figure out how. TCP
does implement protocol-level acknowledgements.

DS

[toc] | [prev] | [next] | [standalone]

#1227

On Mon, 05 Sep 2011 01:59:11 -0700, itt ium wrote:

> This means, if TCP stack failed to send any packets (because of
> retransmission  attempt exhaust),  their is no way for application to
> know dropped bytes. And these dropped byte are likely to corrupt the
> byte stream.

No. TCP will send bytes in order. If the retry limit is exceeded, the
connection will be closed, and subsequent operations on the socket will
report an error.

[toc] | [prev] | [next] | [standalone]

#1232

itt ium <ittium@gmail.com> wrote:
> This means, if TCP stack failed to send any packets (because of
> retransmission attempt exhaust), their is no way for application to
> know dropped bytes. And these dropped byte are likely to corrupt the
> byte stream.

As others point-out, when TCP hits its retransmission limit, the
connection will be terminated and the application on the
retransmitting side at least will be notified of TCP's "probable
non-delivery of data."  TCP (like any other transport?) cannot tell
you conclusively that bytes didn't make it to the other side, only
that it believes it likely that bytes didn't make it to the other
side.  Consider the case where the problem in the communications is
from the receiver back to the sender - the sender's bytes will get
there, but the receiver's ACKnowledgements will not.  The sending TCP
cannot distinguish this case from the data being lost, which is why I
say "probable non-delivery of data."

Indeed there is no way for the application to know which bytes (it
gave to the transport) didn't get to the remote before the connection
was dropped.  Even if TCP could/would tell the sending side which
bytes were ACKnowledged, that would only address the bytes getting as
far as the remote TCP and would say nothing conclusive about them
being consumed by the application.  Even if TCP could/would tell the
sending side about the window updates (which most of the time, but not
always come as applications read data out of the socket - the
application could have simply increased the socket buffer size), it
would say little to nothing about whether the application actually
acted upon those bytes.

Heck, even if the application has its own "acknowledgement" the
sending side won't know the remote application didn't act on the bytes
- it could be that the bytes got there but the TCP ACKs from the
remote side and the remote application's acknowledgement weren't what
was lost.

rick jones
-- 
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web