[dead]
Falsehoods programmers believe about TCP
51–60 of 247 posts
Re: Falsehoods programmers believe about TCP
#52[dead]
Re: Falsehoods programmers believe about TCP
#53Related: 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"
Re: Falsehoods programmers believe about TCP
#54I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
Falsehoods falsehood-list makers believe.
1. That said items are falsehoods in the first place.
2. That said items are necessarily interesting or noteworthy.
3. That a list is necessarily the best format to present said items.
4. That they may speak for the involved parties beliefs.
Re: Falsehoods programmers believe about TCP
#55So 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.
> Set larger kernel TCP send and receive buffers and enable BBR congestion control
I mean yeah, but that requires having access to the kernel config. so for most people multiplexing TCP is a useful way to maximise a link, without having to fiddle with stuff that is a pain to deploy. (politically as well as logistically)
I deployed this "technique" before BBR was a thing. It worked well enough for what I needed it to do (move large images from London to California) It was pretty simple to engineer as well (mainly because I didn't have to make a fancy custom error detection/correction/rate limiting system over UDP )
Re: Falsehoods programmers believe about TCP
#56I 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.
Saying a thing and then saying the opposite, without elaborating, is not good at making you THINK. This list is doing it wrong.
Re: Falsehoods programmers believe about TCP
#57I'll go out on a limb: inside datacenter on your own hardware, you can safely ignore low-level pedantry and mostly ignore “weird networks” and use TCP as two-way Unix pipe. “Mostly” because you still care about bandwidth limits and packet RPS limits and latency of course.
I wouldn't, unless you've got a really solid understanding of your datacenter network and it's 100% good all the time. Which is unlikely, from my experience as a server person.
If you've got dirty optics between two switches, now you're getting packet loss and TCP rears its head. Hopefully it's not an issue now, but diagnosing microbursting[1] was lots of fun, and really wigs TCP out. I've also run into 'fabric congestion'. My true favorite though is when you've got 2x aggregation on servers, and 4x aggregation for top of rack switches to spine switches, so there's 8 paths in each direction between two servers in adjacent racks, and only one path (sometimes in only one direction) is only running at 99.9%. That's a real PITA to track down unless you have visibility into switching metrics.
[1] https://en.m.wikipedia.org/wiki/Micro-bursting_(networking)
Re: Falsehoods programmers believe about TCP
#58I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
I agree. This isn't even a good one of those lists. It's more like "dubious pedantry to make me feel smart about my TCP knowledge".
1-4. Yes we know about the 2 generals problem. And yes we know what "reliable" means in this context. 5-6. This is just stupid. 7. Obviously not true. Nobody thinks this. 8-9. The reasons for and flaws of Nagle's algorithm are well known. 10. This isn't even true. Most of the time you don't need to care about it. That's the whole point of abstraction. You need to care about it if you are doing extensive performance optimisation, but usually you aren't. 11. Again untrue. You can think of TCP as a two way pipe. Again that's the whole point of abstraction. 12. Not sure exactly what they're trying to say here but again it's very well known that TCP and UDP are pretty much the only protocols that are likely to work on the internet. 13. Ditto. We all know why so many protocols are "over HTTPS", e.g. DoH. 14. This isn't a technical point. 15. Dunno what this is talking about but I'm guessing it's along the lines of "a byte is 8 bits", i.e. it is actually true in the modern world.
Re: Falsehoods programmers believe about TCP
#59Earlier quoted context omitted.
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
Also known as ERR_FUCK_YOU. Yes, I know that I'm connected to a misbehaving wifi router. Just load the fucking page.
Re: Falsehoods programmers believe about TCP
#60I 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.
.. on Linux. If you do that on Windows the MAC will detect the loss of link pulses, report the interface as down, and Windows will "helpfully" reset all your TCP connections.
That seems like way more sensible behaviour.