archive mirror
 help / color / mirror / Atom feed
From: "Mike Black" <>
To: "Heusden, Folkert van" <>,
Subject: Re: Client receives TCP packets but does not ACK
Date: Fri, 15 Jun 2001 14:27:47 -0400	[thread overview]
Message-ID: <03c701c0f5c8$e15f7e10$> (raw)
In-Reply-To: <>

This is a very common misconception -- I worked a contract many years ago
where I actually had to quote the author of TCP to convince a banking
company I was working with that TCP is not a guaranteed protocol.
Guaranteed delivery at layer 5 - yes -- but NOT a guaranteed protcol.

Guaranteed means that there is absolutely NO way that data can be dropped by
an application if either sender or receiver screws up.

The only way to do this is at layer 7 of the OSI model -- even then you end
up making assumptions.

Here's some examples for layer 5 (which TCP operates at) but talking at
Layer 7:

#1 - You send() data -- meanwhile the receiver terminates the connection --
what happened to the data?  It's gone!  Your app never receives feedback
that it didn't send() correctly.  You'll see the reset on the next read but
you don't know what happened to the data.
#2 - You send() data and overrun your IP queue -- nobody will ever know the
difference without a layer 7 protocol (or int the case quoted in this
subject it might lock up).
#3 - You send() data and either machine has bad RAM and flips a bit -- guess
what? -- data corruption.

Even when you do layer 7 (with checksums and ack/nak) you make assumptions:

#1 - You checksum the packet you just received -- what's to say a bit can't

TCP may be guaranteed at layer 5 but we don't typically program at layer
5 -- we program at layer 7 and then lots of people assume they're doing it
at layer 5 -- ergo the problems.

To look at it another way -- "Just 'cuz I told my C library to send a packet
doesn't mean it's going to work".
For example, if you're using non-blocking sockets you have to check to
ensure there's room in your IP queue to transmit.

TCP is guaranteed delivery at layer 5 -- but that's all -- not a "guaranteed
Michael D. Black   Principal Engineer  321-676-2923,x203  Computer Science Innovations  My home page
FAX 321-676-2355
----- Original Message -----
From: "Heusden, Folkert van" <>
To: "Mike Black" <>; <>
Sent: Friday, June 15, 2001 8:53 AM
Subject: RE: Client receives TCP packets but does not ACK

> TCP is NOT a guaranteed protocol -- you can't just blast data from one
> to another and expect it to work.

Isn't it? Are you really sure about that? I thought UDP was the
not-guaranteed-one and TCP was the one guaranting that all data reaches the
other end in order and all. Please enlighten me.

  reply	other threads:[~2001-06-15 18:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-15 12:53 Client receives TCP packets but does not ACK Heusden, Folkert van
2001-06-15 18:27 ` Mike Black [this message]
2001-06-15 18:39   ` Gérard Roudier
2001-06-15 19:12   ` Alan Cox
2001-06-17 18:17     ` Pavel Machek
2001-06-17 19:32       ` Alan Cox
2001-06-17 19:40       ` Dan Podeanu
     [not found]         ` <>
2001-06-17 22:09           ` Dan Podeanu
2001-06-17 22:35         ` dean gaudet
2001-06-18 11:50 ` Jan Hudec
2001-06-18 16:17   ` dean gaudet
2001-06-18 16:48     ` Jonathan Morton
2001-06-18 22:30       ` dean gaudet
2001-06-18 23:43         ` Jonathan Morton
2001-06-19  2:46           ` dean gaudet
2001-06-20 21:01   ` David Schwartz
  -- strict thread matches above, loose matches on Subject: below --
2001-07-01 21:27 Nivedita Singhvi
2001-07-11  3:43 ` Robert Kleemann
     [not found] <>
2001-06-17 20:21 ` Andi Kleen
     [not found] <Pine.LNX.4.33.0106121720310.1152-100000@localhost.localdomain.suse.lists.linux.kernel>
2001-06-13  8:48 ` Andi Kleen
2001-06-13 16:09   ` Robert Kleemann
2001-06-13  0:26 Robert Kleemann
2001-06-15  3:50 ` Robert Kleemann
2001-06-15 12:44   ` Mike Black
2001-06-15 18:29     ` Albert D. Cahalan
2001-06-15 23:10       ` Robert Kleemann
2001-06-16 11:55       ` Mike Black
2001-06-16 23:56 ` Robert Kleemann
2001-06-27  1:04   ` Robert Kleemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='03c701c0f5c8$e15f7e10$' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).