8.2 请求响应层

当服务端发现某个多播请求，它可能会一直忽略这个请求，特别是当它没有任何有用的回复（比如说，它只有一个空的payload或者一个错误响应）。这个判断是由应用决定的（例如，在请求过滤 [RFC6690]中，当过滤条件不满足时，服务端不会响应多播请求。更多例子见 [GROUPCOMM]）。

如果服务端决定响应一个多播请求，它不应该立即响应。相反它应该会等待一段时间才进行响应。我们把这段时间称为空闲（Leisure）时间。空闲时间的值可能由应用决定，也可能由下面的描述中得到。服务端应该在选取的空闲时间中的某个随机时间发送一个单播响应给该多播请求。如果再次收到同一个多播组的请求，一个新的空闲时间最早需在上一个空闲时间结束后才能开始。

为了计算出一个空闲时间，服务端必须有一个组大小估计G，一个目标数据传输率R（二者都必须谨慎的选择），一个估计的回复大小S，一个大致的空闲时间计算公式如下：

lb_Leisure = S * G / R

举个例子，一个在2.4G频段，采用IEEE 802.15.4（6LoWPAN）的本地网络中，G可能被设置成100，S为100字节，目标速率R为8kbits/s = 1kB/s。那么空闲时间为100 * 100 / 1000 = 10秒。

如果一个CoAP端不能获得足够的数据来计算空闲时间，它可能采用DEFAULT_LEISURE。

当匹配一个多播请求的回复时，仅仅token必须要匹配。回复的源端不需要（可能也不会）和原始请求的目的端匹配。

为了解释表现中的Location-*选项和任何嵌入的链接，请求URI（例如，响应对应的基本URI）通过将原始请求URI的host组件中的多播地址替换成实际响应的端的ip地址。