November 2011 Archives
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.dll" Secure="true"> </EndPoint> </Endpoints> </TCP> </WASP> </Configuration>
This tells WASP to secure the endpoint using a default certificate called "Wasp" that is located in the "MY" certificate store. You can add a self signed test certificate using the standard Microsoft "make cert" utility, makecert.exe and a simple script which creates and installs the correct type of certificate can be downloaded from here.
if you do not want to use a certificate called "Wasp" in the "MY" certificate store then you can configure the certificate used by adding the StoreName, CertificateName and UseMachineStore config values.
<?xml version="1.0" encoding="Windows-1252"?> <Configuration> <WASP> <TCP> <Endpoints> <EndPoint Name="Echo Server" Port="5050" HandlerDLL="[CONFIG]\EchoServer.dll" Secure="true" StoreName="OurSpecialStore" CertificateName="OurCertificate" UseMachineStore="true"> </EndPoint> </Endpoints> </TCP> </WASP> </Configuration>
Testing your new secure endpoint can be done using either our OpenSSL server test or our SChannel server test. These are example clients that ship with The Server Framework and that allow you to create thousands of concurrent connections and control how they send data to a server. This is an easy way to build a test system for your server as all of the complexity of managing and controlling the connections is done for you and you simply have to adjust the messages that are generated and how the response validation is done. The default message that is built is an network byte order integer length prefixed message and so this program can be used to stress test WASP with either of the first two example plugins that were discussed in the tutorial.
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.
- Bug fixes to JetByteTools::IO::CBufferChain and JetByteTools::IO::CSortedBufferChain.
- Added JetByteTools::IO::CLockableBufferProcessor::PutBackAndLock().
- Adjusted how
JETBYTE_DUMP_STREAM_SOCKET_READ_TO_DEBUG_LOG, etc. work, you can now produce less debug data (faster) using
- Removed duplication in WebSocket header processing.
- Breaking Change JetByteTools::WebSocket::IProtocolHandler::OnConnectionClosed() has been added and should be called when the underlying socket connection is closed. The example servers have been updated so please compare these to your own servers to see the changes required.
- Added overloads of JetByteTools::WebSocket::IWebSocket::WriteText() and JetByteTools::WebSocket::IWebSocket::TryWriteText() which take
BYTE *of pre-formatted UTF8 data.
- JetByteTools::WebSocket::TWebSocketBase now holds a reference to the underlying stream socket until the connection closes, this is because we can't rely on their being a read pending to hold the stream socket open, even if the client thinks there is, as the websocket may have data buffered and so not issue a physical read.
- Adjusted JetByteTools::WebSocket::CAutoDetectProtocolHandler so that it doesn't have to always issue a read when set to accept a connection. This allows for connections which may also carry non-websocket traffic.
- Adjusted how the HyBi protocol handler responds to errors. We now issue the 'correct' websocket layer close notification with the correct close code (we pass the latest Autobahn tests (0.4.3) which include tests for appropriate close codes) and notify client code via two new callbacks on JetByteTools::WebSocket::HyBi::IWebSocketServer, JetByteTools::WebSocket::HyBi::IWebSocketServer::OnError() and JetByteTools::WebSocket::HyBi::IWebSocketServer::OnClosed().
- Bug fix to JetByteTools::WebSocket::HyBi::CProtocolHandler which deals with a race condition during inbound data processing.
- Bug fix to JetByteTools::WebSocket::HyBi::CProtocolHandler and JetByteTools::WebSocket::Hixie76::CProtocolHandler which deals with close handling, we now wait for the other side's close response correctly.
- Removed unnecessary size limitations in the
TCHAR *based socket write methods.
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.
Feedback is essential here. If you DO still need Visual Studio .Net 2003 support then we need to know, otherwise we may bring forward its retirement date...
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.