Dynamic transaction-persistent server load balancing

The present disclosure describes a system for dynamic transaction-persistent server load balancing. The disclosed system receives a client request associated with a new transaction. In response to receiving the client request, the system dynamically infers relative capacities of a plurality of servers coupled to the device in a network. In particular, the system maintains a set of variables corresponding to the servers. Each variable indicates a number of outstanding requests transmitted from the device to a respective server. The system infers relative server capacities and transmission latencies between the device and the servers based on a comparison of current values of the variables. The system identifies and selects a server associated with high capacity or low transmission latency between the device and the server relative to one or more other servers, and transmits an outstanding request corresponding to the client request from the new transaction to the identified server.

BACKGROUND

The present disclosure relates to server load balancing in a wireless network, and in particular, one embodiment of the disclosure relates to dynamically load balancing transaction-persistent requests among a set of authentication servers.

Persistence (also known as “stickiness”), in the context of server load balancing, is preserved by transmitting requests associated with the same transaction to the same server for handling.

Conventionally, server load balancing follows a round robin (RR) approach. In a simple round robin, a load balancer transmits to each server transaction-persistent requests in a periodically repeated order. For example, assuming that a distributed system includes three authentication servers, such as, AS1, AS2, and AS3, the load balancer will always transmit transaction-persistent requests to the authentication servers according to the following order—AS1, AS2, AS3, AS1, AS2, AS3, AS1, . . . Thus, the simple round robin algorithm does not take into account capacities of the authentication servers.

A weighted round robin (WRR) is similar to the simple round robin, but assigns weights to the authentication servers based on their capacities. In the above example, assuming that the capacities of AS1, AS2, and AS3are4,2, and2, respectively, the load balancer will assign weights2,1,1to AS1, AS2, and AS3accordingly. Thus, with the weighted round robin, the load balancer will transmit transaction-persistent requests to the authentication servers according to the following order—AS1, AS1, AS2, AS3, AS1, AS1, AS2, . . . However, WRR requires knowledge of the server capacities. Moreover, both simple RR and WRR are static scheduling approaches that do not consider dynamic real-time transmission latency in a network.

DETAILED DESCRIPTION

In the following description, several specific details are presented to provide a thorough understanding. One skilled in the relevant art will recognize, however, that the concepts and techniques disclosed herein can be practiced without one or more of the specific details, or in combination with other components, etc. In other instances, well-known implementations or operations are not shown or described in details to avoid obscuring aspects of various examples disclosed herein. It should be understood that this disclosure covers all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as claimed.

Overview

The present disclosure supports dynamic transaction-persistent server load balancing based on the number of outstanding requests associated with each server in a server group. First, the disclosed system receives a client request associated with a new transaction. The system dynamically infers relative capacities of the servers in the group by comparing the numbers of outstanding requests. As an example, when server A has 3 outstanding requests and server B has 5 outstanding requests at a given time, the system can infer that server A has higher relative capacity than server B. Server A is inferred to have higher relative capacity than server B, because server A having fewer outstanding requests than server B suggests that, at the given time when the numbers of outstanding requests are compared, server A has relatively more processing power than server B to handle the next outstanding request regardless of the absolute capacity of each server. The system selects a server from the group of servers based on the inferred capacities of the servers, and transmits to the selected server a request corresponding to the received client request from the new transaction. Further, after the server is selected for the new transaction, all subsequent requests within the same transaction will also be transmitted to the selected server. Thus, the system supports transaction-persistent requests, because the load balancing decisions, e.g., the identification and the selection of a server in the server group to transmit requests, are made at the time when a new transaction is initiated by a client.

Specifically, embodiments of the present disclosure may include multiple authentication servers in a network that support Remote Authentication Dial-In User Service (RADIUS) protocol. The RADIUS servers authenticate users or devices before granting them access to the network, authorize the users or devices for network services, and account for usage of the authorized services. The authentication may comply with any network authentication protocol, such as Institute of Electrical and Electronics Engineers (IEEE) 802.1X protocol. An 802.1X authentication transaction typically involves three parties: a suppliant, an authenticator, and an authentication server. One or more access points or controllers in a wireless network, or switches in a wired network, which act as the authenticator in the 802.1X authentication transaction and communicate to the RADIUS servers as Network Access Server (NAS) clients, can perform the dynamic transaction-persistent server load balancing as described herein. Also, the RADIUS servers act the authentication server in the 802.1X transaction.

The outstanding requests for a given server include all previously transmitted requests to the server, as long as (1) the requests have not expired, and (2) no responses corresponding to the requests have been received from the server. It is important to note that a transaction, which an authentication client initiates, may include one or more requests and zero or more responses. Also, it is possible that, during certain time periods within a transaction, all previously transmitted requests to the server have either expired or already associated with the corresponding responses received from the server. In such cases, the number of outstanding requests for the server would be zero during these time periods, although the transaction has not been completed. Thus, depending on the configuration of the system, the number of outstanding requests may or may not be correlated to the number of the transactions.

Furthermore, if a server has a relatively large capacity, and/or if the transmission latency between a host network device and the server is relatively low, the number of outstanding requests corresponding to that server would tend to remain relatively low. Note that the relative capacities of the server and the transmission latencies are impacted by dynamic factors that change their values in real-time, such as, the server downtime, the network traffic between the host device and the server, etc. Thus, by comparing the number of outstanding requests associated with each server in the server group, the disclosed system can dynamically infer the relative capacities of the servers, and transmission latencies between a host network device and the servers in the group. The system can identify or select servers with relatively high capacity and low transmission latency to the host network device based on inferred information. The system then transmits requests from a new transaction to the selected server, thereby performing dynamic transaction-persistent load balancing.

Computing Environment

FIG. 1Ais a block diagram illustrating an example of a computing network environment according to one embodiment of the present disclosure.FIG. 1Aincludes network100, wireless local area network (WLAN)105, access point110, multiple clients120(including, for example, client122, client124, client126, etc.), and multiple authentication servers130(including, for example, authentication server132, authentication server134, authentication server136, etc.).

In the example illustrated inFIG. 1A, network100couples one or more access point110to a group of authentication servers130(e.g., authentication servers132-136). Although only one access point110is depicted inFIG. 1A, it should be noted that the disclosed system can include multiple access points that are either centrally located or distributed in network100. Network100may be any type of wired or wireless network. Access point110is coupled with clients120over WLAN105through any commonly supported wireless communication technology.

Access point110is a hardware unit that acts as a communication node by linking wireless mobile stations such as PCs to a wired backbone network. Access point110may generally broadcast a service set identifier (SSID). Access point110may connect client devices or users to other devices or users in the network, and may serve as a point of connection between WLAN and a wired network. Access point110may have one or more radios. The radios may be configured to support various wireless communication standards. In particular, the radios may include multiple antennas to support multiple-input and multiple-output (MIMO) technology as used in Institute of Electrical and Electronics Engineers (IEEE) 802.11n wireless networking standards (WiFi), Worldwide Interoperability for Microwave Access standards (WiMAX), 4th Generation cellular wireless standards (4G), 3rd Generation Partnership Project Long Term Evolution (3GPP LTE), and Evolved High-Speed Packet Access (HSPA+).

In one embodiment, access point110performs all media access control (MAC) processing functions, such as, terminating the wireless transmission data and management protocols, translating data between the wired and wireless portions of the network, maintaining statistical information regarding wireless clients and the radio environment, etc.

Clients120may be any computing device that includes a communication port, which is capable of WLAN communications. For example, clients120can be, but are not limited to, a smart mobile phone122, a laptop or tablet computing device124, a desktop or work station126, etc.

Authentication servers130are computing devices hosting applications that facilitate authentication of a client device or a user attempting to access a network. Such device can include, but is not limited to, a computer system, a switch, an access point, or a network access server. Authentication generally refers to the process of determining whether a client user or a client device is in fact who or what it declares itself to be. Authentication servers130may use authentication methods based on User Datagram Protocol (UDP), such as Remote Authentication Dial-In User Service (RADIUS), or authentication methods based on Transmission Control Protocol (TCP) such as Terminal Access Controller Access Control System Plus (TACACS+).

FIG. 1Bis a block diagram illustrating another variation of a computing network environment example.FIG. 1Bincludes network100, wireless local area network (WLAN)105, access point110, controller115, multiple clients120(including, for example, client122, client124, client126, etc.), and multiple authentication servers130(including, for example, authentication server132, authentication server134, authentication server136, etc.).

In the example illustrated inFIG. 1B, network100couples one or more controllers115to a group of authentication servers130(e.g., authentication servers132-136). Further, each controller115is coupled to one or more access points110. Although only one access point110and one controller115is depicted inFIG. 1B, it should be noted that the disclosed system can include multiple controllers115that are either centrally located or distributed in network100. Moreover, one controller115can be coupled to multiple access points110. Also, access points110are coupled with clients120over WLAN105through any commonly supported wireless communication technology.

In the embodiment described inFIG. 1B, access point110and controller115split the MAC processing. Access point110may handle a portion of MAC functions, such as, frame exchange handshake between a client user or device122,124, or126and access point110, transmission of beacon frames, buffering frames for power conservation of clients120, response to Probe Request frames from clients120, monitoring radio channels, layer2encryption, etc. Other MAC functions can be processed by controller115. For example, controller115may be configured to process user/device authentication, frame translation and bridging, association and de-association of clients120, etc.

It should be noted that the split of MAC functions described above is by way of example only. The disclosed system can be configured to split the MAC functions differently. Also, access point110and controller115may be integrated in a single device, or maybe physically separated and coupled through a wireless or wired network.

In the example illustrated inFIG. 10, network100couples one or more switches118to a group of authentication servers130(e.g., authentication servers132-136). Further, each switch118is coupled to one or more access points110. Although only one switch118is depicted inFIG. 10, it should be noted that the disclosed system can include multiple switches118that are either centrally located or distributed in network100. Moreover, switches118are coupled with clients120over a wired network, such as Ethernet113.

Switch118can be any network device that performs data forwarding tasks. Switch118may function as a bridge, or a router, and forward frames, packets, or other data units. Moreover, switch118can perform enhanced functions, such as device/user authentication, authorization, and/or accounting, access control list filtering, differentiated quality of service prioritization, link monitoring and failure detection, etc.

FIGS. 1A-1Care provided herein for illustration purposes only. Various embodiments of the disclosure may exist without departing from the spirit of the disclosure. For example, a device or a virtual device other than a controller or a switch may be deployed in the system to communicate with the access point(s) or to replace the access point(s). Such device or virtual device is coupled to the authentication servers through network and is capable of processing user and/or device authentication for the clients.

RADIUS Protocol

The disclosed system may be configured to use various authentication protocols. As described above, one of the commonly used authentication protocols is Remote Authentication Dial-In User Service (RADIUS).

Transactions between a user and a RADIUS server are authenticated through the use of a shared secret which is not transmitted over network. In addition, only encrypted user passwords are transmitted between the user and the RADIUS server. The RADIUS server can support a variety of methods to authenticate the user, including but not limited to, Point-to-Point Protocol Password Authentication Protocol (PPP PAP), Challenge-Handshake Authentication Protocol (CHAP), and other authentication mechanisms. In some embodiment, the authentication methods comply with IEEE 802.1X standard for port-based network access control (PNAC).

The RADIUS protocol uses UDP as its transport protocol. One RADIUS packet is encapsulated in the UDP data field.FIG. 2is a diagram illustrating an example data format of a RADIUS packet260and different types of the RADIUS packet. In this example, RADIUS packet260includes an 8-bit code field210(which identifies the type of the RADIUS packet), an 8-bit identifier field220(which facilitates matching between requests and responses), a 16-bit length field230(which indicates the length of the RADIUS packet), a 16-byte authenticator field240(which is used for authentications), and an attributes field250that can have a variable length.

RADIUS code210includes selected examples of values for the code field in RADIUS packet260. For example, a code value 1 indicates that RADIUS packet260is an Access-Request packet; a code value 2 indicates that RADIUS packet260is an Access-Accept packet; a code value 3 indicates that RADIUS packet260is an Access-Reject packet; a code value 4 indicates that RADIUS packet260is an Accounting-Request packet; a code value 5 indicates that RADIUS packet260is an Access-Response packet; a code value 11 indicates that RADIUS packet260is an Access-Challenge packet; etc.

FIG. 3illustrates an example of communication exchanges under the RADIUS protocol. Communication exchanges under the RADIUS protocol typically involve three parties: a suppliant (e.g., clients310), an authenticator (e.g. NAS client320), and an authentication server (e.g., authentication servers330). For example, a Network Access Server (NAS) can operate as a client (i.e., authenticator) of a RADIUS server (i.e., authentication server). NAS client320can be an access point, a controller, a switch, or any other device, which is coupled to authentication servers330through network, and which is capable of processing user and/or device authentication for clients310. NAS client320is responsible for passing user authentication information received from client310to designated RADIUS servers in a group of authentication servers330, and then acting on responses returned from the RADIUS servers. Authentication servers330are responsible for receiving requests from NAS clients, performing authentication, and returning configuration information for NAS client320to deliver service to clients310. Further, authentication servers330can act as a proxy server to other RADIUS servers or to other kinds of authentication servers.

During operations, a client, C1314, initiates an authentication transaction, and transmits client request322to NAS client320at time t0. Client request322is received by NAS client320at time t1. NAS client320subsequently creates a corresponding Access-Request packet, and transmits Access-Request packet332to RADIUS authentication server, AS1344, at time t2. Access-Request packet332may contain such attributes as user C1314's name, user C1314's password, NAS client320's identifier, and a NAS Port ID corresponding to a port via which user C1314accesses NAS client320. The password can be hidden using methods RSA-based algorithms.

In some embodiments, if no response is returned within an expiration period, request332is retransmitted to AS1344. If NAS client320still receives no response from AS1344after a number of retransmissions, it can also forward request332to another RADIUS server in a server group. Alternatively, alternative RADIUS servers in the server group can be selected for retransmissions in accordance to various load balancing algorithms.

At time t3, the RADIUS server, AS1344, receives request332. AS1344validates NAS client320that transmits request332. Any request from NAS client320for which the RADIUS server, AS1344, does not have a shared secret will be silently discarded. If NAS client320is valid, the RADIUS server, AS1344, consults a database including user information to find a user entry, the user name of which matches the user name of C1314as included in request332. The user entry in the database contains a list of requirements that must be met to allow access for user C1314. In some embodiments, the RADIUS server, AS1344, verifies user's password. In other embodiments, the RADIUS server verifies the NAS client ID and/or the NAS client's port ID to determine whether the user is allowed to access network resources.

In some embodiments, if a condition is not met, the RADIUS server, AS1344, sends an Access-Reject response indicating that the request from NAS client320is invalid. The RADIUS server may include a message in the Access-Reject response that may be displayed to the user. No other attributes are permitted in the Access-Reject response.

In other embodiments, as in the example depicted inFIG. 3, if all conditions are met and RADIUS server AS1344wishes to issue a challenge to which user C1314must respond, RADIUS server AS1344sends Access-Challenge334at time t4, which is received by NAS client320at time t5. In some embodiments, Access-Challenge334includes a message324(which is transmitted from NAS client320to user C1314at time t6, and which is received by user C1314at time t7) to be displayed to the user C1314prompting for a response326(which is transmitted from user C1314to NAS client320at time t8, and which is received by NAS client320at time t9) to the challenge.

NAS client320, upon receiving response326from user C1314, transmits Access-Request336at time t10, which is the same as original Access-Request332but has a new request identifier. In Access-Request336, the user password attribute is replaced by user C1314's response (encrypted) to RADIUS server AS1344's challenge. Access-Request336may further include a state attribute if presented in Access-Challenge334.

Access-Request336is received by RADIUS server AS1344at time t11. After that, RADIUS server AS1344can respond to this new Access-Request336with an Access-Accept, an Access-Reject, or another Access-Challenge. In the illustrated example, AS1314transmits, at time t12, Access-Accept338, which is received by NAS client320at time t13. If all conditions are met, the list of configuration information for the user C1314is placed into Access-Accept338. The configuration information includes the type of service, for example, Serial Line Internet Protocol (SLIP), Point-to-Point Protocol (PPP), login user, and all other necessary information to deliver the desired service. For SLIP and PPP, this may include IP address, subnet mask, MTU, desired compression, and desired packet filter identifiers, etc. For character mode users, this may include, for example, desired protocol and host.

In challenge/response authentication as illustrated by elements338and328inFIG. 3, the user usually is given an unpredictable number and challenged to encrypt it and to reply with the result. Authorized users are equipped with special devices, such as smart cards, or software that facilitate calculation of the correct response. Unauthorized users, lacking the appropriate devices or software and lacking knowledge of the secret key necessary to emulate such devices or software, can only guess at the response. Accordingly, Access-Challenge338typically contains a reply message328, including a challenge to be displayed to the user, such as a numeric value unlikely to be repeated. Preferably, this is obtained from an external server that knows what type of authenticator should be in the possession of the authorized user and can therefore choose a random or non-repeating pseudo-random number of an appropriate radix and length. The user then responds to the challenge with the user's client device or software, which calculates a response based on what the user enters. The client device then forwards the response to the RADIUS server via a new Access-Request. If the response matches the expected response, the RADIUS server replies with an Access-Accept (not shown). Otherwise, the RADIUS server replies with an Access-Reject.

Outstanding Requests

FIG. 4illustrates dynamic transaction-persistent server load balancing according to embodiments of the present disclosure. In this example, clients410communicate to a group of authentication servers430through NAS client420. NAS client420can be an access point, a controller, a switch, or any other device, which is coupled to authentication servers430through network, and which is capable of processing user and/or device authentication for clients410. For illustrative purposes only, the system depicted inFIG. 4comprises clients410, including three users and/or devices, namely C1414, C2416, and C3418, NAS client420, and two authentication servers430, including AS1434and AS2436. However, the disclosed system should not be restricted to the configuration and network setup as described inFIG. 4.

During operations, C1414transmits request441at time t0to NAS client420, which receives request441at time t1. NAS client420creates and transmits Access-Request451to AS1434at time t2, which is received by AS1434at time t3. In response, AS1434transmits Access-Challenge453at time t4to NAS client420. After receiving Access-Challenge453at time t5, NAS client420transmits challenge443to C1414at time t6. C1414receives challenge443at time t7, and responds with reply message445at time t8. Reply message445is received by NAS client420at time t9. Subsequently, NAS client420creates new Access-Request455including the reply, and transmits new Access-Request455to AS1434at time t10. AS1434receives Access-Request455at time t11. The sequence of communication exchanges between time t0and time t11described above in reference toFIG. 4is comparable to the sequence of communication exchanges between time t0and time t11as described inFIG. 3. Note that because Access-Request451and Access-Request455are in the same transaction, the disclosed load balancing system will not load balance them and will transmit both requests to the same authentication server, thereby making both requests transaction-persistent.

At time t12, a second user C2416transmits request461from a new transaction to NAS client420, which receives request461at time t13. In one embodiment, NAS client420considers load balancing requests from clients410, and determines authentication server allocation whenever it receives a first request from a new transaction, e.g., at or after time t13.

NAS client420makes the determination based on numbers of outstanding requests at AS1and AS2respectively. Because after time t10, AS1434has 1 previously transmitted request (i.e., Access-Request455) from NAS client420, and the request has neither expired nor been matched to a response received from AS1434, the number of outstanding request at AS1434before time t13is 1, and the number of outstanding request at AS2436is 0 (i.e., the initialized value). Thus, the system will determine to transmit all requests associated with the new transaction initialized by user C2416to AS2, including Access-Request471.

