OneM2M NOTIFY 阻止规则?
OneM2M NOTIFY blocking rules?
我在规范中找不到指定在最微不足道的情况下应如何排队或阻止通知的位置。
让我们假设一个简单的 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
怎么办?
假设所描述的资源基本订阅场景,并在回答您的第一个问题时,通知不会被阻止,in-ae 将收到两个并发通知。 oneM2M 未指定任何通知阻止机制。
关于您进一步的问题(假设您的意思是 mn-ae 而不是 in-ae,猜测在这种情况下 in-ae 始终是通知目标),通知一生成就会发送到目标,独立于触发它的 ae 或订阅的资源。来自不同订阅资源的通知通过通知元素中的 subscriptionReference 属性来区分。
不同节点之间订阅或连接的不同设置将使这种行为有所不同,即批处理通知、目标可达性等……
我在规范中找不到指定在最微不足道的情况下应如何排队或阻止通知的位置。
让我们假设一个简单的 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
怎么办?
假设所描述的资源基本订阅场景,并在回答您的第一个问题时,通知不会被阻止,in-ae 将收到两个并发通知。 oneM2M 未指定任何通知阻止机制。
关于您进一步的问题(假设您的意思是 mn-ae 而不是 in-ae,猜测在这种情况下 in-ae 始终是通知目标),通知一生成就会发送到目标,独立于触发它的 ae 或订阅的资源。来自不同订阅资源的通知通过通知元素中的 subscriptionReference 属性来区分。
不同节点之间订阅或连接的不同设置将使这种行为有所不同,即批处理通知、目标可达性等……