Subject: [core] Blockwise transfers in CoAP

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Aug 2012 09:58:24 -0400

I was reading draft-borman-core-coap-block-08.
I find that I'm having difficulty understanding the why of this.

A claim is made that this protocol reduces all server state (and I
guess, moves this to the client).  The argument is made that this is
useful for things like firmware updates.

I'm trying to understand this: for this to be useful, the machine
being updated (receiving the new firmware) would have to be the
server.

I'm trying to understand coap-block in comparison to
  a) running TCP with minimal window-size (which Contiki
     does just fine)
  b) TFTP

It seems to me that the major advantage of CoAP block protocol is that
it reuses the CoAP code, but how much?  What I'm wondering is, if
TCP does not fit, does the CoAP block mode client side state fit?

For the firmware upload use case situation, where all the complexity is
on the maintenance machine doing the upload (a laptop or other
non-constrained gateway), and the sensor has enough ram and/or flash to
double buffer the upload. and CRC/check-signature the entire amount..
this method, seems to work just fine.  But all the machines I've worked
on recently that had the double-buffer space for firmware uploads,
did just fine with an HTTP POST over TCP...

The examples include a POST to /soap, with a multi-packet reply.
(some implication that SOAP might be in use...)

-- 
Michael Richardson
-at the cottage-

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Aug 2012 18:14:55 +0300

The reduction in server state is most pronounced for blockwise access to large resources via GET.  The main application for class-1 devices is likely to be enabling access to the resource description.  Block1 (the support for PUT/POST) is mostly there for symmetry; I'd expect this to be implemented less than Block2 (GET support); but there even is a stateless PUT if you need it.  I trust you haven't looked at TFTP too recently; this is a terrible protocol. Most of what you say points out that, indeed, the editorial rewrite is needed.

Sent from Mobile

On 20.08.2012, at 16:58, Michael Richardson <[email-masked]> wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core