CN101686144A - 一种处理数据的方法、系统和节点设备 - Google Patents

一种处理数据的方法、系统和节点设备 Download PDF

Info

Publication number
CN101686144A
CN101686144A CN200810166212A CN200810166212A CN101686144A CN 101686144 A CN101686144 A CN 101686144A CN 200810166212 A CN200810166212 A CN 200810166212A CN 200810166212 A CN200810166212 A CN 200810166212A CN 101686144 A CN101686144 A CN 101686144A
Authority
CN
China
Prior art keywords
node
file
data block
data
diffusion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN200810166212A
Other languages
English (en)
Inventor
陈庆辉
宋宏达
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN200810166212A priority Critical patent/CN101686144A/zh
Priority to PCT/CN2009/071515 priority patent/WO2010031260A1/zh
Publication of CN101686144A publication Critical patent/CN101686144A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及通信技术领域,特别公开了一种处理数据的方法、系统和节点设备。方法包括:A.位于扩散路径中的第一节点获得文件的第一数据块;其中,所述文件由多个数据块构成;B.当第一节点获得到第一数据块后,将获得的第一数据块提供给第一节点下游的第三节点,并获得该文件的第二数据块;C.重复上述的步骤A和步骤B,直到获得该文件的所有数据块。系统包括:位于扩散路径中的第一节点、位于扩散路径中第一节点下游的第三节点。节点设备包括:获取模块和提供模块。本发明实施例的的技术方案提高了数据处理的效率,避免网络通信阻塞,提高了文件分发和下载的效率。

Description

一种处理数据的方法、系统和节点设备
技术领域
本发明涉及通信技术领域,特别涉及一种处理数据的方法、系统和节点设备。
背景技术
目前,网络在进行大规模的升级时,用户缺乏有效的工具和方法来提升全网的升级效率。对于全网升级,可以利用软件自动实现升级维护;或者可以通过人工控制多个节点设备同时进行升级,这对操作人员的技术要求比较高。采用上述现有技术方法,假设对一个100个节点设备规模的网络进行升级,其升级周期接近1个月。
在对现有技术进行分析后,发明人在发明过程中发现:现有技术所提供的软件升级方法是通过网关节点设备分别对单个节点设备进行下载,或者同时对多个节点设备进行下载;如果采用前者的下载方式,则升级效率比较低、操控复杂;如果采用后者的下载方式,则会造成管理通道流量过大,由于网络中管理通道容量有限,当同时参与下载的节点设备过多时,容易造成通信阻塞。
发明内容
为了提高处理数据的效率,本发明实施例提供了一种处理数据的方法、系统和节点设备。所述技术方案如下:
一方面,提供了一种处理数据的方法,所述方法包括:
A、位于扩散路径中的第一节点获得文件的第一数据块;其中,所述文件由多个数据块构成;
B、当位于所述第一节点获得到所述第一数据块后,将所述获得的第一数据块提供给位于扩散路径中所述第一节点下游的第三节点,并获得所述文件的第二数据块;
C、重复上述的步骤A和步骤B,直到获得所述文件的所有数据块。
另一方面,提供了一种处理数据的系统,所述系统包括:位于扩散路径中的第一节点、位于所述扩散路径中所述第一节点下游的第三节点;其中,
所述第一节点,用于获得文件的第一数据块;其中,所述文件由多个数据块构成;还用于当获得到所述第一数据块后,将所述获得的第一数据块提供给所述第三节点,并继续获得所述文件的第二数据块;直到获得所述文件的所有数据块,并将获得的所述文件的所有数据块依次提供给所述第三节点;
所述第三节点:依次获得所述第一节点发送的数据块,直到获得所述文件的所有数据块。
再一方面,提供了一种节点设备,所述节点设备包括:获取模块和提供模块;
所述获取模块,用于获得文件的第一数据块;其中,所述文件由多个数据块构成;还用于当所述提供模块将获得的所述第一数据块提供给扩散路径中位于自身下游的第三节点设备时,继续获得所述文件的第二数据块;依次直到获得所述文件的所有数据块;
所述提供模块,用于在所述获取模块获得到所述第一数据块后,将获得的所述第一数据块提供给所述第三节点设备;直到将获得的所述文件的所有数据块依次提供给所述第三节点设备。
本发明实施例提供的技术方案的有益效果是:
提高了节点设备在网络中数据处理的效率,避免网络通信阻塞;并且提高了网络中文件分发和下载的效率。
附图说明
图1是本发明实施例1提供的扩散原理示意图;
图2是本发明实施例1提供的扩散拓扑示意图;
图3是本发明实施例1提供的扩散逻辑拓扑另一示意图;
图4是本发明实施例1提供的实现扩散的状态机转换示意图;
图5是本发明实施例1提供的处理数据的方法流程示意图;
图6是本发明实施例1提供的中间节点的上、下游节点重新建立连接流程示意图;
图7是本发明实施例2提供的处理数据的系统的示意图;
图8是本发明实施例2提供的处理数据的系统的另一示意图;
图9是本发明实施例3提供的节点设备示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施例提供的技术方案作进一步地详细描述。
本发明实施例提高了数据处理的效率,解决了在网络中各节点设备之间自动进行文件分发和下载的问题,特别是,在全网升级的时候,大大提高了升级软件分发和下载的速度,并且,本发明实施例也可以用于其它需要文件自动分发和下载的场合。本发明实施例提供了一种处理数据的方法,该方法内容如下
A、位于扩散路径中的第一节点获得文件的第一数据块;其中,文件由多个数据块构成;
B、当位于扩散路径中的第一节点获得到第一数据块后,将获得的第一数据块提供给位于扩散路径中第一节点下游的第三节点,并获得该文件的第二数据块;
C、重复上述的步骤A和步骤B,直到获得文件的所有数据块。
其中,在实现该方法之前,还包括:设置扩散路径,扩散路径具体为树型拓扑结构,且扩散路径有且仅有一个首节点,首节点保存文件的多个数据块。
其中,当上述第一节点为首节点时,则通过服务器配置获得文件的数据块;当上述第一节点为非首节点时,通过其上游节点(称为第二节点)获得文件数据块。该上游节点可以为该扩散路径的首节点,也可以为非首节点,
其中,为了便于说明,按照上述第一节点、第二节点、第三节点在扩散路径中的上、下游的逻辑位置关系,分别将上述第一节点、第二节点、第三节点定义为中间节点,中间节点的上游节点(简称为上游节点,如果第一节点上游直接为首节点时,则该上游节点为首节点)、中间节点的下游节点(简称为下游节点)。请参见下述实施例,对本发明实施例提供的方法进行详细的描述。
实施例1
为了提高数据处理的效率,提高网络上各节点设备之间自动进行文件分发和下载的效率,特别是针对全网升级情况下,提高升级软件分发和下载的速度,本发明实施例提供了一种处理数据的方法,本实施例以针对全网进行升级的场景,待扩散的对象具体是升级软件包为例进行说明,该方法内容如下:
为了能够使软件包在多个节点设备之间并行扩散,达到提高软件包下载速度的目的,本发明实施例所提供的扩散协议的基本思想是:针对软件包中的多个文件,将每个文件切分成数据块,只要本节点从其上游节点获得到一个数据块以后,就可以将该数据块向其下游节点并行地扩散,同时又可以向其上游节点继续请求获得其它数据块。参见图1,本发明实施例提供了一种扩散原理示意图,假设网络中存在节点A、节点B、节点C;且节点A作为首节点,节点A中保存有待扩散的文件,该待扩散的文件被切分成固定大小的数据块1、2、3、4、5、6。在对软件包中的文件进行切分时,通常是根据传输通道的带宽,计算采取多大的数据分片能够达到最大的传输效率来进行切分。切分成的数据块可以为固定大小,也可以根据系统的需求进行切分为不同大小,本发明实施例不限制将文件进行切分时所采用的具体方式。参见图1:
Step1:节点B已经获得到数据块3,则向其下游节点即节点C下发该数据块3;并向其上游节点即节点A继续处理数据块4;
同理,通过Step2、Step3、Step4,四个扩散步骤,实现节点B和节点C最终获得到数据块1、2、3、4、5、6,即获得到待扩散的文件;
其中,当节点B准备好一个数据块以后,就可以同时向其直接下游的所有节点传送自身已经准备好的数据块,图1所提供的示意图中该节点B仅有一个下游节点(节点C),实际上该节点B还可以并行存在多个下游节点,例如当还存在下游节点(节点D)时,节点B在向节点C下发数据块3时,并行地向节点D下发该数据块3,实现并行扩散。节点B是否向各下游节点下发数据块取决于是否收到下游节点的请求。
上述仅以针对软件包中的一个文件的扩散为例进行的说明,同理,当实现了所有的文件的扩散时,也就实现了该软件包的扩散。其中,整个软件包进行扩散的过程需要遵循以下几个主要原则:
1)首先扩散的是包信息描述文件,即pkg(package)文件,然后再依次扩散软件包中的其他文件;
其中,pkg文件描述了本软件包中所有文件的文件名、版本、大小、下载后的存储路径等相关的基础信息,后续的文件扩散将全部依赖于此文件中记载的信息,因此只有pkg文件传输成功,后续的扩散才可以继续进行下去。
2)每个完整的文件分成若干个数据块Block(本实施例以划分为固定大小的数据块,且该数据块大小为32K字节为例),每个Block分成若干个分片(816字节),封装每一个分片至扩散协议帧中,然后分别进行扩散。
3)整个软件包中的多个文件按照顺序依次传输,前一个文件没有传输完成,不会开始下一个文件的传输。
其中,整个软件包中的多个文件在进行传输时,可以采用按序依次传输的方式;也可以采用任意顺序传输的方式,此时需要在接收节点实施确认机制,以判断是否收到的整个软件包中的各个文件,为了便于说明,本实施例以采用按序依次传输的方式传输多个文件为例进行说明。
4)每一个文件的多个数据块Block按照顺序依次传输,前一个Block没有传输完成,不会开始下一个Block的传输。
其中,整个文件中的多个Block在进行传输时,可以采用按序依次传输的方式;也可以采用任意顺序传输的方式,此时需要在接收节点实施确认机制,以判断是否收到的整个文件中的各个数据块Block,为了便于说明,本实施例以采用按序依次传输的方式传输多个数据块Block为例进行说明。
5)分片是扩散的最小单位,但是不需要严格按照顺序扩散。
6)当本节点成功接收到一个数据块Block的数据,会通知其所有下游节点,下游节点可以请求其上游节点传输已经准备好的Block数据。
另外,为了实现整个网络中软件包的扩散,其中,需要构建树形拓扑结构的扩散路径,参见图2,参与扩散的节点根据在树形结构中所处的不同位置和不同行为,分别扮演着三种不同的角色:首节点、中间节点、末节点,分别对应着树形结构中的根节点、中间节点和叶节点。在本发明实施例中提到的上游节点和下游节点,是个相对的概念,如,中间节点相对于首节点来说是下游节点,而相对于末节点来说是上游节点。并且,该扩散拓扑为逻辑拓扑,即针对一个扩散任务构建一个扩散拓扑,参见图3,扩散拓扑1其待扩散的任务为软件包1,扩散拓扑2其待扩散的任务为软件包2,其中,中间节点X既需要获得软件包1,又需要获得软件包2,该中间节点X作为一台独立物理节点设备,其逻辑上隶属于两个扩散拓扑,即分别对应为扩散拓扑1、2的中间节点。为了便于说明,本实施例仅以针对一个软件包的扩散为例进行说明。
综上所述,针对软件包扩散过程以及扩散的原则,各节点之间还需要一些扩散信息协议帧、状态协议帧和命令协议帧进行交互,下面对扩散协议中的所有帧类型及其作用进行详细描述,参见表1,本发明实施例提供了一种标准的协议帧结构:
表1
Figure A20081016621200111
如表1所示,该标准的协议帧结构包括:
魔术字:可以设定为0x6475,即“DU”;其中,本领域技术人员可以获知,具体实现时,可以根据需要设定不同的魔术字,该魔术字只是用于指示具体实现方式的标识,对应不同的实现可以定义不同的魔术字标识。
协议版本号:标识该协议帧的版本,例如,为0x0100,后续版本号高字节不同则不兼容,低字节不同可以兼容;
校验和:可以采用奇偶校验,校验范围从帧类型字段开始,到数据域的结尾;其中,本发明实施例不限制采用的校验算法,还可以采用其他校验算法如MD5校验等实现。
帧类型:从0x01到0x0B,共十一种帧类型,具体定义在后面详述;
扩展帧头长度:设定为0x00表示暂不使用,留作后续版本扩展使用;
文件索引:软件包中不同的文件的唯一标识,从1开始连续编号;
总块数:数据块Block总数,其值可以根据文件大小和Block大小进行计算而获得;
块索引:某个文件中不同数据块Block的唯一标识,从1开始连续编号;
分片总数:某个Block的分片总数。在FileDataReq协议帧中有不同含义,具体定义在后面详述;
片索引:该Block中不同分片的唯一标识,从1开始连续编号;
数据域长度:表示数据域以字节计算的长度;
保留字节:保留作后续版本扩展用;
数据域:根据不同类型的协议帧,具有不同的含义。
针对上述表1提供的标准协议帧结构,参见表2,具体应用于软件包的文件扩散中可以设定为共有11种类型的协议帧:数据FileData、数据请求FileDataReq、数据块已准备BlockReady、数据块已准备响应BlockReadyAck、文件已准备FileReady、文件已准备响应FileReadyAck、链接更新UpdateConnect、扩散停止StopAll、状态通知DuState、状态响应DuStateAck、状态请求DuStateReq,详见下表:
表2
  协议帧类型标识   协议帧名称   协议帧作用
  0x01   FileData   携带分片数据扩散到下游节点
  0x02   FileDataReq   请求上游节点发送数据
  0x03   BlockReady   通知下游节点Block准备好
  0x04   BlockReadyAck   响应BlockReady协议帧
  0x05   FileReady   通知下游节点文件准备好
  0x06   FileReadyAck   响应FileReady协议帧
  0x07   UpdateConnect   通知上、下游节点更新链接
  0x08   StopAll   通知下游节点及其分支停止扩散
  0x09   DuState   状态通知帧
  0x0A   DuStateAck   状态响应帧
  0x0B   DuStateReq   状态请求帧
