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?
mn-cse ?in-cse ?in-ae receives two concurrent notifications.Further questions:
in-ae on the same mn-cse ? (ie. are the notification queued based on target ?)in-ae triggered a different notification on a different resource? (ie. are the notificaitons queued based on source ?)in-ae on a different mn-cse ?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…