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

31–40 of 247 posts

Re: Falsehoods programmers believe about TCP

#31

Post by nh2 »

KaiserPro wrote: post #24

So TCP has slow start, and exponential fall off and shit. but you can get round that in a lot of cases by just having a load of TCP connections in parallel. TCP is cheap and well optimised, especially if you are keeping a bunch of connections open. (opening can be expensive) so if you have a high latency connection, or a bit of packet loss, and you want to reach line speed without having to figure out cornercases wit…

Such hack is often not necessary.

Set larger kernel TCP send and receive buffers and enable BBR congestion control. Speed will usually be good also across high latency links, and no multiplexing logic needed. Especially if you control both sides of the connection.

Re: Falsehoods programmers believe about TCP

#32

Post by IAmNotACellist »

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

The following list contains only falsehoods:

1. You're wrong

2. Okay, you're right

3. Okay maybe you're right or wrong but certainly not both

Re: Falsehoods programmers believe about TCP

#33

Post by gwbas1c »

saghm wrote: post #2

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

> 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 of 25 bytes.

> 5. There is a such thing as a TCP packet

This one I struggle with. I think the author is talking about connection set up, acking, and connection teardown.

Re: Falsehoods programmers believe about TCP

#34

Post by efitz »

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

You’re doing it wrong.

“Falsehoods programmers believe…” articles are designed to make you THINK about problematic assumptions. They are not like the 10 commandments and they are not decrees of absolute truth.

Re: Falsehoods programmers believe about TCP

#35

Post by astrobe_ »

ordu wrote: post #15
fracus wrote: 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.

> They don't make sense logically In practice such situations can arise in one of two cases: 1. some non-sense creeped in 2. logic is applied to a self-contradictory set of axioms and definitions. (1) is not very interesting, but (2) happens frequently enough because people often do not try to formalize their definitions and axioms. As a consequence they are using some vague concepts and their statements are true in…

Yes. If one applies correctly the rules of logic on inconsistent axioms, the conclusions will be inconsistent. If one incorrectly applies logic to inconsistent axioms, the conclusions may or may not be consistent. It happens IRL sometimes; "being right for the wrong reasons". That being said, I suspect the game of the author is to play with leaky abstractions. TCP is a stream-oriented protocol, but is implemented on top of frames etc.

Re: Falsehoods programmers believe about TCP

#36

Post by poorman »

> Explainer for 1-4: https://en.wikipedia.org/wiki/Two_Generals%27_Problem. TL;DR: If the connection breaks while an ACK is outstanding, the sender will have no way of knowing whether the segment was received, and this turns out to be an insoluble problem no matter how much complexity you pile on top of it. You need something resembling Paxos or Raft to get a guarantee like that

The hashgraph algorithm is pretty sweet too and doesn't have the issue of a single write leader like Paxos and Raft. Basically multi-writers / leaderless

https://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf

But to be fair, I'm not certain that CAP theorem and partition tolerance really belong in a conversation about TCP anyway

Re: Falsehoods programmers believe about TCP

#37

Post by sgerenser »

toast0 wrote: post #18
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.

Depends on OS settings these days. Lots of OSes want to help and detect link down and reset all your connections. Kind of a pain when you just want to move a cable.

Like Chrome’s oh so helpful ERR_NETWORK_CHANGED

Re: Falsehoods programmers believe about TCP

#39

Post by hnlmorg »

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

Post reply on HN