Observe cancellation by client

[mkovatsc]

node-coap currently does not support proactive cancellation via GET with Observe=1.

In server.js, the _handle() function should probably try to find the corresponding ObserveStream via the token when request.headers['Observe'] === 1 instead of producing a new response with response = new Message(packet, function(response, packet). The ObserveStream needs to be closed. Sending the last (cached) response/notification with that token should work; otherwise, ObserveStream could also take a callback to produce a final response.

[lucarv]

I wonder how to implement this correctly. According to (my perhaps poor) understanding of the specs, when the client stop sending ack to a data posted event, the server should then close the stream. I am not sure how to stop the client from sending an ack to the data event. Is it even possible?

[sjlongland]

Well, no, not when it stops sending ACKs… that'll just cause the server to re-send the notification until it exhausts the retry count.

There are two ways:

• Client replies to the next notification with RST.
• Client sends a GET with token matching the original request and Observe=1.

node-coap does the former when you close the stream, it just cleans up the request at the client end, so next notification it naturally responds with the RST message. To be proactive about things, it just needs to generate that GET request at that time instead.

[GiedriusM]

Per RFC7641 the default way of handling a canceled observation is by sending RST:

A client that is no longer interested in receiving notifications for a resource can simply "forget" the observation.`

and the active cancellation is optional:

a client MAY explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister).

A flag to the close method could be added to indicate active/forced cancellation:

ObserveReadStream.prototype.close = function(sendCancel) {
  if (sendCancel) {
    // duplicate original req and send with observe=1 ...
  }
  this.push(null)
  this.emit('close')
}

However,

... All other options MUST be identical to those in the registration request except for the set of ETag Options.

and the whole request option duplication may look a bit messy/out-of-context in this place.

Your thoughts?

[lucarv]

@sjlongland my bad, i should have re-read the RFC instead of just googling it ;) I found something here and believed it blindly. Anyway, I suppose the lib does not support Observe set to false, and the reset() crashes (there is an issue on it). I found a way around anyway, thanks for the reply.

[sjlongland]

@lucarv Well no, Observe should always be set to an unsigned integer value, never a boolean (e.g. false). Specifically, 0 if you're subscribing, 1 if you're unsubscribing… or any 24-bit value if you're the server sending a notification (the value just has to be slightly greater than the last, modulo 24-bits).

@GiedriusM I don't think duplicating the options is a big issue. If it's got to be done, it's got to be done. It's either that, or tie up a subscription slot on a CoAP server (which could be a tiny embedded device). Waiting for the next notification relying on the RST being sent was a right nuisance in my experience when the server can only handle a single subscriber at a time.

To me, leaving servers with tiny amounts of RAM tied up in a subscription we're not interested in is a tardy way to handle it. Reasonable if the client crashed and subsequently forgot about its subscription, but not good otherwise. If the client knows it won't need something, it should free that resource for someone else.

[lucarv]

For sure. I just used false and true as a way to describe start/stop... Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Stuart Longland <notifications@github.com> Sent: Saturday, January 4, 2020 3:37:39 AM To: mcollina/node-coap <node-coap@noreply.github.com> Cc: Tayo Carvalhal <Tayo.Carvalhal@microsoft.com>; Mention <mention@noreply.github.com> Subject: Re: [mcollina/node-coap] Observe cancellation by client (#195) @lucarv<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flucarv&data=02%7C01%7CTayo.Carvalhal%40microsoft.com%7C77525a3c3e834243f08108d790bf113d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637137022615232011&sdata=Qmw8Lt9o1PNkLOkR6qHei2GsYyHxjsTOT7K8ySDEB5M%3D&reserved=0> Well no, Observe should always be set to an unsigned integer value, never a boolean (e.g. false). Specifically, 0 if you're subscribing, 1 if you're unsubscribing… or any 24-bit value if you're the server sending a notification (the value just has to be slightly greater than the last, modulo 24-bits). @GiedriusM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGiedriusM&data=02%7C01%7CTayo.Carvalhal%40microsoft.com%7C77525a3c3e834243f08108d790bf113d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637137022615232011&sdata=KbDFYWmSZfZIWBH0Emyj2gORFPeU%2Fen3X%2BtHp%2B6mv3k%3D&reserved=0> I don't think duplicating the options is a big issue. If it's got to be done, it's got to be done. It's either that, or tie up a subscription slot on a CoAP server (which could be a tiny embedded device). Waiting for the next notification relying on the RST being sent was a right nuisance in my experience when the server can only handle a single subscriber at a time. To me, leaving servers with tiny amounts of RAM tied up in a subscription we're not interested in is a tardy way to handle it. Reasonable if the client crashed and subsequently forgot about its subscription, but not good otherwise. If the client knows it won't need something, it should free that resource for someone else. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmcollina%2Fnode-coap%2Fissues%2F195%3Femail_source%3Dnotifications%26email_token%3DAE7FSCYBLKHTWS2LUVNEIQ3Q37Y7HA5CNFSM4FWZP3OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICPGDY%23issuecomment-570749711&data=02%7C01%7CTayo.Carvalhal%40microsoft.com%7C77525a3c3e834243f08108d790bf113d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637137022615242008&sdata=19hazhNbPAjSd2EWt7R50MlA9xhv6UVqNnsA7x18bLY%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE7FSC7RW6OBHXYIR6JMZQLQ37Y7HANCNFSM4FWZP3OA&data=02%7C01%7CTayo.Carvalhal%40microsoft.com%7C77525a3c3e834243f08108d790bf113d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637137022615252007&sdata=tK7IbSGMnL5m8fFG7MaSp9XiBUztZq4OgP%2B1SV%2FTEqg%3D&reserved=0>.

[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 within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.

[sjlongland]

Activity has been taking place in pull requests. See PR #164 and PR #214.

[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 within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.

[sjlongland]

PR #164 is closed, PR #214 is in review.

Issue would be fixed if PR #214 was merged: I therefore don't understand the wontfix label.

[Apollon77]

That comment was completely correct. Stalebot can only check last activity on an issue

[sjlongland]

I think with the merge of PR #214 this issue is now fixed.

[JKRhb]

I think with the merge of PR #214 this issue is now fixed.

You are right, I'll close this issue. Thanks once again!