8. Multicast CoAP (组播CoAP)

CoAP支持向IP组播组发出请求. 这是通过对单播CoAP的一系列增量定义的. [GROUPCOMM]中提供了关于CoAP组通信的更一般讨论.

提供希望其他端点能够使用组播服务发现找到的服务的CoAP端点加入一个或多个适当的全CoAP节点组播地址 (第12.8节) 并在默认CoAP端口上侦听. 请注意, 端点可能会在其他组播地址 (包括全节点IPv6地址) 上接收组播请求 (或通过IPv4上的广播); 因此, 端点必须准备好接收此类消息, 但如果不需要组播服务发现, 则可以忽略它们.

8.1. Messaging Layer (消息层)

组播请求的特征是在CoAP消息中传输, 该消息寻址到IP组播地址而不是CoAP端点. 此类组播请求必须是不可确认的.

服务器应该知道请求是通过组播到达的, 例如, 如果可用, 通过使用现代API (例如IPV6_RECVPKTINFO [RFC3542]).

为了避免错误响应的爆发, 当服务器知道请求是通过组播到达时, 它不得返回重置消息来回复不可确认消息. 如果它不知道, 它可以像往常一样返回重置消息来回复不可确认消息. 因为这样的重置消息对于发送者来说看起来与单播消息的重置消息相同, 发送者必须避免使用也仍然从此端点与任何可能接收组播消息的单播端点一起活动的消息ID.

在撰写本文时, 组播消息只能在UDP中携带, 不能在DTLS中携带. 这意味着本文档为CoAP定义的安全模式不适用于组播.

8.2. Request/Response Layer (请求/响应层)

当服务器知道请求是通过组播到达时, 服务器可以始终忽略请求, 特别是如果它没有任何有用的响应 (例如, 如果它只有空有效载荷或错误响应). 此决定可能取决于应用程序. (例如, 在[RFC6690]中描述的查询过滤中, 如果过滤器不匹配, 服务器不应该响应组播请求. [GROUPCOMM]中有更多示例.)

如果服务器确实决定响应组播请求, 它不应该立即响应. 相反, 它应该为它打算响应的时间段选择一个持续时间. 为了本说明的目的, 我们将此时间段的长度称为Leisure. 此Leisure的特定值可能取决于应用程序或可以如下所述派生. 然后, 服务器应该在选择的leisure期间内选择一个随机时间点, 以将单播响应发送回组播请求. 如果需要基于相同的组播地址成员资格发送进一步的响应, 则在前一个完成后最早开始新的leisure期间.

要计算Leisure的值, 服务器应该有组大小估计G, 目标数据传输速率R (两者都应该保守选择), 以及估计的响应大小S; 然后可以将Leisure的粗略下限计算为

lb_Leisure = S * G / R

例如, 对于2.4 GHz IEEE 802.15.4 (6LoWPAN) 网络上的具有链路本地范围的组播请求, G可以 (相对保守地) 设置为100, S设置为100字节, 目标速率设置为8 kbit/s = 1 kB/s. 由此产生的Leisure下限为10秒.

如果CoAP端点没有适当的数据来计算Leisure的值, 它可以诉诸DEFAULT_LEISURE.

当将响应与组播请求匹配时, 只有token必须匹配; 响应的源端点不需要 (也不会) 与原始请求的目标端点相同.

为了解释Location-*选项和表示中嵌入的任何链接, 请求URI (即, 相对于其解释响应的基本URI) 是通过将原始请求URI的主机组件中的组播地址替换为实际响应的端点的文字IP地址来形成的.

8.2.1. Caching (缓存)

当客户端发出组播请求时, 它总是向组播组发出新请求 (因为可能有新的组成员同时加入或没有收到先前的请求). 它可以使用接收到的响应更新缓存. 然后, 它使用缓存的仍然新鲜和新的响应作为请求的结果.

响应于对组播组的GET请求而接收的响应可以用于满足相关单播请求URI上的后续请求. 单播请求URI是通过将请求URI的授权部分替换为响应消息的传输层源地址来获得的.

缓存可以通过在相关单播请求URI上发出GET请求来重新验证响应.

对组播组的GET请求不得包含ETag选项. 抑制客户端已经拥有的响应的机制留待进一步研究.

8.2.2. Proxying (代理)

当正向代理接收到具有Proxy-Uri或从Proxy-Scheme构造的URI的请求, 该请求指示组播地址时, 代理获取如上所述的一组响应, 并将所有响应 (缓存的仍然新鲜和新的) 发送回原始客户端.

本规范没有提供在因此转发的响应中指示单播修改的请求URI (基本URI) 的方法. [GROUPCOMM]中更详细地讨论了代理组播请求; [CoAP-MISC]的第3节中可以找到解决基本URI问题的一个建议.