DNS-SD/Bonjour discovery definition missing info

[bkp7]

The DNS-SD specification doesn't have anywhere to specify the versions or paths to services advertised.

The provision of a REST API is optional, so the endpoint info doesn't have to be available at http://<>:<>/signalk.

The current detail provided in the Bonjour advert includes a port no. but not versions, ipAddresses or paths, so discovery would not be able to work on a websockets only server for example.

Adding these items to the TXT data will not be possible due to the maximum length of 255 bytes.

An alternative would be to mandate a ws connection at signalk/ in the same way we do for REST, which returns the list of endpoints.

[tkurki]

Isn’t the simplest solution to specify http/rest as mandatory for this and other related issues? Simple, easy and effective. Practically everything that does tcp will do http.

What would be real world case where you would have ws and not http?

[bkp7]

@turki, yes I agree doing that would vastly simplify things. I don't know any real world cases, but there may still be some environments out there that have TCP but no http stack, but why anyone would choose one of those for a signalk server is beyond me. It's certainly not a cost issue.

Currently we explicitly state Signal K producers MAY implement an HTTP API. If we make this compulsory we can simplify the Bonjour advert to only advertise the location of the discovery json and then go from there. It would simplify the duplication currently required in the discovery json and Bonjour message, neither of which are mandatory at the moment.

We might need to say that the HTTP API MUST be implemented if the server implements any protocol using TCP or UDP.

[tkurki]

Accidental close

[bkp7]

@rob42 @timmathews @fabdrol @sumps @sbender9, Does anyone have any issues with making the http interface mandatory on TCP based servers? At least to serve the list of entry points at http://<<host>>:<<port>>/signalk. This proposal would make the discovery process much simpler particularly where the server doesn't present the full suite of options. Are there any real world cases where a server using TCP (eg. MQTT, STOMP, WS) could not implement this?

Currently we have to consider the impact of having either, both, or neither of Bonjour and the entry point list, including how they interact and this is not currently well documented as the documentation assumes the presence of the endpoints list.

If no objections, I suggest changing MAY to SHOULD in v1.x.x and then moving to MUST on the next breaking release.

[bkp7]

It has been clarified in #485 that as of v1 both the REST API and the WS API must be at preset locations and that it is only possible to have one signalk server version running on a particular server. Therefore there is no need for bonjour to specify the location of these services. It does however need to specify the version, but we could easily accommodate this by stating that the default is v1 unless another version is specified.

There is a valid case for allowing a TCP only server which advertises itself through bonjour (ie. does not require an http server) and uses the signalk streaming protocol over TCP. In this case no application layer (http) protocols would be required.

There are also 2 potential http admin servers we could be referring to: i) the signalk administration server ii) a generic admin server covering all tasks run on the server, of which signalk is just one

So rather than making http mandatory (note that http is not predicated on tcp and is transport agnostic): would it make sense to define the bonjour _http._tcp service as being the server's generic http interface (ie. case ii), and the signalk interface be advertised within the discovery json (signalk-admin-http) and in bonjour (_signalk-admin-http._tcp).

There should also be an additional service identifier in bonjour for tcp (_signalk-tcp._tcp).

[tkurki]

Sorry that my replies are so sporadic, will get better in a few weeks.

But I don’t think this is true that it is only possible to have one signalk server version running on a particular server. The version is part of the http and ws paths to allow coexistence of multiple versions. Continue at #485?

[tkurki]

Accidental close

[bkp7]

@tkurki, what I mean is that as it stands with only v1 in existence, it is only possible to have one version on a server. Technically I suppose you could have multiple versions running on different ports, but there is no way to advertise those to a consumer. eg. if you wanted to run 1.0.1 and 1.0.4 they can't both be advertised under v1. I suppose you could do it one at an IPv4 address and one at an IPv6....

When v2 comes into existence then yes we can have multiple versions and we can also have a different structure under v2 to allow for multiple v2 versions, multiple IPv4/IPv6 addresses, etc. but that is for another day...

I think #485 is a separate issue and I have proposed a PR #494 on the documentation to deal with it.

In this issue I think we are left with: i) should we mandate every server having http with discovery doc at ../signalk ? ii) if not, do we need additional bits in the bonjour discovery?

If we make http mandatory that is a breaking change taking us to v2 anyway, so that leaves point ii).

[tkurki]

Technically I suppose you could have multiple versions running on different ports, but there is no way to advertise those to a consumer. eg. if you wanted to run 1.0.1 and 1.0.4 they can't both be advertised under v1. I suppose you could do it one at an IPv4 address and one at an IPv6....

I don't think that this is true. DNS-SD/Bonjour advertisements are independent of each other, with the current node server you could have multiple servers running concurrently on different ports with different versions and they would just independently advertise their services.

But this is not really related to the original question.

[tkurki]

The current detail provided in the Bonjour advert includes a port no. but not versions, ipAddresses or paths, so discovery would not be able to work on a websockets only server for example.

I do not think going out of our way to support websocket only servers makes any sense. Websocket connections start as http connection, so in practise all ws servers are http servers to an extent.

If you feel that we need to state explicitly that if you support websockets you must support http and discovery I don't think that is a change that breaks backwards compatibility. To me this is baked into the current specification and if not should be corrected.

[tkurki]

There should also be an additional service identifier in bonjour for tcp (_signalk-tcp._tcp).

Tcp-only server support is an independent issue imho.

I think it only needs the service identifier, as a client can find the version from the server's hello message.

SK over tcp is a bit underspecified: ws connection starts with self subscription by default and you can subscribe to all or none by url, but there is no url to carry this information.

Imho a sk over tcp connection should start with none. If I am not mistaken current node server tcp works like ws with no subscribe parameters, selfthat is.