Closed Bug 20408 Opened 20 years ago Closed 20 years ago

need to parameterize buffer size for transports

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: mscott)

Details

We need to parameterize the buffer size for transports so that images can use a
different buffer size than html, etc.
Status: NEW → ASSIGNED
Target Milestone: M12
I checked in the changes to add a buffer size to NewChannel. Now we have to
make use of it in the image code. Brendan/Scott: Any guesses as to what a good
size should be?
I wasn't part of these discussions, so I'm kind of confused.  Based on
previous conversations with you, my impression is that the pipe that sits
between the transport and the consumer doesn't quantize delivery of data into
chunks, e.g. if a packet is received with 327 bytes, then the consumer is
notified that 327 bytes arrived.  The burden could then be placed on the
consumer to aggregate smaller chunks into larger ones.

The 4.x imagelib didn't use a constant segment size.  For reasons I never
understood, it was tuned differently for different platforms.  Specifically,
Mac and OS/2 had different request sizes than the other platforms.  Also, the
requested segment size was deliberately varied over time based on several
factors:

  + whether image dimensions were available
  + whether image was visible on screen
  + whether image was a background image

Except for Mac and OS/2, the two sizes used were 128 bytes for low-priority
images (e.g. offscreen) and 2048 bytes for normal priority.

Another problem that we had with numerous images on a page was that their
associated network requests were placed on a waiting list for an available
socket in the order they were requested, rather than based on any priority, e.g.
whether or not the image was visible.  It would be useful to have a setter that
allows the priority of a channel to be specified.  That same priority field
could be used to control the request size made to the raw socket since, all
other things being  equal (and in the absence of congestion), larger reads from
a socket tend to get a higher fraction of the bandwidth.
Moving what's not done for M12 to M13.
Assignee: warren → mscott
Status: ASSIGNED → NEW
Scott: Can you give us an API with the url loader to set the buffer size?
Thanks.
Blocks: 21564
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Hey Warren, I have changes in my tree so we create the channel and pass it to
the uri loader. this allows us to set the buffer sizes on the channel in
nsImageContextAsync::GetURL.

We just need to figure out what values we want.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
The uri loader now takes a channel instead of a uri. This allows the caller (in
this case the image library) to create the channel with all the special bells
and whistles it wants without bloating the uri loader interface.

So you can now set the buffer sizes for the transport in the image library when
we create the a channel for the image url.
Status: RESOLVED → REOPENED
But you didn't make imagelib take advantage of this yet, did you? Reopening.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Yes I did. I checked in changes to image lib to create a channel for the url.
You can pass in buffer size's for the transport for the channel in
nsImageNetContextAsync.

Re-closing.

Warren, if you want to use this bug to check in values, I can just re-assign
back to you. I thought you wanted me to provide the ability to set these sizes
in image lib which I just did with my checkin.
No longer blocks: 21564
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.