This might happen in some special cases where
WebSocketTransport::sendOnSocket() fails, closes the socket, and set
the ready state to CLOSED, but WebSocket::run() stills wait the
interrupt event to happen.
Possibly related to #474
* Added support for setting custom ping messages with support for any 'ping' message type (binary ping message, text ping message)
* Add default value
---------
Co-authored-by: YuHuanTin <2@>
* Quick hack to host HTTP and WS on the same port #373
* Quick hack to host HTTP and WS on the same port #373 - simplify code
* ran clang-format
Co-authored-by: En Shih <seanstone5923@gmail.com>
Co-authored-by: The Artful Bodger <TheArtfulBodger@users.noreply.github.com>
* Introduction of IXWebSocketSendData that makes it possible to not only send std::string but also std::vector<char/uint8_t> and char* without copying them to a std::string first.
Add a sendUtf8Text() method that doesn't check for invalid UTF-8 characters. The caller must guarantee that the string only contains valid UTF-8 characters.
* Updated usage.md: sendUtf8Text() and IXWebSocketSendData
* Fix#323: Missing SelectInterrupt implementation for Windows
Using WSAEventSelect, WSAWaitForMultipleEvents and WSAEnumNetworkEvents to emulate poll() with an interrupt-event.
* Cleanup
* Fixed incomplete comment.
* Switched ifdefs to support other Unixes with pipe file descriptors
* Fixed: SelectInterrupt fallback code for getFd()==-1 && getEvent()==nullptr converted a PollResultType::Timeout into a ReadyForRead causing the HttpClient to fail because it uses a hard-coded "SelectInterrupt" instance that doesn't implement getFd() and getEvent().
* Fixed gcc compile errors
* - HttpClient now uses the SelectInterruptFactory
- Fixed wrong ix::poll result when using Windows WSA functions
* We must deselect the networkevents from the socket event. Otherwise the socket will report states that aren't there.
* 1) IXWebSocketTransport: BUG: int type has no warranty of number of bits. It depends on compiler and architecture. In my system (64 bit) is 32 bit.
1 << 63 is bad idea in this case because the final number is 0 by overflow.
The symptom observed is that the server can't receive messages.
2) IXSocketFactory: Compilation Warning: Variable not in use.
* Better aproach suggested by Benjamin.
Websocket Server / do a case insensitive string search when looking for an Upgrade header whose value is websocket. (some client use WebSocket with some upper-case characters)
