CN101009641A - 传输大量数据的方法和系统 - Google Patents
传输大量数据的方法和系统 Download PDFInfo
- Publication number
- CN101009641A CN101009641A CNA2006101564276A CN200610156427A CN101009641A CN 101009641 A CN101009641 A CN 101009641A CN A2006101564276 A CNA2006101564276 A CN A2006101564276A CN 200610156427 A CN200610156427 A CN 200610156427A CN 101009641 A CN101009641 A CN 101009641A
- Authority
- CN
- China
- Prior art keywords
- state
- node
- transmission
- data
- child node
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
发明提供一种传输大量数据的方法,应用于银行业务数据处理中,包括:将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化,并且当发生传输中断的情况下,从中断的状态恢复传输过程。本发明还提供一种传输大量数据的系统。利用本发明,在数据传输过程中相关节点登记本节点的状态,可以实现对传输过程的监控,并且如果由于出错导致传输过程中断,可以在后续的过程中根据中断时登记的传输状态恢复传输。
Description
技术领域
本发明涉及网络中的数据传输,特别涉及一种传输大量数据的方法和系统。
背景技术
银行的不同级别的机构间需要经常性的处理数据。需要处理的数据类型一般有两类:实时交易数据和非实时业务数据。实时交易数据一般指通过实时交易系统发送到银行核心业务系统中进行处理的交易数据,此类数据对时间要求非常严格,一般都要求在若干毫秒内能够获取到;非实时业务数据是指类似银行报表、帐表或者其他对时间要求不严格的数据,此类数据对时间要求比较宽松,一般在几小时甚至几天内获取到即可。有时传输的是大量数据,这类数据一般是非实时的,需要传输的时间比较长,需要几小时至几天。
现有技术中,大量数据的传输过程比较简单,发送方将数据准备好后,就开始向接收方传输。在传输过程中,可能由于种种原因导致传输过程中断,例如接收方没有响应,发送方或接收方产生错误而导致传输终止等情况。这些情况下,虽然可能已经传输了很多的内容,甚至是数据已传输结束,仅需要得到接收方的确认即可完成整个数据的传输过程,但是现有的传输方法将传输过程作为一个简单的传输流程,不能确定传输中断时数据传到了哪个状态,也就不能从中断的传输中恢复。
发明内容
本发明的目的是提供一种传输大量数据的方法和系统,以克服现有技术中不能确定传输到了哪个状态,不能从中断的传输中恢复的缺点。
为解决上述技术问题,本发明提供一种传输大量数据的方法和系统是这样实现的:
一种传输大量数据的方法,将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化,并且当发生传输中断的情况下,从中断的状态恢复传输过程。
当子节点向父节点发送数据时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
设置子节点为任务准备状态,对需要传输的数据进行打包、压缩、加密操作;
子节点任务准备完毕后置状态为传输准备就绪,向父节点发出申请发送文件请求,并在收到返回的请求应答后置状态为ftp传输开始;
父节点收到发来的申请发送文件请求后将自身状态设为ftp传输等待,等待子节点开始ftp传输;
子节点向父节点传输数据,并在传输完毕后将状态置为ftp传输结束;
子节点向父节点确认完成数据发送,将自身状态设为任务结束;
父节点收到子节点发来的确认完成数据发送后将自身设为任务到达状态,对到达的数据进行解密、解压缩、解包后将状态设为任务结束。
当父节点从子节点接收数据时,在子节点向父节点发送数据之前还包括:
置父节点状态为向子节点请求传输任务,向子节点发出接收文件任务请求,并在收到应答后置状态为请求传输等待;
子节点收到发来的接收文件任务请求后置状态为请求状态检查,并返回应答消息到父节点;
子节点检查父节点是否为请求传输等待状态,如果是,子节点置自身状态为任务准备状态。
当父节点发送数据到子节点时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
父节点对需要传输的数据进行打包、压缩、加密,完成这些操作后将状态置为任务准备就绪;
父节点通知子节点取文件,收到返回的应答后将状态置为ftp传输等待;
子节点收到发来的取文件的通知后,将状态置为就绪状态检查,确认父节点状态是否为ftp传输等待;如果是,置自身状态为ftp传输开始;
父节点向子节点传输数据,传输完毕后子节点状态置为ftp传输结束,并将父节点状态置为任务结束;
子节点置为任务到达状态,对到达的数据解密、解压缩、解包,执行完这些操作后置状态为任务结束。
当子节点从父节点接收数据时,在父节点发送数据到子节点之前还包括:
设置子节点状态为向子节点请求传输任务,向父节点申请发送申请文件,并在收到父节点的应答后将状态设为请求传输等待;
父节点收到发来的申请发送文件请求后将自身状态设为请求状态检查,检查子节点状态是否为请求传输等待,如果是,则置自身为任务准备状态。
当中间节点从子节点接收向父节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
子节点发送数据到中间节点按照所述子节点向父节点发送数据过程执行,并在中间节点到达传输准备就绪状态时,中间节点发送数据到父节点,按照所述子节点向父节点发送数据过程执行。
当中间节点从子节点接收向子节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
子节点发送数据到中间节点按照所述子节点向父节点发送数据过程执行,并在中间节点到达传输准备就绪状态时,中间节点发送数据到子节点,按照所述父节点发送数据到子节点过程执行。
当中间节点从父节点接收向子节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
父节点发送数据到中间节点按照所述父节点向子节点发生数据过程执行,并在中间节点到达传输准备就绪装填时,中间节点发送数据到子节点,按照所述父节点向子节点发生数据过程执行。
当第一节点请求的数据在跨过第二节点的第三节点上,第二节点需要接收文件请求的转发时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
第一节点置状态为向子节点请求传输任务,向第二节点申请传输文件,并在收到第二节点的应答后置状态为请求传输等待;
第二节点收到申请传输文件请求后置自身状态为请求状态检查,检查第一节点是否为请求传输等待,如果是,将自身状态置为向子节点请求传输任务;
第二节点向第三节点申请传输文件,并在收到第三节点的应答后置状态为请求传输等待;
第三节点收到申请传输文件请求后置自身状态为请求状态检查,检查第二节点是否为请求传输等待,如果是,将自身置为任务准备状态;
第三节点对要传输的数据进行打包、压缩、加密。
所述加密采用文件密钥对传输的数据文件头部加密的方式。
所述采用文件密钥对传输的数据文件头部加密由以下方式实现:
由文件传输的签到口令得到文件密钥,系统在任务开始时,采用该文件密钥将经打包、压缩后的数据包的头部信息进行加密,并将文件密钥作为该文件的属性通过命令通道传输到目标节点;
任务到达目标节点后,系统利用从源节点传输来的文件密钥将数据包解密并还原。
包括参与数据传输的节点,其中,
所述传输节点包括状态表,传输节点利用该状态表将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化;
所述传输节点包括监控模块,用于监控传输过程所处的状态,并在传输过程发生中断时将监控到的状态发送到恢复模块;
所述传输节点包括恢复模块,用于根据收到的中断状态将传输过程从该状态恢复。
所述状态表包括如下状态:
任务准备状态,该状态对要传输的数据进行打包、压缩、加密操作;
任务到达状态,该状态对到达的传输任务进行解密、解压、解包操作;
传输准备就绪状态,该状态根据节点在传输过程中的位置以及出现的时机不同分为:
该状态出现在子节点且该节点是数据的发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向父节点发出开始传输的请求,并在请求返回应答后,系统将状态改变为ftp传输开始状态;
该状态出现在子节点且该节点是数据的接收方,则表示该任务的数据已经全部从父节点获取结束,系统将该状态置为任务到达状态;
该状态出现在父节点且该节点是数据的发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向其子节点发出开始获取请求,并在请求返回应答后,系统将状态置为ftp传输等待状态;
该状态出现在父节点且该节点是数据的接收方,则表示该任务的数据已经全部从子节点获取结束,系统将该状态置为任务到达状态;
就绪状态检查,该状态出现在子节点,当父节点向子节点传输数据,或子节点向父节点获取数据时,子节点向父节点检查,确认其状态是否已经变成ftp传输等待,如果是则子节点启动ftp请求开始发送或接收数据;
ftp传输开始状态,该状态出现子节点,系统根据该状态启动ftp请求,向其父节点发送或接收数据文件,当ftp请求结束后,系统将该状态置为ftp传输结束状态;
ftp传输结束状态,该状态出现子节点,根据ftp的发送或接收方向的不同分为:
ftp方向为发送,系统向对方节点发送传送数据结束的请求,并将对方节点状态置为传输准备就绪;
ftp方向为接收,系统向对方节点发送传送数据结束的请求,并将对方节点状态置为任务结束;
任务结束,该状态是一个最终状态,表示任务顺利结束;
所述状态表还包括如下状态:
结束状态检查,该状态出现在父节点,系统根据此状态,向子节点检查该节点任务是否结束;
向子节点请求传输任务,该状态发生在子节点向父节点获取数据或父节点向子节点获取数据时,系统根据此状态向对方节点发送请求获取数据的申请,对方节点收到申请后,置状态为请求状态检查,同时返回应答到请求节点,请求节点在收到应答后将本地状态置为请求传输等待;
请求状态检查,系统根据此状态向对方节点检查对方节点状态是否为请求传输等待,在确认后,将本地状态置为任务准备状态;
ftp传输等待,该状态是被动等待状态,当对方节点的状态从ftp传输开始变为ftp传输结束后,由对方节点发送请求将本地状态置为传输准备就绪或任务结束;
请求传输等待,该状态是被动等待状态,当对方节点的状态从任务准备状态变为传输准备就绪后,由对方节点发送请求将本地状态置为就绪状态检查;
任务失败,该状态是一个最终状态,表示任务失败。
由以上本发明提供的技术方案可见,本发明将数据传输过程从任务添加到结束划分为不同的任务状态,并设定不同任务状态对应的具体处理和随之发生的状态改变,这样,在数据传输过程中相关节点登记本节点的状态,可以实现对传输过程的监控,并且如果由于出错导致传输过程中断,可以在后续的过程中根据中断时登记的传输状态恢复传输。
附图说明
图1为银行系统不同级别机构间的树形关系图;
图2为基本的数据传输关系图,分为图2-1和图2-2;
图3为组合的数据传输关系图,分为图3-1、图3-2和图3-3;
图4为子节点向父节点传输数据的流程图;
图5为子节点从父节点接收数据的流程图;
图6为父节点向子节点传输数据的流程图;
图7为父节点从子节点接收数据的流程图;
图8为从子节点接收向父节点转发的流程图;
图9为从子节点接收向子节点转发的流程图;
图10为从父节点接收向子节点转发的流程图;
图11为接收文件请求的转发的流程图
具体实施方式
本发明的核心是提供一种传输大量数据的方法和系统,将传输过程划分为不同的状态,在每个状态执行针对该状态的动作,完成整个传输过程,并且当发生传输中断的情况下,从中断的状态恢复传输过程。
为了使本技术领域的人员更好地理解本发明方案,下面结合附图和实施方式对本发明作进一步的详细说明。
本领域技术人员知道,银行的机构可以分为不同的级别,例如总行、一级分行、二级分行和网点等,银行系统需要在不同级别的机构间进行数据传输。这些银行机构间的关系可以由树形结构来表示,图1示出了银行系统不同级别机构间的树形关系。该树形关系的节点中,任何一个节点都可以与父节点或子节点进行数据传输,也可以与通过父节点与该父节点的其它子节点进行数据传输,并可依此类推得到任何两个节点之间的数据传输都可以由这些情况的组合实现。
这些传输关系中,作为父节点的一般为服务器(Server),作为子节点的一般为客户端(Client),数据在服务器和客户端的传输方向的不同,节点相应的对数据的处理是不同的。因此,基本的数据传输关系可以分为以下两种:子节点传输数据到父节点,父节点传输数据到子节点。图2示出了基本的数据传输关系,阴影的节点表示数据源所在的节点。图2-1中为子节点传输数据到父节点,根据节点发送接收关系的不同,又可分为:a1,向父节点发送(put);b1,从子节点接收(get)。类似的,图2-2中为父节点传输数据到子节点,根据节点发送接收关系的不同,又可分为:a2,向子节点发送;b2,从父节点接收。本发明所采用的底层传输机制可以是proftpd技术,该技术比较成熟且开放,且除了提供基本的数据传输功能外,还提供了对数据断点续传、流量控制以及自定义用户机制,而且,该技术支持大量数据文件的传输,并且可以不对数据文件做任何更改的情况下实现大量数据的传输。
子节点传输数据到父节点的数据处理流程如下:
(1)文件所在节点(即子节点)检测到有需要向父节点发送的数据文件。
(2)向父节点登记put任务,父节点做相关任务登记记录。
(3)子节点作为client向父节点server提交上传请求,将文件发送到父节点。
(4)双方完成文件传输,分别记录各自任务处理状态(子节点记录任务已经完成,父节点记录文件已经到达)。
(4’)若双方未完成文件传输而意外中断,则由双方节点各自记录状态,由子节点下一次发现该传输任务时触发断点续传或重新传输,直至文件传输成功。
父节点传输数据到子节点的数据处理流程如下:
(1)文件所在节点(即父节点)检测到有需要向子节点发送的数据文件。
(2)向子节点登记get任务,子节点做相关任务登记记录。
(3)子节点作为client向父节点server提交下载请求,接收文件。
(4)双方完成文件传输,分别记录各自任务处理状态(父节点记录任务已经完成,子节点记录文件已经到达)。
(4’)若双方未完成文件传输而意外中断,则由双方节点各自记录状态,由子节点在下一次发现该传输任务时触发断点续传或重新传输,直至文件传输成功。
基于上述基本数据传输流程,还有组合的数据传输流程,如图3所示。作为中间节点,图3-1中从子节点接收,向父节点发送;图3-2中从子节点接收,向子节点发送;图3-3中从子节点从父节点接收,向子节点发送。
本发明根据上述内容,将数据传输过程从任务添加到结束(成功或者失败)划分为不同的任务状态,并设定不同任务状态对应的具体处理和随之发生的状态改变。具体如下表所示:
任务状态 | 状态名称 | 具体处理 |
PREPARE | 任务准备状态 | 对要传输的数据进行打包、压缩、加密等操作 |
ARRIVE | 任务到达状态 | 对到达的传输任务进行解密、解压、解包等操 |
作 | |||
XFER_OK | 传输准备就绪 | 该状态根据节点在传输过程中的位置(子节点或父节点)以及出现的时机不同(任务开始或结束)分别有不同的处理模式:1、该状态出现在子节点且该节点是数据发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向其父节点发出开始传输的请求,并在请求返回应答后,就将状态改变为XFER_ST状态;2、该状态出现在子节点且该节点是数据的接收方,则表示该任务的数据已经全部从父节点获取结束,系统将会将该状态改成ARRIVE状态;3、该状态出现在父节点,且该节点是数据的发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向其子节点发出开始获取的请求,并在请求返回应答后,就将状态改变为XFER_ED状态;4、该状态出现在父节点且该节点是数据的接收方,同2 | |
XFER_CHK | 就绪状态检查 | 该状态只出现在子节点,当父节点向子节点传输数据时(或子节点向父节点获取数据),子节点需要向父节点检查、确认其状态是否已经变成XFER_ED,如果确认则子节点就启动一个ftp请求开始put或get数据,这样可以确保两边的状态一致 | |
XFER_ST | ftp传输开始 | 该状态只出现子节点,系统根据该状态将启动 |
一个ftp请求,向其父节点put或get数据文件,当ftp请求结束后,系统会自动将该状态改成XFER_END状态 | ||
XFER_END | ftp传输结束 | 该状态只出现子节点,根据ftp的方向(put或get)不同,其操作也不相同:1、如果ftp方向为put,系统将会向对方节点发送一个传送数据结束的请求,并将对方节点状态修改为XFER_OK;2、如果ftp方向为get,系统将会向对方节点发送一个传送数据结束的请求,并将对方节点状态修改为FINISH |
FIN_CHK | 结束状态检查 | 该状态只出现在父节点,系统根据此状态,向子节点检查该节点任务是否结束 |
GET_REQ | 向子节点请求传输任务 | 该状态发生在子节点向父节点获取数据或父节点向子节点获取数据的情况下,系统将根据此状态向对方节点发送请求获取数据的申请,对方节点在接到申请后,将本节点状态修改为REQ_CHK,同时返回应答给请求节点,请求节点在得到应答后将本地状态修改为REQ_WAIT |
REQ_CHK | 请求状态检查 | 系统将根据此状态向对方节点发送一个检查对方节点状态是否为REQ_WAIT的请求,在确认后,将本地状态修改为PREPARE |
XFER_ED | ftp传输等待 | 该状态是一个被动等待状态,只有当对方节点的状态从XFER_ST变为XFER_END后,才能够由对方节点发送请求将本地状态从XFER_ED修改为XFER_OK或FINISH |
REQ_WAIT | 请求传输等待 | 该状态是一个被动等待状态,只有当对方节点的状态从PREPARE变为XFER_OK后,才能够由对方节点发送请求将本地状态修改为XFER_CHK |
FINISH | 任务结束 | 该状态是一个最终状态,表示任务顺利结束 |
IMPOSSIBLE | 任务失败 | 该状态是一个最终状态,表示任务因为某种不可以修复的错误而失败 |
表1.任务的状态和具体处理
这样,将发送和接收节点所在数据传输的过程划分为不同的状态,在数据传输该过程中,相关节点登记本节点的状态,如果由于出错导致传输过程中断,可以在后续的过程中根据中断时登记的传输状态恢复传输。
同一个节点间的状态转化为本地状态转化,由本地节点的数据传输过程处理触发状态转化,主要包括:PREPARE到XFER_OK,ARRIVE到FINISH。
不同节点间根据任务当前的状态,任务的目标节点和传输方向等条件,触发对方节点的状态转化。具体的,通过向对象节点发送传输控制命令请求,并根据请求结果切换任务状态。传输控制命令请求的发送和应答的接收必须通过命令通道完成,命令通道支持包括如下表所示的内容:
命令类型 | 命令名 | 含义说明 |
传输控制0X | GETREQ | 通知下一节点处理“接收文件任务请求” |
REQCHK | 与上一节点确认已经接收到“接收文件任务请求”的通知 | |
PUTBEG | 子节点向父节点申请发送文件 | |
PUTEND | 子节点向父节点确认已经发送文件完成 | |
GETBEG | 父节点通知子节点取文件 | |
GETCHK | 子节点和父节点确认已经接收到“取文件通知” | |
GETEND | 子节点完成取文件操作,向父节点确认 | |
FINCHK | 检查对象节点是否任务已经完成 |
表2.传输控制命令表
每个状态并不是固定和某个命令相结合,而是根据条件动态的选择一个命令执行,比如:XFER_OK状态,可以对应多个命令,如0XGETBEG、0XPUTBEG,随着节点的位置(子节点、父节点)不同或者任务方向(put或get)不同,选择的命令也会不同。以下列举不同的实施例进行说明。
图4示出了子节点向父节点传输数据的过程。该任务的发起方是子节点A,数据源初始在子节点A上,父节点B是数据的接收方,也是任务的目标节点。整个传输过程由子节点驱动,父节点只需要被动的响应(父节点仅主动处理传输结束后的处理和完成)。
该过程具体为:
PREPARE:子节点对需要传输的数据进行打包、压缩、加密等操作;
XFER_OK:子节点向父节点发出申请发送文件,即执行0XPUTBEG,并在收到返回的请求应答后,将自身的状态更改为XFER_ST;
XFER_ED:父节点此时是被动等待状态;
XFER_ST:ftp传输开始,子节点向父节点传输数据,并在ftp传输完毕后,更改自身状态为XFER_END;
XFER_END:子节点ftp传输结束,向父节点确认已经发送文件完成,即执行0XPUTEND,将父节点状态更改为XFER_OK,子节点自身状态更改为FINISH;
XFER_OK:父节点已从子节点接收数据结束,将自身状态更改为ARRIVE;
ARRIVE:父节点对到达的数据进行解密、解压缩、解包等操作,并将自身状态更改为FINISH;
FINISH:父节点顺利结束传输任务。
可见,该过程一共有13个状态。
图5示出了子节点从父节点接收数据的过程。该任务发起是子节点A,数据源在父节点B上,A是数据的接收方,这是一种较为复杂的传输任务,这种任务模式种一共由11种任务状态构成。任务整个过程既有由A来驱动的部分,也有由B来驱动的部分,双方共同协调完成。在任务的整个过程中,通过两次检查来保证任务的两方状态上的协调,防止因为两边状态不一致而造成任务的失败。
该过程具体为:
GET_REQ:子节点向父节点申请发送文件,即执行0XGETREQ,父节点收到请求后更改状态为REQ_CHK,并返回应答消息给子节点,子节点得到应答后将状态更改为REQ_WAIT;
REQ_CHK:父节点向子节点发送一个检查状态是否为REQ_WAIT的请求0XREQCHK,在确认后,将本地状态修改为PREPARE;
PREPARE:父节点对需要传输的数据进行打包、压缩、加密等操作,并在完成后将状态置为XFER_OK;
XFER_OK:父节点通知子节点取文件,即执行0XGETBEG,并在返回应答后,就状态改变为XFER_ED状态;
XFER_CHK:子节点向父节点检查,确认其状态已变成XFER_ED,即执行0XGETCHK,子节点启动一个ftp请求开始get数据,这样可以确保两边的状态一致;
XFER_ST:ftp传输开始,父节点向子节点传输数据,并在ftp传输完毕后,子节点更改自身状态为XFER_END;
XFER_END:子节点完成从父节点取文件,向父节点确认,即执行0XPUTEND,并将父节点状态修改为FINISH;
XFER_OK:子节点已从父节点接收数据结束,将自身节点更改为ARRIVE;
ARRIVE:子节点对到达的数据进行解密、解压缩、解包等操作,并将自身状态更改为FINISH;
FINISH:子节点顺利结束传输任务。
图6示出了父节点向子节点传输数据的过程。该任务发起方和数据源都是父节点B,A是数据的接收方,这种任务模式中一共由8种任务状态构成。整个过程既有由A来驱动的部分,也有由B来驱动的部分,双方共同协调完成。该过程是图5所示过程的一部分,因此省略对该过程的描述。
图7示出了父节点从子节点接收数据的过程。该任务发起是父节点B,但数据源在子节点A上,B是数据的接收方。这种任务模式种一共由10种任务状态构成。任务整个过程既有由A来驱动的部分,也有由B来驱动的部分,双方共同协调完成。在任务的整个过程中,通过若干次检查来保证任务的两方状态上的协调,防止因为两边状态不一致而造成任务的失败。
该过程具体为:
GET_REQ:父节点向子节点发出接收文件任务请求,即执行0XGETREQ,子节点收到请求后更改状态为REQ_CHK,并返回应答消息给父节点,父节点得到应答后,将自身状态更改为REQ_WAIT;
REQ_CHK:子节点向父节点发送一个检查对方节点状态是否为REQ_WAIT的请求,在确认后,子节点将本地状态修改为PREPARE;
之后的过程与图4相同,不再赘述。
数据传输不仅存在于两个节点之间,还经常存在于跨节点间的传输。跨节点文件传输过程实际上可以分解成是若干个基本传输单元的组合,不过在单个与单个传输单元之间的转发根据具体的传输方向或者传输组合的不同也有着不同的处理方式,跨节点传输主要存在如下3种传输模式和1种跨节点请求模式:
从子节点接收向父节点转发;
从子节点接收向子节点转发;
从父节点接收向子节点转发;
接收文件请求的转发。
以下分别介绍。
图8示出了从子节点接收向父节点转发的过程。如图所示,中间节点B负责任务的路由判断,如果任务目标节点不是本节点,将会在向下一个节点发出开始传输的请求,如果本节点是目标节点,则直接结束本任务,将状态更新为FINISH。该过程可以分解为两个图4过程,子节点A向中心节点B发送数据相当于子节点向父节点发送数据,中心节点B接收后向父节点C发送数据也相当于子节点向父节点发送数据。
图9示出了从子节点接收向子节点转发的过程。如图所示,该过程可以分解为图4和图6。任务从子节点A发起,向中心节点B发送数据,相当于子节点向父节点发送数据,中心节点B接收后向子节点C发送数据,相当于父节点向子节点发送数据。
图10示出了从父节点接收向子节点转发的过程。类似的,该过程可以分解为两个图6。
图11示出了接收文件请求的转发。该情况具体为:节点A请求的数据文件放在节点C上,因此传输请求就需要被跨节点转发到节点C,然后由节点C进行处理,再传输到节点A。
该过程具体为:
GET_REQ:节点A向节点B申请传输文件,即执行0XGETREQ,节点B收到请求后更改状态为REQ_CHK,并返回应答消息给节点A,节点A得到应答后将状态更改为REQ_WAIT;
REQ_CHK:节点B向节点A发送一个检查状态是否为REQ_WAIT的请求0XREQCHK,在确认后,将本地状态修改为GET_REQ;
GET_REQ:节点B向节点C申请传输文件,即执行0XGETREQ,节点C收到请求后更改状态为REQ_CHK,并返回应答消息给节点B,节点B得到应答后将状态更改为REQ_WAIT;
REQ_CHK:节点C向节点B发送一个检查状态是否为REQ_WAIT的请求0XREQCHK,在确认后,将本地状态修改为PREPARE;
PREPARE:节点C对需要传输的数据进行打包、压缩、加密等操作。
由以上各实施例可见,每个状态并不是固定和某个命令相结合,而是根据条件选择一个命令执行,例如:XFER_OK这个状态可以对应多个命令0XGETBEG、0XPUTBEG,随着节点的位置(子节点、父节点)不同或者任务方向(put或get)不同,系统的选择也会不同。当在“子节点向父节点发送”的传输单元中,系统在处理XFER_OK状态时,将会向父节点发送0XPUTBEG命令,通知父节点将其状态改为等待传输(XFER_ED)状态;而在“子节点从父节点接收”传输单元中,则正好相反,系统将会向子节点发送0XGETBEG的命令,通知子节点通过proftpd从父节点取数据文件。
此外,数据传输系统传输的实体是数据文件,银行业内的数据是极其重要的数据,必须保证其在传输过程中的安全,所以需要对数据实体进行加密。
传统的三级密钥体系要求在跨节点的情况下必须进行密钥转换的操作。作为一般的报文,转加密不存在什么问题,但是如果加密的对象是大数据量的文件的情况下必然造成大量系统资源浪费和传输时间增加,从实现上看使用传统模式的三级密钥体系不现实。
本发明的文件传输系统从三级密钥体系出发,以此为基础,采用文件密钥加密。具体的,只用文件密钥对文件头部加密,该文件密钥是由文件传输的签到口令经过运算得到,并保存在本地。系统在任务开始时,用文件密钥将打包、压缩后的数据包的头部信息进行加密,然后将文件密钥作为该任务的一个属性通过命令通道传输到任务的目标节点,而且,在传输命令通道的通讯过程中该文件密钥是受三级密钥体系保护的,当任务到达目标节点后,系统就会用从源节点传输来的文件密钥将数据包解密,并还原。从而用最少的资源、时间消耗保证了大批量数据文件的安全传输。
以下介绍本发明提供的传输大量数据的系统。
传输大量数据的系统包括参与数据传输的节点,其中,
传输节点包括状态表,传输节点利用该状态表将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化;所述状态表如表1所示;
传输节点包括监控模块,用于监控传输过程所处的状态,并在传输过程发生中断时将监控到的状态发送到恢复模块;
传输节点包括恢复模块,用于根据收到的中断状态将传输过程从该状态恢复。
由以上实施例可见,本发明将发送和接收节点所在数据传输的过程划分为不同的状态,在数据传输该过程中,相关节点登记本节点的状态,可以实现对数据传输过程的监控,而且如果由于出错导致传输过程中断,可以在后续的过程中根据中断时登记的传输状态恢复传输。
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。
Claims (14)
1、一种传输大量数据的方法,其特征在于,将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化,并且当发生传输中断的情况下,从中断的状态恢复传输过程。
2、如权利要求1所述的方法,其特征在于,当子节点向父节点发送数据时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
设置子节点为任务准备状态,对需要传输的数据进行打包、压缩、加密操作;
子节点任务准备完毕后置状态为传输准备就绪,向父节点发出申请发送文件请求,并在收到返回的请求应答后置状态为ftp传输开始;
父节点收到发来的申请发送文件请求后将自身状态设为ftp传输等待,等待子节点开始ftp传输;
子节点向父节点传输数据,并在传输完毕后将状态置为ftp传输结束;
子节点向父节点确认完成数据发送,将自身状态设为任务结束;
父节点收到子节点发来的确认完成数据发送后将自身设为任务到达状态,对到达的数据进行解密、解压缩、解包后将状态设为任务结束。
3、如权利要求2所述的方法,其特征在于,当父节点从子节点接收数据时,在子节点向父节点发送数据之前还包括:
置父节点状态为向子节点请求传输任务,向子节点发出接收文件任务请求,并在收到应答后置状态为请求传输等待;
子节点收到发来的接收文件任务请求后置状态为请求状态检查,并返回应答消息到父节点;
子节点检查父节点是否为请求传输等待状态,如果是,子节点置自身状态为任务准备状态。
4、如权利要求2所述的方法,其特征在于,当父节点发送数据到子节点时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
父节点对需要传输的数据进行打包、压缩、加密,完成这些操作后将状态置为任务准备就绪;
父节点通知子节点取文件,收到返回的应答后将状态置为ftp传输等待;
子节点收到发来的取文件的通知后,将状态置为就绪状态检查,确认父节点状态是否为ftp传输等待;如果是,置自身状态为ftp传输开始;
父节点向子节点传输数据,传输完毕后子节点状态置为ftp传输结束,并将父节点状态置为任务结束;
子节点置为任务到达状态,对到达的数据解密、解压缩、解包,执行完这些操作后置状态为任务结束。
5、如权利要求4所述的方法,其特征在于,当子节点从父节点接收数据时,在父节点发送数据到子节点之前还包括:
设置子节点状态为向子节点请求传输任务,向父节点申请发送申请文件,并在收到父节点的应答后将状态设为请求传输等待;
父节点收到发来的申请发送文件请求后将自身状态设为请求状态检查,检查子节点状态是否为请求传输等待,如果是,则置自身为任务准备状态。
6、如权利要求2所述的方法,其特征在于,当中间节点从子节点接收向父节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
子节点发送数据到中间节点按照所述子节点向父节点发送数据过程执行,并在中间节点到达传输准备就绪状态时,中间节点发送数据到父节点,按照所述子节点向父节点发送数据过程执行。
7、如权利要求4所述的方法,其特征在于,当中间节点从子节点接收向子节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
子节点发送数据到中间节点按照所述子节点向父节点发送数据过程执行,并在中间节点到达传输准备就绪状态时,中间节点发送数据到子节点,按照所述父节点发送数据到子节点过程执行。
8、如权利要求4所述的方法,其特征在于,当中间节点从父节点接收向子节点发送时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
父节点发送数据到中间节点按照所述父节点向子节点发生数据过程执行,并在中间节点到达传输准备就绪装填时,中间节点发送数据到子节点,按照所述父节点向子节点发生数据过程执行。
9、如权利要求1所述的方法,其特征在于,当第一节点请求的数据在跨过第二节点的第三节点上,第二节点需要接收文件请求的转发时,所述将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化包括:
第一节点置状态为向子节点请求传输任务,向第二节点申请传输文件,并在收到第二节点的应答后置状态为请求传输等待;
第二节点收到申请传输文件请求后置自身状态为请求状态检查,检查第一节点是否为请求传输等待,如果是,将自身状态置为向子节点请求传输任务;
第二节点向第三节点申请传输文件,并在收到第三节点的应答后置状态为请求传输等待;
第三节点收到申请传输文件请求后置自身状态为请求状态检查,检查第二节点是否为请求传输等待,如果是,将自身置为任务准备状态;
第三节点对要传输的数据进行打包、压缩、加密。
10、如权利要求2至9中任一项所述的方法,其特征在于,所述加密采用文件密钥对传输的数据文件头部加密的方式。
11、如权利要求10所述的方法,其特征在于,所述采用文件密钥对传输的数据文件头部加密由以下方式实现:
由文件传输的签到口令得到文件密钥,系统在任务开始时,采用该文件密钥将经打包、压缩后的数据包的头部信息进行加密,并将文件密钥作为该文件的属性通过命令通道传输到目标节点;
任务到达目标节点后,系统利用从源节点传输来的文件密钥将数据包解密并还原。
12、一种传输大量数据的系统,其特征在于,包括参与数据传输的节点,其中,
所述传输节点包括状态表,传输节点利用该状态表将传输过程划分为不同的状态,在不同状态执行针对该状态的动作和状态转化;
所述传输节点包括监控模块,用于监控传输过程所处的状态,并在传输过程发生中断时将监控到的状态发送到恢复模块;
所述传输节点包括恢复模块,用于根据收到的中断状态将传输过程从该状态恢复。
13、如权利要求12所述的系统,其特征在于,所述状态表包括如下状态:
任务准备状态,该状态对要传输的数据进行打包、压缩、加密操作;
任务到达状态,该状态对到达的传输任务进行解密、解压、解包操作;
传输准备就绪状态,该状态根据节点在传输过程中的位置以及出现的时机不同分为:
该状态出现在子节点且该节点是数据的发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向父节点发出开始传输的请求,并在请求返回应答后,系统将状态改变为ftp传输开始状态;
该状态出现在子节点且该节点是数据的接收方,则表示该任务的数据已经全部从父节点获取结束,系统将该状态置为任务到达状态;
该状态出现在父节点且该节点是数据的发送方,表示数据已经做完预处理,等待向父节点传输,则根据该状态向其子节点发出开始获取请求,并在请求返回应答后,系统将状态置为ftp传输等待状态;
该状态出现在父节点且该节点是数据的接收方,则表示该任务的数据已经全部从子节点获取结束,系统将该状态置为任务到达状态;
就绪状态检查,该状态出现在子节点,当父节点向子节点传输数据,或子节点向父节点获取数据时,子节点向父节点检查,确认其状态是否已经变成ftp传输等待,如果是则子节点启动ftp请求开始发送或接收数据;
ftp传输开始状态,该状态出现子节点,系统根据该状态启动ftp请求,向其父节点发送或接收数据文件,当ftp请求结束后,系统将该状态置为ftp传输结束状态;
ftp传输结束状态,该状态出现子节点,根据ftp的发送或接收方向的不同分为:
ftp方向为发送,系统向对方节点发送传送数据结束的请求,并将对方节点状态置为传输准备就绪;
ftp方向为接收,系统向对方节点发送传送数据结束的请求,并将对方节点状态置为任务结束;
任务结束,该状态是一个最终状态,表示任务顺利结束。
14、如权利要求12所述的系统,其特征在于,所述状态表还包括如下状态:
结束状态检查,该状态出现在父节点,系统根据此状态,向子节点检查该节点任务是否结束;
向子节点请求传输任务,该状态发生在子节点向父节点获取数据或父节点向子节点获取数据时,系统根据此状态向对方节点发送请求获取数据的申请,对方节点收到申请后,置状态为请求状态检查,同时返回应答到请求节点,请求节点在收到应答后将本地状态置为请求传输等待;
请求状态检查,系统根据此状态向对方节点检查对方节点状态是否为请求传输等待,在确认后,将本地状态置为任务准备状态;
ftp传输等待,该状态是被动等待状态,当对方节点的状态从ftp传输开始变为ftp传输结束后,由对方节点发送请求将本地状态置为传输准备就绪或任务结束;
请求传输等待,该状态是被动等待状态,当对方节点的状态从任务准备状态变为传输准备就绪后,由对方节点发送请求将本地状态置为就绪状态检查;
任务失败,该状态是一个最终状态,表示任务失败。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101564276A CN100550848C (zh) | 2006-12-31 | 2006-12-31 | 传输大量数据的方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101564276A CN100550848C (zh) | 2006-12-31 | 2006-12-31 | 传输大量数据的方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101009641A true CN101009641A (zh) | 2007-08-01 |
CN100550848C CN100550848C (zh) | 2009-10-14 |
Family
ID=38697784
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006101564276A Active CN100550848C (zh) | 2006-12-31 | 2006-12-31 | 传输大量数据的方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100550848C (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102036102A (zh) * | 2009-09-25 | 2011-04-27 | 腾讯科技(深圳)有限公司 | 多媒体转码系统、方法及播放多媒体的系统、方法 |
CN102169439A (zh) * | 2010-02-26 | 2011-08-31 | 英业达股份有限公司 | 数据传输系统 |
CN101252506B (zh) * | 2007-12-29 | 2012-07-04 | 中国建设银行股份有限公司 | 一种数据传输系统 |
WO2014187219A1 (en) * | 2013-05-20 | 2014-11-27 | Tencent Technology (Shenzhen) Company Limited | Electronic device, storage medium and file transferrting method |
CN109388618A (zh) * | 2018-10-15 | 2019-02-26 | 深圳市太山科技有限公司 | 嵌入式系统文件压缩、解压及加密、解密的方法及装置 |
CN110602359A (zh) * | 2019-09-02 | 2019-12-20 | Oppo广东移动通信有限公司 | 图像处理方法、图像处理器、拍摄装置和电子设备 |
CN111245929A (zh) * | 2020-01-09 | 2020-06-05 | 卡斯柯信号有限公司 | 一种cocc非实时通道数据断点续传的实现方法 |
CN113660393A (zh) * | 2021-07-08 | 2021-11-16 | 上海途悠信息科技有限公司 | 一种服务窗口双录系统 |
-
2006
- 2006-12-31 CN CNB2006101564276A patent/CN100550848C/zh active Active
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101252506B (zh) * | 2007-12-29 | 2012-07-04 | 中国建设银行股份有限公司 | 一种数据传输系统 |
CN102036102A (zh) * | 2009-09-25 | 2011-04-27 | 腾讯科技(深圳)有限公司 | 多媒体转码系统、方法及播放多媒体的系统、方法 |
CN102169439A (zh) * | 2010-02-26 | 2011-08-31 | 英业达股份有限公司 | 数据传输系统 |
CN102169439B (zh) * | 2010-02-26 | 2014-05-07 | 英业达股份有限公司 | 数据传输系统 |
WO2014187219A1 (en) * | 2013-05-20 | 2014-11-27 | Tencent Technology (Shenzhen) Company Limited | Electronic device, storage medium and file transferrting method |
US10069894B2 (en) | 2013-05-20 | 2018-09-04 | Tencent Technology (Shenzhen) Company Limited | Electronic device, storage medium and file transferring method |
CN109388618A (zh) * | 2018-10-15 | 2019-02-26 | 深圳市太山科技有限公司 | 嵌入式系统文件压缩、解压及加密、解密的方法及装置 |
CN109388618B (zh) * | 2018-10-15 | 2021-02-12 | 密卡思(深圳)电讯有限公司 | 嵌入式系统文件压缩、解压及加密、解密的方法及装置 |
CN110602359A (zh) * | 2019-09-02 | 2019-12-20 | Oppo广东移动通信有限公司 | 图像处理方法、图像处理器、拍摄装置和电子设备 |
CN111245929A (zh) * | 2020-01-09 | 2020-06-05 | 卡斯柯信号有限公司 | 一种cocc非实时通道数据断点续传的实现方法 |
CN113660393A (zh) * | 2021-07-08 | 2021-11-16 | 上海途悠信息科技有限公司 | 一种服务窗口双录系统 |
Also Published As
Publication number | Publication date |
---|---|
CN100550848C (zh) | 2009-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100550848C (zh) | 传输大量数据的方法和系统 | |
CN109493020B (zh) | 基于区块链的安全交易方法和装置 | |
CN111460453B (zh) | 机器学习训练方法、控制器、装置、服务器、终端和介质 | |
CN106503098B (zh) | 内置于Paas服务层的区块链云服务框架系统 | |
US6128647A (en) | Self configuring peer to peer inter process messaging system | |
CN110881063B (zh) | 一种隐私数据的存储方法、装置、设备及介质 | |
WO2022062976A1 (zh) | 用于执行交易的跨区块链的系统、跨链交易方法及设备 | |
CN111213128A (zh) | 实现基于区块链的web服务 | |
CN102710759A (zh) | Web服务器、业务登录方法及系统 | |
JP6283119B2 (ja) | 秘密計算システム、中継装置、それらの方法、プログラム、および記録媒体 | |
JP6951649B2 (ja) | ブロック検証装置、ブロック検証方法、及びプログラム | |
CN102404326A (zh) | 一种验证报文安全性的方法、系统以及装置 | |
CN111262852A (zh) | 基于区块链实现的名片签发方法及系统 | |
CN111448812A (zh) | 信息传输方法、存储介质、信息传输系统及无人飞行器 | |
CN105556890A (zh) | 加密处理方法、加密系统以及服务器 | |
CN101175089A (zh) | 基于http协议和.net架构的服务器和客户端间数据传输方法 | |
CN112532387B (zh) | 一种密钥服务运算系统及其方法 | |
CN105281901A (zh) | 一种云租户关键信息的加密方法 | |
US12032713B1 (en) | Systems and methods for sending and receiving encrypted submessages | |
CN103092932A (zh) | 一种分布式文档转码系统 | |
CN116980155A (zh) | 区块链网络的数据处理方法、装置、产品、设备和介质 | |
CN114091059A (zh) | 数据安全处理方法、装置、终端、介质和系统 | |
US7908333B2 (en) | Self configuring peer to peer inter process messaging system | |
US20210233064A1 (en) | Secure transactional system in a p2p architecture | |
Daodu et al. | A data encryption standard (DES) based web services security architecture |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |