How does IIS communicate at runtime with ASP.NET
When an aspx requested, IIS checks the file extension in its metabase.
To view the metabase Start> Run > inetmgr
In the Internet Information Services window right click in 'Web sites' > Properties
Select 'Home Directory' tab and click the Configuration button
Now you can see a table with 3 columns.
aspx is mapped to aspnet_isapi.dll
When IIS find the extension aspx, then it loads the aspnet_isapi.dll and pass all the request details to it.
aspnet_isapi.dll then loads the CLR and pass all the request details that received.
CLR then create HttpRuntime engine.
The begining of the runtime engine is HttpRunTime class. It creates the HttpContext object and stores all the request details.
From there HttpContext object passes through a pipeline which consists of HttpApplication object, HttpModule objects and finally HttpHandler object ( that is our page class).
HttpHandler object creates the html page
To view the metabase Start> Run > inetmgr
In the Internet Information Services window right click in 'Web sites' > Properties
Select 'Home Directory' tab and click the Configuration button
Now you can see a table with 3 columns.
aspx is mapped to aspnet_isapi.dll
When IIS find the extension aspx, then it loads the aspnet_isapi.dll and pass all the request details to it.
aspnet_isapi.dll then loads the CLR and pass all the request details that received.
CLR then create HttpRuntime engine.
The begining of the runtime engine is HttpRunTime class. It creates the HttpContext object and stores all the request details.
From there HttpContext object passes through a pipeline which consists of HttpApplication object, HttpModule objects and finally HttpHandler object ( that is our page class).
HttpHandler object creates the html page
Introduction
Many of us know that IIS is a web server and we use it in our .Net application since we need a web server to run a web application. But I wonder as many of us don't know the internal architecture of IIS. This article is written for beginners to know the architecture of IIS.
How the Simple Web page execution Happens?
As All of us know A Request comes from Client (Browser) and sends to Server (We call it as Web server) in turn Server Process the Request and sends response Back to the Client in according to the client Request
But internally in the Web server there is quite interesting process that happens. To get aware of that process we should first of all know about the architecture of the IIS
It mainly consists of 3 Parts/Files
1. Inetinfo.exec
2. ISAPI Filter (Container for Internet Server Application Interface dlls) ,
3. Worker Process (aspnet_wp.exe)
When ever a Request comes from the Client:
Inetinfo.exe is the ASP.Net Request Handler that handles the requests from the client .If it’s for static resources like HTML files or image files inetinfo.exe process the request and sent to client If the request is with extension aspx/asp inetinfo.exe processes the request to API filter. ISAPI filter will have several runtime modules called as ISAPI extensions. To process the request ISAPI filter takes the help of these runtime modules .The runtime module loaded for asp page is asp.dll. And for asp.net page it’s ASPNET_ISAPI.dll. From here the request is processed o the Worker Process. Worker Process will have several Application Domains
Application Domain
The purpose of the Application Domain is in order to isolate one application from another. When ever we create a new application, application Domains are created automatically by the CLRHost. Worker process will create a block of memory related to particular application. Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. Application domains are normally created by runtime hosts. Runtime host is responsible for bootstrapping the common language runtime before an application is run.
Worker process sends the request to HTTPPIPE line.(HTTP Pipeline is nonetheless collection of .net framework classes). HTTP Pipeline compiles the request into a library and -makes a call to HTTP runtime and Runtime creates an instance of page class
public class File : System.Web.UI.Page
{
}
ASP.Net web page is a class derived from Page class ,this page class resides in system.web.dll
After creating instance pf Page class HTTP Runtime immediately invokes Process Request Method of Page class
Page Req = new Page();
Req.ProcessRequest();
Process Request Method Does Following things
1.Intialize the Memory
2.Load the View State
3.Page Execution and Post back Events
4.Rendering HTML Content
5.Releasing the memory
Process Request Method executes set of events for page class .These are calles as Page life cycle events.
Page Life Cycle Events
Page_Init
The server controls are loaded and initialized from the Web form’s view state. This is the first step in a Web form’s life cycle.
Page_Load
The server controls are loaded in the Page object. View state information is available at this point, so this is where you put code to change control settings or display text on the page.
Page_PreRender
The application is about to render the Page object.
Page_Unload
The page is unloaded from memory.
Page_Disposed
The Page object is released from memory. This is the last event in the life of a Page object.
Page_Error
An unhandled exception occurs.
Page_AbortTransaction
A transaction is aborted.
Page_CommitTransaction
A transaction is accepted.
Page_DataBinding
A server control on the page binds to a data source.
Process Request Method finally renders HTML Page
The server controls are loaded and initialized from the Web form’s view state. This is the first step in a Web form’s life cycle.
Page_Load
The server controls are loaded in the Page object. View state information is available at this point, so this is where you put code to change control settings or display text on the page.
Page_PreRender
The application is about to render the Page object.
Page_Unload
The page is unloaded from memory.
Page_Disposed
The Page object is released from memory. This is the last event in the life of a Page object.
Page_Error
An unhandled exception occurs.
Page_AbortTransaction
A transaction is aborted.
Page_CommitTransaction
A transaction is accepted.
Page_DataBinding
A server control on the page binds to a data source.
Process Request Method finally renders HTML Page
IIS 6.0 Process Model
The IIS 6 process model is the default model on machines running Windows 2003 Server operating system. It introduces several changes and improvements over the IIS 5 process model. One of the biggest changes is the concept of application pools. On IIS 5.X all web applications, that is, all AppDomains, were hosted by the ASP.NET worker process. To achieve a finer granularity over security boundaries and personalization, the IIS 6 process model allows applications to run inside different copies of a new worker process, w3wp.exe. Each application pool can contain multiple AppDomains and is hosted in a single copy of the worker process. In other words, the shift is from a single process hosting all applications to multiple processes hosting each an application pool. This model is also called the worker process isolation mode.Another big change from the previous model is the way IIS listens for incoming requests. With the IIS 5 model, it was the IIS process, inetinfo.exe, who was listening on a specific TCP port for HTTP requests. In the IIS 6 architecture, incoming requests are handled and queued at kernel level instead of user mode via a kernel driver called http.sys; this approach has several advantages over the old model and is called kernel-level request queuing.
Figure 3: The IIS 6.0 process model
Figure 3 illustrates the principal components taking part in the request processing when using the II 6 model. Once a request arrives the kernel level device driver http.sys routes it to the right application pool queue. Each queue belongs to a specific application pool, and thus to a specific copy of the worker process, which next receives the request from the queue. This approach highly reduces the overhead introduced by named pipes used in IIS 5 model since no inter process communication is taking place, but the requests are headed to the worker process directly from the kernel level driver. This has many advantages concerning reliability, too. Since running in kernel mode, the request dispatching isn’t influenced by crashes and malfunctions happing at user level, that is, in the worker processes. Thereby, even if a worker process crashes, the system is still capable of accepting incoming requests and eventually restarts the crashed process.
It’s the worker process who is in charge of loading the ASP.NET ISAPI extension, which, in turn, loads the CRL and delegates all the work to the HTTP Runtime.
The w3wp.exe worker process, differently from the aspnet_wp.exe process used in IIS 5 model, isn’t ASP.NET specific, and is used to handle any kind of requests. The specific worker process then decides which ISAPI modules to load according to the type of resources it needs to serve.
A detail not underlined in Figure 3 for simplicity reasons is that incoming requests are forwarded from the application pool queue to the right worker process via a module loaded in IIS 6 called Web Administration Service (WAS). This module is responsible for reading worker process – web application bindings from the IIS metabase and forwarding the request to the right worker process.
