FastCGI ASP.NET Server Status Report 10

This status report is for the week of July 30 – August 3. This week has seen a lot of work fine tuning and cleaning up the server so it will be more usable and useful.

THIS WEEK’S ACCOMPLISHMENTS

This week saw an explosion of development activity. Daily commits yielded a Changelog 234 lines (or 64%) larger than the week before. Key features are as outlined.

• Support was added for serving on a new Unix socket, as opposed to a piped socket or TCP socket. This can be used in several web servers in place of TCP sockets.
• Started work on documenting how to configure servers. Lighttpd and Cherokee are completely documented, Abyss is documented except for a bug appearing in ASP.NET 2.0, and the current problems with Apache2 are documented.
• Support was added for setting all command line options via environment variables, due to limitations in some servers. (MONO_FCGI_SOCKET=tcp is the same as setting /socket=tcp)
• Directories containing a “bin” directory are automatically treated as new applications. This is not a perfect way of checking for applications, as it can yield false positives, and not all applications use DLL’s, but it is pretty good for now.
• Support was added for writing to a log file.
• UnmanagedSocket now appropriately flags a closed connection.
• Sending and receiving records was redone, partially because I didn’t fully understand how reading and writing sockets worked and the request would die if Receive didn’t yield the exact number of bytes requested.
• When targetting .NET 2.0, Mono.FastCgi uses strictly generic collections. This reduces the size of the heap and should speed things up slightly.
• Records are now sent at no more than half the maximum size to avoid problems with some web servers. This behavior is similar to that of Cherokee.
• My patch to System.Net.Sockets.Socket was accepted. This patch is important because it removes the limitation of only supporting Unix and TCP sockets. (And may save some resources by not loading Mono.Unix if it isn’t needed.)
• Tons of bug fixes.

and

FastCGI Mono Server can handle full blown applications, like mojoPortal:

This is not hosted on a virtual path, but automatically recognized because the application contains a “bin” directory.

PLANS FOR THE COMING WEEK

1. I’m going to continue my work documenting servers. Each server presents different problems and test cases I may have overlooked and extends the reach of Mono.FastCgi.
2. Work with my mentor on what to do next.

CHALLENGES I’M FACING

I’m not sure how I want to proceed with the socket issue. It turns out all the problems I was having stemmed from bad implementation on my part and problems in mod_fcgid. Now that they’re overcome, the unmanaged socket is working fine. Not adding a mono specific feature to System.Net.Sockets.Socket would allow me to keep the version dependency down, make things easier if building it against MS .NET in the future, and give me an abstraction for using Named Pipes on Windows.

Another challenge is how to proceed with Apache. Admittedly, there are two existing open source implementations, both with their flaws, but both lacking things like Bugzilla, and both with highly cryptic source code. It may be best to develop a new FastCGI module under the Mono Project umbrella, to protect the project’s interests. It could be based off code from mod_mono and design attributes from my FastCGI library.

RESOURCES USED THIS WEEK

• MojoPortal forums.
• Abyss documentation.
• Wrapper scripts for other applications.

Sincerely,
Brian Nickel

---

Possibly related posts: (automatically generated)

• FastCGI ASP.NET Server Status Report 3
• Abyss and Nginx now documented and working
• Sockets in the Browser
• Download: Section 8 v1.1 Patch