Within a single connection, the message order (more precisely the START of the message) is guaranteed.
The only situation where this nuance is important to understand is when you are using Streaming message handling.
Each incoming message results in a new stream, that must be handled via dispatching the start of the message to your handler.
If your handling isn't fast enough, then it might seem that you are getting messages out of order, but in reality you are not.
Its just that you got the following ...
On the wire:
[A], 1, 2, 3, 4, 5, [A-FIN], [B], 1, 2, 3, [B-FIN]
Dispatching:
[A] [B]
Your code:
[onMessage(Stream(A))], r1, r2, r3, r4, r5, [A.close()]
[onMessage(Stream(B)], r1, r2, r3, [B.close()]
Which make it appear as if you got B before A finished, which is very likely and probable.
There was a time period where we would not dispatch Stream(B) until Stream(A) was closed, but this behavior was highly confusing to users of the API.
And to accomplish it we would have to stop reading from the WebSocket endpoint (even CLOSE/PING/PONG frames!) until that occurred.
Either that or we start queuing messages, especially problematic if the messages are short!
With short messages, its very probable that a single network read can result in more than 1 websocket message.
In this case, there would be multiple dispatches, in quick succession.