What Is The Size of Coap Packet

How much data can hold CoAP in single message?

A CoAP implementation usually introduces its own max message size setting (hence a default value).

For more info how to choose the proper limit in a particular case, please refer to point 4.5 of RFC 7252:

[RFC 7252 - The Constrained Application Protocol (CoAP)][1]

Quoting it:

The CoAP specification itself provides only an upper bound to the message size.
Messages larger than an IP packet result in undesirable packet fragmentation.
A CoAP message, appropriately encapsulated, SHOULD fit within a
single IP packet (i.e., avoid IP fragmentation) and (by fitting into
one UDP payload) obviously needs to fit within a single IP datagram.
If the Path MTU is not known for a destination, an IP MTU of 1280
bytes SHOULD be assumed; 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.

Also it depends on network stack implementation:

Implementation Note: CoAP's choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. (However,
with IPv4, it is harder to absolutely ensure that there is no IP
fragmentation. If IPv4 support on unusual networks is a
consideration, implementations may want to limit themselves to
more conservative IPv4 datagram sizes such as 576 bytes; per
[RFC0791], the absolute minimum value of the IP MTU for IPv4 is as
low as 68 bytes, which would leave only 40 bytes minus security
overhead for a UDP payload. Implementations extremely focused on
this problem set might also set the IPv4 DF bit and perform some
form of path MTU discovery [RFC4821]; this should generally be
unnecessary in realistic use cases for CoAP, however.) A more
important kind of fragmentation in many constrained networks is
that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited
to 127 bytes including various overheads); this may motivate
implementations to be frugal in their packet sizes and to move to
block-wise transfers [BLOCK] when approaching three-digit message
sizes.

If you want to send large messages, there is another specification.

[RFC 7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP)][2]

Most of popular implementations implement this specification as well.

  [1]: https://www.rfc-editor.org/rfc/rfc7252
  [2]: https://www.rfc-editor.org/rfc/rfc7959

What are all the options that are set in the copper to coap server using block1 transfer?

Some hints for the parts I understand:

0xb5 other 0x05, block

1. Option 11, len=5, Uri-Path, value "other" (RFC 7252)
2. Option 11, len=5, Uri-Path, value "block" (RFC 7252)

0x10

Option 12, len=0, Content-Format, value 0 (RFC 7252)

0xb1,0x06

Option 23, len=1, Block1, value 0x06 (num=0,m=false,szx=6/1024 bytes) (RFC 7959)

0x41,0xe6

Option 27, len=1, Block2, value 0xe6 (num=14,m=false,szx=6/1024 bytes) (RFC 7959)

I'm thinking about running a COAP system backwards, is this a terrible idea?

Will CoAP Observe work for you?

https://www.rfc-editor.org/rfc/rfc7641#page-4

It is not a part of CoAP RFC but the COAP RFC mentions it and most of mature implementations has the "Observe" RFC implemented as well.

You may combine it with the regular way of requesting.

Also, in one project I've introduced a concept of "session".

It is suitable when you may schedule the sessions or periodic connections is suitable for you, or there is some event which can lead to a session initiation.

Device makes PUT "/session" and CoAP server starts a session and fetches data with GETs or putting something with PUTs. When nothing is remaining to do, the CoAP server sends CON-DELETE "/session" and device goes offline. Sure you need a timeout to force the device to go offline if session close request didn't come for the long time.

Please note: in RFCs a client is a endpoint which does request and server is a endpoint which responds. It can make some confusion. In practice, both the embedded device and a server can act as a client+server the same time.

---

Related Topics