There are two bugs in the Performance Counter library and example servers that mean that performance counters built with the library and following the examples shown in the example servers will fail to work correctly when viewed remotely from another machine. What’s more the remote instance of perfmon will fail to display any counters from the machine with the broken performance counters installed.
The first problem is that the code that checks to see that the process that has loaded the counter dll has the correct privileges to be able to connect to the shared memory segment that is used to communicate between the service and the counters is broken when it’s called from within svchost.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Admin Library - 6.2
We now support Visual Studio 2010. At present the code has only been tested with the beta and release candidate versions.
New build configuration options. All of these are enabled by defining the option to 1 in Config.h and disabled by defining them to 0; the default state if you do not do anything in Config.
I’m just finishing a batch of work that will be included in the 6.2 release of my IOCP based, high performance windows client and server framework and which improves the performance of the framework. There are two main improvements; the first is that the filtering API is now completely optional. There are now filtering and non-filtering base classes so that you only need to include filtering support if you need it.
As I mentioned a while back I’ve been looking at incorporating some simple performance gains in the framework by following the advice given over at the Windows Server Performance Team Blog. Specifically the advice from part three of the “Designing Applications for High Performance” series of postings.
Whilst I’d done some quick and dirty tests with the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag of SetFileCompletionNotificationModes() and all looked good I’m now working my way through my unit tests and adjusting them to work both when this option is enabled and when it’s not (completion dispatch changes somewhat when it’s enabled and my tests are invasive enough to notice this).
Charles Dickens said it best in A Tale of Two Cities; “It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to heaven, we were all going direct the other way”.
The filtering API that’s built into the stream (i.e. TCP) side of the licensed framework is pretty powerful. It’s what the OpenSSL, SChannel and SSPI Negotiate filters use to transform the data as it flows into and out of your server without you needing to do anything special; it’s what the flow control filter uses to provide efficient TCP window based flow control; it’s what the compression filter uses to compress your data stream; it’s what the read timeout filter uses to provide you with asynchronous read timeouts on overlapped I/O and what the connection re-establishment filter uses to automatically reconnect if your connection goes down.
I’ve been spending a little time recently writing a custom Wireshark dissector plugin for the UDT protocol. This didn’t prove to be that difficult once I got over the initial problem of actually getting the Wireshark source to build with VS2008. My problem was that I’d found a CodeProject article which is now slightly out of date and which I followed too closely - setting up the Platform SDK version that the article stated was required.
As I mentioned a while back the CLR Hosting API has changed with .Net 4.0. The new API allows you much more flexibility in loading CLR runtimes and also allows you to load and run multiple different runtimes in a single process. Whilst this is useful if you need to control which runtime runs your code and indispensable if you need to host code that really requires different versions of the runtime and can’t all run in the “latest” runtime, I think the times when a user of my CLRHosting libraries will actually need this functionality will be few and far between.
The licensed version of my freely available I/O Completion Port based, high performance, Windows networking framework provides a whole host of features that the free code doesn’t; aside from performance improvements, bug fixes and an active support and development process. These features make writing highly scalable TCP and UDP clients and servers very easy and solve many of the problems that you would come across if you were to start from scratch, either with the Winsock API directly or using something such as boost::asio.
Compressing TCP (and reliable UDP) streams is one of the things that often comes up in discussion with clients and I’ve helped several people implement stream compression using the TCP stream filtering API that’s part of The Server Framework. The filtering API is also used to provide SSL security over a stream and for things like asynchronous read timeouts, read sequencing, flow control and automatic reconnects. It’s a flexible API and the fact that it’s pluggable means that you can pick and choose from the various filters that form part of the framework and add whichever combination you fancy.
