CN1466311A - 基于客户、服务器模式的用户请求报文的发送方法 - Google Patents

Abstract

本发明公开了一种基于客户、服务器模式的用户请求报文的发送方法，该方法设置存放已经发送给服务器正在等待响应的请求报文的一级缓冲池，以及存放等待向一级缓冲池发送的请求报文的二极缓冲池，当客户端生成请求报文时，如果一级缓冲池有空闲节点，则向服务器发送该报文并将该报文存储到一级缓冲池中报文发送标识对应的节点，否则将该请求报文存入二级缓冲池；当一级缓冲池中有请求报文发送完成后，从二级缓冲池中按序读出一个请求报文发送，并将该报文存储到一级缓冲池中的空闲节点中；采用上述方案，能够解决报文ID资源不足的问题，便于对客户端发送报文强度的控制，以适应不同处理能力的服务器和对大量用户进行管理的要求。

Description

基于客户、服务器模式的用户请求报文的发送方法

技术领域

本发明涉及网络系统中基于客户、服务器(Client/server)模式的报文发送方法。

背景技术

在客户端/服务器(Client/Server)的网络结构体系中，当客户端向服务器端发起类似认证和计费的请求报文时，服务器对该请求报文进行响应，请求报文和响应报文的匹配依赖于报文的标识(ID)，由于受采用客户端/服务器结构的协议ID长度的限制，使得客户端向服务器同时发送报文的数量受到限制。以主要用于用户认证授权和计费的远程用户拨号认证协议(RADIUS协议)为例，RADIUS的客户端程序通常运行于提供数据服务的设备上，RADIUS服务器通常运行于工作站上，其任务是接收客户端发来的用户连接请求，验证、计费并向客户端提供服务所需要的配置信息。客户端的任务是将用户的信息发送到指定的RADIUS服务器，RADIUS服务器根据数据库中的数据对用户进行认证授权计费服务，并给予客户端响应.客户端然后按照服务器的响应信息进行处理.由于RADIUS的报文ID只有一个字节长，造成客户端同时向服务器发送请求报文的数目不能超过256个，当发送请求报文的用户数目大于256个时，必然使得有些报文无法得到ID，这样在客户端管理的用户较多时，可能造成发送报文的丢失或产生较大的延迟，这对管理大量工作在客户端/服务器模式的用户极为不利。

发明内容

本发明的目的在于提供一种有利于对数量较多的用户进行管理的基于客户、服务器模式的用户请求报文的发送方法，使用该方法可以根据服务器处理能力动态调节用户请求报文的发送密度，防止服务器受到冲击。

为达到上述目的，本发明提供的基于客户、服务器模式的用户请求报文的发送方法，包括：

a.设置存放已经发送给服务器正在等待响应的请求报文的一级缓冲池，以及存放等待向一级缓冲池发送的请求报文的二极缓冲池，所述一级缓冲池用于存放请求报文的节点数小于或等于报文管理协议规定的用于标识请求报文的最大值；

b.当客户端生成请求报文时，如果一级缓冲池有空闲节点，则该请求报文申请得到报文发送标识，同时向服务器发送该报文并将该报文存储到一级缓冲池中报文发送标识对应的节点，否则将该请求报文存入二级缓冲池；

c.当一级缓冲池中有请求报文发送完成后，释放该报文所占的节点及报文发送标识，同时从二级缓冲池中按序读出一个请求报文利用上述释放的报文发送标识发送该报文，并将该报文存储到一级缓冲池中上述释放的节点中。

所述一级缓冲池采用数组结构，所述二级缓冲池采用双向链表结构。

所述一级缓冲池的每个节点均设置有用于定时重发存储在该节点的请求报文的定时器。

步骤c还包括判断一级缓冲池中是否有请求报文发送完成，该判断通过判断在指定的时间内是否收到该报文的正确响应或者判断该报文的重发次数是否超过指定的次数实现。

由于本发明设置二级缓冲池，当客户端生成请求报文时，如果一级缓冲池有空闲，则该请求报文申请得到报文发送标识立即向服务器发送并将该报文存储到一级缓冲池中报文发送标识对应的节点，否则将该请求报文存入二级缓冲池；当一级缓冲池中有请求报文发送完成后，从二级缓冲池中读出请求报文发送，并将该报文存储到一级缓冲池中；这样，可以从容地实现对请求报文的管理，解决报文ID资源不足的问题，从而使得对使用类似RADIUS协议的大容量，高密度设备提供认证授权计费服务时仍然适用，不会造成发送报文的丢失或产生较大的延迟，同时可以通过动态的配置，实现对客户端发送报文强度的控制，适应不同处理能力的服务器要求。

