net/gcoap: Confirmable Observe notifications #7548
Conversation
smlng
added
Type: enhancement
kb2ma
changed the title
smlng
added
the
State: waiting for other PR
smlng
removed
the
State: waiting for other PR
|
#7337 is merged, please rebase |
kb2ma
force-pushed
the
gcoap/confirm_observe
branch
from
00c6aba
to
bebf165
Compare
|
Rebased. |
| * via a reset (RST) response to a non-confirmable notification. | ||
| * the Observe option value set to 1. A confirmable notification also is | ||
| * cancelled by a reset (RST) response from the client or by the absence of an | ||
| * ACK response. |
There was a problem hiding this comment.
Is this according to the standard? What if the ACK (or the CON for that matter) just gets lost?
There was a problem hiding this comment.
Yes, according to RFC 7641. There is a short summary at the end of Sec 1.2:
When the client deregisters, rejects a notification, or the transmission of a notification
times out after several transmission attempts, the client is considered no longer
interested in the resource and is removed by the server from the list of observers.
See also Sec 4.5 specifically on retransmissions. This removal of a client is a MUST (in the RFC 2119 sense).
Observe is meant to be a best-effort attempt to notify the client. It's not a guaranteed delivery mechanism. However, the server can include a Max-Age option in the notification so the client can decide to re-register for the resource if it hasn't heard from the server.
The code currently does not include a Max-Age option. See #8831 for the plan to make it easy to add arbitrary options to a message.
There was a problem hiding this comment.
[…] or the transmission of a notification times out after several transmission attempts, […]
How many retransmission attempts are there in this implementation?
There was a problem hiding this comment.
Here is the quote from sec. 4.5:
The client's acknowledgement of a confirmable notification signals
that the client is interested in receiving further notifications. If
a client rejects a confirmable or non-confirmable notification with a
Reset message, or if the last attempt to retransmit a confirmable
notification times out, then the client is considered no longer
interested and the server MUST remove the associated entry from the
list of observers.
So, the number of retransmissions is governed by the confirmable retransmission count in the implementation. nanocoap sets COAP_MAX_RETRANSMIT to 4, so 5 transmission attempts are made altogether, using exponential backoff (2, 4, 8, 16 seconds).
You also might be interested to read at the end of sec. 4.5 about non-confirmable transmission. If notifications are sent non-confirmably, at least once a day the implementation MUST send a transmission confirmably. So, the spec uses the confirmable retransmission limit to eliminate Observe clients no longer interested in the resource.
This requirement to send a message confirmably at least once a day is not enforced by gcoap.
|
Needs a rebase. |
Supports handling an empty message response.
Supports new uses where a coap_pkt_t PDU is not available.
Handles if no ACK response, or if a reset (RST) response.
kb2ma
force-pushed
the
gcoap/confirm_observe
branch
from
bebf165
to
ac71683
Compare
|
Rebase looks good. |
bergzand
added
the
Area: CoAP
|
Sorry, this somehow got lost. @kb2ma can you rebase again, please? |
|
Alright. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
stale
bot
added
the
State: stale
kb2ma
removed
the
State: stale
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
stale
bot
added
the
State: stale
stale
bot
removed
the
State: stale
miri64
added
State: archived
This PR implements the fourth step in the confirmable messaging plan in #7192, and depends on #7337. It allows for an Observe notification to be sent confirmably. Also, the server may deregister a client from further notifications based on the response. The client is deregistered if it responds to the notification with a reset (RST) message, or if the server does not receive a response from the client. This PR also includes refactoring of a couple of utility methods to support the implementation.