4 ms·

In some contexts, sure, you could say literally nothing is "guaranteed." But in this context, we're clearly talking about how distributed systems work in practi

In some contexts, sure, you could say literally nothing is "guaranteed." But in this context, we're clearly talking about how distributed systems work in practice, and which behaviors you can reasonably achieve and what tradeoffs you must make. The article clearly states: > There are essentially three types of delivery semantics: at-most-once, at-least-once, and exactly-once. Of the three, the first two are feasible and widely used. But in the context you're talking about, even those first two are not "feasible." And in the context you're talking about, there's basically no point in talking about anything you can do to try to achieve certain behavior since there is technically no way to physically guarantee that. What you are saying is definitely not "the point of these conversations," because you're just saying that literally nothing can ever be absolutely guaranteed. Technically true, but not particularly helpful when you're designing real systems to solve real problems, and your systems will mostly operate on infrastructure that mostly does work as intended.

ddulaney 4y ago
I work in financial data — lots of big ol’ UDP multicast streams getting replicated by big routers in private data centers on private lines. In that context, everything bad can happen, but it rarely does. For example: packets most definitely get dropped, but not every packet does in practice. Packets can get double-sent, but again, not every packet in practice. Packets can get corrupted randomly, but again, not every packet in practice. The hard mathematical guarantee: nothing at all! You will get a packet from 0 to N times, where N might be arbitrarily large. The in-practice behavior: mostly kinda works, but be careful! Have a strategy for reordering, a strategy for detecting and handling dupes, and a strategy for when you need to just give up and start from scratch. The internet is like that but if some router is screwing it up, you can’t call the owner and complain.
- salawat 4y ago
  You're not trying hard enough. I spent an afternoon on the phone with an ISP in Boston letting them know their BGP was hosed, and consequently black hole'ing my traffic. I had the traceroutes and whois data to prove it. Nowadays though, it is getting much harder to do so however. I know there's a secret IRC of black belt NetOps out there, but I haven't managed to figure out how to route myself there yet. (Rumor has it there's a router out there with a reliably flaky network card that'll mangle the packets juuuuuust right. Personally, I think it's all hooey and someone has a really neat IPTables file complete with port knocking)
jerf 4y ago
There's a bit of daylight between "feasible" and "guaranteed". It turns out it really isn't that much daylight, and it's really easy to overestimate the size of that window. As you scale up, that window gets smaller and smaller, too, which makes it even more exciting. Nevertheless, it is indeed where real systems are built. I also disagree that realizing that nothing can be guaranteed is not important to building systems. The more you scale up, the more important it is. It's hugely important. It's one of the major things that separates people who can build real network systems at scale and those who can't. Far from the only such thing, but certainly one of the important ones.

ddulaney 4y ago

I work in financial data — lots of big ol’ UDP multicast streams getting replicated by big routers in private data centers on private lines. In that context, everything bad can happen, but it rarely does. For example: packets most definitely get dropped, but not every packet does in practice. Packets can get double-sent, but again, not every packet in practice. Packets can get corrupted randomly, but again, not every packet in practice. The hard mathematical guarantee: nothing at all! You will get a packet from 0 to N times, where N might be arbitrarily large. The in-practice behavior: mostly kinda works, but be careful! Have a strategy for reordering, a strategy for detecting and handling dupes, and a strategy for when you need to just give up and start from scratch. The internet is like that but if some router is screwing it up, you can’t call the owner and complain.

salawat 4y ago
You're not trying hard enough. I spent an afternoon on the phone with an ISP in Boston letting them know their BGP was hosed, and consequently black hole'ing my traffic. I had the traceroutes and whois data to prove it. Nowadays though, it is getting much harder to do so however. I know there's a secret IRC of black belt NetOps out there, but I haven't managed to figure out how to route myself there yet. (Rumor has it there's a router out there with a reliably flaky network card that'll mangle the packets juuuuuust right. Personally, I think it's all hooey and someone has a really neat IPTables file complete with port knocking)

jerf 4y ago

There's a bit of daylight between "feasible" and "guaranteed". It turns out it really isn't that much daylight, and it's really easy to overestimate the size of that window. As you scale up, that window gets smaller and smaller, too, which makes it even more exciting. Nevertheless, it is indeed where real systems are built. I also disagree that realizing that nothing can be guaranteed is not important to building systems. The more you scale up, the more important it is. It's hugely important. It's one of the major things that separates people who can build real network systems at scale and those who can't. Far from the only such thing, but certainly one of the important ones.