WASP can expose internal metrics using performance counters. These can then be viewed using the standard Windows performance monitoring tool, perfmon. WASP’s performance counters allow you to see how your server is performing and the counters can be automatically monitored and integrated with the counters from other Windows services, such as SQL server, the base operating system or the CLR, to provide a fully integrated production monitoring system. Installation of performance counters is done once per machine rather than once per WASP instance and performance counters can be used and viewed both when WASP is running as a Windows Service and from the command line.

The latest release of The Server Framework is now available from ServerFramework.com. See here for details.

I’ve put together a new website for my super scalable, high performance, I/O Completion Port based server framework. This has all of the information that you need to decide if you can use The Free Framework or if you’d prefer to license The Server Framework. There’s also a new server example, WASP, which is a pluggable server platform that is available in compiled form and is free for non-commercial use. Over the next few months WASP will evolve to support most of the key features of the various options that are available with The Server Framework such as SSL, Managed hosting, UDP and TCP, etc.

One of my clients has recently required .Net 4.0 hosting support and so most of the changes in the CLR Hosting Tools library in 6.3 have been driven by them. The main new feature is the optional use of the .Net 4.0 hosting API. This allows us to host .Net 4.0 as well as earlier CLRs and also allows us to host multiple different CLRs in a single process. The new hosting API is supported via the CCLRHostFactory object which uses the CCLRMetaHost and CCLRRuntimes objects to present a consistent interface to both the .

In the last tutorial I showed you how to run WASP as a normal command line executable. This can be useful for testing and development and also for debugging but when you want to run WASP on a production machine you probably want to run it as a Windows Service. Running as a Windows Service has the advantage that you don’t need a user logged in to the machine to run WASP, you can also control it remotely using the Windows Service Control Manager application.

I’ve got quite a few plans for expanding the functionality that WASP provides. Ideally it should showcase all of the major options available with The Server Framework; so pretty soon I’ll be adding UDP support, hosting plugins written in managed code, providing secure TCP connections using SSL, etc. Plus I’m sure that some bugs will be shaken out as users push the system in ways that I haven’t anticipated and so haven’t tested.

The development of WASP has been acting as a bit of an internal driver for new feature development in the 6.3 release of The Server Framework. Sitting down to develop a service that was easy to use for a mass market exposed some small holes in the 6.2 release; nothing too serious but pretty soon after putting together the first service shell of the WASP application I had a list of nice to have additions for the Service Tools Library.

The easiest way to get started with WASP is to download the latest version from the download page, here, unzip the contents somewhere and then run the WASP executable, simply double click the executable in Explorer or navigate to the directory that you have installed WASP into and type “wasp”. The result should be that a log file is created in a subdirectory of the directory where the exe is located called log.

Version 6.3 of The Server Framework was released today. This release includes the following, see the release notes, here, for full details of all changes. Performance improvements on Vista and later operating systems. See here for more details. Performance improvements for some designs of datagram server by reusing sockets and buffers more aggressively and thus avoiding the allocators in some situations A redesigned the timer queue to improve timer dispatch performance.

WASP is, at heart, simply another example server for The Server Framework, but it’s also something a little new. Up until now potential clients have been able to look at the example servers source code and ask for pre-built executables for testing. The thing is, the examples are just that, examples and whilst release 6.2 of The Server Framework ships with over 70 examples (see here) they still only show small pieces of functionality in isolation.