On 05.03.2010, at 12:56, Olli Pettay wrote:
And you're saying that javascript really needs to know about the
frame boundary bytes to detect if it is streaming too fast.
Doesn't sound likely to me.
OK
That's true, but I don't know how many of these have already been
sent
unless I perform lots of additional bookkeeping.
"lots"
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?
You could for example have a circular list for the frame boundary byte
indexes and when something is removed from the queue, you just update
the pointer which points to the first frame boundary byte index in the
queue. Then if the circular list is implemented in a reasonable way,
counting all the frame boundary bytes in the queue is just one
subtraction.
Yes, that's lots of work for something no one should care about, as
you implied above. And that's work that makes the results slightly
misleading, even if that's so slightly that it's not important in
practice.
Remembering frame offsets even after data has been serialized to a
stream is an unusual requirement for networking code.
- WBR, Alexey Proskuryakov
