Closed
Bug 2434
Opened 26 years ago
Closed 25 years ago
NECKO: Possible problem with persistent connections
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
M10
People
(Reporter: paulmac, Assigned: rpotts)
Details
dup of 337625 in bugsplat in bugzilla now for 5.0 tracking
-----------------------------------------
Even if Enterprise server keeps answering using http1.1 the communicator keeps
sending http 1.0 that are multiplicating the number of TCP port used, where as
IE4 keeps piplining requests in very few TCP ports (2 or 3)
More over he trafific generated communicator and server is up to 2 times biggr
than with IE4 and the same server on the same pages.
step to reproduce :
1- setup keepalivetimeout 500
2- try to access http://yquem.mcom.com/test/cnn.html with both
(communicator45 - ie4)
3- while accessing with the client I snooped the network between the
client and server. I came out with 2 snoop output
ftp://nsuser:suser@yquem/techsup/netscape/suitespot/docs/test/snoop-cm45
ftp://nsuser:suser@yquem/techsup/netscape/suitespot/docs/test/snoop-ie4
4- then I ran following command to mesure the opened connexions from
client to server on both snoop output :
>cat snoop-cm45 | grep TCP | grep Source | grep -v "= 80" | \
sort -u | wc -l
>11 //11 tcp connections to retrieve this page from the
communicator
>cat snoop-ie4 | grep TCP | grep Source | grep -v "= 80" | \
sort -u | wc -l
>2 //2 tcp connections to retrieve this page from the communicator
FYI I'v put some trace from my test and also the customer trace in
http://baroque/users/madiot/publish/customers/la%20poste/93115/
In the newgroup mcom.consult-bbs news://news/366BB9C8.19943DF0%40netscape.com
Gregory Block is saying that this functionality was once forcasted in
communicator 5.0.
Question :
is it still planed into communicator 5.0
------- Additional Comments From madiot 12/30/98 09:08 -------
Hi,
any updates on that on? I would agree that this should be left as fixed, but I
need the confirmation from engineering that this would be fixed in communicator
5.0
looking forward your feedbacks
------- Additional Comments From hannigan 01/06/99 10:45 -------
chris, is this rfe sound like 5.0 material ? assg'ng to you for tracking
purposes for 5.0 ans setting of TFV.
------- Additional Comments From madiot 01/13/99 7:54 -------
I did reproduce the same behaviour with Gecko today on the same test case.
33 sockets opened on the same page http://yquem/test/cnn.html.
is there still a fix planned for that in the communicator 5.0?
cheers
Reporter | ||
Updated•26 years ago
|
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Reporter | ||
Updated•26 years ago
|
Resolution: LATER → ---
Reporter | ||
Comment 2•26 years ago
|
||
Hey Gags, that's why I opened this bug in bugszilla (for 5.0) for tracking
purposes. This is later :-)
I changed the Severity to 'Enhancement' to avoid confusion.
Thats fine, but there could be a bug with our persistent connections logic as
well. Just to make sure we aren't goofing that up, I'd say we mark these as two
separate bugs-- one for persistent connections and the other for adding support
for pipelining.
Reporter | ||
Updated•26 years ago
|
Severity: enhancement → normal
Summary: ES 351 and HTTP 1.1, Communicator not pipelining → Possible problem with persistent connections
Reporter | ||
Comment 4•26 years ago
|
||
I changed the summary for this one. I will open a new RFE for pipelining. Thanks
for clearing up the confusion.
Reporter | ||
Comment 6•26 years ago
|
||
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Reporter | ||
Updated•26 years ago
|
Component: NetLib → Networking Library
Product: MozillaClassic → Browser
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will
be able to verify it for M8.
Comment 9•26 years ago
|
||
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9. We will need to get on this and it cannot be postponed past the M9
milestone.
Comment 10•26 years ago
|
||
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.
Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change. If this happens, I will fix. ;-)
Summary: Possible problem with persistent connections → NECKO: Possible problem with persistent connections
Comment 11•26 years ago
|
||
Pl. verify with Necko (no pipelining in as yet, just Keep-Alive)
Reporter | ||
Comment 12•26 years ago
|
||
pierre-ephrem, can you verify that this is better with new 5.0 builds?
Reporter | ||
Comment 13•26 years ago
|
||
I e-mailed madiot to see how things look now, but I thought keep-alive wasn't
implemented yet?
Comment 14•26 years ago
|
||
You are right. no Keep-Alive as yet in Necko. Marking component Necko.
Updated•26 years ago
|
Assignee: gagan → rpotts
Status: REOPENED → NEW
Updated•26 years ago
|
Target Milestone: M9 → M10
Comment 15•26 years ago
|
||
Rick was looking at keep-alive I believe. Reassigning to him.
Comment 16•26 years ago
|
||
Probably not m9 critical either -- m10.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 17•25 years ago
|
||
I'm marking this bug a dup of bug #10738 which is the NECKO schedule item for
implementing persistent connections...
We can open another bug later for pipelining if we decide to implement it...
*** This bug has been marked as a duplicate of 10738 ***
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 18•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
You need to log in
before you can comment on or make changes to this bug.
Description
•