Search code examples
onem2m

OneM2M NOTIFY blocking rules?


I'm having trouble finding where in the spec it specifies how notification should be queued or blocked in the most trivial case.

Let's assume a simple mn-ae <=> mn-cse <=> in-cse <=> in-ae setup. There's a resource res1 on the mn-cse, and the in-ae has a trivial subscription on it:

{
    "enc": {
        "net": [3],
        "ty": 4
    },
    "nct": 1,
    "nu": ["<uri>"],
    "pi": "res1",
    "ri": "sub1",
    "rn": "sub1",
    "ty": 23
}

There are no other relevant resources or configurations affecting notifications.

Then, let's say the mn-ae updates res1 and that triggers a notification to in-ae, and let's say the in-ae takes a while to process that notification (not long enough to timeout)... While in-ae is processing the notification, mn-ae does another update to res1.

My question is this: where (if anywhere) is this second notification blocked?

  • in the mn-cse ?
  • in the in-cse ?
  • not blocked - in-ae receives two concurrent notifications.

Further questions:

  • what if it (the 2nd notification) was triggered by a different in-ae on the same mn-cse ? (ie. are the notification queued based on target ?)
  • what if the same in-ae triggered a different notification on a different resource? (ie. are the notificaitons queued based on source ?)
  • what if it was a different in-ae on a different mn-cse ?

Solution

  • Assuming the described scenario for basic subscription on a resource and in response to your first question, notifications are not blocked and in-ae will receive two concurrent notifications. oneM2M does not specify any notification blocking mechanism.

    Regarding your further questions (and assuming you meant mn-ae instead of in-ae, guessing in-ae is always the notification target in such scenario), notifications are sent to the target as soon as they are generated, independently of the ae that triggered it or the subscribed-to resource. Notifications from different subscribed-to resources are distinguished by the subscriptionReference attribute in the notification element.

    Different setups on the subscriptions or connectivity between the different nodes will make this behaviour vary, i.e. batching notifications, target reachability, etc…