ESP32 WiFiServer.available() not working like Arduino's version

[haddow777]

Hello, I've been pounding my head against a wall lately trying to deal with multiple continuous TCP connections being handled from my ESP32 device. It is claimed that the ESP32 WiFi classes should act like Arduino's versions, but I have come to find that they don't in a way that has been causing me a lot of consternation, and I wanted to check here before filing an issue on GitHub over it. It's possible that the ESP32 team has decided to do it differently intentionally and I just haven't found the reasoning why.

Okay, so here what Arduino says about WiFiServer's server.available method (LINK)

Gets a client that is connected to the server and has data available for reading. The connection persists when the returned client object goes out of scope; you can close it by calling client.stop().

Okay, so according to Arduino, the WiFiServer is supposed to hand over a client that has connected to it when you call this method. You can store it in a WiFiClient variable and manipulate it or get info out of it. The problem I am having is where it says that the server stays connected to the client even when the variable you are storing it in goes out of scope. Basically, what it gave you is just a handle to the real client and it doesn't matter if you lose it, because the Server is maintaining the real client itself.

The problem with the ESP32 version is this doesn't appear to be true. When I look in the WiFiClient.cpp code, it shows the object's deconstructor call stop(), which removes the inner connection to the underlying socket, which then causes the handle deconstructor to be called, which calls close on the underlying socket. I was pulling my hair out for quite a while trying to figure out why my connection kept immediately disconnecting after I just got it when the documentation clearly said it was supposed to be persistent.

Obviously, this isn't the way Arduino set this up to work, but this is an ESP32 library, so I wanted to know. Is this library supposed to reflect the functionality of the original Arduino library or have they decided that Arduino's functionality wasn't in line with how they wanted things done and changed it? Is there documentation anywhere on this to specify? I'm mostly wondering if it would be a waste of their time to put an issue on the libraries Github over it. I don't know the underlying C library very well, but I also wouldn't feel comfortable making changes and submitting code as I have no clue what the maintainers thoughts on how the TCP connections should be handled like. This may be a policy issue more than a bug, although, I will say it acts a lot like a bug.

I can't say I like Arduino's method of having the Server hold onto the connections and only handing over handles. Either you should get direct access to all handles or it should just hand them off to you right as soon as they connect.

[ullixesp]

before you spend more time on this I suggest to use the ASYNC server:
https://github.com/me-no-dev/ESPAsyncWebServer
A bit steeper hurdle to start, but at some point you will need it anyway!

[haddow777]

Thank you for the suggestion. I had seen the library before. There's a couple of things though. First, I am trying to get by with the absolute minimum number of additional libraries. Also, I don't feel the HTTP overhead is necessary for my situation. My design is for basic continuous connections. Why do WebSockets when TCP works the same basically? I know of AsyncTCP as an underlying layer of that library, but I was willing to put up with a little old style code to not include an external library.

Beyond that, it just doesn't seem like a great idea to leave what appears to be a broken library in the standard Arduino library. That is what it is supposed to be, so newer people who are used to Arduino's method of doing things will have major issues. It seems like the least that should be done is to have some documentation spelling out the differences and how to deal with them or to fix it so it is in line with how Arduino's library is documented to work. If there is documentation that does spell that out, maybe someone can point me to it.

[haddow777]

before you spend more time on this I suggest to use the ASYNC server:
https://github.com/me-no-dev/ESPAsyncWebServer
A bit steeper hurdle to start, but at some point you will need it anyway!

Hello again. I just want you to know I looked into it and took up your suggestion. At first, I thought you were merely referring me to the Webserver portion. I looked into the AsyncTCP library more and found it's better. I got confused by the lingo they used, calling it an Async library. I'm too used to languages like Dart and JavaScript where async means a different thing. In this case it seems to mean the network functionality works in a different thread, which is great.

Just to let you know something I recently found out is that the AsyncTCP library doesn't need to be difficult to learn. After a while, admittedly, of pounding my head against the C wall trying to figure out what they were doing with (void*) parameters, I found out that the ESPAsyncTCP repository has example code that is extremely easy to follow. The ServerClient example specifically. That library has extra functionality that the AsyncTCP library doesn't, but that example uses only the files the AsyncTCP library does have.

So, in the future, if you recommend AsyncTCP to anyone, maybe keep in mind to also refer them to those examples. Thanks for the help.