Ah, sometimes I just love that younger me for getting to the point…
More here, thanks to Daniel Tarbotton for reminding me of things I said in the past… And, for a change, it seems that someone agrees! ;)
As I mentioned yesterday, I’m running Windows Server 2012 RC with my Intel 10 Gigabit AT2 adapters. I’ve had several emails asking me where I got the drivers from as the latest Intel drivers do not install.
Whilst it’s true that you can’t currently run the downloaded driver exe, PROWinx64.exe on Windows Server 2012 RC (or anything later than Win7). You CAN unzip the exe (it’s just an executable zip file) and then simply use the device manager to update the driver and then browse to the directory that you unzipped the exe into.
I’m still working on my investigation of the Windows Registered I/O network extensions, RIO, which I started back in October when they became available with the Windows 8 Developer Preview. I’ve improved my test system a little since I started and now have a point to point 10 Gigabit network between my test machines using two 2 Intel 10 Gigabit AT2 cards wired back to back.
My test system isn’t symmetrical, that is I have a much more powerful machine on one end of the link than on the other.
I’ve been watching Bartosz Milewski’s C++ 11 Concurrency videos and they’re a pretty good way to get up to speed on the new threading support in the latest C++ standard. They start off nice and slowly, for people who haven’t been doing concurrency for years, and explain the various new features provided by the language. It’s good stuff.
I’ve been reading Anthony Williams’ C++ Concurrency In action which is a great way to understand the details of what you’ll see in the videos.
I must admit that I didn’t really see how Azure could be of much use to anyone except really die-hard, bleeding edge, Microsoft only shops; that is up until yesterday.
The new Azure, which you can read about here on Scott Guthrie’s blog, seems much more usable for general purpose cloud solutions. Durable VMs, Linux VMs, easy migration to/from your own non Azure VHDs, direct access to their new low latency distributed cache from Memcached with no code changes necessary, lots of great new tooling and a REST based management API.
The best thing about Visual Studio 11 is that it doesn’t matter if you like the new style IDE or not. The project files are, at last, backwards compatible, so you can load them in Visual Studio 2010 and build with the new tool chain even though you ignore the new IDE - if that’s what you want to do.
I don’t like the new icons, but I find I can work fine in the IDE as long as I don’t think about it too much… Probably pretty much like how I felt about all previous versions when they were at the beta stage…
I know I’ve said this before, but now it’s really done…
The WebSocket protocol is now an official RFC. There are a small number of changes between RFC 6455 and the draft WebSocket protocol version 17; the only important ones being he addition of two new close status codes. The rest is just a case of tidying up the draft.
There will be a 6.5.3 release of The Server Framework to include these changes.
I’m just back from a wonderfully relaxing holiday in Italy. This time we had internet connectivity all the time, so I’m up to date on email, etc. The first thing that I do after all the ‘we’re back, how’s the house, and you need to go to bed even though you’re excited to see all of the toys you’ve missed’ stuff is to fire up all my machines and make sure that they do their windows update stuff… Then the NAS devices need to be started and allowed to settle in, then the VPN needs to be checked, dyndns kicked, etc.
I’ve been working with the WebSocket protocol recently, updating the code that implements the protocol in The Server Framework to the latest version of the draft standard (the HyBi 09 version). Whilst this looks like it’s almost a real standard, there are still lots of potentially open issues as can be seen from the HyBi discussion mailing list.
It’s quite clear from some of the less cohesive parts of the draft spec (and more so from the mailing list) that the protocol is very much a design by committee effort.
I have a client who is possibly suffering from TIME_WAIT exhaustion and I thought that the best way to find out for sure was to get them to add the TIME_WAIT perfmon counter to their normal counter logs so that we could see how and when sockets in TIME_WAIT accumulate on the machine.
The problem is that there doesn’t seem to be a perfmon counter for this, which is unfortunate, especially since you can easily get the number of established and reset connections from the TCPv4 and TCPv6 performance objects.
