一种版本更新管理方法和相关装置与流程

本申请涉及通信技术领域，特别是涉及一种版本更新管理方法和相关装置。

背景技术：

随着信息技术和互联网技术的不断发展，新兴技术与银行服务的不断融合，金融交易去实体化特征凸显，客户体验要求不断提高，银行网点向智能化、轻型化、营销化逐渐转型。银行对自助设备的投放力度不断增加，自助设备集中管理工作难度不断加大，金融企业对自助设备的软件版本灵活性、拓展性要求不断提高。金融企业自助设备涉及网点智能化改造，往往涉及柜面交易迁移，程序组件多样化及地域业务的特色化，对自助设备的软件版本管理提出了众多要求。

传统自助设备版本管理方式无法满足商业银行总行-分行-网点的复杂网络拓扑结构。如果使用传统的自助设备版本管理模式，随着自助设备的不断增加，企业需要不断增加网络带宽来满足不断增加版本分发的要求，且无法满足自助设备软件集中控制，版本控制，安全控制等定制化要求。同时传统的文件分发网络无法对设备的版本、升级时间(软件版本更新时间)等进行精细化定制化管理，无法跟踪设备的升级记录(软件版本更新记录)，故难以满足审计需求。改进当前的自助设备的软件版本管理方式已成为该领域解决的技术问题。

技术实现要素：

基于上述问题，本申请提供了一种版本更新管理方法和相关装置，以降低总行-分行-网点的复杂网络拓扑结构下自助设备版本更新管理的难度，节省网络带宽，实现对自助设备软件版本的管理控制。

本申请实施例公开了如下技术方案：

本申请第一方面提供一种版本更新管理方法，所述自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件；所述邻近设备列表包括：所述自助设备的至少一个已更新至所述目标版本的邻近自助设备；所述文件列表文件中包括所述目标版本的所有版本文件的文件名和所有所述版本文件的校验码；

所述自助设备向所述邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载所述版本文件；

所述自助设备根据接收到的文件的校验码和所述文件列表文件中所述版本文件的校验码，确定所述版本文件是否成功下载至所述自助设备；

所述自助设备根据成功下载的版本文件对所述自助设备进行版本更新；

所述自助设备在版本更新结束后，向所述总行系统上报所述自助设备的当前版本。

可选地，各级分行分别部署有缓存服务器；所述自助设备与最近一级分行的缓存服务器通信连接；相邻级分行的缓存服务器相互通信连接，一级分行的缓存服务器与所述总行系统相互通信连接；所述方法还包括：

当所述自助设备无法从所述邻近设备列表中的邻近自助设备成功下载所述版本文件时，所述自助设备向最近一级分行的缓存服务器发送第二下载请求，以请求下载所述版本文件。

可选地，所述方法还包括：

当所述自助设备无法从所述最近一级分行的缓存服务器成功下载所述版本文件时，所述最近一级分行的缓存服务器向其上级分行的缓存服务器或者所述总行系统发送第三下载请求，以请求下载所述版本文件。

可选地，所述自助设备根据接收到的文件的校验码和所述文件列表文件中所述版本文件的校验码，确定所述版本文件是否成功下载至所述自助设备，包括：

所述自助设备比较所述接收到的文件的校验码与所述文件列表文件中所述版本文件的校验码是否一致，当一致时，确定所述版本文件成功下载至所述自助设备；否则，确定所述版本文件未成功下载至所述自助设备。

可选地，所述目标版本包括：

目标平台版本和/或目标应用集合版本；所述目标应用集合包括：至少一个待更新的目标应用。

可选地，所述校验码为md5值。

可选地，所述方法还包括：

当确定所述邻近设备列表中某一邻近自助设备为所述自助设备提供文件超时，则所述自助设备将该提供文件超时的邻近自助设备从所述邻近设备列表中删除。

可选地，所述总行系统包括：总行管理系统、总行部署的版本服务器和版本下发控制服务器；

所述自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件，具体包括：

所述自助设备向所述版本下发控制服务器发送版本更新查询请求；

所述自助设备接收所述版本下发控制服务器反馈的所述目标版本的版本号和所述邻近设备列表；

所述自助设备根据所述目标版本的版本号从所述版本服务器获得所述目标版本对应的所述文件列表文件。

可选地，在所述自助设备向所述版本下发控制服务器发送版本更新查询请求之前，所述方法还包括：

所述自助设备重启。

本申请第二方面提供一种版本更新管理装置，应用于自助设备中，所述装置包括：

第一获取模块，用于从总行系统获得邻近设备列表和目标版本对应的文件列表文件；所述邻近设备列表包括：所述自助设备的至少一个已更新至所述目标版本的邻近自助设备；所述文件列表文件中包括所述目标版本的所有版本文件的文件名和所有所述版本文件的校验码；

第一发送模块，用于向所述邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载所述版本文件；

校验模块，用于根据接收到的文件的校验码和所述文件列表文件中所述版本文件的校验码，确定所述版本文件是否成功下载至所述自助设备；

版本更新模块，用于根据成功下载的版本文件对所述自助设备进行版本更新；

反馈模块，用于在版本更新结束后，向所述总行系统上报所述自助设备的当前版本。

相较于现有技术，本申请具有以下有益效果：

本申请提供的版本更新管理方法，自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件；邻近设备列表包括：自助设备的至少一个已更新至目标版本的邻近自助设备；文件列表文件中包括目标版本的所有版本文件的文件名和所有版本文件的校验码；自助设备向邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载版本文件；自助设备根据接收到的文件的校验码和文件列表文件中版本文件的校验码，确定版本文件是否成功下载至自助设备；自助设备根据成功下载的版本文件对自助设备进行版本更新；自助设备在版本更新结束后，向总行系统上报自助设备的当前版本。本申请定制了基于对等网络(peertopeer,p2p)的自助设备软件更新管理技术方案，即便自助设备的数量增加也不需额外增加网络带宽满足版本更新要求，批量试点版本更新，自助设备之间可以请求和获取版本文件，简单、便捷、快速且高效地实现软件版本更新。此外，在版本更新后，自助设备向总行系统上报当前版本，便于总行系统对自助设备版本更新情况的统筹和控制管理。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种版本更新管理方法的应用场景示意图；

图2为本申请实施例提供的一种版本更新管理方法的流程图；

图3为本申请实施例提供的另一种版本更新管理方法的流程图；

图4为自助设备向最近一级分行的缓存服务器发送第二下载请求以请求下载版本文件的示意图；

图5为本申请实施例提供的又一种版本更新管理方法的流程图；

图6为最近一级分行的缓存服务器向上级分行的缓存服务器发送第三下载请求以请求下载版本文件的示意图；

图7为本申请实施例提供的一种版本更新管理装置的结构示意图。

具体实施方式

正如前文描述，目前传统的自助设备版本管理方式难以满足商业银行总行-分行-网点的复杂网络拓扑结构，当自助设备数量不断扩增的情况下，需要不断增加网络带宽实现自助设备的版本管理。此外，传统的自助设备版本管理方式无法满足自助设备软件集中控制管理等定制化要求。

基于上述问题，发明人经过研究提供了以对等网络实现软件版本更新管理的技术方案。以先完成版本更新的自助设备带动其他未完成版本更新的自助设备实现版本更新，节省网络带宽，使版本管理控制更以实现，可操作性更强。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请实施例之前，为便于理解，首先对本申请涉及的术语进行解释说明。

总行：金融行业总机构，例如中国农业银行。

分行：金融行业总机构下的分支机构，例如中国农业银行北京分行、中国农业银行海淀支行等。分行可以包括多个级别，例如一级分行、二级分行等。分行的级别(级次)可以按照行政区域划分，例如直辖市及省会城市的最大分行称为一级分行，直辖市下的区分行及省会以外的其他市级地区的最大分行称为二级分行。以此类推。

自助设备：网点部署的通过影片、图片、音乐等多媒体数据库形成互动环境，从而专门用来储存信息并提供各类信息查询、打印、缴费以及产品贩卖等服务的电子信息设备。金融行业的自助设备一般包括：atm、超级柜台、自助服务终端、叫号机等设备。

缓存服务器：将需要频繁访问的网络内容存放在离用户较近、访问速度更快的服务器中，用以提高内容访问速度。

总行管理系统：为自助设备提供版本管理服务的系统，支持平台、总行、分行的版本上传，并可设定版本下发的批次、时间等。

总行的版本服务器：存储自助设备软件版本的服务器。

总行的版本下发控制服务器：与部署在网点的自助设备交互，用于在自助设备查询时反馈自助设备的待更新版本(即目标版本)。

参见图1，该图为本申请实施例提供的一种版本更新管理方法的应用场景示意图。如图1所示的应用场景包括：总行系统100和多级分行分别部署的缓存服务器w1、w2等。图中仅示意了两级分行，在实际应用中还可能包含更多级的分行，例如三级分行、四级分行等，此处不做限制。分行下级部署有网点，网点的自助设备可以与最近一级分行的缓存服务器通信连接。相邻级缓存服务器w1和w2相互通信连接。一级分行的缓存服务器w1与总行系统100相互通信连接。图1也示意出了总行-分行-网点的拓扑结构。

总行系统100具体可以包括：总行管理系统101、版本服务器102和版本下发控制服务器103。一级分行的缓存服务器w1与版本服务器102通信连接，自助设备可以通过代理程序和版本下发控制服务器103通信连接。

其中，总行管理系统101可以理解为是可面向于平台的程序管理员、各类应用的程序管理员以及分行系统的程序管理员的管理系统。平台的程序管理员、各类应用的程序管理员以及分行系统的程序管理员可以通过登录账号的方式在总行管理系统101中制作版本文件，实现软件版本定制。总行的版本服务器102可根据总行管理系统101上传的文件生成并存储版本资源。总行的版本下发控制服务器103用于响应网点自助设备的版本更新查询请求，告知自助设备目标版本，并反馈邻近设备列表，以便于自助设备根据版本下发控制服务器103的指示和提供的邻近设备列表启动文件下载和版本更新的流程。

以下结合实施例对本申请提供的版本更新管理方法进行详细介绍。

参见图2，该图为本申请实施例提供的一种版本更新管理方法的流程图。在图2示意的流程中，以自助设备作为此方法的执行主体进行说明。如图2所示，版本更新管理方法包括：

s201：自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件。

邻近设备列表包括：自助设备的至少一个已更新至目标版本的邻近自助设备。作为示例，本申请实施例提供的版本更新管理方法中待升级的自助设备为term0，其获得的邻近设备列表中的邻近自助设备包括term1～term10共计10个已升级至目标版本的邻近自助设备。

邻近自助设备可以根据网点的位置或者网点与最近一级分行的部署关系划分。例如，将自助设备term0周边与其距离在3km以内的自助设备称为邻近自助设备。或者例如，将与自助设备term0同属一个二级分行的网点的自助设备成为邻近自助设备。此处对于划分邻近自助设备的实现方式不做限制。

在本申请实施例中，总行系统可以管控各个网点的自助设备的版本升级情况，因此可以根据实际情况向自助设备term0提供上述的邻近设备列表。

文件列表文件中包括目标版本的所有版本文件的文件名和所有版本文件的校验码。为便于理解文件列表文件，下面介绍文件列表文件的形成过程。

在本申请实施例中，目标版本可以包括目标平台版本和/或目标应用集合版本。也就是说，待更新的内容可以仅包括平台部分的待更新内容，仅包括应用程序部分的待更新内容，还可以既包括平台部分的待更新内容还包括应用程序部分的待更新内容。平台支撑自助设备运行，应用程序则是运行在自助设备上实现各类应用功能。

平台的程序管理员可以根据程序运行的各类要求，制作版本程序文件，并压缩为zip包，在总行管理系统上传平台程序版本到总行部署的版本服务器。总行版本服务器解压版本平台、总行程序zip文件，并按照上传次序生成平台版本号，同时生成对应版本的filelist.xml文件。filelist.xml文件中储存zip压缩包中每一个文件，及对应文件的校验码。

各类应用的程序管理员可以根据各类总分行定制化的业务要求，制作版本各类应用的jar包，在总行管理系统上传应用程序版本到总行部署的版本服务器。总行版本服务器解压版本应用程序的jar包，并按照上传次序生成应用程序版本号appv1，appv2，同时生成对应版本的appfilelist.xml文件。appfilelist.xml文件中储存jar压缩包中每一个文件，及对应文件的校验码。

待更新的应用可能包括多个，因此，分行系统管理员可以在总行管理系统，选择合适的应用程序版本、组合成pack包，每个pack包可以根据分行的各类需求，组合应用程序。如packv1可以包含appv1，appv2，同时生成对应版本的packfilelist.xml文件。每个packfilelist.xml存储该pack包中所有的应用程序对应的appfilelist.xml文件的位置和及对应文件的校验码。

分行系统管理员可以通过总行管理系统为自助设备term0分配平台版本v1，应用程序集合版本packv1。总行的版本下发控制服务器可以从总行管理系统获得目标版本包括：平台的版本v1和/或应用程序集合版本packv1。当目标版本既包括v1又包括packv1时，文件列表文件具体包括：filelist.xml文件和packfilelist.xml文件。

s202：自助设备向邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载版本文件。

在本申请实施例中，采用了对等网络机制进行版本更新。某一层级下的自助设备term0需要进行版本升级的时候，通过总行系统查询到附近完成升级的设备，自动向查询到邻近设备列表发起轮询，获取版本文件。一旦自助设备term0更新完成后在总行版本服务器中更新当前设备状态为更新完成，从而附近其他未完成版本更新的自助设备后续也可以从该自助设备term0获取版本文件。本步骤s202则具体描述的是自助设备term0向自助设备term1～term10发送第一下载请求。

文件列表文件中囊括的版本文件通常有多个，自助设备term0具体可以向不同的邻近自助设备发送第一下载请求，分别下载不同的版本文件。如此，加快了文件列表文件中版本文件的下载速度。

s203：自助设备根据接收到的文件的校验码和文件列表文件中版本文件的校验码，确定版本文件是否成功下载至自助设备。

邻近自助设备term1～term10向自助设备term0回传文件时，不但回传文件本身，还将文件的校验码一同回传给自助设备term0。在前面提及，自助设备term0已从总行系统获得了文件列表文件，其中包含版本文件的文件名和校验码。

为确定版本文件是否成功下载到自助设备term0，自助设备term0可以根据从邻近自助设备term1～term10接收到的文件的校验码和文件列表文件中版本文件的校验码进行确认。

作为一种可能的实现方式，自助设备term0比较接收到的文件的校验码与文件列表文件中版本文件的校验码是否一致，当一致时，确定该版本文件成功下载至自助设备term0；否则，确定该版本文件未成功下载至自助设备term0。其他版本文件成功下载与否的确认方式同上。

s204：自助设备根据成功下载的版本文件对自助设备进行版本更新。

当自助设备term0依照s203方式确认文件列表文件中囊括的所有版本文件均已成功下载到自助设备term0后，即可按照下载好的版本文件进行版本更新。

s205：自助设备在版本更新结束后，向总行系统上报自助设备的当前版本。

