mortzdk/websocket

WSServer is a fast, configurable, and extendable WebSocket Server for UNIX systems written in C (C11).

websocket's Issues

Unable to run in Background

If we run this server in background then it is crashing.

wolfssl and mbedtls etc support?

Can it be ssl-neutral so it supports other ssl libraries in addition to openssl? e.g. wolfssl, mbedtls, boringssl,libressl

Unable to receive binary Data

I have used this server code to store the binary data my application sends. But only the first packet bytes are getting stored. When I debugged with valgrind ,the server is blocking on recv call and once I stop my application, its receiving only first packet bytes.

Internet Explorer 11 incorrectly breaks off connection each 15 seconds

Internet Explorer 11 Will break off the websocket connection.

please help to check.

https://github.com/hoaproject/Websocket/issues/33

Here is what need to be considered.

IE sends an unsollicited PONG frame. The RFC6455 says:

A Pong frame MAY be sent unsolicited. This serves as a
unidirectional heartbeat. A response to an unsolicited Pong frame is
not expected.

Several implementations out there (Play, Spring, Go etc.) encountered this issue because receiving an unsollicited PONG was not expected and was creating a bug. In Hoa\Websocket, this is not the case because we handle it as required by the RFC. IE has the fin parameter set to 1, not 0, so this is a valid frame and we don't respond to it.

Since we don't respond, IE sends a random frame that is not a valid one. And yes, random, I don't receive the same frame twice.
After some searches, it seems that this is a known bug in IE10 (not 11). To fix that, we may return a PING. This is what I did, but it does not fix anything. Maybe on IE10, but not on IE11.

Because the bug is still opened on IE10, we can assume this is still present in IE11.

I close this issue because I can't do anything to avoid that… The connection is closed by the server because of the malformed/invalid message we receive after the PONG. IE does not fire the CloseEvent properly despites the server sends a valid close frame!

Sorry for that. If you find a server that handles IE11 properly, I would be glad to know them and look inside the code to see what workaround they found.

Does Not Support TCP keepalive

In this server it does not provide tcp keepalive option. It uses system default configuration so if a client crash/power off then server does not know about this event.