HTTP is ok for Web, but for WoT (Web-Of-Things) it cannot be HTTP but WoT still would need a Req/Res paradigm. The answer is UDP based light weight CoAP.

CoAP (Constrained Application Protocol) is a specialized wire protocol which is built on top of UDP to provide HTTP/REST like Req/Res paradigm for constrained devices. Basing on UDP saves a lot of protocol overhead but the layer built on top of that makes CoAP much more reliable than UDP (stack below) .This was built by the CoRE group (CoRE – Constrained RESTful environment) keeping the lossy and low power networks which IoT devices will always be connected to. Look up the specification (link below) to understand the actual definition of a constrained device / environment. CoAP supports key web concepts like URIs and Internet media types, pretty much you can do everything you did  with HTTP and few extra cool features. Well, I am excited.

Go ahead, check out the CoAP IETF specification here.

CoAP stack

HTTP vs CoAP

WS4D

WS4D is a initiative to enable Web services for devices/sensors leveraging multiple different protocols. This initiative typically targets application domains of industrial automation, home entertainment, automotive systems and telecommunication systems. One of the chosen protocols is CoAP. As a part of this initiative toolkits and software stacks or SDKs are developed and made available for general use. One such stack is WS4D-jCoAP.

Here is a list of CoAP implementations for Constrained devices, servers and mobiles.

So how this works ?

Giving the devices the ability to do “Request/Response” opens lot of new possibilities.  Typical Constrained targets are in the increasing order of Constrainedness *.

1. Mobile phone with data plans. (Even though these aren’t actually targeted use cases)

2. Sensors which can talk IP protocols directly. (i.e Sensors with data plans)

3 .Sensors which cannot talk IP protocols and use IoT gateways to connect to Internet.

Depending on the type of applications even smartphones can be constrained. Think about the scenario of a field service technician doing work order service with a Mobile  phone all day long and chances are he could get into subterranean regions where network is not so good. So in cases like this even HTTP can prove to be NOT so very battery efficient and network efficient. CoAP with the same HTTP  communication style looks appropriate.

But still it may not convince a lot of us to spend the time to change wire protocol of working mobile apps and server applications in production. WS4D-jCoAP comes with a great feature, a HTTP-CoAP 2-way proxy.

WS4D-jCoAP HTTP-CoAP 2-way proxy

So your existing server side can remain the same, you just have to run a CoAP server along side your HTTP server. Your client will be calling the CoAP server instead of the HTTP server directly to ensure CoAP is the actual  wire protocol. Of Course the client should pass the actual HTTP endpoint details to the Proxy server.

Test drive

Go ahead and download the WS4D-jCoAP source from Gitlab. We only need  the ws4d-jcoap-applications, ws4d-coap projects. I am going to show how to run a CoAP client to access a HTTP node service via CoAP-HTTP Proxy. It is a very simple interaction, see below.

Client.java (This is the CoAP client in the sequence diagram)

import org.ws4d.coap.Constants;
import org.ws4d.coap.interfaces.CoapChannelManager;
import org.ws4d.coap.interfaces.CoapRequest;
import org.ws4d.coap.messages.CoapRequestCode;
import org.ws4d.coap.messages.CoapMediaType;

public class Client {

	private static final String SERVER_ADDRESS = "localhost";
	private static final int PORT = Constants.COAP_DEFAULT_PORT;
	CoapChannelManager channelManager = null;

	public void run(){
		
		// Starting client
		BasicCoapClient client = new BasicCoapClient(SERVER_ADDRESS, PORT);
		boolean connected = client.connect();
		if(connected){
			CoapRequest coapRequest = client.createRequest(true, CoapRequestCode.POST);
			coapRequest.setPayload("Echo it back Server");
			coapRequest.setContentType(CoapMediaType.octet_stream);
			coapRequest.setToken("ABDC".getBytes());
			coapRequest.setUriHost(SERVER_ADDRESS);
			coapRequest.setUriPort(PORT);
			coapRequest.setUriPath("/test/light");
			coapRequest.setProxyUri("http://localhost:7070/test/light");
			client.sendRequest(coapRequest);
		}
	}
	
	public static void main(String arg[]){
		example obj = new example();
		obj.run();
	}


}

Proxy.java (This will start proxy CoAP server, client and proxy HTTP  server and client)

This code is available as a part of your applications project, you can just use it.

HTTPServer.js (This is the Node HTTP Server in the sequence diagram)

//Lets require/import the HTTP module
var http = require('http');
var dispatcher = require('httpdispatcher');

//Lets define a port we want to listen to
const PORT=7070; 

//Lets use our dispatcher
function handleRequest(request, response){
    try {
        //log the request on console
        console.log(request.url);
        //Disptach
        dispatcher.dispatch(request, response);
    } catch(err) {
        console.log(err);
    }
}

dispatcher.setStatic('resources');

//A sample POST request
dispatcher.onPost("/test/light", function(req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Echo');
});


//Create a server
var server = http.createServer(handleRequest);

//Lets start our server
server.listen(PORT, function(){
    //Callback triggered when server is successfully listening. Hurray!
    console.log("Server listening on: http://localhost:%s", PORT);
});

Application Areas

• Gartner In 2020, 25 Billion Connected “Things” Will Be in Use, If a human population of much less people than this needed a social setup with Facebooks, twitters and Whatsapp , definitely things will need a social setup to chat and socialise (this might sound weird). Think about building a chat application like whatsapp for both h2m (human to machine) and m2m (machine to machine) chat. You could configure or health-check sensors with a nice chat app. For instance you say “How are you ? “ the sensor would come back with a full list of diagnostic codes like “Battery level: 65%, Current temp: 70,  status: working…”