CN101527654B - 一种网管系统中的数据传输方法及系统 - Google Patents

Abstract

本发明公开了一种网管系统中的数据传输方法及系统，包括：服务器设置压缩阈值下限；服务器动态接收前台网元的上报数据并缓存所述上报数据，当缓存的所述上报数据长度超过所述压缩阈值下限，对缓存的所述上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；服务器将所述发送队列中的上报数据发送到客户端。本发明通过设置压缩阈值下限，保证压缩的效率，同时服务器提供设置消息流量阈值设置，系统对数据通道进行定时监控，根据当前流量情况来确定消息是否发送和压缩发送还是不压缩直接发送，从而能够提高服务器与客户端之间的数据传输效率，适应宽带或窄带的不同通讯环境。

Description

一种网管系统中的数据传输方法及系统

技术领域

本发明涉及一种网管系统中的数据传输方法及系统。

背景技术

目前，在网管系统中，一般采用前台网元处理业务数据，而后上报到服务器，服务器再将这些上报的数据传输到客户端的通讯架构。然而，服务器到客户端的通讯环境并不总是令人满意的。例如前台网元可能分布在沙漠、雪地等环境险恶的地方，这些地方很难具备与客户端的宽带连接，只能提供卫星信道等方式。因此，对于需要监控各个网元的服务器来说，若不能解决到客户端的通讯支撑问题，那么对于具有大量上报数据，例如信令跟踪，失败观察，性能，告警等应用，将有可能无法满足客户端用户对上报数据的实时性要求。或者，虽然客观通讯环境能够满足要求，但由于运营商希望限制某些功能的上报消息占用的带宽，也因此有可能丧失实时性。

目前，为了提高数据传输的实时性，业界通常的处理办法是消息发送前压缩，然后到接收方，对压缩数据进行解压缩从而获得数据。如图1所示，图中的数据发送装置通常位于服务器端，上报数据经过数据压缩模块的压缩及第一数据重组模块的重组为符合当前通讯协议的数据后，被发送给位于客户端的数据接收装置，数据接收装置通过第二数据重组模块解析出数据，通过数据解压模块对数据进行解压缩。这样的数据压缩解压缩处理虽然可以减少数据在网络中的传输包大小，但是实际上还远远不能满足电信等行业的实际要求，仍然需要对现有的数据传输方法进一步的改进。

发明内容

有鉴于此，本发明提供了一种网管系统中的数据传输方法及系统，可以提高数据压缩的效率，从而能够改善数据传输的及时性。

为了解决上述技术问题，本发明采用了如下技术方案：

一种网管系统中的数据传输方法，包括：

A、服务器设置压缩阈值下限；

B、服务器动态接收前台网元的上报数据并缓存所述上报数据，当缓存的所述上报数据长度超过所述压缩阈值下限，对缓存的所述上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；

C、服务器将所述发送队列中的上报数据发送到客户端。

上述的方法，还包括：

服务器设置定时监控；

当到达定时监控时间，服务器确定缓存的所述上报数据长度是否超过所述压缩阈值下限，如是，对所述上报数据进行压缩处理后置入发送队列；否则，对所述上报数据不进行压缩处理，直接置入发送队列。

上述的方法，还包括：服务器设置流量控制阈值，服务器确定前N秒的平均数据传输流量是否超过所述流量控制阈值，如是，将服务器发送上报数据到客户端的过程进行休眠。

上述的方法，服务器设置压缩阈值上限，置入发送队列中的上报数据长度不超过压缩阈值上限。

上述的方法，所述服务器与至少一个客户端进行数据传输，服务器与各个客户端间的数据传输通道在服务器与客户端数据传输期间被绑定。

上述的方法，所述数据传输通道的数量为固定值，当客户端数量超过所述数据传输通道的数量时，客户端对所述数据传输通道的争用遵循先来先占原则。

上述的方法，不同的数据传输通道用不同的消息主题进行标记。

本发明还公开一种网管系统中的数据传输系统，包括：

压缩阈值设置单元，位于服务器上，用于设置压缩阈值下限；

数据预处理单元，位于服务器上，用于动态接收前台网元的上报数据并缓存所述上报数据，当缓存的所述上报数据长度超过压缩阈值下限，对缓存的所述上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；

数据发送单元，位于服务器上，用于将所述发送队列中的上报数据发送到客户端。

所述系统还包括：定时监控单元，用于设置定时监控时间，并在定时监控时间到达时，确定缓存的所述上报数据长度是否超过所述压缩阈值下限，如是，对所述上报数据进行压缩处理后置入发送队列；否则，对所述上报数据不进行压缩处理，直接置入发送队列。

上述的系统，还包括数据传输通道配置模块，用于为不同客户端各自配置数据传输通道并将其与客户端绑定。

与现有技术相比，本发明的有效效果在于：通过设置压缩阈值，根据缓存的上报数据长度是否超出压缩阈值而选择是否进行压缩，从而可以提高压缩效率，也因此可以改善数据上报的及时性。

附图说明

图1描述了一种常用的数据压缩传输装置；

图2描述了本发明示例的数据传输系统的原理框架；

图3描述了本发明示例的数据压缩格式；

图4描述了本发明示例的数据压缩处理流程；

图5描述了本发明示例的传输通道绑定的原理架构；

图6描述了本发明示例的客户端参数配置；

图7描述了本发明示例的数据传输系统的一种具体实现框架。

具体实施方式

下面对照附图并结合具体实施方式对本发明做详细说明。

本发明的第一方面是实现即使在低带宽情况下，也能让用户收到及时的数据上报。需要说明的是，这个“及时”是根据实际应用的特点来决定的，需要在通讯媒体能力、服务器负荷、客户对上报数据的实时性要求之间协商。

本发明的第二方面是实现多客户端的上报消息处理的机会均等，实现根据实际网络带宽情况进行灵活设置，从而达到连接到同一个服务器上的不同带宽的用户能各得其所(高带宽用户可以充分利用带宽在第一时间看到最新上报数据，低带宽用户可以在该用户能接受的情况下最大限度的得到相对及时的数据)。

对于本发明的第一方面，本发明的着眼点落在如何提高上报数据的压缩效率上。

表1

类型	原始长度(byte)	压缩后长度(byte)	压缩率
				GMLC	64	53	17.19
IGW	129	64	50.39
				ANU	88	44	50.00
MSCMAP	129	65	49.61
				MM	23	43	-86.96
GSMSSF	129	59	54.26
				SMSSSF	129	54	58.14
MSCMAP	129	65	49.61
				VLR	97	118	-21.65

如表1所示，本发明对各种类型的数据压缩进行了分析，从中发现，对于单个码流(消息长度较小)，其压缩比率不高而且不稳定，为此，最好能够做批量压缩。同时通过大量的试验数据验证，本发明提出，在压缩处理中若数据总长小于最小压缩单位，则不必压缩，因为压缩后的字节数比没有压缩的还多。

图2示例性的描述了本发明的数据传输系统的原理框架，需要了解，该图仅作为对本发明的数据传输的示例性说明，并非对本发明的数据传输系统结构的具体限定。在本发明的发明构思下，该框架完全可以进行调整。

在本发明中，将发送方设备称为服务器端，接收方设备称为客户端。图2中，以数据发送装置100表示服务器端，数据接收装置200表示客户端。

在数据发送装置100中，网元数据接收单元101接收来自前台网元的上报数据；上报数据由网元数据缓存单元102进行缓存；

根据前文的分析，当数据长度小于最小压缩单位时，如果还对该数据进行压缩，压缩后的字节数比没有压缩的还多。因而，在本发明中，在服务器端设置有压缩阈值下限，在数据长度超过压缩阈值下限时，才进行压缩。由于缓存的上报数据可能来自不同的前台网元，或者是由前台网元在不同时间上报，或者是代表不同任务，因此，在本发明中压缩所针对的数据通常不是一条数据，而是一批数据，即本发明的压缩是一种批量压缩，数据的批量压缩将由数据批量压缩单元103进行，批量压缩后的数据将形成一个DataPackage对象(将在后文描述)。

