12 ms·

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 m

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 http://www.tavendo.de/autobahn/testsuite.html which should go a long way to help nail interop issues.

marshray 15y ago
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 15y ago
  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 15y ago
    But we're talking about messages, not frames. http://tools.ietf.org/html/rfc6455 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
deleted 15y ago
[deleted]

marshray 15y ago

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 15y ago
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 15y ago
  But we're talking about messages, not frames. http://tools.ietf.org/html/rfc6455 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

deleted 15y ago

[deleted]