I’ve finished the write completion driven outbound data flow control connection filter that I started work on a while ago. This provides a way to deal with the problem of having more data to send to a client than the client can receive within a reasonable time. Rather than simply continuing to send and building up a massive amount of buffered data in the TCP/IP stack the connection filter keeps track of write completions and begins to buffer data for you when there are ’too many’ write operations outstanding.
Back in December and January I was working on the initial phases of a system to allow the development of custom Excel worksheet functions in managed code using the Excel XLL ‘C’ interface (Excel4v). Phase 1 finished with us having a pretty workable system that the client could go live with. The only problem was that we skipped the key ease of use part of the project due to time and budget constraints.
As I said in my recent posting about Data Distribution Servers, “Next on the list is writing a more focused server and clients.”. Tick.
I started out by writing the data feed. This was a simplified version of the echo server test harness that I’d extended to use a controllable TCP receive window. The data feed is just a client that generates random data in packets that have simple header, length, sequence number, type and sends it to the server that it’s connected to.
I really really really hate the error that I sometimes get when trying to copy a file from my Vista box to my NAS: “The mounted file system does not support extended attributes”. With the options to “Try again” or cancel. I suppose the “Try again” option is just in case the mounted file system changes its mind or the file somehow decides that the extended attributes that it’s somehow acquired aren’t actually required…
Many of the servers that are built with The Server Framework are for high number of connections and low data flow situations and as such that’s where the focus has been on the framework development and testing. As I’ve shown in the past, we can easily deal with 70,000 concurrent connections with various real world traffic flow patterns and have various test tools that can stress these kinds of servers. As importantly it’s easy to place a limit on the number of connections that a server can handle so as to protect the server (and other processes on the same machine) from resource limits (such a non-paged pool exhaustion).
It has been a busy couple of weeks for me. I’ve been working on an ISO 8583 based transaction server for a client and I set myself some fairly tight deadlines. I actually developed the first version of The Server Framework for another ISO 8583 transaction server that I developed for this client back in 2002. It’s interesting to look back at the original code and see how the framework has evolved (see here for the latest version), it’s also nice to know that the first server is still running nicely and providing customers with the ability to top up their pay as you go mobile phones at PayPoint outlets.
Last week I mentioned that some of my tests for my Win32 Debug API class had suddenly started failing. It seems that I was right and the changes are due to some .Net fixes that have been rolled out recently. The code runs and the tests pass if I run on a clean instal Vista x64 VM and fail on my day to day development box.
It seems that my plan to “stick a breakpoint in mscoree.
I found JP’s blog whilst googling for some information on RVA forwarders in PE files. There’s lots of good stuff there about reasonably low level Windows development, debugging, testing and API hooking. Recommended if you like the kind of stuff that I write about.
In addition to the blog postings JP has produced cfix a unit testing framework for C++. I haven’t had a chance to look at it too deeply yet, but the documentation looks good and the source is available from SourceForge under the GPL.
Back in October 2007 I sumarised my findings from getting my Win32 DebugAPI based debug engine working on x64. One of the strange things that I found at the time was this:
When running a CLR app under the Win32 debug interface you only ever seem to hit the native entry point if you’re running under WOW64. In all other situations you don’t hit the native entry point ever. If you rely on it to pause your debug tools once the process is completely loaded and ready to roll then you need to stick a break point in _CorExeMain in mscoree.
I’ve been putting together a sample server for a client that shows how to cleanly terminate a socket connection. This should have been a simple thing to do, but in doing so I’ve discovered some gnarlyness within The Server Framework and the result has been some new TODO items for the 5.3 release…
When you have an active TCP/IP connection that you wish to terminate cleanly you need to initiate a TCP/IP protocol level shutdown sequence by calling shutdown().
