设备1

等待响应，并加入等待返回消息队列

接收到sessionID的消息

消息发送完成后取一条未过期消息

生成一个带sessionID的消息（sessionID标识消息唯一性）

响应平台收到，标记sessionID的消息已发送成功可能由于网络原因应答多次应答的sessionID的消息如果找不到可以忽略，不做任何处理

设备

判断该sessionID是否处理过

发送消息

空闲时间，发送ping包（也需要生成sessionID）

判断当前是否可发送消息（有等待响应消息不可发送）

处理过

消息发送模块，和上面设备发送流程类似，但又不完全一样，暂省略这里做一下消息定义一种是业务发送的消息，是需要应答的，包括ping消息一种是应答消息，是不需要再应答的，应答消息会包含业务消息的sessionID标记是哪个消息的应答

平台

丢弃消息

响应超时，取出为超时sessionID的消息重发

是否出现发送异常

可以发送新消息

正常

超时并且重试次数用完

发送应答消息

等待

消息处理或者转发消息，省略

有正在发送的消息（不可发送）

发送一条消息

等待消息处理机制实现方式可以是一个有长度队列也可以是带超时时间的队列如果消息队列满直接丢弃消息，可以为消息设置重要级别，最重要消息永不丢弃这个消息队列可以是内存实现也可以用存储实现的，但必须保证线程安全给队列设置最大阈值，超过阈值可以检测网络，重连或者切换udp/tcp

备注（等待服务器响应方式处理逻辑UDP/TCP都需要实现【请求-收到】这个逻辑，收到应答才能确定消息正在被处理） 手机和设备都适用（服务器网络异常处理这块不适用，服务器是被动连接，不能主动连接客户端）单线程设备实现起来比较费劲，但应该可以实现多线程设备会考虑消息统一发到消息队列，另一个线程监听消息队列，有新消息并判断当前可以发送的时候发就发送消息等待响应的实现有两种，一种是真的阻塞等待，一种是立即返回标识等等消息，需要使用到生产者消费者模式，增加消息返回和超时监听，可根据不同设备决定使用哪种方式使用监听模式可以设置等待消息数量，可以处理多条消息，阻塞模式一次只能处理一条消息 如果想减少设备和平台交互次数可以做消息合并发送，和消息合并响应，不建议现在做，会增加复杂度

异常消息处理，看业务需求是丢弃还是重新加入队列还可以做网络检查或者10分钟超时多少次检查网络TCP可以尝试重连，切换udp/tcp