标签：9.png command mmu view http source dev 等等 com
感谢唯笑志在分享
原博主原地址：
http://www.cnblogs.com/lsjwq/
目 录
10．持续传输大块数据流的两种方式（如：文件）... 2
10.1 概述... 2
10.2 大块数据流的两种传输方式... 2
10.2.1 协议数据包的方式... 2
10.2.2 请求长度、确认的方式... 3
10.3 实现持续传输大块数据... 4
10.3.1 设计请求发送数据协议... 4
10.3.2 客户端代码实现... 4
10.3.3 ServerSuperIO框架的实现及注意事项... 7
10.4 运行效果... 11
以现在物联网的现状或是对物联网的认知，特别是工业物联网，必须具备集成多种数据源的能力。数据源大体分两类：硬件产生和软件产生。如下图：
基于现实情况，作为物联网框架必须具备各类数据的集成能力，以及各种应用场景。以数据大小为例，小到一次接收缓存承载能力范围内的数据，大到超出一次接收缓存承载能力范围的数据，只要网络允许，都有可能。以前的连载文章都是以小的数据包为基础介绍的，这篇文章介绍大块数据流的传输方式。
这种方式是规定好数据包协议的开头和结尾，把大块数据分解成一定长度的小数据包，以协议头+小数据包+协议尾的组合方式分批次进行数据传输。接收到每个批次的数据后，再进行数据校验，拼装数据，还原出完整的数据。示意图如下：
这种方式存在以下几个问题：
（1） 每个包的数据出现问题后，要进行数据补发。要设计好协议，完成补发机制。
（2）数据源是多种多样的，例如：压缩文件、序列化的文件、加密的文件等等，那么就存在每个小数据包的数据有可能会和协议头或协议尾一致，甚至和CRC校验一致的情况，从而导致数据无法正常校验和解析，这时进行补发数据，可能出现同类情况是大概率事件。
选择这种传输大块数据流的方式，要根据现场的实际情况进行选择，规避可能出现的风险，提高项目、产品整体的稳定性。
如果选择这种方式，那么根据前面介绍的文章，就可以实现，网友可以自己动手实现。这篇文章主要介绍下面这种方式。
客户端先发送请求发送数据的命令，并且在命令标识本次要发送数据的长度。如果服务端接收到该请求命令后，根据判断请求数据长度是否在允许范围内，然后返回相同命令数据或其他确认数据给客户端，标识是否允许发送该长度的数据信息。如果可以发送，那么客户端则持续发送数据流，服务端也进行持续接收阶段。示意图如下：
针对这种数据传输的方式，ServerSuperIO专门提供了接口。下面进行详细的介绍。
请求发送0x62指令，共10个字节，校验和为从“从机地址”开始的累加和，不包括“数据报头”、“校验和”和“协议结束”。
请求指令数据帧如下：
服务端接收到该请求命令后，返回同样的命令信息给客户端，客户端则进入持续发送数据的状态。
先发送请求数据命令，代码如下：
接收到服务端的确认信息后，持久发送数据的代码如下：
客户端的代码实现基本上没有什么好讲的，主要是介绍基于ServerSuperIO框架，以设备驱动的方式是怎么实现的。注：以下自控模式实现。
DeviceProtocol:ProtocolDriver接口有一个GetPackageLength(byte[] data, IChannel channel, ref int readTimeout)函数接口，data参数是请求发送数据的命令，channel参数是当前IO通道的实例，readTimeout是自定义返回接收数据长度所要使用的时间，如果返回值为0的话，则认为不进入持续接收数据任务。可以通过channel参数直接返回确认信息，具体代码如下：
2. 协议命令的实现
为了实现对大块数据的处理，专门增加一个协议命令，用于解析、保存数据。代码如下：
在接收大块数据流的时候，会把所有数据信息返回到设备驱动的Communicate接口，其中info参数的Data是当前请求数据的命令，BigData就是持续接收数据的信息，通过调用this.Protocol.DriverAnalysis协议接口驱动协议命令DeviceFileCommand。具体代码如下：
主要在配置参数中配置StartCheckPackageLength = true,在接数据的过程中会检测相应设备驱动的协议接口GetPackageLength。
图片
《连载 | 物联网框架ServerSuperIO教程》- 10.持续传输大块数据流的两种方式（如：文件）
标签：9.png command mmu view http source dev 等等 com
原文地址：http://www.cnblogs.com/CoderJYF/p/6091448.html