也就是说，自助设备term0对目标版本更新结束后，向总行系统上报自身已经更新至目标版本。通过上报当前版本，使总行系统能够及时、准确、有针对性地管控版本更新环节，保证对等网络机制的延续。

以上即为本申请实施例提供的版本更新管理方法。本申请定制了基于p2p网络机制的自助设备软件更新管理技术方案，即便自助设备的数量增加也不需额外增加网络带宽满足版本更新要求，批量试点版本更新，自助设备之间可以请求和获取版本文件，简单、便捷、快速且高效地实现软件版本更新。此外，在版本更新后，自助设备向总行系统上报当前版本，便于总行系统对自助设备版本更新情况的统筹和控制管理。

结合图1所示的总行系统100的结构，s201中自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件，具体可以包括：

自助设备向版本下发控制服务器103发送版本更新查询请求；自助设备接收版本下发控制服务器103反馈的目标版本的版本号和邻近设备列表；自助设备根据目标版本的版本号从版本服务器102获得目标版本对应的文件列表文件。

此外，以上实施例中s201可以在每次自助设备重启后执行，也可以定期执行，例如每过12小时执行一次。此处对于执行频率和执行时机不做限制。

实际应用中，自助设备term0向邻近自助设备term1～term10发送的第一下载请求中可以携带版本文件的文件名和校验码。邻近自助设备term1～term10在接收到第一下载请求后，可以首先比对本地是否存在同名文件，如果是，则进一步比对本地文件和版本文件的校验码，校验码一致才向自助设备term0回传文件。如果不存在同名文件，或者同名文件的校验码不一致，则拒绝第一下载请求，不向自助设备term0回传文件。

在实际应用中，邻近自助设备term1～term10还可以根据当前网络情况选择是否回传文件或者拒绝第一下载请求。例如，如果邻近自助设备term1已经同时为n个自助设备提供文件共享服务(n为设定的阈值，n为正整数)，则拒绝自助设备term0的下载请求。

结合上文描述，邻近自助设备term1～term10可能拒绝第一下载请求。此外，实际应用中也可能发生文件回传失败或者文件下载超时的情况。即，自助设备term0可能无法从邻近设备列表中的邻近自助设备上完成文件列表文件中所有版本文件的下载。基于该问题，本申请进一步提供了另一种版本更新管理方法。

图3为本申请实施例提供的另一种版本更新管理方法的流程图。如图3所示，该方法包括：

s301：自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件。

s302：自助设备向邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载版本文件。

s303：自助设备根据接收到的文件的校验码和文件列表文件中版本文件的校验码，确定版本文件是否成功下载至自助设备。

s301～s303的实现方式与前述实施例中s201～s203的实现方式基本相同，相关的描述可以参照前述实施例，此处不再赘述。

s304：当自助设备无法从邻近设备列表中的邻近自助设备成功下载版本文件时，自助设备向最近一级分行的缓存服务器发送第二下载请求，以请求下载版本文件。

图4为自助设备向最近一级分行的缓存服务器发送第二下载请求以请求下载版本文件的示意图。如图4所示，当自助设备无法从邻近自助设备获得版本文件时，可以选择向缓存服务器发起下载请求。如此，弥补了邻近自助设备无法提供或完全提供版本文件的问题。此外向最近一级分行的缓存服务器请求下载版本文件，可以保证文件的回传速度较快，满足自助设备快速更新版本的需求。

在本实施例s304执行后，与s303类似地，自助设备term0还可以根据最近一级分行的缓存服务器回传的文件的校验码和文件列表文件中版本文件的校验码，确定相应的版本文件是否成功下载至自助设备。

s305：自助设备根据成功下载的版本文件对自助设备进行版本更新。

s306：自助设备在版本更新结束后，向总行系统上报自助设备的当前版本。

s305～s306的实现方式与前述实施例中s204～s205的实现方式基本相同，相关的描述可以参照前述实施例，此处不再赘述。

以上实施例介绍的版本更新管理方法中，自助设备在无法从邻近自助设备获得所有版本文件的情况下，通过向最近一级分行的缓存服务器发送第二下载请求，提升了版本文件下载成功率，有利于成功完成版本更新。

第二下载请求中可以携带版本文件的文件名和校验码。最近一级分行的缓存服务器在接收到第二下载请求后，也可以比对本地是否存在同名文件，如果是，则进一步比对本地文件和版本文件的校验码，校验码一致才向自助设备term0回传文件。如果不存在同名文件，或者同名文件的校验码不一致，则拒绝第二下载请求，不向自助设备term0回传文件。

在一种可能的实现方式中，每一级分行部署的缓存服务器缓存的服文件超过预设数量后，可以根据lru算法清理本地最不常用的文件。

结合上文描述，与自助设备最近一级分行的缓存服务器可能拒绝第二下载请求。此外，实际应用中也可能发生文件回传失败或者文件下载超时的情况。即，自助设备term0可能无法从最近一级缓存服务器中获得需要下载的版本文件。基于该问题，本申请进一步提供了又一种版本更新管理方法。

图5为本申请实施例提供的又一种版本更新管理方法的流程图。如图5所示，该方法包括：

s501：自助设备从总行系统获得邻近设备列表和目标版本对应的文件列表文件。

s502：自助设备向邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载版本文件。

s503：自助设备根据接收到的文件的校验码和文件列表文件中版本文件的校验码，确定版本文件是否成功下载至自助设备。

s504：当自助设备无法从邻近设备列表中的邻近自助设备成功下载版本文件时，自助设备向最近一级分行的缓存服务器发送第二下载请求，以请求下载版本文件。

s501～s504的实现方式与前述实施例中s301～s304的实现方式基本相同，相关的描述可以参照前述实施例，此处不再赘述。

s505：当自助设备无法从最近一级分行的缓存服务器成功下载版本文件时，最近一级分行的缓存服务器向其上级分行的缓存服务器或者总行系统发送第三下载请求，以请求下载版本文件。

图6为最近一级分行的缓存服务器向上级分行的缓存服务器发送第三下载请求以请求下载版本文件的示意图。如图6所示，当自助设备无法从最近一级分行的缓存服务器m2获得版本文件时，缓存服务器m2可以向缓存服务器m1发起第三下载请求。如此，弥补了缓存服务器m2无法向自助设备提供版本文件的问题。

当缓存服务器m2从缓存服务器m1下载到自助设备所需的版本文件后，可以将版本文件回传给自助设备。

如果自助设备最近一级分行的缓存服务器是一级分行的缓存服务器m1，则缓存服务器m1可直接从总行系统请求下载版本文件。具体地，可以向总行的版本服务器102发送第三下载请求。

s506：自助设备根据成功下载的版本文件对自助设备进行版本更新。

s507：自助设备在版本更新结束后，向总行系统上报自助设备的当前版本。

s506～s507的实现方式与前述实施例中s305～s306的实现方式基本相同，相关的描述可以参照前述实施例，此处不再赘述。

以上实施例介绍的版本更新管理方法中，自助设备在无法从最近一级分行的缓存服务器下载版本文件的情况下，可以由最近一级分行的缓存服务器向上请求下载。如此，提升了版本文件下载成功率，有利于成功完成版本更新。由于总行系统的版本服务器存储和管理所有版本资源，因此最终自助设备必然能够获得目标版本的版本文件，完成版本更新。

在以上实施例中提到，缓存服务器及各个自助设备可以依据文件的校验码进行比对，以实现文件确认。在具体实现时，校验码可以通过多种不同的方式形成。作为一种可能的实现方式，校验码可以是根据密码散列函数生成的散列值，例如128位(16字节)的md5值。此处对于生成校验码的实现方式不做限制。

