User:Brahmana/Netwerk Docs/Connection Transaction Organization: Difference between revisions

User:Brahmana/Netwerk Docs/Connection Transaction Organization (view source)

Revision as of 15:52, 6 August 2008

1,837 bytes added , 6 August 2008

added abstract notes part

Brahmana

95

edits

@@ Line 41: / Line 41: @@
 [Which lines are you talking about in DispatchTransaction? I don't see where we populate two objects with the same connection. --[[User:Biesi|Biesi]] 18:36, 4 August 2008 (UTC)]
+===Abstract Notes from IRC chats and code browsing===
+* nsHttpConnection (connection) is the one which abstracts the actual socket. The actual socket is present in the NSPR (as it is platform specific thing).
+* A txn sits between the channel and the connection.
+* A txn will not come into picture if we are doing a cache read. It is responsible for talking to the server, sending the request to the server. So it is not required when reading from cache.
+* A channel takes the data from the txn and gives it to any of its consumers.
+* Apart from this delegation work, channel does the job of setting up the transaction if getting the data from the server. If not, then it takes care of the cache read. (So channel is not really dumb).
+* Necko consumers will probably just see the channel. They will ask the nsIIOService to create a channel for the URI that they have. Based on the scheme of the URI, an appropriate channel is created. From the channel all protocol specific works starts. And the consumers just keep getting data and other notifications from the channel.
+* There is a global nsHttpHandler object, named gHttpHandler (obviously), which sort of acts as the manager of all connections. It creates the HttpChannel. There is probably something similar for other protocols also, I have not explored that part. From what I know this does something more also, which I do not know yet. <<Necko people -- something straight from your mind?>>
+* Along with a nsHttpHandler, there is a nsHttpConnectionMgr. This is probably the one which manages the idle connections, active connections and probably allot connections when requested. <<Not sure of this part -- needs validation>>
+** This one activates every nsHttpConnection, which eventually leads to a call in socket transport service, either resulting in the creation of a socket.