/** \page faq FAQ ## Dependency Management ### Can WebSocket++ be used without Boost? Yes. WebSocket++ only uses Boost features as polyfills for C++11 language features and libraries. If you have a C++11 compiler and standard library you can use WebSocket++ without Boost. In most cases setting your build environment to use the C++11 (or later) language dialect is sufficient to enable this mode of use. With less common compilers (and sometimes very recently release compilers) there may be specific issues with certain libraries that aren't automatically detected by the library. For these situations there are additional defines available to fine tune which C++11 libraries and features are used. TODO: more details about them. For the iostream/raw transport the C++11 standard library is sufficient. For the Asio based transports, there is no C++11 library that provides the networking capabilaties that Asio does. As such even with a C++11 build system, you will need a standalone copy of Asio to use if Boost Asio is not available. ### Can WebSocket++ be used with standalone Asio Yes. The process is the same as used with standalone Asio itself. Define `ASIO_STANDALONE` before including Asio or WebSocket++ headers. You will need to download a copy of the Asio headers separately (http://www.think-async.com) and make sure they are in your build system's include path. ### Can WebSocket++ be used without TLS or OpenSSL? Yes. When using the iostream/raw transport, there are no TLS features and OpenSSL is not required. When using the Asio transport TLS features are optional. You only need OpenSSL if you want to use TLS. You can only make or recieve encrypted connections (https/wss) if you have enabled TLS features. Whether an Asio endpoint uses TLS or not is determined by its config template parameter. The default bundled `websocketpp::config::asio` and `websocketpp::config::asio_client` configs do not support TLS, the `websocketpp::config::asio_tls` and `websocketpp::config::asio_tls_client` do. The `` and `` headers will include both the TLS and non-TLS varients of their respective configs and require the presence of OpenSSL. The `` and `` headers will include only the non-TLS configs and do not require OpenSSL. ## Compression ### How do I use permessage-deflate in version 0.6.0-permessagedeflate and 0.7.0? These versions of the library require a custom config to use the permessage-deflate extension. Here is a minimal example of such a custom config. You can also integrate these lines into an existing custom config. Note that in these versions there is no fine grained control over which connections are compressed or not. Clients will request compression with the default settings and use it if the server supports it. Servers will accept whatever parameters clients request. Outgoing messages by default will be compressed if compression was auto-negotiated during the handshake. There is an option to force a specific message to be sent uncompressed even if compression was negotiated. This may be useful for sending data that you know to be compressed already (images, zip files, etc). __Server Example__ ``` #include struct deflate_server_config : public websocketpp::config::asio { // ... additional custom config if you need it for other things /// permessage_compress extension struct permessage_deflate_config {}; typedef websocketpp::extensions::permessage_deflate::enabled permessage_deflate_type; }; typedef websocketpp::server server_endpoint_type; ``` __Client Example__ ``` #include struct deflate_client_config : public websocketpp::config::asio_client { // ... additional custom config if you need it for other things /// permessage_compress extension struct permessage_deflate_config {}; typedef websocketpp::extensions::permessage_deflate::enabled permessage_deflate_type; }; typedef websocketpp::client client_endpoint_type; ``` ## Security ### Is it possible to terminate a malicious connection quickly, without tying up resources performing clean close steps, Yes. The library will automatically detect and terminate connections that violate the WebSocket protocol. In cases where the library believes the remote endpoint to be malicious or sufficiently broken to be unlikely to understand or process the closing handshake, it will be omited. If your application detects conditions above the protocol level that you believe to be malicious, for example, if you recognize an IP from a known denial of service attack, you can close the connection with two different levels of urgency. Use the standard `websocketpp::endpoint::close` or `websocketpp::connection::close` methods with one of the following special close codes: - `websocketpp::close::status::omit_handshake`: Omits the closing handshake, but cleanly closes the TCP connection. - `websocketpp::close::status::force_tcp_drop`: Forcibly drop the TCP connection. Please note that usage of these disconnect methods results in a violation of the WebSocket protocol and may have negative reprocusions for the remote endpoint with respect to network timeouts. Please use caution when using them. ## Build Issues ### Getting compile errors related to `std::chrono`, `boost::chrono`, `waitable_timer`, or `steady_clock` Your build system may be confused about whether it is supposed to be using `boost::chrono` or `std::chrono`. Boost automatically detects this setup on some compilers but not others. Defining `BOOST_ASIO_HAS_STD_CHRONO` can help. See http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/overview/cpp2011/chrono.html for more details. */