前面提到，邻近自助设备可能无法顺利为自助设备提供文件，例如文件下载超时等问题发生，这表明传输发生问题。在一种可能的实现方式中，当确定所述邻近设备列表中某一邻近自助设备为所述自助设备提供文件超时，则所述自助设备可以将该提供文件超时的邻近自助设备从所述邻近设备列表中删除。避免自助设备重复向该邻近自助设备发出请求。

基于前文介绍的实施例，本申请技术方案的主要思路是在金融行业的不同层级机构下自助设备应用对等网络(p2p)机制，某一层级下的自助设备需要进行版本升级的时候，通过总行统一的服务器查询到附近完成升级的设备，自动向查询到设备列表发起轮询，获取版本文件。如获取更新完成设备列表失败，或者向轮询列表中的设备获取版本失败，则沿着拓扑结构向上缓存服务器查询下载。

本申请技术方案相比传统的内容分发网络(contentdeliverynetwork,cdn)软件和传统的全量更新的版本下发机制，根据金融机构，总行、分行、网点的层级和网络部署关系，定制了专有的基于对等网络的自助设备软件管理方法和装置。可以实现在网络最佳利用的情况下，以增量更新的方式，实施自助设备软件版本的全量下载。同时根据金融行业的特殊需求设计了设备批量试点和及时回退的机制，符合金融行业自助设备的精细化管理要求。

基于前述实施例提供的版本更新管理方法，相应地，本申请还提供一种版本更新管理装置，该装置应用于待更新版本的自助设备中。下面结合实施例和附图进行说明。

参见图7，该图为本申请实施例提供的一种版本更新管理装置的结构示意图。如图7所示，该装置700包括：

第一获取模块701，用于从总行系统获得邻近设备列表和目标版本对应的文件列表文件；所述邻近设备列表包括：所述自助设备的至少一个已更新至所述目标版本的邻近自助设备；所述文件列表文件中包括所述目标版本的所有版本文件的文件名和所有所述版本文件的校验码；

第一发送模块702，用于向所述邻近设备列表中的邻近自助设备发送第一下载请求，以请求下载所述版本文件；

校验模块703，用于根据接收到的文件的校验码和所述文件列表文件中所述版本文件的校验码，确定所述版本文件是否成功下载至所述自助设备；

版本更新模块704，用于根据成功下载的版本文件对所述自助设备进行版本更新；

反馈模块705，用于在版本更新结束后，向所述总行系统上报所述自助设备的当前版本。

本申请定制了基于对等网络(peertopeer,p2p)的自助设备软件更新管理技术方案，即便自助设备的数量增加也不需额外增加网络带宽满足版本更新要求，批量试点版本更新，自助设备之间可以请求和获取版本文件，简单、便捷、快速且高效地实现软件版本更新。此外，在版本更新后，自助设备向总行系统上报当前版本，便于总行系统对自助设备版本更新情况的统筹和控制管理。

结合图1所示的场景，在实际应用中，由于邻近设备列表中的邻近自助设备可能无法为自助设备提供所有版本文件，因此，版本更新管理装置还可以进一步包括：

第二发送模块，用于当所述自助设备无法从所述邻近设备列表中的邻近自助设备成功下载所述版本文件时，向最近一级分行的缓存服务器发送第二下载请求，以请求下载所述版本文件。

可选地，校验模块703，具体用于比较所述接收到的文件的校验码与所述文件列表文件中所述版本文件的校验码是否一致，当一致时，确定所述版本文件成功下载至所述自助设备；否则，确定所述版本文件未成功下载至所述自助设备。

可选地，所述目标版本包括：

目标平台版本和/或目标应用集合版本；所述目标应用集合包括：至少一个待更新的目标应用。

可选地，所述校验码为md5值。

可选地，版本更新管理装置还可以进一步包括：

删除模块，用于当确定所述邻近设备列表中某一邻近自助设备为所述自助设备提供文件超时，将该提供文件超时的邻近自助设备从所述邻近设备列表中删除。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。