下面对表2中的11种协议帧分别进行详细描述:
1)FileData协议帧,参见表3,为该数据FileData的结构示意表;
表3
Figure A20081016621200131
参见表3,该FileData协议帧的帧类型为0x01,在数据域中携带了实际要扩散的分片数据,根据网络的传输带宽设定该分片数据的长度,其中,分片数据的长度一般为816个字节,但是对于文件最后一个Block的最后一个分片,可能不足816个字节。
2)FileDataReq协议帧,参见表4和表5,为该数据请求FileDataReq的结构示意表;该FileDataReq协议帧的帧类型为0x02,作用是向上游节点请求发送数据。
表4
Figure A20081016621200132
参见表4,在此协议帧中,如果分片总数字段为0时,表示请求该数据块中的所有分片,此时无数据域;
表5
Figure A20081016621200141
参见表5,如果分片总数字段为非0时,表示需要重新请求的分片总数,所请求的分片索引在数据域中一一列出。此协议帧中片索引字段无效,填0。
3)BlockReady协议帧,参见表6,为数据块已准备BlockReady的结构示意表;
表6
Figure A20081016621200142
参见表6,BlockReady协议帧的帧类型为0x03,作用是通知下游节点本地节点已经准备好的文件的数据块Block,其中的块索引是表示本地节点已经准备好的数据块Block的块名;此协议帧无数据域,“分片总数”字段和“片索引”字段无效,填0。
当本节点接收到一个完整的Block后,就会向自身的所有下游节点发送BlockReady协议帧,而接收到的下游节点通过BlockReadyAck协议帧进行响应。其中,在一个文件的接收过程中,Block是按照顺序发送和接收的,因此BlockReady中的块索引也是按照顺序增长的,所以后续的BlockReady可以起到对之前已发送的BlockReady的重复作用。
4)BlockReadyAck协议帧,参见表7,为数据块已准备响应BlockReadyAck的结构示意表;
表7
Figure A20081016621200151
参见表7,BlockReadyAck协议帧的帧类型为0x04,作用是下游对接收到的BlockReady协议帧进行响应,其中的块索引与接收到的BlockReady协议帧中的相同字段保持一致;此协议帧无数据域,“分片总数”字段和“片索引”字段无效,填0。
5)FileReady协议帧,参见表8,为文件已准备FileReady的结构示意表;
表8
Figure A20081016621200152
参见表8,FileReady协议帧的帧类型为0x05,作用是将本地的文件相关信息通知到所有下游节点,以保持一致;此协议帧帧头中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;此协议帧在数据域携带了一个到多个文件的信息,每个文件的信息由8个字段组成,总长度由数据域长度字段指定。其中,此协议帧在数据域携带的文件信息中各字段含义具体为:
a)文件名:文件名字符串,由16个字节组成;
b)文件索引:文件的唯一标识,由1开始编号,按顺序依次增长;
c)文件优先级:文件扩散的优先级,其数值越小,优先级越高;文件的扩散过程按照文件的优先级来进行:高优先级的文件先扩散,低优先级的文件后扩散,高优先级的文件没有扩散完成时,低优先级的文件不会开始扩散,同优先级文件的扩散顺序可以是任意的,不一定要按照文件索引顺序扩散;
d)文件大小:标识文件的大小,其中,以字节计算该文件大小;
e)已准备好的块数:表示本地已经接收到的或已有的文件块数;由于此字段和BlockReady中的字段含义是相同的,因此当文件接收过程中最后一个或几个BlockReady没有得到响应时,可以通过此协议帧来重发;
f)文件状态:表示该文件扩散的状态,共有以下几种状态:
FileInit(0x00),表示文件状态未知;
FileNotReady(0x01),表示文件没有准备好需要下载更新;
FileReady(0x02),表示本地已有此文件,无需下载更新;
FileUpdateEnd(0x03),表示文件下载更新结束;
g)末文件标识:当此字段为1时,表示此文件为整包中的最后一个文件;当此字段为0时,表示其它文件;
h)保留字节:留作后续扩散使用,此版本中无效,填0。
6)FileReadyAck协议帧,参见表9,为文件已准备的响应FileReadyAck的结构示意表;
表9
参见表9,FileReadyAck协议帧的帧类型为0x06,作用是对上游的FileReady协议帧进行响应;此协议帧帧头中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;该协议帧中作为FileReady协议帧的响应,其各字段的定义同FileReady协议帧中的同名字段定义相同。
7)UpdateConnect协议帧,参见表10,为更新链接UpdateConnect的结构示意表;
表10
Figure A20081016621200172
Figure A20081016621200181
参见表10,UpdateConnect协议帧的帧类型为0x07,作用是在中间节点中止扩散时,协助其上、下游节点完成转接,以达到继续扩散的目的;此协议帧中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;此协议帧将本节点的扩散路径信息封装进数据域,同时发送给上、下游节点;其中,本节点的扩散路径信息具体包括首节点地址、上游节点地址和所有下游节点地址;所有地址由4个字节表示,根据通信协议不同采用不同地址,可以是IP地址、NEID或者其它任何节点的唯一标识。
8)StopAll协议帧,参见表11,为扩散停止StopAll结构示意表:
表11
Figure A20081016621200182
参见表11,StopAll协议帧的帧类型为0x08,作用是命令本节点及所有下游节点中止扩散;此协议帧无数据域,其中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;
当本节点接受到来自上游节点的StopAll协议帧后,会立即停止本节点的扩散进程,并且向自身的所有下游节点扩散发送同样的StopAll协议帧;此协议帧会一直扩散到末节点,达到中止所有节点扩散的目的。
9)DuState协议帧,参见表12,为状态通知DuState结构示意表:
表12
参见表12,DuState协议帧的帧类型为0x09,作用是发送本节点的扩散状态到接收端;此协议帧中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;
其中,DuState协议帧的数据域有两个字段,分别为:
a)节点状态:表示本节点的扩散状态;
b)请求标志:如果请求标志为0时,表示不需要接收端响应本节点的扩散状态;如果请求标志为1时,表示需要接收端响应本节点的扩散状态。
10)DuStateAck协议帧,参见表13,为状态响应DuStateAck结构示意表:
表13
Figure A20081016621200192
Figure A20081016621200201
参见表13,DuStateAck协议帧的帧类型为0x0A,作用是对接收到的状态请求(DuState协议帧或者DuStateReq协议帧)予以响应;此协议帧中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0;此协议帧中“节点状态”字段的定义同DuState协议帧(或DuStateReq协议帧)中的同名字段相同。
11)DuStateReq协议帧,参见表14,为状态请求DuStateReq结构示意表:
表14
Figure A20081016621200202
参见表14,DuStateReq协议帧的帧类型为0x0B,作用是请求接收端发送其节点扩散状态;此协议帧无数据域,其中的“文件索引”字段、“块总数”字段、“块索引”字段、“分片总数”字段和“片索引”字段无效,填0。
以上详细描述了扩散过程中上、下游节点对应的各节点之间进行交互时用到的所有扩散协议帧类型及其作用,为了实现软件包的扩散,发明人定义了软件包扩散所需要的状态机,下面对软件包扩散的状态机中的各个状态以及各状态之间发生迁移的条件进行详细的描述。
参见图4,软件包扩散的状态机有6个状态:正常态NONE、初始态INIT、运行态RUN、阻塞态PEND、完成态CPLD、中止态ABT,下面分别对这六个状态进行描述。
1)NONE:正常态,没有启动扩散;此状态是整个状态机的起始状态和终止状态,属于稳定态。
2)INIT:此状态为软件包扩散的初始化状态,表示扩散信息已成功设置;此状态是进行后续扩散的必经状态。
3)RUN:此状态为软件包扩散的运行状态,表示当前有文件数据正在进行扩散。
4)PEND:此状态为软件包扩散的阻塞状态,表示本节点正在等待上游节点的文件数据。
5)CPLD:此状态为本节点扩散完成状态,表示本节点已经接受完全部文件;停留在此状态是为了等待下游节点完成。
6)ABT:此状态为软件包扩散的中止扩散状态,停留在此状态是为了通知上游和下游节点。
上述6个状态在扩散过程中各个状态间会产生迁移,参见表15,提供了各状态的迁移关系如表所示:
表15
  状态迁移   触发状态迁移的条件说明
  NONE-->INIT   设置扩散信息成功
  INIT-->PEND   1、首节点:接收到应用服务器发来的文件准备信息2、非首节点:接收到上游节点发来的文件准备信息
  PEND-->RUN   检测到上游节点已准备好需要的文件数据,本节点向上游发出数据请求
  RUN-->PEND   检测到上游节点没准备好需要的文件数据
  PEND-->CPLD   首节点收到应用服务器通知“本节点文件接收完成”
  RUN-->CPLD   非首节点判断全部文件接收完成
  CPLD-->NONE   下游节点全部扩散结束(完成扩散或者已退出扩散)
  INIT-->ABT   1、收到清除扩散信息的命令2、收到应用服务器的软件回滚通知3、INIT态停留时间超时
  RUN-->ABT   1、收到用户退出扩散的命令2、收到应用服务器的软件回滚通知3、文件或文件块接收超时
  PEND-->ABT   1、收到用户退出扩散的命令
  2、收到应用服务器的软件回滚通知3、PEND态停留时间超时
  CPLD-->ABT   1、收到用户退出扩散的命令2、收到应用服务器的软件回滚通知
  ABT-->NONE   1、退出消息已通知上游节点、下游节点,并全部收到接收方的确认2、退出消息已通知上游节点、下游节点,虽然没有全部收到接收方的确认,但超时时间到
