[staticassertion]

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.

[zeroxfe]

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

[staticassertion]

Gotcha, ok so specifically protocols built on TCP.

[heavenlyblue]

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

[duijf]

There are numerous valid HTTP payloads that are larger than a single TCP/UDP packet.

Ordering is important in these cases.

[heavenlyblue]

I think I made a point that “if you could fit the whole HTTP request in one UDP packet”, have you read my message?

[0xEFF]

How would you process an unordered response?

[heavenlyblue]

As I have said - you fit in in a single datagram

[whatshisface]

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.