附图说明

图1是本发明所述方法实施例的客户端报文发送流程图；

图2是本发明所述方法实施例的缓冲池报文发送流程图；

图3是本发明采用的二级缓冲池示意图；

图4是图2的二级缓冲池中的报文跃迁示意图。

具体实施方式

本发明所述方法采用报文发送缓冲池实现，在具体实现时可以采用两个相互独立的过程分别实现客户端生成报文的发送和缓冲池报文的发送。

下面结合附图以采用RADIUS协议的客户端和服务器为例对本发明作进一步详细的描述。

本发明在具体实施时，首先设置存放已经发送给服务器正在等待响应的请求报文的一级缓冲池，以及存放等待向一级缓冲池发送的请求报文的二极缓冲池，所述一级缓冲池采用数组结构，所述二级缓冲池采用双向链表结构。由于RADIUS协议规定，计费请求报文每次重发，必须更换报文的ID，所以，一级缓冲池用于存放请求报文的节点数小于或等于报文管理协议规定的用于标识请求报文的最大值，本例中一级缓冲池的节点数目最大为255，这样可以确保，每一个一级缓冲池的报文都能够申请到报文的ID，当然所述一级缓冲池的节点数还可以根据服务器的数据处理能力，在小于255的范围内设置.同时，一级缓冲池中的每个节点均设有相应的定时器，用于在没有收到RADIUS服务器的响应的时候定时重发该节点的报文。

由于一级缓冲池中的各个节点的报文发送是各自独立的，每一个节点都具备相应的定时器来控制该节点的报文的重发操作。因而，一级缓冲池的大小也直接同向服务器发送的RADIUS报文的强度大小相关。在服务器处理能力强大的时候，可以配置大的一级缓冲池，使得更多的报文能够得到同时发送，加快用户认证授权计费的响应时间；在服务器处理能力较弱时，我们可以减小一级缓冲池的大小，控制设备侧报文的强度，确保服务器能够从容应答。

所述二级缓冲池中的报文都没有报文的ID。处在这个缓冲池中的报文等待转移到一级缓冲池中，才能得到发送。二级缓冲池的大小可以根据实际情况而定义，同样可以动态的配置。本例采用的报文两级缓冲池的示意图参考图3。

图1是本发明所述方法实施例的客户端报文发送流程图。按照图1，当客户端在步骤11生成新的请求报文时，由统一入口进入，在步骤12判断一级缓冲池是否有空空闲节点，如果一级缓冲池有空闲节点，则在步骤13该请求报文申请得到报文发送ID，同时向RADIUS服务器发送该报文并将该报文存储到一级缓冲池中报文发送标识对应的节点，同时启动定时器，以便在配置的指定时间内仍然没有收到服务器对该报文的响应的时候，重新发送该报文。如果一级缓冲池没有空空闲节点，则在步骤14将该请求报文存入二级缓冲池的尾部，等待着跃迁到一级缓冲池中发送。

图2是本发明所述方法实施例的缓冲池报文发送流程图。按照图2，首先在步骤21判断一级缓冲池中是否有空闲节点，即判断一级缓冲池中是否有请求报文发送完成，该判断通过判断在指定的时间内是否收到该报文的正确响应或者判断该报文的重发次数是否超过指定的次数实现。当处于一级缓存池中有报文收到对应的正确响应报文或者该报文的重发次数超过限度时，则一级缓冲池处于该节点的报文需要被删除。即在步骤22删除该节点的报文的同时，释放该报文所占的节点及报文发送标识，同时从二级缓冲池中按序读出一个请求报文，即获得处于头部的报文，利用上述释放的报文发送标识发送该报文，并将该报文存储到一级缓冲池中上述释放的节点中，然后回到步骤21继续判断；如果在步骤21判断一级缓冲池中没有空闲节点，则要继续步骤21继续判断。上述过程参考图4。

在图3和图4中，为了方便数组中的节点和链表中的节点互相移动，对图3、4中的数组中的节点定义了与链表节点相同的数据结构。

二级缓冲池中的报文在加入一级缓冲池的同时也要申请报文的ID，这样，可以同时记录使用该ID的报文在一级缓冲池的位置，以在收到服务器的响应报文的时候，能够很容易的找到与之匹配的请求报文。