综上所述,本发明实施中软件包中文件扩散的基本原理和基础知识,下面详细介绍文件扩散的具体工作流程:
基于上述基本原理获知文件扩散是将待扩散的软件包先由服务器下载到首节点,再由首节点按照扩散路径扩散到所有参与扩散软件包的节点节点中;其中,将待扩散的软件包从服务器下载到首节点,可以采用现有的FTP或者其它任何文件下载协议,或者采用通过网管在首节点进行文件配置的方式实现,本发明实施例不限制首节点获得待扩散的软件包的方式。
在文件扩散开始前,还需要由网管工具提前集中计算整个网络的扩散路径,并且将扩散路径以(整个扩散路径的首节点、本节点的上游节点(假设以在扩散路径上的本节点和首节点之间存在一个节点为例)、本节点、本节点的下游节点1、下游节点1的下游节点2,……、下游节点N-1的下游节点N)的形式分别下发到参与扩散软件包的各个节点;并为整个扩散路径中的各个节点分配节点地址,其中,节点地址可以根据网络类型和底层通信协议类型而有所不同,可以是NEID(Net Element Identifier,节点标识)、IP地址或者任何其它唯一识别的节点标识;构建扩散路径时,需要遵循以下几个原则:
1)针对一个独立的逻辑扩散网络,该扩散网络中有且仅有一个首节点;对于一个物理网络可以同时设置多个逻辑扩散网络,并同时扩散;特别需要注意的是:如前文所述,针对一个物理节点而言,通过在该物理节点上启动不同的扩散实例实现该物理节点隶属于不同的扩散网络。
2)每个参与扩散的节点有且仅有一个上游节点(首节点除外)。
3)每个参与扩散的节点可以有0到多个下游节点。
4)扩散网络不能成环,必须保证严格的树型拓扑结构。
5)扩散的逻辑路径与物理通道可以不同,若多条逻辑路径共用一条物理通道,可能会造成通信阻塞,从而降低了扩散效率。优选地,建议逻辑路径与物理通道尽量保持一致,并尽量遵循最短路径或最小代价原则。
按照上述原则,当整个网络所有参与扩散的节点所在的扩散路径设置完毕后,通过向首节点下发扩散开始命令,开始整个网络的文件扩散,参见图5,该软件包的具体扩散实现步骤如下:
步骤101:文件扩散开始,首节点向位于其下游的节点A扩散PKG文件;
其中,PKG文件中包括了所有需要参与扩散的文件相关信息,具体包括包版本号、文件名、文件版本号、文件大小、文件存储路径等。
步骤102:节点A接收到此PKG文件后,在本地建立和维护扩散文件列表。
步骤103:节点A根据PKG文件中的信息向位于自身上游的节点(即首节点)发送FileDataReq协议帧请求文件第一个数据块Block的所有数据分片。
其中,该FileDataReq协议帧的帧头中的分片总数字段为0。
步骤104:首节点接收到FileDataReq请求后,从本地缓存或文件中读取对应文件的Block的数据,分割为多个数据分片,封装入FileData协议帧,依次发送给对应的节点A。
其中,当上游节点执行扩散某文件的动作时,根据该文件的大小将其分割成若干个Block,每个Block又分割为若干个数据分片,封装进FileData协议帧进行发送;本发明根据ECC管理通道的带宽,将每个数据分片的大小定为816字节,其中,每40个数据分片组成一个Block。若将此协议用于其它通信协议时,可以根据通信带宽的不同,进行不同的划分。
步骤105:节点A依次接收来自上游节点的FileData协议帧,提取其中的有效数据,并重新组合成完整的Block,写入到本地缓存或者文件中,并向该节点A的所有下游节点发送BlockReady协议帧。
步骤106:节点A继续请求该文件的下一个Block的数据,直到该文件的所有Block接收完毕。
其中,该节点A向其上游节点(针对本实施例该上游节点即为首节点)请求该文件中的Block的下一个Block的数据时,依旧重复采用上述步骤103至105的方式实现,直到该文件的所有Block接收完毕。
进一步地,当针对中间节点而言,其上游节点准备好数据后,可以向其下游的该中间节点发送FileReady协议帧,该协议帧主要用来发送该上游节点本地文件准备状态的信息,当位于该上游节点的中间节点接收到FileReady协议帧后,根据FileReady协议帧携带的信息更新本地信息,并根据此信息向其上游节点请求相应的文件,FileReady协议帧拥有可靠的传输机制,每一个协议帧都要求得到对端设备的确认;同时,FileReady协议帧携带的信息包含了BlockReady协议帧携带的信息内容,因此在某些情况下也可以代替BlockReady协议帧的作用进行发送。
通过上述步骤101至106,描述了文件扩散的具体实现步骤,由于实际应用时,通信网络传输的过程中会存在误码现象,从而导致协议帧丢失。因此,为了保证协议的健壮性,本发明实施例根据上述不同协议帧的不同作用,定义了不同的确认重传机制,具体内容如下:
1、设定接收端的超时时限
a)针对每个数据块Block而言,协议对每个Block的接收时间设置了超时时限,当到达该超时时限时,接收端还没有接收到该Block的所有数据分片,接收端向其上游节点重新发送Fi leDataReq协议帧进行请求;
其中,Block的超时时限采用类似指数回退算法,分别设定为(3s,3s,6s,12s,24s,48s,48s,……,即Block接收失败后,第一次等待3秒后重新请求,再失败后,等待3秒再重新请求,之后一次类推,等待时间会越来越长,依次为6秒,12秒,24秒,48秒。到达48秒后不再增大等待重传的时间间隔,而是固定以48秒重传。该操作一直持续到该数据块Block传送成功或者超过配置的超时时间(3分钟)。该机制主要是为了防止网络短时阻塞引起的数据丢包,如果一直以很短的时间间隔重发,反而会加重网络阻塞的状况。但如果经过多次重试,单个Block的接收时间超过3分钟(可根据需要进行配置)仍未成功,那么接收端会中止本节点的扩散。
b)针对FileDataReq协议帧而言,接收端在超时时限后重新向上游节点发送FileDataReq协议帧,请求所有数据分片,其中,该帧帧头中的分片总数字段为0。
c)对于Block中某个或多个数据分片的丢失,接收端在超时时限后向上游节点发送FileDataReq协议帧,请求未接收到的数据分片,其中,该帧帧头中的分片总数字段为非0;此过程会重复,直到接收到所有的数据分片或者Block总超时。
2、设定发送端的超时时限
a)针对BlockReady协议帧而言
由于接收端接收来自其上游节点的BlockReady后,会发送BlockReadyAck协议帧进行响应,如果BlockReady或者BlockReadyAck协议帧丢失,上游节点总是用下一个Block的BlockReady协议帧作为重发;
其中,上游节点用下一个Block的BlockReady协议帧作为重发可以对之前所有的BlockReady都进行确认,但其作用范围仅限于单个文件,即本文件的BlockReadyAck只能对本文件之前的BlockReady进行确认;因此,对于该文件的最后一个或几个BlockReady(或BlockReadyAck)协议帧的丢失,是没有后续的BlockReady协议帧进行重发的;此时,上游节点在超时后向下游节点发送FileReady协议帧作为其重发,下游节点接收到FileReady后响应FileReadyAck协议帧;FileReady协议帧拥有可靠的传输机制,每一个协议帧都要求得到对端设备的确认,同时其中携带的信息包含了BlockReady协议帧携带的信息内容,因此在某些情况下也可以代替BlockReady协议帧的作用进行发送。
b)针对FileReady协议帧而言
由于上游节点发送了FileReady协议帧后,下游节点会通过FileReadyAck协议帧进行响应。如果上游节点在设定的超时时限后仍没有得到响应,会重新发送FileReady协议帧;
其中,FileReady协议帧的重发超时时限采用类似指数回退算法,分别为(3s,3s,6s,12s,24s,48s,48s,……),但如果经过多次重试,该FileReady仍未得到下游节点响应,那么上游节点会停止对下游节点的扩散。
综上所述,论述了实际应用中,针对通信网络中出现的协议帧丢失的情况,本发明实施例根据上述不同协议帧的不同作用提供的不同确认重传机制,从而确保了文件扩散过程中数据的正常传输,特别是,由于本发明实施例通过采用将文件切分成数据块(数据分片、甚至更小的传输单位)进行请求和传输,当出现网络丢包等情况时,仅需要重传丢失的那部分数据,从而提高了数据传输的效率,节约了网络传输的带宽。
针对整个构建的扩散网络,扩散路径中的中间节点可能会因为接收到中止扩散命令或者由于其它原因造成扩散中止。例如,中间节点出现故障退出整个扩散过程,进一步地,本发明实施例通过UpdateConnect协议帧,实现协助该中间节点的上、下游节点重新建立链接继续扩散,其中,参见图6,具体实现过程为:
201:中间节点将自身的首节点、上游节点和下游节点信息封装进UpdateConnect协议帧,同时发送给其上游节点和所有下游节点。
中间节点收到中止扩散命令后,向其上游节点发送UpdateConnect协议帧,该UpdateConnect协议帧具体用于将该中间节点的下游节点的信息通知该中间节点的上游节点,该下游节点的信息具体为下游节点的地址信息。
中间节点收到中止扩散命令后,向其下游节点发送UpdateConnect协议帧,该UpdateConnect协议帧具体用于将该中间节点的上游节点的信息通知该中间节点的下游节点,该上游节点的信息具体为上游节点的地址信息;
其中,中间节点封装首节点的目的是为了避免网络中传输的其他协议帧对该UpdateConnect协议帧的影响,如前所述,由于针对不同的扩散网络,其对应的首节点是不同的;因此,通过携带首节点的信息,从而确保接收端收到的协议帧是针对本扩散网络的更新链接UpdateConnect协议帧。
202:上述中间节点的上游节点接收到UpdateConnect协议帧后,根据该协议帧中的下游节点信息添加新的下游节点。
203:上述中间节点的下游节点接收到UpdateConnect协议帧后,根据该协议帧中的上游节点信息更新其上游节点地址。
其中,根据该协议帧中的上游节点信息更新其上游节点地址的步骤具体为:使用该协议帧中的上游节点的地址信息替换该下游节点的原上游节点(即中止扩散的中间节点)的地址信息。
204:中间节点的上游节点和中间节点的下游节点重新建立通信链接,继续执行扩散。
进一步地,为了避免上述UpdateConnect协议帧丢失,确保接收端能够收到UpdateConnect协议帧,中间节点在彻底退出扩散前会周期性多次发送UpdateConnect协议帧(根据具体的需要进行次数的设定,例如为5次),以提高对端节点接收的成功概率;如果发送的UpdateConnect协议帧全部丢失了,那么转接失败,下游节点最终也会退出扩散;如果UpdateConnect协议帧多次发送成功,上游节点和下游节点对重复接收到的UpdateConnect协议帧不予处理。
上述本发明实施例提供的方案,通过将待扩散的软件包先由服务器下载到首节点,再由首节点按照扩散路径下发到所有参与扩散软件包的节点中,,特别是针对电信网络的升级需求,应用本发明实施例提供的技术方案可以提高待升级的电信网络的升级效率,解决了在电信网络上各节点之间自动进行文件分发和下载的问题,特别是在全网升级的时候,大大提高了升级软件分发和下载的速度。本发明同时还可以用于其它需要文件自动分发和下载的场合。
综上所述,本发明实施例提供处理数据的方法,通过利用泛洪式的网络并行传输方式,提高了全网文件扩散效率,通过将文件切分成数据块和数据分片等更小的单位进行请求和传输,在存在网络丢包时仅需要重新传输丢失的数据分片,提高了传输效率,并且由于事先指定参与扩散的节点和计算扩散路径,并下发到各节点,通过下发命令或自动故障检测触发单节点或全网扩散过程的中止,实现整个扩散过程的可管可控。并且,当扩散路径中的中间节点出现异常时,可以通过协议帧通知其上、下游节点扩散路径信息,从而实现扩散路径的转接,不影响全网扩散;并且,传输通道具有通信协议无关性,支持各种电信管理通道协议,包括ECC,IP,OSI等;提供电信级可靠性,基于扩散路径可以支持手工中止扩散,并支持异常时的软件回滚。
实施例2
参见图7,本发明实施例还提供了一种处理数据的系统,该系统包括:位于扩散路径中的第一节点、位于扩散路径中第一节点下游的第三节点;其中,
第一节点,用于获得文件的第一数据块;其中,文件由多个数据块构成;还用于当获得到第一数据块后,将获得的第一数据块提供给位于扩散路径中第一节点下游的第三节点,并继续获得该文件的第二数据块;直到获得该文件的所有数据块,并将获得的该文件的所有数据块依次提供给所述第三节点;
第三节点:依次获得第一节点发送的数据块,直到获得到文件的所有数据块。
进一步地,参见图8,系统还包括:位于扩散路径中第一节点上游的第二节点,
第二节点,用于向第一节点依次提供文件的数据块,直到将文件的所有数据块依次提供给第一节点。
其中,本领域技术人员可以获知,在实际应用时,该第二节点可以是整个扩散路径的首节点。
其中,第一节点,还用于设置超时时限,当达到超时时限,第一节点还没有完整的收到第一数据块,则重新请求获得第一数据块的丢失的数据分片,直到第一节点收到完整的第一数据块。
其中,
第一节点,还用于向第三节点发送数据块已准备消息,获得第三节点发送的数据块已准备响应;相应地,
第三节点,还用于收到第一节点发送的数据库已准备消息后,向第一节点发送数据块已准备响应。
相应地,第一节点,还用于设置超时时限,当达到超时时限,第一节点还没有收到第三节点发送的数据块已准备响应,则第一节点重新向第三节点发送数据块已准备消息,直到第一节点收到第三节点发送的数据块已准备响应。
特别是,当第一节点退出扩散路径时,第一节点,还用于将位于第一节点下游的第三节点的信息通知位于第一节点上游的第二节点,并将第二节点的信息通知第三节点,实现第二节点和第三节点分别根据收到的信息重新建立连接。
其中,当位于该第一节点上游的节点为首节点时,即上述第二节点即为首节点,则该第一节点需要将位于第一节点下游的第三节点的信息通知位于第一节点上游的首节点,并将首点的信息通知第三节点,实现首节点和第三节点分别根据收到的信息重新建立连接。
进一步地,当位于第一节点直接下游的节点为多个时;
第一节点,还用于当获得到第一数据块后,将获得的第一数据块提供给位于扩散路径中第一节点的多个下游节点。
上述系统内各节点之间的信息交互、执行过程等内容,由于与本发明方法实施例基于同一构思,具体内容可参见本发明方法实施例中的叙述,此处不再赘述。
上述本发明实施例提供的方案,提高了数据处理的效率,解决了在电信网络上各节点之间自动进行文件分发和下载的问题,特别是在全网升级的时候,大大提高了升级软件分发和下载的速度。本发明同时还可以用于其它需要文件自动分发和下载的场合。
综上所述,本发明实施例提供处理数据的系统,通过利用泛洪式的网络并行传输方式,提高了全网文件扩散效率的提升,通过将文件切分成数据块和数据分片等更小的单位进行请求和传输,在存在网络丢包时仅需要重新传输丢失的数据分片,提高了传输效率,并且由于事先指定参与扩散的节点和计算扩散路径,并下发到各节点,通过下发命令或自动故障检测触发单节点或全网扩散过程的中止,实现整个扩散过程的可管可控。并且,当扩散路径中的中间节点出现异常时,可以通过协议帧通知其上、下游节点扩散路径信息,从而实现扩散路径的转接,不影响全网扩散;再次,传输通道具有通信协议无关性,支持各种电信管理通道协议,包括ECC,IP,OSI等;提供电信级可靠性,基于扩散路径可以支持手工中止扩散,并支持异常时的软件回滚。
实施例3
参见图9,本发明实施例还提供了一种节点设备,该节点设备包括:获取模块和提供模块,其中,
获取模块,用于获得文件的第一数据块;其中,文件由多个数据块构成;还用于当提供模块将获得的第一数据块提供给扩散路径中位于自身下游的第三节点设备时,继续获得该文件的第二数据块;依次直到获得该文件的所有数据块;
提供模块,用于在获取模块获得到第一数据块后,将获得的第一数据块提供给扩散路径中位于自身下游的第三节点设备;直到将获得的文件的所有数据块依次提供给第三节点设备。
进一步地,本发明实施例提供的节点设备还包括:
时间设置模块,用于设置超时时限,当达到超时时限且还没有完整的收到第一数据块时,则重新请求获得第一数据块的丢失的数据分片,直到获得完整的第一数据块。
进一步地,节点设备的提供模块还包括:
处理单元,用于向第三节点设备发送数据块已准备消息,获得第三节点设备发送的数据块已准备响应。
其中,本发明实施例提供的节点设备的时间设置模块还用于设置超时时限,当达到超时时限,处理单元还没有收到第三节点发送的数据块已准备响应,则重新向第三节点设备发送数据块已准备消息,直到收到第三节点设备发送的数据块已准备响应。
特别是,当节点设备退出扩散路径时,节点设备还包括通知模块,
通知模块,用于将第三节点设备的信息通知第二节点设备;并将第二节点设备的信息通知第三节点设备,实现第二节点设备和第三节点设备分别根据收到的信息重新建立连接。
其中,上述第二节点设备位于扩散路径中本发明实施例提供的节点设备的上游,其中,具体实现时,该第二节点设备可以为整个扩散路径的首节点。
进一步地,当位于节点设备直接下游的节点为多个;相应地,
提供模块,用于将获取模块获得的第一数据块提供给位于扩散路径中本节点设备的多个下游节点设备,直到将获得的文件的所有数据块依次提供给位于该多个下游节点设备。
上述设备内各模块及单元之间的信息交互、执行过程等内容,由于与本发明方法实施例基于同一构思,具体内容可参见本发明方法实施例中的叙述,此处不再赘述。
上述本发明实施例提供的方案,提高了数据处理的效率,解决了在电信网络上各节点之间自动进行文件分发和下载的问题,特别是在全网升级的时候,大大提高了升级软件分发和下载的速度。本发明同时还可以用于其它需要文件自动分发和下载的场合。
综上所述,本发明实施例提供节点,通过利用泛洪式的网络并行传输方式,提高了全网文件扩散效率的提升,通过将文件切分成数据块和数据分片等更小的单位进行请求和传输,在存在网络丢包时仅需要重新传输丢失的数据分片,提高了传输效率,并且由于事先指定参与扩散的节点和计算扩散路径,并下发到各节点,通过下发命令或自动故障检测触发单节点或全网扩散过程的中止,实现整个扩散过程的可管可控。并且,当扩散路径中的中间节点出现异常时,可以通过协议帧通知其上、下游节点扩散路径信息,从而实现扩散路径的转接,不影响全网扩散;并且,传输通道具有通信协议无关性,支持各种电信管理通道协议,包括ECC,IP,OSI等;提供电信级可靠性,基于扩散路径可以支持手工中止扩散,并支持异常时的软件回滚。
本发明实施例中的“接收”一词可以理解为主动从其他模块获得也可以是接收其他模块发送来的信息。
本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的硬件平台的方式来实现,当然也可以全部通过硬件来实施,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求书的保护范围为准。

