This library has a fundamental problem that makes me wonder how it ever worked at all. There is even a comment in the code which led me to the surprising discovery that the code is simply not “fit for purpose”. Of course I have concrete proof and an explanation of that statement which I present below. It also explains why ever since I have started using it, I have noticed “random” periods of disconnection / reconnection loops, so it actually doesn’t work. As soon as I looked “under the hood” I could immediately see why.

This comment alerted me:

// Using a sendbuffer to fix bug setwill on SSL not working

The irony of this is that there is nothing wrong with either setwill or SSL or even the two combined. Certainly there is nothing wrong with LwIP that caused it. The problem is with your code and it is only coincidentally that the setwill issue showed it up. The same problem still exists in 90% of the rest of your library, and it is easy to explain.

The problem

ESPAsyncTCP is a thin wrapper arounf LwIP. LwIP client calls take char* parameters for “strings” e.g. clientID, topic etc. Thus of course, so does ESPAsyncTCP which effectively just “forwards” them to LwIP.

LwIP has many optimisations to improve throughput and performance, the main ones being buffering, queuing and coalescing of data. This is why there are two calls to send data rather than the more usual send found in synchronous aka “blocking” code.

The add function simply tells LwIP to buffer the data. If it doesn’t get any more within a given timeframe, it may then send the data. If gets more adds in rapid succession, it lumps them all together until…

The send function effectively tells LwIP “no more data from me for a while”. At this point LwIP still may not actually put it “on the wire” - it has some complex algorithms - but the main point is that your code has no control over when LwIP finally decides to do that. It could be up to several seconds after you call send and long after your function has exited…invalidating all your temporary variables as it does so.

Any code (not just this egregious example) that sends a temporary stack pointer (aka “local variable” address) data to a delayed function a) is asking for trouble b) has no concept of “asynchronous” c) breaks every rule of programming from chapter 1 of any book on C d) will run only by pure luck, if at all.

ALL the data you send to LwIP via ESPAsyncTCP are temporary stack pointers.

Example

ESPAsyncTCP add prototype takes a char*

size_t add(const char* data, size_t size, uint8_t apiflags=0);//add for sending

It then passes that data * to LwIP

Code such as the next snippet (which is 90% of your library ‘style’) is going to fail. Not “might” or “could” but “absolutely and definitely will” . Your setwill / SSL already proves that, as do the frequent “random” disconnects.

scope / lifetime: stack variables

// @ global scope
AsyncClient*  client=new AsyncClient();
void willCrash(){
  char[] shortlifetime="disaster waiting to happen";
  client->add(shortlifetime);
 client->send(); // at an undefined time posibly seconds into the future
} // char array "shortlifetime just disappeared out-of-scope
// yet you just passed it ot a lower level function = disaster

The ONLY reason this works at all on ESP8266 is that by happy accident and accident alone, the stack hasn’t (yet) been trashed by the time LwIP does its actual send - which could be several seconds after your function has exited and released/destroyed and thus invalidated every pointer you just passed down the chain.

Whether, several seconds later the data bears any resemblance at all to the former values is a function of the number and size of LwIP buffers/queue length, the MCU clock, the latency of the network, the underlying ‘system’ code, interrupts etc etc etc -none of which you have any control over. Change any one of them and your code will crash at some point - as it currently does, regularly.

One of those “unlucky” “random” events just so happens to occur when setwill was used. Whatever you think you did to fix just slightly tweaked that list of uncontrollables above and accidentally hid it - till the next time…

Your library is basicially a whole collection of code written excusively in the style of the above snippet. It needs a ground-up rewrite to hold those pointers until the final ACK is received …or make all variables paased to ESPAsyncTCP -> LwIP into globals.

And just in case you still don’t beleive me, take it from the LwIP documentation: