Subject: [core] CoAP Observe over serial

From: Tobias Kaupat <[email-masked]>
Date: Mon, 2 Jan 2017 19:26:51 +0100

Hi all,
I just implemented a basic observe request for my Go CoAP Client over
Serial. (Code @ https://github.com/Lobaro/lobaro-coap)

I have some thoughts where I like to get *confirmation or feedback*.

CoAP by default restricts a Client to have 1 open interaction at the time.
Would you also recommend this for Observes?
Due to simplicity I implemented it the way, that there can be only one
Interaction, which means I can not do any request als long as the observe
is running.

Another implication is, that I can not observe 2 resources at a time. But
since I need to be able to send requests while observing, what would be a
good alternative?

What comes to my mind is:
- CoAP pub/sub (I have not looked into it yet)
- Allow for multiple parallel interactions on client side (makes code more
state-full / complex)
- Polling multiple endpoints (maybe the worst solution)

I guess implementing parallel transactions would be nice in any case. Since
we have no concept of connections or ports, mapping from CoAP messages to
Interactions must fully rely on MessageID and Token? Or do all server
responses carry the Token?

I'm also a bit afraid of loosing resource updates. For some resources I
must be sure not to loose any update. Maybe that's a reason for pub/sub
over observe?

Enough questions for now ;)

Cheers,
Tobias

-- 

Lobaro UG (haftungsbeschränkt)
Tempowerkring 21d
21079 Hamburg

040 / 22816531-0
www.lobaro.de
[email-masked]

USt.-Identifikationsnr.: DE297198645
WEEE-Reg.-Nr. DE18824018

Geschäftsführer: Dipl.-Ing. Tobias Rohde
Sitz der Gesellschaft: Hamburg
Handelsregister: HRB 134264
Amtsgericht Hamburg

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 2 Jan 2017 21:27:05 +0100

Hi Tobias!

Tobias Kaupat wrote:
> CoAP by default restricts a Client to have 1 open interaction at the time. Would you also recommend this for Observes?
> Due to simplicity I implemented it the way, that there can be only one Interaction, which means I can not do any request als long as the observe is running.
>
> Another implication is, that I can not observe 2 resources at a time. But since I need to be able to send requests while observing, what would be a good alternative?

The limits are placed by congestion control and apply to communication
over the Internet. If both client and server and the network
in-between are under your control, you are free to choose whatever
limits make sense for your application and hardware.

> I guess implementing parallel transactions would be nice in any case.

Yes :-) Ignoring message IDs and tokens and just assuming that all
messages belong to the only interaction you started is not a good idea
anyway.

> Since we have no concept of connections or ports, mapping from CoAP messages to Interactions must fully rely on MessageID and Token? Or do all server responses carry the Token?

All responses (including notifications) carry the token of the
request. All acknowledgement and reset messages carry the message ID
of the confirmable message, but do not always carry a token.

I haven't followed the CoAP-over-serial topic; are you doing
acknowledgements and retransmissions over serial? If not, then
checking the token is all you need.

> I'm also a bit afraid of loosing resource updates. For some resources I must be sure not to loose any update. Maybe that's a reason for pub/sub over observe?

Observe follows a best-effort approach. If the resource state does not
change more frequently than you can send notifications (and there are
no proxies involved), then you should receive one notification for
each resource state change. If the resource state however does change
more frequently, then it is not possible that the client receives a
notification for each state change without delay.

Observe addresses this problem by sending only the latest resource
state to the client. If a resource changes and then changes again, it
is permissible that the server sends a notification only for the later
change. This means that all important information needs to be in the
representation of the resource state. The information is not lost when
a notification is lost -- it just reaches the client a little bit
later. Only if the server runs out of storage for new resource state,
it must throw (for example) sensor readings away or start making fewer
sensor readings.

Pub/sub systems usually address the problem by not accepting new
messages when the message queue is full. In this case, a publisher can
buffer messages until the queue becomes less full. Again, the
information is not lost, it just reaches the subscriber a little bit
later. Only if the publisher runs out of storage for new messages, it
must throw sensor readings away or start making fewer sensor readings.

Long story short: You must write code that deals with the case that
not all updates can be sent and code that deals with the case that not
all updates are received. If you like it or not.

Klaus

---

From: Tobias Kaupat <[email-masked]>
Date: Wed, 4 Jan 2017 11:22:13 +0100

Thanks that helped a lot. I just implemented the interaction concept to
handle parallel requests.

One open question, more to CoAP than to observe, but related to my
interactions: In the case of "A GET Request with a Separate Response". *How
long should the client wait for the separate response after the ACK?* I
need some timeout to close my interaction. I would take some reasonable
default value like 10 seconds but can not find anything in the RFC - or did
I missed it?

There might be cases where it would be nice to have a hint from the server
(e.g. in an option in the Ack) and there might be cases where the client
can decide per Endpoint how long to wait. Are there already opinions on
this issue?

Regards,
Tobias

On Mon, Jan 2, 2017 at 9:27 PM, Klaus Hartke <[email-masked]> wrote:

> Hi Tobias!
>
> Tobias Kaupat wrote:
> > CoAP by default restricts a Client to have 1 open interaction at the
> time. Would you also recommend this for Observes?
> > Another implication is, that I can not observe 2 resources at a time.
> But since I need to be able to send requests while observing, what would be
> a good alternative?
>
> > Since we have no concept of connections or ports, mapping from CoAP
> messages to Interactions must fully rely on MessageID and Token? Or do all
> server responses carry the Token?
>

-- 

040 / 22816531-0
www.lobaro.de
[email-masked]