Closed heweisheng closed 2 years ago
In rfc6762 10.2:
The cache-flush bit MUST NOT ever be set in any shared resource record. To do so would cause all the other shared versions of this resource record with different rdata from different responders to be immediately deleted from all the caches on the network.
https://datatracker.ietf.org/doc/html/rfc6762#section-10.2
may be used share service. such as print or airplay, there are shared resource. I think may be used in share resource. And I don't know when to use the only service
I’m looking into this
I read the RFC more carefully and added a dump mode to the example application to see what other implementation send, and to me it seems only the PTR records are shared records of the types this library currently use.
I've updated the answer functions (answer, announce and goodbye) to make sure PTR records are never sent with cache flush, while unique records are sent with cache flush on announce. This is now consistent with observed data from other implementations.
when I use MDNS_CACHE_FLUSH flag in my mdns service , my new device can replace the older device,and make it lost in android NsdManager,I think don't use it will be better.
my NsdManager log: D/[mdns start]: _jxmirror._tcp. D/[mdns get info]: Desktop-Test-123456789-测试-abcdefg-END D/[mdns lost info]: Desktop-Test-123456789-测试-abcdefg-END D/[mdns get info]: noName
If don't use MDNS_CACHE_FLUSH my log: D/[mdns start]: _jxmirror._tcp. D/[mdns get info]: Desktop-Test-123456789-测试-abcdefg-END W/om.rom1v.sndcp: Accessing hidden method Lmiui/contentcatcher/sdk/ContentCatcherManager;->unregisterContentInjector(Lmiui/contentcatcher/sdk/Token;)V (greylist, linking, allowed) D/[mdns get info]: noName