Asynchronous Events

We have a new client profile available here for a client that began using The Server Framework in its GeognoSIS web mapping product in September 2010.

Version 6.4 of The Server Framework was released today. This release includes the following, see the release notes, here, for full details of all changes. The ability to enable, configurable, automatic, crash dump creation on certain error conditions. Two new single reader, multiple writer, lock implementations. Full code page support for unicode to multi-byte conversions. Rationalisation of output from ToHexString() variants. The ability to limit the number of pending file writes to a collection of asynchronous file writers.

I’m in the process of completing a custom server development project for a client. The server deals with connections from thousands of embedded devices and allows them to download new firmware or configuration data and upload data that they’ve accumulated in their local memory. To enable maximum scalability the server use asynchronous reads and writes to the file system as well as the network. One feature of the server is the ability to configure it to create per session log files.

There’s a bug in CStringConverter::WtoA() when the default system code page is set to a multi-byte code page. The result is that the call will fail with an exception stating that “The data area passed to a system call is too small”. This was due to some naive code page handling (or lack of handling) in the code that determined the required buffer size. This bug will be fixed in release 6.

The next release of The Server Framework, 6.4, includes code which allows a server to create a crash dump whilst it is running. Typically you might want to do this if some strange and possibly fatal exception gets thrown. Crash dumps are a great way to debug a server that is failing in production, the server generates the dump when something goes wrong and you can then load up the dump on your development machine and your debugger will be sitting on the line that caused the problem.

The CIOPool class’s constructor takes a ThreadIdentifier value which is used to allow the threads in the pool to know that they’re in the pool. The value is stored in thread local storage for each thread in the pool and can then be examined to determine if a thread belongs to the I/O pool. The value can also be queried and other threads can ‘be treated as I/O pool threads’ by setting the appropriate TLS slot to this value.

I’ve been doing a lot of performance related work over the past few months. Much of it has originally stemmed from work that I have been doing for our Online Game Company client. They want the asynchronous ENet-based server that we’ve built for them to be the fastest it can be and so I’ve been looking at all aspects of performance within the framework. The testing hasn’t brought anything too embarrassing to light; the I/O recursion limiter that was introduced in 6.

Overview When building TCP client server systems it’s easy to make simple mistakes which can severely limit scalability. One of these mistakes is failing to take into account the TIME_WAIT state. In this blog post I’ll explain why TIME_WAIT exists, the problems that it can cause, how you can work around it, and when you shouldn’t. TIME_WAIT is an often misunderstood state in the TCP state transition diagram. It’s a state that some sockets can enter and remain in for a relatively long length of time, if you have enough socket’s in TIME_WAIT then your ability to create new socket connections may be affected and this can affect the scalability of your client server system.

We have a new client profile available here for a client that we’ve had since 2006 in the IP Fax business.

Version 6.3.3 of The Server Framework was released today. This release is purely a bug fix release and includes the following fix. A fix to JetByteTools::Service::CServiceManager so that it actually allows the service to run without throwing an exception! Fixes to JetByteTools::CLRHosting::CCLREventSink and JetByteTools::CLRHosting::CHostPolicyManager to remove a race condition during host shutdown which could have caused a purecall due to events being fired after the event sink has been destroyed. There’s no need for a documentation update so the latest docs available online will be for the 6.