Revert endpoint to an old version to allow ESP32 projects to run more… #23
Conversation
This file contains 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
… reliably The code in send has been revered to as it was as commit 91e7043. Commit 217257b changed the code to concatenate the header and body using a string, but for large sends this causes a doubling of the memory required. A number of web based ESP32 projects nor fail. This has been documented in issue #131
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
… reliably
The code in WebsocketsEndpoint::send has been revered to as it was in commit 91e7043. Commit 217257b changed the code to concatenate the header and body using a string. For large sends this causes a doubling of the memory required. A number of web based ESP32 projects now fail. This has been documented in issue #131 in the dependent ArduinoWebsockets repository
gilmaimon/ArduinoWebsockets#131
There are a number of other places in the code that also use string to concatenate buffers and reduce sends. I can see that for small messages this is a performance improvement, but for large messages it is a memory limitation. The memory soon gets fragmented and the send fails with a crash.
The project I was playing with when I discovered this was an example webserver using ESP32-CAM. The buffers being sent are a complete image from the camera (so many k). The image is created in the large PSRAM and, as long as "mask" isn't being used, it will be sent directly from there without any additional allocation. I would imagine that many of the target processors are also resource limited, and so will have trouble sending large packets.
If anyone is interested, I would be happy to create a change that uses a size threshold to select the send method of either 2 sends without memory allocation, or one with. This should probably also be applied to other places where string is used to concatenate buffers. It would preserve the throughput for small messages while protecting from memory problems when using large messages.