Please note that it's not an article on lwn.net, it's a comment written by someone.
Falsehoods programmers believe about TCP
191–200 of 247 posts
Re: Falsehoods programmers believe about TCP
#192Earlier quoted context omitted.
Uhhh....how does the screen show black?
The screen knows what color it displays at all times. It knows this because it knows what it doesn't. By subtracting what it does from what it doesn’t, or what it doesn’t from what it does (whichever is greater), it obtains a difference, or deviation. The controller board uses deviations to generate corrective commands to drive the display from a state where it does not display black to a state where it does, and arr…
For the uninitiated: The Missile Knows Where It Is[1]
Re: Falsehoods programmers believe about TCP
#193Earlier quoted context omitted.
> Why can I not put an abstraction layer that provides me with the illusion of exactly-once delivery? You can do that. You can implement a video conferencing system ontop of TCP, and it will even work, technically. It will just have terrible performance characteristics that you'll never be able to fix. You might even call it fundamentally broken.
OK, I don't dispute that, but that is a very different claim than "you can't get exactly-once delivery." You can (if you have at-least-once delivery).
Read the two general's problem. It is proven that exactly once _delivery_ is a physical and mathematical impossibility.
Like you said, you can simulate it with exactly once _processing_. But to do that, you have to know to do that.
Others are saying "you can't divide by zero" and you are saying "yeah, but if I detect a zero and the do something different, then it is the same thing." No, knowing you have to do something is the very point of acknowledging you can't divide by zero.
Because you can't have exactly once delivery, you have to deal with it. One trick is duplicate checks or idempotent writes. This gives exactly once processing. This also takes additional overhead and why audio and video stream processing doesn't typically do the additional checks.
I have fixed many bugs written by people who believe the network is reliable. I even hired one when during the interview and we talked about this kind of issue that they realized why they were getting duplicated writes reading from sqs or sns at $existing_job. They were green but smart and she became a real asset to the team.
Re: Falsehoods programmers believe about TCP
#194Earlier quoted context omitted.
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"?
Read the two general's problem. It is a mathematical impossibility. The counter is the delivery counter. Delivery, delivery + 1
Re: Falsehoods programmers believe about TCP
#195Earlier quoted context omitted.
> 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.
Agreed. Idempotent _processing_, not delivery.
Re: Falsehoods programmers believe about TCP
#196This 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…
Honest question: Why didn't you send the message's idempotency token back to the client? Then you're playing the familiar local database locking game.
You can't imagine how desperately I asked for that. Backend guys came up with all sorts of excuses to not do it. As far as I know, they did do it sometime after I quit.
Re: Falsehoods programmers believe about TCP
#197Earlier quoted context omitted.
I wonder what he means by France having a “weird” naming system in common use. As far as I can tell, the traditional French naming system works exactly the same way as the traditional American one (except that it’s more common for French people to have several middle names rather than zero or one, but I don’t think that’s too rare in the US either). Maybe he’s referring to the fact that some last names are two words…
Perhaps he is thinking of how marriage does not change your last name, but rather gives you an extra, optional last name. [1] The French ID card has two last name fields! [1] https://fr.m.wikipedia.org/wiki/Nom_d%27usage_en_France
Err. It still does by default change your name (if you're a woman). But you can ask and keep your 'maiden' (ugh) name or have both. It gets a bit trickier for kids' family names...
Re: Falsehoods programmers believe about TCP
#198> remember, all of the following statements are false at least some of the time, but for some of these, perhaps not very often > 5. There is a such thing as a TCP packet > 6. There is no such thing as a TCP packet I don't understand this at all. Either the concept of a TCP packet exists, or the concept does not exist. Even it's not being used in certain scenarios, I don't see how you can argue that "there's no such t…
It sounds like TCP is totally fucked and useless. It needs to be depreciated immediately and replaced with something better and more intuitive from a programming perspective. Maybe someone at Apple or Google is working on it lol.
Re: Falsehoods programmers believe about TCP
#199Earlier quoted context omitted.
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.
Every point is not self-explanatory, and some are clearly true (while the assumption is they must be false). For instance, it surely is true that any name will fit in under a Terabyte of text, if it can be encoded at all (and assuming the contrary is counter-productive). Claiming you should not assume any name can be spelled in Unicode is absurd as well. And, yes, it's perfectly fine to assume that if your system mus…
I think Prince proved the Unicode assertion. He had to distribute his own custom font so news outlets could continue to write about him.
Re: Falsehoods programmers believe about TCP
#200Earlier quoted context omitted.
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…
The author probably doesn't understand the answers very well themselves.
Doesn't the author basically admit that when he prompts someone else to write "falsehoods programmers believe about TCP"? After all, if the author did have the understanding himself he could do it himself.
The reset of the writing just laments the pain of using products that make incorrect assumptions – continuing in same lamenting from the quoted segment he includes. It almost has nothing to do with TCP at all, so it is not clear where the parent comment here got the idea that it was trying to teach something about it.