Skip to content

Conversation

@vortigont
Copy link

Hey team, long time! family matters, you know...
but I've returned with something new. Took my time to re-implement websockets from scratch.

  • created a newer more abstracted design pattern for message containers, gives more freedom to accommodate various objects
  • incoming message reassembly that spans multiple TCP packets
  • queue/message size limit with graceful disconnection
  • server side message replication
  • multiple endpoint handling with one server instance
  • optional server worker that decouples user callbacks handling from AsyncTCP (yes, finally!)
  • some other things...

I decided to give away all backward compatibility to untie my hands and implemented all in a separate classes within a single .cpp unit, 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).

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 :)
@vortigont vortigont marked this pull request as draft October 15, 2025 14:23
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.
@github-actions
Copy link

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@mathieucarbou
Copy link
Member

@vortigont : as you proposed, would you be able to refresh your PR but move the code in other classes (like WebSocketv2) so that we could have both implementation side by side for now to avoid breaking changes ?

@mathieucarbou
Copy link
Member

@vortigont : I tested the PR in a project and indeed this is not a breaking change PR - the classes are isolated.

I had to do some changed though:

  1. To supports Arduino String

  2. To set the handler not directly from the constructor (in some cases this is not possible when the WS server is a class field with the handler being a method of this class). Example: _ws.setEventHandler(std::bind(&WebApiWsLiveClass::onWebsocketEvent, this, _1, _2));

diff --git a/src/AsyncWSocket.h b/src/AsyncWSocket.h
index d45fe30..4944c93 100644
--- a/src/AsyncWSocket.h
+++ b/src/AsyncWSocket.h
@@ -167,7 +167,20 @@ public:
 
   // variadic constructor for anything that T can be made of
   template<typename... Args>
-  WSMessageContainer (WSFrameType_t t, bool final, Args&&... args) : WSMessageGeneric(t, final), container(std::forward<Args>(args)...) {};
+  WSMessageContainer (WSFrameType_t t, bool final, Args&&... args) : WSMessageGeneric(t, final), container(_convertArg(std::forward<Args>(args))...) {};
+
+private:
+  // Helper to convert Arduino String to const char* for std::string compatibility
+  template<typename Arg>
+  static auto _convertArg(Arg&& arg) {
+    if constexpr (std::is_same_v<std::decay_t<Arg>, String>) {
+      return arg.c_str();
+    } else {
+      return std::forward<Arg>(arg);
+    }
+  }
+
+public:
 
   /**
    * @copydoc WSMessageGeneric::getSize()
@@ -983,6 +996,10 @@ public:
     _handshakeHandler = handler;
   }
 
+  void setEventHandler(WSocketClient::event_cb_t handler) {
+    eventHandler = handler;
+  }
+
   /**
    * @brief callback for AsyncServer - onboard new ws client
    * 
  1. Why restricting to ESP-IDF 5 ? The project I tried into is using Arduino Core 2... It seems to work without the macro:
diff --git a/src/AsyncWSocket.cpp b/src/AsyncWSocket.cpp
index b4aa967..94dafe4 100644
--- a/src/AsyncWSocket.cpp
+++ b/src/AsyncWSocket.cpp
@@ -7,7 +7,6 @@
 #if __cplusplus >= 201703L
 #include "AsyncWSocket.h"
 #if defined(ESP32)
-#if (ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(5, 0, 0))
 #include "literals.h"
 
 #define WS_MAX_HEADER_SIZE  16
@@ -1036,6 +1035,5 @@ void WSocketServerWorker::_taskRunner(){
   vTaskDelete(NULL);
 }
 
-#endif  // (ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(5, 0, 0))
 #endif  // defined(ESP32)
 #endif  // __cplusplus >= 201703L
  1. Could you please rebase and move your code into a feature branch feature/new-ws in the asyncws repo so that all the team can participate ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants