Skip to content
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

Subtypes not working? #1

Open
wesleytodd opened this issue Dec 27, 2015 · 17 comments
Open

Subtypes not working? #1

wesleytodd opened this issue Dec 27, 2015 · 17 comments

Comments

@wesleytodd
Copy link

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
Copy link
Owner

watson commented Dec 27, 2015

@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
Copy link
Author

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
Copy link
Owner

watson commented Dec 27, 2015

@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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

watson commented Dec 28, 2015

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

watson commented Dec 29, 2015

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
Copy link
Author

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
Copy link

Any news on this matter ?

@wesleytodd
Copy link
Author

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.

@MeirionHughes
Copy link

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

@wesleytodd
Copy link
Author

Feel free to take over and finish it up :)

@MeirionHughes
Copy link

what was the issue with #21?

manucorporat pushed a commit to ionic-team/bonjour that referenced this issue Jun 14, 2017
merge latest changes from base repo
manucorporat pushed a commit to ionic-team/bonjour that referenced this issue Jun 14, 2017
Adds PTR records for `_services._dns-sd._udp.local` on every published service.
@Gozala
Copy link

Gozala commented Jul 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants