Changes

Jump to: navigation, search

Remote Debugging Protocol Stream Transport

3 bytes added, 01:47, 9 November 2012
[bulk-transport 0bd62f5] Revise transport per mail comments.
where:
<ul>
<li>The keyword <code>bulk</code> is the four encoded in ASCII characters 'b', 'u', 'l', and 'k';<li>there is the spaces are always exactly one ASCII space character (the single byte 0x20) between <code>bulk</code> and <i>actor</i>, and between <i>actor</i> and <i>length</i>;.
<li><i>actor</i> is a sequence of Unicode characters, encoded in UTF-8, containing no spaces or colons;
<li><i>length</i> is a sequence of decimal ASCII digits; and
== Implementation Notes ==
=== ZeroConstant-copy Overhead Bulk Data ===
Mozilla added bulk data packets to the protocol to download profiling data from let devices with limited memory upload performance profiling data more efficiently. Profiling data sets need to be as large as possible, as larger data sets can cover a longer period of time or more frequent samples. However, converting a large data set to a JavaScript object, converting the that object to a JSON text, and sending the text over the connection entails making several temporary complete copies of the data; on small devices, and thus this limits how much data the amount that profiler can be collectedcollect. We wanted to let Avoiding these temporary copies would allow small devices to collect and transmit larger profile data while making as few temporary copies as possiblesets. Since it seemed likely that other sorts of tools would need to exchange large binary blocks efficientlyas well, we wanted this capability to be a solution usable by any all protocol participantparticipants, rather than being one tailored to the profiler's specific case.
In our implementation of this Stream Transport, when a participant wishes to transmit a bulk data packet, it provides the actor name, the data's length in bytes, and a callback function. When the underyling stream is ready to send more data can be sent, the transport writes the packet's <code>bulk <i>actor</i> <i>length</i>:</code> header, and then passes the callback function the underlying <code>nsIOutputStream</code>, and to the callback , which then writes the packet's <i>data </i> portion directly to the stream. Thus, the transport itself requires no intermediate copies of the data; the packet can be sent as efficiently as the underlying tool can manage. Similarly, when a participant receives a bulk data packet, the transport parses the header, and then passes the actor name and the transport's underlying <code>nsIInputStream</code> directly to a callback function registered for the purpose. The callback function can then consume , which consumes the data directly. Thus, while the callback functions may well use fixed-size buffers to send and againreceive data, the transport itself requires imposes no intermediate copiesoverhead proportional to the full size of the data.
<!-- Local Variables: -->
<!-- eval: (visual-line-mode) -->
<!-- End: -->
Confirm
496
edits

Navigation menu