The work on the CLR hosting socket server example is going pretty well. I now have a server that can pass server notifications to managed code that either runs in an AppDomain per connection or within a single AppDomain (depending on how isolated you want the user code to be). I think I’m pretty much there as far as what I want to demonstrate is concerned; it works and the line between managed and unmanaged code is likely to vary depending on a client’s particular requirements so there’s little point in extending the example code any further.
My investigations into CLR hosting are going well and today I built an echo sever based on The Server Framework and my CLR Hosting helper library. The idea is that the server can deal with the network IO and then hand off the ‘real work’ to some .Net code. So far the integration is going pretty smoothly….
People often ask me what the difference is between the free code that’s available on this website and the licensed version; this is what I reply…
Please note that the most up to date information on the licensed version of our high performance, super scalable, IO completion port based networking code will always be available from the dedicated website for The Server Framework. The latest version of The Server Framework is available in source code form, the same as the free version, but includes many new features , performance improvements and bug fixes.
The Server Framework now includes UDP multicast. There are a couple of new examples; a server that joins a multicast group and a client that sends to a multicast group.
Back in April 2006 I posted a copy of TickShifter, see here for details. It seems that there was a bug in my Win32 debugger code on which TickShifter is built. The bug was that we failed to “forget about” dlls that were unloaded… Because we failed to forget about them it was possible for the debugger code to try and do something with addresses in these dlls that were no longer loaded and this would cause a C++ exception on the debugger thread when our call to ReadProcessMemory() failed and this caused all sorts of problems…
Nice to see that the new beta, sorry, CTP, of the next .Net Framework will increase the performance of .Net sockets by 70%! Way to go .Net dudes….
Interesting to see that it’s a joint effort between the System.Net people (who, I assume own the sockets code) and the CLR people (who own the platform)… I wonder what the CLR guys brought to the tuning table…
It would be nice to know how the new (and existing) .
Back in July Joe Duffy wrote an interesting piece on the CLR thread pool. I commented on it then, here. He’s now written another piece about why they increased the maximum number of threads in “the thread pool” from 25/cpu to 250/cpu. Joe, I refer you to my previous comment… You’re solving the wrong problem!
I’m in Jackson Hole right now, my skis are still in Denver…
Although they’ve replaced the baggage handling system at Denver International Airport since the days of the classic software project failure, it seems that the current system could still need some work ;)
Hopefull I’ll see my skis later today…
This is mainly a reminder for me so that I can read this when I get back from Jackson Hole…
Dino Viehland has written some interesting looking blog posts on how to implement the thread/task and syncrhonisation host managers for a hosted CLR. Note that this is all “Whidbey beta 1” stuff so, well, your milage may vary…
I’m still playing with hosting the CLR in C++ (using “Customizing the Microsoft.NET Framework Common Language Runtime” by Steven Pratschner as my guide)… It’s an interesting journey but, once again, I wonder who makes the important technical decisions at Microsoft and how they sleep at night ;) .
I’m currently playing with the ICLRRuntimeHost interface. This lets you load the CLR into your unmanaged process and gives you a remarkable amount of control over how the CLR that you’re hosting operates.
