I just turned in Bugzilla 181292 on this.

Doug Dillon wrote:

    One more thing. I looked at the bug you referenced
and it was something that would completely lock up the browser,
if I read the description correctly. That's more evidence that this is
not that bug.

    Doug.................

Doug Dillon wrote:

>     I was running the version downloaded off the home page yesterday,
> Build 2002101612. If I understand you correctly,
> your guess does not account for this.
>
>     Doug....................
>
>
> Kai Engert wrote:
>
> > Without having looked at the code, here is a first wild guess: Maybe
> > what you see was caused by bug
> >   http://bugzilla.mozilla.org/show_bug.cgi?id=163605
> >
> > You say you are using 1.2, but not exactly which version - 1.2 final
> has
> > not yet been released.
> >
> > Builds *after* 1.2 beta have the fix for bug 163605, including the
> > latest-1.2 builds on the ftp server.
> >
> > If you were using a version that has not yet the fix, could you please
> > test with a later build?
> >
> > Thanks,
> > Kai
> >
> >
> > Doug Dillon wrote:
> >
> > >
> > >     I'm hoping to optimize Mozilla so that it has
> > > faster secure web page response time over broadband satellite
> > > connections than IE.
> > >
> > >     Today I analyzed some ethernet traces of Mozilla retrieving
> > > a simple web page with multiple embedded images.
> > >
> > >     The trace started out as I expected:
> > >     1 - after an SSL connection is established and the
> > > HTML is retrieved Mozilla opens additional TCP connections to
> > > retrieve the embedded images.
> > >     2 - The TCP connection establishment completes as expected.
> > >
> > >     BUT THEN I WAS STUNNED TO DISCOVER:
> > >     3 - Mozilla would only perform a single SSL session reuse
> > > negotiation with the server at a time!
> > >     4 - As a result, the image retrieval proceeded one image at
> > > a time!!!
> > >
> > >     This is obviously really bad for web page response time
> > > when you are on a long-latency link such as a geosynchronous
> satellite
> > > link.
> > >
> > >     Can anyone provide insight on this:
> > >     1 - Am I crazy and reading the trace wrong?
> > >     2 - Is there some not so well known parameter I could
> > > reconfigure to help?
> > >     3 - How much trouble would it be to relieve this single
> > > negotiation at a time restriction?
> > >
> > >     I'm willing, along with a colleague, to spend dozens of hours
> > > trying to fix this if it is possible.
> > >
> > >     Doug Dillon
> > >
> >
>


Reply via email to