Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0, Agenda Item: Information Flows – Basic Procedures

Problem © 2013 oneM2M Partners oneM2M-ARC-0441R01 2 We cannot expect that an originator will always be able to wait for a ‘synchronous’ response, i.e. a response that is in synch with the requested operation (=> possibly long blocking request) In case this takes a (very) long time, we need a way to respond to the originator before the operation has completed and allowing the originator to get the result of the requested operation later on This is partially anticipated by some of the parameters in clause 8.1 (response type)… but the concept is not consistently defined in the specs so far ∆t may be quite long!

More Thoughts © 2013 oneM2M Partners oneM2M-ARC-0441R01 3 It may be unlikely that a request to a local CSE (i.e. a request to a CSE that the originator is directly communicating with via Y) would take so long that a blocking request is not acceptable – However: Power-constraint devices acting as an Application Dedicated Node may not be able to wait for a response, not even a short time. They may want to express a request as quickly as possible and find out if the CSE got the request and then go sleep ASAP. If needed at all, they may poll the result of the requested operation when they wake up next time. When a request is targeting a resource on a remote CSE, it could be anticipated that originator may not be accepting a long blocking time – Constraints on power consumption / uptime may not allow for long blocking – Long blocking may require to program AE with multiple threads, not always feasible More capable originators may actually want the local CSE to send back the result of an operation to a specific URI that the Originator handles – This would be equivalent to making a CRUD request on a target resource and simultaneously initiating a subscription to the result of the operation, so that the originator receives a notification when the requested operation finished => avoid polling

Way Out © 2013 oneM2M Partners oneM2M-ARC-0441R01 4 Allow for use of – Synchronous as well as – Asynchronous processing and – provide a reference to a specified resource for retrieving status of requests and results See following slides for details

Synchronous (1) © 2013 oneM2M Partners oneM2M-ARC-0441R01 5 Originator of request is expecting the request to be blocked until the result of the requested operation is available and get the result with the response to the request – If everything works OK, the originator makes the request, the request stays open until the result of the operation is known and the Local CSE returns the result of the operation with the response to the request back to the Originator of the request

Synchronous (2) © 2013 oneM2M Partners oneM2M-ARC-0441R01 6 – If result of requested operation is NOT available within a timeout, local CSE responds with a Request-ID that can be used to retrieve details (result, status) via a new resource – Timeout: Can be set by originator. If not set, use default. No need to force usage of that parameter in each request Timeout could be much shorter than the expiration time Allows for short or long polling of results or alternatively subscription – Request-ID: Already defined as M2M-Request-ID So far only for CSE-to-CSE request… but could be extended for AE-to-CSE – Synergy with specification in clause 8.1: Access to the resource could be limited by ‘rp’ used in “response persistence: indicates the duration for which the address containing the responses is to persist” defines it relative to expiration time ‘et’ The information ‘rt’ response type in could define that only Req-ID is returned immediately without even waiting for an operation result If operation result is expected in response (‘rt’ set to expect result content), but timeout happens => return Req-ID only If all works OK, return Req-ID and requested result of operation – Request-ID would always make sense to return When an entity refers to a previously issued request, use Request-ID. Avoids duplicate requests for operations (idempotent requests)

Synchronous (3) © 2013 oneM2M Partners oneM2M-ARC-0441R01 7 – When original attempt did only return the Request-ID, Originator can just ask again for the expected results Just needs to issue another request and refer to the Request-ID – Allows for polling (short, long, … depending on timeout) – Also allows for subscription Originator may subscribe to the resource to find out about a change Could also selectively subscribe to the particular attribute of interest (e.g. operation result)

Synchronous (4) © 2013 oneM2M Partners oneM2M-ARC-0441R01 8 – From an Originator’s perspective the processing is the same no matter whether the resource is hosted locally or not The originator may not even be aware of whether the target of the requested operation is local or not (think e.g. of a group as a target) – The originator can poll result/status/context of the requested operation – The Originator can subscribe to any changes in the resource or particular attributes of it Can find out when operation result changes

Asynchronous (1) © 2013 oneM2M Partners oneM2M-ARC-0441R01 9 Originator of request is expecting the request to return a prompt response right after acceptance or rejection of the request by the local CSE. If a result of the requested operation is expected, the originator provides a reference to the local CSE that shall be used as a target for sending the result of the requested operation (notification target) – Assumes that Originator can receive asynchronous messages (AKA “server capable”) or has a mechanism set up beforehand to be able to receive messages in a pseudo asynchronous manner (long polling channel)

Asynchronous (2) © 2013 oneM2M Partners oneM2M-ARC-0441R01 10 Originator of request is expecting the request to return a prompt response right after acceptance or rejection of the request by the local CSE. Originator then subscribes to the part of the resource that it is interested in – See suggested structure of the resource at the end of this deck

Motivation Resource Type © 2013 oneM2M Partners oneM2M-ARC-0441R01 11 General motivation Usage of resources and Reqest-IDs that would be used as the ID for the respective resource allows for robust synchronous and asynchronous request processing coping with various constraints on maximum blocking time. Provides a means to poll or subscribe to status/result/content related to a specific request at a later time after issuing a request Straight-forward way of referring to previously issued requests in a RESTful manner Allows for very simple Originators (power / complexity constraint) that need to get responses to a request very quickly and need to poll status/result/content later on Allows for Originators to pick how long they want to wait for a request to be responded Allows for more complex Originators that can handle subscriptions CMDH related motivation (see ARC-0397R01) as well When a request is targeting a remote CSE, the request needs to be put inside the data that gets forwarded to the target CSE When delivery data reaches a target CSE, it needs to extract what the original request was When a result of a requested operation comes back from a target CSE to the originating CSE, the result may have to be stored for later access by the originator of the triggering request => Agree on a Definition of a resource type

Resource Type © 2013 oneM2M Partners oneM2M-ARC-0441R01 12 The ID of the resource could simply be the M2M- Request-ID operation: Operation being requested, see op in clause 8.1 target: Targeted resource, see to in clause 8.1 originator: Entity that originated the request, see fr in clause 8.1 metaInformation: Meta information on the request (expiration time etc.), see mi in clause 8.1 Content: Content going to / coming from target, see cn in clause 8.1 requestStatus: Status of the request, see rs in clause 8.1 (e.q. accepted & pending) operationResult: Result of the requested operation, see cs in clause 8.1 (e.g “resource created with URI xyz”)