[LenHolgate]

The protocol preserves message boundaries but not fragment boundaries. You may send a message of, say, 100 bytes and get 100 x 1 byte fragments arrive, or you may send 100 x 1 byte fragments and get 100 bytes in a single frame. The main issue, for me, at the time, was that when you get that first 1 byte frame there's no way to know how big the resulting message will be.

Luckily there's a rather excellent compliance test suite, here: http://www.tavendo.de/autobahn/testsuite.html which should go a long way to help nail interop issues.

[marshray]

when you get that first 1 byte frame there's no way to know how big the resulting message will be

So that's a design tradeoff. I've implemented protocols that did it both ways and it's definitely easier on the guy trying to implement a library or other receiving application if he can get a reasonable upper limit on the size of the messages.

But on the other hand, by not requiring the total message length be known in advance, it eases the logical (and memory) burden on the sender. Often the sender will be an overloaded server.

Nothing can prevent a higher-level protocol on top of WS from negotiating its own max message size.

So the design choice that was made would seem to allow optimizations for the overloaded server case without prohibiting other optimizations. This is typical of W3C protocols.

[simpsond]

Well, all frames actually do have length in the header. It's just not the first byte... it's the lowest 7 bits of the second byte, and possibly more (check the spec).

So, if I can read 2 bytes from my buffer, I can get a good idea of the message size. If I only have 1 byte, I rewind and wait until I receive another.

[marshray]

But we're talking about messages, not frames. http://tools.ietf.org/html/rfc6455 "frames have no semantic meaning"

If Websocket developers begin making unwarranted assumptions about message framing and fragmentation you will regret it. BELIEVE ME.

/me gets back to bugfixing