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

Add a Things Discovery section #75

Open
benfrancis opened this Issue Mar 14, 2018 · 15 comments

Comments

Projects
None yet
3 participants
@benfrancis
Collaborator

benfrancis commented Mar 14, 2018

Add a section to explain how Thing Descriptions can be discovered. This could include:

  • Via a directory of things like a cloud service or things gateway
  • Via an mDNS broadcast on a local network (see also mozilla-iot/gateway#696)
  • Via a Bluetooth Eddystone beacon broadcast in physical proximity (see also mozilla-iot/gateway#695)

Another possibility is adding HTML link relations to web pages which point to a Thing Description, similar to <link rel="manifest">

@benfrancis

This comment has been minimized.

Collaborator

benfrancis commented Jun 27, 2018

@mrstegeman @hobinjk Would you mind providing a quick overview of how the webthing mDNS broadcasts and Eddystone beacons work to start to put together some wording for this? Currently this isn't documented anywhere.

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Jun 27, 2018

Discovery via mDNS can be done in either of the following ways:

  • Server broadcasts service type _http._tcp, with 2 TXT records:
    • webthing=true
    • url=http://mything.local
  • Server broadcasts service type _http._tcp, subtype _webthing (i.e. _webthing._sub._http._tcp or _http._tcp,_webthing), with 1 TXT record:
    • url=http://mything.local

Discovery via Bluetooth:

  • Server broadcasts a URL-type beacon with the URL being the server's entry point, i.e. http://mything.local.
@phoddie

This comment has been minimized.

phoddie commented Jul 10, 2018

Thanks for the details on the use of mDNS in Web of Things. That's helpful for our current exploration. I understand that this may change later as the specification evolves. A few observations based on a recent review of the mDNS specification and related documents.

The _http._tcp service is intended for providing web pages to a browser. From dns-sd.org:

The meaning of this service type, though called just "http", actually denotes something more precise than just "any data transported using HTTP" The DNS-SD service type "http" should only be used to advertise content that:

  • is served over HTTP,
  • can be displayed by "typical" web browser client software, and
  • is intented primarily to be viewed by a human user.

This suggests that a more specific service type would be preferred, such as _webthing._tcp. Doing so eliminates the need for the webthing=txt entry in the TXT record and removes a filtering step for clients looking only for Web of Things compatible devices.

The url entry in the TXT record specifies an absolute URL (e.g. http://mything.local/description). At zeroconf.org, this practice is not recommended:

The TCP (or UDP) port number of the service, and target host name, are given in the SRV record. This information — target host name and port number — MUST NOT be duplicated using name/value attributes in the TXT record.

The approach described on dns-sd.org for the path entry in the TXT record for _http._tcp services seems applicable here:

generate a URL of the form shown below, where {host} and {port} are obtained from the information in the service's SRV record, and {path} is obtained from the "path" key in the TXT record:

Applying the rule reduces http://mything.local/description to /description. Both this change and the elimination of the webthing TXT entry reduces the size of the mDNS TXT answers, leaving room for future options or merging more mDNS answers into a single packet.

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Jul 10, 2018

@phoddie Thank you for pointing this out, we're in the process of changing over.

Do you know if there is a way to specify that the host is using TLS/HTTPS? The dns-sd spec you pointed out says to build the URL as such:
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

@phoddie

This comment has been minimized.

phoddie commented Jul 11, 2018

When using the _http._tcp service, the current recommendation seems to be to have the HTTP server force an upgrade to HTTPS:

Work is currently being done on adding mechanisms to HTTP and TLS to allow the server to tell the client that it needs to activate TLS on the current connection before proceeding. If this becomes widely adopted, it further justifies the decision to not create a separate DNS-SD service type "_https._tcp", because security becomes just another one of the things that is negotiated on a per-connection basis (like content-type negotiation today) rather than being an entirely separate thing.

If you switch from _http._tcp to your own Web of Thing service type, you can define any rules you like. Still, the host name and port should come from the SRV record as noted above.

I'm no expect on TLS, but I recall there is some challenge in providing certificates for a .local host.

@benfrancis

This comment has been minimized.

Collaborator

benfrancis commented Jul 11, 2018

I'm wondering how in future a Web of Things client might differentiate between things using different protocol bindings (other than HTTP).

I guess a CoAP binding might be advertised as _webthing._udp, but that doesn't leave much room for other protocol bindings which might also use TCP or UDP.

Does mDNS have a way to differentiate, or even to advertise multiple services on different ports?

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Jul 11, 2018

@benfrancis Yes, you'd just set up multiple advertisements.

@phoddie

This comment has been minimized.

phoddie commented Jul 11, 2018

Does mDNS have a way to differentiate, or even to advertise multiple services on different ports?

Yes. You can have as many services as you like on a single device. Many devices do including just about every Mac.

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Oct 15, 2018

As an update to my earlier comment, here is what is currently implemented.


Discovery via mDNS can be done by broadcasting a service as follows:

  • Type: _webthing._tcp
  • TXT record: path=/

Discovery via Bluetooth:

  • Server broadcasts an Eddystone beacon with the URL being the server's entry point, i.e. http://mything.local.
@phoddie

This comment has been minimized.

phoddie commented Oct 18, 2018

Great to see the type change. Is there a reason to continue using an absolute URL in the TXT record?

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Oct 18, 2018

@phoddie We actually did switch to path. My comment was invalid. I will edit it.

@phoddie

This comment has been minimized.

phoddie commented Oct 18, 2018

Oh, great. Is that in the current shipping Gateway?

@mrstegeman

This comment has been minimized.

Contributor

mrstegeman commented Oct 18, 2018

Yes.

@phoddie

This comment has been minimized.

phoddie commented Oct 18, 2018

Excellent. We'll give that a try. Thank you!

@phoddie

This comment has been minimized.

phoddie commented Oct 19, 2018

Spiffy. We just tried the latest Gateway and it works with _webthing._tcp. We also confirmed that it is using the port number from the SRV record. Very cool. Thank you. We'll push an update to our WebThings module for the Moddable SDK to sync with these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment