嵌入式-nal-minimal-coaptcpserver

基于[嵌入式_nal]构建的最小CoAP-over-TCP服务器实现。

这是嵌入式-nal-minimal-coapserver的TCP等价物；它用于说明差异，并作为基准工具来比较CoAP-over-TCP和CoAP-over-UDP。从长远来看，它还可能在CoAP-over-TCP对约束设备（在NAT穿越中）实用的地方有用；为此，它需要获得一些基本客户端功能来发送请求。

用法和操作

另见等效部分：拥有一个[ServerPool]并在可能发生网络活动时调用ServerPool::poll。

每个TCP连接需要一些（少量）状态，该状态与套接字一起存储在[ConnectionState]中。ServerPool所做的一切就是接受连接、单独轮询连接并在收到错误时丢弃状态（包括此时已关闭的套接字）。如果想要使用其他管理连接的方法，包括主动打开连接，只需替换ServerPool并手动调用ConnectionState::poll_connection即可。

如果你不想提供接收和发送缓冲区的堆分配，而是用一些刮擦内存替换它，目前可以通过以下方式手动进行每连接轮询：ConnectionState::poll_connection_with_buffer可以与一个锁定区域一起使用。

注意事项

请参阅等效部分，以下有修改：

• 作为一个TCP服务器，它不易受到放大缓解的影响，不需要执行消息去重，并且不易受到细微的响应地址问题。

  虽然这是CoAP-over-UDP服务器需要幂等性的原因，但以下原因仍需要幂等性。

• 与CoAP-over-UDP不同，服务器没有“错过”请求的余地。

  如果读取了请求但发送响应失败（因为发送缓冲区未就绪），仍然需要处理请求而不会造成太大的暂停点；此服务器所做的就是响应5.03并等待客户端重试。因此，仍然建议处理程序需要是幂等的。

  （即使发送缓冲区完全满，发送5.03也可能失败，在这种情况下，连接将被终止）。

  幸运的是，这种事件（需要发送5.03，更不用说终止）可以预期是罕见的，至少当客户端同步发送请求时（客户端完全有权利不这样做，但许多应用程序简单地同步）。

  如果TCP套接字指示某些大小的outbuffer可以得到保证，这可以减轻这种情况；这种实现可以仅在最大响应可用时才开始读取请求。

  （更复杂的服务器可能会希望处理程序的响应数据尽可能小，正如它在[coap-handler]生态系统中所应有的。然后，它可以为已处理请求设置一个暂停点（状态机状态），并等待构建响应所需的确切大小可用。这种实现将不会这样做。较简单的服务器可以存储令牌，并且至少可以可靠地发送5.03，即使稍后）。

• 底层堆栈必须能够在一个非阻塞读取中提供完整的CoAP请求（直到某个大小）。否则，CoAP库需要为每个可能缓慢流入的连接保留自己的缓冲区。

  这仅由实现embedded_nal_tcpextensions::TcpExactStack特征的TCP堆栈提供，该特征在https://github.com/rust-embedded-community/embedded-nal/issues/59中讨论。

路线图

服务器仍在开发中，但至少是基本功能的。

此服务器的目标是保持简单和最小化组件，在生产就绪性方面比embedded-nal-minimal-coapserver有较低的雄心。

许可：MIT OR Apache-2.0