Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 2

We skimmed through some basics of ASP.Net compilation model and the ASP.Net runtime environment yesterday. We mentioned the 2 process models that ASP.Net supports; we will see more inside these 2 models today.

ASP.Net Process Models

IIS 5.0 Process Model

On IIS 5.x all ASP.Net applications run inside a separate process called aspnet_wp.exe. So in this model aspnet_isapi doesn't actually process the requests, it is hosted within the inetinfo process of IIS but it acts as a dispatcher, collects all the information available about the invoked URL and routes the request towards this distinct process aspnet_wp also called the ASP.Net worker process. The communication between the ISAPI extension and the worker process takes place through named pipes. By default this worker process runs under the identity of the account called ASPNET, created when ASP.Net is installed

Only a single copy of aspnet_wp runs all the time and hosts all the active web applications each in a distinct AppDomain. In a web garden scenario though, multiple worker processes run simultaneously, one for each affinitized CPU. If a client requests a page from an already running web application, ASP.Net runtime simply forwards the request to the existing AppDomain associated with the corresponding virtual directory. If the assembly needed to process the page is not available in the AppDomain, it will be created on the fly, otherwise, if it is already created upon the first call, it will simply be re-used.

Below is a diagrammatic explanation of this process model:

IIS 6.0 Process Model

IIS 6 employs a different pipeline of internal modules to process an inbound request, although it mimics the behavior of IIS 5 when run in the IIS 5 isolation mode, also called emulation mode. This model by default is centered on the concept of Application Pools; an application pool is a group of web applications that share the same copy of the worker process. We can configure each pool (and so the process) with a different set of properties.

So on IIS 6, in the default worker process process model, ASP.Net applications use a generic – ASP.Net agnostic process because it's the similar process that serves any other web applications. The other key component of this model is the kernel level driver called http.sys which is the HTTP listener that captures and eventually services all requests. When a request arrives http.sys routes it to a queue managed by the application pool that the invoked application belongs to. There is just one queue per pool. In IIS 5 isolation mode however, http.sys places requests in a unique, shared request queue.

In this model, w3wp.exe – the worker process loads aspnet_isapi.dll – the ISAPI extension which in turn loads the CLR (Common Language Runtime) and also starts the ASP.Net runtime pipeline. When this default model is in use on IIS 6, the built in ASP.Net worker process (aspnet_wp) id disabled.

So, the worker process w3wp uses http.sys to get requests and send responses to the client. This process by default runs under the Network Service account. This is a specific account with the least set of privileges compatible with the functionality it is expected to allow.

Below is a diagrammatic explanation of this process model:

That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will talk about the ASP.Net pipeline that is demonstrated in the above diagrams and in the coming days we will delve into the dynamic compilation of pages.

Thanks,

Sukesh Khare

Coordinator Daily .Net Feed Program