search

khoih-prog / WebSockets2_Generic

A WebSocket Server and Client library for Arduino, based on RFC6455, for writing modern Websockets applications. Now support ESP8266, ESP32 (including ESP32-S2 Saola, AI-Thinker ESP-12K, WT32_ETH01, etc.), nRF52, SAMD21, SAMD51, SAM DUE, STM32F/L/H/G/WB/MP1, Teensy, RP2040-based, etc. boards, with WiFiNINA, Teensy 4.1 NativeEthernet/QNEthernet, Ethernet W5x00 / ENC28J60 / LAN8742A / LAN8720, ESP8266 / ESP32-AT modules/shields, as well as SINRIC / Alexa / Google Home
GNU General Public License v3.0
80 stars 29 forks source link

Serious problem with timeout when sending packages #60

Closed jonathanlundstrom closed 1 year ago

jonathanlundstrom commented 1 year ago

Hi,

We've developed a solution using the Pico 2040W that gets data from an Acconner radar chip (core 1) and saves this into a circular buffer that is then read and uploaded (core 0) using this library. We're using the WifiMulti library to connect and manage our wireless network connection, and I've done extensive testing to make sure that library functions as intended – it does.

Our main concern is that the thread (core 0) responsible for offloading the radar frames, sent as binary data, randomly freezes when the connection is bad or when the connection to the websocket is lost. Sometimes this seems to happen without an actual closed event being fired, and the available() method also returns a status indicating that the connection is alive and well, despite the connection obviously not working.

Since our application is led to believe that the connection is still working, we proceed with trying to send data – and this process seems to have a very long timeout, hanging our core on each and every send for approximately 5 seconds, before returning true, indicating that a send was indeed successful, despite that not being the case.

So there seems to be multiple problems:

  1. The first one being that the library doesn't detect if the connection actually drops and available() keeps saying that the connection is fine.
  2. The send method found here is still called, despite the connecting not being available, and the _client send method seems to have a timeout of about 5000 ms.
  3. The third and final issue also has to do with line linked above. That the send method assumes that the transfer went through, which is just not a good idea for a TCP transfer, and means that our application is fooled yet again.

Are there any prospects for solutions on these issues? If not I think that we'll unfortunately have to move to a plain TCP socket based solution as the embedded code is dependent on issues like this not happening.

Thank you! :)

khoih-prog commented 1 year ago

Hi @jonathanlundstrom

Thanks for taking time to use and investigate the issue.

For real-time, best performance and demanding use-cases, I suggest you to use regular / plain TCP Socket.

WebSockets is made for browser to server communication where you have no access to raw TCP sockets anyway

Check

  1. WebSockets vs. Regular Sockets
  2. Teensy 4.1 high rate websocket communication

I know there are too many TODO improvements to be made and bugs to be fixed. But the reality is that I haven't got enough time to spend on them.

For example, there are too many in the library for almost every new board / interface.

https://github.com/khoih-prog/WebSockets2_Generic/blob/aa30bc03f604efe07d6c08214391a5ad98676776/src/Tiny_Websockets_Generic/network/RP2040W/RP2040W_tcp.hpp#L106-L168

So if possible, please help contribute, create new PRs to fix and help other users.

Good Luck with your promising project,