On 05.03.2010, at 10:27, Olli Pettay wrote:
I was going to mention this as the primary reason why frame bytes
should
be included. JavaScript code needs this information for flow control,
Why?
I assume you are asking why JavaScript code needs this information for
flow control.
My recollection is that feature was added as a result of discussions
about implementing flow control. How else are you supposed to know
that you're streaming too fast without modifying the server? Since
WebSockets is a match for TCP/IP, and the latter provides ways to
adaptively change data rate, it's natural that one expects the same
from WebSockets.
and it's raw bytes that are sent over the tubes, not original message
strings.
Right. But this is about the API. I assume the underlying protocol may
change or the API can eventually support different kinds of protocols
(some may use UPD, some TCP, some send text, some binary).
The API usage should be still the same, if possible.
This is something we agree about.
I guess the root of our disagreement is in how one uses the API. I'm
saying that the interesting question is how many bytes are buffered to
be sent over the wire, so in order to keep the API usage the same we
need to include protocol overhead in this number.
In WebKit, we'd have to queue
unsent messages separately just to implement this quirk (see
https://bugs.webkit.org/attachment.cgi?id=50093 for a proof of
concept).
It becomes very difficult to implement we decide to add size of data
that an underlying network library buffers internally - which I think
would be a reasonable thing to do.
I don't see why that would be difficult. If you know you have just
written x bytes to the whatever network method, you know how many
bytes
of those were frame markers.
That's true, but I don't know how many of these have already been sent
unless I perform lots of additional bookkeeping. Consider sending
"data" message three times in a row:
\x00data\xFF\x00data\xFF\x00data\xFF
If we are to exclude protocol overhead in bufferedAmount, and we know
that there are 8 bytes still queued (a\xFF\x00data\xFF), and we know
that there were three frames sent (with an overhead of 6 bytes) how
would we know that the answer is 5?
- WBR, Alexey Proskuryakov