Claims (19)

1、一种处理数据的方法,其特征在于,所述方法包括:
A、位于扩散路径中的第一节点获得文件的第一数据块;其中,所述文件由多个数据块构成;
B、当位于所述第一节点获得到所述第一数据块后,将所述获得的第一数据块提供给位于扩散路径中所述第一节点下游的第三节点,并获得所述文件的第二数据块;
C、重复上述的步骤A和步骤B,直到获得所述文件的所有数据块。
2、如权利要求1所述的方法,其特征在于,所述方法还包括:
设置扩散路径,所述扩散路径具体为树型拓扑结构,且所述扩散路径有且仅有一个首节点,所述首节点保存所述文件的多个数据块。
3、如权利要求1所述的方法,其特征在于,所述步骤A包括:
所述第一节点获得第二节点发送的所述第一数据块;所述第二节点是位于扩散路径中的所述第一节点上游的节点。
4、如权利要求1所述的方法,其特征在于,所述方法还包括:
所述第一节点设置超时时限,当达到所述超时时限且还没有完整的收到所述第一数据块时,则重新请求获得所述第一数据块的丢失的数据分片,直到收到完整的所述第一数据块。
5、如权利要求1所述的方法,其特征在于,所述步骤B之前还包括:
所述第一节点向所述第三节点发送数据块已准备消息,获得所述第三节点发送的数据块已准备响应。
6、如权利要求5所述的方法,其特征在于,所述获得所述第三节点发送的数据块已准备响应的步骤,具体包括:
所述第一节点设置超时时限,当达到所述超时时限且还没有收到所述第三节点发送的数据块已准备响应,则重新向所述第三节点发送数据块已准备消息,直到所述第一节点收到所述第三节点发送的数据块已准备响应。
7、如权利要求3所述的方法,其特征在于,所述方法还包括:
当所述第一节点退出扩散路径时,所述第一节点将所述第三节点的信息通知所述第二节点,并将所述第二节点的信息通知所述第三节点,实现所述第二节点和所述第三节点分别根据收到的信息,重新建立连接。
8、如权利要求1所述的方法,其特征在于,
根据网络传输带宽,将所述文件划分为大小相同的多个数据块。
9、如权利要求1所述的方法,其特征在于,
位于所述第一节点的下游的节点为多个;
相应地,所述当位于扩散路径中的第一节点获得到所述第一数据块后,将所述获得的第一数据块提供给位于扩散路径中所述第一节点下游的第三节点的步骤,具体包括:
当所述第一节点获得到所述第一数据块后,将获得的所述第一数据块提供给位于扩散路径中所述第一节点的多个下游节点。
10、一种处理数据的系统,其特征在于,所述系统包括:位于扩散路径中的第一节点、位于所述扩散路径中所述第一节点下游的第三节点;其中,
所述第一节点,用于获得文件的第一数据块;其中,所述文件由多个数据块构成;还用于当获得到所述第一数据块后,将所述获得的第一数据块提供给所述第三节点,并继续获得所述文件的第二数据块;直到获得所述文件的所有数据块,并将获得的所述文件的所有数据块依次提供给所述第三节点;
所述第三节点:依次获得所述第一节点发送的数据块,直到获得所述文件的所有数据块。
11、如权利要求10所述的系统,其特征在于,所述系统还包括:位于扩散路径中所述第一节点上游的第二节点,
所述第二节点,用于向所述第一节点依次提供所述文件的数据块,直到将所述文件的所有数据块全部提供给所述第一节点。
12、如权利要求10所述的系统,其特征在于,所述第一节点,还用于设置超时时限,当达到所述超时时限且还没有完整的获得所述第一数据块时,则重新请求获得所述第一数据块的丢失的数据分片,直到所述第一节点获得完整的所述第一数据块。
13、如权利要求11所述的系统,其特征在于,当所述第一节点退出扩散路径时,
所述第一节点,还用于将所述第三节点的信息通知所述第二节点,并将所述第二节点的信息通知所述第三节点,实现所述第二节点和所述第三节点分别根据收到的信息重新建立连接。
14、如权利要求10所述的系统,其特征在于,当位于所述第一节点的下游的节点为多个时;
所述第一节点,还用于当获得到所述第一数据块后,将获得的所述第一数据块提供给位于扩散路径中所述第一节点的多个下游节点。
15、一种节点设备,其特征在于,所述节点设备包括:获取模块和提供模块;
所述获取模块,用于获得文件的第一数据块;其中,所述文件由多个数据块构成;还用于当所述提供模块将获得的所述第一数据块提供给扩散路径中位于自身下游的第三节点设备时,继续获得所述文件的第二数据块;依次直到获得所述文件的所有数据块;
所述提供模块,用于在所述获取模块获得到所述第一数据块后,将获得的所述第一数据块提供给所述第三节点设备;直到将获得的所述文件的所有数据块依次提供给所述第三节点设备。
16、如权利要求15所述的节点设备,其特征在于,所述节点设备还包括:
时间设置模块,用于设置超时时限,当达到所述超时时限且还没有完整的获得所述第一数据块时,则重新请求获得所述第一数据块的丢失的数据分片,直到获得完整的所述第一数据块。
17、如权利要求15所述的节点设备,其特征在于,所述节点设备的提供模块还包括:
处理单元,用于向所述第三节点设备发送数据块已准备消息,获得所述第三节点设备发送的数据块已准备响应。
18、如权利要求15所述的节点设备,其特征在于,当所述节点设备退出扩散路径时,所述节点设备还包括通知模块,
所述通知模块,用于将所述第三节点设备的信息通知位于所述扩散路径中所述节点设备上游的第二节点设备;并将所述第二节点设备的信息通知所述第三节点设备,实现所述第二节点设备和所述第三节点设备分别根据收到的信息,重新建立连接。
19、如权利要求15所述的节点设备,其特征在于,当位于所述节点设备的下游的节点为多个时;相应地,
所述提供模块,用于将所述获取模块获得的所述第一数据块提供给位于扩散路径中所述节点设备的多个下游节点设备,直到将获得的所述文件的所有数据块依次提供给所述多个下游节点设备。
CN200810166212A 2008-09-22 2008-09-22 一种处理数据的方法、系统和节点设备 Pending CN101686144A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200810166212A CN101686144A (zh) 2008-09-22 2008-09-22 一种处理数据的方法、系统和节点设备
PCT/CN2009/071515 WO2010031260A1 (zh) 2008-09-22 2009-04-28 一种处理数据的方法、系统和节点设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200810166212A CN101686144A (zh) 2008-09-22 2008-09-22 一种处理数据的方法、系统和节点设备

