## 新生命网络库


### 标准网络封包协议
经过十多年经验积累以及多方共同讨论，于昨晚凌晨通过了新生命团队的标准网络封包协议，作为网络库NewLife.Net中封包接口的标准实现。（强烈推荐使用标准网络封包协议，用户也可以根据业务需要去自己实现接口）


**标准网络封包协议：<font size="6" color="#ff0000">1 Flag + 1 Sequence + 2 Length + N Payload</font>**  
**<font size="4"><font color="#0000ff">
1个字节标识位，标识请求、响应、错误、加密、压缩等；  
1个字节序列号，用于请求响应包配对；  
2个字节数据长度N，指示后续负载数据长度（不包含头部4个字节），解决粘包问题；  
N个字节负载数据，数据内容完全由业务决定，最大长度65535=64k。  
</font>**

**<font size="5" color="#800080">
该网络封包协议应用于服务端RPC通信、CS通信、Web端、移动端、硬件设备端，10年内不做改变！！！
</font>**


相关讨论点：  
1. **数据长度字段定长**。不同语言实现不便于使用7位压缩编码整数，并且头部定长非常有利于各种过滤器实现。  
2. **数据长度定为2个字节**。2个字节可表示64k的负载数据，可满足99%的业务需要，超过64k的数据，完全可以由业务层进行划分解决。  
3. **粘包问题**。封包协议实现类，根据长度字段拆分负载数据交给业务层，内部带有数据缓冲区，也可以把众多小包重新组合成为一个标准包交给业务层。  
4. **非标干扰数据**。在一个标准包接收之外，可能收到干扰数据，此时可根据长度字段解包，绝大部分干扰数据因为不符合封包格式而被抛弃。  
5. **GPRS网络数据干扰**。在物联网2G领域，运行商可能在标准包之后额外发送一些数据，此数据有可能导致后续解包连锁错误。封包实现带有500ms超时丢弃功能，此时间内未完成解包则清空缓冲区。  
6. **物联网硬件设备实现**。固定4字节的头部长度，非常便于嵌入式C/C++实现协议。  
7. **网页前端实现**。js可操作二进制实现该头部。  
8. **HTML5增强**。HTML5强烈推荐使用WebSocket，无需使用标准封包协议再次封装。本封包协议实现将会避开WebSocket数据包，同一个Tcp端口仅对非WebSocket数据包解包。  

**特别说明**，讨论期间争议最大的莫过于干扰数据导致连续出错，结论如下：  
1. 封包格式可以有效干掉干扰数据  
2. 500ms超时后清空缓冲区，避免干扰数据残留在缓冲区里面影响后续标准包，除非干扰数据能够以小于500ms的速度不断进来  
3. 间隔小于500ms的干扰数据将会摧毁整个封包协议，但是这种情况已经不是程序问题，而是用户网络问题！！！  
