NewLife/X

大石头 编写于 2020-02-04 22:44:36
4ef44d4
Handlers Loading... Loading... 0001-01-01 08:00:00
INetSession.cs Loading... Loading... 0001-01-01 08:00:00
ISocket.cs Loading... Loading... 0001-01-01 08:00:00
ISocketClient.cs Loading... Loading... 0001-01-01 08:00:00
ISocketServer.cs Loading... Loading... 0001-01-01 08:00:00
ISocketSession.cs Loading... Loading... 0001-01-01 08:00:00
ITransport.cs Loading... Loading... 0001-01-01 08:00:00
NetException.cs Loading... Loading... 0001-01-01 08:00:00
NetHandlerContext.cs Loading... Loading... 0001-01-01 08:00:00
NetHelper.cs Loading... Loading... 0001-01-01 08:00:00
NetServer.cs Loading... Loading... 0001-01-01 08:00:00
NetSession.cs Loading... Loading... 0001-01-01 08:00:00
NetUri.cs Loading... Loading... 0001-01-01 08:00:00
Readme.md Loading... Loading... 0001-01-01 08:00:00
ReceivedEventArgs.cs Loading... Loading... 0001-01-01 08:00:00
SerialPortConfig.cs Loading... Loading... 0001-01-01 08:00:00
SerialTransport.cs Loading... Loading... 0001-01-01 08:00:00
SessionBase.cs Loading... Loading... 0001-01-01 08:00:00
SessionCollection.cs Loading... Loading... 0001-01-01 08:00:00
Setting.cs Loading... Loading... 0001-01-01 08:00:00
SocketHelper.cs Loading... Loading... 0001-01-01 08:00:00
TcpServer.cs Loading... Loading... 0001-01-01 08:00:00
TcpSession.cs Loading... Loading... 0001-01-01 08:00:00
UdpServer.cs Loading... Loading... 0001-01-01 08:00:00
UdpSession.cs Loading... Loading... 0001-01-01 08:00:00
Upgrade.cs Loading... Loading... 0001-01-01 08:00:00
WebSocketSession.cs Loading... Loading... 0001-01-01 08:00:00
Readme.md
## 新生命网络库 ### 标准网络封包协议 经过十多年经验积累以及多方共同讨论,于昨晚凌晨通过了新生命团队的标准网络封包协议,作为网络库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的干扰数据将会摧毁整个封包协议,但是这种情况已经不是程序问题,而是用户网络问题!!!