https://serverframework.com/ Recent content from ServerFramework.com Hugo -- gohugo.io en-uk Wed, 24 Apr 2024 10:30:00 +0100 https://serverframework.com/asynchronousevents/2024/04/bug-in-oob-data-handling.html Wed, 24 Apr 2024 10:30:00 +0100 https://serverframework.com/asynchronousevents/2024/04/bug-in-oob-data-handling.html There’s a bug in the TCP OOB (out of band) data handling code in all versions of The Server Framework from 6.6 through to 7.4. This issue manifests as a purecall during socket destruction and is due to a race condition during the release of the last two references held on a socket. If you don’t use OOB then a simple work around is to comment out the following in TAsyncSocket. https://serverframework.com/asynchronousevents/2023/04/windows-registered-io-code-update.html Sat, 15 Apr 2023 15:35:00 +0100 https://serverframework.com/asynchronousevents/2023/04/windows-registered-io-code-update.html The code for this series of articles is now available on GitHub and has been updated for Visual Studio 2022. This code is licensed with the MIT license. I’ve updated the code as I expect it will be useful as a comparison to the code that I eventually come up with for using \Device\Afd to access the Windows networking stack. You can read about my adventures with Afd here https://serverframework.com/asynchronousevents/2023/04/stability.html Wed, 12 Apr 2023 14:32:00 +0100 https://serverframework.com/asynchronousevents/2023/04/stability.html It seems amazing but the last time we did a release of The Server Framework was in 2021. Since then the mainline development of the framework has been pretty stable with no new bug reports. Most of the time the code doesn’t need a new release to handle minor changes in compiler version and often it’s easy enough for client’s to do these changes themselves. I’m planning a maintenance release, 7. https://serverframework.com/asynchronousevents/2021/09/recent-release-notifications.html Thu, 16 Sep 2021 08:38:33 +0000 https://serverframework.com/asynchronousevents/2021/09/recent-release-notifications.html We’ve just found out that an email misconfiguration means that some emails to serverframework.com email addresses have been bouncing. This should be fixed now! Sorry about the inconvenience. If you have contacted us recently and not had a reply, please try again now! https://serverframework.com/asynchronousevents/2021/09/recent-releases-and-80-beta-1.html Sun, 12 Sep 2021 19:30:04 +0000 https://serverframework.com/asynchronousevents/2021/09/recent-releases-and-80-beta-1.html As you’ll see, we released 3 new versions of The Server Framework today. Of these, only the 7.3 release includes code changes. The 7.2 release updates almost every header file in the framework to remove ‘old style’ include guards and touches lots of source files to remove lint directives that we no longer use. This kind of change creates a lot of noise in an update and so it has been done separately to the functional changes to make it easier for users of the framework to see what has actually been changed in 7. https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-74.html Sun, 12 Sep 2021 19:30:02 +0000 https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-74.html Version 7.4 of The Server Framework was released today. This release includes no bug fixes and no new code. It removes deprecated code and removes support for Visual Studio 2015. https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-73.html Sun, 12 Sep 2021 19:30:01 +0000 https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-73.html Version 7.3 of The Server Framework was released today. This release includes bug fixes and new code. As always, see the release notes here, for full details of all changes. Bug fixes: Fixed a bug with JetByteTools::Core::CCallbackTimerWheel which would show up if the time provider was providing ticks at a different granularity than the granularity of the wheel. Fixed a bug in CDatagramSocketConnectionManager and CDatagramSocketServer where the buffers returned in write and sendTo completion callbacks had an incorrect number of bytes set as ‘used’. https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-72.html Sun, 12 Sep 2021 19:30:00 +0000 https://serverframework.com/asynchronousevents/2021/09/latest-release-of-the-server-framework-72.html Version 7.2 of The Server Framework was released today. This release includes no bug fixes and no new code. It adds support for Visual Studio 2022 and removes redundant manual include guards from most header files and removes unused “lint” directives from some of the older files. As such this release just serves as a stepping stone to the 7.3 release and makes it easier to see the changes that are made in the 7. https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-71.html Fri, 29 Jan 2021 08:49:00 +0000 https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-71.html Version 7.1 of The Server Framework was released today. This release includes no bug fixes but begins to apply transformations that will allow code to compile on different platforms. The next release, 7.2, will add in functional changes and bug fixes. If you haven’t yet migrated to 7.x, please see the 7.0 release notes. There will be no more releases of the 6.9.x release stream. As always, see the release notes here, for full details of all changes. https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-70.html Mon, 18 Jan 2021 12:40:00 +0000 https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-70.html Version 7.0 of The Server Framework was released today. This release includes no functional changes or bug fixes but moves code that could compile on different platforms out of the Win32Tools library and into a new CoreTools library. It also updates all include paths to use / rather than \ as / is valid on Unix-based systems and also on Windows. The next release, 7.1, will begin to move the code towards cross platform compilation and the release after that will add in functional changes and bug fixes. https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-695.html Mon, 18 Jan 2021 10:45:00 +0000 https://serverframework.com/asynchronousevents/2021/01/latest-release-of-the-server-framework-695.html Version 6.9.5 of The Server Framework was released today. This release includes changes to support Visual Studio 2019 (16.5 - 16.9), some new functionality and a bug fixes. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix in JetByteTools::SChannel::CServerContext::ContinueHandshake() so that we return HandshakeFatalError and set the last status correctly on failure rather than throwing an exception. This allows us to correctly report, or not, the issue to the other side. https://serverframework.com/asynchronousevents/2020/01/latest-release-of-the-server-framework-694.html Fri, 17 Jan 2020 12:15:20 +0000 https://serverframework.com/asynchronousevents/2020/01/latest-release-of-the-server-framework-694.html Version 6.9.4 of The Server Framework was released today. This release includes changes to support Visual Studio 2019 (16.4), some new functionality and a bug fix to our OpenSSL ALPN handling code. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::OpenSSL::CAsyncConnector. We were dealing with ALPN callbacks incorrectly and this could cause an access violation. Changes: Added a debug log message to alert you to the fact that a JetByteTools::IO::CAsyncFileLog instance has had OnPendingWriteLimit() called. https://serverframework.com/asynchronousevents/2019/10/latest-release-of-the-server-framework-693.html Thu, 10 Oct 2019 10:10:19 +0000 https://serverframework.com/asynchronousevents/2019/10/latest-release-of-the-server-framework-693.html Version 6.9.3 of The Server Framework was released today. This release includes changes to support Visual Studio 2019 (16.3), lots of code changes to migrate towards “modern C++” idioms, issues raised by Resharper++ and changes in include path separators and file name case to support compilation on Linux. We have also removed some code that was previously deprecated and dropped support for Visual Studio 2013. There are no bug fixes or intentional functionality changes to this release but a LOT of files have been touched; we decided to put this release out so that functionality and bug fix changes can be more easily seen going forwards. https://serverframework.com/asynchronousevents/2019/07/latest-release-of-the-server-framework-692.html Mon, 01 Jul 2019 09:00:00 +0000 https://serverframework.com/asynchronousevents/2019/07/latest-release-of-the-server-framework-692.html Version 6.9.2 of The Server Framework was released today. This release includes changes to support Visual Studio 2017 (15.9), Visual Studio 2019 (16.2), design changes to the PerfMon tools library to improve performance and some bug fixes. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::Win32::TimeChangeNotificationMonitor and JetByteTools::Win32::CSystemShutdownMonitor so that we don’t truncate the pointer passed SetWindowLongPtr(). Truncation was rarely occurring to just the top bits. https://serverframework.com/asynchronousevents/2018/01/latest-release-of-the-server-framework-691.html Thu, 18 Jan 2018 14:00:00 +0000 https://serverframework.com/asynchronousevents/2018/01/latest-release-of-the-server-framework-691.html Version 6.9.1 of The Server Framework was released today. This release includes changes to support Visual Studio 2017 15.5 and some bug fixes. It’s required if you’re using Visual Studio 2017. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::Win32::TimeChangeNotificationMonitor so that it doesn’t leak window timer handles. Note the leak was, at worst, one handle per object lifetime. Bug fix to JetByteTools::Win32::TZeroInitialiseExpandableBuffer for when it’s instantiated with non-POD types. https://serverframework.com/asynchronousevents/2017/11/latest-release-of-the-server-framework-69.html Mon, 27 Nov 2017 10:15:00 +0000 https://serverframework.com/asynchronousevents/2017/11/latest-release-of-the-server-framework-69.html Version 6.9 of The Server Framework was released today. This release includes lots of code change due to: the removal of support for Visual Studio 2012 and the results of lots of static analysis. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::Win32::TAddressOrderedMultiLock::Unlock() which was not setting the ’locked’ flag correctly and so could lead to locks being unlocked multiple times. https://serverframework.com/asynchronousevents/2016/12/latest-release-of-the-server-framework-68.html Mon, 05 Dec 2016 09:31:08 +0000 https://serverframework.com/asynchronousevents/2016/12/latest-release-of-the-server-framework-68.html Version 6.8 of The Server Framework was released today. This release includes important bug fixes. It also includes lots of code change due to: the removal of support for Visual Studio 2010, adding support for Visual Studio 2017 and the results of lots of static analysis. This release is essential for users of Release 6.7. As always, see the release notes here, for full details of all changes. Bug fixes: https://serverframework.com/asynchronousevents/2016/12/bug-in-multi-buffer-writes-in-67.html Mon, 05 Dec 2016 09:31:01 +0000 https://serverframework.com/asynchronousevents/2016/12/bug-in-multi-buffer-writes-in-67.html A bug has been discovered in Release 6.7 in the code that deals with TCP socket writes that involve more than a single buffer. These ‘multi-buffer writes’ are writes that involves either a buffer chain or a block of data passed as a pointer and a length where the length exceeds the size of the buffer allocator that the connection is using. The bug prevents the ‘multi-buffer write’ from being executed as a single atomic write at the network layer and so can cause corruption of a TCP data stream if multiple sockets are writing to the same connection concurrently. https://serverframework.com/asynchronousevents/2016/07/supporting-visual-studio-2015-update-3.html Mon, 11 Jul 2016 10:15:12 +0000 https://serverframework.com/asynchronousevents/2016/07/supporting-visual-studio-2015-update-3.html Visual Studio Update 3 adds some new warnings for precompiled header generation. One of these, C4598, will prevent precompiled header builds of framework code due to our warnings as errors policy. A fix for this issue is to add the new warning to the list of disabled warnings in the project file. The easiest way to do this is to do a search and replace across your source tree for *. https://serverframework.com/asynchronousevents/2016/06/latest-release-of-the-server-framework-67.html Thu, 09 Jun 2016 14:00:00 +0000 https://serverframework.com/asynchronousevents/2016/06/latest-release-of-the-server-framework-67.html Version 6.7 of The Server Framework was released today. This release is mainly a code simplification release which removes support for legacy compilers and operating systems. See here for more details. However, there are some breaking changes where smart buffers have replaced buffer references and this causes function signature changes. In addition there has been considerable churn in the Streaming Media Option Pack with knock on changes in the HTTP library code which needed to be made more complete to deal with serving HLS streams. https://serverframework.com/asynchronousevents/2016/06/67---potentially-faster-code-in-some-circumstances.html Wed, 08 Jun 2016 10:00:00 +0000 https://serverframework.com/asynchronousevents/2016/06/67---potentially-faster-code-in-some-circumstances.html I hinted at the end of the last post that the 6.7 release might increase performance a little. Well, whilst the bulk of the changes in 6.7 are purely code cleaning and the removal of legacy support there is a fairly major functional change as well. In most situations references or pointers to I/O buffers have been replaced with smart pointers. This change may cause some issues during an upgrade as you need to change some function signatures from IBuffer refs to CSmartBuffers. https://serverframework.com/asynchronousevents/2016/06/another-release-is-coming.html Tue, 07 Jun 2016 13:06:00 +0000 https://serverframework.com/asynchronousevents/2016/06/another-release-is-coming.html We’ve only just shipped Release 6.6.5 of The Server Framework but we already have another release that’s just about to ship. This isn’t because some horrible bug has slipped through our testing, it’s because we’ve been planning to produce a ‘clean up’ release for some time. 6.7 is that release. Lets be straight here, 6.7 is a release for us more than for you. The aim is to simplify our build/test and release process, remove dead code whilst introducing no new bugs and removing no functionality that you rely on. https://serverframework.com/asynchronousevents/2016/06/latest-release-of-the-server-framework-665.html Thu, 02 Jun 2016 09:50:00 +0000 https://serverframework.com/asynchronousevents/2016/06/latest-release-of-the-server-framework-665.html Version 6.6.5 of The Server Framework was released today. This release is mainly a feature release with a few bug fixes. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::Socket::TAsyncSocket::ProcessAndGetNextOperation(). We now wrap the body of the function in an exception handler and abort the connection with JetByteTools::Socket::ConnectionClosureReason::FatalErrorAbort if an exception is thrown during processing. This fixes a bug whereby the connection would otherwise hang in these situations. https://serverframework.com/asynchronousevents/2015/12/tls-12-handshake-failure-for-certificates-signed-with-md5.html Wed, 16 Dec 2015 15:52:39 +0000 https://serverframework.com/asynchronousevents/2015/12/tls-12-handshake-failure-for-certificates-signed-with-md5.html A while back a client of mine had an issue with a TLS 1.2 connection failing during the TLS handshake. We couldn’t see any issues with the code and if we only enabled TLS 1.1 on the server then the connection handshake worked just fine. Eventually we tracked the issue down to the fact that the certificate in use had been signed with MD5 and that MD5 isn’t a valid hash algorithm for TLS 1. https://serverframework.com/asynchronousevents/2015/12/latest-release-of-the-server-framework-664.html Mon, 14 Dec 2015 14:44:44 +0000 https://serverframework.com/asynchronousevents/2015/12/latest-release-of-the-server-framework-664.html Version 6.6.4 of The Server Framework was released today. This release is mainly a bug fix release for clients using WebSockets over SSL. As always, see the release notes here, for full details of all changes. Bug fixes: Bug fix to JetByteTools::Win32::CallbackTimerQueueBase which prevents the timeout handle from ever being incremented to zero. It’s unlikely but possible. Bug fix to JetByteTools::Win32::CBuffer and JetByteTools::Win32::CLockFreeBuffer to make code take notice of when m_maxBytesToRead is set. https://serverframework.com/asynchronousevents/2015/08/latest-release-of-the-server-framework-663.html Tue, 25 Aug 2015 10:30:00 +0000 https://serverframework.com/asynchronousevents/2015/08/latest-release-of-the-server-framework-663.html Version 6.6.3 of The Server Framework was released today. This release is mainly a bug fix release but it also adds support for Visual Studio 2015 and Windows 10 (though we don’t explicitly use any Windows 10 APIs). There are quite a lot of small changes due to us running Gimpel Lint over the code. Most of the changes will have fixed potential issues rather than issues that have actually been reported. https://serverframework.com/asynchronousevents/2015/01/wsarecv-wsasend-and-thread-safety.html Mon, 19 Jan 2015 10:00:00 +0000 https://serverframework.com/asynchronousevents/2015/01/wsarecv-wsasend-and-thread-safety.html Last week I learnt something new, which is always good. Unfortunately it was that for over 15 years I’d been working under a misconception about how an API worked. TL;DR When using WSARecv() and WSASend() from multiple threads on a single socket you must ensure that only one thread calls into the API at a given time. Failure to do so can cause buffer corruption. It all began with this question on StackOverflow and I dived in and gave my usual response. https://serverframework.com/asynchronousevents/2014/10/dropping-support-for-visual-studio-2005-and-2008.html Mon, 20 Oct 2014 09:57:09 +0000 https://serverframework.com/asynchronousevents/2014/10/dropping-support-for-visual-studio-2005-and-2008.html The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Visual Studio 2005 or Visual Studio 2008. The 6.6.x releases will be the last to support these compilers. Please get in touch immediately if this will be a problem for you. https://serverframework.com/asynchronousevents/2014/10/dropping-support-for-windows-xp-and-server-2003.html Mon, 20 Oct 2014 09:46:50 +0000 https://serverframework.com/asynchronousevents/2014/10/dropping-support-for-windows-xp-and-server-2003.html The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Windows XP or Windows Server 2003. The 6.6.x releases will be the last to support these operating systems. Release 6.6.3, is due shortly and is a minor bug fixing release. We may release subsequent 6.6.x bug fix releases but no new development will occur on the 6.6 branch. Removal of support for these operating systems allows us to clean up the code considerably and to remove lots of code that’s required purely to work around ‘interesting’ twists in various Windows APIs pre-Vista. https://serverframework.com/asynchronousevents/2014/10/new-option-pack-streaming-media.html Mon, 13 Oct 2014 10:45:00 +0000 https://serverframework.com/asynchronousevents/2014/10/new-option-pack-streaming-media.html We have a new Option Pack, The Streaming Media Option Pack. This allows you to easily add streaming of H.264 and MPEG audio and video to your clients and servers using RTSP, RTP and RTCP. With more and more Internet Of Things devices supporting rich media streaming for remote monitoring it’s becoming essential to have the ability to manage these media streams within your device management servers and clients. Whether it’s recording device streams for later analysis or arbitrating between multiple clients and devices, manipulating streaming media is becoming more and more important. https://serverframework.com/asynchronousevents/2014/09/new-client-profile-eonic-gaming---turf-battles.html Mon, 15 Sep 2014 16:30:03 +0000 https://serverframework.com/asynchronousevents/2014/09/new-client-profile-eonic-gaming---turf-battles.html We have a new client profile available here for a new client who is using The Server Framework to power their MMORPG game server. https://serverframework.com/asynchronousevents/2014/08/latest-release-of-the-server-framework-662.html Fri, 01 Aug 2014 14:00:00 +0000 https://serverframework.com/asynchronousevents/2014/08/latest-release-of-the-server-framework-662.html Version 6.6.2 of The Server Framework was released today. This release is a bug fix and internal feature release which results in lots of change to the OpenSSL, SChannel, Compression and TCP flow control filters. See the release notes here, for full details of all changes. All clients using earlier versions of both the OpenSSL Option Pack and the SChannel Option Pack are advised to upgrade to this release. Bug fixes: https://serverframework.com/asynchronousevents/2014/07/udp-flow-control-and-asynchronous-writes.html Tue, 22 Jul 2014 17:33:00 +0000 https://serverframework.com/asynchronousevents/2014/07/udp-flow-control-and-asynchronous-writes.html I don’t believe that UDP should require any flow control in the sending application. After all, it’s unreliable and it should be quite OK for any stage of the route from one peer to another to decide to drop a datagram for any reason. However, it seems that, on Window’s at least, no datagrams will be dropped between the application and the network interface card (NIC) driver, no matter how heavily you load the system. https://serverframework.com/asynchronousevents/2014/02/latest-release-of-the-server-framework-661.html Mon, 17 Feb 2014 10:30:00 +0000 https://serverframework.com/asynchronousevents/2014/02/latest-release-of-the-server-framework-661.html Version 6.6.1 of The Server Framework was released today. This release is a minor bug fix release mainly for several bugs in the 6.6 version’s OpenSSL code, see the release notes here, for full details of all changes. All clients using version 6.6 of the OpenSSL Option Pack are advised to upgrade to this release. Bug fixes: Bug fix to JetByteTools::OpenSSL::CAsyncConnector so that we spot failures in the SSL allocation functions due to low memory situations and throw exceptions if we fail to create the SSL objects. https://serverframework.com/asynchronousevents/2014/02/openssl-outbound-connection-establishment-failure-bug-in-version-66-of-the-server-framework.html Mon, 03 Feb 2014 13:50:21 +0000 https://serverframework.com/asynchronousevents/2014/02/openssl-outbound-connection-establishment-failure-bug-in-version-66-of-the-server-framework.html I’ve just found and fixed a bug in version 6.6 of the OpenSSL Option Pack which relates to how we deal with outbound connection establishment errors. Changes in 6.6 mean that the OpenSSL ‘connector’ holds a reference to the socket whilst the SSL connection is active. The bug prevents connections which fail to be established from closing and causes a socket leak. Note that this is ONLY for outbound (client) connections that you establish with The Server Framework. https://serverframework.com/asynchronousevents/2013/11/new-client-profile-wave-systems-corp.html Thu, 21 Nov 2013 10:00:00 +0000 https://serverframework.com/asynchronousevents/2013/11/new-client-profile-wave-systems-corp.html We have a new client profile available here for a new client who is using The Server Framework for secret things that they can’t tell us about! https://serverframework.com/asynchronousevents/2013/11/new-client-profile-chinese-company---m2m-server.html Tue, 19 Nov 2013 09:25:00 +0000 https://serverframework.com/asynchronousevents/2013/11/new-client-profile-chinese-company---m2m-server.html We have a new client profile available here for a new client who selected The Server Framework to replace its previous networking layer in an M2M server which deals with 20,000 devices connected via GPRS. https://serverframework.com/asynchronousevents/2013/11/new-client-profile-tricerat-inc---printer-sharing.html Sun, 17 Nov 2013 10:30:00 +0000 https://serverframework.com/asynchronousevents/2013/11/new-client-profile-tricerat-inc---printer-sharing.html We have a new client profile available here for a client who uses The Server Framework in their Printer presence and print job transfer system. They use both the OpenSSL Option Pack and the SSPI Option Pack in their product. The ease of adding security and authentication which can communicate with a disparate selection of clients is one of the strong points of developing with The Server Framework. https://serverframework.com/asynchronousevents/2013/11/new-client-profile-french-security-hardware-company---m2m-server-for-smart-alarm-panels.html Thu, 14 Nov 2013 13:19:31 +0000 https://serverframework.com/asynchronousevents/2013/11/new-client-profile-french-security-hardware-company---m2m-server-for-smart-alarm-panels.html We have a new client profile available here for a new French client who uses The Server Framework in an M2M server to control its smart alarm panels. https://serverframework.com/asynchronousevents/2013/10/latest-release-of-the-server-framework-66.html Fri, 11 Oct 2013 14:00:00 +0000 https://serverframework.com/asynchronousevents/2013/10/latest-release-of-the-server-framework-66.html 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. 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. https://serverframework.com/asynchronousevents/2013/10/release-66-to-support-visual-studio-2013-and-windows-81.html Tue, 08 Oct 2013 09:08:12 +0000 https://serverframework.com/asynchronousevents/2013/10/release-66-to-support-visual-studio-2013-and-windows-81.html 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. https://serverframework.com/asynchronousevents/2013/10/saying-goodbye-to-compilers-operating-systems-and-code.html Tue, 08 Oct 2013 09:00:00 +0000 https://serverframework.com/asynchronousevents/2013/10/saying-goodbye-to-compilers-operating-systems-and-code.html 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. https://serverframework.com/asynchronousevents/2013/07/new-client-profile-geosocket-information-inc---oil-and-gas-industry-gis-developer.html Mon, 01 Jul 2013 10:10:43 +0000 https://serverframework.com/asynchronousevents/2013/07/new-client-profile-geosocket-information-inc---oil-and-gas-industry-gis-developer.html We have a new client profile available here for a new Chinese client who uses The Server Framework to build servers for its GIS applications for the Oil and Gas industry. https://serverframework.com/asynchronousevents/2013/06/new-client-profile-korean-gaming-company---mobile-gaming.html Tue, 04 Jun 2013 08:17:18 +0000 https://serverframework.com/asynchronousevents/2013/06/new-client-profile-korean-gaming-company---mobile-gaming.html We have a new client profile available here for a new client who selected The Server Framework to build the servers for its iOS and Android games. https://serverframework.com/asynchronousevents/2013/04/66---breaking-changes---service-tools-library.html Tue, 02 Apr 2013 16:00:00 +0000 https://serverframework.com/asynchronousevents/2013/04/66---breaking-changes---service-tools-library.html Release 6.6 of The Server Framework includes some breaking changes to both the IService, IServiceCallbacks and IShutdownService interfaces. Many functions now return an ServiceTools::ExitCode, either directly or by value, which allows you to fine tune the exit code returned from your service under failure conditions. This exit code is reported to the Service Control Manager (SCM) when your service shuts down and also returned from the exe if you run the service as a normal exe. https://serverframework.com/asynchronousevents/2013/04/slightly-more-efficient-locking.html Mon, 01 Apr 2013 16:30:00 +0000 https://serverframework.com/asynchronousevents/2013/04/slightly-more-efficient-locking.html Another performance improvement in the forthcoming 6.6 release is due to a change in our default choice for locking primitives on most platforms. Note that the perf improvement is small and, according to our testing, it doesn’t materialise on all hardware (though there’s no performance degradation seen). The change is to switch from using CRITICAL_SECTION objects to using Slim Reader Writer Locks in exclusive (write) mode. You can read about the differences between these two locks in Kenny Kerr’s MSDN article here. https://serverframework.com/asynchronousevents/2013/03/reducing-context-switches-and-increasing-performance.html Wed, 27 Mar 2013 16:00:00 +0000 https://serverframework.com/asynchronousevents/2013/03/reducing-context-switches-and-increasing-performance.html I’ve been working on a “big” new release for some time, too long actually. It has steadily been accumulating new features for over a year but the arrival of my second son in July last year and masses of client work has meant that it has repeatedly been pushed on the back burner. Well, no more, Release 6.6 is now in the final stages of development and testing (so I won’t be adding more new features) and hopefully will see a release in Q2 https://serverframework.com/asynchronousevents/2013/01/latest-release-of-the-server-framework-659-1.html Mon, 07 Jan 2013 16:49:15 +0000 https://serverframework.com/asynchronousevents/2013/01/latest-release-of-the-server-framework-659-1.html Version 6.5.9 of The Server Framework was released today. This release contains one bug fix for write sequencing bug which has been present in The Server Framework since at least release 5.0 but which, thankfully, is very unlikely to occur. It also contains a bug fix for the TCP flow control filter, some bug fixes for the WebSocket code, hardening of the WebSocket code to help it resist denial of service attacks and a small amount of new functionality in several other libraries. https://serverframework.com/asynchronousevents/2012/09/latest-release-of-the-server-framework-659.html Thu, 20 Sep 2012 08:55:21 +0000 https://serverframework.com/asynchronousevents/2012/09/latest-release-of-the-server-framework-659.html Version 6.5.8 of The Server Framework was released today. This release contains one bug fix for a bug which has been present in The Server Framework since at least release 5.0 and one change to work around a bug in Windows 8 and Server 2012. If you plan to use AcceptEx() on Windows 8 or Server 2012 or you have connections which run for a long period of time, use sequenced sockets and issue more than 2,147,483,647 writes on a socket then you need this release. https://serverframework.com/asynchronousevents/2012/09/write-sequencing-bug-in-all-versions-of-the-server-framework.html Tue, 18 Sep 2012 07:12:00 +0000 https://serverframework.com/asynchronousevents/2012/09/write-sequencing-bug-in-all-versions-of-the-server-framework.html I’ve just found and fixed a bug which has been present in The Server Framework from the very beginning. The problem affects connections which are “sequenced” and which have had more than 2,147,483,647 writes performed on them. The observant amongst you will be thinking that it’s a counter wrap bug and you’d be correct. The annoying thing for me is that the code in question has unit tests which explicitly test for correct operation when the sequence number wraps; the tests pass but the bug is still there. https://serverframework.com/asynchronousevents/2012/09/acceptex-bug-in-windows-8-and-all-server-2012-variants.html Tue, 04 Sep 2012 09:32:27 +0000 https://serverframework.com/asynchronousevents/2012/09/acceptex-bug-in-windows-8-and-all-server-2012-variants.html Be aware that there is a known bug in Windows 8 and all Server 2012 variants which causes AcceptEx() completions to be delayed in some situations. This was confirmed by a Microsoft representative on Microsoft Connect, see the error report ticket here. An example of how to demonstrate this bug, its likely affects and the current know causes can be found here in this Stack Overflow question. I’m a little disappointed with the official response to this bug report. https://serverframework.com/asynchronousevents/2012/08/winsock-registered-io-io-completion-port-performance.html Wed, 29 Aug 2012 18:20:00 +0000 https://serverframework.com/asynchronousevents/2012/08/winsock-registered-io-io-completion-port-performance.html Continuing my analysis of the performance of the new Winsock Registered I/O API, RIO, compared to more traditional networking APIs we finally get to the point where we compare I/O completion port designs. I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview, though lately most of my testing has been using Windows Server 2012 RC. https://serverframework.com/asynchronousevents/2012/08/winsock-registered-io---traditional-multi-threaded-iocp-udp-example-server.html Thu, 23 Aug 2012 12:00:00 +0000 https://serverframework.com/asynchronousevents/2012/08/winsock-registered-io---traditional-multi-threaded-iocp-udp-example-server.html This article presents the sixth in my series of example servers for comparing the performance of the Winsock Registered I/O Networking extensions, RIO, and traditional Windows networking APIs. This example server is a traditional multi-threaded, IOCP based, UDP design that we can use to compare to the multi-threaded RIO IOCP UDP example server. I’ve been looking at the Winsock Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview, though lately most of my testing has been using Windows Server 2012 RC. https://serverframework.com/asynchronousevents/2012/08/worrying-issue-with-windows-8-and-acceptex.html Wed, 22 Aug 2012 17:08:39 +0000 https://serverframework.com/asynchronousevents/2012/08/worrying-issue-with-windows-8-and-acceptex.html There’s an interesting question over on stack overflow about a perceived change in IOCP behaviour on Windows 8 (and Server 2012 RC). The question includes some code which demonstrates how an overlapped AcceptEx() call is blocked on by the thread that issued it being blocked inside a call to ReadFile() at the time that the AcceptEx() completes. The completion for the AcceptEx() is delayed until the ReadFile() completes even though a thread is waiting for completions on the IOCP associated with the socket. https://serverframework.com/asynchronousevents/2012/08/windows-8server-2012-registered-io-performance---take-2.html Tue, 21 Aug 2012 17:20:00 +0000 https://serverframework.com/asynchronousevents/2012/08/windows-8server-2012-registered-io-performance---take-2.html I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance. https://serverframework.com/asynchronousevents/2012/08/latest-release-of-the-server-framework-657.html Mon, 20 Aug 2012 17:30:00 +0000 https://serverframework.com/asynchronousevents/2012/08/latest-release-of-the-server-framework-657.html Version 6.5.7 of The Server Framework was released today. This release contains one important bug fix and support for Visual Studio 2012 RTM. The bug that was introduced in 6.5.6 has exposed a gap in our unit testing which has also been filled with this release. If you use either the Read Timeout filter or VS2012 RTM then you should install this update. This release includes the following, see the release notes, here, for full details of all changes. https://serverframework.com/asynchronousevents/2012/08/latest-release-of-the-server-framework-656.html Mon, 13 Aug 2012 11:53:30 +0000 https://serverframework.com/asynchronousevents/2012/08/latest-release-of-the-server-framework-656.html Version 6.5.6 of The Server Framework was released today. This release contains some bug fixes, a selection of minor improvements and improved support for the Visual Studio 2012 (Note that there will be a further release shortly after Visual Studio 2012’s RTM if needed to address any changes between the Release Candidate and the RTM versions). If you use either the Read Timeout filter or the Flow Control filter then you should install this update. https://serverframework.com/asynchronousevents/2012/07/windows-8-registered-io-performance---finally-using-a-full-10-gigabit-link.html Mon, 30 Jul 2012 12:00:00 +0000 https://serverframework.com/asynchronousevents/2012/07/windows-8-registered-io-performance---finally-using-a-full-10-gigabit-link.html As I mentioned back in March I’m now doing some RIO performance testing with a 10 Gigabit Ethernet link as I couldn’t push my test server hard enough with multiple 1 Gigabit links. This involves 2 Intel 10 Gigabit AT2 cards connected directly to each other. One of the cards is in our test server and the other has been tried in various other pieces of test hardware in an attempt to ramp up the bandwidth usage for the RIO tests. https://serverframework.com/asynchronousevents/2012/07/bug-in-the-655-changes-for-the-read-timeout-connection-filter.html Mon, 02 Jul 2012 10:36:58 +0000 https://serverframework.com/asynchronousevents/2012/07/bug-in-the-655-changes-for-the-read-timeout-connection-filter.html The recent changes to 6.5.5 so that JetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilter holds a socket reference when the timer is set causes problems when the socket is shutdown. The filter doesn’t see the shutdown and fails to cancel the timer which means that a reference is held on the socket until the timeout expires. This delays socket closure and causes your timeout handling code to be run on a socket which has been cleanly shut down. https://serverframework.com/asynchronousevents/2012/06/differences-between-visual-studio-11-beta-and-visual-studio-2012-rc.html Fri, 15 Jun 2012 14:44:28 +0000 https://serverframework.com/asynchronousevents/2012/06/differences-between-visual-studio-11-beta-and-visual-studio-2012-rc.html As I mentioned in the release notes for version 6.5.5, The Server Framework now supports Visual Studio 11 Beta. It also supports Visual Studio 2012 RC but there are a couple of new warnings that you may need to suppress in Warnings.h. I haven’t been able to locate and details of the differences in the native code generation and C++ compiler side of Visual Studio 2012 RC from what was present in Visual Studio 11 Beta. https://serverframework.com/asynchronousevents/2012/05/latest-release-of-the-server-framework-655.html Tue, 22 May 2012 09:00:00 +0000 https://serverframework.com/asynchronousevents/2012/05/latest-release-of-the-server-framework-655.html Version 6.5.5 of The Server Framework was released today. This release contains some bug fixes, a selection of minor improvements and support for Visual Studio 11 Beta and Windows 8. If you use either the Read Timeout filter or the Flow Control filter then you should install this update. This release includes the following, see the release notes, here, for full details of all changes. Rewrote CFlowControlStreamSocketConnectionFilter to make it more reliable and correct. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-performance---10-gigabit-networking.html Mon, 26 Mar 2012 16:44:35 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-performance---10-gigabit-networking.html When I switched to looking at the performance of the more advanced RIO server designs that use IOCP it quickly became apparent that even multiple 1 Gigabit connections weren’t enough of a challenge to give me any meaningful figures; my traditional IOCP datagram servers were easily able to keep up and increasing the workload per datagram required such high workloads that the tests became meaningless. So, we’ve brought forward the purchase of the hardware that we intended to use for our private cloud scalability testing and we now have 2 Intel 10 Gigabit AT2 cards. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-performance.html Thu, 15 Mar 2012 15:15:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-performance.html I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---generating-load-for-the-performance-tests.html Wed, 14 Mar 2012 17:15:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---generating-load-for-the-performance-tests.html Now that we have five example servers, four RIO designs and a traditional polled UDP design, we can begin to look at how the RIO API performs compared to the traditional APIs. Of course these comparisons should be taken as preliminary since we’re working with a beta version of the operating system. However, though I wouldn’t put much weight in the exact numbers until we have a non-beta OS to test on, it’s useful to see how things are coming along and familiarise ourselves with the designs that might be required to take advantage of RIO once it ships. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---traditional-polled-udp-example-server.html Wed, 14 Mar 2012 14:00:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---traditional-polled-udp-example-server.html This article presents the fifth in my series of example servers for comparing the performance of the Windows 8 Registered I/O Networking extensions, RIO, and traditional Windows networking APIs. This example server is a traditional polled UDP design that we can use to compare to the RIO polled UDP example server. I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---multi-threaded-rio-iocp-udp-example-server.html Mon, 12 Mar 2012 18:10:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---multi-threaded-rio-iocp-udp-example-server.html This article presents the fourth in my series of example servers using the Windows 8 Registered I/O Networking extensions, RIO. This example server, like the last example, uses the I/O Completion Port notification method to handle RIO completions, but where the last example used only a single thread to service the IOCP this one uses multiple thread to scale the load . I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---single-threaded-rio-iocp-udp-example-server.html Mon, 12 Mar 2012 15:45:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---single-threaded-rio-iocp-udp-example-server.html This article presents the third in my series of example servers using the Windows 8 Registered I/O Networking extensions, RIO. This example server uses the I/O Completion Port notification method to handle RIO completions, but only uses a single thread to service the IOCP. I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---single-threaded-rio-event-driven-udp-example-server.html Fri, 09 Mar 2012 22:25:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---single-threaded-rio-event-driven-udp-example-server.html This article presents the second in my series of example servers using the Windows 8 Registered I/O Networking extensions, RIO. This example server uses the event driven notification method to handle RIO completions. I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---simple-rio-polled-udp-example-server.html Wed, 07 Mar 2012 11:28:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io---simple-rio-polled-udp-example-server.html I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance. https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-example-udp-servers.html Wed, 07 Mar 2012 11:27:00 +0000 https://serverframework.com/asynchronousevents/2012/03/windows-8-registered-io-example-udp-servers.html I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance. https://serverframework.com/asynchronousevents/2012/02/latest-release-of-the-server-framework-654.html Tue, 14 Feb 2012 08:28:41 +0000 https://serverframework.com/asynchronousevents/2012/02/latest-release-of-the-server-framework-654.html Version 6.5.4 of The Server Framework was released today. This release contains two important bug fixes and a selection of minor improvements. If you run your code on Vista/Windows Server 2003 or later and you don’t explicitly disable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS in your Config.h then you should install this update. This release includes the following, see the release notes, here, for full details of all changes. Bug fix. If FILE_SKIP_COMPLETION_PORT_ON_SUCCESS was enabled but JetByteTools::Socket::CanEnableSkipCompletionPortOnSuccess() returned false then the the code that handled issuing read and write calls would fail if ERROR_SUCCESS was returned because it would assume that FILE_SKIP_COMPLETION_PORT_ON_SUCCESS was enabled and that it should handle the completion directly but a completion would have been posted to the IOCP and so the completion would get handled twice. https://serverframework.com/asynchronousevents/2012/02/the-advantage-of-having-lots-of-clients-and-clients-with-lots-of-clients.html Wed, 08 Feb 2012 12:11:02 +0000 https://serverframework.com/asynchronousevents/2012/02/the-advantage-of-having-lots-of-clients-and-clients-with-lots-of-clients.html Our Secretive Online Game Company client uses The Server Framework for their custom application server for the games industry. They have thousands of users who run their server on a very diverse set of hardware. This is great for us as it really helps to shake down The Server Framework. There’s nothing like running your multi-threaded code on lots of different hardware to help find all of the hidden race conditions and whatever. https://serverframework.com/asynchronousevents/2012/02/wasp-download-of-xp-versions-now-fixed.html Thu, 02 Feb 2012 14:58:40 +0000 https://serverframework.com/asynchronousevents/2012/02/wasp-download-of-xp-versions-now-fixed.html I’ve just noticed a problem with downloading the XP versions of WASP. This is now fixed. The XP versions can now be downloaded correctly again from here. Sorry for any inconvenience caused. https://serverframework.com/asynchronousevents/2011/12/latest-release-of-the-server-framework-653.html Wed, 14 Dec 2011 08:47:43 +0000 https://serverframework.com/asynchronousevents/2011/12/latest-release-of-the-server-framework-653.html Version 6.5.3 of The Server Framework was released today. This release updates the WebSockets Option pack to the final version of the protocol as detailed in RFC 6455 which was released yesterday. There is also a bug fix to WebSocket status reason processing. If you have 6.5 or 6.5.1 or 6.5.2 and you are NOT using WebSockets then you probably don’t need this release. This release includes the following, see the release notes, here, for full details of all changes. https://serverframework.com/asynchronousevents/2011/11/new-client-profile-smart-moves-software-systems-ltd---online-gaming.html Wed, 23 Nov 2011 08:38:32 +0000 https://serverframework.com/asynchronousevents/2011/11/new-client-profile-smart-moves-software-systems-ltd---online-gaming.html We have a new client profile available here for a new client who selected The Server Framework to help it expand its online gaming platform to incorporate a WebSockets interface. https://serverframework.com/asynchronousevents/2011/11/a-new-release-of-wasp-now-with-ssltls-support.html Tue, 22 Nov 2011 10:10:47 +0000 https://serverframework.com/asynchronousevents/2011/11/a-new-release-of-wasp-now-with-ssltls-support.html We’ve just released a new version of WASP, our pluggable application server platform. This release is built with release 6.5.2 of The Server Framework and includes support for secure TCP connections using SSL/TLS via our SChannel Option pack. Setting up a secure TCP endpoint with WASP is easy, simply add the Secure configuration option to the <EndPoint> node like this: <?xml version="1.0" encoding="Windows-1252"?> <Configuration> <WASP> <TCP> <Endpoints> <EndPoint Name="Echo Server" Port="5050" HandlerDLL="[CONFIG]\EchoServer. https://serverframework.com/asynchronousevents/2011/11/latest-release-of-the-server-framework-652.html Mon, 21 Nov 2011 08:25:00 +0000 https://serverframework.com/asynchronousevents/2011/11/latest-release-of-the-server-framework-652.html Version 6.5.2 of The Server Framework was released today. This release adds some new functionality to the WebSockets Option pack and fixes some bugs in code that is only currently used by the WebSockets Option pack. If you have 6.5 or 6.5.1 and you are not using WebSockets then you probably don’t need this release. This release includes the following, see the release notes, here, for full details of all changes. https://serverframework.com/asynchronousevents/2011/11/dropping-support-for-visual-studio-net-2002-and-2003.html Wed, 09 Nov 2011 11:25:24 +0000 https://serverframework.com/asynchronousevents/2011/11/dropping-support-for-visual-studio-net-2002-and-2003.html We are dropping support for Visual Studio .Net 2002 from release 6.6 of The Server Framework which is due early next year. We don’t expect that this will cause anyone any problems as this compiler became unsupported by Microsoft in 2009, and most native C++ people seemed to skip this release entirely. We are also considering dropping support for Visual Studio .Net 2003. This compiler is still supported by Microsoft until 2013 but we expect that most people interested in native C++ will have switched to Visual Studio 2005 or 2008 at the earliest opportunity. https://serverframework.com/asynchronousevents/2011/11/new-client-profile-takion-technologies---equity-trading-platform.html Fri, 04 Nov 2011 09:11:03 +0000 https://serverframework.com/asynchronousevents/2011/11/new-client-profile-takion-technologies---equity-trading-platform.html We have a new client profile available here for a client that we’ve had since 2006 and who use The Server Framework in their equity trading systems. https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-buffer-strategies.html Mon, 31 Oct 2011 07:30:00 +0000 https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-buffer-strategies.html One of the things that allows the Windows 8 Registered I/O Networking Extensions, RIO, to perform better than normal Winsock calls is the fact that the memory used for I/O operations is pre-registered with the API. This allows RIO to do all the necessary checks that the buffer memory is valid, etc. once, and then lock the buffer in memory until you de-register it. Compare this to normal Winsock networking where the memory needs to be checked and locked on each operation and already we have a whole load of work that simply isn’t required for each I/O operation. https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-and-io-completion-ports.html Tue, 25 Oct 2011 18:56:24 +0000 https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-and-io-completion-ports.html In my last blog post I introduced the Windows 8 Registered I/O Networking Extensions, RIO. As I explained there are three ways to retrieve completions from RIO, polled, event driven and via an I/O Completion Port (IOCP). This makes RIO pretty flexible and allows it to be used in many different designs of servers. The polled scenario is likely aimed at very high performance UDP or High Frequency Trading style situations where you may be happy to burn CPU so as to process inbound datagrams as fast as possible. https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-networking-extensions.html Mon, 24 Oct 2011 16:50:35 +0000 https://serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-networking-extensions.html Most of the buzz being generated around the Windows 8 Developer Previews at the moment seems to be centred on the new Metro user interface and the Windows Runtime. Whilst both Metro and WinRT are key components of the next Windows release I find the Registered I/O Networking Extensions to be far more interesting, but then I guess I would… What are the Registered I/O Networking Extensions? The Registered I/O Networking Extensions, RIO, is a new API that has been added to Winsock to support high-speed networking for increased networking performance with lower latency and jitter. https://serverframework.com/asynchronousevents/2011/10/out-of-band-data-and-overlapped-io.html Thu, 20 Oct 2011 10:30:00 +0000 https://serverframework.com/asynchronousevents/2011/10/out-of-band-data-and-overlapped-io.html Some stream protocols have the concept of ‘out of band’ (OOB) data. This is a separate logical communication channel between the peers which enables data that is unrelated to the current data in the stream to be sent alongside the normal data stream. This is often a way for some data to jump ahead of the normal stream and arrive faster than if it were delivered via the the normal data stream. https://serverframework.com/asynchronousevents/2011/10/latest-release-of-the-server-framework-651.html Tue, 11 Oct 2011 08:23:31 +0000 https://serverframework.com/asynchronousevents/2011/10/latest-release-of-the-server-framework-651.html Version 6.5.1 of The Server Framework was released today. This is primarily a bug fix release, although we also add several new example clients and servers. This release includes the following, see the release notes, here, for full details of all changes. Bug fixes to The Core Framework which affect the use of the newly added “Read Again” functionality. Fixes to the Hixie76 WebSockets protocol handler to improve interoperability. Added outbound connection establishment support to the Hixie76 protocol handler. https://serverframework.com/asynchronousevents/2011/10/a-little-note-to-all-you-chinese-hackers.html Sun, 09 Oct 2011 12:53:22 +0000 https://serverframework.com/asynchronousevents/2011/10/a-little-note-to-all-you-chinese-hackers.html My server logs are showing that there are some people currently trying to hack this site. They appear to be mainly Chinese. I assume you think you might be able to download the source code to The Server Framework for free if you manage to hack my websites; after all the same IP addresses have been exploring my sites a lot and looking at lots of the documentation pages on here… https://serverframework.com/asynchronousevents/2011/10/new-client-profile-mix-telematics.html Mon, 03 Oct 2011 12:42:08 +0000 https://serverframework.com/asynchronousevents/2011/10/new-client-profile-mix-telematics.html We have a new client profile available here for a client that we’ve had since 2009 and who use The Server Framework in their vehicle tracking software. https://serverframework.com/asynchronousevents/2011/09/latest-release-of-the-server-framework-65.html Thu, 15 Sep 2011 14:40:08 +0000 https://serverframework.com/asynchronousevents/2011/09/latest-release-of-the-server-framework-65.html Version 6.5 of The Server Framework was released today. This release includes the following, see the release notes, here, for full details of all changes. WebSockets support via The WebSockets Option Pack. WebSocket protocol compliance test results can be found here. Improvements to the flow control connection filter so that managing high volume connections is easier than ever. Added code to automatically detect if it’s safe to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS on a given machine. https://serverframework.com/asynchronousevents/2011/06/the-websocket-protocol-draft-hybi-09.html Tue, 21 Jun 2011 09:15:53 +0000 https://serverframework.com/asynchronousevents/2011/06/the-websocket-protocol-draft-hybi-09.html Due to client demand we’re working on the WebSocket protocol again. Things have moved on since the work we did in December and this time the resulting option pack really will make it into the next release rather than simply being something that we tweak for each client that asks for it. Back in December one of our gaming clients wanted WebSocket functionality in their game server so we did some work on the two versions of the spec that they wanted, the Hixie 76 draft and the HyBi 03 draft. https://serverframework.com/asynchronousevents/2011/06/tcp-flow-control-and-asynchronous-writes.html Thu, 09 Jun 2011 22:10:00 +0000 https://serverframework.com/asynchronousevents/2011/06/tcp-flow-control-and-asynchronous-writes.html 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. https://serverframework.com/asynchronousevents/2011/05/new-client-profile-inconcert.html Thu, 26 May 2011 06:40:50 +0000 https://serverframework.com/asynchronousevents/2011/05/new-client-profile-inconcert.html 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. https://serverframework.com/asynchronousevents/2011/04/new-client-profile-cadcorp.html Thu, 21 Apr 2011 09:31:14 +0000 https://serverframework.com/asynchronousevents/2011/04/new-client-profile-cadcorp.html 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. https://serverframework.com/asynchronousevents/2011/04/latest-release-of-the-server-framework-64.html Wed, 20 Apr 2011 12:00:00 +0000 https://serverframework.com/asynchronousevents/2011/04/latest-release-of-the-server-framework-64.html 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. https://serverframework.com/asynchronousevents/2011/04/avoiding-non-paged-pool-exhaustion-when-using-asynchronous-file-writers.html Wed, 06 Apr 2011 10:57:42 +0000 https://serverframework.com/asynchronousevents/2011/04/avoiding-non-paged-pool-exhaustion-when-using-asynchronous-file-writers.html 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. https://serverframework.com/asynchronousevents/2011/03/bug-in-cstringconverterwtoa.html Mon, 07 Mar 2011 10:23:20 +0000 https://serverframework.com/asynchronousevents/2011/03/bug-in-cstringconverterwtoa.html 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. https://serverframework.com/asynchronousevents/2011/03/automatic-crash-dump-creation.html Tue, 01 Mar 2011 10:00:00 +0000 https://serverframework.com/asynchronousevents/2011/03/automatic-crash-dump-creation.html 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. https://serverframework.com/asynchronousevents/2011/02/potential-for-bugs-in-the-design-of-the-pre-64-ciopool-constructor.html Mon, 28 Feb 2011 10:42:46 +0000 https://serverframework.com/asynchronousevents/2011/02/potential-for-bugs-in-the-design-of-the-pre-64-ciopool-constructor.html 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. https://serverframework.com/asynchronousevents/2011/02/performance-allocators-pooling-and-64.html Mon, 14 Feb 2011 11:11:51 +0000 https://serverframework.com/asynchronousevents/2011/02/performance-allocators-pooling-and-64.html 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. https://serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html Fri, 21 Jan 2011 11:39:49 +0000 https://serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html 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. https://serverframework.com/asynchronousevents/2011/01/new-client-profile-rte-network.html Tue, 18 Jan 2011 11:30:24 +0000 https://serverframework.com/asynchronousevents/2011/01/new-client-profile-rte-network.html We have a new client profile available here for a client that we’ve had since 2006 in the IP Fax business. https://serverframework.com/asynchronousevents/2011/01/latest-release-of-the-server-framework-633.html Fri, 07 Jan 2011 09:00:00 +0000 https://serverframework.com/asynchronousevents/2011/01/latest-release-of-the-server-framework-633.html 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. https://serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html Fri, 10 Dec 2010 10:39:15 +0000 https://serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html It seems that C10K is old hat these days and that people are aiming a little higher. I’ve seen several questions on StackOverflow.com (and had an equal number of direct emails) asking about how people can achieve one million active TCP connections on a single Windows Server box. Or, in a more round about way, what is the theoretical maximum number of active TCP connections that a Windows Server box can handle. https://serverframework.com/asynchronousevents/2010/12/the-websocket-protocol.html Thu, 09 Dec 2010 14:47:18 +0000 https://serverframework.com/asynchronousevents/2010/12/the-websocket-protocol.html I’ve spent the last few days implementing the WebSocket protocol (well, two versions of the draft standard actually) and integrating it into an existing server for one of our clients. This has proved to be an interesting exercise. The protocol itself is pretty simple but, as ever, the devil is in the detail. I now have server side code that deals with both the Hixie 76 draft and the HyBi 03 draft of the protocol. https://serverframework.com/asynchronousevents/2010/11/my-approach-to-bugs.html Wed, 24 Nov 2010 10:53:12 +0000 https://serverframework.com/asynchronousevents/2010/11/my-approach-to-bugs.html As the recent spate of bug fix and patch releases shows I’m not scared of talking about the bugs that I find in the code of The Server Framework and pushing fixes out quickly. It’s my belief that the most important thing to get out of a bug report is an improved process which will help prevent similar bugs from occurring in future and the only way to achieve that is to be open about the bugs you find and equally open about how you then address them and try and prevent similar issues. https://serverframework.com/asynchronousevents/2010/11/bug-fix-for-63x-cservicemanagercpp.html Wed, 24 Nov 2010 08:46:44 +0000 https://serverframework.com/asynchronousevents/2010/11/bug-fix-for-63x-cservicemanagercpp.html There’s a stupidly obvious, should have been caught at numerous points during pre-release testing, bug in CServiceManager.cpp. The code below that starts at line 158: case RunActionRunAsService : { if (!StartServices()) { const DWORD lastError = ::GetLastError(); const _tstring message = messageHeader + _T("Failed to start service.\n\n ") + GetLastErrorMessage(lastError); MessageBox(message); result = 2; } } default : throw CException(_T("CServiceInstanceManager::Run()"), _T("Unexpected run action:") + ToString(runAction)); } Should actually look like this, note the inclusion of the missing break; and the exception source correction: https://serverframework.com/asynchronousevents/2010/11/new-client-profile-desktop-sharing-company.html Wed, 24 Nov 2010 08:16:09 +0000 https://serverframework.com/asynchronousevents/2010/11/new-client-profile-desktop-sharing-company.html We have a new client profile available here for a client that we’ve had since 2006 in the desktop sharing market. Their system, built on The Server Framework, runs on more than 120 servers worldwide and handles more than 200,000 desktop sharing sessions each day! https://serverframework.com/asynchronousevents/2010/11/latest-release-of-the-server-framework-632.html Tue, 23 Nov 2010 09:23:02 +0000 https://serverframework.com/asynchronousevents/2010/11/latest-release-of-the-server-framework-632.html Version 6.3.2 of The Server Framework was released today. This release is purely a bug fix release and includes the following fixes. Fixes to JetByteTools::OpenSSL::CAsyncConnection to remove the possibility of deadlock due to a lock inversion. Fixes to JetByteTools::SSPI::SChannel::CAsyncConnection to remove the possibility of deadlock due to a lock inversion. Fixes to JetByteTools::SSPI::Negotiate::CAsyncConnection to remove the possibility of deadlock due to a lock inversion. Fixes to JetByteTools::CLRHosting::CCLREventSink and JetByteTools::CLRHosting::CCLRHost 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. https://serverframework.com/asynchronousevents/2010/11/useful-link-to-tcp-connection-knowledge-base-articles.html Sat, 13 Nov 2010 09:13:56 +0000 https://serverframework.com/asynchronousevents/2010/11/useful-link-to-tcp-connection-knowledge-base-articles.html I found this article recently whilst discussing a question about socket reuse using DisconnectEx() over on StackOverflow. It’s a useful collection of the various configuration settings that can affect the number of concurrent TCP connections that a server can support, complete with links to the KB articles that discuss the settings in more detail. It’s a bit out of date, but it’s probably a good starting point if you want to understand the limits involved. https://serverframework.com/asynchronousevents/2010/11/potential-to-deadlock-in-openssl-schannel-and-sspi-negotiate-connectors.html Fri, 12 Nov 2010 08:38:52 +0000 https://serverframework.com/asynchronousevents/2010/11/potential-to-deadlock-in-openssl-schannel-and-sspi-negotiate-connectors.html I’ve been improving my pre-release testing system and now run a lock inversion detector as part of my build machine’s build and test cycle for the socket server examples. This lock inversion detector can detect the potential to deadlock without the code ever needing to actually deadlock, so it’s a pretty powerful tool. It has detected a lock inversion in the async connectors used by the OpenSSL, SChannel and SSPI Negotiate libraries. https://serverframework.com/asynchronousevents/2010/11/latest-release-of-the-server-framework-631.html Mon, 08 Nov 2010 12:59:24 +0000 https://serverframework.com/asynchronousevents/2010/11/latest-release-of-the-server-framework-631.html Version 6.3.1 of The Server Framework was released today. This release is purely a bug fix release and includes the following fixes. Fixes to JetByteTools::OpenSSL::CStreamSocketConnectionFilter to prevent buffer reference leaks which result in memory leaks during secure connection processing; see here for more details. Fixes to JetByteTools::OpenSSL::CAsyncConnector to prevent socket reference leaks in situations where connections are reset or where unexpected SSL errors occur. These socket reference leaks can cause delays and hangs when shutting down a server or connection manager. https://serverframework.com/asynchronousevents/2010/11/bug-in-openssl-stream-socket-filter-which-cases-memory-leaks.html Wed, 03 Nov 2010 17:44:59 +0000 https://serverframework.com/asynchronousevents/2010/11/bug-in-openssl-stream-socket-filter-which-cases-memory-leaks.html There’s a bug in the OpenSSL stream socket filter which results in I/O buffers being leaked on both inbound and outbound data flow. This causes the memory used by the client or server to grow throughout the life of the process. The bug has been present since release 6.2 when the structure of the filtering code was redesigned. Note that due to the fact that the filtering code was all redone at that time I expect that the same bug is likely to be present in the SChannel, SSPI and compression filters. https://serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html Wed, 27 Oct 2010 09:05:32 +0000 https://serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html As I mentioned last time, supporting a large number of concurrent connections on a modern Windows operating system is reasonably straight forward if you get your initial design right; use an I/O Completion Port based design, minimise context switches, data copies and memory allocation and avoid lock contention… The Server Framework gives you this as a starting point and you can often use one of the many, complete and fully functionaly, real world example servers to provide you with a whole server shell, complete with easy performance monitoring and SSL security, where you simply have to fill in your business logic. https://serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html Mon, 25 Oct 2010 10:34:50 +0000 https://serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html Using a modern Windows operating system it’s pretty easy to build a server system that can support many thousands of connections if you design the system to use the correct Windows APIs. The key to server scalability is to always keep in mind the Four Horsemen of Poor Performance as described by Jeff Darcy in his document on High Performance Server Architecture. These are: Data copies Context switches Memory allocation Lock contention I’ll look at context switches first, as IMHO this is where outdated designs often rear their head first. https://serverframework.com/asynchronousevents/2010/10/wasp-command-line-options.html Wed, 20 Oct 2010 10:35:35 +0000 https://serverframework.com/asynchronousevents/2010/10/wasp-command-line-options.html As you’ve seen from some of the earlier tutorials, WASP has quite a few command line parameters that can change how it runs. You can run WASP as a normal executable or install it as a Windows Service. The complete set of command line options are displayed if you run WASP with /help or with an option that it doesn’t understand but I thought I’d list them all here for completeness and so that I can explain in a little more detail what each one does. https://serverframework.com/asynchronousevents/2010/10/more-complex-message-framing.html Tue, 19 Oct 2010 08:50:54 +0000 https://serverframework.com/asynchronousevents/2010/10/more-complex-message-framing.html So far the tutorials have focused on a simple length prefixed message type. This is probably the easiest message in the world to process, the message framing is very simple and there’s hardly anything to do in your message framing DLL. Unfortunately not all protocols are this simple to parse. Another common real-world protocol is a line based protocol that is delimited by a terminating character, or characters. One such protocol is the POP3 protocol which works in terms of commands which are delimited by the CR LF sequence. https://serverframework.com/asynchronousevents/2010/10/wasps-config-file.html Mon, 18 Oct 2010 10:57:49 +0000 https://serverframework.com/asynchronousevents/2010/10/wasps-config-file.html As you have discovered if you’ve been following the tutorials, WASP is configured using an XML file. This file can either live in the same directory as the WASP executable or, for when you’re running WASP as a Windows Service, it can live in a place that is configured in the registry. The file is pretty simple and we’ve covered most of the options in the various tutorials but there are some configuration options that we haven’t touched on yet and it seems sensible to have one place to look for details of all of the options that you can configure in the config file. https://serverframework.com/asynchronousevents/2010/10/wasp-plugin-entry-points.html Fri, 15 Oct 2010 08:42:28 +0000 https://serverframework.com/asynchronousevents/2010/10/wasp-plugin-entry-points.html By now you’ve probably taken a look inside of the WASP SDK header, WASPDLLEntryPoints.h and seen all of the various plugin entry points that you can export from your plugin. This tutorial will explain what each of them is for and how you use them and will present a simple plugin which uses all of the entry points and logs its actions to WASP’s debug log. As you’ve seen from the previous tutorials, a WASP plugin can be either a message framing DLL or a message handling DLL or both depending on the entry points that it exports. https://serverframework.com/asynchronousevents/2010/10/wasp-server-instances.html Thu, 14 Oct 2010 14:34:21 +0000 https://serverframework.com/asynchronousevents/2010/10/wasp-server-instances.html A single WASP plugin can be loaded by multiple end points to provide the same server on multiple ports. A plugin could, for example, be configured on one end point to provide services to the internal network and on another end point to provide services to the internet. Alternatively, in later WASP releases, a single plugin may be used to provide services over an insecure link on one end point and via an SSL protected link on another. https://serverframework.com/asynchronousevents/2010/10/testing-complex-server-code.html Wed, 13 Oct 2010 12:40:23 +0000 https://serverframework.com/asynchronousevents/2010/10/testing-complex-server-code.html As I mentioned in the release notes for v6.3 here, I’ve added some code to prevent potential recursion issues if certain performance improvements are enabled. In Windows Vista and later it’s possible to set the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag on a socket using SetFileCompletionNotificationModes(). When this flag is set an overlapped operation can complete “in-line” and the completion operation can be handled on the thread that issued the operation rather than on one of the threads that is servicing the IO completion port that is associated with the socket. https://serverframework.com/asynchronousevents/2010/10/calling-wasp-functions-from-your-plugin-dll.html Wed, 13 Oct 2010 08:41:43 +0000 https://serverframework.com/asynchronousevents/2010/10/calling-wasp-functions-from-your-plugin-dll.html So far our simple example WASP plugins have all used OnReadCompletedEx() which gives you both an input and an output buffer and assumes that you generate a single response to each inbound message. It also assumes that you wont write more data than will fit in a single I/O buffer. Whilst this is suitable for some server designs it’s quite restrictive. Most plugins will probably use a combination of OnReadCompleted() and the WASP callback function writeToConnection(). https://serverframework.com/asynchronousevents/2010/10/some-thoughts-on-that-two-thread-pool-server-design.html Tue, 12 Oct 2010 11:27:25 +0000 https://serverframework.com/asynchronousevents/2010/10/some-thoughts-on-that-two-thread-pool-server-design.html I’m currently re-reading “High Performance Server Architecture” by Jeff Darcy and he has a lot of sensible stuff to say about avoiding context switches and how my multiple thread pool design, whilst conceptually good is practically not so good. In general I agree with him but often the design provides good enough performance and it’s easy to compose from the various classes in The Server Framework. Explicitly managing the threads that could run, using a semaphore that only allows a number of threads that is equal to or less than your number of cores to do work at once is a nice idea but one that adds complexity to the workflow as you need to explicitly acquire and release the semaphore as you perform your blocking operations. https://serverframework.com/asynchronousevents/2010/10/wasps-thread-pools.html Tue, 12 Oct 2010 09:04:41 +0000 https://serverframework.com/asynchronousevents/2010/10/wasps-thread-pools.html Way back in 2002 when I was developing ISO8583 servers for PayPoint I put together a two thread pool server design that has worked so well that many of the servers that I develop today still use variations on the original design. The main idea behind the design was that the threads that do the network I/O should never block and the threads that do the user work can block if they like. https://serverframework.com/asynchronousevents/2010/10/using-openssl-with-asynchronous-sockets.html Tue, 12 Oct 2010 08:25:23 +0000 https://serverframework.com/asynchronousevents/2010/10/using-openssl-with-asynchronous-sockets.html OpenSSL is an open source implementation of the SSL and TLS protocols. Unfortunately it doesn’t play well with windows style asynchronous sockets. This article - previously published in Windows Developer Magazine and now available on the Dr. Dobbs site - provides a simple connector that enables you to use OpenSSL asynchronously. Integrating OpenSSL with asynchronous sockets is similar to integrating it with overlapped I/O and IO completion port based designs and so the ideas behind the code discussed in the article were then used as part of the original design for The Server Framework’s OpenSSL option pack. https://serverframework.com/asynchronousevents/2010/10/stress-testing-wasp-using-the-echoservertest-program.html Mon, 11 Oct 2010 12:15:43 +0000 https://serverframework.com/asynchronousevents/2010/10/stress-testing-wasp-using-the-echoservertest-program.html The simple echo server plugin that we developed in the earlier tutorial was easy to test using telnet as it simply echoed all data back to the client. The plugin which used simple message framing was less easy to test using telnet as you first needed to enter the correct bytes to specify a message length as an int in network byte order. Neither plugin was easy to stress test using telnet as you’d need lots of monkeys and lots of machines to simulate lots of users. https://serverframework.com/asynchronousevents/2010/10/message-framing-a-length-prefixed-packet-echo-server.html Fri, 08 Oct 2010 08:45:42 +0000 https://serverframework.com/asynchronousevents/2010/10/message-framing-a-length-prefixed-packet-echo-server.html Most TCP servers deal with distinct messages whereas TCP itself deals in terms of a stream bytes. By default a single read from a TCP stream can return any number of bytes from 1 to the size of the buffer that you supplied. TCP knows nothing about your message structure. This is where message framing comes in. If the protocol that you are supporting has a concept of what constitutes a “message” then your protocol requires message framing. https://serverframework.com/asynchronousevents/2010/10/the-simplest-plugin-examining-echoserverdll.html Thu, 07 Oct 2010 08:40:10 +0000 https://serverframework.com/asynchronousevents/2010/10/the-simplest-plugin-examining-echoserverdll.html WASP plugins are, at present, native DLLs that expose a set of known entry points. The minimal plugin exposes a single entry point, either OnReadCompleted() or OnReadCompletedEx(). The entry points and other details that you need to build a plugin for WASP are detailed in the WASPDLLEntryPoint.h header file that ships in the SDK directory with WASP. The simplest plugin that you could possibly write is one that uses OnReadCompletedEx() and which simply echoes all inbound data back to the client again. https://serverframework.com/asynchronousevents/2010/10/automating-wasp-installation.html Wed, 06 Oct 2010 08:34:15 +0000 https://serverframework.com/asynchronousevents/2010/10/automating-wasp-installation.html As you will have noticed if you’ve been following along with the tutorials, WASP displays a message box when you successfully install an instance of the service or install the performance counters. This is less than ideal for automated installations and so you can add the /noMessages command line argument to these operations to give you an installation which does not require a user to acknowledge the message box. If you need to automate the installation of one or more instances of WASP and/or the performance counters you can using /noMessages. https://serverframework.com/asynchronousevents/2010/10/enabling-and-viewing-wasps-performance-counters.html Tue, 05 Oct 2010 08:56:59 +0000 https://serverframework.com/asynchronousevents/2010/10/enabling-and-viewing-wasps-performance-counters.html WASP can expose internal metrics using performance counters. These can then be viewed using the standard Windows performance monitoring tool, perfmon. WASP’s performance counters allow you to see how your server is performing and the counters can be automatically monitored and integrated with the counters from other Windows services, such as SQL server, the base operating system or the CLR, to provide a fully integrated production monitoring system. Installation of performance counters is done once per machine rather than once per WASP instance and performance counters can be used and viewed both when WASP is running as a Windows Service and from the command line. https://serverframework.com/asynchronousevents/2010/10/changes-to-the-clr-hosting-tools-library-in-63.html Mon, 04 Oct 2010 09:39:19 +0000 https://serverframework.com/asynchronousevents/2010/10/changes-to-the-clr-hosting-tools-library-in-63.html One of my clients has recently required .Net 4.0 hosting support and so most of the changes in the CLR Hosting Tools library in 6.3 have been driven by them. The main new feature is the optional use of the .Net 4.0 hosting API. This allows us to host .Net 4.0 as well as earlier CLRs and also allows us to host multiple different CLRs in a single process. The new hosting API is supported via the CCLRHostFactory object which uses the CCLRMetaHost and CCLRRuntimes objects to present a consistent interface to both the . https://serverframework.com/asynchronousevents/2010/10/running-wasp-as-a-windows-service.html Mon, 04 Oct 2010 08:24:50 +0000 https://serverframework.com/asynchronousevents/2010/10/running-wasp-as-a-windows-service.html In the last tutorial I showed you how to run WASP as a normal command line executable. This can be useful for testing and development and also for debugging but when you want to run WASP on a production machine you probably want to run it as a Windows Service. Running as a Windows Service has the advantage that you don’t need a user logged in to the machine to run WASP, you can also control it remotely using the Windows Service Control Manager application. https://serverframework.com/asynchronousevents/2010/10/checking-for-new-versions-of-wasp.html Fri, 01 Oct 2010 10:00:25 +0000 https://serverframework.com/asynchronousevents/2010/10/checking-for-new-versions-of-wasp.html I’ve got quite a few plans for expanding the functionality that WASP provides. Ideally it should showcase all of the major options available with The Server Framework; so pretty soon I’ll be adding UDP support, hosting plugins written in managed code, providing secure TCP connections using SSL, etc. Plus I’m sure that some bugs will be shaken out as users push the system in ways that I haven’t anticipated and so haven’t tested. https://serverframework.com/asynchronousevents/2010/10/changes-to-the-service-tools-library-in-63.html Fri, 01 Oct 2010 09:35:34 +0000 https://serverframework.com/asynchronousevents/2010/10/changes-to-the-service-tools-library-in-63.html The development of WASP has been acting as a bit of an internal driver for new feature development in the 6.3 release of The Server Framework. Sitting down to develop a service that was easy to use for a mass market exposed some small holes in the 6.2 release; nothing too serious but pretty soon after putting together the first service shell of the WASP application I had a list of nice to have additions for the Service Tools Library. https://serverframework.com/asynchronousevents/2010/10/getting-started-with-wasp.html Fri, 01 Oct 2010 09:25:46 +0000 https://serverframework.com/asynchronousevents/2010/10/getting-started-with-wasp.html The easiest way to get started with WASP is to download the latest version from the download page, here, unzip the contents somewhere and then run the WASP executable, simply double click the executable in Explorer or navigate to the directory that you have installed WASP into and type “wasp”. The result should be that a log file is created in a subdirectory of the directory where the exe is located called log. https://serverframework.com/asynchronousevents/2010/10/latest-release-of-the-server-framework-63.html Fri, 01 Oct 2010 08:50:39 +0000 https://serverframework.com/asynchronousevents/2010/10/latest-release-of-the-server-framework-63.html Version 6.3 of The Server Framework was released today. This release includes the following, see the release notes, here, for full details of all changes. Performance improvements on Vista and later operating systems. See here for more details. Performance improvements for some designs of datagram server by reusing sockets and buffers more aggressively and thus avoiding the allocators in some situations A redesigned the timer queue to improve timer dispatch performance. https://serverframework.com/asynchronousevents/2010/10/an-introduction-to-wasp.html Fri, 01 Oct 2010 08:39:05 +0000 https://serverframework.com/asynchronousevents/2010/10/an-introduction-to-wasp.html WASP is, at heart, simply another example server for The Server Framework, but it’s also something a little new. Up until now potential clients have been able to look at the example servers source code and ask for pre-built executables for testing. The thing is, the examples are just that, examples and whilst release 6.2 of The Server Framework ships with over 70 examples (see here) they still only show small pieces of functionality in isolation. https://serverframework.com/asynchronousevents/2010/10/welcome-to-serverframeworkcom.html Fri, 01 Oct 2010 08:30:28 +0000 https://serverframework.com/asynchronousevents/2010/10/welcome-to-serverframeworkcom.html ServerFramework.com is a new website that we’ve put together to make it easier for users and potential users of the licensed version of our high performance, I/O completion port based client/server socket framework to find all of the information that they need. As many of you know, I’ve been working on the code that forms The Server Framework since 2001 and it’s been used by lots of our clients to produce highly scalable, high performance, reliable servers that often run continuously 24/7, all year round.