RWHttpSocketClient::connect() with a timeout may take longer to complete than the timeout specified. This occurs because, even though the underlying socket connect is limited to the timeout specified, the client must first determine the address for the host by calling the ::gethostbyname() function. This function call may take longer to execute than the timeout specified, causing RWHttpSocketClient::connect() to exceed its timeout.
In order to reduce the amount of time blocked in the connect call, you may invoke RWSockAddr::prepare() prior to passing it to the RWHttpClient::connect() method. This will force the RWSockAddr instance to resolve the hostname to an IP address before invoking connect(), so that it doesn't have to repeat this process once inside the call.
This should allow the timeout passed to connect to accurately restrict the amount of time the process will wait inside the call.
Non-blocking secure sockets are not supported in this release.
Clients using SSLv2 may no longer be able to connect to servers using TLSv1WithFallback. This is because the default cipher list used by OpenSSL 1.0.0 and later no longer include the necessary ciphers for this fallback to work.
While it is strongly encouraged to avoid using SSLv2, fallback support for SSLv2 can be enabled by enabling the necessary ciphers on a context. The following code snippet demonstrates.
RWSecureSocketContext context;
context.setCipherList("ALL:!NULL");
|
The DaytimeMulticast example can hang on machines with multiple network adapters
The DaytimeMulticast server and client example should be executed on a machine that has a single active network adapter.
The Secure Communication Module depends on the underlying Cryptographic library being installed, built, and working correctly before the Secure Communication Module is built. The following section details installation requirements on your platform.
Telling RCB Where Your C Cryptography Library is Located
When using RCB to build the Secure Sockets package, you are prompted to select which cryptography library you are using and to enter the directory where it is installed.
It is important to note that the directory you specify will have /lib and /include appended to it in the makefiles that RCB creates. Therefore the directory you enter should be the directory that has lib and include subdirectories.
Examples:
If the library files are installed in /usr/local/ssl/lib and the headers are located in /usr/local/ssl/include, then the common root directory that RCB expects is /usr/local/ssl.
Likewise on Windows, if the library files are installed in D:\ssl\lib and the header files are in D:\ssl\include, then the common root directory that RCB expects is D:\ssl.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.