Re: Current Practices Freeze

> On 16 Jun 2016, at 09:57, Owen A.R. <Alex.Owen@soton.ac.uk> wrote:
> 
> Hello Matthias,
> 
> I am very much in favour of a WebSockets binding, HTTP/COAP is nowhere near real time enough for the kind of applications I'm doing (UI grade, sub 200ms across multiple devices).
> 
> If I can find the time to add to the document I will, but I don't think I can for a couple of weeks at least. I did want to show my support though.
> 
> BLE and MQTT I could take or leave though. BLE is always going to need to connect to a hub, and by the time you're on the hub you're probably going to need something more lightweight than the TD for embedded devices. And MQTT is far too inflexible to hold up long term (IMO).

This sounds like a misunderstanding.  A modest multi-protocol hub can easily handle small thing descriptions. The thing description essentially tells the hub how to communicate with the embedded IoT devices. The thing description doesn’t need to be held by the IoT device itself, and may instead be retrieved from the cloud following identification of the device using whatever discovery mechanism is appropriate.

200mS is actually pretty loose compared to real-time requirements in smart manufacturing.  There has been a great deal of work on protocols, e.g. EtherCAT (IEC 61158) which offers update times ≤ 100 µs and jitter ≤ 1 µs.

The choice of protocol should be based upon a careful study of the requirements. MQTT as a topic directed pub-sub protocol is fine for some purposes.  Directly connecting an IoT device to the Internet comes at a cost. You need to make it securely software upgradeable for security patches and to follow security best practices.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>