DataPackage对象将被送入到服务器端的发送队列中作为待发送数据，对于发送队列而言，其可能包含不止一个DataPackage对象，例如，如果将发送设置为定时发送，或者DataPackage对象进入发送队列的速度大于DataPackage对象从发送队列被发出的速度，发送队列中都会积累一定数量的DataPackage对象。因此，在本发明中，将发送称为批量发送，这将由批量发送单元104完成。

数据发送装置100发出的数据将在客户端被数据接收装置200接收，在数据接收装置200中，首先有接收数据缓存单元201接收由数据发送装置100发送来的数据，而后由接收数据重组单元202数据进行重组(解析通讯协议，从通讯数据包中重组出DataPackage对象)。

在数据解压缩单元203，解析出的DataPackage对象被解压缩，而后被送入解压缩数据缓存单元204缓存。

图3描述了DataPackage对象的格式，在此，将某个前台网元针对某个任务一次发送到服务器端的上报数据称为一条消息，一条消息包括参数部分和数据体部分，消息参数将记录消息的起始位置、消息的长度、消息的对应任务等等信息。一个DataPackage对象将包含参数列表Paras和数据体Data，参数列表Paras记录该DataPackage对象中的各条消息的参数部分，数据体Data存储该DataPackage对象中的各条消息的数据体部分。DataPackage对象还设置有压缩标志isCompressed，以指明该DataPackage对象中的数据是否被压缩，以利于客户端根据该压缩标志对接收到的DataPackage对象进行相应处理。

根据前文所述，在服务器端，可以设置压缩参数以表明前台网元的上报数据是否需要压缩，例如，在服务器缓存的数据长度超过设置的压缩阈值下限，则将压缩参数设置为需要压缩。

压缩参数设置为需要压缩时，服务器压缩数据体，设置压缩标志为true，发送数据；如果压缩参数设置为不需要压缩，则不对数据体进行压缩，设置压缩标志为false。需要注意的是压缩的粒度是一批数据(DataPackage)，故压缩标志是标志这一批数据是否压缩，而不是针对其中的单条消息。通过通讯双方约定的压缩参数中的压缩标志，确保了在同一条通信链路上同时传输压缩和未压缩的数据，而在解析上不发生冲突。

本发明在发送方通信设备和接收方通信设备上设置了统一的压缩参数，这个压缩参数随数据对象一起传送，由于通信双方不必再对压缩或解压缩参数和相关控制进行初期协商，减少了协商时间和协商流量，增加了压缩比和减少了处理时间。

图4示例性的描述了本发明的数据传输的压缩处理流程。图4中，左侧是未设置定时检查的处理流程。该流程中：

在步骤S101，可以在服务器端开辟一个固定的内存区(需要注意，固定仅指该用于缓存的内存区固定存在，不表示该内存区的长度固定，在下文中，内存区将可以视同为缓存数据)用来缓存数据，该用作缓存的内存区例如由前文的网元数据缓存单元102管理。

在步骤S102，例如由前文的网元数据接收单元101接收前台网元上报的数据，这些数据称为原始数据，原始数据将被顺序的存放到固定的内存区x。

在步骤S103，当内存区长度x(即内存区中缓存数据的长度)达到设置的压缩阈值下限a，则需要对数据压缩，流程进入到步骤S104；否则，则回到步骤S102，继续接收数据。

在步骤S104，压缩多条消息构成的内存区x为内存区y，即将数据长度x的缓存数据压缩成数据长度y的数据，需要注意的是，缓存数据x可能是由多条消息构成的(参见图3)。另需注意的是，尽管流程进入到步骤S104的数据压缩，这并不表示步骤S102的数据接收、缓存过程的停止，除非服务器端主动限制，不再从前台网元接收数据，否则，数据接收缓存过程将可以持续进行，即使在数据压缩过程中。因而，在本发明中，用“动态接收”的概念来表示这种持续接收的状态。

