ServiceRemoved triggered too long

[mycrl]

Right now it takes about two minutes for an offline notification to be triggered after a particular service goes offline, how can I reduce this delay?

https://docs.rs/mdns-sd/latest/mdns_sd/struct.ServiceDaemon.html#method.verify

Do I need to actively call this function at regular intervals to verify this?

I may need to get an offline notification immediately after the service goes offline in about two seconds.

Does calling this function frequently put a burden on the network? How does it work internally?

[keepsimple1]

Right now it takes about two minutes for an offline notification to be triggered after a particular service goes offline, how can I reduce this delay?

https://docs.rs/mdns-sd/latest/mdns_sd/struct.ServiceDaemon.html#method.verify

Do I need to actively call this function at regular intervals to verify this?

Yes, this is the right API to call. And you need to actively call it at the interval that fits your need.

I may need to get an offline notification immediately after the service goes offline in about two seconds.

You should pass a duration of 2 seconds as the timeout. (The default is 10 seconds)

Does calling this function frequently put a burden on the network? How does it work internally?

Not much burden unless you call it super frequently (every 2 seconds is okay).

Internally it simply sends out a query (with one retry) for the service records, with a given timeout. When the timeout expires and no responses received from the service, the service is considered offline and ServiceRemoved is sent to the client.

Please let me know your experience of using this recently added API. I'm interested in learning if it works for users, and if not, how can be improved (including doc). Thanks!

[mycrl]

@keepsimple1 I'm not familiar with the mdns protocol, so I'm not quite sure what api's make sense.

But, for now, the scenarios that use mdns are basically for device or service discovery on the LAN, and to support notification of services coming on and going offline.

It would actually be better if a higher level and simpler encapsulation could be provided in addition, but of course, the encapsulation is pretty simple nowadays. But providing a simple api to just do service discovery I don't see a problem with, for example, just passing the name and attributes of the service to register the service. And the other end only needs to look up the specific service name.

By the way, there is one other issue, there is a maximum length limit for the service's attributes, but your documentation doesn't describe it. I checked the source code, you use U8 as the length of the property content, this will limit the content size of the property, this part needs to be described in the documentation.

[keepsimple1]

I think for this issue specifically, if you could let me know if the verify() function works for you, that will be very helpful.

[mycrl]

I misunderstood you.

The api verify is not used by me, I check for drops through other mechanisms. Because I need to exchange some data between devices, all check if they are offline by socket disconnection.

Sorry for not being able to help you.