软件更新方法、系统及设备的制作方法
软件更新方法、系统及设备的制作方法
【专利摘要】本发明公开了软件更新方法、设备及系统，涉及数据共享及数据传输领域。本发明的软件更新方法包括：客户端向其他客户端发送本地更新软件广播信息；判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。本发明可以解决软件更新过程中传输速度受到OTA服务器的制约及传输数据中拥堵的问题，从而提高了下载速度，因此可以同时为大量的设备更新软件，避免了服务器因大量的设备需求导致拥塞或者瘫痪的可能性。
【专利说明】软件更新方法、系统及设备
【技术领域】
[0001]本发明涉及数据传输领域，特别涉及软件更新的方法、系统及设备。
【背景技术】
[0002]随着电子和通信技术的发展，越来越多的电子设备应用到日常生活中的各个方面。目前，这些电子设备的硬软件更新过程中不能实现兼容，而给使用者带来不便。为解决这一问题，已经提出了可重构设备(Reconfigurable Devices)技术。在实现可重构设备技术的过程中，在对硬件进行改进的基础上也必须得到软件的支持。可支持可重构设备的硬件包括FPGA或者rDPA处理器。这些处理器可以通过编程来调节其功能。
[0003]软件重构是有效实现硬件多种功能的方法。常用的操作方式是将编写好的软件放到一个服务器上，然后可重构设备从服务器下载并更新。下载可以通过有线和无线两种方式。由于智能手机的普遍应用，通过空中下载(Over-The-Air:0ΤΑ)成了主要的方式。由于空中下载有很多益处，因此世界上几个主要的机构形成了一个工作组叫做Open MobileAlliance (0ΜΑ)来制定空中下载的技术标准。其制定的标准0ΜΑ DM (Device Management)被IBM，微软和Motive以及其它大的厂商采用。据统计新近发行的移动设备中，80%的固件可以重构。0ΜΑ DM不仅可以用来下载、更新软件和修正软件中的错误，还可以用于车辆的管理，监控设备的信号和质量控制。近几年来，人们还做了大量的工作来提高0ΜΑ DM的性能，如设计新的管理代理(management agent)等。所有的这些方法都是基于传统的客户/服务器模式。这种模式不适合为大量的设备同时提供下载和更新。
[0004]国内相关0ΤΑ的专利主要集中在四个方面，即0ΤΑ技术的新方法，0ΤΑ实现的新方法，0ΤΑ的应用以及有关0ΤΑ的测试。
[0005]在专利文献CN101247416中公布了固件下载方法“基于0ΤΑ的固件下载方法、预处理方法、完整性验证方法”。该专利文献提出的是固件下载的预处理方法、固件完整性验证方法、以及固件下载方法，但还是基于传统的客户/服务器模式。
[0006]在专利文献CN102625288A “多处理器终端空中下载的方法及多处理器终端”中公开了多处理器终端空中下载的方法及多处理器终端。所述多处理器终端包括应用处理器AP、通信处理器CP和通用集成电路卡nCC。其中AP承担了 nCC和0ΤΑ服务器的中继站。当nCC向空中下载0ΤΑ服务器发起数据下载请求时，将所述数据下载请求发送给AP ；AP收到所述数据下载请求后，将所述数据下载请求发送至所述0ΤΑ服务器；AP接收到0ΤΑ服务器响应所述数据下载请求而发送的响应数据，并将所述响应数据发送至UICC，以实现数据下载。该文献通过AP进行0ΤΑ服务器与nCC之间的数据交互，提高了下载速度。该方案突破了传统的客户/服务器模式，提高了 0ΤΑ下载的效率。但是这些方法以及已公开的专利文献与发表的研究论文中所涉及到的0ΤΑ下载方法，都还是直接或者间接的从0ΤΑ服务器上下载软件，因此对0ΤΑ服务器提出了很高的要求，其性能和处理及数据传输速度将直接影响到各个客户端的使用，在客户端数量级高及待处理数据容量大的情况下，将不能满足客户的使用需求。
【发明内容】
[0007]本发明人注意到，上述现有技术存在如下的问题:由于现有的数据及软件更新方法都是通过与0ΤΑ服务器进行数据交互实现的，因此，在服务终端数量众多且传输数据量大，客户请求密集的情况下，难以满足各个服务终端客户的需要。同时，在网络中大量相同数据的发送，也造成了系统中数据传输资源的浪费，提高了使用成本。
[0008]因此，本发明的目的之一是解决软件更新过程中传输速度受到0ΤΑ服务器的制约及传输数据中拥塞的问题。
[0009]为此，本发明提供了软件更新方法，包括以下步骤:向多个客户端发送本地更新软件广播信息；判断是否有客户端发出应答信息，所述应答信息包括存在更新软件的信息，若是，则通过发送所述应答的客户端更新其它客户端本地软件，若否，则通过远端服务器更新本地软件。
[0010]在一些实施方式中，在客户端设置DL代理和CIC (中央信息控制器)模块。当某个客户端要更新本地软件时，其DL代理向CIC模块发送请求；CIC模块配置为发送本地更新软件广播信息，并注册和管理发出应答信息的客户端信息，确定下载更新软件的方式，由DL代理根据CIC模块确定的方式，与客户端或服务器连接进行软件下载和更新。
[0011]同时，本发明还提供了软件更新系统，包括广播发送单元及更新单元，其中，所述广播发送单元配置为向多个客户端发送本地更新软件广播信息；所述更新单元配置为判断是否有客户端发出更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0012]同时，本发明还提供了软件更新设备，包括:发送模块和更新模块，其中，所述发送模块配置为向其他客户端发送本地更新软件广播信息；所述更新模块配置为判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0013]本发明的上述实施方式具有以下优点:通过在一定的区域范围内，使客户终端通过相互交流确认所储存软件的信息。如果某一客户端储存其它客户端所需要的软件，则从该客户端下载。否则的话，则从0ΤΑ服务器下载。利用这种分散式的下载方式能让设备既能够从服务器下载，也可以从相邻节点下载。从而提高了下载速度，因此可以同时为大量的设备更新软件，还避免了服务器因大量的设备需求导致拥塞或者瘫痪的可能性。
[0014]本领域技术人员可以理解，本发明的方法虽然描述为以软件更新为对象，但实际上还可用于下载安装本机没有的新软件。因此，在本申请中所述的“软件更新““既包括了“更新旧软件“，也包括了 “下载新的软件”。
【专利附图】
【附图说明】
[0015]以下结合【专利附图】
【附图说明】本发明实施方式的技术方案。这些附图仅仅是用于描述本发明的一些实施例，而非对本发明的限定。其中:
[0016]图1为本发明一实施例的软件更新方法的流程图；
[0017]图2为本发明一实施例的分散式下载的示意图；
[0018]图3为本发明一实施例的客户端设备中代理的编程设计层级示意图；
[0019]图4为本发明一实施例的FUM0代理模块的设计示意图；
[0020]图5为本发明一实施例的DL Agent代理模块的设计示意图；
[0021]图6为本发明一实施例的CIC的设计模块示意图；
[0022]图7为本发明一实施例的软件更新系统的结构示意图；
[0023]图8为本发明一实施例的软件更新设备的结构示意图。
【具体实施方式】
[0024]下面结合附图和实施例，对本发明的【具体实施方式】作进一步详细描述。
[0025]如图1所示，为本发明一实施方式的软件更新方法的流程示意图。该软件更新方法包括以下步骤:
[0026]步骤S101:发送要更新软件的广播信息。在该步骤中，客户端的CIC向临近的多个客户端发送本身需要更新的软件广播信息。该广播信息包括软件名称和软件版本信息等。
[0027]步骤S102:进行本地软件的更新。临近的客户端CIC在收到该CIC广播信息后，立即应答。发出广播信息的客户端CIC从收到的应答信息中寻找哪个客户端设备储存有所需要的软件，并注册该设备的ID，以获得该设备所带有软件的信息，并通过该ID和该设备交流。随后向该设备发出下载软件的请求，并在设备确认下载请求后直接下载。如果所收到的应答信息中没有包含所需要更新的软件，那么发出广播信息的客户端直接联系0ΤΑ服务器，将按照传统的方法从服务器上下载更新软件。
[0028]作为一种实施方案，在步骤S102中，通过发送应答的客户端更新本地软件的步骤可包括:将发送应答的客户端地址注册到本地客户端软件读取列表中；根据本地客户端软件读取列表更新本地软件。
[0029]在一种实施方案中，通过发送应答的客户端更新本地软件的步骤还包括:判断发送所述应答客户端的数量是否为多个。若有多个，则根据多个应答客户端的忙碌度确定空闲的应答客户端，并通过空闲应答客户端更新本地软件；若只有一个，则通过发送应答的客户端更新本地软件。
[0030]上述根据多个应答客户端的忙碌度确定空闲应答客户端的步骤可包括:通过测量数据流量和节点的容量获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。从而，在发送存在更新软件的应答的客户端数量为多个时，可根据应答客户端的忙碌度选择要下载的客户端，优化了客户端间的负载均衡性。
[0031]在本实施方式中，结合了传统的客户/服务器模式和提出的分散式模式两种下载方式。本实施方式中下载方法如图2所示。在客户设备中设置一个新的模块，称之为DL代理(DL Agent)。DL代理、DM代理和FUM0代理几个模块在客户设备中共存。可以根据实际情况，智能地选取下载方式。
[0032]在DL 代理中，设置一个 CIC(Central Informat1n Controller:中央信息控制器)模块。该模块通过和其它客户设备中的CIC模块交流来实现客户设备间软件的下载。CIC模块记录设备中软件的信息，发布信息到其它的客户设备并且管理软件下载。
[0033]当一个客户设备要更新软件时，首先以广播消息的方式向区域网络内其它设备的CIC模块发出请求。如果某一个设备的CIC模块中存在所需求的软件，那么发出请求的这个设备就会和存在该软件的设备建立联系并从后者下载所需软件。如果区域网络中的客户端都没有所需要的软件，那么该设备就和服务器相连接并从服务器下载软件。这里，客户端下载软件与从服务器下载软件的方式都是常规的手段，不再赘述。
[0034]如果一个设备离开区域(例如通过与该设备的无线连接的断开来判定)，那么这个设备所带有相关软件的信息将从其它设备的CIC模块中删除。
[0035]以下具体说明在客户端设备中代理的实现方式。从编程的角度来看，客户端的逻辑设计分为四个层次。如图3所示，从顶到底，分别为应用层，DM核心层，硬件抽象层和操作系统。
[0036]本发明的主要部分都在应用层和DM核心层实现，如下所述。硬件和操作系统只是基础。以手机为例，手机的硬件及Android系统、1S等为其中运行的应用软件提供了操作环境。虽然对每个系统下所做的软件开发不同，但是对方法本身没有影响。也就是说，本领域技术人员对于此处描述的本发明的方法，可以利用常规的手段在不同的硬件和操作系统上相应地实现。因此，本说明书中对硬件抽象层和操作系统这两部分不再说明。
[0037]其中，应用层直接处理软件更新时的管理操作。从DM核心层接收操作指令并实现所指定的管理操作，如软件下载、更新等。此外，它还向DM核心层发回操作的结果以进行进一步的处理。然后，其结果可以被发送回服务器端。FUMO (Firmware Update ManagementObject:固件更新管理对象)代理和DL代理都在应用层。
[0038]其中，FUM0代理是OMA DM中固件下载和更新的核心模块，是已经标准化的固有模块。FUM0代理主要由两个包构成,即dm.client, downloadmanager和dm.client,updatemanager。
[0039]dm.client, downloadmanager负责处理由DM核心层解析来的软件更新并且和DL代理一起管理软件的下载。当采用传统的客户/服务器下载方式时，它也负责软件下载。dm.client, updatemanager主要负责软件的更新。图4显示了这两个包的详细设计。它们是常规的设计，因此不再赘述。
[0040]DL代理是本发明中提出的软件下载机制。和FUM0代理协同工作，在不同的情况下实现软件的下载。DL代理在这里起着管理员的作用，负责联系协调调度各个模块，包括系统中原有的下载管理模块。它根据CIC中的信息来确定以何种方法下载软件。因此，DL代理具有和CIC通信的能力，以获取相关的软件信息。另外，它也可以从邻近的客户端上下载软件。DL代理是由一个包来实现的，称之为dm.client, dlagent。dm.client, dlagent由五个代表不同功能的类组成。
[0041]DIManager类是DL代理的主要部分，它负责管理其它类的操作并且通知FUM0代理采用下载的方法。
[0042]RspforSwRQ类用来从CIC中获取软件的信息。
[0043]DIMethodDecider根据CIC中所获取的信息来决定哪种下载方法。
[0044]Communicat1n类负责实现DL代理和其它设备的通信。
[0045]decentralizedDownloader类负责分散下载(即从其它客户端下载)时软件的下载。
[0046]各个类的详细设计图如图5所示。CIC是决定下载方法的控制中心。从编写代码的角度来看，它由5个类组成，以实现五个不同的功能，即Broadcast (广播)，Register (注册)，DeviceManager (设备管理)，SoftwareManager (软件管理)和 Communicat1n (通信)。详细设计如图6所示。
[0047]其中，Broadcast使用Req4SW向它相邻的客户端广播所请求的软件。如果相邻的客户端设备有这个软件的话，将利用Req4RegiSter把设备和软件的信息返回到CIC中。CIC将利用Register模块中的AddDev功能注册该设备。注册完成后,CIC将用DeviceManager和SoftwareManager来管理特定的设备和软件。例如以软件管理为例，该管理包括注册、取消软件信息、获取软件的名称和获取软件等。
[0048]当某一设备要更新软件时，将利用Communicat1n向CIC模块发出请求信息。如果CIC模块响应该请求而在Register中找到与该更新软件相关的信息(如名称和版本号)，那么就通知发出请求的设备，该发出请求的设备和拥有要更新的软件的设备直接连接，并通过DL代理下载和更新软件。如果CIC中没有相关的信息，那么发出请求的设备就与内容服务器进行通信，采用传统的OMA DM下载方法通过FUM0代理下载和更新软件。
[0049]图7所示为本发明一实施方式的软件更新系统的结构示意图。该软件更新系统包括广播发送单元201及更新单元202。其中，广播发送单元201用于向其他客户端发送本地更新软件广播信息；更新单元202用于判断是否收到更新软件存在的应答，若收到应答，则通过发送应答的客户端更新本地软件；若未收到应答，则通过远端服务器更新本地软件。
[0050]同时，更新单元202还用于将应答的客户端地址注册到本地客户端软件读取列表中；根据所述本地客户端软件读取列表更新本地软件。
[0051]当应答客户端数量为多个时，所述更新单元202还用于判断所述应答客户端的数量是否为多个。若有多个，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。其中获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
[0052]如图8所示，为本发明软件更新设备结构示意图。该软件更新设备包括发送模块301和更新模块302。其中，
[0053]发送模块301用于向其他客户端发送本地更新软件广播信息；
[0054]更新模块302判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0055]更新模块302还包括:注册模块3021及通讯下载模块3022，其中，
[0056]注册模块3021将所述应答的客户端地址注册到本地客户端软件读取列表中；
[0057]通讯下载模块3022根据所述本地客户端软件读取列表，更新本地软件。
[0058]同时在此设备中还可包括:设备管理模块303、软件管理模块304。设备管理模块303生成所述应答客户端的设备信息。软件管理模块304生成更新软件的名称、版本及容量信息。
[0059]以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域技术人员能够根据这些公开内容想到的变化都属于本发明的范畴，并落入所附权利要求书限定的保护范围。
【权利要求】
1.软件更新方法，其特征在于，包括: 向多个客户端发送本地更新软件广播信息； 判断是否有客户端发出应答信息，所述应答信息包括存在更新软件的信息，若是，则通过发送所述应答的客户端更新其它客户端本地软件，若否，则通过远端服务器更新本地软件。
2.如权利要求1所述的软件更新方法，其特征在于，所述通过发送所述应答的客户端更新本地软件的步骤还包括: 将发出所述应答的客户端的地址注册到本地客户端软件读取列表中； 根据所述本地客户端软件读取列表更新本地软件。
3.如权利要求1或2所述的软件更新方法，其特征在于，所述通过发送所述应答的客户端更新本地软件步骤还包括: 判断所述应答客户端的数量是否为多个，若是，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。
4.如权利要求3所述的软件更新方法，其特征在于，所述根据多个应答客户端的忙碌度确定空闲应答客户端的步骤包括: 获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
5.如权利要求1-4任一项所述的软件更新方法，其特征在于，在客户端设置DL代理和CIC模块，所述方法包括: 当客户端要更新本地软件时，其DL代理向CIC模块发送请求； 所述CIC模块发送本地更新软件广播信息，并注册和管理发出应答信息的客户端信息，根据所注册的发出应答信息的客户端信息，确定下载更新软件的方式； DL代理根据CIC模块确定的下载更新软件的方式，与相应的客户端或服务器连接进行软件下载和更新。
6.软件更新系统，其特征在于，包括广播发送单元及更新单元，其中， 所述广播发送单元配置为向多个客户端发送本地更新软件广播信息； 所述更新单元配置为判断是否有客户端发出更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
7.如权利要求6所述的软件更新系统，其特征在于，所述更新单元还配置为将所述应答的客户端地址注册到本地客户端软件读取列表中；根据所述本地客户端软件读取列表更新本地软件。
8.如权利要求6或7所述的软件更新系统，其特征在于，所述更新单元还配置为判断所述应答客户端的数量是否为多个，若是，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。
9.如权利要求8所述的软件更新系统，其特征在于，所述更新单元还配置为获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
10.软件更新设备，其特征在于，包括:发送模块和更新模块，其中， 所述发送模块配置为向其他客户端发送本地更新软件广播信息； 所述更新模块配置为判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
11.如权利要求10所述的软件更新设备，其特征在于，所述更新模块还包括注册模块及通讯下载模块，其中， 所述注册模块配置为将发送所述应答的客户端地址注册到本地客户端软件读取列表中； 所述通讯下载模块配置为根据所述本地客户端软件读取列表更新本地软件。
12.如权利要求10或11所述的软件更新设备，其特征在于，还包括设备管理模块和软件管理模块，其中， 所述设备管理模块配置为生成发送所述应答的客户端的设备信息； 所述软件管理模块配置为生成更新软件的名称、版本及容量信息。
【文档编号】H04L29/08GK104378391SQ201310348829
【公开日】2015年2月25日 申请日期:2013年8月12日 优先权日:2013年8月12日
【发明者】王新珩, 张慧, 陆晓欢 申请人:无锡知谷网络科技有限公司
【专利摘要】本发明公开了软件更新方法、设备及系统，涉及数据共享及数据传输领域。本发明的软件更新方法包括：客户端向其他客户端发送本地更新软件广播信息；判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。本发明可以解决软件更新过程中传输速度受到OTA服务器的制约及传输数据中拥堵的问题，从而提高了下载速度，因此可以同时为大量的设备更新软件，避免了服务器因大量的设备需求导致拥塞或者瘫痪的可能性。
【专利说明】软件更新方法、系统及设备
【技术领域】
[0001]本发明涉及数据传输领域，特别涉及软件更新的方法、系统及设备。
【背景技术】
[0002]随着电子和通信技术的发展，越来越多的电子设备应用到日常生活中的各个方面。目前，这些电子设备的硬软件更新过程中不能实现兼容，而给使用者带来不便。为解决这一问题，已经提出了可重构设备(Reconfigurable Devices)技术。在实现可重构设备技术的过程中，在对硬件进行改进的基础上也必须得到软件的支持。可支持可重构设备的硬件包括FPGA或者rDPA处理器。这些处理器可以通过编程来调节其功能。
[0003]软件重构是有效实现硬件多种功能的方法。常用的操作方式是将编写好的软件放到一个服务器上，然后可重构设备从服务器下载并更新。下载可以通过有线和无线两种方式。由于智能手机的普遍应用，通过空中下载(Over-The-Air:0ΤΑ)成了主要的方式。由于空中下载有很多益处，因此世界上几个主要的机构形成了一个工作组叫做Open MobileAlliance (0ΜΑ)来制定空中下载的技术标准。其制定的标准0ΜΑ DM (Device Management)被IBM，微软和Motive以及其它大的厂商采用。据统计新近发行的移动设备中，80%的固件可以重构。0ΜΑ DM不仅可以用来下载、更新软件和修正软件中的错误，还可以用于车辆的管理，监控设备的信号和质量控制。近几年来，人们还做了大量的工作来提高0ΜΑ DM的性能，如设计新的管理代理(management agent)等。所有的这些方法都是基于传统的客户/服务器模式。这种模式不适合为大量的设备同时提供下载和更新。
[0004]国内相关0ΤΑ的专利主要集中在四个方面，即0ΤΑ技术的新方法，0ΤΑ实现的新方法，0ΤΑ的应用以及有关0ΤΑ的测试。
[0005]在专利文献CN101247416中公布了固件下载方法“基于0ΤΑ的固件下载方法、预处理方法、完整性验证方法”。该专利文献提出的是固件下载的预处理方法、固件完整性验证方法、以及固件下载方法，但还是基于传统的客户/服务器模式。
[0006]在专利文献CN102625288A “多处理器终端空中下载的方法及多处理器终端”中公开了多处理器终端空中下载的方法及多处理器终端。所述多处理器终端包括应用处理器AP、通信处理器CP和通用集成电路卡nCC。其中AP承担了 nCC和0ΤΑ服务器的中继站。当nCC向空中下载0ΤΑ服务器发起数据下载请求时，将所述数据下载请求发送给AP ；AP收到所述数据下载请求后，将所述数据下载请求发送至所述0ΤΑ服务器；AP接收到0ΤΑ服务器响应所述数据下载请求而发送的响应数据，并将所述响应数据发送至UICC，以实现数据下载。该文献通过AP进行0ΤΑ服务器与nCC之间的数据交互，提高了下载速度。该方案突破了传统的客户/服务器模式，提高了 0ΤΑ下载的效率。但是这些方法以及已公开的专利文献与发表的研究论文中所涉及到的0ΤΑ下载方法，都还是直接或者间接的从0ΤΑ服务器上下载软件，因此对0ΤΑ服务器提出了很高的要求，其性能和处理及数据传输速度将直接影响到各个客户端的使用，在客户端数量级高及待处理数据容量大的情况下，将不能满足客户的使用需求。
【发明内容】
[0007]本发明人注意到，上述现有技术存在如下的问题:由于现有的数据及软件更新方法都是通过与0ΤΑ服务器进行数据交互实现的，因此，在服务终端数量众多且传输数据量大，客户请求密集的情况下，难以满足各个服务终端客户的需要。同时，在网络中大量相同数据的发送，也造成了系统中数据传输资源的浪费，提高了使用成本。
[0008]因此，本发明的目的之一是解决软件更新过程中传输速度受到0ΤΑ服务器的制约及传输数据中拥塞的问题。
[0009]为此，本发明提供了软件更新方法，包括以下步骤:向多个客户端发送本地更新软件广播信息；判断是否有客户端发出应答信息，所述应答信息包括存在更新软件的信息，若是，则通过发送所述应答的客户端更新其它客户端本地软件，若否，则通过远端服务器更新本地软件。
[0010]在一些实施方式中，在客户端设置DL代理和CIC (中央信息控制器)模块。当某个客户端要更新本地软件时，其DL代理向CIC模块发送请求；CIC模块配置为发送本地更新软件广播信息，并注册和管理发出应答信息的客户端信息，确定下载更新软件的方式，由DL代理根据CIC模块确定的方式，与客户端或服务器连接进行软件下载和更新。
[0011]同时，本发明还提供了软件更新系统，包括广播发送单元及更新单元，其中，所述广播发送单元配置为向多个客户端发送本地更新软件广播信息；所述更新单元配置为判断是否有客户端发出更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0012]同时，本发明还提供了软件更新设备，包括:发送模块和更新模块，其中，所述发送模块配置为向其他客户端发送本地更新软件广播信息；所述更新模块配置为判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0013]本发明的上述实施方式具有以下优点:通过在一定的区域范围内，使客户终端通过相互交流确认所储存软件的信息。如果某一客户端储存其它客户端所需要的软件，则从该客户端下载。否则的话，则从0ΤΑ服务器下载。利用这种分散式的下载方式能让设备既能够从服务器下载，也可以从相邻节点下载。从而提高了下载速度，因此可以同时为大量的设备更新软件，还避免了服务器因大量的设备需求导致拥塞或者瘫痪的可能性。
[0014]本领域技术人员可以理解，本发明的方法虽然描述为以软件更新为对象，但实际上还可用于下载安装本机没有的新软件。因此，在本申请中所述的“软件更新““既包括了“更新旧软件“，也包括了 “下载新的软件”。
【专利附图】
【附图说明】
[0015]以下结合【专利附图】
【附图说明】本发明实施方式的技术方案。这些附图仅仅是用于描述本发明的一些实施例，而非对本发明的限定。其中:
[0016]图1为本发明一实施例的软件更新方法的流程图；
[0017]图2为本发明一实施例的分散式下载的示意图；
[0018]图3为本发明一实施例的客户端设备中代理的编程设计层级示意图；
[0019]图4为本发明一实施例的FUM0代理模块的设计示意图；
[0020]图5为本发明一实施例的DL Agent代理模块的设计示意图；
[0021]图6为本发明一实施例的CIC的设计模块示意图；
[0022]图7为本发明一实施例的软件更新系统的结构示意图；
[0023]图8为本发明一实施例的软件更新设备的结构示意图。
【具体实施方式】
[0024]下面结合附图和实施例，对本发明的【具体实施方式】作进一步详细描述。
[0025]如图1所示，为本发明一实施方式的软件更新方法的流程示意图。该软件更新方法包括以下步骤:
[0026]步骤S101:发送要更新软件的广播信息。在该步骤中，客户端的CIC向临近的多个客户端发送本身需要更新的软件广播信息。该广播信息包括软件名称和软件版本信息等。
[0027]步骤S102:进行本地软件的更新。临近的客户端CIC在收到该CIC广播信息后，立即应答。发出广播信息的客户端CIC从收到的应答信息中寻找哪个客户端设备储存有所需要的软件，并注册该设备的ID，以获得该设备所带有软件的信息，并通过该ID和该设备交流。随后向该设备发出下载软件的请求，并在设备确认下载请求后直接下载。如果所收到的应答信息中没有包含所需要更新的软件，那么发出广播信息的客户端直接联系0ΤΑ服务器，将按照传统的方法从服务器上下载更新软件。
[0028]作为一种实施方案，在步骤S102中，通过发送应答的客户端更新本地软件的步骤可包括:将发送应答的客户端地址注册到本地客户端软件读取列表中；根据本地客户端软件读取列表更新本地软件。
[0029]在一种实施方案中，通过发送应答的客户端更新本地软件的步骤还包括:判断发送所述应答客户端的数量是否为多个。若有多个，则根据多个应答客户端的忙碌度确定空闲的应答客户端，并通过空闲应答客户端更新本地软件；若只有一个，则通过发送应答的客户端更新本地软件。
[0030]上述根据多个应答客户端的忙碌度确定空闲应答客户端的步骤可包括:通过测量数据流量和节点的容量获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。从而，在发送存在更新软件的应答的客户端数量为多个时，可根据应答客户端的忙碌度选择要下载的客户端，优化了客户端间的负载均衡性。
[0031]在本实施方式中，结合了传统的客户/服务器模式和提出的分散式模式两种下载方式。本实施方式中下载方法如图2所示。在客户设备中设置一个新的模块，称之为DL代理(DL Agent)。DL代理、DM代理和FUM0代理几个模块在客户设备中共存。可以根据实际情况，智能地选取下载方式。
[0032]在DL 代理中，设置一个 CIC(Central Informat1n Controller:中央信息控制器)模块。该模块通过和其它客户设备中的CIC模块交流来实现客户设备间软件的下载。CIC模块记录设备中软件的信息，发布信息到其它的客户设备并且管理软件下载。
[0033]当一个客户设备要更新软件时，首先以广播消息的方式向区域网络内其它设备的CIC模块发出请求。如果某一个设备的CIC模块中存在所需求的软件，那么发出请求的这个设备就会和存在该软件的设备建立联系并从后者下载所需软件。如果区域网络中的客户端都没有所需要的软件，那么该设备就和服务器相连接并从服务器下载软件。这里，客户端下载软件与从服务器下载软件的方式都是常规的手段，不再赘述。
[0034]如果一个设备离开区域(例如通过与该设备的无线连接的断开来判定)，那么这个设备所带有相关软件的信息将从其它设备的CIC模块中删除。
[0035]以下具体说明在客户端设备中代理的实现方式。从编程的角度来看，客户端的逻辑设计分为四个层次。如图3所示，从顶到底，分别为应用层，DM核心层，硬件抽象层和操作系统。
[0036]本发明的主要部分都在应用层和DM核心层实现，如下所述。硬件和操作系统只是基础。以手机为例，手机的硬件及Android系统、1S等为其中运行的应用软件提供了操作环境。虽然对每个系统下所做的软件开发不同，但是对方法本身没有影响。也就是说，本领域技术人员对于此处描述的本发明的方法，可以利用常规的手段在不同的硬件和操作系统上相应地实现。因此，本说明书中对硬件抽象层和操作系统这两部分不再说明。
[0037]其中，应用层直接处理软件更新时的管理操作。从DM核心层接收操作指令并实现所指定的管理操作，如软件下载、更新等。此外，它还向DM核心层发回操作的结果以进行进一步的处理。然后，其结果可以被发送回服务器端。FUMO (Firmware Update ManagementObject:固件更新管理对象)代理和DL代理都在应用层。
[0038]其中，FUM0代理是OMA DM中固件下载和更新的核心模块，是已经标准化的固有模块。FUM0代理主要由两个包构成,即dm.client, downloadmanager和dm.client,updatemanager。
[0039]dm.client, downloadmanager负责处理由DM核心层解析来的软件更新并且和DL代理一起管理软件的下载。当采用传统的客户/服务器下载方式时，它也负责软件下载。dm.client, updatemanager主要负责软件的更新。图4显示了这两个包的详细设计。它们是常规的设计，因此不再赘述。
[0040]DL代理是本发明中提出的软件下载机制。和FUM0代理协同工作，在不同的情况下实现软件的下载。DL代理在这里起着管理员的作用，负责联系协调调度各个模块，包括系统中原有的下载管理模块。它根据CIC中的信息来确定以何种方法下载软件。因此，DL代理具有和CIC通信的能力，以获取相关的软件信息。另外，它也可以从邻近的客户端上下载软件。DL代理是由一个包来实现的，称之为dm.client, dlagent。dm.client, dlagent由五个代表不同功能的类组成。
[0041]DIManager类是DL代理的主要部分，它负责管理其它类的操作并且通知FUM0代理采用下载的方法。
[0042]RspforSwRQ类用来从CIC中获取软件的信息。
[0043]DIMethodDecider根据CIC中所获取的信息来决定哪种下载方法。
[0044]Communicat1n类负责实现DL代理和其它设备的通信。
[0045]decentralizedDownloader类负责分散下载(即从其它客户端下载)时软件的下载。
[0046]各个类的详细设计图如图5所示。CIC是决定下载方法的控制中心。从编写代码的角度来看，它由5个类组成，以实现五个不同的功能，即Broadcast (广播)，Register (注册)，DeviceManager (设备管理)，SoftwareManager (软件管理)和 Communicat1n (通信)。详细设计如图6所示。
[0047]其中，Broadcast使用Req4SW向它相邻的客户端广播所请求的软件。如果相邻的客户端设备有这个软件的话，将利用Req4RegiSter把设备和软件的信息返回到CIC中。CIC将利用Register模块中的AddDev功能注册该设备。注册完成后,CIC将用DeviceManager和SoftwareManager来管理特定的设备和软件。例如以软件管理为例，该管理包括注册、取消软件信息、获取软件的名称和获取软件等。
[0048]当某一设备要更新软件时，将利用Communicat1n向CIC模块发出请求信息。如果CIC模块响应该请求而在Register中找到与该更新软件相关的信息(如名称和版本号)，那么就通知发出请求的设备，该发出请求的设备和拥有要更新的软件的设备直接连接，并通过DL代理下载和更新软件。如果CIC中没有相关的信息，那么发出请求的设备就与内容服务器进行通信，采用传统的OMA DM下载方法通过FUM0代理下载和更新软件。
[0049]图7所示为本发明一实施方式的软件更新系统的结构示意图。该软件更新系统包括广播发送单元201及更新单元202。其中，广播发送单元201用于向其他客户端发送本地更新软件广播信息；更新单元202用于判断是否收到更新软件存在的应答，若收到应答，则通过发送应答的客户端更新本地软件；若未收到应答，则通过远端服务器更新本地软件。
[0050]同时，更新单元202还用于将应答的客户端地址注册到本地客户端软件读取列表中；根据所述本地客户端软件读取列表更新本地软件。
[0051]当应答客户端数量为多个时，所述更新单元202还用于判断所述应答客户端的数量是否为多个。若有多个，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。其中获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
[0052]如图8所示，为本发明软件更新设备结构示意图。该软件更新设备包括发送模块301和更新模块302。其中，
[0053]发送模块301用于向其他客户端发送本地更新软件广播信息；
[0054]更新模块302判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
[0055]更新模块302还包括:注册模块3021及通讯下载模块3022，其中，
[0056]注册模块3021将所述应答的客户端地址注册到本地客户端软件读取列表中；
[0057]通讯下载模块3022根据所述本地客户端软件读取列表，更新本地软件。
[0058]同时在此设备中还可包括:设备管理模块303、软件管理模块304。设备管理模块303生成所述应答客户端的设备信息。软件管理模块304生成更新软件的名称、版本及容量信息。
[0059]以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域技术人员能够根据这些公开内容想到的变化都属于本发明的范畴，并落入所附权利要求书限定的保护范围。
【权利要求】
1.软件更新方法，其特征在于，包括: 向多个客户端发送本地更新软件广播信息； 判断是否有客户端发出应答信息，所述应答信息包括存在更新软件的信息，若是，则通过发送所述应答的客户端更新其它客户端本地软件，若否，则通过远端服务器更新本地软件。
2.如权利要求1所述的软件更新方法，其特征在于，所述通过发送所述应答的客户端更新本地软件的步骤还包括: 将发出所述应答的客户端的地址注册到本地客户端软件读取列表中； 根据所述本地客户端软件读取列表更新本地软件。
3.如权利要求1或2所述的软件更新方法，其特征在于，所述通过发送所述应答的客户端更新本地软件步骤还包括: 判断所述应答客户端的数量是否为多个，若是，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。
4.如权利要求3所述的软件更新方法，其特征在于，所述根据多个应答客户端的忙碌度确定空闲应答客户端的步骤包括: 获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
5.如权利要求1-4任一项所述的软件更新方法，其特征在于，在客户端设置DL代理和CIC模块，所述方法包括: 当客户端要更新本地软件时，其DL代理向CIC模块发送请求； 所述CIC模块发送本地更新软件广播信息，并注册和管理发出应答信息的客户端信息，根据所注册的发出应答信息的客户端信息，确定下载更新软件的方式； DL代理根据CIC模块确定的下载更新软件的方式，与相应的客户端或服务器连接进行软件下载和更新。
6.软件更新系统，其特征在于，包括广播发送单元及更新单元，其中， 所述广播发送单元配置为向多个客户端发送本地更新软件广播信息； 所述更新单元配置为判断是否有客户端发出更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
7.如权利要求6所述的软件更新系统，其特征在于，所述更新单元还配置为将所述应答的客户端地址注册到本地客户端软件读取列表中；根据所述本地客户端软件读取列表更新本地软件。
8.如权利要求6或7所述的软件更新系统，其特征在于，所述更新单元还配置为判断所述应答客户端的数量是否为多个，若是，则根据多个应答客户端的忙碌度确定空闲应答客户端，通过所述空闲应答客户端更新本地软件，若否，则通过发送所述应答的客户端更新本地软件。
9.如权利要求8所述的软件更新系统，其特征在于，所述更新单元还配置为获取多个应答客户端中的最高数据交换速度，将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
10.软件更新设备，其特征在于，包括:发送模块和更新模块，其中， 所述发送模块配置为向其他客户端发送本地更新软件广播信息； 所述更新模块配置为判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。
11.如权利要求10所述的软件更新设备，其特征在于，所述更新模块还包括注册模块及通讯下载模块，其中， 所述注册模块配置为将发送所述应答的客户端地址注册到本地客户端软件读取列表中； 所述通讯下载模块配置为根据所述本地客户端软件读取列表更新本地软件。
12.如权利要求10或11所述的软件更新设备，其特征在于，还包括设备管理模块和软件管理模块，其中， 所述设备管理模块配置为生成发送所述应答的客户端的设备信息； 所述软件管理模块配置为生成更新软件的名称、版本及容量信息。
【文档编号】H04L29/08GK104378391SQ201310348829
【公开日】2015年2月25日 申请日期:2013年8月12日 优先权日:2013年8月12日
【发明者】王新珩, 张慧, 陆晓欢 申请人:无锡知谷网络科技有限公司
相关技术
网友询问留言
已有0条留言
- 还没有人留言评论。精彩留言会获得点赞！
1