News for hackers. Stuff that matters.
Re:Google pub/sub released an ordering feature by jerf on Friday October 02, 2020 @10:31AM (#24662986)
"What's a use case where strict ordering is critically important?"

In general, as the use case grows, every use case where the developers did not make explicit and careful provision for ensuring that order is not important, with quite non-trivial effort.

Even a lot of systems whose developers think they have no ordering dependencies are wrong in at least one subtle way without realizing it.

If you need to megascale, you're going to have to bite the bullet and build a system that can handle out-of-order, but there's a lot of systems out there where you don't need megascale, and you can get rid of that "quite non-trivial effort" to deal with out-of-orderness by asking for messages to arrive in order.

To get a sense of just how useful that can be... bear in mind that every time you open a TCP socket instead of a UDP one, you just made exactly that choice, to use an ordered message system when you didn't "need" one. Take a look at everything you do with a TCP socket and think about trying to run it over UDP, and not with something like QUIC that basically adds half of TCP back on it, but with UDP straight-up. That's what kind of things can use in-order delivery... lots of things.

Almost everything can be simplified by guaranteed in-order delivery. It's just that some things can't afford the downsides.

Re:Google pub/sub released an ordering feature by staticassertion on Friday October 02, 2020 @11:57AM (#24663930)
I can understand your post, but I don't quite buy the TCP thing. I don't think anyone is using TCP for ordering, they're using it because they don't want their packet dropped.

I guess all of the systems I build are just built to assume no order/ or to leverage causal ordering, because that feels much easier to reason about - enforcing ordering feels really hard, and like something that a message bus can only do some of the work of.

Re:Google pub/sub released an ordering feature by zeroxfe on Friday October 02, 2020 @12:10PM (#24664063)
> I can understand your post, but I don't quite buy the TCP thing. I don't think anyone is using TCP for ordering, they're using it because they don't want their packet dropped.

Think of (almost) any modern protocol built on top of TCP, and you'll see that ordering is critical. (http, smtp, telnet/ssh, etc.)

Re:Google pub/sub released an ordering feature by staticassertion on Friday October 02, 2020 @01:25PM (#24664857)
Gotcha, ok so specifically protocols built on TCP.
Re:Google pub/sub released an ordering feature by heavenlyblue on Friday October 02, 2020 @12:28PM (#24664250)
There's no ordering in HTTP. If you could send a whole HTTP request as a UDP packet you'd get exactly the same protocol (obviously sans WebSockets - but you could work around that).
Re:Google pub/sub released an ordering feature by duijf on Friday October 02, 2020 @01:16PM (#24664766)
There are numerous valid HTTP payloads that are larger than a single TCP/UDP packet.

Ordering is important in these cases.

Re:Google pub/sub released an ordering feature by heavenlyblue on Saturday October 03, 2020 @09:28AM (#24671955)
I think I made a point that “if you could fit the whole HTTP request in one UDP packet”, have you read my message?
Re:Google pub/sub released an ordering feature by 0xEFF on Friday October 02, 2020 @01:44PM (#24665029)
How would you process an unordered response?
Re:Google pub/sub released an ordering feature by heavenlyblue on Saturday October 03, 2020 @09:35AM (#24671989)
As I have said - you fit in in a single datagram
Re:Google pub/sub released an ordering feature by whatshisface on Friday October 02, 2020 @12:54PM (#24664529)
I'm not sure that ordering doesn't matter for most TCP data. For example, HTTP depends on ordering. Any time you are transmitting messages larger than the size of a packet, you need some degree of ordering, even if it's only to reconstruct the individual messages, when you don't care about the order of the messages.