A Bonsoir service has been lost after 3500ms of discovering

[DJMontanova]

Describe the bug
When I'm trying to discover _webrtc._udp. protocols on my local network, the discovery finds all the devices, but loses them after 3500ms, and re-finds them right after. The problem is that I resolve them when they appear for the first time to get their IP.
When the service is lost and re-found, it is already resolved, but its attributes are scrambled with attributes from another service.

On this image, you can see that the service is found et resolved, with clearly different attributes. After the service is lost and re-found at the bottom of the screen, the attributes are mixed.

To Reproduce
Steps to reproduce the behavior:
It can be reproduced by cloning the example project : https://github.com/Skyost/Bonsoir/tree/master/packages/bonsoir
Broadcast 2 services with the same type and different attributes, and launch a discovery for that type.
Better debug logs while did on an android smartphone due to the debug console.

Expected behavior
I do not want to lose the services after 3500ms.

Smartphone :

• Device: Oppo Find X3 Pro
• OS: Android 14, API 33

[foxik0169]

Hi,

this seems to be related to the usage/implementation of queryTxtRecord(). On each serviceFound event there is a call to queryTxtRecords without needing to resolve the service. When it resolves the TXT records, it produces one serviceLost event and then one serviceFound event after changing the service attributes to the result of the query attempt.

I am not sure what is the intention behind this originally however it's seems to be doing more harm then good as I would like to see only real mdns events (eg. serviceFound and serviceLost are the same as for example when you run avahi-browse).

This queryTxtRecord should either produce different event (something like txtRecordsResolved) or the API should provide a way to disable this query.

Do you have any thoughts about this @Skyost ?

Daniel

[Skyost]

On Android (only), it's impossible to query service properties without resolving them first (see NsdServiceInfo#getAttributes()). Because of this limitation, we need to query TXT records separately when a service is discovered.

How should we handle this? There are two possible approaches:

1. Query TXT records before reporting the service. We could delay reporting the service until TXT records have been retrieved. However, this introduces a delay (up to 2 seconds, due to timeout), meaning the service would only be reported after the query succeeds or fails.

2. Query TXT records asynchronously after discovering the service. Instead of delaying, we perform the TXT record lookup in the background. If the query succeeds, we trigger a service removed / service found sequence to update the service information. This is the approach I've chosen.

Additionally, we can cancel the TXT record resolution if a resolve() call is made in the meantime.

[foxik0169]

Yeah, canceling the TXT resolution when resolve() is called sounds reasonable.

[foxik0169]

That being said, producing serviceLost and serviceFound events still feels not correct - it doesn't represent the reality of the network. Maybe letting the user specify if he wants to run discovery with or without resolving TXT records on start and then when he chooses to resolve TXT records, produce serviceFound event after the TXT record has been resolved.

// edit

Another alternative may be to produce "serviceChanged" events as that seems more appropriate even for real service change events from native implementations.