From: "Gérard Roudier" <email@example.com> To: Mike Black <firstname.lastname@example.org> Cc: "Heusden, Folkert van" <email@example.com>, firstname.lastname@example.org Subject: Re: Client receives TCP packets but does not ACK Date: Fri, 15 Jun 2001 20:39:56 +0200 (CEST) [thread overview] Message-ID: <Pine.LNX.email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, 15 Jun 2001, Mike Black wrote: > 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. You are mixing oranges (protocols) and apples (implementations and APIs) here. The layer that is expected to provide reliable end to end communication is layer 4 (transport layer). TCP, at least in theory, is as good as OSI transport in providing reliable end to end communication. > 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 > flip? > > 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. Layers above layer 4 provide additionnal services for applications but they assume that layer 4 is reliable. In other words, a broken transport layer breaks all layers above it and thus the applications. In fact, when you build your application above layer 4 and need services normally provided by upper OSI layers, you have to implement equivalent services in your application, using layered protocols or not. > 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. That's API semantic issue, not protocol issue. Gérard.
next prev parent reply other threads:[~2001-06-15 21:52 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-06-15 12:53 Heusden, Folkert van 2001-06-15 18:27 ` Mike Black 2001-06-15 18:39 ` Gérard Roudier [this message] 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] ` <200106172113.f5HLDhJ377473@saturn.cs.uml.edu> 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] <E15BiHy-0002xCemail@example.com> 2001-06-17 20:21 ` Andi Kleen [not found] <Pine.LNX.firstname.lastname@example.org> 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Client receives TCP packets but does not ACK' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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).