WebSocket is over TCP, so still ordered. I think by message-based GP is talking not only about message framing (which WebSocket provides) but also reliable out-of-order delivery.

When does a long out of order delay look like a packet loss?

Is it possible for an out of order packet to get delayed by a millisecond? A second? A minute? An hour?

Have you written code to be robust to this?

Other people have probably thought about it more than I have, but the way I see it working is that a set of unacked messages are stored on each end of the connection. When a connection receives a message, it acks it by ID. When acks come out of the order the client sent them in (or after a timeout period), it re-sends the packet that may have dropped.

If every message is getting dropped, the set of unacked messages fills up and the connection stops accepting messages from the application, similar to TCP in that situation.

I mostly work with TCP so haven't had to deal with unreliable channels generally, but I do use a similar approach at the application level for reliable delivery across reconnects.

My point is that a lost message looks the same as an arbitrary delay.