- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Fri, 05 Mar 2010 13:13:31 -0800
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
Received on Friday, 5 March 2010 13:13:31 UTC