Closed timoxley closed 10 years ago
if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size.
- CoAP reliability and congestion control measures are minimal vs those of TCP
That is not entirely true: CoAP can run on larger payload using blockwise transfers, but they are not yet implemented (see #3). If you want to give them a go, I'd be very grateful!
As far as reliability is concerned, I'd say that if something goes wrong, the latency of recovering is high (in contrast with TCP). There are retries (four in total) involved, and the first one is after ~1sec and the last one after around ~45sec. So, it is less reliable, but it somewhat reliable.
CoAP also specifies to throw an error if the message size is > 1280. This library respect that.
With such low-reliability, why is CoAP said to be designed for Lossy networks? (http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols/)
CoAP intend to bring Web-like service over low-power / loosy network, like 802.15.4, etc. To bring CoAP and HTTP together, a coap-http proxy/gateway needed.
@heri16 in fact, low-reliability is much better on lossy networks. TCP enforces retransmissions in case of a packet loss. UDP on the other end leaves that choice to the developer. CoAP has a typical retransmission scheme with exponential backoff.
:+1:
:dancers:
As far as I can tell, CoAP seems like a far more flexible, minimal version of HTTP (in terms of functionality), what can HTTP do that CoAP cannot?
One obvious thing was the ability to reuse a connection via keep-alive, but what else? Specifically, what are CoAPs drawbacks (other than support)? Why not transition away from HTTP and use CoAP for everything?
This question isn't specific to
node-coap
, it's a general question about CoAP, but I figure rather than asking privately I'd ask here so someone else may stumble upon it. If you'd prefer to not have such things in the issue queue, let me know and I will not repeat!