Reimplementing WebSockets #312
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
it would allow using AsyncWebSocketResponse with any type of objects that could take ownership of client pointer, not limited to specific class. This is a prereq for newer WSocket implementation
a proof of concept - message and buffer are abstracted behind generic class - websocket client reassembles incoming meassage spanning multiple tcp segments - in/out message queues - 8 byte message size support - queue / message cap limit - different event and status calls - two-way ws-close ack
If client sends us a message with size larger that predefined quota we could handle it gracefully. We send to the peer ws close message with proper code and wait for ack to terminate TCP connection. Meanwhile incoming message data is transparently discarded.
WSocketServer with worker thread that handles events from clients. Decouples AsyncTCP thread callbacks from executing user code to handle events and incoming messages.
- keepalive pongs implementation for Client class - message size/q cap for WSocketServer class
- keepalive would send periodical unsolicited pong messages to peer as per https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.3 - server-side echo. When activated server will echo incoming messages from any client to all other connected clients. This could be usefull for applications that share messages between all connected clients, i.e. WebUIs to reflect controls across all connected clients
variadic tpls would allow easy sending for text/strings contructables
This example would show how WSocketServer could register connections/disconnections for every new user, deliver messages to all connected user and replicate incoming data amoung all members of chat room. Change you WiFi creds below, build and flash the code. Connect to console to monitor debug messages. Figure out IP of your board and access the board via web browser using two or more different devices, Chat with yourself, have fun :)
A message that carries a pointer to arbitrary blob of data it could be used to send large blocks of memory in zero-copy mode, i.e. avoid intermediary buffering copies. + bunch of bugfixes for dataflow control, frame assembly, message containers methods
…module
This example implements a WebCam streaming in browser using cheap ESP32-cam module.
The feature here is that frames are trasfered to the browser via WebSockets,
it has several advantages over traditional streamed multipart content via HTTP
- websockets delivers each frame in a separate message
- webserver is not blocked when stream is flowing, you can still send/receive other data via HTTP
- websockets can multiplex vide data and control messages, in this example you can also get memory
stats / frame sizing from controller along with video stream
- WSocketServer can easily replicate stream to multiple connected clients
here in this example you can connect 2-3 clients simultaneously and get smooth stream (limited by wifi bandwidth)
a single instance of WSocketServer can serve multiple websocket URLs connection URL is hashed to 32 bit and kept as a member of respective WSocketClient struct a set of methods are provided to get/set/check server and client's URL
In case if there are pending messages in the Q we clamp window size gradually to push sending party back. The larger the Q grows then more window is closed. This works pretty well for messages sized about or more than TCP windows size (5,7k default for Arduino). It could prevent Q overflow and sieze incoming data flow without blocking the entie network stack. Mostly usefull with websocket worker where AsyncTCP thread is not blocked by user callbacks.
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey team, long time! family matters, you know...
but I've returned with something new. Took my time to re-implement websockets from scratch.
I decided to give away all backward compatibility to untie my hands and implemented all in a separate classes within a single
.cppunit, ESP32/C++17 minimum, other platforms I do not have in possession for now.This all is highly experimental for now, still work in progress with a bunch of features to be implemented. But I've created some examples for evaluation and early feedback if any (esp32cam is most funny one to play with).