You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sending a web socket message using the above methods a buffer is created. Under certain circumstances you might want to manipulate or populate this buffer directly from your application, for example to prevent unnecessary duplications of the data. This example below shows how to create a buffer and print data to it from an ArduinoJson object then send it.
Copy file name to clipboardExpand all lines: src/AsyncWebSocket.h
+24-14Lines changed: 24 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -225,7 +225,7 @@ class AsyncWebSocketClient {
225
225
mutable asyncsrv::mutex_type _queue_lock;
226
226
std::deque<AsyncWebSocketControl> _controlQueue;
227
227
std::deque<AsyncWebSocketMessage> _messageQueue;
228
-
boolcloseWhenFull = true;
228
+
bool_closeWhenFull = false;
229
229
230
230
AwsFrameInfo _pinfo;
231
231
@@ -274,29 +274,39 @@ class AsyncWebSocketClient {
274
274
return _pinfo;
275
275
}
276
276
277
-
// - If "true" (default), the connection will be closed if the message queue is full.
277
+
// CloseClientOnQueueFull:
278
+
//
279
+
// - If "true", the client will be closed if the message queue becomes full.
278
280
// This is the default behavior in yubox-node-org, which is not silently discarding messages but instead closes the connection.
279
281
// The big issue with this behavior is that is can cause the UI to automatically re-create a new WS connection, which can be filled again,
280
282
// and so on, causing a resource exhaustion.
283
+
// Also this can lead to a crash as explained in this issue: https://github.com/ESP32Async/ESPAsyncWebServer/issues/433
281
284
//
282
-
// - If "false", the incoming message will be discarded if the queue is full.
285
+
// - If "false" (default in this library), the incoming message will be discarded if the queue is full.
283
286
// This is the default behavior in the original ESPAsyncWebServer library from me-no-dev.
284
287
// This behavior allows the best performance at the expense of unreliable message delivery in case the queue is full (some messages may be lost).
285
288
//
286
-
// - In any case, when the queue is full, a message is logged.
287
-
// - IT is recommended to use the methods queueIsFull(), availableForWriteAll(), availableForWrite(clientId) to check if the queue is full before sending a message.
289
+
// With recent refactorings of the library, the queue is barely used and the library supports a fast sending rate of messages. So if the queue is growing:
290
+
// - either the server is sending messages at an insane fast rate, faster than what the client can acknowledge, which can be the case if the client is slow or if the messages are big and the network is slow,
291
+
// - or there is a network issue causing the client to not receive messages, or network is broken. In that case, if the network is broken, the queue will fill temporarily until the connection is closed and client removed.
292
+
//
293
+
// In case your application requires a fast and high frequency message sending and you foresee some queue usage, you can:
294
+
// - increase the queue side to allow some room
295
+
// - check some functions status before or when sending in order to decrease your sending rate to let the queue drain, or take action by closing this client if necessary.
288
296
//
289
-
// Usage:
290
-
// - can be set in the onEvent listener when connecting (event type is: WS_EVT_CONNECT)
297
+
// This has to be an application-specific deicison that the library cannot take for you.
298
+
// Here are a list of some functions that you can use and check the boolean value returned:
299
+
// - the send methods
300
+
// - queueIsFull()
301
+
// - availableForWriteAll()
302
+
// - availableForWrite(clientId)
291
303
//
292
-
// Use cases:,
293
-
// - if using websocket to send logging messages, maybe some loss is acceptable.
294
-
// - But if using websocket to send UI update messages, maybe the connection should be closed and the UI redrawn.
304
+
// When the queue is full, a message is logged in case it is discarded.
0 commit comments