Publications (1)

Publication Number Publication Date
CN101686144A true CN101686144A (zh) 2010-03-31

Family

ID=42039081

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810166212A Pending CN101686144A (zh) 2008-09-22 2008-09-22 一种处理数据的方法、系统和节点设备

Country Status (2)

Country Link
CN (1) CN101686144A (zh)
WO (1) WO2010031260A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201911A (zh) * 2011-05-18 2011-09-28 山东中创软件商用中间件股份有限公司 实现同步传输数据的方法和系统
CN103955381A (zh) * 2014-04-04 2014-07-30 京信通信系统(中国)有限公司 管理服务器对终端设备进行批量软件升级方法与系统
CN109085995A (zh) * 2017-06-14 2018-12-25 中国电信股份有限公司 数据动态分片的存储方法、装置和系统
CN110096378A (zh) * 2019-04-29 2019-08-06 杭州涂鸦信息技术有限公司 一种线程间通信方法及相关装置
CN110298031A (zh) * 2019-05-28 2019-10-01 北京百度网讯科技有限公司 一种词典服务系统及模型版本一致性配送方法
CN110704133A (zh) * 2019-09-11 2020-01-17 北京控制工程研究所 一种基于有限状态机的卫星分包遥控接收控制方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109657015B (zh) * 2018-12-25 2023-05-02 四川效率源信息安全技术股份有限公司 一种基于oracle行迁移和行连接的数据提取方法
CN112532728B (zh) * 2020-11-30 2022-09-20 中国航空工业集团公司西安航空计算技术研究所 一种确定性的机载高性能文件传输方法和系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7570649B2 (en) * 2005-02-28 2009-08-04 Alcatel Lucent Forwarding state sharing between multiple traffic paths in a communication network
US7822009B2 (en) * 2005-05-09 2010-10-26 Industrial Technology Research Institute Distributed medium access protocol for wireless mesh networks
US7493406B2 (en) * 2006-06-13 2009-02-17 International Business Machines Corporation Maximal flow scheduling for a stream processing system

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201911A (zh) * 2011-05-18 2011-09-28 山东中创软件商用中间件股份有限公司 实现同步传输数据的方法和系统
CN102201911B (zh) * 2011-05-18 2013-10-30 山东中创软件商用中间件股份有限公司 实现同步传输数据的方法和系统
CN103955381A (zh) * 2014-04-04 2014-07-30 京信通信系统(中国)有限公司 管理服务器对终端设备进行批量软件升级方法与系统
CN109085995A (zh) * 2017-06-14 2018-12-25 中国电信股份有限公司 数据动态分片的存储方法、装置和系统
CN110096378A (zh) * 2019-04-29 2019-08-06 杭州涂鸦信息技术有限公司 一种线程间通信方法及相关装置
CN110096378B (zh) * 2019-04-29 2021-01-08 杭州涂鸦信息技术有限公司 一种线程间通信方法及相关装置
CN110298031A (zh) * 2019-05-28 2019-10-01 北京百度网讯科技有限公司 一种词典服务系统及模型版本一致性配送方法
CN110704133A (zh) * 2019-09-11 2020-01-17 北京控制工程研究所 一种基于有限状态机的卫星分包遥控接收控制方法
CN110704133B (zh) * 2019-09-11 2023-03-31 北京控制工程研究所 一种基于有限状态机的卫星分包遥控接收控制方法

