Propagate TTLs from new messages into the cache. #39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've tried using a few Golang libraries for mDNS in the past couple days. I found https://github.com/grandcat/zeroconf and then this one, and I noticed that this one actually does things with the TTLs returned with mDNS entries. That appears to be because this fork has this commit, which the parent repo doesn't have.
When experimenting with it, I discovered that this updated TTL support doesn't quite work. Specifically,
(*client).mainloop
accumulates new responses into theentries
map, and once it has sent information about a new service to the subscriber, it stores a copy of it in thesentEntries
map. It has code to delete entries from thesentEntries
map once they expire. But if it receives updated information for an entry, it doesn't propagate the newExpiry
time to the entry insentEntries
, so that entry will be missing between the expiry of the original message and when it receives a new message for it.This PR has a simple fix for this - propagate the updated
Expiry
time from any new entries that it receives.I've seen comments in other PRs saying "please submit this to the parent, we don't want to deal with the maintenance burden". As far as I can tell, this issue is specific to your fork, so I think this is the right place to send it. Also, if you don't want it, no worries.