20408 - need to parameterize buffer size for transports

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Warren Harris]

We need to parameterize the buffer size for transports so that images can use a
different buffer size than html, etc.

Comment 1

[Warren Harris]

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?

Comment 2

[Scott Furman]

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.

Comment 3

[Warren Harris]

Moving what's not done for M12 to M13.

Comment 4

[Warren Harris]

Scott: Can you give us an API with the url loader to set the buffer size?
Thanks.

Comment 5

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 6

[Scott MacGregor]

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.

Comment 7

[Scott MacGregor]

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.

Comment 8

[Warren Harris]

But you didn't make imagelib take advantage of this yet, did you? Reopening.

Comment 9

[Scott MacGregor]

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.

Comment 10

[Tom Everingham]

verified