-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Did WiFiClient.connected recently change for small payloads? #5257
Comments
It is true that semantic of Current semantic is:
So Thus a general inner communication loop could be:
Historically, @earlephilhower Is this this semantic the same when using BearSSL ? We really should document that somewhere. |
@d-a-v The SSL implementation of For SSL "::connected()" means: "TCP is still connected OR there is some decrypted data in a SSL decrypted buffer." axTLS: Arduino/libraries/ESP8266WiFi/src/WiFiClientSecureAxTLS.cpp Lines 261 to 272 in 561426c
BearSSL copied this behavior: Arduino/libraries/ESP8266WiFi/src/WiFiClientSecureBearSSL.cpp Lines 251 to 255 in 561426c
|
This change appeared in #4626. This is a semantic change : connected() == allowed to write. Do you think it is wise to use the same semantic with BearSSL (and AxTLS) ? Also, about |
@d-a-v // available() must be tested first when using "(available() || connected())" Under what conditions is this test order important. |
Only if you don't call |
See discussion here: esp8266/Arduino#5257
See discussion here: esp8266/Arduino#5257
@d-a-v @Bodmer I propose we don't rely on such implementation details in our client implementation as they might change in the future w/o breaking API. Same goes for relying on how BearSSL and axTLS implemented The documented template should be robust enough to work reliably regardless of such subtleties (hence, |
Made it a PR #5355. |
Basic Infos
Platform
Settings in IDE
Problem Description
This is a follow-up to ThingPulse/esp8266-weather-station#140 which in turns follows up on as long thread in our support forum.
It appears that a (nested) HTTP/TCP parse loop that first checks for
client.connected()
and then forclient.available() > 0
no longer works reliably for small payloads.What seems to be happening on the networking stack is that "sometimes" the
WiFiClient
reportsconnected() == false
immediately when the payload is sufficiently small. However, even though the client is no longer connected its internal buffer contains all the data and, hence,client.available()
returns more than 0.Can you confirm that such a double nested loop, which is a very common sketch template, should these days be changed to only check for
client.available() > 0
?Sketch fragment
The text was updated successfully, but these errors were encountered: