P2P网络Socket传输数据不完整致json.loads解析异常问题排查

• 最致命的设计缺陷：接收端的接收状态没有和连接绑定
  当前代码里msg_length和buffer是定义在select主循环外的全局共享变量，所有接入的客户端连接共用同一个缓冲区、同一个消息长度解析状态。只要有两个以上连接同时有数据可读，不同socket收到的字节会被无差别拼到公共缓冲区里，直接导致长度头解析错乱、JSON内容被拆分到错误上下文，出现字节缺失、结构不完整的问题。
• 解码逻辑存在边界漏洞
  代码对每次recv(1024)拿到的原始字节直接做整体decode('utf-8')，但UTF-8是变长编码，一个多字节字符很可能被拆分到两次recv返回的数据包中，直接解码会出现乱码、内容截断，进一步破坏JSON结构的完整性。
• 消息解析流程存在提前中断的问题
  接收端在内层循环解析消息时，只要解析出第一条带node_identifier字段的消息，就直接触发break跳出循环。哪怕缓冲区里已经攒够了后续完整的消息内容，也不会继续处理，会造成数据滞留，后续消息完全无法正常解析。
• 发送端异常处理颗粒度太粗
  发送端捕获到发送异常后直接静默跳过，既没有标记无效连接触发清理流程，也没有补传剩余未发送的数据。一旦发送过程中出现发送缓冲区满、对端连接重置、线程调度切换导致的状态异常，就会出现数据发一半就中断的问题。

• 给每个连接单独维护独立的接收状态：新建和socket列表配套的独立结构，分别存储每个socket对应的字节缓冲区、待解析的消息长度，完全隔离不同连接的接收流程，从根源上避免多连接数据串流。
• 调整内层解析循环逻辑：移除解析到首条身份标识消息就break的硬中断逻辑，循环处理当前缓冲区中所有可完整解析的消息，直到缓冲区中凑不齐下一个完整长度头或消息体时再退出，避免数据滞留。
• 优化解码时机：先把收到的原始字节存入对应socket的字节缓冲区，等凑够对应长度的完整消息后，再对完整消息字节做一次性UTF-8解码，从根源上避免多字节字符拆分导致的解码错误。
• 完善发送端异常处理：发送触发异常时，主动标记无效连接并触发断连清理流程；非阻塞场景下通过select监听socket可写事件再执行发送，避免发送缓冲区满导致的发送中断。

内容的提问来源于stack exchange，提问作者kamui_34