User:Brahmana/Netwerk Docs/Connection Transaction Organization

There are two main classes which actually define the basic behavior of a Http Connection and a Http Transaction. They are:

1. nsAHttpConnection
2. nsAHttpTransaction

Ideally, I would have expected these two be two interfaces. Because that's what they are, "Interfaces to two things, viz a connection and a transaction". But for some reason these were made abstract classes. Probably to avoid usage from JS. Then again these could be made non-scriptable interfaces. Now as you know, I seriously do not know why these are abstract classes and not interfaces.

[When you say interface you mean IDL file? There's no point to write an IDL for these two interfaces really. They're only supposed to be used inside of the HTTP implementation, and there doesn't seem to be any advantage in being restricted by IDL syntax --Biesi 06:20, 18 July 2008 (PDT)]

Going ahead, there are multiple implementations of these two behavioral classes. Some of which I have come across are:

• nsAHttpConnection
  • nsHttpConnection -- This actually represents a connection. This is never accessed directly. The two things below act as wrappers to this one.
  • nsConnectionHandle -- This is used for wrapping the connection when pipelining is not allowed.
  • nsPipeline -- This is used for wrapping the connection when pipelining is allowed and is being done.

• nsAHttpTransaction
  • nsHttpTransaction -- This is used when pipelining is not allowed.
  • nsPipeline -- This is used when pipelining is allowed and is being done.

[you mean nsHttpPipeline where you write nsPipeline, right? --Biesi 18:36, 4 August 2008 (UTC)]

Now I do not know whether these implementations have something extra apart from helper methods. That is a question for necko folks.

Q1. Do the concrete implementations have a lot more things than what is present in the abstract classes? If so what sort of stuff? (Examples at a high-level)

[Sorry, I don't really understand the question. Other than the helper methods they also have the implementation of the interfaces. I'm not sure what kind of answer you are looking for...

The transaction class is what actually sends the data to the server, parses the headers, etc. It sits between the channel and the socket.

Does that answer your question? --Biesi 18:36, 4 August 2008 (UTC)]

There is no 1-to-1 mapping between a transaction and a connection.

Q2. What all things are logically represented by a transaction (a nsHttpTransaction or a nsHttpPipeline object)?

[A transaction (txn) is a single HTTP request. An HTTP channel usually has one txn, but can have more than one in the case of authentication retries or none in case of cache reads. It can not have more than one at a time though. --Biesi 18:36, 4 August 2008 (UTC)]

Q3. In this part of code we take away references to the actual connection from both the transaction and the wrapper object connection handle. But later in DispatchTranscation we populate the two objects with the same connection. What is the reason for this? Is this to take care of the situation where in initially pipelining was not done and now it needs to be done? What is rationale behind this code?

[Which lines are you talking about in DispatchTransaction? I don't see where we populate two objects with the same connection. --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?>> [The HTTP protocol handler also stores some global state, some preference values, the value of the User-Agent header; it caches some services; and it has a few helper methods. But mainly it's just an implementation of nsIProtocolHandler for HTTP. There is indeed one protocol handler for each supported protocol. Their job is basically to manage nsIURI and nsIChannel creation. --Biesi 07:25, 7 August 2008 (UTC)]
• 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>> [Sounds right to me. --Biesi 07:25, 7 August 2008 (UTC)]
  • This one activates every nsHttpConnection, which eventually leads to a call in socket transport service, either resulting in the creation of a socket.