On Apr 12, 2017, at 04:42, Mark Nottingham <mnot(_at_)mnot(_dot_)net> 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.)
Also, the assertions about firewalls are interesting; we're hearing very
different assertions in the discussions of QUIC (e.g,. 90%+ success rates for
UDP protocols).
Apart from the backend motivation, the main motivation for CoAP over TCP was
easier NAT traversal (UDP bindings are timed out much faster in most NATs).
This may extend to other middleboxes, including firewalls that build (and then
time out) UDP-based state.
I’m not sure the QUIC numbers transfer to this use case very well, as QUIC is
mostly used for web page access from browsers, so short NAT binding timeouts
don’t matter that much. For a sensor that needs to be accessed every 30
minutes, these are much more of an issue.
Grüße, Carsten