-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v0.9.0 #254
Conversation
on ESP32 this is already default behaviour in the AsyncTCP library. On ESP8266 the copy flag was absent by default so adding here.
- trigger disconnect after a long period of inactivity from server - When we call disconnect() without force condition, then if client space is less, it wont disconnect. Because it calls sendDisconnect(). - calling disconnect(); for disconnecting due to no server activity isn't enough. Sometimes, if multiple .connect() is called and some packets are lost in the internet and arrives later. A situation occurs such that, the tcp has been closed and hence pcb is equals to NULL. While the library still think its connected necause the onConnect callback is called a little later. In Such situation _client.close(); will not do anything since pcb is null, so onDisconnect callback wont be called either. So we also have to call _clear() manually.
have separate classes for outgoing packets
- add outgoing messages in queue - fix initializer list - add logging - add simple "mutex" for ESP8266 - fix timeout disconnect in inPoll - add state (not only "connected")
* add Github Actions * fix linting
* reorder * update deps
fixes #226
- LWIP always adds the COPY flag on ESP8266 and ESP32 so there is no need for this lib to keep data until acked. This also means we don't suffer from the "ack handler doesn't fire"-bug in ESPAsyncTCP and can have the tcp-client as member instead of as pointer. - Since we're only sending one packet at a time, and don't have to wait for the ACK, we no longer need the pointer to the packet in process - renamed some vars to be more "mainstream"
fix packetId remove virtual call minor formatting
Add TCP timeout on connecting
* remove unused travis config * bump copyright year
* Add clearQueue function * Update Docs * Bump versions
Squash or not? Although there are some spurious commits, imo there are too many commits to squash them all together. On the other hand, commit history is also in the develop branch. |
go for it! |
I did some quick tests on ESP8266 with the newest develop branch (uptime 6 hours so far) - for me it's green light... |
I've been running on the ESP32 for ~20hrs...not a glitch |
I switched one of my devices to the develop branch (had it on a few test projects so far) and it's been working fine for a day and a half now. |
Squash? |
I think squash is fine in this case. Looks tidier on main and every single commit is still preserved on develop |
No description provided.