通用的通信框架，不应该与具体的协议绑定：

通信框架服务端的职责如下：

1.提供上层API,用于初始化服务端实例，设置服务端通信相关参数，包括服务端的I/O线程池、监听地址、TCP相关参数、接收和发送缓存区大小等。
2.提供可扩展的编解码插件，用户可以通过扩展的方式实现自定义协议的编码和解码。
3.提供拦截面，用于私有协议栈开发。

服务端最重要的设计原则有三条：

1.服务端只提供上层的API，不与任何具体的协议绑定。
2.服务端提供给用户的API要尽量屏蔽底层的通信细节，防止底层的变更引起上级变更。
3.服务端功能上不要求全，重点在可扩展上。

客户端需要考虑的更多

从技术层面看，要解决链路的可靠性问题，必须周期性地对链路进行有效性检测，目前最流行的做法是心跳检测。

心跳检测机制分为三个层面：

1.TCP层面的心跳检测，即TCP的keep-Alive机制，它的作用域是整个TCP协议栈。
2.协议层的心跳检测，主要存在于长连接协议中。
3.应用层的心跳检测，它主要由各业务通过约定方式定时给对方发送心跳消息实现。

心跳检测的目的是确认当前链路可用，对方活着并且能够正常接收和发送消息。下面熟悉下心跳的检测原理：

Netty的心跳检测机制实际上是利用了链路空闲检测机制实现的额，它的空闲检测机制分为三种：

客户端检测到链路中断后，等待Interval时间，由客户端发起重连操作，如果重连失败，间隔周期Interval后再次发起重连，直到重连成功。

之所以等待Interval时间，主要是让服务端有充足的事件释放句柄资源。

当我们调用消息发送接口的时候，消息并没有真正被写入到socke中，而是先放入NIO通信框架的消息发送队列中，由reactor线程扫描待发送的消息队列，异步地发送给通信对端。但是若不幸的是，消息队列中积压了消息，此时部分链路断开，这回导致部分消息并没有真正发送给通信对端。

第三章通信框架

results matching ""