Bindings To Common Protocols

From Web of Things Interest Group
  • Standard protocol bindings will free web developers from needing to deal with transport protocol variations across servers

This work item will define a set of standard protocol bindings for Web of Things data models, e.g. messages for registering and unregistering proxies, event notifications, property and metadata updates, action invocations and responses. The protocols should include commonly used protocols for constrained devices and Internet servers, e.g. HTTP, Web Sockets, CoAP, MQTT and XMPP.

HTTP

The standard protocol for accessing Web resources, e.g. HTML pages. It is also widely used for serving data, e.g. using RESTful APIs layered on top of HTTP. One limitation of HTTP is its client-server model. This makes it awkward for servers to push notifications to clients. Work arounds include polling and extended duration HTTP connections. HTTP is one of the few protocols that can be used from web page scripts. For server to server communication asynchronous communication is straightforward since each server can act as a client to open a connection to the other server. This technique doesn't work when one server is hidden behind a firewall.

Web Sockets

An evolution from HTTP to support asynchronous messages between two parties. Web Sockets is frequently used with JSON based messages due to the ease with which application services can be constructed. Web Sockets is one of the few protocols that can be used from web page scripts. The asynchronous nature of Web Sockets makes it popular when it comes to establishing a bidirectional messaging channel between two parties when one is behind a firewall and the other is on the public Internet. In this situation, the party behind the firewall initiates the connection with the party on the public Internet.

CoAP

This can be considered as a HTTP over UDP for resource constrained devices. CoAP borrows ideas from HTTP, e.g. links to related resources. CoAP is considered practical on devices with at least 10 Kbytes RAM and 100 Kbytes of secondary storage (e.g. Flash). Like HTTP, a client behind a firewall can open a session with a server that is on the public Internet. CoAP also includes support for pub-sub, so once the session is open, the external server can push notifications in response the original subscribe request. Complications include inactivity timeouts in firewalls, and the fact that battery operated IoT devices typically spend a lot of time asleep. Work arounds include the use of powered hubs as gateways, and making the IoT device send a subscribe request immediately it wakes up from sleeping.

MQTT

MQTT is a popular lightweight pub-sub protocol that is based upon reliable channel, typically TCP/IP. It relies on a broker to distribute messages to clients that have registered an interest in messages with a given topic. The architecture scales to an unlimited number of clients unlike protocols such as HTTP, Web Sockets and CoAP.

MQTT-SN is a variant of MQTT that is designed for use with UDP, and is thus suited to low end IoT devices for which TCP is too expensive in its memory demands.

XMPP

XMPP is a popular pub-sub protocol which started life an XML based messaging scheme for chat servers (Jabber). XMPP includes support for negotiation passage through firewalls. XMPP is based upon TCP/IP and hence is not suited to low end IoT devices.

AMQP

AMQP is another messaging protocol with a focus on robustness and which has found use for financial services. There is interest in applying AMQP to the Web of Things for applications where robust message delivery is more important than delivery speed.

See Also

Further information is available at: