Difference between revisions of "Necko"
(how it fits together) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Short Description == |
| + | Necko is a platform-independent API for several layers of networking (transport to presentation) that is built on XPCOM. It is currently in use in Mozilla and all of its clients. | ||
| − | + | == Longer Description == | |
| + | * Built on XPCOM and NSPR - Not a stand-alone library | ||
| + | * Implemented mainly in C++ | ||
| + | * Continually evolving (quite drastically!) | ||
| + | * Originally located at mozilla/network. This version is now completely deprecated. | ||
| + | * Now located at [http://lxr.mozilla.org/seamonkey/source/netwerk/ mozilla/netwerk]. | ||
| + | == Important Interfaces == | ||
Necko has several important pieces: | Necko has several important pieces: | ||
* nsIOService | * nsIOService | ||
| Line 11: | Line 18: | ||
=== nsIOService === | === nsIOService === | ||
| − | * | + | * Provides network utility functions. |
| − | * Manages | + | * Manages nsIProtocolHandler implementations. |
| − | * Creates | + | * Creates nsIURI objects from URI strings. |
=== nsIURI === | === nsIURI === | ||
| − | * is an object that | + | * Represents a URI (scheme://host/path). |
| − | * | + | * Parent class of nsIURL, which is implemeted by nsStandardURL, which handles standard URL operations. |
| + | |||
| + | === nsIProtocolHandler === | ||
| + | * Manages a single protocol based on a scheme (e.g. http). | ||
| + | * Uses nsIURI instance to create nsIChannel. | ||
| + | |||
| + | === nsIChannel === | ||
| + | * Uses nsIURI information to create logical connection to resource. | ||
| + | |||
| + | === nsIStreamListener === | ||
| + | * Listener for connection start, arrival of data, and stop request. | ||
| + | |||
| + | === 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 == | ||
| + | * [http://www.mozilla.org/projects/netlib/ Mozilla Networking Library Documentation] | ||
| + | * [http://www.mozilla.org/projects/netlib/necko_interface_overview.html Necko Interfaces Primer] | ||
| + | * [http://www.mozilla.org/projects/netlib/presentations/necko1-2002-02-18/slide1.xml Darin Fisher's Necko presentation, 2002/02/18] | ||
| + | * [http://lxr.mozilla.org/seamonkey/source/netwerk/ LXR - seamonkey/netwerk] | ||
Latest revision as of 22:07, 5 October 2006
Contents
Short Description
Necko is a platform-independent API for several layers of networking (transport to presentation) that is built on XPCOM. It is currently in use in Mozilla and all of its clients.
Longer Description
- Built on XPCOM and NSPR - Not a stand-alone library
- Implemented mainly in C++
- Continually evolving (quite drastically!)
- Originally located at mozilla/network. This version is now completely deprecated.
- Now located at mozilla/netwerk.
Important Interfaces
Necko has several important pieces:
- nsIOService
- nsIURI
- nsIChannel
- nsIProtocolHandler
- nsITransport
nsIOService
- Provides network utility functions.
- Manages nsIProtocolHandler implementations.
- Creates nsIURI objects from URI strings.
nsIURI
- Represents a URI (scheme://host/path).
- Parent class of nsIURL, which is implemeted by nsStandardURL, which handles standard URL operations.
nsIProtocolHandler
- Manages a single protocol based on a scheme (e.g. http).
- Uses nsIURI instance to create nsIChannel.
nsIChannel
- Uses nsIURI information to create logical connection to resource.
nsIStreamListener
- Listener for connection start, arrival of data, and stop request.
nsITransport
- Represents physical connection (e.g. file descriptor, socket).
How it fits Together
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.
