OneM2M NOTIFY 阻止规则？

如何解决OneM2M NOTIFY 阻止规则？

我无法在规范中找到它指定在最微不足道的情况下应如何排队或阻止通知的位置。

让我们假设一个简单的 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。

我的问题是：哪里（如果有）第二个通知被阻止了？

• 在 mn-cse 中？
• 在 in-cse 中？
• 未阻止 - in-ae 收到两个并发通知。

其他问题：

• 如果它（第二个通知）是由同一个 in-ae 上的不同 mn-cse 触发的怎么办？ （即，通知是否基于 target 排队？）
• 如果同一个 in-ae 在不同的资源上触发了不同的通知怎么办？ （即，通知是否根据 source 排队？）
• 如果在不同的 in-ae 上是不同的 mn-cse 会怎样？

解决方法

假设所描述的资源基本订阅场景，并且响应您的第一个问题，通知不会被阻止并且 in-ae 将收到两个并发通知。 oneM2M 未指定任何通知阻止机制。

关于您的进一步问题（假设您的意思是 mn-ae 而不是 in-ae，猜测 in-ae 在这种情况下始终是通知目标），一旦生成通知，就会将通知发送到目标，而与目标无关触发它的 ae 或订阅的资源。来自不同订阅资源的通知通过通知元素中的 subscriptionReference 属性进行区分。

不同节点之间订阅或连接的不同设置将使这种行为有所不同，即批量通知、目标可达性等......