CN1291333C - 同步消息处理方法 - Google Patents

同步消息处理方法 Download PDF

Info

Publication number
CN1291333C
CN1291333C CNB028059638A CN02805963A CN1291333C CN 1291333 C CN1291333 C CN 1291333C CN B028059638 A CNB028059638 A CN B028059638A CN 02805963 A CN02805963 A CN 02805963A CN 1291333 C CN1291333 C CN 1291333C
Authority
CN
China
Prior art keywords
data
synchronization message
judged
transmission source
synchronization
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.)
Expired - Fee Related
Application number
CNB028059638A
Other languages
English (en)
Other versions
CN1494687A (zh
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.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial 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 Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of CN1494687A publication Critical patent/CN1494687A/zh
Application granted granted Critical
Publication of CN1291333C publication Critical patent/CN1291333C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275Synchronous replication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Abstract

一种同步消息处理方法,甚至当接收到大量同步消息时也不会引起损害。依据该方法,终端设备(100)包括:应用单元(102),用于保存将要实现数据同步的数据,以及接受用户对该数据的操作;同步单元(104),用于产生同步信息,使保存在应用部件(102)中数据和服务器(300)中的数据同步,并解释从服务器(300)接收的同步消息;以及协议处理单元(106),用于执行协议处理,将由同步单元(104)产生的同步消息发送到网络(200)中,并执行协议处理,将从网络(200)接收的同步消息传递到同步单元(104)中。如果来自先前同步消息的接收时间间隔在预先确定的时间内,则协议处理单元(106)丢弃该同步消息。

Description

同步消息处理方法
                         技术领域
本发明涉及一种用在通过网络连接到服务器并与服务器管理的数据获得数据同步的终端设备中的同步消息处理方法。
                         背景技术
在当今广泛应用的信息设备中,对于一个使用者来说具有多个终端设备,例如移动终端,蜂窝电话和个人计算机,以及在每个设备中的记录数据,例如地址和计划表等不再是什么稀罕的事了。将记录在多个终端设备中的数据更新成最新数据的行为称为“数据同步”,并且通过获得数据同步,就使保存在每个终端设备中的数据内容一致了。
今年来,出现了一种系统,来代替用户在用户的每个终端设备中执行数据同步,以及一种系统,称为组件,在其中,利益的各方通过网络共享事情所需数据、浏览这些数据并将这些数据复制到各方的终端中。
在这样的系统中,例如,如图1所示,蜂窝电话12、移动终端14、桌面个人电脑16和笔记本个人电脑18作为终端设备10(在图中简称为“终端”,这也应用于其它图中)通过互联网20连接到服务器30上。例如,当更新蜂窝电话12中的地址簿时,向服务器30登记被更新的数据。这样,在更新保存在终端设备14、16和18中而不是蜂窝电话12中地址簿的情况下,从这些终端设备14、16和18通过互联网20向服务器30发出数据同步请求。当接收到该请求时,服务器30返回该地址簿中被更新的数据,这样在终端设备14、16和18中的地址簿就被更新了。
图2表示这种情况下的处理顺序。首先,需要数据同步的终端设备10请求服务器30开始同步,并提供包含最新更新日期/时间的初始信息(1)。当服务器30接收到该请求时,开始同步处理,并向终端设备10提供保存在服务器30中包含最新更新日期/时间的初始信息(2)。当终端设备10需要数据更新时,设备10向服务器30提供地址簿的更新历史(3),并且,服务器30将保存在服务器30中的地址簿数据和终端设备10的地址簿数据进行比较,向终端设备10报告更新的内容,并指导更新(4)。在将地址簿准确地更新为从服务器30接收的更新内容之后,终端设备10向服务器30发送同步完成通知(5)。然后,服务器30记录终端设备10中的更新状态,并向终端设备10发送同步完成确认通知(6)。
需要在终端设备10上安装专用软件来执行这样的数据同步处理,这个软件还不是通用的。因此,目前正在讨论同步处理的标准化,这种标准化方案通常称为“Sync ML(同步ML)”。
如图3所示,在Sync ML下新的同步处理顺序中,服务器30a首先向设备10a发送一条消息(称为“服务器警告消息”),命令开始数据同步(1),终端设备10a解释这条消息(消息处理),以在显示屏上显示(2)。当用户选择数据同步处理,按照与图2相同的方式,终端设备10a向服务器30a提供开始同步处理的请求和初始信息,并以与图2中相同的同步处理开始(4)。
在Sync ML下新的同步处理顺序与图2中的情况不同,在于服务器30a发出开始数据同步的指令,并且终端设备10a执行该消息处理。
在这点上,由于服务器30a发送服务器警告消息,而不用知道用户和终端设备10a的条件,故可能发生一种情况,就是终端设备10a不发送同步开始请求(3)。因此,当没有从终端设备10a中接收到同步开始请求(3)时,服务器30a重复发送服务器警告消息。
这样,由于服务器端发送同步开始请求,用户就不会忘记执行终端设备的数据同步。而且,在终端设备的制造商中,通过在系统中引入Sync ML方案,在服务器中登记和管理出售的终端设备,就可能通过服务器来更新每个终端设备中的软件。
图4表示Sync ML的协议结构。在终端设备10a和服务器设备30a之间交换应用数据的通信中,在每个对应层上,发送方执行分解数据和给数据加头部的处理,而接收方执行从数据去头部并连接数据的处理。
图4表示了一个示例处理,其中将新加到终端设备10a地址簿数据库中的数据发送给服务器30a。例如,将该数据经Sync ML核转化为同步消息数据格式,然后,通过会话层(例如HTTP)、传输层(例如TCP)和网络层(例如IP)中的处理,形成带有IP头部的分组,并将其发送到连接局域网的服务器30a。
在服务器30a中,通过在网络层、传输层和会话层的处理,将接收的数据恢复为同步消息格式的数据。在会话层中,从该格式中将数据识别为同步消息,然后提供给Sync ML核。Sync ML核解释并将该数据转化为一种数据结构,以便写到应用地址簿的数据库中。这样,就将新的数据添加到服务器30a的应用数据库中。
在协议结构每层中的处理发生在终端设备10a或服务器30a的CPU中。随着层的变高,在该层中的处理将增加CPU的负担,从而将增加处理所要求的时间。例如,假定通过网络层、传输层和会话层处理100个字节数据,总的处理时间是0.01秒,那么,在Sync ML核中执行的消息处理,要求的处理时间大约是其10倍,即0.1秒。
但是,在Sync ML方案中,由于服务器发送一个同步开始指令消息(服务器警告信息),所以,可预知存在下面的问题。
在数据同步处理的过程中,终端设备10a和服务器30a相互通信,同时等待从另一方来的响应以进行到下一次发送。但是,不管用户的意愿和终端设备10a的状态,都将发送服务器警告消息,而服务器30a根据该警告消息来命令终端设备10a开始数据同步。当终端设备10a接收到该消息时,就处理和解释该消息。由用户根据解释的结果来确定是否开始数据同步;但是,一旦接收到服务器警告消息,就需要处理该消息,并且该处理加到CPU上的负载不小。
如果怀恶意的人(如黑客或计算机窃贼(cracker))向终端设备10a发送大量的同步消息(例如,1秒100条消息),则终端设备10a必须处理所有这些消息而停止所有其它处理,并且更进一步,在最坏的情况下,存在系统被瘫痪的危险。在本上下文中,“同步信息”是指与数据同步处理相关的任意消息,并包括图3(和图2)所示的所有消息,连同服务器警告消息。
实际上,由同时发送的大量消息所引起的损失有时发生在了流行的主页和搜索页上。
为了防止发生这样的损失,通常执行一种设置黑名单和白名单的方法,其中黑名单具体说明被拒绝接收的发送者,而白名单具体说明被允许接收的发送者,并且丢弃黑名单中说明的发送者的消息和丢弃没有在白名单中说明的发送者的消息。
但是,用户产生这样的名单是很费时间的,而且产生有效的名单是困难的。更进一步,在一个其终端设备中的软件是经过服务器来设置的系统中,就存在制造商改变服务器的情况,在这种情况下,当同步消息的发送者由白名单所限制时,恐怕就不能从应该收到消息的服务器中收到同步消息。而且,特别是很难通过黑名单来具体说明出现的黑客。
发明说明
本发明的一个目的是提供一种同步信息处理方法,甚至当发送大量同步消息时也能防止损害。
依据本发明的一个方面,同步消息处理方法具有以下步骤:接收数据;当接收的数据为与数据同步处理相关的消息时,判定接收的数据为同步消息;测量判断为同步消息的数据的接收时间并记录;对之前判断为同步消息的数据所记录的接收时间,与现在判断为同步消息的数据所记录的接收时间,计算它们之间的时间间隔;比较计算的时间间隔和阈值;以及当计算的时间间隔不大于所述阈值时,丢弃当前判断为同步消息的数据。。
                         附图说明
图1表示实现数据同步的系统的例子;
图2表示在图1系统中数据同步处理顺序的例子;
图3表示在Sync ML中数据同步处理顺序的例子;
图4是概念性表示在Sync ML中协议处理的例子;
图5是表示依据本发明的第一个实施例,将同步消息处理方法应用到终端设备中的结构示例方框图;
图6是表示图5所示的终端设备硬件结构示例的方框图;
图7是表示在图5所示的终端设备中协议处理器操作的流程图,以依据第一个实施例实现同步消息处理方法;
图8是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第二个实施例实现同步消息处理方法;
图9是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第三个实施例实现同步消息处理方法;
图10是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第四个实施例实现同步消息处理方法;
图11是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第五个实施例实现同步消息处理方法;
图12是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第六个实施例实现同步消息处理方法;以及
图13是表示在图5所示的终端设备中协议处理器操作的流程图,以依据本发明的第七个实施例实现同步消息处理方法。
                    具体实施方式
下面将参考附图对本发明的实施例进行具体地说明。
(第一个实施例)
图5是表示依据本发明的第一个实施例,将同步消息处理方法应用到终端设备的结构示例方框图。
如图5所示,终端设备100通过网络200连接到服务器300上。终端设备100具有应用部件102,用于保存将要实现数据同步的数据并接收用户对该数据的操作;同步处理器104,用于产生同步消息,使保存在应用部件102中数据和服务器300中的数据同步,并同时解释从服务器300接收到的同步消息;以及协议处理器106,用于执行协议处理以向网络200发送在同步处理器104中产生的同步消息,并进一步执行协议处理以将从网络200接收到的同步消息提供给同步处理器104。应用部件102的具体例子包括,例如,蜂窝电话的电话薄应用。在终端应用100和服务器300之间,由Sync ML执行数据同步处理。如前所述,在上下文中的“同步信息”是指与数据同步处理相关的任何消息,不仅包括服务器警告消息,而且还包括与数据同步处理相关的,在终端设备100和服务器300之间交换的所有信息。
同步处理器104将发送数据转换为Sync ML数据格式,同时解释以SyncML格式接收的数据,将其转换为一种数据结构以保存在应用部分102中。
当接收的数据是一种同步消息时,协议处理器106执行协议处理,直到将数据恢复为Sync ML格式,并将处理后的数据提供给同步处理器104。但是,在这个实施例中,在这个同步消息是在预先确定周期中接收的多个同步消息之一的情况下,只有当该消息是第一个数据时,该同步消息才被提供给同步处理器104,而当该消息不是第一个数据时,该同步消息被丢弃。协议处理器106的操作将在下面详细说明。
例如,终端设备100是蜂窝电话、移动终端或个人电脑(见图1),并且作为硬件结构具有例如图6所示的CPU 110、ROM 112、RAM 114、发送/接收芯片116以及定时器118。CPU110执行应用部件102、同步处理器104和协议处理器106的处理。ROM 112保存具体说明CPU 110操作的程序。RAM 114用作CPU 110的工作区。在图5中,发送/接收芯片116通过网络200发送/接收数据。定时器118测量数据的接收时间。另外,程序存储介质不限于ROM,可以使用适合于保存程序的任意记录介质(例如闪速存储器)。
与处理协议处理器106进行处理所要求CPU的负载相比,同步处理器104和应用部分102所做处理所要求的CPU 110的负载相当大。因此,在该实施例中,为了减少CPU 110的负载,协议处理器106判定是向上层(同步处理器104和应用部件102)提供所接收的同步消息,还是在中断同步消息之前不检查内容而丢弃该消息。
接下来,参考图7所示的流程图,对具有上述结构的终端设备100中的协议处理器106的操作进行说明。图7表示依据该实施例,实现同步消息处理方法的协议处理器106的操作。另外,图7所示的流程图作为控制程序保存在ROM112中,并由CPU 110实施。
首先,在步骤S1000中,从服务器300接收消息(数据)。
在步骤S2000中,对在步骤S1000中接收到的消息执行协议处理,并且从接收数据的数据格式中判定接收的消息是否为同步消息。当作为判定的结果,接收的消息不是同步消息(例如,当接收的消息是在web浏览器或e-mail中的消息时)(S2000:NO),处理流程进行到步骤S3000。而当接收的消息是同步消息(S2000:YES)时,进行到步骤S4000。
在步骤S3000中,将步骤S2000中通过协议处理的消息提供给上层模块(例如,web浏览器和e-mail的处理器)。
同时,在步骤S4000中,由定时器118测量的消息接收时间记录在RAM114中。
在步骤S5000中,计算当前测量的消息接收时间和保存在RAM 114中最后一次同步消息的接收时间之间的时间间隔。
然后,在步骤S6000中,判定在步骤S5000中计算的时间间隔是否小于或等于预先确定的阈值。例如,该阈值被设置为协议处理器106接收服务器警告消息以及同步处理器104完成对消息处理的处理时间。作为判定的结果,当计算的时间间隔小于或等于该阈值时(S6000:YES),协议流程进行到步骤S7000,而当计算的时间间隔大于计算的阈值时(S6000:NO),处理进行到步骤S8000。
在步骤S7000中,由于从最后一次接收开始的时间间隔小于或等于该阈值,也就是,从最后一次接收同步消息的接收时间间隔是在预先确定的时间内,于是将当前接收的同步消息丢弃。
同时,在步骤S8000中,由于最后一次接收的时间间隔大于该阈值,也就是,最后一次接收同步消息的接收时间间隔超过预先确定的时间,于是将当前接收的同步消息提供给上层模块的同步处理器104。
另外,当从协议处理器106接收到同步消息时,同步处理器104解释该同步消息。然后,例如,依据同步消息的内容,开始图3所示的数据同步处理。
这些操作随着CPU 110重复读取保存在ROM 112中具体说明层中处理的程序,以及重复读取RAM 114中的数据以将这些数据又写到该层中处理已结束的RAM 114中而开始进行。
换句话说,当在发送/接收芯片116中接收到从服务器300发送的数据,并将这些数据保存在RAM 114中时,CPU 110就从RAM 114中读取数据,同时,去掉连接的头部,并且判定这些数据是否为同步消息(另外,该处理可以通过RAM 114作为介质,在多个步骤中执行)。当该数据不是同步消息(在步骤S2000的“NO”的情况下),将该数据保存在RAM 114中。另一方面,当该数据是同步消息(在步骤S2000的“YES”的情况下),执行步骤S4000和步骤S5000的处理,并且做出步骤S6000的判定。然后,在步骤S6000的“YES”的情况下,丢弃数据而不是返回到RAM 114中。另一方面,在步骤S6000的“NO”的情况下,将数据保存在RAM 114中。
当该数据不是同步消息而是例如web浏览器或e-mail消息时,CPU110从RAM 114中读出数据,并依据从ROM 112中读出的相关程序来处理该数据。而且,相似地,对于保存在RAM 114中的同步消息,CPU 110从RAM114中读出数据,依据从ROM 112中读出的程序来解释该同步消息,并执行数据同步处理。
假定这个终端设备100接收了大量的同步消息,并且,不管CPU 100顺序地处理同步消息的解释,假定接收的同步消息是留在RAM 114中并引起RAM 114为溢出状态,这样发送/接收芯片116就不能接收数据,并存在可能发生系统停机的危险。
但是,由于终端设备100丢弃了在小于预定时间(阈值)的较短间隔内接收的同步消息,而不执行对CPU 110是费时的消息处理,甚至当接收到大量的同步消息时,也可以避免系统停机。
另外,即使当被丢弃的同步消息包括原来是必要的并指示开始同步的同步消息时(服务器警告消息),如果终端设备100不发送同步开始请求,由于服务器300又发送该同步消息,于是就没有什么不方便的。在这方面,同步消息有别于一旦丢弃而不重发的web浏览器和e-mail消息。
这样,依据该实施例,当在预先确定期间内有很多同步消息到达时,除了第一个消息外所有消息都被丢弃,这样,甚至当大量的同步消息同时达到时,也可能避免损害。更具体地说,例如,当怀有恶意的第三方发送大量同步消息时,就可能避免象系统停机或系统失效等这样的损害。
(第二个实施例)
构造第二个实施例,使得在数据同步处理过程中不会错误地丢弃从服务器来的消息。
依据本实施例终端设备的基本结构与依据第一个实施例,在图5和图6中所示终端设备的基本结构相同,以下不再说明。但是,该实施例与第一个实施例的不同在于同步处理器104,在同步处理过程中(见图3的(4))设置了一个标志,表示同步处理的过程。
如先前所述,如果终端设备100不发送同步开始请求,服务器300命令终端设备100开始同步的服务器警告消息将被重复地从服务器300中发出。但是,对于在同步处理过程中从服务器300发送到终端设备100的消息,不保证它们的重发。因此,在该实施例中,同步处理器104设置了一个标志,表示在同步处理过程中同步处理正在进行,这样,协议处理器106在时间标志设置期间不丢弃同步消息。
接下来,将参考图8所示的流程图,对依据本实施例的协议处理器106的操作进行说明。图8表示实施依据本实施例的同步消息处理方法的协议处理器106的操作。图8所示的流程图作为控制程序被保存在ROM 112中,并且由CPU 110实施。
在这个实施例中,如图8所示,步骤S2100被插入到图7所示的流程图中。
步骤S1000和步骤S2000与图7流程图的对应步骤相同,因此省略对其的详细说明。另外,在该实施例中,当接收到的消息是同步消息(S2000:YES)时,处理流程进行到步骤S2100。
在步骤S2100中,同步处理器104判定是否设置了一个标志来表示同步消息在处理中。作为该判定的结果,当表示同步处理正在进行的标志没有设置(关断)(S2100:YES)时,处理流程进行到步骤S4000。当表示同步处理正在进行的标志被设置了(S2100:NO)时,处理流程立即进行到步骤S8000。
步骤S4000到S8000与图7中所示的流程中的对应步骤相同,因而省略对其说明。但是,在该实施例中,当表示同步处理正在进行的标志被设置了(S2100:NO),另外,当时间间隔小于或等于阈值时(S6000:否),就执行步骤S8000的处理。
这样,依据本实施例,把将要丢弃的同步消息具体化(限制)为从服务器重发的服务器警报消息,这样,就可以确保同步处理的执行。
(第三个实施例)
在第三个实施例中说明这样的情况,其中白名单用于判定是否要丢弃同步消息。
依据本实施例终端设备的基本结构与依据第一个实施例的如图5和图6所示的终端设备的基本结构相同,以下不再说明,但本实施例与第一个实施例的不同在于RAM 114保存了白名单,而当协议处理器106判定是否丢弃同步消息时要参考白名单。
接下来,将参考图9所示的流程图对依据本实施例协议处理器106的操作进行说明。图9表示依据本实施例实施同步消息处理方法的协议处理器106的操作。另外,图9所示的流程图作为控制程序保存在ROM 112中,并由CPU 110实现。
如图9所示,在该实施例中,步骤6100和步骤6200被插入到图7所示的流程图中。
步骤S1000到S60000与图7所示流程图中的对应步骤相同,因而省略对其说明。但是,当时间间隔小于或等于阈值时(S6000:YES),处理流程进行到步骤S6100中。
在步骤S6100中,识别所接收的同步消息的发送源。
在步骤S6200中,判定在步骤S6100中识别的发送源是否在白名单中。作为判定的结果,当发送源不在白名单时(S6200:NO),处理流程进行到步骤S7000。当发送源在白名单时(S6200:YES),则处理流程进行到步骤S8000。
在步骤S7000中,由于在同步消息之间的接收间隔小于或等于该阈值,并且发送源不在白名单中,所以,就丢弃当前接收到的消息。
同时,在步骤S8000中,由于在同步消息之间的接收间隔超过该阈值,或者发送源在白名单中,所以,把当前接收的同步消息提供给作为上层模块的同步处理器104。
这样,依据该实施例,就可能避免丢弃从位于白名单的发送源发送的同步消息。进一步,在该实施例中使用白名单的方法不同于传统的方法,它并不将消息的发送者局限于白名单中的发送源,因而,甚至当制造商出于方便,改变了设置终端设备软件的服务器,也可能从改变后的服务器上接收消息。
另外,作为可选择功能,可以自动地将对其正常地执行同步处理的发送源,添加到白名单中。例如,在这种情况下,关于web浏览器和e-mail消息,用户需要检查它们的内容并判定是否将该发送源放在白名单中。同时,关于同步消息,可自动判定同步处理是否已经正确完成,并且当同步处理已经正确完成时,发送源被放入白名单中,因而能自动地产生白名单。
(第四个实施例)
在第四个实施例中说明了这样的情况,其中的白名单被用来设置(改变)用于判定是否丢弃同步消息的阈值。
依据本实施例的终端设备的基本结构与依据第一个实施例,图5和图6所示终端设备的基本结构相同。但是,该实施例与第一个实施例的不同在于RAM 114保存了白名单,并且协议处理器106使用白名单确定用来判定是否丢弃同步消息的阈值。
接下来,将参考图10所示流程图对依据本实施例协议处理器106的操作进行说明。图10表示实施依据该实施例的同步消息处理方法的协议处理器106的操作。另外,图10所示流程图作为控制程序保存在ROM 112中,并由CPU 110实施。
在该实施例中,如图10所示,步骤S5100,S5200,S5300和S5400被插入到图7所示的流程图中。
步骤S1000到步骤S5000与同图7所示流程中的对应步骤相同,因而省略对它们的说明。
在步骤S5100中,识别所接收的同步消息的发送源。
在步骤S5200中,判定在步骤S5100中识别的发送源是否在白名单中。作为判定的结果,当发送源不在白名单中时(S5200:NO),处理流程进行到步骤S5300。当发送源在白名单中时(S5200:YES),处理流程进行到步骤S5400。
在步骤S5300中,由于发送源不在白名单中,该阈值被设置为一个较大的值,并且处理流程进行到步骤S6000。具体地说,例如,在接收到服务器警告消息,且参考时间被设置在同步处理器104完成对消息处理所用时间的情况下,当希望给CPU 110提供附加时间时,就设置一个较大的阈值。在这种情况下,例如,为了在最坏的情况下,对服务器警告消息的处理最多只占用CPU110的大约50%,就将该阈值设置为两倍的参考时间。
同时,在步骤S5400中,由于发送源在白名单中,就将阈值设置为较小的值,并且处理流程进行到步骤S6000。具体地说,示例说明了与步骤S5300中描述的将阈值设置为较大值的情况相反的情况。更进一步,象该实施例那样,在白名单发送目的地的情况下,一般的阈值被设置为参考值的10倍以提供附加的时间,而只有当发送源在白名单中时,总的阈值被设置为参考值的1/10。
步骤S6000到S8000与图7所示流程中的相应步骤相同,因而省略对其说明。另外,在该实施例中,利用在步骤S5300或S5400中设置的阈值来执行步骤S6000的处理。
这样,依据本实施例,相应于发送源是否在白名单中,就可能调整消息的丢弃条件。例如,当发送源不在白名单中时,就可能对消息丢弃条件服务器进行限制。
(第五个实施例)
在第五个实施例中说明这样的情况,其中使用黑名单来判定是否丢弃同步消息。
依据本实施例终端设备的基本结构与依据第一个实施例,图5和图6所示终端设备的基本结构相同,以下不再说明。但是这个实施例与第一个实施例的不同在于RAM 114保存黑名单,并且当协议处理器106判定是否丢弃同步消息时将参考黑名单。
接下来,将参考图11中的流程图对依据本实施例协议处理器106的操作进行说明。图11表示依据本实施例实施同步消息处理方法的协议处理器106的操作。另外,图11所示的流程图作为控制程序保存在ROM 112中,并由CPU 110实施。
如图11所示,在该实施例中,步骤S6100和步骤S6300被插入到图7所示的流程图中。另外,与图9所示的第三个实施例相比,步骤S6300被插入到图9所示的流程图中,而步骤S6200被从图9所示的流程图中删除。
步骤S 1000到步骤S6000与图7所示流程图的对应步骤相同,因而省略对其说明。但是,在这个实施例中,当时间间隔小于或等于阈值时(S6000:YES),处理流程进行到步骤S6100。
在步骤S6100中,识别所接收的同步消息的发送源。
在步骤S6300中,判定在步骤S6100中识别的发送源是否在黑名单中。作为判定的结果,当发送源在黑名单中时(S6300:YES),处理流程进行到步骤S7000。当发送源不在黑名单中时(S6300:NO),处理流程进行到步骤S8000。
在步骤S7000中,由于在同步消息之间的接收间隔是在该阈值内,并且发送源是在黑名单中,所以就丢弃当前接收的消息。
同时,在步骤S8000中,由于同步消息之间的接收间隔超过了该阈值,或发送源不在黑名单中,所以,将当前接收的同步消息提供给作为上层模块的同步处理器104。
这样,依据本实施例,只有当同步消息之间的接收间隔不大于该阈值,且发送源在黑名单中时,才可能丢弃同步消息。
(第六个实施例)
在第六个实施例中说明这样的情况,其中使用黑名单来设置(改变)用于判定是否丢弃同步消息的阈值。
依据本实施例终端设备的基本结构与依据第一个实施例,图5和图6所示终端设备的基本结构相同,所以以下不再说明。但是,该实施例与第一个实施例的不同在于RAM 114中保存黑名单,而协议处理器106使用该黑名单来确定用于判定是否丢弃同步消息的阈值。
接下来,将参考图12所示的流程图对依据本实施例协议处理器106的操作进行说明。图12表示依据本实施实施例同步消息处理方法的协议处理器106的操作。另外,图12所示的流程图作为控制程序保存在ROM 112中,并由CPU 110实施。
在这个实施例中,如图12所示,步骤S5100,S5200,S5300和S5400被插入到图7所示的流程图中。另外,与图10中表示的第四个实施例相比,步骤S2500被插入到图10所示的流程图,而步骤S5250被从图10所示的流程图中删除。
步骤S 1000到S5000与图7所示的流程图中相应的步骤相同,所以省略对其说明。
在步骤S5100中,识别所接收的同步消息的发送源。
在步骤S5200中,判定在步骤S5100中识别的发送源是否在黑名单中。作为判定的结果,当发送源在黑名单中时(S5200:YES),处理流程进行到步骤S5300。当发送源不在黑名单中时(S5200:NO),则处理流程进行到步骤S5400。
在步骤S5300中,由于发送源在黑名单中,将阈值设置为一个较大的值,且处理流程进行到步骤S6000。具体地说,例如,在接收到服务器警告消息并且参考时间被设置在同步处理器104完成对该消息的处理所用的处理时间的情况下,当希望为CPU 110提供附加的时间时,就设置较大的阈值。在这种情况下,例如,为了对服务器警告消息的处理在最坏的情况下最多只占用CPU 110的大约50%,该阈值被设置为参考时间的两倍。进一步,象另一个例子那样,当发送源在黑名单中,并且该发送源的消息被优先丢弃时,就设置较大的阈值。在这种情况下,例如,对于从黑名单上的发送源发送来的消息,为了在最坏情况下将对其处理压到CPU 110的大约10%,就将黑名单上发送源的阈值设置为参考时间的10倍。
同时,在步骤S5400中,由于发送源不在黑名单上,该阈值被设置为较小的值,并且处理流程进行到步骤S6000中。具体地说,示例中这样的情况与该阈值被设置为步骤S5300所述较大值的情况相反。
步骤S6000到S8000与图7所示流程图中相应的步骤相同,因而省略对其的说明。另外,在该实施例中,利用在步骤S5300或S5400中设置的阈值来执行步骤S6000的处理。
这样,依据本实施例,相应于发送源是否在黑名单中,就可能调整消息丢弃条件。例如,当发送源在黑名单中时,就可能对消息丢弃条件服务器进行限制。
(第七个实施例)
在第七个实施例中说明这样的情况,其中的黑名单是自动产生的。
依据本实施例终端设备的基本结构与依据第一个实施例,图5和图6所示终端设备的基本结构相同,所以以下不再说明。但是,该实施例与第一个实施例的不同在于RAM 114保存黑名单,而当协议处理器106判定是否丢弃同步消息时将参考该黑名单,并且,当同一发送源在较短时间内连续发送同步消息时,将执行将该发送源加入黑名单的处理。
接着,将参考图13所示的流程对依据该实施例协议处理器106的操作进行说明。图13表示依据该实施例实施同步消息处理方法的协议处理器106的操作。另外,图13所示的流程图作为控制程序保存在ROM 112中,并由CPU 110实施。
在本实施例中,如图13所示,步骤S6100、S6120、S6140、S6160和S6300被插入到图7所示的流程图中。另外,与图11所示的第五个实施例相比,步骤S6120、S6140和S6160被插入到图11所示的流程图中。
步骤S1000到S5000与图7中所示的流程图中的相应步骤相同,因而省略对其的说明。另外,在本实施例中,当时间间隔小于或等于阈值时(S6000:YES),处理流程进行到步骤S6100。
在步骤S6100中,识别所接收的同步消息的发送源。
在步骤S6120中,例如,将在步骤S6100中识别的发送源保存在RAM114中。
在步骤S6140中,参考发送源的记录,就可以判定连续地发送同步消息的发送源是否为同一发送源。作为判定的结果,当连续发送同步消息的发送源是同一发送源时(S6140:YES),处理流程进行到步骤S6160。当同一发送源没有连续地发送同步消息时(S6140:NO),则处理流程进行到步骤S6300。
在步骤S6160中,由于同一发送源连续地发送同步消息,就将该发送源加入到黑名单中,且处理流程进行到步骤S6300。
在步骤S6300中,判定在步骤S6100中识别的发送源是否在黑名单中(包括在步骤S6160中加入的源)。作为判定结果,当发送源在黑名单中时(S6300:YES),处理流程进行到步骤S7000。当发送源不在黑名单中时(S6300:NO),处理流程进行到步骤S8000。
在步骤S7000中,由于同步消息之间的接收间隔在阈值内,且发送源在黑名单中,所以,就丢弃当前接收的消息。
同时,在步骤S8000中,由于同步消息之间的接收间隔超出阈值,或者发送源不在黑名单中,所以,就将目前接收的同步消息提供给作为上层模块的同步处理器104。
于是,依据该实施例,只有当同步消息之间的接收间隔不大于该阈值,且发送源在黑名单中时,可以丢弃同步消息。
另外,本发明并不局限于以上提到的实施例,可以实施在不超出权利要求的范围所进行的各种的修改。例如,实施例的特性可以是合适的任意组合。
从上述的说明可以显而易见的是,依据本发明,当怀有恶意的第三者发送大量的同步消息时,就可能避免如系统停机和功能瘫痪的损害。
该申请是根据专利申请号为2001-269247,2001年9月5日提交的日本专利,其全部内容作为参考一并列于此。
工业应用性
本发明可应用到通过网络连接到服务器并与服务器管理的数据获得数据同步的终端设备,例如用在Sync ML系统中的终端设备。

Claims (13)

1.一种同步消息处理方法,包括步骤:
接收数据;
当接收的数据为与数据同步处理相关的消息时,判定接收的数据为同步消息;
测量判断为同步消息的数据的接收时间并记录;
对之前判断为同步消息的数据所记录的接收时间,与现在判断为同步消息的数据所记录的接收时间,计算它们之间的时间间隔;
比较计算的时间间隔和阈值;以及
当计算的时间间隔不大于所述阈值时,丢弃当前判断为同步消息的数据。
2.依据权利要求1的同步消息,丢弃步骤在解释接收的数据之前。
3.依据权利要求1的同步消息处理方法,其中,当计算的时间间隔不大于所述阈值时,判断为同步消息的数据在丢弃步骤中全被丢弃。
4.依据权利要求1的同步消息处理方法,进一步包括步骤:
判定数据同步处理是否正在进行中,
其中,当数据同步处理正在进行中时,在丢弃步骤中不丢弃判断为同步消息的数据。
5.依据权利要求1的同步消息处理方法,还包括步骤:
确认判断为同步消息的数据的发送源;
判定所述发送源是否在白名单上;
其中,当计算的时间间隔不大于所述阈值,并且所述发送源不在白名单中时,在丢弃步骤中丢弃当前判断为同步消息的数据。
6.依据权利要求1的同步消息处理方法,进一步包括步骤:
确认判断为同步消息的数据的发送源;
判定所述发送源是否在白名单上;以及
根据所述发送源是否在白名单中,来设置在比较步骤中使用的所述阈值,
其中,在比较步骤中,将计算的时间间隔与在设置步骤中设置的所述阈值进行比较。
7.依据权利要求5的同步消息处理方法,进一步包括步骤:
根据判断为同步消息的数据,判定数据同步处理是否已经正确地完成;
当根据判断为同步消息的数据,数据同步处理已经正确地完成时,将所述发送源添加到白名单中。
8.依据权利要求6的同步消息处理方法,进一步包括步骤:
根据判断为同步消息的数据,判定数据同步处理是否已经正确地完成;
当根据判断为同步消息的数据,数据同步处理已经正确地完成时,将所述同步消息的发送源添加到白名单中。
9.依据权利要求1的同步消息处理方法,进一步包括步骤
确认判断为同步消息的数据的发送源;
判定所述发送源是否在黑名单上;
其中,当计算的时间间隔不大于所述阈值,并且所述发送源在白名单中时,在丢弃步骤中丢弃当前判断为同步消息的数据。
10.依据权利要求1的同步消息处理方法,进一步包括步骤:
确认判断为同步消息的数据的发送源;
判定所述发送源是否在黑名单上;
根据所述发送源是否在黑名单上,来设置在比较步骤中使用的所述阈值;
其中,在比较步骤中,将计算的时间间隔与在设置步骤中设置的阈值进行比较。
11.依据权利要求9的同步消息处理方法,进一步包括步骤:
当计算的时间间隔不大于所述阈值时,识别当前判断为同步消息的数据的发送源;
当计算的时间间隔不大于所述阈值时,记录当前判断为同步消息的数据的发送源;
根据发送源的记录结果,判定当前判断为同步消息的数据的发送源,是否与计算的时间间隔均不大于所述阈值的、之前判断为同步消息的数据的发送源相同;及
在当前判断同步消息的数据的发送源,与计算的时间间隔均不大于所述阈值的、之前判断为同步消息的数据的发送源相同时,将判断为相同的发送源添加到黑名单中。
12.依据权利要求10的同步消息处理方法,进一步包括步骤:
当计算的时间间隔不大于所述阈值时,确认当前判断为同步消息的数据的发送源;
当计算的时间间隔不大于所述阈值时,记录当前判断为同步消息的发送源。
根据发送源的记录结果,判定当前判断为同步消息的数据的发送源,是否与计算的时间间隔均不大于所述阈值的、之前判断为同步消息的数据的发送源相同;及
在当前判断为同步消息的数据的发送源,与计算的时间间隔均不大于所述阈值的、之前判断为同步消息的数据的发送源相同时,将判断为相同的发送源添加到黑名单中。
13.一种同步消息处理设备,包括:
接收数据的接收单元;
判定单元,用于在接收的数据为与数据同步处理相关的消息时,判定接收的数据为同步消息;
记录单元,测量判断为同步消息的数据的接收时间并记录;
计算单元,对之前判断为同步消息的数据所记录的接收时间,与现在判断为同步消息的数据所记录的接收时间,计算它们的时间间隔;
比较单元,将计算的时间间隔与阈值比较;
丢弃单元,当计算的时间间隔不大于所述阈值时,丢弃当前判断为同步消息的数据。
CNB028059638A 2001-09-05 2002-09-03 同步消息处理方法 Expired - Fee Related CN1291333C (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP269247/2001 2001-09-05
JP269247/01 2001-09-05
JP2001269247 2001-09-05

Publications (2)

Publication Number Publication Date
CN1494687A CN1494687A (zh) 2004-05-05
CN1291333C true CN1291333C (zh) 2006-12-20

Family

ID=19095101

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB028059638A Expired - Fee Related CN1291333C (zh) 2001-09-05 2002-09-03 同步消息处理方法

Country Status (4)

Country Link
US (1) US20040064517A1 (zh)
EP (1) EP1388792A1 (zh)
CN (1) CN1291333C (zh)
WO (1) WO2003023630A1 (zh)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NO20006683D0 (no) * 2000-12-28 2000-12-28 Abb Research Ltd Fremgangsmåte for tidssynkronisering
JP3965059B2 (ja) * 2002-02-01 2007-08-22 富士通株式会社 端末情報管理方法
US20070180127A1 (en) * 2003-11-11 2007-08-02 Nokia Corporation Preconfigured syncml profile categories
US8909712B2 (en) * 2003-11-25 2014-12-09 Sap Ag System and method for a generic mobile synchronization framework
DE102004018200A1 (de) * 2004-04-15 2005-11-10 Deutsche Thomson-Brandt Gmbh Verfahren zum Verarbeiten einer Folge von Datenpaketen in einer Empfängervorrichtung sowie Empfängervorrichtung
US7552303B2 (en) * 2004-12-14 2009-06-23 International Business Machines Corporation Memory pacing
US20060187915A1 (en) * 2005-02-18 2006-08-24 Rami Caspi Method and apparatus for updating a wireless telephone
US7609625B2 (en) * 2005-07-06 2009-10-27 Fortinet, Inc. Systems and methods for detecting and preventing flooding attacks in a network environment
CN100411484C (zh) * 2005-09-08 2008-08-13 华为技术有限公司 一种在通信设备中实现消息流控的方法
DE602006015986D1 (de) * 2005-10-21 2010-09-16 Research In Motion Ltd Instant-messaging-einrichtungs- bzw. -serverprotokoll
KR100724879B1 (ko) * 2006-03-06 2007-06-04 삼성전자주식회사 휴대단말기의 서머타임정보 업데이트 방법
CN101355524B (zh) * 2007-07-24 2013-10-09 华为技术有限公司 一种消息处理方法、系统、服务器和终端
US20130097116A1 (en) * 2011-10-17 2013-04-18 Research In Motion Limited Synchronization method and associated apparatus
CN102394930B (zh) * 2011-11-02 2014-11-19 宇龙计算机通信科技(深圳)有限公司 移动终端、云服务器和数据处理方法
CN103605800A (zh) * 2013-12-06 2014-02-26 贝壳网际(北京)安全技术有限公司 文件处理方法及系统
US10069785B2 (en) * 2015-06-05 2018-09-04 Apple Inc. Network messaging for paired devices
WO2016205842A1 (de) * 2015-06-25 2016-12-29 Fts Computertechnik Gmbh Vorrichtung und verfahren zur integration von softwarekomponenten in ein verteiltes zeitgesteuertes echtzeitsystem
JP6798349B2 (ja) * 2017-02-23 2020-12-09 株式会社デンソー 通信システム及び中継装置
CN110019494B (zh) * 2017-07-26 2021-09-07 北京国双科技有限公司 媒体数据处理方法和装置、存储介质及处理器
US11025488B1 (en) 2018-12-28 2021-06-01 8X8, Inc. Intelligent network operations for data communications between client-specific servers and data-center communications servers
US11044338B1 (en) 2018-12-28 2021-06-22 8X8, Inc. Server-presented inquiries using specific context from previous communications
US11622043B1 (en) 2019-03-18 2023-04-04 8X8, Inc. Apparatuses and methods involving data-communications virtual assistance
US11539541B1 (en) 2019-03-18 2022-12-27 8X8, Inc. Apparatuses and methods involving data-communications room predictions
US11196866B1 (en) 2019-03-18 2021-12-07 8X8, Inc. Apparatuses and methods involving a contact center virtual agent
US11445063B1 (en) 2019-03-18 2022-09-13 8X8, Inc. Apparatuses and methods involving an integrated contact center

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5829007A (en) * 1993-06-24 1998-10-27 Discovision Associates Technique for implementing a swing buffer in a memory array
JPH08272723A (ja) * 1995-03-30 1996-10-18 Canon Inc 情報処理方法及び装置
JPH09168182A (ja) * 1995-12-18 1997-06-24 Matsushita Electric Ind Co Ltd 移動電話装置及びその干渉回避方法
US6295541B1 (en) * 1997-12-16 2001-09-25 Starfish Software, Inc. System and methods for synchronizing two or more datasets
JP3963417B2 (ja) * 1999-11-19 2007-08-22 株式会社東芝 データ同期処理のための通信方法および電子機器
JP2001156834A (ja) * 1999-12-01 2001-06-08 Matsushita Electric Ind Co Ltd Faxサーバシステム

Also Published As

Publication number Publication date
WO2003023630A1 (fr) 2003-03-20
US20040064517A1 (en) 2004-04-01
EP1388792A1 (en) 2004-02-11
CN1494687A (zh) 2004-05-05

Similar Documents

Publication Publication Date Title
CN1291333C (zh) 同步消息处理方法
CN1285236C (zh) 用于图像处理的方法、设备及程序
CN1622055A (zh) 用于移动终端的应用数据管理方法和其中使用的移动终端
CN1308853C (zh) 电子文档阅览系统及其方法
CN1461130A (zh) 自动改变用户数据的系统及方法
CN1293467C (zh) 环境设定装置、环境设定程序存储介质、信息处理装置和环境设定方法
CN1229715C (zh) 信息控制系统和信息处理方法
CN100341368C (zh) 移动通信终端、控制移动通信终端的方法和遥控系统
CN1518708A (zh) 实时搜索引擎
CN1929472A (zh) 数据网络中管理数据传输的方法、系统、信号及介质
CN1585382A (zh) 在无线局域网接入点中处理分组数据的设备和方法
CN1238803C (zh) 综合Web浏览业务的装置及其方法
CN1731740A (zh) 网络设备的管理方法及网络管理系统
CN1577323A (zh) 结构化文挡处理器、结构化文挡处理方法和程序
CN1285229C (zh) 获取移动用户状态信息的方法、系统及相应用户识别模块
CN1960377A (zh) Ap与ac的连接处理方法、ap、计算机软件产品及设备
CN1679286A (zh) 电子邮件传送系统
CN1675884A (zh) 间歇通讯方法及间歇通讯装置
CN1917618A (zh) 视频数据传输方法及其传输系统
CN1934836A (zh) 内容中继服务器、内容中继系统、内容中继方法和采用该方法的程序
CN1858709A (zh) 一种协调面向用户功能执行顺序的方法和装置
CN1810009A (zh) 包括不同种类的终端集合的网络的环境管理系统
CN1227586C (zh) 根据授权使用数据处理设备的方法和数据处理设备
CN1881957A (zh) 信息处理系统、服务器装置、访问装置及设备操作方法
CN1704931A (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
C19 Lapse of patent right due to non-payment of the annual fee
CF01 Termination of patent right due to non-payment of annual fee