I've been running into issues when posting data files from my MCUs up to a website where the connection is being dropped/closed before the data is completely sent. It seems to happen more frequently with larger files, but that could just be that larger files take longer to send/have more data writes so is more prone to encounter the problem. Failures seem to be happening a bit randomly though - sometimes after sending ~40 lines, sometimes after sending 350+ lines. (Anywhere from 170ms after opening the connection to 960ms.) Sending larger data files from my desktop does not have this issue.
I'm not sure what the underlying issue might be, but a solution that I was able to implement is to simply increase the number of times HTTPClient.cpp tries to do a retry. Currently it is hard-coded to retry 5 times:
size_t WiFiClient::retry(const uint8_t *buf, size_t size, bool write) {
size_t rec_bytes = 0;
if (write) {
//RETRY WRITE
for (int i=0; i<5; i++) {
rec_bytes = ServerDrv::sendData(_sock, buf, size);
if (rec_bytes) {
break;
}
}
return rec_bytes;
} else {
return rec_bytes;
//RETRY READ
// To be implemented, if needed
}
}
I changed my copy of the code to allow for that to be set dynamically (added an HTTPClient::setNumRetries()) method, but anyone else running into this issue can just change the '5' above to a larger number. But this might be something that could get added into the library as a whole.
(I've also added a delay(i) in there to incrementally delay the retries - not sure if that matters, but I figured it might help to delay each retry slightly in case its a WiFi connection issue or something else that just "needs more time".)
In my tests, 6 or 7 retries is pretty common and I've seen as many as 9. I've set my retry to 15 just to give me more wiggle room with the option of increasing the value via on the fly in case I run into more issues down the line once these MCUs are deployed.
(Note: this might be related to some of the other issues previously reported on related to dropped connections such as #129.)
I've been running into issues when posting data files from my MCUs up to a website where the connection is being dropped/closed before the data is completely sent. It seems to happen more frequently with larger files, but that could just be that larger files take longer to send/have more data writes so is more prone to encounter the problem. Failures seem to be happening a bit randomly though - sometimes after sending ~40 lines, sometimes after sending 350+ lines. (Anywhere from 170ms after opening the connection to 960ms.) Sending larger data files from my desktop does not have this issue.
I'm not sure what the underlying issue might be, but a solution that I was able to implement is to simply increase the number of times HTTPClient.cpp tries to do a retry. Currently it is hard-coded to retry 5 times:
I changed my copy of the code to allow for that to be set dynamically (added an HTTPClient::setNumRetries()) method, but anyone else running into this issue can just change the '5' above to a larger number. But this might be something that could get added into the library as a whole.
(I've also added a
delay(i)in there to incrementally delay the retries - not sure if that matters, but I figured it might help to delay each retry slightly in case its a WiFi connection issue or something else that just "needs more time".)In my tests, 6 or 7 retries is pretty common and I've seen as many as 9. I've set my retry to 15 just to give me more wiggle room with the option of increasing the value via on the fly in case I run into more issues down the line once these MCUs are deployed.
(Note: this might be related to some of the other issues previously reported on related to dropped connections such as #129.)