在步骤S105，压缩后的内存区y与其相应的各条消息的自描述信息队列(即图3中的消息参数列表)形成为DataPackage对象，DataPackage对象加入发送队列等待发送。

图4左侧所描述的未定时检查的数据压缩处理方式，在压缩效率上得到了提升，从而即使在低带宽情况下，也可以保证数据上报到客户端的及时性。然而，在某些情况下，这样的处理方式可能不太适宜。例如，若前台上报了1条100字节的消息后，1分钟内没有新的上报消息的情况下，由于100字节远远小于最小压缩单位，服务器将很有可能一直等待后续消息累计到压缩阈值下限，才将数据发送到客户端，从而可能导致前台的上报消息到客户端的时间会推迟比较长的时间，影响用户对业务状态的判断。

因此，在本发明的另一种实施例中，采用了定时检查方式来解决上述上报消息较少而引起的发送延迟问题。即对内存区进行定时监控，每到定时时间，服务器检查缓存数据是否超过压缩阈值下限，如是，则对其进行压缩后送入发送队列；否则，不再等待缓存的数据长度累积到压缩阈值下限，而是直接将缓存的数据送入到发送队列。

本发明的定时检查方式的又一种实施例如图4的右侧所示，在图示的方式中，不仅增加了定时监控，还增加了流量控制处理。

流程控制处理的整体构思是：设置流量控制阈值，由服务器确定前N秒的平均数据传输流量是否超过所述流量控制阈值，如是，则将服务器发送上报数据到客户端的过程进行休眠。这将可以避免流量过大而发生传输堵塞。在下面的具体示例中，流量控制对入口流量和出口流量都进行了控制，并结合定时监控而形成为一种精细的流程控制处理流程。

在步骤S201，定时时间设置为1秒，流程等待下1秒定时时间到。由于设定了流量控制，需要参照前几秒的定时时间监控结果，因此这里用下1秒定时表明非首次定时检查。

在步骤S202，计算前5秒平均入口流量flux。(入口指压缩通道cp入口，入口流量即服务器向客户端的发送流量)

在步骤S203，检查内存区使用的大小xSize。

在步骤S204，比较xSize是否大于512Byte。512Byte即压缩阈值下限a，为本例中所采用的数值，但不限定于此。当大于512Byte，流程将进入步骤S208，否则，进入步骤S205。

在步骤S205，判断平均入口流量flux是否大于1MByte/s，1MByte/s为本例中设定的入口流量控制阈值，但不限定仅取该值。当大于1MByte/s，流程进入步骤S207，否则，流程进入步骤S206。

在步骤S206，平均入口流量flux没有超过设定的入口流量控制阈值，则将未压缩的内存区x与相应的各条消息的自描述信息队列形成为DataPackage对象，将DataPackage对象加入到发送队列。

在步骤S207，检查客户端的5秒(本例的设定值，不限于此)平均出口流量(出口指压缩通道cp出口，出口流量即客户端从服务器的接收流量)是否超过设置的出口流量控制阈值(出口流量控制阈值就是用户设置界面中设置的，可参见图6中的后台消息流量限制，用户目前有256k，512k，1024k，2048k共4个选择)，若超过，则将消息入口流程，即服务器向客户端发送数据的流程进行休眠，此时，服务器对于前台网元的上报，设定为每秒处理1条消息；如果没有超过，则休眠的消息入口流程恢复，服务器和客户端之间的数据传输通道开始正常工作。在结束了出口流量控制阈值的判断处理后，流程回到步骤S201开始下一次定时的等待。

在步骤S208，此时，xSize＞512Byte，则将由多条消息构成的内存区x压缩成内存区y。

在步骤S209，将压缩的内存区y与相应的各条消息的自描述信息队列形成为DataPackage对象，将DataPackage对象加入到发送队列。之后，流程进入步骤207，进行出口流量控制处理。

