W3C home > Mailing lists > Public > public-wot-ig@w3.org > September 2015

AW: [TF-AP]: Using CoAP for bi-directional communication

From: Hund, Johannes <johannes.hund@siemens.com>
Date: Tue, 15 Sep 2015 09:00:02 +0000
To: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "'Carsten Bormann'" <cabo@tzi.org>
CC: "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <C271054E16F8474D9104E1146C767BF14E2333@DEFTHW99EK1MSX.ww902.siemens.net>
Hi Claes,
Hello List,

that is a very interesting discussion going on about NAT/FW issues and CoAP.

> if a device is capable of running TCP is the memory and
> processing requirements much lower for CoAP over TCP than using Web Sockets?

Websocket is on top of http which is on top of TCP.

So what you safe by using TCP directly instead of websockets is basically the GET+Upgrade request/response handshake and the Frame markers - if that is much depends on your setup...

I personally see websockets as a way to enable TCP-based communication into browsers and across HTTP proxies. If that is your use case it makes perfect sense to use WS. So often is more the question of integration needs rather than footprint.


> Or is the main architecture for CoAP over TCP a GW running CoAP over TCP on
> the cloud side and CoAP over UDP on the local constrained side?

We often see these kinds of setups in deployments where the Thing-to-Thing communication is handled differently than the Thing-to-Backend. There are always pros and cons to consider. For example, it requires some nodes to have dual stacks for both communication forms, resulting in more implementation and maintenance effort as well as a larger target area. Also intermediaries will introduce a higher round-trip-time and jitter. Thenagain, especially for RESTful architectures, proxies enable you to have shared caches that can boost performance.

If there is a need it is of course valid to have a setup as you mention, that is also the reason why I always try to abstract the interactions to be protocol-independent. CoAP is pretty much transport-independent.

It is however interesting for me to hear the quite different experiences people have with CoAP/UDP and natted firewalls.

On a sidenote: does somebody know if Google is having the same issues with QUIC (which is a TCP-like transport over UDP), or is there some UDP-friendly keep-alive involved (as the driver there seems to be performance, not being lightweight/low-power)?

Best regards,
Johannes
Received on Tuesday, 15 September 2015 09:00:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:45 UTC