121–130 of 247 posts
I mean, that's true, insofar as pipes have incredibly weak guarantees too — after all, the other end of a pipe might be a program reading from/writing to a network socket, or other unreliable transport. Whenever you let your program be plugged into an arbitrary pipe, you have to expect all that same flakiness and then some.
Earlier quoted context omitted.
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 conge…
Agreed. Having done Akka.NET Remote/Cluster setups in prod that survived multiple 'new to the org' categories of DC Failures at their level of scale/capacity [0] there's a lot to account for if you want to keep everything happy and visible [1][2][3] [0] - Cut fiber between DCs, Rack failures due to IO-ish type issues, bad switches... at least 2 out of 3. [1] - The upshot was we were able to survive all of the scenari…
Yeah, my Erlang clustering experience was that we (the customer) were the monitoring system for the DC/managed hosting provider. Although, by the time we left there, they would have outage notifications before we put in tickets.
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?
> 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…
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…
> That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format. Neither TCP nor Ethernet provide for forward error correction. Ethernet frames include a 32-bit CRC while TCP segments use the so called "internet checksum".
I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
Earlier quoted context omitted.
Why not? (Please see the update on my OP before answering that.)
The mechanism you're describing already exists. TCP has sequence numbers. It can drop duplicate data. The difference between "processing" and "delivery" relates to "network capacity." Process handling wastes capacity in favor of latency. Delivery handling increases latency in favor of capacity. Systems which have "exactly once" delivery typically do so with "send/receive" and "release/delete" message pairs. You need…
Yes, I know, which makes it all the more bizarre that people are claiming that this is impossible.
> Systems which have "exactly once" delivery typically do so...
Ah, so exactly-once delivery is possible after all?
Earlier quoted context omitted.
Uhhh....how does the screen show black?
The screen knows what color it displays at all times. It knows this because it knows what it doesn't. By subtracting what it does from what it doesn’t, or what it doesn’t from what it does (whichever is greater), it obtains a difference, or deviation. The controller board uses deviations to generate corrective commands to drive the display from a state where it does not display black to a state where it does, and arr…
Earlier quoted context omitted.
That seems like a distinction without a difference to me. Why should I care if the thing I get exactly one of is called "processing" or "delivery"?
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…
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 if I have at-least-once delivery. In fact, I claim that writing such a library is an elementary exercise. The TCP protocol is an existence proof. Where is the flaw in my reasoning?