Using QtZeroconf on Android, I've noticed that resuming from suspend would often cause services to disappear even if they should not and it would take up to minutes for them to reappear. I've tracked it down to this code block which removes the service entry if resolving of a service fails:
https://github.com/jbagg/QtZeroConf/blob/master/avahicore.cpp#L206
The problem with this is that it seems to happen frequently when the app is in background, or the display is locked. This does not necessarily mean the other device disappeared. I understand that just removing this may cause situations where a remote service does not respond any more for real.
Not sure what the proper fix would be but I feel like the current situation might be to aggressively removing services, at least for my use case. Perhaps one option could be to pass the remove reason (eg. serviceUnregistered/resolveFailed). Or maybe not removing the service but just flagging the resolve failure in a property?
I suppose the same goes for avahiclient, but on systems with an actual avahi running presumably this happens way less often.
Using QtZeroconf on Android, I've noticed that resuming from suspend would often cause services to disappear even if they should not and it would take up to minutes for them to reappear. I've tracked it down to this code block which removes the service entry if resolving of a service fails:
https://github.com/jbagg/QtZeroConf/blob/master/avahicore.cpp#L206
The problem with this is that it seems to happen frequently when the app is in background, or the display is locked. This does not necessarily mean the other device disappeared. I understand that just removing this may cause situations where a remote service does not respond any more for real.
Not sure what the proper fix would be but I feel like the current situation might be to aggressively removing services, at least for my use case. Perhaps one option could be to pass the remove reason (eg. serviceUnregistered/resolveFailed). Or maybe not removing the service but just flagging the resolve failure in a property?
I suppose the same goes for avahiclient, but on systems with an actual avahi running presumably this happens way less often.