esp-nimble-cpp icon indicating copy to clipboard operation
esp-nimble-cpp copied to clipboard

NimBLEDevice::getDisconnectedClient returns currently connecting clients

Open dcodeIO opened this issue 10 months ago • 2 comments

When performing a pClient->connect, while the client is still (asynchronously) connecting, it appears that calling NimBLEDevice::getDisconnectedClient() can return the still connecting client as it doesn't yet have a connection handle.

Found this while trying to reuse client objects, and I am wondering if this particular behavior is expected?

dcodeIO avatar May 20 '25 21:05 dcodeIO

Hello @dcodeIO, this could go either way and is a bit of an oversight. The trouble is that the client returned is not connected even though it's trying to, though it may not succeed so this is valid. The other issue is that only one connection attempt can be initiated at once, so trying to get another instance of a client and doing something with it would likely fail as well. What would you like to see happen in this case?

h2zero avatar May 21 '25 13:05 h2zero

Hey @h2zero, thanks. I was basing my code on this example where NimBLEDevice::getDisconnectedClient() is used to reuse clients properly. Indeed, I was initially trying to connect to multiple devices simultaneously, but quickly figured that this isn't possible as you note, in the process discovering that the currently connecting pClient's peer address became unexpectedly overwritten. On the background of the example, my expectation would have been that NimBLEDevice::getDisconnectedClient() only returns a client when it is not actively doing something.

As a workaround, I switched to enabling self-delete (which led me to discover #336), and replaced NimBLEDevice::getDisconnectedClient() with NimBLEDevice::createClient as it won't return non-deleted clients.

Not sure what'd be best. Perhaps updating the example, or adding a dedicated getReusableClient API, or changing the behavior?

dcodeIO avatar May 21 '25 14:05 dcodeIO