Also mark the WS client as closing before we close the Redis connection,
to avoid its last error callback (if sent) trying to send out data while
we're in the middle of freeing the client.
1. Introduce ws_client struct
2. Handle all communications from websocket.c for WS clients
3. Always use a dedicated Redis connection for WS clients
4. Add rbuf & wbuf evbuffers for incoming & outgoing WS data
5. Use event_base_once to control R/W events
6. WS test: make sure to read complete HTTP response
For WS clients, reuse a persistent cmd struct attached to the
http_client object: take the cmd built from the WS frame, and copy it to
the persistent cmd.
1. Only HTTP-based pub-sub clients were re-using a cmd object, but
WS clients were not. This led to the commands sent by a WS client
to be processed out of order, just queued to Redis but with no
guarantee that they would be de-queued from the event loop in the
same order. This change attaches a permanent cmd object (with its
associated Redis context) to WS clients just like pub-sub clients
do.
2. WS responses are also no longer sent out of order, but added to a
write buffer that is scheduled for writing as long as there is still
some data left to send. This replaces the use of http_response which
contained extra fields (headers, HTTP response) that were duplicated
without ever being sent out.
Both ws_handshake_reply and ws_reply build http_response objects without
using the status code or headers, this code can be refactored to use a
single method.
Add new pub-sub test using WebSockets, disabled by default due to
message ordering not matching what is expected.
Enable the test with `PUBSUB=1 ./ws-tests.py`
The overall rate was incorrect when using non-default intervals. Also
simplify the code using plain nanosecond values, and fix the rate for
the last event which was based on the number of sleeps instead of the
actual time elapsed.
The implementation was waiting for the client, which leaves some hanging
even after they called close(). This mirrors the behavior for HTTP
connections in client.c where close() is called right before
http_client_free.
1. Origin and Sec-WebSocket-Origin are now optional: only return a matching
Sec-WebSocket-Origin if one of the two headers was provided.
2. Change order of headers: return Sec-WebSocket-Accept immediately
after Upgrade and Connection since some clients expect it there.
If the client closes the connection before we can even start to respond,
the event_add will fail and we need to clean up the http_response object
since this would have happened only after we've sent the whole response.
ws_handshake_reply was sending its response using a single write(2) call
without error-checking, which could well send only part of it and leave
the client hanging. This change creates an HTTP response object and
schedules it for writing using the event loop.
Tested with Valgrind, no memory is leaked.
1. Generate random WS connection key
2. Read headers returned in WS connection (upgrade) response
3. Validate Sec-WebSocket-Accept return value from webdis
Tested by introducing an artificial error in webdis, reported as
expected.
* Use pure.css for a basic grid
* Detect disconnections, update UI accordingly
* Make GET/SET commands configurable and interactive
* Add button to clear logs
* Test with current branch
The keep_alive flag is needed on http_response for websocket
connections. Without it, the server closes the connection as soon as a
reply to the first frame is sent.