User:Brahmana/Netwerk Docs/Netwerk Request Life Cycle

Here is the sequence diagram that I created by tracing the code: The control is now divided into two parts;

• Stuff that happens in DocShell
• Stuff that happens in Netwerk (or Netlib)

Click on the thumbnails to look at the UML diagrams.

• Control flow in the DocShell code starts from nsWebBrowser.LoadURI() which typically happens from a consumer (which can be JS). This is presented as the first diagram.

• Control flow in the Netwerk code starts from the point where the URILoader transfers the call to the nsHttpChannel via the call nsHttpChannel.AsyncOpen(). This is the second diagram.

All through out I have considered a HTTP document request. At some points I have not marked a return from a function. Assume a return in those cases. Though creation of objects are clearly marked, the destruction of the same is not shown. One of the reason being most objects get on to the Heap and are either reference counted or destroyed by the object that creates them. This info might be more clear with the class diagram that is present in another document.

I have few questions regarding all this:

1. Where is the socket opened and an actual TCP connection is made?
2. When do actually things get multithreaded? Because the sequence flow here stops at EnsureWaiting(), when will it come out of waiting?

[For the first of those, if you go through the stuff in nsHttpConnectionMgr until you get to the call to nsHttpConnection::Activate. This calls CreateTransport, whcih calls into the socket transport service, etc. You'd need to trace into that to find the NSPR code that actually does the socket-opening, which is probably different on different OSes. For the second, nsHttpConnectionMgr::AddTransaction (called when setting up the transaction) calls PostEvent, which dispatches the event to call OnMsgNewTransaction to the socket thread. So there are basically two threads in play here, as I understand: the UI thread, where the asyncOpen happens, and the socket thread, where the socket access happens. I think there is also a thread pool that comes into play later (from the stream transport service), but I'm not sure how that fits into the setup, to be honest. --Bzbarsky 09:00, 9 July 2008 (PDT)]

[HTTP doesn't use the stream transport service. Also, shouldn't gHttpHandler be the connection manager instead, in the diagram? The diagram also sort of skips the more interesting parts of the HTTP code (i.e. the parts that actually write the data into the pipe) --Biesi 10:47, 9 July 2008 (PDT)]

There are few more questions , which I will put up once I have answers to these.