OneM2M通知阻塞规则？

Question

在最简单的情况下，我很难找到规范中指定如何排队或阻塞通知的地方。

让我们假设一个简单的mn-ae <=> mn-cse <=> in-cse <=> in-ae设置。在res1上有一个资源mn-cse，而in-ae上有一个简单的订阅：

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

没有其他相关资源或配置影响通知。

然后，假设mn-ae更新res1并触发对in-ae的通知，假设in-ae需要一段时间来处理该通知(不够长到超时).在in-ae处理通知时，mn-ae会对res1进行另一次更新。

我的问题是:第二个通知在哪里(如果有的话)被阻止？

• in mn-cse ?
• in in-cse ?
• not - in-ae接收两个并发的

进一步问题：

如果

• (第二个通知)是由同一mn-cse上的不同in-ae触发的，怎么办？(即)通知是否基于目标排队？)
• ，如果同一个in-ae在不同的资源上触发了不同的通知，怎么办？(即)通知是否基于源排队？)
• ，如果它是不同mn-cse上的不同in-ae ?

Answer 1

假设对资源进行基本订阅的描述场景，并且响应您的第一个问题，通知不会被阻止，in将接收两个并发通知。oneM2M没有指定任何通知阻塞机制。

关于你的进一步问题(假设你指的是mn-ae而不是in- ae，猜测in-ae总是这种场景中的通知目标)，通知一旦生成就会被发送到目标，而不依赖触发它或订阅的ae-到资源。来自不同订阅资源的通知通过notification元素中的subscriptionReference属性进行区分。

不同节点之间对订阅或连接的不同设置会使这种行为发生变化，例如批处理通知、目标可达性等。