You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
... 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.
The text was updated successfully, but these errors were encountered: