René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RFC 6762/10.4 Cache Flush on Failure Indication","articleBody":"Is there a mechanism to indicate to `Zeroconf`/`AsyncZeroconf` or `ServiceBrowser`/`AsyncServiceBrowser` that a cache entry might be stale, based on application level failures on connecting to advertised services?\r\n\r\nhttps://datatracker.ietf.org/doc/html/rfc6762#section-10.4\r\n\r\n\u003e    The software implementing the Multicast DNS resource record cache\r\n   should provide a mechanism so that clients detecting stale rdata can\r\n   inform the cache.\r\n\r\n\u003e  When the cache receives this hint that it should reconfirm some\r\n   record, it MUST issue two or more queries for the resource record in\r\n   dispute.  If no response is received within ten seconds, then, even\r\n   though its TTL may indicate that it is not yet due to expire, that\r\n   record SHOULD be promptly flushed from the cache.\r\n\r\nSo it looks like an optional feature according to the RFC, but would be nice to have (if it's not there already, I'm new to this library).","author":{"url":"https://github.com/lenard-mosys","@type":"Person","name":"lenard-mosys"},"datePublished":"2024-09-20T09:38:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/1413/python-zeroconf/issues/1413"}