Access-Request471is transmitted from NAS client420at t14and received by AS2436at t15. Therefore, subsequent time t14and prior to time t17when Access-Accept457is received by NAS client420from AS1434(which transmits Access-Accept457at time t16), the number of outstanding request at AS1434is 1 (indicating Access-Request455), and the number of outstanding request at AS2436is also 1 (indicating Access-Request471). If a new client request from a new transaction is received during this time period, NAS client420can select either AS1434or AS2436to transmit requests associated with the new transaction in accordance with the load balancing algorithm described herein. However, because Access-Accept457is received by NAS client420at t17, and also because the identifier in Access-Accept457matches the identifier in Access-Request455, after NAS client420receives Access-Accept457at time t17, the number of outstanding requests at AS1434will be updated to 0. Therefore, after time t17, NAS client420will infer that AS1434has a higher relative server capacity than AS2436.

Next, user C3418transmits new request481from another new transaction at time t18to NAS client420. New request481is received by NAS client420at time t19. Note that, after time t17, AS1434is associated with 0 outstanding request and AS2436is associated with 1 outstanding request, namely Access-Request471. Therefore, the disclosed system will determine to transmit Access-Request491corresponding to the other new transaction from C3418to AS1434, because AS1434has fewer number of outstanding requests at the time of load balance determination.

As illustrated inFIG. 4, Access-Request491is transmitted by NAS client420at time t20, and received by AS1434at time t21. Also, after receiving Access-Accept457at time t17, NAS client420transmits corresponding response447to user C1414at t22. Response447is received by user C1414at time t23.

In this example, after AS2436verifies NAS client432's ID and/or the NAS client's port ID, as well as user name and password supplied by user C2416in request461, AS2436determines that one or more conditions in the authentication database are not met. As a result, AS1434sends Access-Reject473indicating that request471from NAS client420is invalid at time t24. NAS client420receives Access-Reject473at time t26, and transmits reply463to user C2416at t27. Reply463informing C2416of the rejection is received by C2416at time t28.

FIG. 5shows a summary of the number of outstanding requests at AS1540and the number of outstanding requests at AS2560at different time points520.FIG. 5further shows AS selection580based at least on the relative capacities of AS1and AS2, and transmission latencies between NAS clients and AS1and/or AS2at different time points.

In this embodiment, the variables indicating outstanding requests at authentication servers are initialized to zero. In this example, the variable for an authentication server increases when a new request is transmitted from a NAS client to the authentication server. The variable decreases when a previously transmitted request expires, or when a response, which is corresponding to a non-expired previously transmitted request, is received by the NAS client from the authentication server. However, in another embodiment, the variable for the authentication server decreases when a new request is transmitted from the NAS client to the authentication server. The variable increases when a previously transmitted request expires, or when a response, which is corresponding to a non-expired previously transmitted request, is received by the NAS client from the authentication server. Further, it should be noted that any methods capable of tracking incremental and/or decremental changes, or progressions and/or regressions, may be used for tracking purposes. The metrics may be, for example, numerical, alphabetical, or categorical.

It should be further noted that the relative server capacities and transmission latencies are dynamically inferred from the numbers of outstanding requests at different authentication servers in the server group. For example, during the time period between time t13and time t14, because the number of outstanding request at AS1540is 1, and the number of outstanding request at AS2560is 0, the disclosed system can infer that AS2has a higher capacity and lower transmission latency than AS1. Thus, the system will identify AS2as the authentication server for processing requests associated with the new transaction initiated by C2, and transmits the first request from the new transaction at time t14to AS2.

As another example, during time period between time t17and time t19, the number of outstanding request at AS1540is 0, and the number of outstanding request at AS2560is 1, the system therefore infers that AS1has a higher capacity and lower transmission latency than AS2. Accordingly, the system will select AS1for authentication of requests associated with the new transaction initiated by C3, and transmits the first request from the new transaction at time t20to AS1.

