Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
Handlers
INetSession.cs
ISocket.cs
ISocketClient.cs
ISocketServer.cs
ISocketSession.cs
ITransport.cs
NetException.cs
NetHandlerContext.cs
NetHelper.cs
NetServer.cs
NetSession.cs
NetUri.cs
Readme.md
ReceivedEventArgs.cs
SerialPortConfig.cs
SerialTransport.cs
SessionBase.cs
SessionCollection.cs
Setting.cs
SocketHelper.cs
TcpServer.cs
TcpSession.cs
UdpServer.cs
UdpSession.cs
Upgrade.cs
WebSocketSession.cs

Readme.md

新生命网络库

标准网络封包协议

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

标准网络封包协议:1 Flag + 1 Sequence + 2 Length + N Payload
1个字节标识位,标识请求、响应、错误、加密、压缩等;
1个字节序列号,用于请求响应包配对;
2个字节数据长度N,指示后续负载数据长度(不包含头部4个字节),解决粘包问题;
N个字节负载数据,数据内容完全由业务决定,最大长度65535=64k。

该网络封包协议应用于服务端RPC通信、CS通信、Web端、移动端、硬件设备端,10年内不做改变!!!

相关讨论点:

  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的干扰数据将会摧毁整个封包协议,但是这种情况已经不是程序问题,而是用户网络问题!!!