OneM2M 通知阻止规则？

Question

我很难找到规范中的哪个位置，它指定了在最微不足道的情况下应该如何排队或阻止通知。

让我们假设一个简单的mn-ae <=> mn-cse <=> in-cse <=> in-ae 设置。 mn-cse 上有资源res1，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 收到两个并发通知。

其他问题：

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

Answer 1

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

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

不同节点之间的订阅或连接的不同设置将使此行为发生变化，即批处理通知、目标可达性等......