Description
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.