Also Published As

Publication number Publication date
WO2010031260A1 (zh) 2010-03-25

Similar Documents

Publication Publication Date Title
CN101686144A (zh) 一种处理数据的方法、系统和节点设备
US10666537B2 (en) Managing connections for data communications using heartbeat messaging
ES2376893T3 (es) Control de flujo de TFTP por un servidor
WO2021083244A1 (zh) 一种mesh网络设备的多设备批量固件升级的方法
CN100385862C (zh) 一种对光网络单元onu进行版本升级的方法
CN105516221B (zh) 信息推送系统及方法
US10931529B2 (en) Terminal device management method, server, and terminal device for managing terminal devices in local area network
CN111711680A (zh) 基于udp协议的文件断点续传方法及装置
WO2015139359A1 (zh) 无线网络维护方法、装置和系统
CN103973414B (zh) 一种数据传输方法及装置
CN109714409A (zh) 一种消息的管理方法和系统
CN105282803A (zh) 通讯接口和基于通讯接口的信息传递方法及系统
CN109391691A (zh) 一种单节点故障下nas服务的恢复方法及相关装置
CN105847175A (zh) 数据中心网络中的应用层调度方法
WO2013083013A1 (zh) 一种网络设备间的同步方法、网络设备及系统
US11196792B2 (en) Method, device and system for transmitting data
US9300438B2 (en) Method and system for transmitting large object
CN111355764B (zh) 保活报文发送方法、装置、电子设备及可读存储介质
CN114915622B (zh) 一种web端基于http的文件传输方法
WO2007124629A1 (fr) Procédé de traitement de message lmp, unité et noeud de traitement de message lmp
JP2003304273A (ja) パケット中継装置、パケット中継プログラム、およびパケット中継方法
KR100396921B1 (ko) 중계기서버를 이용한 멀티캐스팅 전송 시스템의 오류 제어방법
CN114489730A (zh) 一种远程升级方法及其终端设备、计算机可读存储介质
CN104081728A (zh) 网络管理
CN109688085B (zh) 传输控制协议代理方法、存储介质及服务器

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20100331