Further, it should be noted that, the comparison of the number of outstanding requests may be based on concrete values, statistical values, categorical classifications, etc. In some embodiments, the system may be configured to identify the authentication server with fewest outstanding requests based the comparison. In other embodiments, the system may be configured to identify the authentication server with relatively few, but not necessarily the fewest, outstanding requests based on the comparison. Moreover, requests generally include many different types of communication transmissions from the NAS client to authentication servers. In the RADIUS protocol example, the requests can include, but are not limited to, Access-Request and Accounting-Request. In some embodiments, the system can be used to perform load balance among multiple server farms. Each server farm includes a group of servers coupled through a proxy server to a NAS client. The NAS client will transmit requests associated with a new transaction based on comparison of numbers of outstanding requests associated with each proxy server.

Dynamic Transaction-Persistent Load Balancing Process

FIG. 6A-6Bare flowcharts illustrating the process of dynamic transaction-persistent server load balancing. During operations, the disclosed system initializes variables corresponding to servers (operation605) to an initial value. Note that separate variables are maintained for different servers.

Further, the system determines whether a response is received from a corresponding server (operation615). If so, the system updates the variable for the corresponding server (operation675), and subsequently transmits a response to client (operation695). If not, the system continues with additional determinations.

For example, the system can determine whether a request from a new transaction is received from a client (operation625). If so, the system compares current values of the variables corresponding to the servers (operation645). The system can then infer the relative capacities of the servers, and transmission latencies between the NAS client and the authentication servers based on the comparison (operation655). For example, a server with fewer outstanding requests than another server is inferred to have a higher relative capacity than the other server at a specific time, because the server is presumed to have high processing capacity and low transmission latency based on the low number of outstanding requests. Next, the system identifies and selects a server based on inferred relative capacities of the servers and transmission latencies (operation665). The system also updates the variable for the identified server (operation675), and transmits the request to identified server (operation685).

In addition, the system can determine whether a request that has been previously transmitted to a corresponding server is expired (operation635). If so, the system will update the variable associated with the corresponding server (operation675).

Dynamic Transaction-Persistent Load Balancing System

FIG. 7is a block diagram illustrating a Network Access Server (NAS) client system capable of performing dynamic transaction-persistent server load balancing in a network. Network Access Server (NAS) system700includes at least one or more radio antennas710capable of either transmitting or receiving radio signals or both, a processor730capable of processing computing instructions, a network interface720capable of communicating to a wired or wireless network, a memory740capable of storing instructions and data, and an authentication mechanism750. System700may be used as a client system, or a server system, or may serve both as a client and a server in a distributed system or a cloud system.

Radio710may be any combination of known or convenient electrical components, including but not limited to, transistors, capacitors, resistors, multiplexers, wiring, registers, diodes or any other electrical components known or later become known.

Network interface720can be any communication interface, which includes but is not limited to, a modem, token ring interface, Ethernet interface, wireless 802.11 interface, cellular wireless interface, satellite transmission interface, or any other interface for coupling network devices.

Processor730can include one or more microprocessors and/or network processors. Memory740can include storage components, such as, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), etc.

Authentication mechanism750is coupled to processor730and memory740to perform the process of dynamic transaction-persistent server load balancing as describe in the present disclosure.

The present disclosure may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems coupled to a network. A typical combination of hardware and software may be an access point with a computer program that, when being loaded and executed, controls the device such that it carries out the methods described herein.

The present disclosure also may be embedded in nontransitory fashion in a computer-readable storage medium, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

As used herein, “access point” (AP) generally refers to receiving points for any known or convenient wireless access technology which may later become known.

Specifically, the term AP is not intended to be limited to 802.11 APs. APs generally function to allow wireless devices to connect to a wired network via various communications standards.

As used herein, the term “mechanism” generally refers to a component of a system or device to serve one or more functions, including but not limited to, software components, electronic components, mechanical components, electro-mechanical components, etc.

As used herein, the term “embodiment” generally refers an embodiment that serves to illustrate by way of example but not limitation.