Hello,
On 12/04/17 07:04, Carsten Bormann wrote:
On Apr 12, 2017, at 04:42, Mark Nottingham <mnot@xxxxxxxx> wrote:
So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.
Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.
I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case. (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)
Carsten's right. The primary use case which motivated us to undertake
the work were for browser access, and for sandboxed web applications
that want to use CoAP-based communication to a end-point, but are
restricted from using system-level APIs such as TCP or UDP socket
libraries. Matthias (in a forked version of this message thread) also
mentioned where we saw benefits in allowing CoAP over Websockets to
reach constrained devices.
While the work was progressing however, we did become aware of minor use
cases where using CoAP over Websockets can provide an advantage:
Reaching constrained nodes residing in domains where end users may lack
the authority to configure middleboxes to allow new services over
TCP/UDP. This is commonplace in particularly restrictive and firewalled
networks that otherwise allow traditional messaging, email and web-based
services. However, I need to emphasise this is a minor use case.
Best regards,
Bill