系统对CP进行每秒1次的定时监控，当1秒扫描时间到时，若当前字节数大于最小压缩单位就不必检查流量，压缩后发送；若当前字节数小于最小压缩单位，而平均入口流量flux大于1MByte/s，待下1秒来处理(原因是客户端分发、解析、显示需要时间，之前发送的数据可能都没有显示完，没有必要发送这么小的消息到客户端了，等下1秒)；否则若平均入口流量flux不大于1MByte/s，且当前字节数小于最小压缩单位就不压缩直接发送。

压缩阈值下限可以根据实际需要进行调整，但在工程实施中建议最小值为4K，此外，还可以设置压缩阈值上限，例如，在本发明的一个实施例中，对于压缩数据块大小设置有最大64K的上限要求，这样可避免数据一直在压缩，却没有及时发送到客户端。

根据本发明的另一方面，考虑客户端为多个的情况，在这种情况下，为保证各个客户端获得上报数据的及时性，本发明采用数据传输通道绑定方式。如图5所示，服务器支持连接多个客户端，服务器与每个客户端通过各自的数据传输通道相连，服务器接收并分发前台网元的上报数据到各个数据传输通道。在本发明中，将数据传输通道称为CP(CompressPipeline，压缩通道)。通过CPI端口绑定模块，每个数据传输通道CP都被绑定到一个客户端。

通过压缩通道CP的绑定，连接的客户端将获得获取上报数据的均等机会。但由于数据传输通道的数量增加，将带来服务器消息流量的增加，加重服务器的处理负荷。因而，在本发明的实施例中，服务器对数据传输通道数量进行了限制，即服务器对客户端限制有最大同时连接数，例如可以设置为同一时刻最多连接5个客户端。已经登陆服务器的客户端可以在发起任务时，主动发起CPI绑定，当该客户端的任务异常结束或人为停止，客户端可以主动发起CPI绑定解除；同一个客户端的其他任务发起时可以不必再重复进行CPI绑定。通过CPI绑定与解绑定，实现了有限的服务器资源的动态分配。当客户端的数量超过5个，未连接的客户端将需要等待某个连接的客户端解除对某一数据传输通道的绑定，则该数据传输通道空闲，由未连接的客户端进行争用。数据传输通道的争用将遵循先来先用的抢占原则，保证了系统资源的可用性。

本发明中，CP预先被规划好并静态分配，随系统启动而创建，长驻内存。通过并行的静态分配的多个压缩通道，可以保证各个已绑定CPI的客户端的数据上报的机会均等，以及消息的定向发送。消息的定向发送，可以避免消息混发导致的无效带宽占用。CP仅仅存在2态：工作态与空闲态。空闲态时，CP处于休眠态，不占用系统资源；工作态时，CP才会占用CPU与内存资源。由于CP长期处于伺服状态，只要客户端执行绑定，CP立即可用，并且有效保证了多客户端的数据上报处理的机会均等。

CP之所以需要静态分配，是因为有些资源(例如内存等)动态申请很方便，但是有些资源动态申请就不太方便，例如JMS消息主题、IP地址、端口号、数据库连接等，这些资源都需要规划，需要物理设施，压缩通道的静态分配让用户可以根据实际环境来分配CP个数、分配CP依赖的资源，例如JMS消息主题等，由于这部分在框架中实现，CP对应用是透明的，故建立在本发明提供的通讯支撑上的网络应用，可以在实现上做到完全与通讯实现无关，减少了模块间的耦合，提高了可维护性。

本发明中的压缩和解压缩做到了算法和业务流程分离，用户也可以根据需要直接替换算法。因为JDK中的ZIP包压缩算法基于经典的Hufman压缩算法，压缩率和耗费资源上比较平衡，本发明推荐使用GZIP的二进制数组的输入输出流方式压缩和解压缩。

经过实验，本发明可以成功运用于跟踪管理新框架中，在CS、PS、IMS、HLR、HLRe、HA等项目(这些项目分别属于WCDMA和CDMA)的跟踪类网管产品(信令跟踪、流程跟踪、失败观察、业务观察)中的试用都获得很好的效果。

下面将以一个典型的信令跟踪任务来对本发明做进一步的说明。

参见图6，对于本例中的客户压缩通道参数配置，用户可以设置本客户端最大消息流量(flux)，范围为：256KB/S、512KB/S、1024KB/S、2048KB/S；同时用户也可以配置最大压缩数据块(compressBlock)，范围为：不压缩、4KB、8KB、16KB、32KB。为满足不同用户环境的不同要求，在用户使用功能前，可以根据实际情况来限制消息压缩的compressBlock与flux。例如在带宽受限制的情况下可以采用最大数据块压缩方式和最小发送流量，就是compressBlock＝32k，flux＝256k；带宽足够的情况下可以采用最小数据块压缩方式和最大发送流量，就是compressBlock＝不压缩，flux＝2048k，让系统在最大流量和不压缩方式下高速发送和处理数据。通过图6提供的设置界面，不同用户可以根据实际网络带宽情况灵活设置，达到连接到同一个服务器上的不同带宽的用户能各得其所(高带宽用户可以充分利用带宽在第一时间看到最新上报数据，低带宽用户可以在该用户能接受的情况下最大限度的得到相对及时的数据)。

如图7所示，客户端的信令跟踪任务创建后，在任务启动前，先注册到服务器并同时进行CPI绑定，当前面操作没有异常时，启动跟踪任务。收到前台返回的任务激活应答，客户端就开始启用已经绑定的CP，等待前台上报消息通过服务端与客户端间的CP上报到客户端的数据表格中。在客户端，跟踪模块客户端负责发出信令跟踪任务。在前台，作为跟踪目标的前台网元，通过业务子系统对客户端的信令跟踪任务进行处理，并通过跟踪Agent将数据上报到网元维护操作板，网元维护操作板包括平台信令跟踪Manager，跟踪Agent以及跟踪Manager，其收集各个跟踪目标的上报数据，并发送到网管的服务器端，服务器端的跟踪服务器端(网元数据接收单元)接收到上报数据后，进行数据消息压缩发送管理，对缓存数据判断是否需要压缩，将需要压缩的缓存数据送入到数据压缩器，由数据批量发送单元发送到各个绑定的客户端。网管客户端的数据接收缓存单元接收并缓存服务器端发送来的数据，对数据进行批量解压、数据重组。

对于网管的服务器端，当前台对应客户端的信令跟踪任务有数据上报时，服务器端收到前台的信令跟踪任务的上报数据，先将前台上报消息的数据体及其自描述信息(任务号、消息在内存区的起始地址、消息长度)缓存，到了满足发送条件时，将多条消息构成的整个内存区一起压缩，并将压缩后的数据连同其消息参数列表一起作为一个对象DataPackage，将该DataPackage对象送入发送队列。由于全部的单次发送的批量消息无论是否压缩，均统一为同一个DataPackage类的对象，保证了处理上的一致性，使得可以在同一条通信链路上同时传输压缩和未压缩的数据。

服务端向客户端发送消息时统计该客户端的消息流量(即每秒的消息字节数)，如前所示，用户可以设置本客户端最大消息流量。若超过本客户端最大消息流量限制，可以将消息处理线程休眠到1秒间隔结束，需要注意的是本客户端最大消息流量是最终发送的消息字节数的统计，如果数据压缩了会小于实际的大小。

当客户端的消息接收流量的5秒内平均值大于设置值(出口流量控制阈值)，系统会一直休眠，直到流量正常。休眠期若有上报，服务器端每秒只处理1条上报消息，以避免客户端用户以为跟踪停止，同时也能保证数据的及时更新。

客户端在收到CP发送过来的数据消息后，以DataPackage类来解析，根据压缩标志来决定是否需要对对象中的码流进行解压。逐个读取对象的消息列表中的消息参数，根据消息数据的起始位置和长度，从解压后的码流(若未压缩则直接对应对象中的码流)中得到数据体，这样就合并生成了每个完整的数据消息，然后再根据数据消息对应的任务号，转发给消息的订阅者：数据消息对应的任务表格，任务表格收到上报信息，则进行解码和界面呈现。

