Programming · Summer of Code 2007

FastCGI ASP.NET Server Status Report 2

This is a status report for the week of June 4 – June 8. This week is best categorized as a research and planning week.


On the coding front, there hasn’t been too much progress. The main things that changed were a general tidying of the API, addition of more FastCGI features, and general stabilization. The complete list is in the ChangeLog <>.

Outside of coding, I spent most of my time rummaging through the XSP source code trying to make heads and tales of what everything does. It has been a pretty slow process but I’ve been storing my results in MonoDoc format <>, so it should be helpful to other developers down the line.

Another thing that occupied my time was deciding what to do to bridge my FastCGI implementation with the current ApplicationServer. Below is my plan.


This week, my #1 goal is to get an actual working ASP.NET implementation on top of my FastCGI library. To do this, I plan to separate the FastCGI implementation into its own library and implement three classes on top of it: FastCgiApplicationHost, FastCgiWorkerRequest, and FastCgiWebSource. ApplicationServer may or may not be used as the server, depending on whether my AbstractSocket (below) works out. If ApplicationServer is not used as the server, it will still be used to manage application paths. After all that, a driver class similar to XSP’s server.cs should be all that I need.

As for the socket issue I faced last week, I intend to create a base class AbstractSocket with two subclasses, ManagedSocket which will wrap around System.Net.Sockets.Socket, and UnmanagedSocket which will work with the existing socket by P/Invoking libc. All operations will then be done via AbstractSocket. This will require research on how to accomplish a similar effect on other operating systems.


The biggest challenge this week has been sorting through everything. There currently isn’t any documentation on the library and there are very few source code comments.


  • MSDN – Looking up information on various classes and methods.
  • FastCGI Specification – Obvious reasons.
  • XSP Source Code – To see what everything does.
  • Running XSP with tracing enabled – This was extremely helpful because it not only described the path of operation but showed what arguments were passed. This was very helpful for cryptic identifiers. (For example, seeing that ‘verb’ == “GET” really clarified things.)

Brian Nickel


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s