Question 1. Can A Handler Be Changed After A Connection Is Established? Can One Be Removed?
Yes, but not globally.
Handlers assigned to endpoints will be automatically copied to the connections created by that endpoint. Changing a handler on an endpoint will only affect future connections.
Once a particular connection is created, it’s handlers can be changed individually by calling the set_*_handler methods. Once changed, all future events of that type for that connection will use the new handler.
To remove a handler that was previously set, call the set method with nullptr or NULL.
Question 2. Can I Reject Or Conditionally Accept A Connection?
Yes. The validate handler is called after the initial handshake has been recieved but before WebSocket++ has responded. This gives you the opportunity to inspect the incoming connection request, its headers, origin, subprotocols, and the remote endpoint IP. Return true from the validate handler to accept the connection and false to reject it.
To set a custom HTTP error message for your rejection, use websocketpp::connection::set_status and (optionally) websocketpp::connection::set_body() to set the HTTP status code and error message body text. If you do not set body text a message will be generated automatically based on the status code.
Question 3. How Do I Negotiate Subprotocols?
The Asio transport based clients and servers use the Asio library’s underlying io_service to handle asyncronous networking operations. The standard behavior of the io_service is to run until there are no async operations left and then return. WebSocket++, when using the Asio transport, behaves like a standard Asio application. If you want your WebSocket++/Asio based program to stop network operations and cleanly close all sockets you will want to do the following:
- For servers, call websocketpp::transport::asio::endpoint::stop_listening to initiate the closing of the server listening socket.
- For clients, if you have engaged perpetual mode with websocketpp::transport::asio::endpoint::start_perpetual, disable it with websocketpp::transport::asio::endpoint::stop_perpetual.
- For both, run websocketpp::endpoint::close or websocketpp::connection::close on all currently outstanding connections. This will initiate the WebSocket closing handshake for these connections
- Wait. Asio is asyncronous. When the calls to the above methods (stop_listening, close, etc) complete the server will still be listening, the connections will still be active until the io_service gets around to asyncronously processing the socket and WebSocket protocol closing handshakes. The io_service::run method will exit cleanly and automatically when all operations are complete.
WARNING: Asio’s io_service has a method called stop. WebSocket++ wraps this method as websocketpp::transport::asio::endpoint::stop. While this operation has a benign sounding name, it is a powerful and destructive operation that should only be used in special cases. If you are using io_service::stop or endpoint::stop without a very good reason your program is likely broken and may exhibit erratic behavior. Specifically, io_service::stop stops the processing of events entirely. This does not give current operations (such as socket closing handshakes) the opportunity to finish. It will leave your sockets in a dangling state that may invoke operating system level timeouts or other errors.
Question 4. Is There A Way To Check The Validity Of A Connection_hdl?
Sometimes, not generally though, because there isn’t a way to check if a TCP connection is valid.
You can try upgrading your hdl to a full connection_ptr using websocketpp::endpoint::get_con_from_hdl. If this fails, the hdl is definitely invalid. If it succeeds it may or may not be. The only way to tell definitively is to try and send something (either a message or a ping).
If you handle errors from methods like send, ping, close, etc correctly then you shouldn’t have to worry about accidentally sending to dead connections. The send/ping/pong/close methods will set or throw a specific error in the case that you tried to send something but the connection was closed/gone/etc.
Question 5. How Do I Fix The “address Is In Use” Error When Trying To Restart My Server?
Normally, for security purposes, operating systems prevent programs from listening on sockets created by other programs. When your program crashes and restarts, the new instance is a different program from the perspective of the operating system. As such it can’t listen on the socket address/port that the previous program was using until after a timeout occurs to make sure the old program was done with it.
The the first step for handling this is to make sure that you provide a method (signal handler, admin websocket message, etc) to perform a clean server shutdown.
The clean close strategy won’t help in the case of crashes or other abnormal closures. An option to consider for these cases is the use of the SO_REUSEADDR socket option. That instructs the OS to not request an exclusive lock on the socket. This means that after your program crashes the replacement you start can immediately listen on that address/port combo again.
Question 6. How Do You Send And Recieve Binary Messages?
When supported by the remote endpoint, WebSocket++ allows reading and sending messages in the two formats specified in RFC6455, UTF8 text and binary. WebSocket++ performs UTF8 validation on all outgoing text messages to ensure that they meet the specification. Binary messages do not have any additional processing and their interpretation is left entirely to the library user.
To determine the type of an incoming message, use websocketpp::message_buffer::message::get_opcode. The relevant return values are websocketpp::frame::opcode::text and websocketpp::frame::opcode::binary. There is no difference in how payloads are retrieved between these modes, only in how WebSocket++ validated the contents and how the library user is to interpret the data.
To specify the type of an outgoing message, use the frame opcode values listed above as the second op parameter for websocketpp::connection::send. There are two relevant overloads of send. One that takes a std::string and defaults to op=text. The other that takes a void const * and a size_t length and defaults to op=binary. Note: You can send binary messages via the string overload and text messages via the void * overload. In the case that you are manually building a message buffer rather than using the automatic send member functions, you can pass the opcode in as a parameter to the message buffer constructor or user the websocketpp::message_buffer::message::set_opcode member function to set or re-set it later.
Question 7. 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 capabilities 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.
Question 8. Can Websocket++ Be Used With Standalone Asio?
Yes. The process is the same as used with standalone Asio itself. Defined ASIO STANDALONE before including Asio or WebSocket++ headers. You will need to download a copy of the Asio headers separately and make sure they are in your build system’s include path.
Question 9. 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.
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.
Question 10. Build Issues With Tls On Recent Versions Of Os X?
Mac OS X ships a severely outdated Yes. The process is the same as used with standalone Asio itself. Defined ASIO STANDALONE before including Asio or WebSocket++ headers. You will need to download a copy of the Asio headers separately and make sure they are in your build system’s include path.
version of the OpenSSL library. To securely use TLS with WebSocket++ on OS X you will need to install a modern version of OpenSSL via homebrew or compiling from source.
Question 11. How Do I Use Permessage-deflate In Version 0.6.0-permessage Deflate 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).
Question 12. What Is Websockets?
WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection.
Question 13. How To Create A Websocket Connection?
ws = new WebSocket(‘ws://localhost:8080/user’);
Question 14. Have You Implemented Websockets? What Was The Use Case?
Have implemented WebSockets for a chat application using Spring Boot.
Python Interview Questions
CSS3 Interview Questions
HTML 5 Interview Questions
OOJS Interview Questions
HTML 5 Tutorial
Angular JS Interview Questions
Python Interview Questions