ESP8266 Community Forum

In the ESP SDK there is a function called "espconn_regist_reconcb" which some folks think is an awfully bad name for what it does. It registers a callback function that is invoked when a TCP connection has failed. For example, if the ESP8266 forms a TCP connection to a partner and then partner is shutdown, the ESP8266 will detect that this has happened and invoke the registered callback function that was registered with "espconn_regist_reconcb".

While contemplating this, a though struck me. If I receive an indication that a connection is now in error ... should I then subsequently issue an "espconn_disconnect" to close the connection?

My thinking here is blurry ... I have assumed that calling "espconn_disconnect" will close a connection and free up ESP8266 resources. But what if the ESP detects that a connection is now bad? Has it already freed up the resources or do I now have to explicitly state that I realize that the connection has failed and it is now ok to forget about it ... as in performing an actual "espconn_disconnect"?

To make matters even grayer, the error callback supplies an indication of the nature of the error. The options include:

ESPCONN_TIMEOUT (-3)
ESPCONN_ABRT (-8)
ESPCONN_RST (-9)
ESPCONN_CLSD (-10)
ESPCONN_CONN (-11) – Failed connecting to a partner
ESPCONN_HANDSHAKE (-28)
ESPCONN_PROTO_MSG ??

Do some of these need explicit closing of a connection? None of them? All of them?

A mystery (to me). I'd be very interested to hear your own thoughts.

I would have a few thoughts on this although I haven't tried it out myself. First off have you created such a scenario as you described while running wireshark on your network. It'd be interesting to see what the ESP is doing when something like this happens. I'm no expert in TCP traffic but I believe that most devices will send a Close and or Reset when they want to leave a connection with a device even if it's because the other device has dropped the connection (excluding the first device sending the close). Depending on what the ESP is pushing out when something like this happens it's very possible that the ESP is running the disconnect command without the user defined callback specifying.

Not really an answer I know but if you have a setup for testing this you should be able to get your answer with some wireshark traces.