ESP8266 Community Forum

- Sat Jan 09, 2016 4:26 pm #38339 You're right, I was making an assumption that it was client.connect(). I ran this for a while and picked the worst bit:

client.connect() millis: 2
client.print() millis: 3
client.connect() millis: 2
client.print() millis: 3
client.connect() millis: 2
client.print() millis: 3
client.connect() millis: 6
client.print() millis: 49
client.connect() millis: 1
client.print() millis: 37
client.connect() millis: 1
client.print() millis: 3
client.connect() millis: 2
client.print() millis: 3
client.connect() millis: 2
client.print() millis: 3649

I would need to get more stats to make sure but it looks like the big delays happen exclusively with client.print(). So maybe client.connect() does have a good timeout/re-try but client.print() doesn't. Though that is another assumption which I will have to test.

- Sat Jan 09, 2016 5:49 pm #38360 I've been digging to this issue and while I don't understand all the details it seems it mostly comes down to the fact that the library can only handle one data-packet on the wire at a time and thus has to keep it in the buffer in case it has to be retransmitted, ergo it has to wait for an ACK from the other party. https://github.com/esp8266/Arduino/issues/922 talks about this issue and in https://github.com/esp8266/Arduino/pull/1323 Links2004 claims he will take a look at it later, but does not say when.

In the meantime you can try the modified non-block library mentioned on the last post in the first link I gave. And hope that Links2004 or some other code-wizard does manage to come up with a proper solution to this, eh?