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

201–210 of 247 posts

Re: Falsehoods programmers believe about TCP

#201

Post by Groxx »

cubano wrote: post #89
raggi wrote: post #61

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

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

What, you've never heard of a "black light" before? They just turn on the black sub-pixels.

https://en.wikipedia.org/wiki/Blacklight

Re: Falsehoods programmers believe about TCP

#202

Post by Bognar »

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 implementations are an abstraction that work 99.99% of the time, but are still vulnerable to two generals when you look close. TCP is implemented in the kernel with a buffer, the kernel responds with ACKs before an application reads the data.

There is no guarantee that the application reads from that buffer (e.g. the process could crash), so the client on the other end believes that the application has received the message even though it hasn't.

The kernel is handling at-least-once delivery with the network boundary and turning it into at-most-once with the process boundary.

Re: Falsehoods programmers believe about TCP

#203

Post by zinekeller »

krick wrote: post #188
lovecg wrote: 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.

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…

> Claiming you should not assume any name can be spelled in Unicode is absurd as well.

China (and Japan, and to a certain extent Korea and Viet Nam) exists? https://en.wikipedia.org/wiki/Naming_laws_in_China#Notable_c...

I'm pretty sure that patio11, having spent his life in Japan, would know that technology like SING glyphlets exists because of this exact issue.

(and before you answer "what are you talking about, it is in Unicode?", these characters are literally added after the relevant issue surfaced, and some characters like 𱅒 (U+31152) are recent additions that don't even render properly)

Re: Falsehoods programmers believe about TCP

#204

Post by theluketaylor »

thayne wrote: post #176
School-Cotton wrote: post #136

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

> I don’t think that’s too rare in the US eithe Anecdotal, but the only people I've met in the US with more than one middle name are people who originally came from another country. Although, I wonder if maybe that is enforced by the fact tha legal forms and similar typically assume you only have first, last, and optionally a (single) middle name.

George Herbert Walker Bush comes to mind as a native son of the US with multiple middle names. He used H. W. in politics, but that still includes some whitespace and non-traditional characters.

Re: Falsehoods programmers believe about TCP

#205

Post by School-Cotton »

theluketaylor wrote: post #204
thayne wrote: post #176

Earlier quoted context omitted.

> I don’t think that’s too rare in the US eithe Anecdotal, but the only people I've met in the US with more than one middle name are people who originally came from another country. Although, I wonder if maybe that is enforced by the fact tha legal forms and similar typically assume you only have first, last, and optionally a (single) middle name.

George Herbert Walker Bush comes to mind as a native son of the US with multiple middle names. He used H. W. in politics, but that still includes some whitespace and non-traditional characters.

Or George R. R. Martin.

Re: Falsehoods programmers believe about TCP

#206

Post by Uptrenda »

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 noticed that too and thought I was missing something. Some cool resources that are actually decent for network programming:

https://beej.us/guide/bgnet/ -- Covers what abstractions the OS provides for network programming and the guarantees that are possible.

https://www.madwizard.org/programming/tutorials/ - This is the very first ever good tutorial I read on socket programming. It's OG winsock. Introduces network programming from the most basic level. Aimed at C.

When you understand these guides you'll learn that how you structure your entire programs networking depends on whether you want to use blocking or non-blocking sockets. If you go with blocking you'll probably be using threads or processes. Otherwise you can't do any other work. With non-blocking it will be more about polling sockets and eventually you might end up with something resembling an event loop.

Until you come towards to the current approach to networking which is mostly async await -- an event loop works with non-blocking sockets, watches them for changes, and passes data from them to event handlers. There's a lot more that can be done on sockets to effect things like how data is flushed, how TCP errors are handled, and so on, but its a good start.

Re: Falsehoods programmers believe about TCP

#207

Post by rcxdude »

bcoates wrote: post #53
solatic wrote: post #22

Related: you can get at most once delivery or at least once delivery; you cannot get exactly once delivery. If I had a dollar for every junior who thought that a lack of exactly once delivery guarantees was a bug...

This is a popular saying that is basically wrong. You have very limited guarantees around an arbitrarily bad partition, but this is also a detectable condition. Lots of defective systems exist, but in general non-defective systems generally guarantee "exactly once delivery or detected failure"

That sounds like "at most once" to me

Re: Falsehoods programmers believe about TCP

#208

Post by ooterness »

ameliaquining wrote: post #132
ooterness wrote: post #11

Earlier quoted context omitted.

Pedantically: TCP has segments, IP has packets, and Ethernet has frames. They are one-to-one in simple cases, but not always. https://networkengineering.stackexchange.com/questions/50083... In particular, fragmentation by intermediate routers means that the server and receiver may disagree about the frame and packet boundaries. TCP is expected to make a "reliable" pipe-like service out of whatever happens, and the ap…

I think I've heard the term "packet" used to refer to the general category of thing that Ethernet frames, IP packets, and TCP segments are all examples of.

Colloquially, yes, they're all just packets unless I'm writing an RFC for the IETF.

If I recall correctly, the formal term for the all-encompassing category is the "datagram".

It's like who-vs-whom. Prescriptivists will try to tilt that windmill forever, descriptivists observe that most people just don't care.

Re: Falsehoods programmers believe about TCP

#209

Post by rcxdude »

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…

What part of the article do you think pertains to error correction codes or data checksumming? The first four points are true even if the transmission medium never changes bytes, just becomes unavailable at a given point.

Re: Falsehoods programmers believe about TCP

#210

Post by [deleted] »

adrianmonk wrote: post #80
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 don't think you're taking into account the context or intended audience. It's a casual forum message posted in reply to someone else's message. They have not written a "falsehoods programmers believe" article. They have proposed that one ought to be written and have given a starting point for what it might cover. They offered their list to "get the ball rolling", confirming that they don't see it as a finished prod…

[deleted]
Post reply on HN