CN102025712B - 一种数据更新方法、装置和系统 - Google Patents
一种数据更新方法、装置和系统 Download PDFInfo
- Publication number
- CN102025712B CN102025712B CN 200910195953 CN200910195953A CN102025712B CN 102025712 B CN102025712 B CN 102025712B CN 200910195953 CN200910195953 CN 200910195953 CN 200910195953 A CN200910195953 A CN 200910195953A CN 102025712 B CN102025712 B CN 102025712B
- Authority
- CN
- China
- Prior art keywords
- frame
- loading
- broadcasting
- load
- point
- 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.)
- Active
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明提供数据更新方法、装置和系统,涉及通讯领域。所述方法:从广播中接收加载数据帧;解析加载数据帧,当加载数据帧中包含本加载对象标识时存储该加载数据帧;利用存储的加载数据帧进行更新。另一方法:构建广播加载通道;通过广播加载通道向各加载对象广播加载数据帧,加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新。还提供了数据更新装置和系统。主控端通过广播方式发送加载数据帧可供多加载对象接收使用,使多个加载对象避免排队等待,且由于广播加载帧方式没有确认握手,无需多次等待应答,从而提高更新效率。
Description
技术领域
本发明涉及通讯领域,尤其涉及一种数据更新方法、装置和系统。
背景技术
随着电子设备被广泛的使用,在每一种电子产品的开发与维护过程中,电子产品软件功能不断推陈出新,电子产品的软件版本更新是一个常见的过程。
现有的电子产品的更新采用点对点更新方案,该方案中多个待更新单板需排队依次等待数据更新,采用固定的握手模式和数据传输窗口进行数据更新,即待更新单板在接收完一个窗口的数据帧之后,与主控端有一个确认的握手动作,通知主控端继续传输下一个窗口数据帧,主控端在接收到待更新单板的握手确认后,才继续发送下一个窗口数据帧。
发明人发现现有技术中至少存在如下问题,点对点更新方案中由于无法支持多个单板同步更新,更新效率很低。
发明内容
本发明实施例提供一种电子设备更新方法、装置和系统,以解决现有点对点更新方式由于无法支持多个待更新单板同步更新而导致更新效率低的问题。
一方面,提供了一种数据更新方法,包括:
从广播中接收加载数据帧;
解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
利用存储的所述加载数据帧进行数据更新。
另一方面,还提供了一种数据更新方法,包括:
通过广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新。
另一方面,还提供了一种数据更新装置,包括:
接收模块,用于从广播中接收加载数据帧;
解析存储模块,用于解析所述接收模块接收的加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
更新模块,用于利用所述解析存储模块存储的加载数据帧进行数据更新。
另一方面,提供了一种数据更新装置,包括:
构建模块,用于构建广播加载通道;
广播模块,用于通过所述构建模块构建的广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新。
再一方面,还提供了一种数据更新系统,包括主控端和多个加载对象,
所述主控端:用于通过广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧均携带需要进行更新的各个加载对象标识;
各个所述加载对象:用于从广播中接收加载数据帧,解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储所述加载数据帧;利用存储的所述加载数据帧进行更新。
与现有技术相比,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明一种电子设备更新方法实施例的流程图;
图2为本发明实施例中加载对象端丢帧处理的步骤流程图;
图3为本发明另一种电子设备更新方法实施例的流程图;
图4为本发明实施例中电子设备更新方法流程图;
图5为本发明实施例中控制广播加载数据帧频度的方法的步骤流程图;
图6为本发明一种电子设备更新装置实施例的结构框图;
图7为本发明实施例中第一丢帧处理模块的结构框图;
图8为本发明电子设备更新装置另一实施例的结构框图;
图9为本发明实施例中第二丢帧处理模块的结构框图;
图10为本发明一种电子设备更新系统实施例的结构框图。
具体实施方式
本发明实施例提供了一种电子设备更新方法、装置和系统,可以解决现有点对点更新方式无法支持多个待更新单板同步更新而导致更新效率低的问题。
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
参见图1所示的一种数据更新方法实施例,该实施例是以加载对象一方的角度来撰写的,可以包括:
步骤S101,加载对象从广播中接收加载数据帧;
步骤S102,加载对象解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
步骤S103,加载对象利用存储的所述加载数据帧进行更新。
可见,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
优选的,本发明实施例中所述从广播中接收加载数据帧之前还包括:
加载对象当接收到主控端发送的广播加载命令时,发出广播加载请求;接收主控端根据所述广播加载请求广播的加载初始化信息;当所述加载初始化信息包含本加载对象标识时,执行所述从广播中接收加载数据帧。
其中,加载对象在接收到主控端发来的广播加载命令后,对所述广播加载命令进行确认应答,即发起广播加载请求。基本上通信系统中的广播消息是无需确认应答的,只有点对点消息才有确认应答一说,所以优选的,这里采用点对点方式发送广播加载命令,当加载对象能识别该命令时,可以通过发送广播加载请求来启动广播加载,当加载对象不能识别则加载对象仍然可以按照点对点方式发起点对点单点加载请求,采用本段所述技术方案对系统的前向兼容是比较好的。
加载初始化信息可以包括本次广播加载的对象、总数据帧长度、每个加载数据帧的帧长度,各个加载对象接收到该广播消息后,启动内部的流程,并开始监听广播加载进程。这样可以减少系统之间的耦合性,通过加载初始化信息通知各个加载对象本次加载的数据帧格式,让本次加载可以按照特定的格式进行,加载对象即可预测本次数据加载的进程。
加载对象从广播中接收加载初始化信息后,在该加载初始化信息的广播加载对象列表中检测有没有自己的标识,如果没有,则对于后续的广播加载数据帧则不予处理,直接丢弃。
优选的,本发明实施例提供的所述方法还包括:各个加载对象从广播中接收加载结束信息的步骤,当从广播中接收到主控端广播的加载结束信息时,利用步骤S102中解析并存储的广播加载数据帧启动更新程序,进行更新。
采用上述技术方案,可以实现多个加载对象同时接收加载数据帧即更新程序所使用的数据,避免加载对象排队等待,极大的提高了更新加载对象程序的效率;而且,由于广播加载帧的方式没有确认握手的动作,使得更新流程大大简化,从而极大的提高了更新效率。
优选的,步骤S102中,所述存储该加载数据帧还包括:判断存储的加载数据帧的帧号是否连续,否则确定为丢帧,将丢失帧数量累加到当前总丢帧次数;
当所述当前总丢帧次数超过预设丢帧门限时,终止从广播中接收加载数据帧,发出点对点单点加载请求;并响应主控端启动的点对点数据加载流程重新加载数据;
当所述当前总丢帧次数未超过预设丢帧门限时,通过点对点方式发出携带丢失帧帧号和帧长度的丢帧重传请求;并接收符合所述丢失帧帧号和帧长度的数据加载帧,接收成功后更新所述当前总丢帧次数,当仍存在丢帧时,继续发起下一个丢帧重传处理。
这样,可以进一步有效解决丢帧的问题,即采用广播加载的技术方案,可能会出现更新程序所需要的数据不完整,无法完成更新的情况。因为整个广播加载过程是一个无确认的加载过程,主控端无法识别各个加载对象的加载情况,因此广播加载过程中的丢帧设计是一个关键的环节,需要主控端和加载对象分工协作。对加载对象来说,必须建立可靠的丢帧检测重传机制,需要及时检测丢帧,并主动发起重传流程,让丢帧以最快的速度请求重传回来;对关键的流程控制类命令,主控端可以增加机制来降低丢帧的概率,例如,主控端可以通过重发N1次(N1可设定,默认为3次)广播加载初始化信息(SW_LOAD(LOAD_INIT))或广播加载结束信息(SW_LOAD(LOAD_END))等机制实现。
下面通过实施例来具体说明加载对象端丢帧处理的技术方案:
从加载对象的角度来说,参看图2,采用的丢帧处理方案可以包括:
步骤S201,加载对象判断存储的加载数据帧的帧号是否连续,如果不连续则确定为丢帧,将丢失帧数量累加到当前总丢帧次数;
步骤S202,加载对象判断累计的当前总丢帧次数是否超过预设丢帧门限;
步骤S203,如果累计的当前总丢帧次数超过预设丢帧门限,则加载对象终止从广播中接收加载数据帧,向主控端发出点对点单点加载请求,执行步骤S207;
步骤S204,如果累计的当前总丢帧次数未超过预设丢帧门限,则加载对象通过点对点方式发出携带丢失帧的帧号和帧长度的丢帧重传请求;
步骤S205,加载对象接收主控端以点对点方式发来的符合上述丢失帧的帧号和帧长度的数据加载帧,并更新相应的丢帧记录及当前总丢帧次数;
步骤S206,当仍存在丢帧记录时,继续发起下一个丢帧重传处理,结束;
步骤S207,加载对象响应主控端启动的点对点数据加载流程重新加载数据。
在实施步骤S201时,需要对是否出现丢帧进行判断,该判断包括:若当前帧号为下一个待接收加载数据帧帧号时,则认为接收正常;若当前帧帧号小于下一个待接收加载数据帧帧号,则可以认为是重复帧或者是重发帧;若当前帧帧号大于下一个待接收加载数据帧帧号,即帧号不连续,则可以认为出现丢帧。出现丢帧时,记录丢帧信息,累计总丢帧次数,即将丢失帧数量累加到当前总丢帧次数,因为在步骤S205中有更新丢帧记录的动作,所以,总丢帧次数中需要减去已经重传回来的数据帧所占的丢帧次数。
在实施步骤S204时,加载对象向主控端发出丢帧重传请求,并将不连续的加载帧的帧号和帧长度一并发送给主控端,请求主控端重新发送该帧号的数据加载帧。其中,除最后一帧外,每次广播的所述加载数据帧的帧长度等于所述加载初始化信息中携带的每帧数据的帧长度。这里,所述加载帧帧长度即本次加载过程中的数据帧格式。
优选的,丢帧重传请求最好以最快的速度到达主控端,否则在丢帧相对密集时,很容易达到丢帧次数预设门限,致使丢帧重传机制失效,可以将主控端和加载对象的点对点方式发送的丢帧重传消息作为最高优先级处理。
在实施步骤S205时,更新相应的丢帧记录是指在丢帧记录中清除当前重传回来的丢帧信息。
上面的实施例从加载对象的角度,给出了本发明技术方案一种数据更新方法的实施步骤,还给出了本发明丢帧处理的技术方案,下面的实施例从主控端的角度,给出本发明技术方案一种数据更新方法的实施步骤,参看图3,可以包括如下步骤:
步骤S301,主控端构建广播加载通道。
步骤S302,主控端通过广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象通过所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新。
优选的,本发明实施例中,通过广播加载通道向各个加载对象广播加载数据帧之前还包括:
主控端向各个加载对象发送广播加载命令;
当接收到加载对象针对所述广播加载命令的第一条广播加载请求时,通过广播加载通道向各个加载对象广播加载初始化信息,所述初始化信息中携带需要进行更新的各个加载对象标识,以便加载对象通过所述初始化信息中包含的加载对象标识判断是否从广播中接收加载数据帧。
本发明实施例中,需要构建广播加载通道,在该广播加载通道上完成加载初始化信息、加载数据帧、加载结束信息等信息帧的广播。
每一种类型的加载对象,例如待更新的站点、终端都有自身的广播通信通道和点对点通信通道,本实施例中,主控端可以通过如下方法构建广播加载通道,即在各加载对象自身的广播通信通道上承载广播加载通道,具体的方法可以是,在现有各加载对象自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,以便主控端所能广播到的所有加载对象在收到广播消息时,能有效识别该广播加载消息,从而将加载流程承载到广播通信机制。也就是说,广播加载通道是软件通信上的一种协定,是一种通信机制,在现有的广播通信帧中增加广播加载信息域,可以将广播加载流程承载到广播通信机制中。广播加载信息域是一个可选域,当携带该域时,所有载频通信对象识别该信息帧为广播加载信息帧;当不携带该域时,所有载频通信对象识别该信息帧为普通的广播通信帧。举例说明:
采用GSM BTS3012系列的基站系统中,主控单板(主控端)与从属其管理的载频单板(加载对象)之间操作维护链路数据链路层是基于HDLC通信机制进行通信的,其广播通信帧的消息格式为:
Information Element消息元素 | Presence | Format格式 | Length长度 | Note消息 |
Recv Addr | M | V | 2 | 0xFFFF广播地址 |
Send Addr | M | V | 2 | 0 |
Control | M | V | 1 | HDCL控制域 |
Msg Len | M | V | 2 | 后面消息长度 |
Rack Type | M | V | 1 | 机架类型 |
Rack No | M | V | 1 | 机架号 |
则在现有的广播数据帧中增加广播加载信息域Boardcast Load Sw的封装,其消息格式为:
Information Element消息元素 | Presence | Format格式 | Length长度 | Note消息 |
Recv Addr | M | V | 2 | 0xFFFF广播地址 |
Send Addr | M | V | 2 | 0 |
Control | M | V | 1 | HDCL控制域 |
Msg Len | M | V | 2 | 后面消息长度 |
Rack Type | M | V | 1 | 机架类型 |
Rack No | M | V | 1 | 机架号 |
Boardcast Load Sw | O | 可选域 |
其中,广播加载信息域Boardcast Load Sw是个可选域,当携带该域时,所有载频通信对象识别该信息帧为广播加载信息帧;当不携带该域时,所有载频通信对象识别该信息帧为普通的广播通信帧。可见,本发明实施例提供的Boardcast Load Sw广播加载信息帧实际上是一种特殊的广播通信帧,该通信帧中Boardcast Load Sw域封装了广播加载的对象列表和加载流程相关的信息(包括加载初始化信息、加载分段数据、加载结束信息)。其消息格式可以是:
Information Element消息元素 | Presence | Format格式 | Length长度 | Note消息 |
EI | M | V | 1 | 0x80 |
Board List | M | V | 9 | 加载对象标识列表,按照比特解释,最低比特对应加载对象1。比特位设置为1代表包含对应加载对象 |
Msg Len | M | V | 1 | Msginfo包含字节数 |
Msg Info | M | V |
考虑到广播加载对象可选择,或多种广播功能同时启动,广播加载消息中在携带加载流程指示同时,需要携带广播加载对象列表,和广播加载帧实际加载数据帧长。在整个加载过程中,不一定需要所有的加载对象都发起广播加载请求,只要有一个加载对象发起广播加载请求就可以触发主控端发起广播加载流程。
其中,加载初始化信息及加载数据帧中携带有需要进行更新的各加载对象标识,例如,可以用加载对象列表的形式携带各加载对象标识,其中,加载对象标识用于标识各加载对象,比如加载对象名称、单板号等标识信息。
进一步的,加载初始化信息及加载数据帧中携带的需要进行更新的各个加载对象标识,可以是加载对象列表的形式,其还可以用以解决多种类型单板同时升级加载时加载数据包内容不一致问题,比如可根据加载对象列表中包含的各加载对象所属类型标识,指定主控端向基于同种类型的部分加载对象广播加载升级。在不同的总线上进行数据加载,广播加载数据帧格式可以完全统一,各接收对象可以通过加载对象列表来识别是否是本加载对象数据,如果不是则直接丢弃。
通常,加载初始化信息中还包含如下信息:
总数据帧长度,是为监控加载进程使用的,加载对象可以预测最大加载数据帧帧号,预测本次加载的最大时长,超过时长时自动发起点对点的加载,减少系统的不稳定性带来的问题。
每帧数据长度即帧长度,是通知各加载对象本次加载的数据帧格式,各单板对象仅接收满足该长度条件的数据帧,加载过程除最后一帧外必须长度一致,否则后续的加载数据帧帧号没有办法监控是否正确,无法实时有效检测丢帧,也无法让重传回来的丢帧插入到对应的数据位置。
优选的,所述加载数据帧发送完毕后,所述方法还包括:
通过广播加载通道广播加载结束信息,以便各个加载对象在接收到所述加载结束信息时利用所述存储的加载数据帧进行数据更新。
为了解决广播加载中出现的丢帧现象,在本发明的另一个实施例中,从主控端的角度来看,采用的丢帧处理技术方案可以包括:
当主控端收到加载对象发出的点对点单点加载请求时,对该加载对象启动点对点数据加载流程。
当主控端接收到加载对象发出的点对点单点加载请求后,启动点对点加载处理流程,主控端将所有的加载数据帧通过点对点的方式发送给发出请求的加载对象;点对点加载与广播加载最好为串行,广播加载结束后再启动单个点对点加载,以减少总线拥塞。
当主控端收到加载对象发来的点对点方式丢帧重传请求时,以点对点方式发送符合所述丢帧重传请求中携带的丢失帧的帧号和帧长度的加载数据帧。
当主控端接收加载对象发来的点对点丢帧重传请求时,该丢帧重传请求包括丢失的帧号和帧长度,主控端根据帧长度唯一识别对应的帧号的加载数据段,这样主控端就可以将对应长度和该帧号的数据发送给该加载对象。
上述给出的丢帧处理的实施例都是一种被动的处理方式,为了降低丢帧概率,也可以采用一种主动的处理方式,在本发明的另一个实施例中,可以设置主控端按照一定的时间间隔自动重复广播加载初始化信息或广播加载结束信息。有时,当第一次发出初始化信息之后,有的加载对象也许还没有启动,就可能遗漏接收,这样多发几次初始化信息就可以让加载对象的准备时间充分;当第一次发出广播加载结束信息之后,有的加载对象可能没有收到该结束信息进而不能及时启动更新程序,多发几次广播加载结束信息,可以尽可能的让加载对象接收到该结束信息,进而及时的启动更新程序。
可见,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
进一步的,本发明的实施例提供的丢帧处理方法,通过识别广播加载数据帧帧号是否连续来判断是否出现丢帧,并记录丢帧次数,当出现丢帧且丢帧次数超过预设门限时,终止接收广播加载数据帧,发出点对点单点加载请求;当出现丢帧但丢帧次数没有超过预设门限时,通过点对点方式发出丢帧重传请求。可以进一步解决由于广播加载帧的方式没有确认握手的动作而导致不能及时发现丢帧的问题,在网络环境不理想的状态下,有可能导致加载对象接收完毕加载数据帧之后,无法更新程序的现象。这样避免了采用广播方式而造成无法及时发现丢帧现象的不足。
上面分别从主控端和加载对象各自的角度描述了本发明的技术方案的实现,下面从主控端和加载对象两方面结合的角度来描述本发明技术方案的实现过程:在该实施例中参见图4所示,给出了整个广播加载的步骤流程图,该实施例描述了主控端和加载对象双方的动作,可以包括:
步骤S401,主控端通过点对点的方式向加载对象发送广播加载命令,加载对象对主控端发来的广播加载命令进行确认应答,并发起广播加载请求。
主控端启动广播加载前,向所有广播加载对象通过点对点的方式发送广播加载命令,指示即将进入广播加载;广播加载对象识别广播加载命令后,对主控端命令进行确认应答,并开始发起广播加载请求(BOARDCAST_LOAD_REQ);如果加载对象不能识别广播加载命令,则仍可以按照现有技术中通过点对点的方式发起点对点单点加载请求,这样的设计使得系统的前向兼容性较好。
步骤S402,主控端通过广播加载通道向各个加载对象广播加载初始化信息。
主控端在收到广播加载对象通过点对点方式发出的第一条广播加载请求(BOARDCAST_LOAD_REQ)后,开始以广播方式通过广播加载通道通知各个加载对象开始广播加载初始化信息(SW_LOAD(LOAD_INIT)),初始化信息可以包括本次广播加载的加载对象列表、加载总数据长度和每帧数据长度等信息。
步骤S403,主控端通过广播加载通道向各个加载对象广播加载数据帧,当从广播中接收的加载初始化信息中包含本加载对象标识时,则从广播中接收主控端广播的加载数据帧。
主控端向各个加载对象广播加载初始化信息(SW_LOAD(LOAD_INIT))后,主控端开始以一定的频度向各个加载对象广播加载数据帧(SW_LOAD(LOAD_SEG));广播加载数据帧以预定的窗口发送,数据窗口的大小可以预先设置,例如,可以设置一个窗口数据包含4帧数据帧。每个广播加载数据帧均包含各个加载对象列表、广播加载数据帧帧号及该帧号对应的加载数据帧帧长度。广播通道设计是没有握手机制的,因此广播加载也不可能有主控端和加载对象的握手确认机制,广播加载数据帧帧号及该帧号对应的加载数据帧帧长度是加载数据包的唯一定位标识。除最后一帧外,所有广播加载数据帧长度必须均与初始化消息中广播的每帧数据长度信息一致,这样可以保证在丢帧处理的时候,重发的帧数据可以插回到对应的位置;加载对象从广播通道上解析加载数据帧,当本加载对象包含在广播加载对象列表中时,则加载对象接收并处理广播加载数据帧,否则直接丢弃该广播加载数据帧。在一次广播加载中,所有加载对象收到的广播数据包是一致的,同时升级时可以指定同种类型加载对象的一部分更新,这个时候该类加载对象中不升级的加载对象不会在加载对象列表中,这些不在列表中的加载对象收到数据时也是直接丢弃的。
步骤S404,加载对象解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧,否则直接丢弃。
步骤S405,主控端通过广播加载通道广播加载结束信息,加载对象从广播中接收到加载结束信息时,利用存储的所述加载数据帧进行数据更新。
加载数据全部传输完毕后,主控端通过广播通道通知各加载对象广播加载结束信息SW_LOAD(LOAD_END)。
其中,在步骤S403主控端向各个加载对象广播加载数据帧过程中,还可以包括丢帧处理的步骤。
加载对象从广播加载数据帧SW_LOAD(LOAD_SEG)中解析帧号、帧长度、帧数据,根据帧号和帧长度将帧数据保存至对应缓存;当存储的帧号不连续时即出现丢帧时,记录丢帧信息,并累计当前总丢帧次数,如果当前总丢帧次数超过预设丢帧门限,加载对象终止从广播中接收加载数据帧,尝试向主控端启动点对点方式的单点加载;如果当前总丢帧次数没有超过预设丢帧门限,加载对象通过点对点方式向主控端请求丢帧重传SW_LOAD(RELOAD_DATA_REQ),丢帧重传请求携带丢失帧的帧号和帧长度;主控端收到加载对象的丢帧重传请求后,将符合丢失帧帧号和帧长度的数据帧通过点对点方式发给加载对象,加载对象将收到的对应丢帧数据保存至缓存,然后清除相应的丢帧记录,当存在另外的丢帧时,继续发起丢帧重传请求,直至所有丢帧收回。
正常业务帧和广播加载帧是同一总线上的两种不同格式的数据帧,正常业务帧可以认为是点对点通信消息;普通的广播消息可以认为是一种系统消息,向所有对象发送。在进行广播加载的时候,需要控制好广播加载帧的发帧频度,以免造成线路拥塞。
本发明的另一个实施例中,给出了通过控制广播加载数据帧的频度来解决可能造成线路拥塞的方案,可以通过如下方法控制所述广播加载数据帧的发帧频度:
在预定窗口的加载数据帧之后添加标志帧,当处理到所述标志帧时,发送下一预定窗口的加载数据帧;或
预设时间间隔,每隔所述时间间隔发送下一预定窗口的加载数据帧。
其中,在预定窗口的加载数据帧之后添加标志帧,当处理到所述标志帧时,发送下一预定窗口的加载数据帧的方法,具体的可以是:
步骤S501,主控端的流程控制层在预定窗口的加载数据帧之后增加一个标志帧;
步骤S502,流程控制层将预定窗口的加载数据帧连同标志帧发送至数据链路层;
步骤S503,流程控制层收到数据链路层发回的处理到该标志帧的通知之后,发送下一个预定窗口的加载数据帧。
该实施例是在主控端本身内部实施的,在主控端内部包括有流程控制层和数据链路层,流程控制层位于数据链路层之上。流程控制层在准备发送的预定窗口的数据加载帧之后增加一个标志帧,所述预定窗口,可以根据实际需要来设定,例如一个窗口可以包含4帧数据加载帧;标志帧在数据加载帧之后发送至数据链路层;数据链路层将收到的数据加载帧发送给加载对象,当数据链路层处理到标志帧时,说明数据链路层已经把前面收到的加载数据帧发送出去了,数据链路层将标志帧发回给流程控制层,意思是通知流程控制层可以继续发送下一个窗口的数据加载帧了,流程控制层收到所述标志帧之后,就继续按照预定窗口发送下一个窗口数据加载帧,当然,在下一个窗口数据加载帧之后也增加有一个标志帧。依照上述方法不断重复,直到数据加载帧发送完毕。实际应用中,不限于预定窗口加载数据帧与标志帧同时发送,还可以是将一预定窗口的加载数据帧发送完后,再发送一标志帧。
该实施例采用的技术方案可以应用在数据链路层和流程控制层相对开放的单项目团队开发的系统。
在下面的实施例中,介绍一种可以应用在流程控制层相对于数据链路层为黑盒操作的系统,也就是说,该系统的数据链路层的链路功能基于平台方式提供,流程控制层和数据链路层可以是分属不同的开发团队交付的产品。具体的,仍然沿用上面在预定窗口的加载数据帧之后添加标志帧的方法,所不同的是:在流程控制层和数据链路层之间增加注册消息处理方式的API接口(Application Programming Interface,应用程序编程接口),流程控制层通过该API接口分别注册广播加载消息和广播加载标志帧的处理方式,其中,广播加载消息的处理方式注册为广播发送,标志帧的处理方式注册为内部处理,即数据链路层通知流程控制层发送下一预定窗口的加载数据帧。
流程控制层通过API接口将预设的处理方式通知数据链路层,以便数据链路层无需关心消息的内容,只需按照流程控制层注册的处理方式对相应的加载数据帧和标志帧进行处理。
上述两种实施例给出的广播加载数据帧发帧频度控制的方法,这两种方法实施的时候对应用的环境有要求,在本发明的另一实施例中,介绍一种可以应用在任何系统中的控制发帧频度的方法,即预设时间间隔,每隔所述时间间隔发送下一预定窗口的加载数据帧:
根据各广播加载对象的处理能力和正常业务数据帧的通常情况来设置一个广播加载数据帧的时间间隔。譬如发送1M的软件包,每个数据帧的长度为256字节,那么需要发送帧数为4096,设定每发送4帧为一个窗口,假定每发送完一个窗口数据延时0.5s,那么这个加载的时间就是固定的0.5s×1024,而实际上传输一个窗口的数据是远远小于0.5s的,但需要考虑系统的最恶劣运行,需要一个保守的延时。
本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
进一步的,本发明的实施例提供了的丢帧处理的步骤,通过识别广播加载数据帧帧号是否连续来判断是否出现丢帧,并记录丢帧次数,当出现丢帧且丢帧次数超过预设门限时,终止接收广播加载数据帧,发出点对点单点加载请求;当出现丢帧但丢帧次数没有超过预设门限时,通过点对点方式发出丢帧重传请求。可以进一步解决由于广播加载帧的方式没有确认握手的动作而导致不能及时发现丢帧的问题,在网络环境不理想的状态下,有可能导致加载对象接收完毕加载数据帧之后,无法更新程序的现象。这样避免了采用广播方式而造成无法及时发现丢帧现象的不足。
针对上面的实施例介绍的本发明方法的技术方案,在下面的实施例中,提供了与方法的技术方案对应的装置和系统。
本发明实施例还提供了一种数据更新装置,应用于加载对象,参见图6,可以包括:
接收模块601,用于从广播中接收加载数据帧;
解析存储模块602,用于解析所述接收模块601接收的加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
更新模块603,用于利用所述解析存储模块602存储的加载数据帧进行数据更新。
优选的,所述接收模块还用于接收主控端发送的广播加载命令,以及从广播中接收加载初始化信息;则上述装置实施例还可以包括:
第一发送模块,用于当所述接收模块接收到主控端发送的广播加载命令时,发出广播加载请求;
第一处理模块,用于当所述接收模块接收到主控端根据所述广播加载请求广播的加载初始化信息,并且所述加载初始化信息包含本加载对象标识时,指示所述接收模块执行所述从广播中接收加载数据帧。
优选的,所述接收模块还用于从广播中接收加载结束信息;则上述装置实施例还可以包括:
更新指示模块,用于当所述接收模块接收到加载结束信息时,指示所述更新模块执行所述利用所述解析存储模块存储的加载数据帧进行数据更新。
进一步的,上述装置实施例还可以包括第一丢帧处理模块,所述第一丢帧处理模块,参见图7,可以包括:
记录单元701,用于判断所述解析存储模块存储的加载数据帧的帧号是否连续,如果不连续则确定为丢帧,将丢失帧数量累加到当前总丢帧次数,更新丢帧记录;
终止单元702,用于终止从广播中接收加载数据帧;
第一判断单元703,用于当存在丢帧信息时,判断记录单元701中记录的当前总丢帧次数数是否超过预设丢帧门限;
点对点加载单元704,用于当所述第一判断单元703的判断结果为超过预设丢帧门限时,指示所述终止单元702终止从广播中接收加载数据帧,并发出点对点单点加载请求;
点对点重传单元705,用于当所述第一判断单元703的判断结果为未超过预设丢帧门限且所述记录单元701记录的总丢帧次数不为0时,发出携带丢失帧的帧号和帧长度的点对点丢帧重传请求;
第二接收单元706,用于接收符合丢失帧的帧号和帧长度的数据加载帧,并指示所述记录单元701更新相应的丢帧记录。
可见,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
进一步的,本发明的实施例提供了的丢帧处理的步骤,通过识别广播加载数据帧帧号是否连续来判断是否出现丢帧,并记录丢帧次数,当出现丢帧且丢帧次数超过预设门限时,终止接收广播加载数据帧,发出点对点单点加载请求;当出现丢帧但丢帧次数没有超过预设门限时,通过点对点方式发出丢帧重传请求。可以进一步解决由于广播加载帧的方式没有确认握手的动作而导致不能及时发现丢帧的问题,在网络环境不理想的状态下,有可能导致加载对象接收完毕加载数据帧之后,无法更新程序的现象。这样避免了采用广播方式而造成无法及时发现丢帧现象的不足。
本发明的另一个实施例还提供了一种数据更新装置,应用于主控端,参见图8,可以包括:
构建模块801,用于构建广播加载通道;
广播模块802,用于通过所述构建模块801构建的广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新。
上述装置实施例还可以包括第二发送模块,用于向各个加载对象发送广播加载命令;和第一反馈模块,用于在接收到针对所述广播加载命令的第一条广播加载请求时,指示所述广播模块802通过广播加载通道广播加载初始化信息,所述初始化信息中携带需要进行更新的各个加载对象标识,以便加载对象通过所述初始化信息中包含的加载对象标识判断是否从广播中接收加载数据帧。
上述装置实施例中,所述广播模块802还用于当所述加载数据帧发送完毕后,通过广播加载通道广播加载结束信息,以便各个加载对象在接收到所述加载结束信息时利用所述存储的加载数据帧进行数据更新。
其中,所述构建模块801具体用于:
在各加载对象自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,从而在各个加载对象自身的广播通信通道上承载广播加载通道。
上述装置实施例还可以包括第二丢帧处理模块,参见图9,所述第二丢帧处理模块包括:
第三发送单元901,用于发送信息;
第三反馈单元902,用于当收到加载对象点对点单点加载请求时,指示所述第三发送单元901对该加载对象启动点对点数据加载流程;
第四反馈单元903,用于当收到加载对象点对点丢帧重传请求时,指示所述第三发送单元901以点对点方式发送符合丢失帧的帧号和帧长度的加载数据帧。
可见,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
进一步的,本发明的实施例提供了的丢帧处理的步骤,通过识别广播加载数据帧帧号是否连续来判断是否出现丢帧,并记录丢帧次数,当出现丢帧且丢帧次数超过预设门限时,终止接收广播加载数据帧,发出点对点单点加载请求;当出现丢帧但丢帧次数没有超过预设门限时,通过点对点方式发出丢帧重传请求。可以进一步解决由于广播加载帧的方式没有确认握手的动作而导致不能及时发现丢帧的问题,在网络环境不理想的状态下,有可能导致加载对象接收完毕加载数据帧之后,无法更新程序的现象。这样避免了采用广播方式而造成无法及时发现丢帧现象的不足。
再进一步的,由于本发明的实施例中没有确认握手的动作,因此整个更新过程中无需多次等待应答,不但可以缩短软件更新时间,极大的提高了更新效率,还进一步可以有效解决整个更新过程中业务中断的问题。
本发明实施例还提供了一种数据更新系统的实施例,参见图10,可以包括主控端1001和多个加载对象1002,
所述主控端1001,用于通过广播加载通道向各个加载对象1002广播加载数据帧,所述加载数据帧均携带需要进行更新的各个加载对象标识;
各个所述加载对象1002:用于从广播中接收加载数据帧,解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储所述加载数据帧;利用存储的所述加载数据帧进行数据更新。
上述系统实施例中,主控端1001还用于:向各个加载对象发送广播加载命令;则当接收到加载对象针对所述广播加载命令的第一条广播加载请求时,通过广播加载通道广播加载初始化信息,所述初始化信息中携带需要进行更新的各个加载对象标识,以便加载对象通过所述初始化信息中包含的加载对象标识判断是否从广播中接收加载数据帧;
各个加载对象1002还用于:当接收到主控端发送的广播加载命令时,发出广播加载请求,以便主控端在接收到针对所述广播加载命令的第一条广播加载请求时,通过广播加载通道广播加载初始化信息。
其中,主控端1001通过如下方法构建广播加载通道:
在各加载对象1002自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,从而在各个加载对象自身的广播通信通道上承载广播加载通道。
可见,本发明实施例中多个加载对象从广播中接收加载数据帧,解析如果包含本加载对象标识时,存储所述加载数据帧,并利用存储的加载数据帧进行更新,这样主控端通过广播加载通道以广播方式发送加载数据帧可以供多个加载对象接收并更新使用,使得多个加载对象可以避免排队等待,且由于广播方式没有确认握手动作,使得更新中无需多次等待应答,从而极大的提高了更新效率。
进一步的,本发明的实施例提供了的丢帧处理的步骤,通过识别广播加载数据帧帧号是否连续来判断是否出现丢帧,并记录丢帧次数,当出现丢帧且丢帧次数超过预设门限时,终止接收广播加载数据帧,发出点对点单点加载请求;当出现丢帧但丢帧次数没有超过预设门限时,通过点对点方式发出丢帧重传请求。可以进一步解决由于广播加载帧的方式没有确认握手的动作而导致不能及时发现丢帧的问题,在网络环境不理想的状态下,有可能导致加载对象接收完毕加载数据帧之后,无法更新程序的现象。这样避免了采用广播方式而造成无法及时发现丢帧现象的不足。
再进一步的,由于本发明的实施例中没有确认握手的动作,因此整个更新过程中无需多次等待应答,不但可以缩短软件更新时间,极大的提高了更新效率,还进一步可以有效解决整个更新过程中业务中断的问题。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员可以理解,结合本文中所公开的实施例描述的各示例的单元及方法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,所述程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (16)
1.一种数据更新方法,其特征在于,包括:
从广播中接收加载数据帧;
解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
利用存储的所述加载数据帧进行数据更新;
所述方法还包括:
判断存储的加载数据帧的帧号是否连续,如果不连续则确定为丢帧,将丢失帧数量累加到当前总丢帧次数;
当所述当前总丢帧次数超过预设丢帧门限时,终止从广播中接收加载数据帧,发出点对点单点加载请求;并响应主控端启动的点对点数据加载流程重新加载数据;
当所述当前总丢帧次数未超过预设丢帧门限时,通过点对点方式发出携带丢失帧帧号和帧长度的丢帧重传请求;并接收符合所述丢失帧帧号和帧长度的数据加载帧,更新所述当前总丢帧次数,当仍存在丢帧时,继续发起下一个丢帧重传处理。
2.根据权利要求1所述的方法,其特征在于,所述从广播中接收加载数据帧之前还包括:
当接收到主控端发送的广播加载命令时,发出广播加载请求;
接收主控端根据所述广播加载请求广播的加载初始化信息;当所述加载初始化信息包含本加载对象标识时,执行所述从广播中接收加载数据帧。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
从广播中接收加载结束信息;
则当从广播中接收到加载结束信息时,执行所述利用存储的所述加载数据帧进行数据更新。
4.一种数据更新方法,其特征在于,包括:
构建广播加载通道;
通过所述广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新;
其中,通过如下方法构建广播加载通道:
在各加载对象自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,从而在各个加载对象自身的广播通信通道上承载广播加载通道。
5.根据权利要求4所述的方法,其特征在于,所述通过广播加载通道向各个加载对象广播加载数据帧之前还包括:
向各个加载对象发送广播加载命令;
当接收到加载对象针对所述广播加载命令的第一条广播加载请求时,通过广播加载通道广播加载初始化信息,所述初始化信息中携带需要进行更新的各个加载对象标识,以便加载对象通过所述初始化信息中包含的加载对象标识判断是否从广播中接收加载数据帧。
6.根据权利要求4所述的方法,其特征在于,所述加载数据帧发送完毕后,所述方法还包括:
通过广播加载通道广播加载结束信息,以便各个加载对象在接收到所述加载结束信息时执行所述利用存储的加载数据帧进行数据更新。
7.根据权利要求4-6任一项所述的方法,其特征在于,所述方法还包括:
当收到加载对象发来的点对点单点加载请求时,对该加载对象启动点对点数据加载流程;
当收到加载对象发来的点对点丢帧重传请求时,以点对点方式发送符合所述丢帧重传请求中携带的丢失帧的帧号和帧长度的加载数据帧。
8.根据权利要求4-6任一项所述的方法,其特征在于,通过如下方法控制所述广播加载数据帧的发帧频度:
在预定窗口的加载数据帧之后添加标志帧,当处理到所述标志帧时,发送下一预定窗口的加载数据帧;或
预设时间间隔,每隔所述时间间隔发送下一预定窗口的加载数据帧。
9.一种数据更新装置,其特征在于,包括:
接收模块,用于从广播中接收加载数据帧;
解析存储模块,用于解析所述接收模块接收的加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储该加载数据帧;
更新模块,用于利用所述解析存储模块存储的加载数据帧进行数据更新;
所述数据更新装置还包括第一丢帧处理模块,所述第一丢帧处理模块包括:
记录单元,用于判断所述解析存储模块存储的加载数据帧的帧号是否连续,如果不连续则确定为丢帧,将丢失帧数量累加到当前总丢帧次数,更新丢帧记录;
终止单元,用于终止从广播中接收加载数据帧;
第一判断单元,用于当存在丢帧信息时,判断所述记录单元中记录的当前总丢帧次数是否超过预设丢帧门限;
点对点加载单元,用于当所述第一判断单元的判断结果为超过预设丢帧门限时,指示所述终止单元终止从广播中接收加载数据帧,并发出点对点单点加载请求;
点对点重传单元,用于当所述第一判断单元的判断结果为未超过预设丢帧门限且所述记录单元记录的总丢帧次数不为零时,发出携带丢失帧的帧号和帧长度的点对点丢帧重传请求;
第二接收单元,用于接收符合丢失帧的帧号和帧长度的加载数据帧,并指示所述记录单元更新相应的丢帧记录。
10.根据权利要求9所述的装置,其特征在于,所述接收模块还用于接收主控端发送的广播加载命令,以及从广播中接收加载初始化信息;
所述装置还包括:
第一发送模块,用于当所述接收模块接收到主控端发送的广播加载命令时,发出广播加载请求;
第一处理模块,用于当所述接收模块接收到主控端根据所述广播加载请求广播的加载初始化信息,并且所述加载初始化信息包含本加载对象标识时,指示所述接收模块执行所述从广播中接收加载数据帧。
11.根据权利要求9所述的装置,其特征在于,所述接收模块还用于从广播中接收加载结束信息;
所述装置还包括:
更新指示模块,用于当所述接收模块接收到加载结束信息时,指示所述更新模块执行所述利用所述解析存储模块存储的加载数据帧进行数据更新。
12.一种数据更新装置,其特征在于,包括:
构建模块,用于构建广播加载通道;
广播模块,用于通过所述构建模块构建的广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧中携带需要进行更新的各个加载对象标识,以便加载对象根据所述加载数据帧中包含的加载对象标识存储接收到的加载数据帧,并利用存储的所述加载数据帧进行数据更新;
其中,所述构建模块具体用于:在各加载对象自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,从而在各个加载对象自身的广播通信通道上承载广播加载通道。
13.根据权利要求12所述的装置,其特征在于,所述装置还包括:
第二发送模块,用于向各个加载对象发送广播加载命令;和
第一反馈模块,用于在接收到针对所述广播加载命令的第一条广播加载请求时,指示所述广播模块通过广播加载通道广播加载初始化信息,所述初始化信息中携带需要进行更新的各个加载对象标识,以便加载对象通过所述初始化信息中包含的加载对象标识判断是否从广播中接收加载数据帧。
14.根据权利要求12所述的装置,其特征在于,
所述广播模块还用于当所述加载数据帧发送完毕后,通过广播加载通道广播加载结束信息,以便各个加载对象在接收到所述加载结束信息时执行所述利用存储的加载数据帧进行数据更新。
15.根据权利要求12-14任一项所述的装置,其特征在于,所述装置还包括第二丢帧处理模块,所述第二丢帧处理模块包括:
第三发送单元,用于发送信息;
第三反馈单元,用于当收到加载对象点对点单点加载请求时,指示所述第三发送单元对该加载对象启动点对点数据加载流程;
第四反馈单元,用于当收到加载对象点对点丢帧重传请求时,指示所述第三发送单元以点对点方式发送符合丢失帧的帧号和帧长度的加载数据帧。
16.一种数据更新系统,其特征在于,包括主控端和多个加载对象,
所述主控端:用于通过广播加载通道向各个加载对象广播加载数据帧,所述加载数据帧均携带需要进行更新的各个加载对象标识,其中,所述主控端通过在各个所述加载对象自身广播通信通道的广播数据帧中,增加广播加载信息域的封装,从而在各个加载对象自身的广播通信通道上承载广播加载通道,以实现构建广播加载通道;
各个所述加载对象:用于从广播中接收加载数据帧,解析所述加载数据帧,当所述加载数据帧中包含本加载对象标识时,存储所述加载数据帧;利用存储的所述加载数据帧进行数据更新。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200910195953 CN102025712B (zh) | 2009-09-15 | 2009-09-15 | 一种数据更新方法、装置和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200910195953 CN102025712B (zh) | 2009-09-15 | 2009-09-15 | 一种数据更新方法、装置和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102025712A CN102025712A (zh) | 2011-04-20 |
CN102025712B true CN102025712B (zh) | 2013-08-07 |
Family
ID=43866569
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200910195953 Active CN102025712B (zh) | 2009-09-15 | 2009-09-15 | 一种数据更新方法、装置和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102025712B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102404387B (zh) * | 2011-10-25 | 2015-12-16 | 上海聚力传媒技术有限公司 | 一种用于与其他节点进行信息同步的方法、装置和设备 |
CN102347955A (zh) * | 2011-11-01 | 2012-02-08 | 杭州依赛通信有限公司 | 一种基于虚拟通道的可靠数据传输协议 |
CN104038813B (zh) * | 2014-06-20 | 2017-09-26 | 深圳市九洲电器有限公司 | 一种多屏互动方法及系统 |
CN106484446A (zh) * | 2015-08-28 | 2017-03-08 | 晨星半导体股份有限公司 | 应用程序的程序代码载入方法及应用其方法的电脑系统 |
WO2018045512A1 (zh) * | 2016-09-07 | 2018-03-15 | 海能达通信股份有限公司 | 一种数据组呼方法、装置及系统 |
CN109743521B (zh) * | 2018-12-25 | 2021-10-08 | 深圳云天励飞技术有限公司 | 视频数据传输方法、装置、电子设备和存储介质 |
CN111078255B (zh) * | 2019-12-13 | 2023-05-23 | 深圳中科讯联科技股份有限公司 | 一种软件升级方法和软件升级系统 |
CN113157611B (zh) * | 2021-02-26 | 2023-04-18 | 山东英信计算机技术有限公司 | 一种数据传输控制方法、装置、设备及可读存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0895419B1 (en) * | 1992-10-30 | 2002-06-26 | Ricos Co., Ltd. | Billing system for services provided via radio communications |
CN1591350A (zh) * | 2003-08-26 | 2005-03-09 | 华为技术有限公司 | 一种使前后台数据库中数据相一致的方法 |
CN1968078A (zh) * | 2006-09-29 | 2007-05-23 | 中兴通讯股份有限公司 | 一种移动多媒体广播接收终端时钟同步的方法 |
CN101127960A (zh) * | 2007-09-20 | 2008-02-20 | 中兴通讯股份有限公司 | 一种电子业务指南的差异性更新的系统及方法 |
CN101222344A (zh) * | 2008-01-23 | 2008-07-16 | 中兴通讯股份有限公司 | 文件组播传输方法和系统 |
CN101461181A (zh) * | 2006-04-24 | 2009-06-17 | 诺基亚公司 | 无线网络中可靠的多播/广播 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060023731A1 (en) * | 2004-07-29 | 2006-02-02 | Eduardo Asbun | Method and apparatus for processing data in a communication system |
-
2009
- 2009-09-15 CN CN 200910195953 patent/CN102025712B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0895419B1 (en) * | 1992-10-30 | 2002-06-26 | Ricos Co., Ltd. | Billing system for services provided via radio communications |
CN1591350A (zh) * | 2003-08-26 | 2005-03-09 | 华为技术有限公司 | 一种使前后台数据库中数据相一致的方法 |
CN101461181A (zh) * | 2006-04-24 | 2009-06-17 | 诺基亚公司 | 无线网络中可靠的多播/广播 |
CN1968078A (zh) * | 2006-09-29 | 2007-05-23 | 中兴通讯股份有限公司 | 一种移动多媒体广播接收终端时钟同步的方法 |
CN101127960A (zh) * | 2007-09-20 | 2008-02-20 | 中兴通讯股份有限公司 | 一种电子业务指南的差异性更新的系统及方法 |
CN101222344A (zh) * | 2008-01-23 | 2008-07-16 | 中兴通讯股份有限公司 | 文件组播传输方法和系统 |
Non-Patent Citations (2)
Title |
---|
《软件更新中PUSH和P2P分发的研究与实现》;王喜;《中国优秀硕士学位论文全文数据库》;20070215(第2期);全文 * |
王喜.《软件更新中PUSH和P2P分发的研究与实现》.《中国优秀硕士学位论文全文数据库》.2007,(第2期), |
Also Published As
Publication number | Publication date |
---|---|
CN102025712A (zh) | 2011-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102025712B (zh) | 一种数据更新方法、装置和系统 | |
US10083021B2 (en) | Method and apparatus for providing firmware over the air service to user equipments | |
CN100486390C (zh) | 无线分组交换网络中移动通信设备的联系管理 | |
KR101845086B1 (ko) | 푸시 알림 메시지를 전송하기 위한 장치 및 방법 | |
CN103514173A (zh) | 数据处理的方法和节点设备 | |
US20130139178A1 (en) | Cluster management system and method | |
WO2021057666A1 (zh) | 传输控制方法、网管服务器、基站及存储介质 | |
CN104346198A (zh) | 信息处理装置、服务器装置、信息处理方法和程序 | |
US11057813B2 (en) | Method and apparatus for transmitting downlink data | |
CN102210157B (zh) | 向客户端提供数据的方法 | |
CN103973414A (zh) | 一种数据传输方法及装置 | |
KR100451786B1 (ko) | 이동통신 시스템의 소켓 자동 관리 방법 | |
CN101088299B (zh) | 用于在目标忙时自动重新路由信息的系统和方法 | |
US7336947B2 (en) | Method for providing software in radio-based cellular communication networks, and a communication network for implementing the method | |
EP2502402A1 (en) | Expediting the distribution of data files between a server and a set of clients | |
CN101494569B (zh) | 一种报文处理方法和装置 | |
CN101562515A (zh) | 一种多处理机同步关键数据的方法 | |
CN101741811A (zh) | PMIPv6中接口前缀的注册方法、系统及本地移动锚点 | |
KR101007408B1 (ko) | 데이터 공유 기반 데이터 전송 방법 및 시스템 | |
CN103905429A (zh) | 基于dhcp扩展标签实现网络设备自动发现的方法 | |
EP1547262B1 (en) | System and method for piggybacking data across an open data channel of a wireless device | |
KR100977043B1 (ko) | 이동통신 시스템의 자동 재전송 요구를 이용한 데이터송수신 방법 및 장치 | |
CN109688085B (zh) | 传输控制协议代理方法、存储介质及服务器 | |
CN101242296B (zh) | 一种释放接口资源的方法、系统及设备 | |
CN111093288A (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 | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |