Sending SK deltas in datagrams (UDP)

[jboynes]

Define the protocol for sending SK messages using an unreliable, unordered, packet oriented transport such as UDP. Simple applications include:

• sensor devices broadcasting data updates
• sending updates to many clients using a vessel-local multicast topic

[sumps]

It is fairly simple to use UDP for Deltas. The maximum IPv4 UDP packet size excluding headers is 65,507 bytes, so you have plenty of room to have one complete Signal K Delta Message per packet, so no need for error checking but time stamps should be mandated and then the receiving device can put them in time order. In my experience on a modern LAN onboard a boat, there are no major problems using UDP.

[jboynes]

Suggest a couple of constraints:

• a datagram must contain exactly one JSON object (the sender should combine values as needed)
• the JSON must be encoded using UTF-8
• the SK message must identify the original source(s) of the data

The intent of the last one is that the receiver should not rely on the datagram's source IP address to identify the sender as those can change over time (e.g. after DHCP lease renewal) or be modified en-route (e.g. by NAT). Instead, it must rely on the SK device identifier based on what we define in #288.

[jboynes]

We should define a way to protect the datagrams when sent over an open network. With stream transports like TCP or WebSocket, the stream can be protected by authentication and encryption at the transport level e.g. using TLS v1.2. We can recommend a similar approach here (e.g. DTLS) or could take a JSON-specific approach like JWE.

[toqduj]

I thought MQTT or STOMP was recommended for the sending of deltas?

[jboynes]

MQTT "runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections." It is not designed for unreliable, unordered transports like UDP. Same for STOMP. They rely on a message broker for distributing messages rather than doing it at the network layer. There are pros and cons for both approaches, this issue is meant to discuss the latter.

[toqduj]

Ah, thanks for the clarification. I knew I must have missed something.

On Tue, Nov 8, 2016 at 4:23 PM, Jeremy Boynes notifications@github.com wrote:

MQTT http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html "runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections." It is not designed for unreliable, unordered transports like UDP. Same for STOMP https://stomp.github.io/stomp-specification-1.2.html. They rely on a message broker for distributing messages rather than doing it at the network layer. There are pros and cons for both approaches, this issue is meant to discuss the latter.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/289#issuecomment-259165803, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyazRDUdfvWCqh5X6FbayC9bT82Cbks5q8JPigaJpZM4KrZG0 .