Closed matejk closed 4 years ago
This effectively reverts back to c286fcd. We need the QSocketNotifier so that when the service's IP address changes, we get notified. I suspect if you run with this patch and change the IP address on one of the devices, the IP address in bonjour will not update in the other. On Linux QSocketNotifier boils down to adding a file descriptor to poll() and it can be tricky not to miss an event when setting up the poll(). Maybe we can try calling addressReady() after the QSocketNotifier is setup as it looks like the event is getting dropped. Can you test this?
This effectively reverts back to c286fcd.
Not really. The code that I removed is there since the first version.
I did additional tests:
Test | jbagg master | bonjour-start-stop-fix | Discovery/dns-sd |
---|---|---|---|
service down | Pass | Pass | Pass |
service up | Fail | Pass | Pass |
ifconfig down | Fail | Fail | Fail (not detected) |
ifconfig up | Pass | Fail (browse callback not called) | Fail (no visible reaction) |
ifconfig change IP | only first change | Fail (browse callback not called) | Fail (no visible reaction, proper IP when expanded in the UI) |
client remove eth | Pass | Pass | Pass |
client enable wifi | Fail (browse callback called) | Pass | Pass |
I do not use IP addresses in my application, only hostnames from DNS-SD and they always get properly resolved when used also when the IP changes. Therefore reacting on IP change is redundant in my use cases.
I was able to restore my mac finally. Turns out you can no longer download a OSX installer unless you own another MAC. I was able to reproduce the issue right away. I pushed a fix in commit d346cd78a708a1e85c8af4027ad4a32ad9b54652
Environment: macOS 10.13
Test case:
I started the application that uses QtZeroConf. It properly detected all services on startup. I kept the application running.
While testing service stop and start on another embedded device on the same network I discovered that QtZeroConf properly detects when a service is removed, however it does not detect (or very seldom) when the service is started again.
I analysed the issue and resolved it by replacing event from the socket with direct call to resolver in two places.
Stop and start of a service is reliably detected every time.