The only tricky thing is that when you receive a disconnect or recon callback the espconn argument will have the reverse field properly set to point to your struct, but your struct's forward pointer to the espconn will be incorrect at that point (which doesn't matter much 'cause you can't do anything to the connection anymore anyway).
This is really correct and unfortunately I have learned it in a hard way.
The struct espconn pointer comes along with the disconnect or reconnect callback is indeed the espconn of the TCP server that you has created to "listen" for incoming TCP connection (called tcpServerEspconn hereafter), rather than the espconn of the "accepted" TCP connection (called acceptEspconn hereafter). But when the time to dismantle the accepted TCP connection comes, several parameters, including the reverse pointer, are copied from the acceptEspconn to tcpServerEspconn before destroying the acceptEspconn internally and calling the disconnect/reconnect callbacks.
So it is safe to keep acceptEspconn and use it to send/receive/etc until disconnect/reconnect callback is made. In those callbacks, the acceptEspconn pointer is no longer valid, and the most convenient way to find your data structure (where a reference of acceptEspconn is kept) is to use the reverse pointer, which you must set (very likely in the connect callback) when you first made a reference of acceptEspconn.Statistics: Posted by ming — Sun Aug 02, 2015 10:15 am
]]>