Enhance Qt Websocket API

The Qt websockets API provided by Qt 5.3.1 limits the API user to invoke all read and write access to the API from a single thread. It is very natural for an API user to create a websocket and thereafter perform read and write operations from two different threads.

The websocket API is not thread safe by design but the API does not provide the flexibility to the user to support thread safety in their own API without significant changes to the Qt Websocket API. The current Qt API performs asynchronous reads of the socket and delivers a signal on completion of the socket read. The socket write operation is a synchronous write operation. The unavailability of the socket descriptor to the user for reads does not allow the ability to mutex protect the socket for simultaneous read and write operations.

The suggestion here would be :

• To provide a signal say “dataAvailableToRead” which then allows the API user to perform a synchronous websocket textMessageRead / binaryMessageRead / textFrameRead and binaryFrameRead in the slot handler.
• The synchronous reads must take a timeout value for the operation.
  The user can then Mutex protect the socket for all read and write operations enabling thread safety.
  The websocket API does not allow the user to set options for the descriptor on the open call. The suggestion would be to allow the user to setup various options that include :
• Read timeout values.
• Keep Alive Timer.

Currently the Qt API’s for websockets hard codes the timeout to 5 secs. This may have a tendency to block the UI if it was implemented in the same thread. The API user is forced to move all read operations into a separate thread.
A call to waitForReadyRead with a timeout value will provide additional flexibility to the user to read from the socket.
A signal from QWebsocket on completion of writing all the data to the socket would also be useful.