Subtypes not working? about bonjour HOT 17 OPEN

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

from bonjour.

@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

from bonjour.

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

from bonjour.

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

from bonjour.

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.

from bonjour.

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

from bonjour.

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.

from bonjour.

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?

from bonjour.

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

from bonjour.

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?

from bonjour.

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.

from bonjour.

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.

from bonjour.

Any news on this matter ?

from bonjour.

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.

from bonjour.

Its a shame this doesn't work yet as it would be useful for websocket subtype services

from bonjour.

Feel free to take over and finish it up :)

from bonjour.

what was the issue with #21?

from bonjour.