-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
WifiUDP::stopAll() doesn't not stop classes that implement udpcontext directly. E.g. MDNS causes httpupdater to fail #3296
Comments
So I think i've solved it. MDNS is active during uploads, and causing problems. Adding a stop function to MDNS, and calling it before updating has fixed it, and made downloads a lot quicker:) void MDNSResponder::stop() {
if (_conn) {
_conn->unref();
_conn = nullptr;
}
}
no UDP traffic... @igg what do u think? |
It would appear MDNS in general is active, and with more advanced logging I see all requests across the network for MDNS clients appearing. Adding the stop() function, stops this, and allows updates to progress unhindered. Also exposing the restart function allows it to be restated:) |
Took a while to get to the bottom of this. But basically libs that wish to roll async need to implement udpcontext directly and not use wifiudp, as there is no rx callback.
As it stands the MDNS lib does cause my updates to stutter and sometimes fail. Any thoughts? |
I am not sure that pausing in the upper layers will help. connections need to be freed so the lower layer does not actually process most of the packets |
i guess by pause and resume i mean allow stop to be called which calls https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/include/UdpContext.h#L108, and then have a method that allows restarting of the service. the udpcontext has a disconnect and listen function that should do this. I guess the issue is quite complex. I was thinking of interfacing at the lower layer anyway, at least in udpcontext, as many people seem to roll their own implementation using that instead of WiFiUDP. I am one of those people, preferring to use udpcontext with a callback rather than polling using isavailable() from wifiUDP. My thoughts are that we could allow a callback to be used in wifiUDP, then modify at least MDNS to use that, the WiFiUDP.stopAll() would work with that. plus implement some way of restarting the stopped services. If implementing this alone in WiFiUDP the stop could call alternatively hook in at a lower level and chain together the udpcontext instances rather than the wifiudp. This might get more tricky as higher level classes like WiFiUDP will expect them to still exist, so it will have to be done carefully. e.g. class UdpContext : public SList<WiFiUDP> {
...
}; I'm happy to implement these changes I'm looking for some opinions as to what would be the best. keeping it all in wifiUDP would be best, but there are several libraries that don't use it. e.g. OTAupdater, MDNS, (some of mine). I was also wondering if it could all be put together as part of the WiFi class object. so you could have which contains both wifiUDP and wifiClient instances. WiFi.stopAllClients() --> calls unref()
WiFi.resumeAllClients() --> called restart(); |
Ok i've made a pull request with some ideas i've mentioned.
|
@igrr any thoughts on this pull request? I've been using it for a while with no issues, and uploads are certainly much much smoother (especially if you have a lot of ESPs generating MDNS traffic) on your network. |
#3305 was closed, should we close this one too ? |
Why was #3305 closed and the branch deleted? |
Looks like it was me that closed and deleted it... this might have just been an accident as i cleaned up my wild github account. tbh I've not looked into this for a very long time, my job has been a lot of covid ICU this past year and i've had professional exams and a new baby, so there has been very little time to spend on projects. My vague memories of this were that the jumpy updates were due to UDP requesting being fired off especially if the arduino IDE was open. I'm no longer using the arduinoIDE as i use platform for everything. I can't however commit time atm to look into the merge conflicts with #3305, i still have #7696 to sort out! |
Closing as too old and no similar report has been posted since then. |
Using latest git, and most others...
I get the error
When using the HTTP update lib.
In sort it seems that lots of UDP traffic causes it to timeout...
Further investigation shows that this only occurs when using the Arduino IDE and is down to the MDNS being active during the update. I added in the IP and port for each packet, showing they come from all the other devices on the network running mdns.
So is this normal behaviour for MDNS? Should replies be broadcast to everyone? I do not really know anything about MDNS. However, this is currently breaking uploads at least via HTTP...
The text was updated successfully, but these errors were encountered: