- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Fri, 05 Mar 2010 23:17:51 +0200
On 3/5/10 11:13 PM, Alexey Proskuryakov wrote: > > 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 lots? I wouldn't call that "lots". > for something no one should care about, as you > implied above. From API perspective I do care. Web developers shouldn't need to know about the protocol, yet (s)he should be able to understand what bufferedAmount means. -Olli > 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:17:51 UTC