Overview To enable network applications to send and receive data via a TCP connection reliably and efficiently the TCP protocol includes flow control which allows the TCP stack on one side of the connection to tell the TCP stack on other side of the connection to slow down its data transmission, or to stop sending data entirely. The reason that this is required is that the TCP stack in each peer contains buffers for data transmission and data reception and flow control is required to prevent a sender from sending when a receiver’s buffer is full.

Dhanji over at Rethrick Construction has written an interesting piece on the value of unit testing. I agree with his conclusion; “So the next time someone comes to you saying let’s write the tests first, or that we should aim for 80% code coverage, take it with a healthy dose of scepticism.” But then I tend to take everything with a dose of scepticism… I also agree with the fact that sometimes the tests get in the way of refactorings that you’d like to do and sometimes the tests give you more code that needs to be maintained and that they often appear to slow down your development time.

We have a new client profile available here for a client that began by using The Free Framework and then switched to using The Server Framework to take advantage of the advanced features that it offers.

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.

We are building a server for a custom electronics manufacturer who would prefer to remain nameless. The server will manage communication and firmware updates for networks of thousands of smart devices using The Server Framework.

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.