CN1822596A - 一种客户/服务器架构中的数据处理方法 - Google Patents

Abstract

本发明公开了一种客户/服务器架构中的数据处理方法，包括：a.客户端收集用户输入的数据，并将该数据分割成若干数据块；b.在所述客户端保存分割后的数据块并将数据块发送到服务器；c.服务器响应客户端请求，并将执行结果信息返回所述客户端；d.客户端根据收到的执行结果信息显示相关信息。利用本发明提供的方法，在不增加任何硬件的情况下，减少大数据量处理过程中设备的资源占用，并实时显示处理结果。本发明在嵌入式设备上的优点更为明显，具有占用资源少，功能简单、可靠、灵活的特点。同时以WEB方式处理的过程中具有允许用户交互的特点，网管界面极为友好，从而大大提高网管人员的工作效率，降低维护成本。

Description

一种客户/服务器架构中的数据处理方法

技术领域

本发明涉及计算机网络技术领域，具体涉及客户/服务器架构中的数据处理方法。

技术背景

随着Internet的商业化，其技术获得了迅猛发展，应用范围得到不断拓展。HTML页面与浏览器配合，以其友好的界面成为广大用户访问Internet的最主要、最常见方式。这种方式因其客户端通用、普遍，已应用在嵌入式设备例如交换机、路由器的管理中。

现有的嵌入式设备的管理***采用客户机/服务器(C/S：Client/Server)架构，支持标准的HTTP协议，提供WEB方式的管理，通过标准的IE浏览器能够对设备进行访问和控制，直观、方便地对设备进行管理，还可通过HTTP协议进行数据的远程传输实现提供远程升级功能。

与普通的Web服务器不同，交换机和路由器等网络设备的处理性能和所配置的内存，Flash都比较低，当处理大量的数据时需要耗费相当长的时间，导致客户端出现长时间没有响应的现象，对用户很不友好。另外在设备上使用循环分别配置每一个端口的多个属性，当出现错误时，停止后面的配置，把当前的错误提示给用户，不能清楚地告诉用户哪些端口配置成功那些端口配置失败；继续后面的配置，把当前的错误保存到内存中，因为配置项较多需要占用大量的内存，故将影响设备的其他性能。

因此，在设备的web网管***运行过程中，需要减轻设备的负担。目前比较常用的方法是数据库技术，可以支持大数据量的处理，和复杂的查询请求。该技术的主要特点如下：

支持数据的部分输出，对大数据量可以分页显示。浏览器发送的http请求到达服务器端后，服务器通过浏览器发送的请求输出指定数据中的一段内容，并且输出上一页和下一页的查询关键字。支持数据过滤。允许用户输入自定制的查询条件过滤数据。也可以与部分输出技术相结合，只获取需要的数据。服务器端使用数据库技术支持用户的查询操作，允许输出指定数据段的内容。

但是，在有些客户/服务器(C/S)架构的***中，如嵌入式设备的web网管***，采用的数据库技术存在以下缺点：

对硬件性能要求高，功能强大的数据库支持需要有高性能的硬件配置来处理复杂的请求和操作，嵌入式设备受CPU和内存的限制不易实现。

所需存储空间大，数据库的实现代码量庞大，需要较大的存储空间。设备上的存储介质(Flash)一般不超过64M，少的只有几M，不能满足需求。

要求数据相对稳定，当处理大数据量时需要有一定的时间。如果使用分页显示就需要数据相对稳定，否则上一页和下一页出现的数据不具有相关性，对于数据处理就没有什么实际意义，因为整体数据分别在读取两个页面的数据的时间点会差别很大，也就是说后一个页面中的数据很可能就不是用户所想要的数据。这对于设备中时刻在变化的路由和MAC地址等相关数据来说就不太适合。

为了提高数据库的性能，需要操作***的支持，比如环境变量和管道等，所述数据库技术需要利用操作***的高级功能，这在有些设备如嵌入式设备中不易实现。

发明内容

有鉴于此，本发明要解决的技术问题在于，提供一种客户/服务器架构中的数据处理方法。在不增加任何硬件的情况下解决大数据量处理过程中减少设备的资源占用，并实时显示处理结果。

