Buffer `send_buf` for high throughput

[ayufan]

Thanks for great component. It was great to find it :)

I was having a trouble when running UART on ESP8266 on 1.5M where there was clearly buffer overrun first on UART side, second on TCP side. This changes how this is implemented and makes it work pretty well by buffering UART receive, to ensure that TCP write succeeds. It is being retried on next try. This works for me well after these changes:

uart:
  id: uart_bus
  tx_pin: GPIO15
  rx_pin: GPIO13
  baud_rate: 1500000
  rx_buffer_size: 8192

Note: it would be great if this project would have license assigned (MIT preferable?). Currently, it is unclear under what conditions I'm contributing.

[oxan]

Do I understand it correctly that the problem you want to solve is that if in high throughput situations, there could be read more data from the UART than fits in the TCP buffers, and data gets lost (because the result of tcp_client->write() isn't checked/handled properly)?

Note: it would be great if this project would have license assigned (MIT preferable?). Currently, it is unclear under what conditions I'm contributing.

There's a GPLv3 header in every file. I could add a LICENSE file to the repository, but the license should be pretty clear already.

[ayufan]

Do I understand it correctly that the problem you want to solve is that if in high throughput situations, there could be read more data from the UART than fits in the TCP buffers, and data gets lost (because the result of tcp_client->write() isn't checked/handled properly)?

Exactly. This happens with larger RX buffers on UART side. I have Linux-based devices that output 1.5M by default (Rockchip SBC) that easily overruns first UART (unless you enlarge buffer), second a way how it is written to TCP.

There's a GPLv3 header in every file. I could add a LICENSE file to the repository, but the license should be pretty clear already.

Ah. I did not notice that. I usually look for LICENSE. This is great! Thank you

[bojanpotocnik]

Do you plan to merge this PR?

[oxan]

Do you plan to merge this PR?

Yes, but I've to find some time and energy to properly review, test and adapt this.

[syssi]

@ayufan Could you rebase your PR? Thanks in advance!

[oxan]

Hi! Sorry for the silence, I've neglected this project quite a bit over the last year.

Tonight I've finished refactoring the component to use ESPHome's socket abstraction (see #25). During that process I've also implemented something analogous to this PR, but in slightly different manner. I've used a ringbuffer and keep track of the read position of each client separately, so that one lagging client doesn't prevent sending of data to other clients (until the buffer is full). I've also made the buffer side configurable in the YAML configuration.

[oxan]

Equivalent functionality has been merged with #25.