基于TCP和心跳包的自动化通讯模型

1. 服务端与客户端的分配

PC端为服务器.硬件为客户端.

---

2. 建立连接的过程

- 服务端开启监听
- 客户端创建连接,每3秒尝试连接一次,
- 客户端连接成功后,向服务端发送心跳报.每三秒发送一次.连续5次未响应则重连.

---

3. 开启监听线程的问题及解决方案
我自己封装了一个TCP服务端类.
在构造的时候开启监听,并开始阻塞式接收,那么问题来了:
开启监听后不是立刻就有可用连接(时间差),因此这个时候开始阻塞式接收必然报错.
解决方案:
开启监听后等待一段时间(因为3秒连接一次,那么等待超过三秒,则必然会有连接)
我设置了4秒的时间.问题解决.

---

4. 支持脱机模式的解决方案
如果软件打开后.根本没有连接硬件.要脱机使用,怎么办?
解决方案:
- 增加一个是否开启接收方法的标识,
- 在监听方法中,尝试开启接收方法,如果标识为已开启,则跳过.

---

5. 关于硬件断开连接重连问题的说明
如果已经连接的情况下,硬件断开.之后硬件重新开启.会出现什么情况?
TcpClient的阻塞式接收方法的重连异常有效的避免了这个问题.
当再次连接(连接成功)的时候, Receive()阻塞方法会抛出异常.这个时候catch这个异常.不处理,而是继续阻塞.
当然.此时进行阻塞接收的TcpClient已经是新的了.

---

6. 总结一下
1 TcpClient的第一次开启接收,需要特别标识,
2 每次连接的时候检查标识,尝试开启接收线程.
3 硬件主动断开后,重新连接,此时阻塞抛出异常为正常现象.跳过并重新阻塞接收即可.此操作在接收线程内部.接收线程并不受影响.