Setting observe lifetime about libcoap

[mrdeep1]

I can find nothing in RFC7641 that defines a lifetime option for use with a CoAP request. The Max-Age option is used for responses, not requests, but would be most closely aligned with what you are trying to do, but the client and server would need to be coded appropriately to understand this.

What is the motivation behind doing this?

[mikefoxTB]

The idea is mentioned in: https://datatracker.ietf.org/doc/id/draft-ietf-core-observe-01.html
We have an unreliable constrained network and several clients, with a lifeime option the clients can renew their observations and the server can prune expired observations.

[cabo]

The idea is mentioned in: https://datatracker.ietf.org/doc/id/draft-ietf-core-observe-01.html

Which is the path not taken. We didn't see a need for regular refresh.
Why should the client control how often the server gets to check for its continued presence?

We have an unreliable constrained network and several clients, with a lifeime option the clients can renew their observations and the server can prune expired observations.

The server can check up on observing clients by sending confirmable notifications.
The frequency of these is under server control, as it should.
Compare the last paragraph of section 4.5 1.

[mikefoxTB]

Got it, the server can use confirmable notifications to detect disconnected clients. Is there any other way? Can Ping/Pong(s) be used? In our situation the notifications are not a regular periodic update but more of a Poisson distribution with long intervals of no updates until at some random point in time there are many updates. During the long intervals of no update, we would like to minimize the traffic and only send notifications to the currently connected clients because of to the constrained network. Advice on to how to do this would be appreciated!

[cabo]

How is it beneficial to get rid of observers when you are not sending notifications anyway?
You can always send an unchanged value as a confirmable notification, that would be your ping/pong.
But why not stay silent and wait for the next actual change?
That indeed minimizes the traffic.

[mikefoxTB]

The other part of the story is that a multitude of clients come and go, as they "connect" they set up observations and then usually get disconnected in a disorderly manner due to link limitations, (something like a mobile mesh network where parts go out of range of one another unpredictably). We want to have the server efficiently prune the zombie (not connected) clients so when an event does happen, we use bandwidth to communicate with the connected clients and not retry too much on the zombies.
Seems we could do this with confirmable notification from an observable "heartbeat" resource, and both the client and server agree to a loss condition, and once the loss condition occurs both the server and client "knows" they are in a disconnected state and then client can try to reconnect. Does this sound Ok?

[mrdeep1]

Confirmable Observable "heartbeat" resource would work. You need to determine the frequency of unsolicited response to make sure that any interim NAT device has its mapping tables kept "warm", and monitor the alerts / nacks generated. See coap_handler(3).

It is also possible/permissible for the server to initiate a CoAP Ping request to illicit a CoAP pong response back from the client. This is not automatically supported by libcoap at present (but is supported when initiated by the client using coap_keepalive(3)). The downside compared to the observable "heartbeats" is that no (state etc.) information can be carried using CoAP Ping/Pong.

Recently added is support for server restarts maintaining observe information so that the client does not need to re-register following a server reboot (only works for UDP, not DTLS sessions). See coap_persist(3).

[mikefoxTB]

Thank you for the guidance, it is always a balance adding "features" to a protocol or letting applications do something on their own and each differently.
Perhaps a "well known" resource named ("heartbreak") is in order to allow generic applications to register and receive the server's update period, and then the client could decide to try and reregister if it did not receive the update at the expected time.