需要注意的是，本发明中压缩通道有2次批量封装与解封装的处理，一个是服务端的上报数据根据前述的数据压缩策略，被封装到一个DataPackage对象中；另一个是服务端的多个DataPackage对象，根据发送情况被序列化，即送入到发送队列。客户端的解封，实际上也包括这样两个过程，一个是客户端从接收到的字节序列中反序列化出多个DataPackage对象，另一个是客户端从DataPackage对象解封出多条业务消息。通过2次批量封装，达到最大化的带宽节省，同时2次不同的封装策略，也体现了物理层和业务层的不同封装处理。

图7所示的实例主要是列举本发明在J2EE架构上实施的核心实现模块，通过这样的系统架构，解决了低带宽大量数据上报情况下的数据传输的及时性，以及多客户端的机会均等。

目前，AGENT任务号AGENT_SESSIONID是在前后台之间传递的，是唯一标识一个任务的DWORD类型数值，其高16位对应任务号，低16位对应客户端的CLIENT_F_SESSIONID。通过解析AGENT任务号，可以得到对应的客户端信息，通过任务号，可以通过任务的基本信息知道其所属的功能，这样就可以通过AGENT任务号将消息发送到对应的客户端的对应功能的缓存区中。同时AGENT任务号可以直接定位对应的任务信息，从而实现对任务的控制。在本系统中，由于每条消息在其整个生命周期中都携带了任务号，而任务号中已经携带了客户端的信息，这样我们可以很容易的将消息分发到不同客户端的CP。

由于在本发明中，批量上报的1个上报数据中，可能压缩了多条消息，从而不能支持JMS消息的过滤属性，将导致若不做处理，在5个客户端都有跟踪的情况下，5个客户端的不同消息上报，各个客户端都会收到，这样对某1个客户端来说，本不应该由该客户端接收的其他4个客户端的消息，该客户端也能收到。给某1个客户端发送的消息，最后却变成了广播，容易导致消息风暴，影响系统功能，同时这些无效的消息占用了宝贵的网络带宽，在带宽受限制的环境下，会影响信令跟踪的使用。为解决这个问题，采用了一个客户端对应一个消息主题的做法来限制消息仅仅发往指定的客户端。

尽管网管可以支持10个以上的客户端，但是对应大量的数据上报的应用，太多的并发用户将加重服务器的处理负荷，本发明上述的静态分配CP的做法，既可以满足各个客户端都能跟踪的要求，又可以限制并发客户端数，也解决了资源不可随意动态分配的问题。用户只需遵循排队原则，若CP全部被占用，等待或通知其他人员停止使用该功能后，就可以使用其他人员已经释放的CP。

为此设置服务器端只支持5个客户端，在服务器端，可以配置5个数据上报消息主题，与1个后向消息主题(用于公共消息的广播等功能)。5个数据上报消息主题分别对应不同客户端，由客户端任务注册服务端任务管理器时，进行数据上报消息主题与客户端会话号的绑定。

服务端维护一个功能、数据上报消息主题与实际客户端(也就是客户端的SESSIONID)的对应关系。当客户端重新登录时已经注册的任务，应该失效，并清理数据上报消息主题与实际客户端的对应关系。这个清理应该在由客户注销与登录时都要清理一下。

上述对应关系应该在客户端当前没有启动跟踪任务时，该客户端的第1个跟踪来向服务端注册时，来绑定数据上报消息主题与该客户端，若绑定失败，可以由服务器端对该客户端进行失败提示，例如“由于已有5个客户端已经注册了跟踪任务，不再接受新的客户端的跟踪任务”。

在客户端注册某模块的第1个跟踪任务时，在服务端，进行数据上报消息主题绑定，并返回绑定的消息主题，跟踪任务在收到返回后，需要注册该模块的数据监听器与对应的后向消息监听器。在客户端停止某模块的最后一个跟踪任务时，则取消注册该模块的数据监听器与后向消息监听器，并通知服务器端取消消息主题绑定。(数据监听器与后向消息监听器即对应于前文的数据接收模块)

由于不同模块的后向消息与数据上报消息在不同消息主题上监听，分散到不同线程上来处理，能充分利用目前广泛使用的多核CPU的好处，从而提高系统的处理能力。

本发明也示例性的描述了一种网管系统中的数据传输系统，包括：

压缩阈值设置单元，位于服务器上，用于设置压缩阈值下限；

数据预处理单元，位于服务器上，用于动态接收前台网元的上报数据并缓存所述上报数据，当缓存的所述上报数据长度超过压缩阈值下限，对缓存的所述上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；

数据发送单元，位于服务器上，用于将所述发送队列中的上报数据发送到客户端。

上面的描述，是从模块功能的另一角度对系统的描述，其虽然与前文中图2所述的原理框架略有差异，但从整个数据传输的整体实现上并无实质区别，其表明，在以软件或硬件方式来实现本发明时，具体的功能模块设置是相当灵活的，而不必拘泥于本文所揭示的示例框架。

在采用定时监控方式时，系统可以包括定时监控单元，用于设置定时监控时间，并在定时监控时间到达时，确定缓存的所述上报数据长度是否超过所述压缩阈值下限，如是，对所述上报数据进行压缩处理后置入发送队列；否则，对所述上报数据不进行压缩处理，直接置入发送队列。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，但这只是为便于理解而举的实例，不应认为本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，可以做出各种可能的等同改变或替换，这些改变或替换都应属于本发明的保护范围。

Claims (10)

1.一种网管系统中的数据传输方法，其特征在于，包括：

A、服务器设置压缩阈值下限；

B、服务器动态接收前台网元的上报数据并缓存所述上报数据，当缓存的一批上报数据长度超过所述压缩阈值下限，对缓存的所述一批上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；

C、服务器将所述发送队列中的上报数据发送到客户端。

2.如权利要求1所述的方法，其特征在于，还包括：

服务器设置定时监控；

当到达定时监控时间，服务器确定缓存的所述上报数据长度是否超过所述压缩阈值下限，如是，对所述上报数据进行压缩处理后置入发送队列；否则，对所述上报数据不进行压缩处理，直接置入发送队列。

3.如权利要求2所述的方法，其特征在于，还包括：服务器设置流量控制阈值，服务器确定前N秒的平均数据传输流量是否超过所述流量控制阈值，如是，将服务器发送上报数据到客户端的过程进行休眠。

4.如权利要求2所述的方法，其特征在于，服务器设置压缩阈值上限，置入发送队列中的上报数据长度不超过压缩阈值上限。

5.如权利要求1所述的方法，其特征在于，所述服务器与至少一个客户端进行数据传输，服务器与各个客户端间的数据传输通道在服务器与客户端数据传输期间被绑定。

6.如权利要求5所述的方法，其特征在于，所述数据传输通道的数量为固定值，当客户端数量超过所述数据传输通道的数量时，客户端对所述数据传输通道的争用遵循先来先占原则。

7.如权利要求6所述的方法，其特征在于，不同的数据传输通道用不同的消息主题进行标记。

8.一种网管系统中的数据传输系统，其特征在于，包括：

压缩阈值设置单元，位于服务器上，用于设置压缩阈值下限；

数据预处理单元，位于服务器上，用于动态接收前台网元的上报数据并缓存所述上报数据，当缓存的一批上报数据长度超过压缩阈值下限，对缓存的所述一批上报数据进行压缩处理，将该经压缩处理的上报数据置入发送队列；

数据发送单元，位于服务器上，用于将所述发送队列中的上报数据发送到客户端。

9.如权利要求8所述的系统，其特征在于，所述系统还包括：

定时监控单元，用于设置定时监控时间，并在定时监控时间到达时，确定缓存的所述上报数据长度是否超过所述压缩阈值下限，如是，对所述上报数据进行压缩处理后置入发送队列；否则，对所述上报数据不进行压缩处理，直接置入发送队列。

10.如权利要求8所述的系统，其特征在于，还包括数据传输通道配置模块，用于为不同客户端各自配置数据传输通道并将其与客户端绑定。

Images