Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WiFiSocketBuffer interferes with sized reads #249

Open
xmkg opened this issue Jul 12, 2023 · 0 comments
Open

WiFiSocketBuffer interferes with sized reads #249

xmkg opened this issue Jul 12, 2023 · 0 comments
Labels
topic: code Related to content of the project itself

Comments

@xmkg
Copy link

xmkg commented Jul 12, 2023

The WiFiSocketBuffer change introduced with the commit ea1a366 , to address issue #9 (i.e. to optimize byte-by-byte reads), but it's also forcing API users to pull at most 64 bytes of data (or 1500 for non-AVR) at a time, which is inefficient if the amount of data to be read is known beforehand.

My library (tdslite) has such a scenario where TDS packets have a fixed 8-byte header and N-byte data, where the value of N is included in the header. The library's per-packet data pull routine is roughly as follows:

  • Pull exactly 8 bytes from the client (client.read(buf, 8))
  • Read the packet length from the 8 bytes just been read
  • Wait until at least N bytes of data becomes available by polling the client.available() periodically
  • Read the rest of the packet (client.read(buf, N))

... which works flawlessly with the other implementations, such as Arduino EthernetClient or the ESP's WiFiClient. So, I wonder if we can disable the buffer for the sized reads, or alternatively add a way to disable this intermediate buffer. The second option would be desirable for memory optimization purposes as well in tightly memory-constrained environments where the amount of memory consumed is much more important than the processing delay.

@per1234 per1234 added the topic: code Related to content of the project itself label Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself
Projects
None yet
Development

No branches or pull requests

2 participants