Closed Bug 2434 Opened 26 years ago Closed 25 years ago

NECKO: Possible problem with persistent connections

Categories

(Core :: Networking: HTTP, defect, P2)

x86
Windows 95
defect

Tracking

()

VERIFIED DUPLICATE of bug 10738

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
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → LATER
We never did pipelining. We hope to be able to do it for 5.0.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: LATER → ---
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.
Severity: enhancement → normal
Summary: ES 351 and HTTP 1.1, Communicator not pipelining → Possible problem with persistent connections
I changed the summary for this one. I will open a new RFE for pipelining. Thanks for clearing up the confusion.
Setting all current Open/Normal to M4.
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Component: NetLib → Networking Library
Product: MozillaClassic → Browser
Target Milestone: M4 → M6
Marking till Necko lands...
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.
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.
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
Pl. verify with Necko (no pipelining in as yet, just Keep-Alive)
pierre-ephrem, can you verify that this is better with new 5.0 builds?
I e-mailed madiot to see how things look now, but I thought keep-alive wasn't implemented yet?
Component: Networking-Core → Necko
You are right. no Keep-Alive as yet in Necko. Marking component Necko.
Assignee: gagan → rpotts
Status: REOPENED → NEW
Target Milestone: M9 → M10
Rick was looking at keep-alive I believe. Reassigning to him.
Probably not m9 critical either -- m10.
Status: NEW → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → DUPLICATE
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 ***
Status: RESOLVED → VERIFIED
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Component: Networking → Networking: HTTP
You need to log in before you can comment on or make changes to this bug.