Live data from Hacker News

Falsehoods programmers believe about TCP

lwn.net

241–247 of 247 posts

Re: Falsehoods programmers believe about TCP

#241
post #199
post #188

Earlier quoted context omitted.

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.

No, he one proved that other people don't need to put up with your bs if you try to break conventions. Hence your use of ASCII "Prince" being entirely adequate.

Besides, AFAIK he only changed his stage name, not his legal name.

Re: Falsehoods programmers believe about TCP

#242
post #67

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

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 means allcaps family name followed by normal case given name.

Re: Falsehoods programmers believe about TCP

#243
post #10

Earlier quoted context omitted.

5 and 6 are mutually exclusive. They don't make sense logically. And most of the list was never explained at all.

The point is that a lot of stuff in Networking (and Computer Engineering in general) is very context dependent, and that you cannot be extremely opinionated about this stuff.

No context was ever provided.

Re: Falsehoods programmers believe about TCP

#244
post #33

Earlier quoted context omitted.

> 6. There is no such thing as a TCP packet Because the software abstraction is a stream of bytes; and it's up to the application to decide where the "packets" begin and end. For example, I might write to a TCP socket: 100 bytes, 50 bytes, and then 125 bytes. BUT, the receiver could get: A single event with 275 bytes. Or it could get an event with 75 bytes and then an event with 200 bytes. Or it could get 11 events o…

If you have a look at the underlying network traffic, you'll see IP packets carrying TCP data, ie. The protocol field in the IP packet header will be set to TCP; this could be assimilated to a TCP packet.

Well, maybe...

Re: Falsehoods programmers believe about TCP

#245

> "7. If we fail to connect to a well-known remote host, then we must be offline." Now that is a very interesting one! It's sort of related to the question: "How much of the Internet is accessible from any given point (location, locality, etc.) at any given point of time?" Which is sort of unknowable, at least, without attempting to connect with every possible connection point on the Internet, which (if it could be d…

Related: https://en.wikipedia.org/wiki/Complementarity_(physics)

Re: Falsehoods programmers believe about TCP

#246
post #199

Earlier quoted context omitted.

I think Prince proved the Unicode assertion. He had to distribute his own custom font so news outlets could continue to write about him.

No, he one proved that other people don't need to put up with your bs if you try to break conventions. Hence your use of ASCII "Prince" being entirely adequate. Besides, AFAIK he only changed his stage name, not his legal name.

I thought he really did change his legal name, in an attempt to get out of a contract.

Re: Falsehoods programmers believe about TCP

#247
post #155

Earlier quoted context omitted.

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

Yes, but the handoff can fail in the same way (it can't know if the thing it's handing off to actually got it). But the application can also just be resilient to that with idempotent operations and have the handoff be at-least-once.

> the handoff can fail in the same way

Everything in a digital system can fail, but by convention (and because it's not so far from the actual truth) some parts are assumed to be 100% reliable when modeling them. If you don't make this assumption, you can't guarantee anything.

Post reply on HN