-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolver API design #98
Comments
The |
More importantly, it looks like they're clearly "single use only" (i.e., it calls "shutdown" after one use). So I'd either:
|
I'm working on a clean shutdown procedure for the client / resolver, and I'm unsure how to proceed because I'm a bit confused by the API.
To start a mDNS client, you first create a new resolver, and then call
Lookup
orBrowse
:This raises 2 problems:
Browse
andLookup
return immediately. The go routines started by these methods (including the Go routine that reads from the connection) is stopped eventually after the context is done, but there's no way to deterministically tell when this happened.Lookup
/Browse
once perResolver
instance, as both of them start reading from theUDPConn
(and it only makes sense to read from a connection with a single Go routine).I can see 2 fundamentally different ways to resolve this:
Browse
andLookup
can be called multiple times.Resolver
, and exposeBrowse
andLookup
as top-level functions.Browse
andLookup
block until all Go routines have stopped.Browse
andLookup
concurrently. This would require us to have some demultiplexing logic, to associate received message with a particular lookup. This is easy for responses to a query (they come with an ID), but I'm not sure how one would implement this for the unrequested announcements that servers send out regularly.Any thoughts, @grandcat and @Stebalien?
The text was updated successfully, but these errors were encountered: