One of the problems with iterative development of servers that include performance counters is that it’s quite easy for the counters that are installed on a machine to get out of sync with the counters that the server is actually compiled to use. As development progresses and new counters are added the counter dll needs to be uninstalled and then reinstalled so that the text strings associated with the counters remain in sync.
I’m currently fixing a bug in the UDP side of The Server Framework. The problem is that I’m failing to handle how Winsock reacts when an overlapped SendTo() results in an ICMP Port Unreachable response from the remote host. This error gets reported by failing a pending WSARecvFrom() on the same socket by returning 0 bytes from the WSARecvFrom() with an error code of ERROR_PORT_UNREACHABLE.
This would be fine if the framework didn’t assume that all errors from an overlapped WSARecvFrom should mean that we don’t post another read… You may recall from when I was doing some work on making the framework survive low resource situations that we can’t just issue another read when the previous one failed due to a low resource situation as we would just continue the problem, so we back off and recover later.
My current server development for a client has been going well but this week I finally got to the point where I wanted to look at the peformance counters it was presenting and they weren’t showing up in perfmon. My daily development for most projects is on my x64 box and I was building the server in x86 mode and although it was registering its counter DLL correctly it was an x86 DLL and the x64 perfmon can’t load x86 counter dlls.
I ran into an unexpected issue with OnSocketReleased()yesterday whilst writing a connection filter for a client. OnSocketReleased() is a callback method in The Server Framework that allows you to ‘do stuff’ at the last possible moment of a connection’s lifetime. It’s guaranteed to be the last callback ever called for a connection and it’s guaranteed not to be called until all references to a connection have been released; so you can’t get caught out by other threads still processing other last minute connection shutdown events.
Continuing last week’s theme of being wrong, ‘M’ pointed out to me in a comment on my posting about changing the memory allocation strategy for the IO buffer allocator that I actually have a bit more work to do… I’d forgotten that VirtualAlloc() allocates in terms of the memory allocation granularity of the operating system…. So, at present, the quick and dirty fix that I posted is allocating buffers in blocks of at least 64k of memory… They are, at least, page aligned ;) Thanks for pointing out the error of my ways, comments like this are one of the main reasons that I blog.
Whilst being wrong this week I reviewed some of the other socket server entries on this site and was reminded of an item that’s on a todo list somewhere by a comment on this posting from Matt: “What do you think about using VirtualAlloc to allocate page-aligned memory for the receive buffers? Would it reduce the number of locked pages? I mean if you allocate a buffer of ‘page size’ using ’new[]’ it is very likely that the buffer uses 2 pages instead of 1.
This week I’ve spent some of the time being wrong, which has proven useful as I’ve learned quite a lot and clarified my understanding of a situation. It all began when I had a bug report from a client who claimed that an obscure internal part of The Server Framework wasn’t working as he expected it to…
The report said that the m_outstandingWrites variable of the TAsyncSocket sometimes ‘stays above 2’.
The x64 version of our I/O completion port based, networking client and server framework, The Server Framework, is now shipping. This is the licensed version of the free server framework that’s available here. An overview of the licensed version can be found here. The changes from that version to the latest version can be found here.
The documentation for this version is available online, here. Please be patient, the docs are a work in progress and I know they could be better.
I’m finalising the testing of the x64 version of The Server Framework and, since it’s a fairly major release, I figured that it waranted an email to existing customers to see who wanted to have the update shipped to them straight away (although all existing customer are entitled to all upgrades to The Server Framework free of charge I usually rely on them monitoring this RSS feed and asking for new releases rather than just sending them out; generally only critical bug fixes are worthy of an email notification…).
It’s interesting, no, really, how the more things change the more they stay the same… I’ve been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port.
