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

151–160 of 247 posts

Re: Falsehoods programmers believe about TCP

#151

Post by lisper »

Ayyyyyron wrote: post #145
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…

The principal difference between 'at most once' and 'at least once' is whether a sender re-tries when it is unsure if the recipient has received the message. If the recipient's ack never makes it back, then a sender cannot know whether they actually received the message or not (the two-generals problem). So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recip…

> So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recipient it's proxying for.

That's not how I would implement exactly-once on top of at-lest-once. I would do it at the recipient, not at the intermediate nodes.

> 'exactly once' delivery is impossible because you can't know if the recipient actually got the message

But the recipient can know.

Re: Falsehoods programmers believe about TCP

#152

Post by lisper »

to11mtm wrote: post #143
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?

You can absolutely abstract 99% of it out. But not 100%. At some point, a counter move on the delivery has to be stored... -somewhere-. And sure you -can- make it very very close to EOD and for some subsets you can totally do EOD, but you are , realistically, better off with ALOD+Ack once it makes its way into a system. There's always that 'moving the counter' problem. The upshot is, things tend to get faster, easier…

> But not 100%.

Why not?

> At some point, a counter move on the delivery has to be stored... -somewhere-.

What is a "counter move on the delivery"?

Re: Falsehoods programmers believe about TCP

#153

Post by shepherdjerred »

lisper wrote: post #130
jerf wrote: post #114

Earlier quoted context omitted.

Because you need to understand that your processing code is constrained by the fact that you can't get exactly-once delivery. You must write your processing code to handle it one way or another. There's some libraries that try to wrap the abstraction of processing exactly once around the code, but those libraries still impose constraints on the sort of code you can write. They can make it easier but they can't fully…

> Because you need to understand that your processing code is constrained by the fact that you can't get exactly-once delivery. Why do I need to understand that? Why can I not put an abstraction layer that provides me with the illusion of exactly-once delivery? > There is no library that can make that just go away Well, this is the thing that I dispute. I believe that there is a library I can write to make it go away…

TCP is at least once, not exactly once.

Here's another useful article: https://blog.bulloak.io/post/20200917-the-impossibility-of-e...

TCP does not solve the two generals problem. TCP gets around this limitation by requiring only one ACK.

https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Engine...

https://www.scaler.com/topics/computer-network/two-generals-...

Re: Falsehoods programmers believe about TCP

#155

Post by Izkata »

Ayyyyyron wrote: post #145
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…

The principal difference between 'at most once' and 'at least once' is whether a sender re-tries when it is unsure if the recipient has received the message. If the recipient's ack never makes it back, then a sender cannot know whether they actually received the message or not (the two-generals problem). So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recip…

> So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recipient it's proxying for. How will it know that the recipient has actually received it?

It seems like the answer is in the first part, the "check that it's not a duplicate".

Implement at-least-once but with a unique token to identify the request, and the receiver sends back acknowledgement with that token every time it receives the original message, but only hands it off for processing the first time. Stuff this behind library/API so it's hidden to the user and the application code doesn't have to handle it, and... isn't that it?

Re: Falsehoods programmers believe about TCP

#156

Post by userbinator »

pjc50 wrote: post #30
hinkley wrote: post #9

I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.

.. on Linux. If you do that on Windows the MAC will detect the loss of link pulses, report the interface as down, and Windows will "helpfully" reset all your TCP connections.

I remember there was a (now rather obscure) patch floating around in the days of Win9x/2K that gave you the Linux behaviour, with an associated option to extend the timeout to very large values.

Later, Microsoft made it configurable:

https://learn.microsoft.com/en-us/troubleshoot/windows-serve...

Of course if the connection is active when that happens, the other end will probably not like the prolonged silence, and give up first.

Re: Falsehoods programmers believe about TCP

#157

Post by lisper »

shepherdjerred wrote: post #153
lisper wrote: post #130

Earlier quoted context omitted.

> Because you need to understand that your processing code is constrained by the fact that you can't get exactly-once delivery. Why do I need to understand that? Why can I not put an abstraction layer that provides me with the illusion of exactly-once delivery? > There is no library that can make that just go away Well, this is the thing that I dispute. I believe that there is a library I can write to make it go away…

TCP is at least once, not exactly once. Here's another useful article: https://blog.bulloak.io/post/20200917-the-impossibility-of-e... TCP does not solve the two generals problem. TCP gets around this limitation by requiring only one ACK. https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Engine... https://www.scaler.com/topics/computer-network/two-generals-...

OK, but you have to do a little extrapolating here because the claim is not that you can do exactly-once under all circumstances. That is obviously false because you can't do exactly-once in a situation where all comms are down indefinitely. My claim is that if I have at-least-once then I can build exactly-once out of that.

Re: Falsehoods programmers believe about TCP

#158

Post by kstrauser »

raggi wrote: post #61
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

Yep, I work on low level networking software professionally and this post is largely meaningless dribble and is probably motivated by grandstanding. It’s like an engineer who says “how does a screen show black” and then says “nope” to every response. It’s maybe a way to make people think, but beyond that the negativity and grandstanding of it is ultimately a turn off for many receivers which eventually either then ha…

I thought you were probably exaggerating, but yes. I've never heard anyone make anything resembling any of those claims.

What I have said is something to the effect that if TCP isn't reliable over a given path, there's not a whole lot I can do about it as an application engineer short of making my own ad hoc, informally-specified, bug-ridden, slow implementation of half of TCP inside my own app, which I'm not going to do.

> 14. Weird networks that are not transparent to standard protocols are an aberration. I can safely ignore them.

I certainly can and will. If you wanna run an RFC 2549 network, I'm going to spend approximately 0 seconds making my app support it. If you want to do something weird, you make it work. I'm going to optimize for the other 99.99999% of customers.

Re: Falsehoods programmers believe about TCP

#159

Post by kragen »

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 thought this list was also self-explanatory. i didn't have a hard time thinking of counterexamples to any of the points, which is not true of patio11's article. but what's self-explanatory depends on your knowledge base. maybe i just know less about foreign cultures than i do about tcp

Re: Falsehoods programmers believe about TCP

#160

Post by Ayyyyyron »

lisper wrote: post #151
Ayyyyyron wrote: post #145

Earlier quoted context omitted.

The principal difference between 'at most once' and 'at least once' is whether a sender re-tries when it is unsure if the recipient has received the message. If the recipient's ack never makes it back, then a sender cannot know whether they actually received the message or not (the two-generals problem). So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recip…

> So this hypothetical middleman will receive a packet, check that it's not a duplicate, and forward it to the recipient it's proxying for. That's not how I would implement exactly-once on top of at-lest-once. I would do it at the recipient, not at the intermediate nodes. > 'exactly once' delivery is impossible because you can't know if the recipient actually got the message But the recipient can know.

But the recipient is not one atomic thing - we're assuming perfect communication between the process/driver/hardware receiving the packets and doing the duplicate detection and the process which wants to receive the message exactly once.

There's still communication happening there, and it can still fail. Buffers fill, processes pause for arbitrary delays which exceed timeouts, etc. Your assumptions based on your model are correct, but your model doesn't include that communication.

But all models have some level of detail they care about, and assuming the computer always works is a perfectly valid model for plenty of cases. It's just not all of them. You'll be able to create real-world cases where this abstraction is faced with a choice of whether to retry or not, and at that moment it will be unable to deliver exactly once.

Post reply on HN