为解决上述问题，本发明提供的一种客户/服务器架构中的数据处理方法，包括：

a.客户端收集用户输入的数据，并将该数据分割成若干数据块；

b.在所述客户端保存分割后的数据块并将数据块发送到服务器；

c.服务器响应客户端请求，并将执行结果信息返回所述客户端；

d.客户端根据收到的执行结果信息显示相关信息。

步骤b中，分割数据块时，平衡分割后的数据块的大小和开销，以使所述分割后的数据块在服务器上运行时在预定时间内得到响应。

步骤b包括：

将分割后的数据块保存到一个队列中，由队列发送模块按顺序把队列中的数据块发送到服务器。

客户端每发送一个数据块，在服务器返回执行结果后再进行后续操作。

在步骤c中，所述执行结果信息包括反馈信息及描述信息；

当客户端发送的请求在服务器上执行成功时，服务器端返回执行成功的反馈信息；

当客户端发送的请求在服务器上执行失败时，服务器端返回执行失败的反馈信息以及包括失败原因的描述信息。

当客户端发送的请求在服务器上执行失败时，服务器端判断后续步骤不会成功时，通过反馈信息通知客户端终止后面的下发。

当客户端发送的请求在服务器上执行失败时，服务器端返回执行失败，但需要用户确认是否终止后续数据块发送的反馈信息以及包括失败原因在内的描述信息，用户根据所述失败原因，决定是否继续发送后续的数据块。

所述服务器为具有Http服务器功能的嵌入式设备。

所述客户端界面中显示的内容包括进度条显示、停止按钮、用户确认对话框。

在客户的服务器交互过程中，包括客户端响应用户输入的步骤。

在现有的Web应用中，同一处理过能内用户无法与服务器交互，也就是说，在用户提交之后到服务器完成的过程中用户无法参与。本发明中可以允许用户提交后在服务器运行的过程中参与交互，可以暂停或停止后面的处理，并且在服务器执行过程中如果出现错误，用户还可以决定是否继续后面的设置。

利用本发明提供的客户/服务器架构中的数据处理方法。当以Web方式访问设备进行大数据量的处理时，将大数据分解为小数据块，具有嵌入式Http服务器的设备及时响应并反馈相关信息给客户端。在不增加任何硬件的情况下，减少大数据量处理过程中设备的资源占用，并实时显示处理结果。避免了设备长期运行同一业务时过多的占用CPU资源从而影响其它业务的运行，并且避免了设备在处理大数据量时客户端长时间没有响应，没有任何信息显示，出现假死的现象。

本发明应用在嵌入式设备上优点更为明显，具有占用资源少，功能简单、可靠、灵活的特点。同时以WEB方式处理的过程中具有允许用户交互的特点，网管界面极为友好，用户不用再输入繁琐的命令和脚本就可以实现设备上的批量参数配置，并以进度条方式显示当前的进度，使网管人员随时了解当前的配置进度和每一条命令的配置结果。从而可大大提高网管人员的工作效率，降低维护成本。

附图说明

图1为本发明的方法的运行***构成框图；

图2为根据本发明实施例的客户端界面图；

图3为根据本发明实施例的用户操作界面图；

图4为根据本发明实施例的方法流程图；

图5为根据本发明第一实施例的用户操作界面图；

图6为根据本发明第二实施例的用户操作界面图。

具体实施方式

为了进一步说明本发明的原理，下面结合附图来描述本发明的具体实现。

图1为本发明的方法的运行***构成框图。如图1所示，本发明的方法在实施时包括客户端和服务器端两部分的工作。本发明中所述服务器包括具有Http服务器功能的嵌入式设备。客户端包括信息收集模块、队列发送模块、用户交互模块和信息显示模块。

图4为根据本发明实施例的方法流程图。参照图4，首先，从客户端发送HTTP请求。用户从WEB页面中输入大量的数据后，***即开始运行。信息收集模块收集用户输入的数据，对输入数据规划后，将数据分割成若干数据块。分割原则是分割后的数据块在服务器端，如具有http服务器功能的嵌入式设备上，运行时不影响设备上的其它业务并且在用户预期的时间内得到响应，即数据块的大小要适当。数据块过小会增大数据块的数量，从而增加各数据块的分块传输和处理时的切换开销，而数据块过大，其极限状态就是只有一个数据块，又影响到其它业务。例如，假定共有速率、双工状态和端口类型3个属性，52个端口，如果按照最小数据块划分，可以分成52*3＝156个数据块，其结果是提示信息最明确，但效率最低，考虑到数据块不是很多，因此这样划分也是可以接受的。若现在需要对500个端口同时做10个属性的配置。如果还按照上面的方法划分，花费的时间就会很长，用户是无法接受的。因此，可以把20个端口和一个属性划分为一个数据块，额外开销就会大大减少，但提示信息就不会很到位，并且占用设备的资源也会增加。因此要根据具体情况，使得分割后的数据块的大小和额外的开销尽量平衡，以提高整体效率。

在客户端，分割后的数据块被保存到一个队列中，由队列发送模块自动按顺序把队列中的数据块发送到服务器。由于单个的小数据块不会占用设备的太多资源，并且执行的时间也较短，用户可以很快的得到执行结果，另外，也可以根据情况随时终止后面的发送，以适应用户的临时决策。

服务器响应客户端请求，并将执行结果信息返回所述客户端。服务器返回的结果包括反馈信息和描述两部分，通过反馈信息客户端可以知道服务器的执行结果。针对不同的反馈信息，客户端会做出不同的响应，客户端根据反馈信息确定下一步操作，客户端不对描述部分做任何处理。

当客户端发送的请求在服务器上执行成功时，或是服务器端程序认为执行的结果不重要或不必要知道时，服务器端返回执行成功的反馈信息。描述字符串可以是“OK”、“成功”、“正确”等确认信息。客户端在收到该反馈信息时会继续检查队列并进行下一个数据块的下发。

当客户端发送的请求在服务器上执行失败时，并且服务器端程序判断如果继续后面的下发也不会成功时，服务器端返回执行失败，终止后续数据块下发的反馈信息。描述部分内容设置为失败的原因，以方便用户知道为什么会失败。客户端在收到该反馈信息时会终止队列后面的所有数据块的下发，等同于用户点击了客户端的“关闭”按钮。

例如，批量创建访问控制列表(ACL：Access Control List)的规则(RULE)，由于一个设备中所支持的RULE是有限的，当创建一条RULE失败时，很可能是已经达到了最大条数，此时再继续后面的创建肯定也是失败，因此需要返回反馈信息。

当客户端发送的请求在服务器上执行失败，并且服务器端程序不能确认后面的下发请求是否会成功时，服务器端返回执行失败，用户确认是否终止后续数据块下发的反馈信息。描述字符串内容设置为本次发送失败的原因，以方便用户决定是否继续后面的发送。客户端在收到这个反馈信息时显示确认对话框，由用户选择继续下发还是终止队列后面的所有数据块的发送。

例如，批量删除MAC地址，由于每一个MAC地址的删除是相互独立的，当删除某一个MAC地址失败时，其失败原因可能是这条MAC已经被其它管理员删除了，这并不影响其它MAC地址的删除，此时再继续后面的删除很可能还会成功，因此需要返回反馈信息。

综上所述，在现有的Web应用中，同一处理过程内用户无法与服务器交互，也就是说，在用户提交数据之后到服务器完成的过程中用户无法参与。本发明中可以允许用户提交数据后在服务器运行的过程中参与交互，可以暂停或停止或继续后面的处理，并且在服务器执行过程中如果出现错误，用户还可以决定是否继续后面的设置。假如服务器在处理到第30个端口时出现故障，在现有技术中，其后面的执行只能由服务器决定。本发明中由用户决定是否继续后面的操作，即使不出现错误，用户也可停止第30个端口以后的配置。

客户端根据收到的执行结果信息显示相关信息。

信息显示模块创建客户端界面，根据收到的执行结果信息显示相关信息，并且在收到服务器程序返回执行结果后，对界面进行刷新。客户端界面中至少应包括进度条显示、停止按钮、用户确认对话框。实际应用时可以增加一些附加功能，以增加界面的友好性。图2为根据本发明实施例的客户端界面示意图，所示为一个带有跳过用户确认的客户端界面。

具体应用时可以通过修改颜色、布局、附加功能等以实现与当前格式的搭配与界面的友好。

客户端中与用户交互的操作，即对用户的输入及时的响应，包括点击暂停/继续、停止/关闭按钮和发生错误时用户的确认选择。图3为根据本发明实施例的用户交互操作界面示意图。

实施例1

下面以删除MAC地址为例说明本发明的实现。

现在设备上有5001条MAC地址，删除其中的5000条。下图只是一个Demo，假定其总数为5001。

如果使用一般的方法，就是一次将5000条全部提交到设备上，在设备上使用循环逐条删除。此时会占用设备大量的CPU，影响其他业务的正常运行。使用本发明可以避免这一缺点，参考下面的实现：

客户端：

选中5000条MAC地址，点击Remove按钮后执行下面的代码

var count=oMAutoList.GetSelCount();//oMAutoList为多列选择框对象

if(0==count)

{

    //选择框中没有被选中的行

    return false；

}

//本发明可以使用一个对象实现，通过下面的函数可以取道本发明的一个实例

var oSendMsg=GetQueue(window)；

oSendMsg.Reset("/wcn/mac/summary_detail");

//从多列选择框中获取所有选中的行，以实现数据分块

var arrSelRows=oMAutoList.GetSelectedRows();

for(var i=0;i＜count;i++)

{

    //在此例子中，每一行数据为一个数据块

    sURL=sAction+"&mac="+arrSelRows[i].getValue();

    oSendMsg.AddMsg(sURL,arrSelRows[i].GetText());

}

    //每次分出的数据块后及时保存。

//启动本发明的自动执行

oSendMsg.Start();

return false;}

服务器端：

获取客户端的数据后执行设备上的删除MAC动作。因为客户端的一个数据块只有一条MAC地址，因此服务器端处理起来又简单又不占用***资源。if(RemoveMac()==OK){

//删除成功，返回允许继续删除的反馈信息

return OutputResul t(“OK”,WCN_QA_NEXT);}else if(InternalError()){

//出现内部错误，返回强制终止的反馈信息，此时如果允许客户端继续后面的设置基本上还是不成功

return OutputResult(“Internal error.”,WCN_QA_STOP);}else{

//一般性的错误可以让用户去决定后面的操作。同时输出错误的原因

return OutputResult(GetErrorMsg(),WCN_QA_USER);}

客户端对三种反馈信息的处理是封装好的，对开发者是透明的。服务器端可以根据不同的情况输出到客户端不同的反馈信息。

本实施例的操作界面图如图5所示。

实施例2

以端口配置为例说明多端口多配置项时实施本发明的情况。在一台52口的交换机上对所有的端口同时配置端口速率、双工状态、流量控制、长帧转发和广播风暴时，使用本发明的做法如下：

客户端：

//本发明可以使用一个对象实现，通过下面的函数可实施本发明var oSendMsg=GetQueue(window);oSendMsg.Reset("/wcn/port/summary");

//按照一个端口一个配置项进行数据分块

//可能会占用客户端的CPU较多，但因为减少了设备上的负担，且客户端的PC

//的配置一般都比设备要高的多，所以不影响正常工作。var nPortCount=GetSelectedPortCount();var sAction="/wcn/port/setup";for(var i=0;i＜nPortCount;i++){

var sPortAction=sAction+"&port="+GetSelectedPort(i);

//分割端口速率数据块

sURL=sPortAction+"&speed="+getSpeedValue();

oSendMsg.AddMsg(sURL,"设置端口速率");

//分割双工状态数据块

sURL=sPortAction+"&duplex="+getDuplexValue();

oSendMsg.AddMsg(sURL,"设置双工状态");

//分割流量控制数据块

sURL=sPortAction+"&speed="+getSteamValue();

oSendMsg.AddMsg(sURL，"设置流量控制");

//分割长帧转发数据块

sURL=sPortAction+"&frm="+getFrameValue();

oSendMsg.AddMsg(sURL,"设置长帧转发");

//分割广播风暴数据块

sURL=sPortAction+"&bd="+getBroadValue();

oSendMsg.AddMsg(sURL,"设置广播风暴");}

//每次分出的数据块后及时保存。

//启动本发明的自动执行

oSendMsg.Start();

服务器端：

获取客户端的数据后执行设备上的设置端口动作。因为客户端的一个数据块只有一个端口和一个设置项，因此服务器端处理起来比较简单且占用***资源较少。

//取端口char*sPort=GetUrlParameter(“port”);if(NULL==sPort){

//取参数错误，返回强制终止的反馈信息，此时可能是非法用户进入。

return OutputResult(“Parameter error.”，WCN_QA_STOP);}if(是设置端口速率){

ulRetCode=SetPortSpeed();}else if(是设置双工状态){

ulRetCode=SetPortDuplex();}else if(是设置流量控制){

ulRetCode=SetPortStream();}else if(是设置长帧转发){

ulRetCode=SetPortFrame();}else if(是设置广播风暴){

ulRetCode=SetPortBroad();}else{

//数据错误，输出强制终止的反馈信息，此时可能是非法用户进入。

return OutputResult(“Parameter error.”,WCN_QA_STOP);}if(OK==ulRetCode){

//设置成功，输出允许继续配置的反馈信息

return OutputResult(“OK”,WCN_QA_NEXT);}if(InternalError()){

//出现内部错误，输出强制终止的反馈信息，此时如果允许客户端继续后面的设置还是不成功

return OutputResult(“Internal error.”,WCN_QA_STOP);}

//一般性的错误可以让用户去决定后面的操作。同时输出错误的原因

return OutputResult(GetErrorMsg()，WCN_QA_USER)。

本实施例的操作界面图如图6所示。

以上列举的是说明本发明的原理的示范性实例，本发明并不限于此。对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims (10)

1、一种客户/服务器架构中的数据处理方法，其特征在于，包括：

a.客户端收集用户输入的数据，并将该数据分割成若干数据块；

b.在所述客户端保存分割后的数据块并将数据块发送到服务器；

c.服务器响应客户端请求，并将执行结果信息返回所述客户端；

d.客户端根据收到的执行结果信息显示相关信息。

2、如权利要求1所述的客户/服务器架构中的数据处理方法，其特征在于，步骤b中，分割数据块时，平衡分割后的数据块的大小和开销，以使所述分割后的数据块在服务器上运行时在预定时间内得到响应。

3、如权利要求1所述的客户/服务器架构中的数据处理方法，其特征在于，步骤b包括：

将分割后的数据块保存到一个队列中，由队列发送模块按顺序把队列中的数据块发送到服务器。

4、如权利要求1至3中任一项所述的客户/服务器架构中的数据处理方法，其特征在于，客户端每发送一个数据块，在服务器返回执行结果后再进行后续操作。

5、如权利要求1所述的客户/服务器架构中的数据处理方法，其特征在于，在步骤c中，所述执行结果信息包括反馈信息及描述信息；

当客户端发送的请求在服务器上执行成功时，服务器端返回执行成功的反馈信息；

当客户端发送的请求在服务器上执行失败时，服务器端返回执行失败的反馈信息以及包括失败原因的描述信息。

6、如权利要求5所述的客户/服务器架构中的数据处理方法，其特征在于，当客户端发送的请求在服务器上执行失败时，服务器端判断后续步骤不会成功时，通过反馈信息通知客户端终止后面的下发。

7、如权利要求5所述的客户/服务器架构中的数据处理方法，其特征在于，当客户端发送的请求在服务器上执行失败时，服务器端返回执行失败，但需要用户确认是否终止后续数据块发送的反馈信息以及包括失败原因在内的描述信息，用户根据所述失败原因，决定是否继续发送后续的数据块。

8、如权利要求1至7中任一项所述的客户/服务器架构中的数据处理方法，其特征在于，所述服务器为具有Http服务器功能的嵌入式设备。

9、如权利要求1所述的客户/服务器架构中的数据处理方法，其特征在于，所述客户端界面中显示的内容包括进度条显示、停止按钮、用户确认对话框。

10、如权利要求1所述的客户/服务器架构中的数据处理方法，其特征在于，在客户的服务器交互过程中，包括客户端响应用户输入的步骤。

Images