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

111–120 of 247 posts

Re: Falsehoods programmers believe about TCP

#111

Post by jerf »

devman0 wrote: post #95
Rauchg wrote: post #83

Earlier quoted context omitted.

Falsehoods programmers believe: the OSI model

Falsehoods programmers believe: the OSI model is useless

Sure, it's misleading, needs a lot of "interpretation" doing a non-trivial amount of the lifting to make it map to anything in the real world, mismatches things that happen in the real world while leaving no room for other things that happen in the real world a lot, and will lead anyone who tries to use it to understand the real world deeply astray, but it isn't always wrong about absolutely everything so it has some non-zero "utility".

Fine. It's not wrong about absolutely everything all the time. It isn't bereft of all truth. It's just something that is of net negative value. I see no value in insisting on trying to "rescue" a net-negative value model of the world.

I suppose you could say ultimately I agree with you though. The OSI model isn't useless. It's worse than useless. You're better off trying to understand networking from basic first principles than through the lens it provides.

Re: Falsehoods programmers believe about TCP

#113

Post by 8organicbits »

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…

> because you don't know the ID of your message yet

Wouldn't the client know the ID if they randomly generated it? (honest question)

Re: Falsehoods programmers believe about TCP

#114

Post by jerf »

lisper wrote: post #102
shepherdjerred wrote: post #84

Earlier quoted context omitted.

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"?

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 remove the need to think about how your processing code works. It isn't exactly the same.

This is why people like me insist it's important to understand that you can not have exactly-once delivery. There is no library that can make that just go away, they can only shuffle around exactly where the lumps under the carpet live, and if one programs with the mistaken idea that these libraries really do solve "exactly once" delivery, one will get into deep trouble. Possibly the "my architecture is fundamentally broken and can't be rescued" sort of trouble.

Re: Falsehoods programmers believe about TCP

#115

Post by ahazred8ta »

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

Previously: "falseoods programmers believe about X":

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Re: Falsehoods programmers believe about TCP

#116

Post by nilamo »

ahoka wrote: post #100
cubano wrote: post #89

Earlier 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…

[flagged]

Re: Falsehoods programmers believe about TCP

#117

Post by shepherdjerred »

lisper wrote: post #102
shepherdjerred wrote: post #84

Earlier quoted context omitted.

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"?

I don't know enough to answer this. I'm sure there is plenty of writing on this subject from people more qualified than me.

Re: Falsehoods programmers believe about TCP

#118

Post by koala_man »

9dev wrote: post #65
hnlmorg wrote: post #39

Earlier quoted context omitted.

I’m pretty sure originals that defined this format did have examples and citations. But I do agree that some of the later entries have felt a little lazy.

Right, I was about to comment that. One of the first ones I remember was this one, about addresses[1]; or this one, about names[2]. Both provide examples and information, which is the only thing making the whole article useful. [1]: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ [2]: https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/

I remember the address one. It was fantastic and I loved it. I wish they were all that helpful.

Re: Falsehoods programmers believe about TCP

#119

Post by okl »

ijustlovemath wrote: post #108

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…

> That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format.

Neither TCP nor Ethernet provide for forward error correction. Ethernet frames include a 32-bit CRC while TCP segments use the so called "internet checksum".

Re: Falsehoods programmers believe about TCP

#120

Post by [deleted] »

ijustlovemath wrote: post #108

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…

[deleted]
Post reply on HN