Changes

Jump to: navigation, search

Necko

1,630 bytes added, 23:07, 5 October 2006
how it fits together
=== nsITransport ===
* Represents physical connection (e.g. file descriptor, socket).
 
== How it fits Together ==
[[media:Neckobig.png|This]] is a diagram of how the different necko components fit together.
 
When a client (such as Firefox) needs to open a URI (http://, ftp://, file:///, etc.) it sends an nsURI to it's nsIOService. The nsIOService constructs the proper nsIProtocolHandler. Depending on which nsIProtocolHandler is used different things happen. In the case of HTTP the nsIProtocolHandler goes through the File Transport (an nsITransport) to check the cache. If no page is cached it goes to the Socket Transport (also an nsITransport). For files only the File Transport would be used. If a proxy is enabled and the Protocol Handler needs to reach the Socket Transport it goes through the Proxy. The Socket Transport has a few different paths. If no DNS resolution is needed it goes directly to the remote server and retrieves the data. If DNS resolution is needed it goes through the DNS object first which in turn retrieves the page. The PSM object is used for SSL and other secure connection types. When the PSM object is used the Socket Transport never talks to a remote server directly. When the Socket Transport has data back in it's hands it sends it back to the Protocol Handler. If any data conversion is necessary (some form of encoding to another) it runs the data through a nsIStreamConverter. The Protocol Handler eventually hands this data to the client. For stateless protocols like HTTP or file this is all that happens. But in the case of ftp or other things that maintain an open connection the client can send commands back to the Protocol Handler which goes back a Transport, etc.
== References ==
1
edit

Navigation menu