- Increased performance due to major design changes in the dispatch and processing of completion and per socket buffer pooling.
- New lock classes which offer more efficient locking.
- Lots of breaking changes in the Service Tools library.
- The removal of deprecated compilers and operating systems and the addition of support for Visual Studio 2013 and Windows 8.1
- Added support for Out of Band data, TCP "Urgent mode".
October 2013 Archives
Version 6.6 of The Server Framework was released today.
This release is a major release and contains many changes, see the release notes, here, for full details of all changes.
All clients are advised to upgrade to this release.
The latest release of The Server Framework, which is due later this month, adds support for Visual Studio 2013 and Windows 8.1 as well as a host of other major changes.
As we first mentioned here, release 6.6 of The Server Framework removes support for Visual Studio .Net (2002) and Visual Studio .Net (2003). The 2002 compiler is no longer supported by Microsoft and the 2003 compiler becomes unsupported in October this year. To be honest, I'm very pleased to see the back of them. Hopefully most users of the framework are using at least Visual Studio 2005, if you're not, get in touch now.
We're also dropping support for Windows 2000, which Microsoft stopped supporting in 2010 this means the Windows XP is the earliest supported operating system for version 6.6.
Finally we're deprecating quite a bit of code. This will still be present in 6.6 but will, generally, be unavailable by default. You can add various defines to your Config.h to re-enable the deprecated code but be warned, it will be going in a future release.
The following code is deprecated in 6.6
CInOrderBufferList- use a
CSequentialBufferList- use a
- The entire concept of "shared" locks, so
CSmartSharedCriticalSection- the concept is no longer especially useful as the resource limitations and problems that existed with NT4 are now a thing of the distant past. However, since the code is still present in the framework people use it and end up with slower and more complex servers with contention between otherwise unrelated connections. Use the socket allocators that do NOT require lock factories as a replacement.
- Likewise the entire concept of "shared lock sockets" which require the above shared locks to work, so socket allocators no longer take lock factories as constructor arguments and
CSharedLockSequencedStreamSocketare also no longer available - but that's an implementation issue.
CCriticalSection2- use one of the new locks,
CDeflatingStreamSocketConnectionFilterand the "deflate-stream" WebSockets extension - note that "deflate-stream" was dropped from the final WebSocket standard and is not generally used.