这篇“ServerSuperIO持续传输大块数据流的两种方式是什么”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“ServerSuperIO持续传输大块数据流的两种方式是什么”文章吧。
网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、重庆小程序开发公司、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了沈河免费建站欢迎大家使用！
以现在物联网的现状或是对物联网的认知，特别是工业物联网，必须具备集成多种数据源的能力。数据源大体分两类：硬件产生和软件产生。如下图：
基于现实情况，作为物联网框架必须具备各类数据的集成能力，以及各种应用场景。以数据大小为例，小到一次接收缓存承载能力范围内的数据，大到超出一次接收缓存承载能力范围的数据，只要网络允许，都有可能。以前的连载文章都是以小的数据包为基础介绍的，这篇文章介绍大块数据流的传输方式。
这种方式是规定好数据包协议的开头和结尾，把大块数据分解成一定长度的小数据包，以协议头+小数据包+协议尾的组合方式分批次进行数据传输。接收到每个批次的数据后，再进行数据校验，拼装数据，还原出完整的数据。示意图如下：
这种方式存在以下几个问题：
（1） 每个包的数据出现问题后，要进行数据补发。要设计好协议，完成补发机制。
（2）数据源是多种多样的，例如：压缩文件、序列化的文件、加密的文件等等，那么就存在每个小数据包的数据有可能会和协议头或协议尾一致，甚至和CRC校验一致的情况，从而导致数据无法正常校验和解析，这时进行补发数据，可能出现同类情况是大概率事件。
选择这种传输大块数据流的方式，要根据现场的实际情况进行选择，规避可能出现的风险，提高项目、产品整体的稳定性。
如果选择这种方式，那么根据前面介绍的文章，就可以实现，网友可以自己动手实现。这篇文章主要介绍下面这种方式。
客户端先发送请求发送数据的命令，并且在命令标识本次要发送数据的长度。如果服务端接收到该请求命令后，根据判断请求数据长度是否在允许范围内，然后返回相同命令数据或其他确认数据给客户端，标识是否允许发送该长度的数据信息。如果可以发送，那么客户端则持续发送数据流，服务端也进行持续接收阶段。示意图如下：
针对这种数据传输的方式，ServerSuperIO专门提供了接口。下面进行详细的介绍。
请求发送0x62指令，共10个字节，校验和为从“从机地址”开始的累加和，不包括“数据报头”、“校验和”和“协议结束”。
请求指令数据帧如下：
服务端接收到该请求命令后，返回同样的命令信息给客户端，客户端则进入持续发送数据的状态。
先发送请求数据命令，代码如下：
+ View Code
接收到服务端的确认信息后，持久发送数据的代码如下：
+ View Code
客户端的代码实现基本上没有什么好讲的，主要是介绍基于ServerSuperIO框架，以设备驱动的方式是怎么实现的。注：以下自控模式实现。
1. 协议接口的实现
DeviceProtocol:ProtocolDriver接口有一个GetPackageLength(byte[] data, IChannel channel, ref int readTimeout)函数接口，data参数是请求发送数据的命令，channel参数是当前IO通道的实例，readTimeout是自定义返回接收数据长度所要使用的时间，如果返回值为0的话，则认为不进入持续接收数据任务。可以通过channel参数直接返回确认信息，具体代码如下：
+ View Code
2. 协议命令的实现
为了实现对大块数据的处理，专门增加一个协议命令，用于解析、保存数据。代码如下：
+ View Code
3. 设备驱动调用协议，并驱动协议命令
在接收大块数据流的时候，会把所有数据信息返回到设备驱动的Communicate接口，其中info参数的Data是当前请求数据的命令，BigData就是持续接收数据的信息，通过调用this.Protocol.DriverAnalysis协议接口驱动协议命令DeviceFileCommand。具体代码如下：
+ View Code
4. 宿主程序服务实例配置注意事项
主要在配置参数中配置StartCheckPackageLength = true,在接数据的过程中会检测相应设备驱动的协议接口GetPackageLength。
+ View Code
图片
以上就是关于“ServerSuperIO持续传输大块数据流的两种方式是什么”这篇文章的内容，相信大家都有了一定的了解，希望小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注创新互联行业资讯频道。