WiFiClient - fast with available caching

[JAndrassy]

I test sketch upload to SAMD and nRF5 with different libraries and WiFiSpi couldn't make it. Was too slow. This PR makes WiFiSpiClient much faster in typical use with available() checking.

Additionally read(buffer, size) method should return count of bytes put into buffer, to be useful. Firmware doesn't change the input value of the parameter. I patched it with cached available count.

[JiriBilek]

Thank you, I will look at it ASAP.

[JAndrassy]

Arduino in WiFiNINA library uses a buffer layer https://github.com/arduino-libraries/WiFiNINA/blob/master/src/utility/WiFiSocketBuffer.cpp

[JiriBilek]

Juraj, finally, I examined your PR and IMHO there is a problem. The available bytes change in time as new data come through the wifi. I observed that shortly after sending GET request, the ESP reports some 1000 bytes available and after a while the value rises. I see, you are asking the ESP for new available bytes every time availData==0 but this might prevent reading bigger chunks of data. I have to consider both the positive and the negative aspects of the feature.

[JAndrassy]

I uploaded 40 kB of application binary over it.

availData is the last know count of available bytes. it is decremented as data are read and refreshed from esp if all of the known count of bytes was read

[JiriBilek]

Sure it works, I said I prefer buffered reading of data. I consider:

• caching available() value
• reading in 25 byte chunks (7 bytes protocol overhead to 32 byte SPI message length)

Hesitating:

• inserting available() value into read() response and automatically update cached available value
• coupling read() with connected() and available() - this requires change of return value from read()

Maybe more, I will post my further ideas here.

Just now I finished a first SSL support and my next goal should be https://github.com/JiriBilek/WiFiSpi/issues/14

[JAndrassy]

it has no advantage to refresh availData with every read. read(buff, size) should return count of bytes filled into buffer. (parameter size is the size of the buffer)

[JiriBilek]

Refreshing availData has sense when you are reading chunks of data into buffer held on client. I agree that the return value from read(buff, size) is bad, I copied the prototype from arduino library as I wanted my library to be 1:1 replacement.

[JAndrassy]

in my PR the return data size from read is the same as getAvailable called before read.

• if someone calls read(buff, available) the return is as expected.
• if someone calls it with buffer size, then he expects to return count of bytes read.
• and if the buffer size is smaller then available, the return value is good too.

it can happen that the read return less then buffer size and it is not the end of all data. but it can always happen that the next chunk of data didn't arrive yet

[JAndrassy]

I close this because it doesn't sync for WiFClient copies