Skip to content
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

Merged
merged 40 commits into from
Jul 25, 2021
Merged

v0.9.0 #254

merged 40 commits into from
Jul 25, 2021

Conversation

bertmelis
Copy link
Contributor

No description provided.

bertmelis and others added 30 commits December 11, 2020 16:11
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
cleanup before implementing queue
- 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")
remove unused std::vector
* add Github Actions
* fix linting
* reorder
* update deps
- 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"
bertmelis and others added 10 commits February 25, 2021 11:27
@bertmelis bertmelis requested a review from luebbe July 23, 2021 09:37
@bertmelis
Copy link
Contributor Author

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.

@proddy
Copy link

proddy commented Jul 24, 2021

go for it!

@Pablo2048
Copy link
Contributor

I did some quick tests on ESP8266 with the newest develop branch (uptime 6 hours so far) - for me it's green light...

@proddy
Copy link

proddy commented Jul 24, 2021

I've been running on the ESP32 for ~20hrs...not a glitch

@luebbe
Copy link
Collaborator

luebbe commented Jul 25, 2021

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.
Green light from me for the functionality. I didn't review the code in detail, but the few snippets I looked at during the "making of" all looked plausible to me.

@bertmelis
Copy link
Contributor Author

Squash?

@luebbe
Copy link
Collaborator

luebbe commented Jul 25, 2021

I think squash is fine in this case. Looks tidier on main and every single commit is still preserved on develop

@bertmelis bertmelis merged commit e9b3966 into master Jul 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants