Libwebsockets中消息重复发送问题的分析与解决

问题现象描述

在使用Libwebsockets库开发WebSocket服务器时，开发者发现一个奇怪的现象：服务器会在5分钟后自动重新发送最后一次接收或发送的消息。这个行为并非开发者有意设计的，而是由底层库的某些机制导致的。

代码分析

从提供的代码来看，这是一个非常基础的WebSocket服务器实现，主要功能是接收客户端消息并广播给所有连接的客户端。关键部分包括：

1. 接收回调(LWS_CALLBACK_RECEIVE)：将接收到的消息存入缓冲区，并标记所有协议实例为可写状态
2. 可写回调(LWS_CALLBACK_SERVER_WRITEABLE)：将缓冲区中的消息发送给客户端

问题根源

问题的核心在于对Libwebsockets库中可写回调机制的理解不足。在Libwebsockets中：

1. 可写请求(LWS_CALLBACK_SERVER_WRITEABLE)并不总是由用户代码通过lws_callback_on_writable()直接触发的
2. 库本身也会因为多种原因(如发送控制操作码、完成部分发送等)触发可写请求
3. 事件循环仅通过位标志来跟踪事件类型(如POLLOUT)，无法区分用户请求和库内部请求

这种设计导致当库消耗一个可写事件时，它会自动添加一个额外的可写请求，以补偿可能被库"抢占"的用户请求。因此，开发者可能会收到比预期更多的可写回调。

解决方案

正确的处理方式是将可写回调视为"有机会写入"的通知，而不是必须写入的命令。修改后的代码逻辑应该是：

1. 只有在确实有新消息需要发送时，才在可写回调中执行发送操作
2. 如果没有新消息需要发送，则直接跳出回调处理

具体到代码实现，可以添加一个标志位来记录是否有新消息需要发送，或者直接清空消息缓冲区来避免重复发送。

最佳实践建议

1. 状态管理：维护明确的状态机来跟踪是否有数据需要发送
2. 缓冲区处理：发送完成后及时清空或标记缓冲区
3. 错误处理：考虑发送失败的情况并实现重试机制
4. 流量控制：在高负载情况下实施适当的流量控制策略

总结

Libwebsockets库的这种设计实际上提供了更大的灵活性，允许库和用户代码共享相同的可写事件机制。理解这一机制对于开发稳定的WebSocket应用至关重要。开发者应该将可写回调视为发送机会而非义务，根据实际需求决定是否发送数据，这样才能避免消息意外重发的问题。

通过这种模式，Libwebsockets既保证了内部操作的顺利进行，又为用户代码提供了充分的机会进行数据发送，实现了库功能与用户需求的平衡。