Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about TCP

lwn.net

Post reply on HN
Print view View original

101–110 of 247 posts

Re: Falsehoods programmers believe about TCP

#101

Post by lisper »

ZephyrBlu wrote: post #87
lisper wrote: post #75

Earlier quoted context omitted.

> you usually really want 'at least once delivery with acks and idempotent processing on the other side'. Why? I'm pretty sure I really want (the illusion of) exactly-once delivery, and it seems to me that I can implement that pretty easily given at-least-once delivery. Why would I not want that? > The difference is subtle but important Why?

> I'm pretty sure I really want (the illusion of) exactly-once delivery Do you know what idempotency is? This is exactly what he described. Idempotency is important to prevent unwanted behaviour for duplicate actions. If you have "exactly-once", and accidentally execute the action twice that could cause problems.

> Do you know what idempotency is?

Yes.

> This is exactly what he described.

So? Idempotency and an exactly-once delivery abstraction are not the same thing.

Re: Falsehoods programmers believe about TCP

#102

Post by lisper »

shepherdjerred wrote: post #84
lisper wrote: post #64

Earlier quoted context omitted.

If you can get at-least-once delivery, why can you not build exactly-once on top of that? [UPDATE] Apparently I need to be more explicit about this. My question is: if I can get at-least-once delivery, why can I not build an abstraction layer on the receiving node that provides the illusion of exactly-once delivery? It seems like it should be a simple matter of keeping a log of received messages, and discarding dupli…

You can get exactly once processing, but not exactly once delivery. https://bravenewgeek.com/you-cannot-have-exactly-once-delive...

That seems like a distinction without a difference to me. Why should I care if the thing I get exactly one of is called "processing" or "delivery"?

Re: Falsehoods programmers believe about TCP

#103

Post by lisper »

akira2501 wrote: post #98
lisper wrote: post #64

Earlier quoted context omitted.

If you can get at-least-once delivery, why can you not build exactly-once on top of that? [UPDATE] Apparently I need to be more explicit about this. My question is: if I can get at-least-once delivery, why can I not build an abstraction layer on the receiving node that provides the illusion of exactly-once delivery? It seems like it should be a simple matter of keeping a log of received messages, and discarding dupli…

You cannot while maintaining the half-duplex behavior of the current system.

Why not? (Please see the update on my OP before answering that.)

Re: Falsehoods programmers believe about TCP

#104

Post by HDThoreaun »

grishka wrote: post #66

This reminds me of a very particular problem that we tried to solve when I worked at VKontakte. It was about instant messaging and flaky mobile data connections. The problem: you're on a subway train and you send a message as it departs a station. The request does get to the server, but by the time the response arrives, the train is already in the tunnel and you don't have a signal any more. So the client thinks that…

Ive learned that just about nothing is trivial when it comes to distributed systems

Re: Falsehoods programmers believe about TCP

#106

Post by Waterluvian »

shermantanktop wrote: post #94
cubano wrote: post #89

Earlier quoted context omitted.

Uhhh....how does the screen show black?

Each of the pixels is actually a little shining eye which watches your every move. When the pixel’s eyelid closes, that pixel turns black. That’s why they call it putting a display “to sleep.”

I like your explanation, but to be fair, it depends.

Some displays are implemented with dual-eyelid technology for the blackest of blacks. Naturally, like all genius engineering, we see this in nature: cats.

Re: Falsehoods programmers believe about TCP

#107

Post by EGreg »

lovecg wrote: post #67
koala_man wrote: post #29

I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious

I believe the article that started it all is https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... - crucially every entry is self-explanatory, which is a point that a lot of the subsequent “Falsehood…” list authors miss.

I saw this one first, but seems patio11 was first:

https://infiniteundo.com/post/25326999628/falsehoods-program...

Re: Falsehoods programmers believe about TCP

#108

Post by ijustlovemath »

Has this author never heard of error correcting codes? The whole point of them is to assume there's lossiness and add bytes to allow correction (or at least detection) of tampered or missing bytes. That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format.

Additionally, I'm sure they're aware that HTTP over TLS has encrypted data frames, which would be unreceivable in a lot of cases if these situations arose a bunch. And considering how much of the modern Internet is built on this paradigm, I think that many of these points are rare and probably extremely pedantic.

This is coming from someone who agrees with much of the nuance implied (but not explained!) by the post.

All great technical writing (which I assume these clickbait articles are at least attempting to be) is written with mutual discovery and deeper understanding in mind, and if you leave no actual explanation in the post, you can't really achieve either of those.

Re: Falsehoods programmers believe about TCP

#109

Post by lttlrck »

ZephyrBlu wrote: post #87
lisper wrote: post #75

Earlier quoted context omitted.

> you usually really want 'at least once delivery with acks and idempotent processing on the other side'. Why? I'm pretty sure I really want (the illusion of) exactly-once delivery, and it seems to me that I can implement that pretty easily given at-least-once delivery. Why would I not want that? > The difference is subtle but important Why?

> I'm pretty sure I really want (the illusion of) exactly-once delivery Do you know what idempotency is? This is exactly what he described. Idempotency is important to prevent unwanted behaviour for duplicate actions. If you have "exactly-once", and accidentally execute the action twice that could cause problems.

> Do you know what idempotency is? This is exactly what he described.

Is it though? It seems like a false equivalency, even if the outcome is approximately the same?

Re: Falsehoods programmers believe about TCP

#110

Post by akira2501 »

lisper wrote: post #103
akira2501 wrote: post #98

Earlier quoted context omitted.

You cannot while maintaining the half-duplex behavior of the current system.

Why not? (Please see the update on my OP before answering that.)

The mechanism you're describing already exists. TCP has sequence numbers. It can drop duplicate data.

The difference between "processing" and "delivery" relates to "network capacity." Process handling wastes capacity in favor of latency. Delivery handling increases latency in favor of capacity.

Systems which have "exactly once" delivery typically do so with "send/receive" and "release/delete" message pairs. You need additional round trips to actually accomplish this at the "delivery" layer.

Post reply on HN