Open wesleytodd opened 8 years ago
@wesleytodd thanks for reporting this. I'm not using subtypes my self, so I most likely didn't implement it correctly. Thanks for pointing me to the subtypes docs :smiley:
In regards to the three DNS records types, they are described in DNS-SD (RFC 6763). This is one of the two core RFC's at the root of the Bonjour/Zeroconf standard - the other being RFC 6762.
From the RFC 6763 Introduction:
A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "
. ", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs.
In other words:
Awesome, those links and your description are exactly what I needed. I will take a look at making a pull request for this and let you know sometime today. Thanks, and great work on the module!!
@wesleytodd A PR would be great, thanks :) FYI, I'm just about to merge the v3.0.0 branch into master which adds discovery support but contains a few breaking changes. If you create a PR, do your self a favour and base it on that branch if I haven't merged it into master before that.
For sure, I was planning on making it against the 3.x branch anyway. I just updated my little project to use that branch so I even have an integration to test against.
Question: Should find only emit when it matches ALL subtypes or should it emit once for each matched subtype?
Example:
bonjour.publish({
// ...
subtypes: ['foo']
});
bonjour.publish({
// ...
subtypes: ['bar']
});
bonjour.find({
// ...
subtypes: ['foo', 'bar']
}).on('up', function() {
// once or twice?
});
I think it's going to become really hard to merge responses for multiple subtypes in a consistent manner. My current gut feeling is that we shouldn't allow the user fo query for multiple sub-types at the same time.
Pros for allowing multiple subtypes in a single query:
Cons for allowing multiple subtypes in a single query:
So instead I would consider only allowing one optional subtype per query:
bonjour.find({
type: 'http',
subtype: 'foo'
})
I might have overlooked something here since I'm not that familiar with subtypes, but from reading up on it a little bit this is my suggestion.
Ok, so I think I was wrong on even asking this question. I have been reading through the spec you linked to and I think the method for querying multiple is by querying the parent type and filtering client side. That book says that a query for _http._tcp
should also return results for foo._http._tcp
:
When a full client browses for games to join, it simply browses for the main type
_mynetgame._tcp
and finds all the advertised instances on the network, both open and password-protected
And the spec says this:
"The Server._http._tcp.example.com.", and the advertised web page is still discoverable using a standard browsing query for services of type "_http._tcp"
So with this in mind I think allowing only one subtype query is the ONLY way we should do it. Sound good?
Also, side note, the multicast-dns-service-types
module implements subtypes wrong, so I will have to fix that as well to get it working. Clearly it is not going to get done tonight, but I will keep working on it, possibly after the new year, going out of town :)
Ok, more updates:
Nowhere in the spec or any documentation I can find talk about one service having multiple subtypes. There is also no spec saying it CANNOT have multiple either. Is this maybe a question of how we want to implement this?
If so, I would say we don't support multiple subtypes. Seems overblown and not technically spec'd. Thoughts?
I wouldn't say there's anything wrong with allowing a published service to have multiple subtypes as far as I understand it - but maybe I don't understand the issue you're raising? But as mentioned above I think it's too complicated and too high level to figure out all the subtypes of a service when finding it. So when discovering services, just allow for either no subtype or a single subtype.
Ok, sounds good! Im working on a few features related to the multicast-dns-service-types
module (https://github.com/mafintosh/multicast-dns-service-types/issues/2, https://github.com/mafintosh/multicast-dns-service-types/issues/3, https://github.com/mafintosh/multicast-dns-service-types/issues/4, https://github.com/mafintosh/multicast-dns-service-types/issues/5) and will let you know when those are finished and integrated here.
Any news on this matter ?
Work has really taken my OSS time from me. I have a bunch of work on this that is not complete but I am on my work computer and cant see if I have pushed it all. But I do hope to be albe to get back to this at some point.
Its a shame this doesn't work yet as it would be useful for websocket subtype services
Feel free to take over and finish it up :)
what was the issue with https://github.com/watson/bonjour/pull/21?
As far as I understand https://tools.ietf.org/html/rfc6763#section-7.1 subtypes are just ._
delimited prefix for a service type. In which case service like:
bonjour.publish({ name: 'fritter', type: 'dat', subtypes:['utp'], port: 3000})
Should produce following fqdn
:
fritter._utp._dat._tcp.local
Looks like this is maybe subtypes are not implemented? The service has a property, but it isn't used.
According to this I think it should register an entry for each subtype. I THINK that I can do this despite this being my first time working with the bonjour protocol. But I dont know why there are the three types of records in the first place (
PTR
,SVR
,TXT
). If you can point me in the right direction for that I think I will understand enough to get this working.