Question

This MSDN article states that:

To guarantee optimal performance,
aspnet_isapi uses asynchronous named
pipes to forward requests to the
worker process and to get responses.
On the other hand, the worker process
exploits synchronous pipes when it
needs to query for information about
the IIS environment (that is, server
variables).

1. Does the worker process always uses “synchronous” named pipes? (Response to aspnet_isapi.dll would be asynchronous too, right?)
2. Can the worker process talk directly to IIS or does it have to send a synchronous request to aspnet_isapi.dll to inquire about IIS environment etc.?

Answer 1

Later in the same article, things get a little clearer, :p :

The logic behind the processing of each ASP.NET request can be summarized in the following steps.

1. When the request arrives, IIS examines the resource type and calls into the ASP.NET ISAPI extension. If the default process model is enabled, aspnet_isapi queues the request and assigns it to the worker process. Any request data is sent through asynchronous I/O. If the IIS 6 process model is enabled, the request is automatically queued to the worker process (w3wp.exe) handling the IIS application pool to which the application belongs. The IIS 6 worker process doesn’t know anything about ASP.NET and managed code. It is limited to processing the *.aspx extension and loading the aspnet_isapi module. When the ASP.NET ISAPI works under the IIS 6 process model, it behaves differently and just loads the CLR in the context of the w3wp.exe worker process.
2. After receiving the request, the ASP.NET worker process notifies the ASP.NET ISAPI that it is going to serve it. The notification takes place through synchronous I/O. The synchronous model is used because for consistency the worker process can’t start processing a request that is not yet marked as “executing” in the ISAPI’s internal requests table. A request that is being serviced by a particular worker process cannot be reassigned to a different process unless the original one dies.
3. The request executes in the context of the worker process. There might be circumstances in which the worker process needs to call the ISAPI back in order to complete the request that is, to enumerate server variables). In this case, the worker process uses synchronous pipes because this would preserve the sequence of the request-processing logic.
4. When finished, the response is sent to aspnet_isapi opening an asynchronous pipe. The state of the request now changes to “Done”; later on the request will be removed from the table. If the worker process crashes, all the requests it was handling remain in the “executing” state for a while. When aspnet_isapidetects that the worker process is dead, it automatically aborts the request and frees any associated IIS resources.

So, I think the answer to my first question would be No and to the second point 3 above implies that the worker process doesn’t directly accesses IIS but goes through aspnet_isapi.dll.