Subtypes not working?

[wesleytodd]

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.

[watson]

@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 😃

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:

• The PTR record makes it easy to discover SRV/TXT record pairs of a given type (e.g. all printers or all http servers)
• The SRV record points to the host and port where to find the service
• The TXT record can be empty (but must be supplied) and can hold any extra meta data about the service

[wesleytodd]

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!!

[watson]

@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.

[wesleytodd]

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.

[wesleytodd]

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?
});

[watson]

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:

• It's a convince for the user to optionally query fro multiple subtypes

Cons for allowing multiple subtypes in a single query:

• The underlying mdns query logic becomes a more complicated as you can technically not query for more than one subtype at a time (as far as I understand it), so you'd have to submit one query per subtype behind the scenes
• Merging multiple responses to different subtypes becomes a nightmare

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.

[wesleytodd]

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?

[wesleytodd]

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 :)

[wesleytodd]

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?

[watson]

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.

[wesleytodd]

Ok, sounds good! Im working on a few features related to the multicast-dns-service-types module (mafintosh/multicast-dns-service-types#2, mafintosh/multicast-dns-service-types#3, mafintosh/multicast-dns-service-types#4, mafintosh/multicast-dns-service-types#5) and will let you know when those are finished and integrated here.

[quentin-ol]

Any news on this matter ?

[wesleytodd]

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.