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

Hi Johannes,

Se below.

Claes



Claes Nilsson
Master Engineer - Web Research
Research&Incubation

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com

sonymobile.com



> -----Original Message-----
> From: Hund, Johannes [mailto:johannes.hund@siemens.com]
> Sent: den 15 september 2015 11:00
> To: Nilsson, Claes1; 'Carsten Bormann'
> Cc: public-wot-ig@w3.org
> Subject: AW: [TF-AP]: Using CoAP for bi-directional communication
> 
> 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.
[Claes] Yes, I think we have use cases for this, i.e. use cases that require an IoT device respond to REST calls "anytime".

> 
> 
> > 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.
[Claes] We have been experimenting with CoAP over UDP, E2E cloud server to IoT device. The IoT device is behind a firewall/NAT and by keep-alive messages from the device to the server we keep the NAT open for incoming messages from the server. 
> 
> 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 16:36:48 UTC