Asp. NET bottom architecture explore the. NET Runtime

Here we have an instance of the callable Isapiruntime object that is active in the ISAPI extension. Each time the runtime is started and running (in contrast, if the runtime does not start, you need to load the runtime as described in the previous chapter), the ISAPI code calls the Isapiruntime.processrequest () method, This method is really the entry into the ASP.net pipeline, which is shown in Figure 4.

Remember that the ISAPI is multi-threaded, so the request will also pass Appdomainfactory.create () (the original applicationdomainfactory, suspect) The reference returned in the function is processed in a multithreaded environment. Listing 1 shows the Isapiruntime.processrequest code in the method () that receives an ISAPI ECB object and service type (Workerrequesttype) As a parameter. This method is thread-safe, so multiple ISAPI threads can call this method safely on this returned object instance at the same time.

The list 1:processrequest method receives an ISAPI ECB and passes it to the worker thread

public int ProcessRequest(IntPtr ecb, int iWRType)
{
　HttpWorkerRequest request1 = ISAPIWorkerRequest.CreateWorkerRequest(ecb，iWRType);
　string text1 = request1.GetAppPathTranslated();
　string text2 = HttpRuntime.AppDomainAppPathInternal;
　if (((text2 == null) || text1.Equals(".")) ||
(string.Compare(text1, text2, true, CultureInfo.InvariantCulture) == 0))
　{
HttpRuntime.ProcessRequest(request1);
return 0;
　}
　HttpRuntime.ShutdownAppDomain("Physical application path changed from " +text2 + " to " + text1);
　return 1;
}

The actual code here is not important, remember that this is from the internal framework code decompile, you can not directly deal with it,　It is also likely to change in the future. It's just used to reveal what's going on behind the scenes. The ProcessRequest method receives an unmanaged ECB reference and passes it to the Isapiworkerrequest object. This object is responsible for creating the creation request context for the current request. This procedure is shown in Listing 2.

The System.Web.Hosting.ISAPIWorkerRequest class is an abstract subclass of the HttpWorkerRequest class (HttpWorkerRequest and Isapiworkerrequest are abstract classes, And Isapiworkerrequest inherits from HttpWorkerRequest), its job is to build an abstract perspective of input and output as input to Web applications. Note that there is another factory method: Createworkerrequest, to create the corresponding Workerrequest object by judging the second parameter that is accepted. There are three different versions: Isapiworkerrequestinproc,　ISAPIWorkerRequestInProcForIIS6, Isapiworkerrequestoutofproc. Each time a request enters, the object is created and serves as the basis for the request and response object, which receives their data and the stream of data provided by Workerrequest.

The abstract HttpWorkerRequest class provides a high-level abstraction on the low-level interface, which encapsulates where the data comes from, can be a CGI Web server, a Web browser control, or something you use to "feed" the HTTP runtime. The mechanism for customizing the data. The key is that ASP.net can receive information in a uniform way.

In the case of IIS, this abstraction is built around the ISAPI ECB block. During our request processing, Isapiworkerrequest hangs the ISAPI ECB and takes out information from it as needed. Listing 2 shows the request string value (query strings Value) is how it was taken out.