在本发明所述方法具体实施时，可以一定的变化，以使本发明具有更好的实施效果，例如在基于RADIUS协议的客户端/服务器模式中，对认证报文和计费报文分开处理，每种报文都拥有自己独立的报文二级缓冲池。由于这两种报文的性质不同，因此需要在上面描述的二级缓冲池进行略微的变化，分别处理：

(1)认证报文的处理：

对于认证报文，报文要求得到响应的时间上要求比较严格，因为用户可能无法容忍长时间得不到认证响应。

首先，在认证报文的一级缓存缓冲池的配置上，一般配置比较大的一级缓冲池，例如：80；这样，用户的认证报文立即加入到一级缓冲池中的机会增大，同时也缩小了滞留在二级缓冲池的时间。

其次，在报文的二级缓冲池的发送算法基础上，作一些改进。认证报文在一级缓冲池中定时发送，如果发送次数超过配置次数(例如3次)仍然没有收到响应，则认为认证失败。处于在二级缓冲池中的报文跃迁到报文一级缓冲池的时候，需要计算该报文滞留在二级缓冲池中的时间，将该时间折算为发送次数，如果折算出来的发送次数超过配置次数，则不再发送，认为认证失败；这样，就保证了认证报文的认证时间，满足了认证报文在及时性上的要求。

(2)计费报文的处理：

计费报文的要求同认证报文的要求不同，在实时性上要求不如认证报文严格，但在报文的安全性上要求更高，在服务器暂时出现故障的期间，计费报文不能轻易抛弃，不能因为收不到服务器的响应就抛弃计费报文。对应这些要求，进行如下处理：

首先，在认证报文的一级缓存缓冲池的配置上，一般配置比较小的一级缓冲池，例如：2；这样，用户的计费报文立即加入到一级缓冲池中的机会很小，计费报文产生后一般加入到二级缓冲池中，等待一级缓冲池中的报文得到响应后，才有机会得到发送；

其次，处于一级缓冲池中的计费报文，发送次数到达配置次数(例如3次)后仍然没有收到响应，并不抛弃，而是将其从一级缓冲池中摘除，放置到二级缓冲池的尾部，等待再次跃迁到一级缓冲池的时候发送，如此反复3次后删除。这样，如果在服务器能够正常响应的时候，计费报文同样可以很快的发送。在Server出现故障的时候，由于一级缓冲池很小，大量的计费报文存放在二级缓冲池中，形成很长的链表。一个计费报文需要经历三次从链表的尾部渐渐的移到链表的头部，才能得到发送机会。这样，大大的增加了计费报文在设备内的滞留时间，提高了计费报文的安全性。

Claims (5)

1、一种基于客户、服务器模式的用户请求报文的发送方法，包括：

a.设置存放已经发送给服务器正在等待响应的请求报文的一级缓冲池，以及存放等待向一级缓冲池发送的请求报文的二极缓冲池，所述一级缓冲池用于存放请求报文的节点数小于或等于报文管理协议规定的用于标识请求报文的最大值；

b.当客户端生成请求报文时，如果一级缓冲池有空闲节点，则该请求报文申请得到报文发送标识，同时向服务器发送该报文并将该报文存储到一级缓冲池中报文发送标识对应的节点，否则将该请求报文存入二级缓冲池；

c.当一级缓冲池中有请求报文发送完成后，释放该报文所占的节点及报文发送标识，同时从二级缓冲池中按序读出一个请求报文利用上述释放的报文发送标识发送该报文，并将该报文存储到一级缓冲池中上述释放的节点中。

2、根据权利要求1所述的用户请求报文的发送方法，其特征在于：所述一级缓冲池采用数组结构，所述二级缓冲池采用双向链表结构。

3、根据权利要求2所述的用户请求报文的发送方法，其特征在于：所述一级缓冲池的每个节点均设置有用于定时重发存储在该节点的请求报文的定时器。

4、根据权利要求3所述的用户请求报文的发送方法，其特征在于：所述一级缓冲池的节点数根据服务器的数据处理能力设置。

5、根据权利要求4所述的用户请求报文的发送方法，其特征在于步骤c还包括判断一级缓冲池中是否有请求报文发送完成，该判断通过判断在指定的时间内是否收到该报文的正确响应或者判断该报文的重发次数是否超过指定的次数实现。