Network load balancing with host status information

(54) Title: NETWORK LOAD BALANCING WITH STATUS INFORMATION

MAIN COMPUTER (51) lnt.CI .: H04L 29/06; H04L 29/08 (30) Unionist Priority: 06/30/2003 US 10 / 610,519 (73) Holder (s): MICROSOFT TECHNOLOGY LICENSING, LLC (72) Inventor (s): CHRISTOPHER L. DARLING; JOSEPH M. JOY; SUNITA SHRIVASTAVA; CHITTUR SUBBARAMAN (85) National Phase Start Date: 06/30/2004 • «· · • • • ···

NETWORK LOAD BALANCING WITH MAIN COMPUTER STATUS INFORMATION

TECHNICAL FIELD

This report refers, in general, to network load balancing and, in particular, by way of example but not limitation, to network load balancing with status information from the main computer.

FUNDAMENTALS

<img file="BRPI0402591B1_D0001.tif" />

Communication, and many facets of life that involve communication, has been greatly impacted by the Internet. The Internet allows information to be communicated between two people and / or entities quickly and relatively easily. The Internet includes many network nodes that are connected in such a way that information can be transferred between them. Some network nodes can be routers that propagate a packet from one link to another, they can be individual client computers, they can be personal networks for different entities (for example, intranets for companies) and so on.

For this case of the personal network / as well as others, packets arriving at a node or nodes on the Internet are distributed within the personal network. Such a personal network can be formed, for example, from a set of servers that can work, each, in packets that arrive in the personal network. A company, a university, a government agency, etc., can receive many packages in a short time on their personal network. In order to respond in a timely manner and to reduce the likelihood of rejection or loss of pa

<img file="BRPI0402591B1_D0002.tif" />

·· ········ · • ·· ·· · ··· ·· · · ··· · · * ··· · · ···· · ······ · · • · · · ···· ·· ·· ··· cotes arriving, the personal network can count on multiple servers that can each work on the packets that arrive simultaneously.

Incoming packages are often inquiries regarding certain information, such as a document, a catalog item, a web page, and so on. Incoming packages can also refer to an economic transaction between a consumer and a merchant. Other purposes are possible for packet-based communication packages. Despite this, incoming packets are distributed between different servers in a set of servers to accommodate fast packet arrival and / or complex communication exchanges.

The distribution of packets that arrive between the different servers in a set of servers is often called network load balancing. In other words, a network balancing operation can be performed on packets as they arrive at a node or nodes on the Internet when the node or nodes constitute a personal network and / or when they connect the personal network to the Internet.

Such load-balancing operation is achieved using dedicated hardware that borders the personal network at the node or nodes that connect the personal network to the Internet and / or that provide a presence for the personal network on the Internet. The physical hardware that performs the load balancing operation is usually duplicated in its entirety to achieve redundancy and improve the availability of the load balancing operation. To increase capacity

<img file="BRPI0402591B1_D0003.tif" />

of load-balancing operations, more powerful hardware that replicates all previous load-balancing hardware and, thus, its operational capacity, replaces the previous load-balancing hardware. Such an expansion of the operational capabilities of the database, consequently, is confined to increasing the power of the hardware via its replacement.

To implement a load balancing operation, the hardware usually performs a round robin distribution of incoming connection requests. In other words, incoming connection requests are distributed to servers in a set of servers in a linear and repeated manner with a single connection request being distributed to each server. This distribution of round load balancing connections is typically used regardless of the condition of the personal network or the nature of an incoming connection request. If a load-balancing operation extends beyond a round robin distribution, these other factors are only considered to the extent that they can be inferred from network traffic and / or a level of personal network congestion .

Therefore, there is a need for schemes and / or techniques that improve network load balancing and / or the options associated with it.

SUMMARY

In a first exemplary media implementation, one or more media accessible by the processor includes

<img file="BRPI0402591B1_D0004.tif" />

instructions executable by the processor that, when executed, direct a system to perform actions that include: accumulating information about the status of the main computer in multiple main computers; and sending accumulated master computer status information from multiple master computers. In a second exemplary media implementation, one or more media accessible by the processor includes instructions executable by the processor that, when executed, direct a system to take actions that include: receiving state information from main computer from multiple main computers; and making load balancing decisions in response to the status information received from the main computer. In a third exemplary media implementation, one or more media accessible by the processor includes instructions executable by the processor that, when executed, direct a system to perform actions that include: determining health and load information on a per-application basis; and selecting an application among multiple applications in response to health and cargo information.

<img file="BRPI0402591B1_D0005.tif" />

In a fourth exemplary media implementation, one or more media accessible by the processor includes instructions executable by the processor that, when executed, direct a system to perform actions that include: health information and / or load analysis for multiple application endpoints ; and ascertain a token allocation for the multiple application end points in response to the analysis.

In a fifth implementation of exemplary media, one or more media accessible by the processor includes instructions executable by the processor that, when executed, allow a system to implement a message protocol between at least one main computer and one or more load balancing units, the message protocol being used to communicate health and / or load information between at least one main computer and one or more load balancing units.

In an exemplary system implementation, a system includes: at least one device that is hosting one or more applications, the at least one device including a health and load table that includes multiple entries, with each entry among multiple entries associated one or more applications; each entry among multiple entries including: an application identifier for a particular application from one or more applications; the information featuring at least one state of the particular application; and at least one load balancing policy for the particular application.

Other implementations of method, system, approach, device, application programming interface (API), device, media, procedure, arrangement, etc., are described here.

<img file="BRPI0402591B1_D0006.tif" />

BRIEF D DESCRIPTION OF THE DRAWINGS

The same numbers are used in all drawings to refer to similar and / or corresponding aspects, characteristics and components.

<img file="BRPI0402591B1_D0007.tif" />

··· ·· · ·· ···· ·· ·· ··♦

Figure 1 is an exemplary network load balancing paradigm that illustrates a load balancing infrastructure and multiple primary computers;

Figure 2 is an exemplary network load balancing paradigm that illustrates multiple database units and multiple main computers;

Figure 3 illustrates an exemplary load-balancing unit having separate functionality and an exemplary main computer.

Figure 4 illustrates an exemplary load balancing infrastructure with separate sorting and shipping functionality.

Figure 5 is a flow diagram that illustrates an exemplary method for scaling network load balancing infrastructure in different configurations.

Figure 6 illustrates a first exemplary network load balancing infrastructure configuration from a device perspective.

Figure 7 illustrates a second exemplary network load balancing infrastructure configuration from a device perspective.

Figures 8A and 8B illustrate exemplary first and second network load balancing infrastructure configurations from a component perspective.

Figures 9A and 9B illustrate exemplary first and second network load balancing infrastructure configurations from a resource perspective.

Figure 10 illustrates a balancing approach

<img file="BRPI0402591B1_D0008.tif" />

of exemplary network load involving main computer status information.

Figure 11 is a flow diagram illustrating an exemplary method for balancing network load that encompasses main computer status information.

Figure 12 illustrates an exemplary network load balancing approach that involves health and load information.

Figure 13A is a health and load table as shown in Figure 12.

Figure 13B is a consolidated health cache and exemplary load as shown in Figure 12.

Figure 14 is a flow diagram illustrating an exemplary method for balancing network load that involves health and load information.

Figure 15 illustrates an exemplary message protocol for communications between the main computers and the load balancing units that are illustrated in Figure 12.

Figure 16 illustrates an exemplary message transmission scheme for communications between the main computers and the load balancing units that are illustrated in Figure 12.

Figures 17A and 17B illustrate exemplary health and cargo information proxy storage scenarios for health and cargo tables in Figure 13A and for consolidated health and cargo caches in Figure 13B, respectively.

Figure 18 illustrates an allocation procedure for ·· ··· ·· · ·· ·· ···· ·· exemplary target main computer that uses health and load information.

Figure 19 illustrates an exemplary network load balancing approach that involves session information.

Figure 20 illustrates an exemplary network load balancing approach that involves communicating session information using notifications and messages.

Figure 21 is a flow diagram that illustrates an exemplary method for network load balancing that involves communicating session information using notifications and messages.

Figure 22 illustrates an exemplary approach to managing session information across multiple load balancing units.

Figure 23A is an example session table as illustrated in Figure 20.

Figure 23B is an exemplary distributed atom manager table (DAM - Distributed Atom Manager; DAMT Distributed Atom Manager Table), as illustrated in Figure 22.

<img file="BRPI0402591B1_D0009.tif" />

Figure 24 is a flow diagram that illustrates an exemplary method for managing session information across multiple load balancing units.

Figure 25 illustrates an exemplary network load balancing infrastructure with request routing functionality.

Figure 26 is a flow diagram that illustrates an exemplary method for routing incoming packets with respect to (i) session information and (ii) health and cargo information.

Figure 27 illustrates an exemplary traffic routing flow in the absence of failures.

Figure 28 illustrates an exemplary traffic routing flow in the presence of failure (s).

Figure 29 illustrates additional exemplary back-up (failover) operating mode procedures for high availability of network load balancing infrastructure.

Figure 30 illustrates an exemplary operational implementation of traffic routing interaction with health and cargo information.

Figure 31 illustrates exemplary high availability mechanisms for network load balancing infrastructure.

Figure 32 illustrates an exemplary approach to network load balancing at the exemplary application level with connection migration.

Figure 33 is a flow diagram that illustrates an exemplary method for migrating a connection from a first device to a second device.

Figure 34 illustrates an exemplary approach to connection migration from the perspective of an originating device.

Figure 35 illustrates an exemplary approach to connection migration from the perspective of a target device.

Figure 36 illustrates an exemplary approach to a ··· ··· ·· · ·· ·· * ··· ·· • «·· ·· · · · ·· · • · · · · · · · · · ··· · ··· «« ··· «·· · · · ·· • ··« ······ • ·· »·· * ·· ····« · ·· discharge procedure for a connection migration.

Figure 37 illustrates an exemplary approach to a loading procedure for a connection migration.

Figure 38 illustrates an exemplary approach to building a packet tunnel between a sender and a main computer.

Figure 39 is a flow diagram illustrating an exemplary method for constructing a packet tunnel between a first device and a second device.

Figure 40 illustrates an exemplary computing operating environment (or general device) that is capable of implementing (in whole or in part) at least one network load balancing aspect as described here.

<img file="BRPI0402591B1_D0010.tif" />

DETAILED DESCRIPTION

Exemplary Network Load Balancing Paradigms

This section describes exemplary paradigms for network load balancing and is used to provide fundamentals, environments, contexts, etc. for descriptions in the following sections. This section refers mainly to Figures 1 to 3.

Figure 1 is an exemplary network load balancing paradigm 100 that illustrates a load balancing infrastructure 106 and multiple primary computers 108. The exemplary network load balancing paradigm 100 includes multiple clients 102 (1), 102 (2) ... 102 (m) and multiple main computers 108 (1), 108 (2) ... 108 (n), as well as network 104 and infrastructure of

<img file="BRPI0402591B1_D0011.tif" />

load balancing 106.

Each of the clients 102 can be any device capable of network communication, such as a computer, a mobile station, an entertainment instrument, another network, and so on. 102 clients can also relate to a person and / or entity that is operating a client device. In other words, clients 102 can comprise logical clients that are users and / or machines. Network 104 may be formed from one or more networks, such as the Internet, an intranet, a wired or wireless telephone network, and so on. Additional examples of devices for clients 102 and network types / topologies for network 104 are described below with reference to Figure 40 in the section entitled Environment

Exemplary Operational for Computer or Other Device.

Individual clients 102 are able to communicate with one or more main computers 108 and vice versa, over network 104 via load balancing infrastructure 106. Main computers 108 host one or more applications for interaction / communication with clients 102, for use by 102 customers and so on. Each main computer 108 can correspond to one server and / or one device, multiple servers and / or multiple devices, part of a server and / or part of a device, some fuel from these and so on. Particular implementations for main computers 108 are described below in the context of different network load balancing situations. (However, indirect support for main computers 108 is generally not shown for the sake of clarity.) In addition, additional examples of devices for main computers 108 are also described below with reference to Figure 40 in the section entitled Operating Environment Copy for Computer or Other Device.

Load balancing infrastructure 106 can be reached or located over network 104 at one or more virtual Internet Protocol (IP) addresses. Communications from clients 102 (or other nodes) that are routed to the virtual IP address of load balancing infrastructure 106, are received there and forwarded to a main computer 108. The load-balancing infrastructure 106 comprises hardware and / or software components (not shown explicitly in Figure 1).

Although load-balancing infrastructure 106 is shown as an integral ellipse, the infrastructure for load-balancing can also be distributed to other aspects of the exemplary network load-balancing paradigm 100. For example, component (s) load balancing infrastructure software 106, may be located on one or more main computers 108, as described below. Examples of architectures for load-balancing infrastructure 106 are described below with reference to Figure 40 in the section whose title is Exemplary Operating Environment for Computer or Other Device.

As indicated in (1), one or more main computers 108 can provide computer status information

<img file="BRPI0402591B1_D0012.tif" />

main controller from main computers 108 for load balancing infrastructure 106. This η

Main computer status information can be application specific. Examples of such main computer status information are described below and include health and / or load information, session information, etc., for main computers 108. A particular implementation that includes providing health and / or load information from the main computers 108 to the load balancing infrastructure is described below in the section entitled Exemplary Health and Load Handling.

In (2), a request is sent from client 102 (1) over network 104 to load balancing infrastructure 106 at its virtual IP address. The content, format, etc., of a request from a client 102 may depend on the application to which the request is directed and the term request may implicitly include a response or responses from main computers 108, depending on the context . Types of customer requests include, but are not limited to:

1. Hyper Text Transfer Protocol (HTTP) GET requests from a client using a browser. Depending on the application (and more specifically, the uniform resource locator (URL) of the requests), it may be better not to serve requests from different sets of primary computers and the existence of a client session state on the computers

<img file="BRPI0402591B1_D0013.tif" />

<img file="BRPI0402591B1_D0014.tif" />

can prevent requests from specific customers from being routed to specific primary computers. Requests can be over a secure sockets layer (SSL - Secure Sockets Layer) connection (or another encrypted one).

2. Virtual private network (VPN) connections (for example, primary computers are a set of VPN servers). In this case, the request can be considered as a 2-layer tunneling protocol (L2TP) connection or point-to-point tunneling protocol (PPTP) connection (the latter is a combination of a transmission control protocol control connection ( TCP) and associated generic routing (GRE) data traffic.

3. Terminal server connections (for example, the primary computers are a set of terminal servers).

<img file="BRPI0402591B1_D0015.tif" />

4. Proprietary requests in the form of individual TCP connections (one per request) using a proprietary application-specific protocol.

5. Simple object access protocol (SOAP) requests.

6. Real-time communication requests involving control information over a TCP connection and latency-sensitive media flow in the real-time protocol (RTP).

Thus, requests can take many different application-specific forms. In certain described implementations, the load balancing infrastructure 106 can make application-specific shipping decisions.

<img file="BRPI0402591B1_D0016.tif" />

In 33, the load balancing infrastructure 106 sends the request from 102 (1) to the main computer &lt;7 I (108) (in this example). The infrastructure (/ load balancing 106 can consider one or more among many factors when selecting a main computer 108 to which the request should be sent, depending on what implementation (s) described here is ( (s) being employed. For example, load-balancing infrastructure 106 can take into account health and / or load information from the application of each main computer 108, session information pertaining to client 102 (1), as stored on a main computer 108 and so on.

Figure 2 is an exemplary network load balancing infrastructure paradigm 200 that illustrates multiple load balancing units 106 and multiple main computers 108. Specifically, load balancing infrastructure 106 is shown as multiple load balancing units. charge 106 (1), 106 (2). . .

106 (u) in the exemplary network load balancing paradigm 200. Additionally, two routers and / or switches 202 (1) and 202 (2) are illustrated.

Routers / switches 202, if present, can be considered as part of or separate from load-balancing infrastructure 106 (of Figure 1). Routers / switches 202 are responsible for directing general requests and individual packets that are received from network 104 to the shared virtual IP address (es) (VIP) of load balancing units 106. If a first router / switch 202 fails, the second router / switch 202 can take the place of the first. Although two routers / switches 202 are illustrated, one or more of two routers / switches 202 can be employed alternatively.

Routers / switches 202 can bypass the load balancing infrastructure or be aware of load balancing. If routers / switches 202 are not aware of load balancing, one of two exemplary options can be employed: For a first option, a load balancing unit 106 is assigned to the shared VIP address and all network traffic is forwarded to over there. This load balancing unit 106 then redistributes traffic evenly across the other load balancing units 106. However, there are some bottlenecks and back-up mode (failover) problems with this first option. (which can be mitigated if multiple VIP addresses are shared and divided between multiple load balancing units 106). For a second option, routers / switches 202 are tricked into directing network traffic to all load balancing units 106, which individually decide which traffic each should accept for load balancing. However, there are problems with inefficient effort duplication and switch performance / compatibility with this second option.

<img file="BRPI0402591B1_D0017.tif" />

If, on the other hand, routers / switches 202 * · * ·· · are aware of load balancing, routers / switches 202 can be made to distribute network traffic that arrives between multiple load balancing units 106 (for example, by roundrobin). It should be understood that such load-balanced routers / switches 202 are capable of performing load-balancing functions at a rudimentary level (for example, in hardware). For example, load-aware routers / switches 202 can perform simple session affinity based on the IP address such that all packets from a specific source IP address are routed to the same load-balancing unit 106.

Each load-balancing unit 106, illustrated separately among the load-balancing units 106, can represent a physical device, multiple physical devices, or part of a single physical device. For example, load balancing unit 106 (1) can correspond to one server, two servers or more. Alternatively, the load balancing unit 106 (1) and the load balancing unit 106 (2) can together correspond to a single server. An exemplary load balancing unit 106 is described below from a functional perspective with reference to Figure 3.

Two exemplary request paths [1] and [2] are illustrated in Figure 2. For request path [1], client 102 (2) transmits a request over network 104 that reaches router / switch 202 (1). 0 routed

<img file="BRPI0402591B1_D0018.tif" />

·· ·· *«·· ·· • · · ·

<img file="BRPI0402591B1_D0019.tif" />

<img file="BRPI0402591B1_D0020.tif" />

· ♦ ·· * ♦ ·· »· painter / switch 202 (1) directs the request packet (s) from client 102 (2) to the load balancing unit 106 (1). The load balancing unit 106 (1) then sends the request packet (s) to the main computer 108 (1), according to some load balancing functionality (e.g., guideline). For the request path [2], the client 1029m) transmits a request over network 104 that reaches router / switch 202 (2). 0 router / switch 202 (2) directs the request packet (s) from the client-102 (m) to the load balancing unit 106 (u). The load balancing unit 106 (u) then sends the request packet (s) to the main computer 108 (n), according to some load balancing functionality. Exemplary load balancing functionality is described below with reference to Figure 3.

<img file="BRPI0402591B1_D0021.tif" />

Figure 3 illustrates an exemplary load balancing unit 106 that has separate functionality and an exemplary main computer 108. The load balancing unit 106 includes seven (7) function blocks 302-314. These function blocks of the load balancing unit 106 can be realized at least partially using software. Main computer 108 includes one or more 316 applications. In a described implementation, load balancing unit 106 includes a sender 302, a classifier 304, a request router 306, a session tracker 308, a connection migrator 310, a tunneler 312 and a health and load handler 314 .

·· ♦·· ♦· · *· ·· ·· • * · · · 4 4 4 44 4 4 • 4 4 4 44 4 4 4 4 44 4 • ·· 4 44 4444 44 44 4

The health and load handler 314 is located partly on the main computers 108 and partly on the devices of the load balancing units 106. The health and load handler 314 monitors the health and / or load (or more generally, the state) of computers key 108 such that your health and / or load information can be used for load balancing functionality (for example, when making load balancing decisions). Exemplary implementations for the health and cargo handler 314 are described below, particularly in the section titled Health Handling and Exemplary Cargo.

<img file="BRPI0402591B1_D0022.tif" />

Session tracker 308 can also be located partially on main computers 108 and partially on devices in load balancing units 106. Session tracker 308 monitors sessions that are established by clients 102 such that reconnections / continuations of previously established sessions can be facilitated by the load balancing functionality. For example, some applications maintain application-specific client session data on the primary computers (which is also a type of primary computer state information). These applications typically expect customers to use the same main computer for the duration of any given session. Exemplary types of sessions include: (i) a TCP connection (which is, strictly speaking, a session); (ii) an SSL session; (iii) a secure IP session (IPsec); (iv) an HTTP cookie-based session; and so on.

♦ · ··· • ·· • · · · •····* • · ·

<img file="BRPI0402591B1_D0023.tif" />

Although session tracker 308 is illustrated as a discrete block in load balancing unit 106, session tracking functionality of session tracker 308 can actually be implemented at a global level. In other words, session affinity is supported on multiple load balancing units 106. Session tracker 308 includes a centralized database and / or a distributed database of information

10- session in order to preserve the affinity of the session. Exemplary implementations for the 308 session tracker, with an emphasis on a distributed database approach, are described below, particularly in the section whose title is Exemplary Session Tracking.

0 classifier 304 uses the data acquired and maintained by the health and load handler 314 and / or session tracker 308, possibly in conjunction with other factors, to classify incoming requests. In other words, classifier 304 selects a main computer

108 target for each incoming request from a client 102. Sender 302 sends the client's requests (and / or their packages) according to the target host computer 108, as selected by classifier 304. Sender 302 and classifier 304 can operate on a per-package basis. Exemplary implementations for sender 302 and classifier 304 are described below, particularly in the sections whose titles are Exemplary Approach to Flexible Network Load Balancing and Classification, Shipping

<img file="BRPI0402591B1_D0024.tif" />

<img file="BRPI0402591B1_D0025.tif" />

Exemplary Request Routing and Request.

request router 306, in contrast to packet implementations from sender 302 and classifier 304, can act as a proxy for an application that runs on a host computer 108. For example, request router 306 can terminate TCP connections, analyze (perhaps partially) each logical request from a client 102 and resubmit each logical request to the target host computer 108. Consequently, each logical request from a -102 client can be directed to a different main computer 108, depending on the decisions made by the request router 306. Furthermore, the request router 306 can pre-process a connection (for example, SSL decryption), can choose to absorb certain requests (for example, due to the fact that the request router 306 maintains a response cache) , you can arbitrarily modify requests before sending them to main computers 108, and so on. Exemplary implementations for the 306 request router are also described below, particularly in the sections whose headings are Exemplary Approach to Flexible Network Load Balancing and Exemplary Request Classification, Shipping and Routing.

Connection migrator 310 allows a connection to be initially terminated at load balancing unit 106 and then migrated, such that the connection is subsequently terminated at main computer 108. This migration

<img file="BRPI0402591B1_D0026.tif" />

connection can facilitate load balancing at the application level. Connection migrator 310 is capable of migrating a connection from the load balancing unit 106 to a main computer 108 in such a way that the original termination in the load balancing unit 106 is transparent to a requesting client 102 and applications 316 main computer 108 that has just been completed.

Tunneler 312 can use an encapsulation scheme for tunneling packages that does not introduce an extra code for each tunneled package.

The 312 tunneler functionality can also be used - in situations that do not involve connection migration. Furthermore, the connection migrator 310 and / or tunneling machine 312 can additionally be used in unbalanced load implementations. Exemplary implementations for connection migrator 310, as well as for tunneler 312, are described below, particularly in the section whose title is Exemplary Connection Migration with Optional Tunneling and / or Application-level load balancing.

Any given implementation of a load balancing unit 106 may include one or more of the functions illustrated. Although illustrated separately, each of the functions of blocks 302-314, can actually be related to, be superimposed on and / or even other functions. For example, the health and / or cargo information from the health and cargo handler 314, can be used by the 304 classifier. In addition, connection migrator 310 and tunneler 312 work together with sender 302 and classifier 304. Certain other overlaps and interactions e10

<img file="BRPI0402591B1_D0027.tif" />

xemplares are described below.

In a described implementation, host computer 108 runs and provides access to one or more 316 applications. Generally, 316 applications include file delivery programs, management programs / web site servers, remote access programs, e-mail programs , database access programs, and so on. Specifically, 316 applications may include, but are not limited to, web servers such as Internet Information Server® (IIS), from Microsoft® Corporation, terminal servers such as Microsoft® Terminal Server ™ and protection and proxy barrier products such as Internet Security and Acceleration Server ™ (ISA). Although the examples of the specific application 316 in the previous sentence relate to Microsoft® products, network load balancing, as described here, is not limited to any vendor (s), application (s) or operating system (s) ) particular (s).

Exemplary Approach to Load Balancing

Flexible Network

<img file="BRPI0402591B1_D0028.tif" />

This section clarifies how the network load balancing implementations described in this and other sections provide a flexible approach to network load balancing. This section mainly refers to Figures 25 to 9B.

As noted above, the network load balancing functionality can be scaled by replacing a first network load balancing director with

999 ♦ &lt;9 99 99 · ♦ ·· 99 · · 9 · 9 ♦ è ♦ · «· • 9 9 9 9 · 9 · · ♦♦ 9 9 • 9 999999 9 9 999«

999 999 «» 9 · a second largest and most powerful network load balancing agent. The hardware capabilities of the second network load balancing director replicate all of the hardware capabilities of the first network load balancing director, except that greater capacity is provided. This is an inflexible approach that can be very inefficient, especially when only one network load balancing item is limiting performance and precipitating an upgrade.

<img file="BRPI0402591B1_D0029.tif" />

10 network load balancing director.

Figure 4 illustrates an exemplary network load balancing infrastructure with separate classification and shipping features. Separate classification and shipping functionalities are represented by the classifier

304 and sender 302, respectively. Although the classification and shipping functions are further described below, especially in the section titled Exemplary Classification, Shipping and Request Routing, an initial description is presented here as an example of the interaction between the load balancing infrastructure functionality. network and main computers 108.

In a described implementation, sender 302

- corresponds to, and is the network endpoint for, the virtual IP address (or addresses) (VIP). Sender 302 is a relatively low level component that makes simplified and / or elementary orientation decisions, if at all, when routing packets to another destination or final destination. Sender 302 queries a routing table pa25 ·· ··· ·· »·« · * ···· * «• · · ·· · · · ···· · ·« «· · ···· ·· · «· ···» ··· ···· · · · · ··· ·· «·· ···· ·· ··« · «to determine this destination. Classifier 304 populates the routing table based on one or more factors (for example, status information from the main computer), which are further described in other sections.

Clients 102 and host computers 108 also correspond to indicated network addresses. Specifically, client 102 (1) corresponds to address Cl, client 102 (2) corresponds to address C2 ... client 102 (m) corresponds to address Cm. In addition, main computer 108 (1) corresponds to address H1, main computer 108 (2) corresponds to address H2 ... main computer 108 (n) corresponds to address Hn.

Five communication paths (1) to (5) are shown in Figure 4. The communication path (1) is between client 102 (1) and sender 302 and the communication path (5) is between sender 302 and main computer 108 (1). Communication paths (2) to (4) are between sender 302 and classifier 304. For simplicity in this example, the connection associated with communication paths (1) to (5) is an HTTP TCP connection. Furthermore, load balancing in this example refers to the routing of connections arriving at the main computer 108 less loaded, at least without any explicit load balancing consideration at the application level.

Communication paths (1) to (5) indicate how the sender 302 and classifier 304 load balance a simple HTTP TCP connection from client 102 (1). In (1), client 102 (1) initiates the TCP connection via

<img file="BRPI0402591B1_D0030.tif" />

<img file="BRPI0402591B1_D0031.tif" />

• ·# · • · · • · · · • ····· • » »

<img file="BRPI0402591B1_D0032.tif" />

by sending a TCP SYN packet addressed to the VIP address. The routing infrastructure of network 104 performs the routing of this packet to sender 302 via router / switch 202 (1), which is router / switch 202 plus 5 near sender 302.

In (2), the sender 302 consults a routing table, which can be internal to the sender 302 or, otherwise, accessible from him, in order to look for this connection. These connections can be identified in the table of

10. routing through 4-.tuple TCP./IP (ie _is, source IP address, source TCP port, destination IP address, destination TCP port). Due to the fact that this is the first packet of the connection, there is no entry in routing table 1 a. Then, the try paddle 302 applies the default route action, which is to send this packet to classifier 304.

In (3), classifier 304 queries its cache (for example, consolidated) of main computer status information for the main computers 108 (1), 108 (2) ... 108 (η). The classifier 304 concludes that the main computer 108 (1) is available and the main computer 108 minutes loaded at this time for this example. Classifier 304 also evaluates a route in the routing table consulted by sender 302 for this TCP connection. For example, classifier 304 adds a route entry or instructs the sender 302 to add a route entry in the routing table that maps the TCP connection (for example, identified by the 4-tuple TCP) to a specific destination computer 108 , which is the computer

<img file="BRPI0402591B1_D0033.tif" />

main painter 108 (1) in this example. More particularly, the route entry specifies the network address H1 of the main computer 108 (1).

In (4), classifier 304 sends the TCP SYN packet back to sender 302. Alternatively, classifier 304 can forward this initial TCP SYN packet to host computer 108 (1) without using sender 302. Other options available for the classifier 304 are further described below.

In (5), the sender 302 can access a route entry for the connection represented by the SYN packet, then it forwards the packet to the main computer 108 (1) at address H1. Sender 302 also forwards all subsequent packets from client 102 (1) to this connection directly to main computer 108 (1). In other words, sender 302 can avoid further interaction with classifier 304 for this connection. You can use a mechanism or a combination of mechanisms, which are further described below, to delete the route entry when the connection is over.

<img file="BRPI0402591B1_D0034.tif" />

For communication path (5) in many protocol environments, sender 302 cannot simply send packets from client 102 (1) to main computer 108 (1) at network address H1, because these packets are addressed to the VIP address that is hosted by the sender 302 itself. Instead, the sender 302 can employ one or more of the following exemplary options:

1. Sender 302 performs NetWork Address Trans28

<img file="BRPI0402591B1_D0035.tif" />

··»»··

<img file="BRPI0402591B1_D0036.tif" />

(NAT) by (i) overwriting the source IP address (client 102 (1)) (Cl) and the port number with the IP address and port number generated by NAT from sender 302 and (ii) recording above the destination IP address (VIP) with the IP address (Hl) of the main computer (108 (1)).

2. Sender 302 performs half-NAT by overwriting the destination IP address (VIP) with the IP address (Hl) of the main computer (108 (1)), such that the source IP address (client 102 (1)) (Cl) and the port number are preserved.

<img file="BRPI0402591B1_D0037.tif" />

3. Sender 302 tunnels packets received from client 102 (1) from sender 302 to main computer 108 (1). Specifically in this example, tunneling can be done by encapsulating each packet within a new IP packet that is addressed to the main computer 108 (1). Network load balancing conscious software on main computer 108 (1) reconstructs the original package as received at sender 302 from customer 102 (1). This original package is then displayed on a virtual interface on main computer 108 (1) (for example, the VIP address corresponding to sender 302 is linked to this virtual interface on main computer 108 (1)). Exemplary implementations of such tunneling are additionally described below with reference to tunneler 312, especially for connection migration and particularly in the section whose title is Exemplary Connection Migration with Optional Tunneling and / or Application-level load balancing.

Although Figures 4 to 9B show two specific functions, such as classification and referral, it must be understood that other functions, such as the 306 request router, session tracker, 308, connection migrator 310 and health and cargo handler 314, can also be scaled independently (for example, independently factored), as further described below. In addition, it should be noted that one or more of two functions can be separated and scaled independently at different times and / or simultaneously. In addition, although TCP / IP is used for clarity in many examples in this and other sections, the network load balancing principles described here are applicable to other transmission and / or communication protocols.

In the exemplary manner of Figure 4, the network load balancing functions (such as that shown in Figure 3) can be separated from each other for purposes of scalability. They can also be separated and duplicated in different configurations for greater availability. Exemplary configurations for scalability and / or availability are described below with reference to Figures 6 to 9B,

<img file="BRPI0402591B1_D0038.tif" />

since the method of Figure 5 is described.

Figure 5 is a flow diagram 500 that illustrates an exemplary method for scaling network load balancing infrastructure in different configurations. Flow diagram 500 includes three blocks 502-506. Although the actions of the flow diagram 500 can be performed in other environments and with a variety of software schemes, Figures 1-4 and 6-9B are used in particular to illustrate

<img file="BRPI0402591B1_D0039.tif" />

certain aspects and examples of the method.

In block 502, the load-balancing infrastructure is operated in a first configuration. For example, each configuration can relate to one or more of a selection, proportion and / or interrelation of different load balancing functionalities; a series of and / or type (s) of different devices; an organization and / or design of different components; a distribution and / or allocation of resources; and so on. In block 504, the network load balancing infrastructure is scaled. For example, separate load-balancing features can be expanded and / or concurrently contracted on an individual and / or independent basis. In block 506, the scaled network load balancing infrastructure is operated in a second configuration.

As noted above, a monolithic network load balancing realizer can be scaled up by increasing the network load balancing functionality in its entirety by supplanting the previous network load balancing hardware with hardware load balancing hardware. most powerful network.

On the other hand, scaling the network load balancing infrastructure can allow (sub) network load balancing functions to be scaled individually and / or independently. It can also allow network load balancing functions to be scaled together or individually between different numbers of devices. Examples of device, component and scale orientated

<img file="BRPI0402591B1_D0040.tif" />

<img file="BRPI0402591B1_D0041.tif" />

resource is provided below.

Figure 6 illustrates a first exemplary network load balancing infrastructure configuration from a device perspective. In this first device-oriented network load balancing infrastructure configuration, three devices 602 (1), 602 (2) and 602 (3) are illustrated. However, one, two or more of three devices 602 can be employed alternatively.

As illustrated, a sender 302 (1), a classifier 304. (_ L.) _ And a main computer 108 (1) are resident and run on device 602 (1). A sender 302 (2), a classifier 304 (2) and a main computer 108 (2) are resident and run on device 602 (2). In addition, a sender 302 (3), a classifier 304 (3) and a main computer 108 (3) are resident and run on device 602 (3). Thus, in this first device-oriented network load balancing infrastructure configuration, a respective sender 302, classifier 304 and main computer 108 are sharing the resources of each respective device 602.

In operation, senders 3 02 are the end points of the network for the VIP address (es). Any classifier 304 can guide a route for a connection to any main computer 108, depending on the status information of the main computer. For example, classifier 304 (2) can evaluate a route for a new connection that arrives at main computer 108 (3). According to a new route entry for this connection, the sender 302 (2) sends the pa25 • · ♦ ····· · · · ··· · ·· »* ····· ·· · ♦♦ ♦ · · ♦ ♦♦ ♦ · · ♦ · subsequent quotas for main computer 108 (3).

In a device-oriented network load balancing infrastructure configuration to which the first illustrated can be scaled, a fourth device 602 (4) (not shown explicitly in Figure 6) can be added and includes a 302 sender ( 4), a classifier 304 (4) and a main computer 108 (4). If, on the other hand, sufficient classifier functionality is already present with 304 classifiers (1-3), but additional shipping functionality can benefit the handling of main computers 108, a fourth device 602 (4) that includes a sender may be added 302 (4) and, optionally, a main computer 108 (4). For this scaled configuration, another classifier 304 (1, 2 or 3) can evaluate routes to the sender 302 (4) to any of the main computers 108 (1, 2, or 3) and the main computer 108 (4), if present.

The first exemplary device-oriented network load balancing infrastructure configuration in Figure 6 may be especially appropriate for smaller housing situations where separate devices for the network load balancing infrastructure are not technically worthwhile and / or economically or are not viable. However, as hosting obligations expand to a larger number (and / or greater demand in the same number) of primary computers 108 or if the network balance on primary computers 108 is significant, the first infrastructure configuration -structure of

<img file="BRPI0402591B1_D0042.tif" />

• · * ·· · exemplary device-oriented network load balancing can be scaled to accommodate this expansion, as represented by a second exemplary device-oriented network load balancing infrastructure configuration in Figure 7.

Figure 7 illustrates a second exemplary network load balancing infrastructure configuration from a device perspective. In this second exemplary device-oriented network load balancing infrastructure configuration, three devices 602 (1), 602 (2) and 602 (3) are also illustrated. Again, one, two or more than three devices 602 can be employed alternatively.

As shown, sender 302 (1) and classifier 304 (1) are resident and are executed on device 602 (1). The sender 302 (2) and the classifier 304 (2) are resident and are executed on the device 602 (2). In addition, sender 302 (3) and classifier 304 (3) are resident and executed on device 602 (3). Thus, in this second device-oriented network load balancing infrastructure configuration, each respective sender 302 and classifier 304 are not sharing resources from each respective device 602 with a main computer 108. Furthermore, the infrastructure network load balancing can be serving any number of primary computers 108.

In operation, 302 senders are again the

<img file="BRPI0402591B1_D0043.tif" />

end points of the network to the VIP address (es). Besides that,

<img file="BRPI0402591B1_D0044.tif" />

any classifier 304 can evaluate a route for a connection to any host computer 108, depending on host computer status information. For example, classifier 304 (3) can evaluate a route for a new arrival connection to main computer 108 (2). According to a new route entry for this connection, sender 302 (3) sends subsequent packets to main computer 108 (2).

Thus, the network load balancing infrastructure 10 as performed in the software, for example, can be scaled by moving the network load balancing infrastructure (or part of it) from devices that are shared with primary computers 108, for devices that are not shared with primary computers 108. In addition, as alluded to above for Figure 6, another device 602 (4) can be added to the network load balancing infrastructure to provide additional shipping functionality, additional sorting functionality, additional functionality of both types and so on.

Figures 8A and 8B illustrate exemplary first and second network load balancing infrastructure configurations from a component perspective. As illustrated, the first exemplary component-oriented network load balancing infrastructure configuration includes four components. The second exemplary 850 component-oriented network load balancing infrastructure configuration includes six

<img file="BRPI0402591B1_D0045.tif" />

<img file="BRPI0402591B1_D0046.tif" />

components. A second alternative configuration 850 includes a seventh component, as indicated by the dotted line block, which is further described below.

Specifically, the first exemplary network load balancing infrastructure configuration oriented for component 800 (or first configuration 800) includes (i) two senders 30291) and 302 (2) and (ii) two classifiers 30491) and 304 (2) . The second exemplary network load balancing infrastructure configuration oriented for component · 850 (or- second configuration 850) includes (i) four senders 302 (1), 302 (2), 302 (3) and 302 (4) and (ii) two classifiers 304 (1) and 304 (2). Thus, the first configuration 800 is scaled to the second configuration 850 through the addition of two components, which are shipping components in this example.

In a described implementation, each respective functional component related to network load balancing, corresponds to a respective device (not explicitly shown in Figure 8A or 8B); however, each component may alternatively correspond to part of a device or more than one device. For example, senders 302 (1) and 302 (2) can be distributed across three devices. Or sender 30291) and classifier 304 (1) can correspond to a first device and sender 302 (2) and classifier 304 (2) can correspond to a second device.

Two functional components related to network load balancing are added to scale the

<img file="BRPI0402591B1_D0047.tif" />

<img file="BRPI0402591B1_D0048.tif" />

first configuration 800 to second configuration 850. However, a component (or more than two) can alternatively be added to scale the network load balancing infrastructure. In addition, two or more different types of functional components can be scaled simultaneously. For example, as illustrated by the block in dotted lines, another classification component (for example, classifier 304 (3)) can also be added when scaling the first configuration 800 to the second configuration 850.

Furthermore, scaling through two or more different types of functional components can be carried out in similar proportions (for example, equivalent) or dissimilar to each other. As illustrated, adding shipping components 302 (3) and 302 (4) while adding no classifier component 304 or while adding a single classifier component 304 (3), represents scalar in dissimilar proportions. However, two classifying components 304 (3) and 304 (4) (the latter not explicitly illustrated in Figure 8B) can be added while the two shipping components 302 (3) and 30294) are added to a scale in similar proportions. In spite of this, each functional component related to individual network load balancing can consume a different amount of available network load balancing infrastructure resources, as described with reference to Figures 9A and 9B.

Figures 9a and 9B illustrate the first and second

<img file="BRPI0402591B1_D0049.tif" />

♦ · · • · · · ···· »*» ···· ·· · • · · · · ·· · ··· · · · · · · · · · · · · · ··· · ·· ·· ··· exemplary network load balancing infrastructure configurations from a resource perspective. The first exemplary network-oriented load balancing infrastructure configuration 900 (or first 900 configuration) includes a first distribution or resource allocation for a load balancing unit 106. The second exemplary 950 resource-oriented network load balancing infrastructure configuration (or second configuration) includes a second distribution10 '

<img file="BRPI0402591B1_D0050.tif" />

dog^_'resource for the load balancing unit. 106._

As illustrated, the first 900 configuration includes a 70% -30% resource distribution and the second 950 configuration includes a 40% 60% resource distribution. Such resources may include total device resources (for example, number of devices), processing resources (for example, part of cache, main memory, etc.), network bandwidth and / or interface resources (for example, bits per second and / or physical network interface cards (NICs)) and so on.

Specifically for the first configuration 900, the sender 302 consumes 70% of the resources of the load balancing unit 106 while the classifier 304 consumes 30% of these resources. After re-allocation during a scale procedure to produce the second 950 configuration, the sender 302 consumes 40% of the resources of the load balancing unit 106 while the classifier 304 consumes 60% of these resources.

In an exemplary situation, the first configuration

<img file="BRPI0402591B1_D0051.tif" />

900 can facilitate better network load balancing performance when fewer longer transactions are being handled by the associated primary computers (not shown in Figures 9A and 9B) because the classifier functionality is used when initial communication for a connection and shipping functionality be used after that. The second 950 configuration, on the other hand, can facilitate better network load balancing performance when more minor transactions are being handled by the associated primary computers, because the sorting functionality is used for a larger percentage of the total number of packets that have been tunneled through the network load balancing infrastructure. In this situation, if the request routing functionality is also being employed, then a percentage of the total computing resources is also allocated to the requesting router (s) 306. The distribution of resources among the three functionalities can be adjusted while connections are being handled (for example, still adjusted during flight), depending on current consumption and / or resource deficit.

As indicated above with reference to Figures -2 and 3, each load balancing unit 106 can correspond to all or part of a total load balancing infrastructure 106. For any given load balancing unit 106, defined or stipulated physically, logically, arbitrarily, etc., its resources can be re-allocated during a

<img file="BRPI0402591B1_D0052.tif" />

<img file="BRPI0402591B1_D0053.tif" />

shut up. More specifically, a distribution of resources between different separate functions related to the network load balancing of a load balancing unit 106, can be changed in a scaling procedure. In addition, more than two different functions, as well as other network load balancing functions that are not specifically illustrated in Figures 9A and 9B, may have different percentages of resources allocated.

The percentage of total system resources allocated to all load balancing functions can also be changed in a scaling procedure. As an example of overall processing power, the percentage of total processing power that is devoted to load balancing can be gradually increased as the amount of traffic that needs to be load balanced increases.

Optionally, the network load balancing software can perform monitoring to analyze and determine whether resources should be re-allocated. For example, network load balancing software can monitor processor utilization of different functions related to network load balancing. Actual relocation can also be performed, optionally, automatically by the network load balancing software in an offline or in-line mode.

It must be understood that a scalability of the network load balancing infrastructure (for example, as performed at least partially in the software)

<img file="BRPI0402591B1_D0054.tif" />

<img file="BRPI0402591B1_D0055.tif" />

re), as described here, can relate to different facilities and not necessarily to a move to a single facility. In a resource-oriented example, the network load balancing infrastructure, as described here, can be configured according to a distribution of resources in an installation environment and can be configured according to a different resource distribution in another installation environment having different operating parameters. In addition, the capabilities, features, options, etc., described above with respect to scaling, are also applicable for scaling in. In other words, the resources devoted to the¹network load balancing structure (or its subfunctions) can also be reduced.

Exemplary Health and Cargo Handling

This section describes how the main computer's status information, such as health and / or load information, can be collected and used for network load balancing. This section mainly refers to Figures 10 to 18 and clarifies the health and load functionality, such as that provided by the health and load handler 314 (from Figure 3). As described above with reference to Figure 3, each main computer 108 hosts one or more 316 applications. The health and load handler 314 uses health and / or load information relating to applications 316 and / or main computers 108 for certain described network load balancing implementations.

Figure 10 illustrates an exemplary baseline approach

<img file="BRPI0402591B1_D0056.tif" />

• · · · · · * ··· · «• ····· ♦ ·» ···· • »ft ft ft« «·» «A» '

<img file="BRPI0402591B1_D0057.tif" />

network load launch that involves state information from the host computer (HSI) 1006. Each host computer 108 (1), 108 (2) ... 108 (n), includes one or more applications 316 (1), 316 ( 2), ... 316 (n), respectively. Generally, these main computers 108 and these applications 316 specifically, can change states from time to time.

For example, host computers 108 and applications 316 may be accepting new connections or may not be accepting new connections. In addition, they can quickly handle customer requests or slowly handle customer requests. Furthermore, they may have too many resources in reserve or too few unused resources. All data or any part of such data, or other data, may comprise status information from the main computer 1006. Generally, the status information of the main computer 1006 provides an indication of the status of some aspect of the main computers 108 and / or applications 316 running on them.

In a described implementation, each main computer 108 (1), 108 (2) ... 108 (n) includes a determiner

<img file="BRPI0402591B1_D0058.tif" />

main computer status information (HSI) 1002 (1), 1002 (2) ... 1002 (n), respectively. Each main computer 108 (1), 108 (2) ... 108 (n) also includes a main computer status spreader (HSI) 1004 (1), 1004 (2) ... 1004 (n), respectively. Each status information determiner of main computer 1002 and / or status information disseminator of main computer 1004 can be part of the balance25 infrastructure: ··

- - 10 is

<img file="BRPI0402591B1_D0059.tif" />

loading (LBI) 106.

Each main computer status determiner 1002 determines main computer status information 1006 for its respective main computer 108 and / or application 316 running on it. Exemplary techniques for determining such status information from main computer 1006 are described below with reference to Figures 12 to 14 and particularly, Figure 13A. Each state computer disseminator of main computer 1.004 disseminates state information from main computer 1006 to its respective main computer 108 and / or applications 316 to load balancing infrastructure 106 (for example, those parts of the load balancing 106 that are not located on main computers 108). Exemplary techniques for disseminating such status information from main computer 1006 are described below with reference to Figures 12 to 17 and, in particular, Figures 13B and 15-17.

Specifically, each main computer status spreader 1004 disseminates status information from main computer 1006 (directly or indirectly) to each load balancing unit (LBU) 106 of the load balancing infrastructure 106 that includes at least one health and cargo handler 314 and / or 304 classifier. The load balancing infrastructure 106 refers to the status information of the main computer 1006 when implementing network load balancing. For example, as indicated by logic 1008, in10

<img file="BRPI0402591B1_D0060.tif" />

f_frogload-balancing structure 106 is capable of making load-balancing decisions in response to status information from main computer 1006.

In operation in (1), the status information determinants of the main computer 1002 determine status information of the main computer 1006 for the respective main computers 108 and / or applications 316. In (1) and (2), the information disseminators status of main computer 1004 disseminate status information of main computer 100.6. from main computers 108 to load-balancing infrastructure 106. For example, status information from main computer 1006 can be disseminated to individual load balancing units 106. In (3), logic 1008 makes network load balancing decisions in response to status information from main computer 1006. In (4), the connections are forwarded to the 108 target computers based on these network load balancing decisions.

Figure 11 is a flow diagram 1100 that illustrates an exemplary method for balancing network load involving state information from the main computer. Flow diagram 1100 includes three blocks 1102-1106. Although the actions of the flow diagram 1100 can be performed in other environments and with a variety of software schemes, Figures 1 to 3 and 10 are used in particular to illustrate certain aspects and examples of the method.

In block 1102, status information from the main computer is sent from the main computers to

<img file="BRPI0402591B1_D0061.tif" />

<img file="BRPI0402591B1_D0062.tif" />

<img file="BRPI0402591B1_D0063.tif" />

load balancing units. For example, status information from host computer 1006 can be sent from host computers 108 to load balancing units 106. In block 1104, status information from the host computer is received from host computers in load balancing units. charge. For example, load balancing units 106 can receive status information from main computer 1006 from main computers 108. In block 1106, load balancing decisions - are made in response to received status information from the main computer. For example, logic 1008 on load balancing units 106 can make decisions for network load balancing in response to status information from main computer 1006.

Thus, in Figure 10, load-balancing infrastructure 106 collects state information from main computer 1006 from main computers 108 (and / or its applications 316) and incoming load balancing requests, which are directed to main computers 108 in response to status information from main computer 1006. As further described below with reference to Figures 12 to 18, this status information from main computer 1006 can be application specific. Also as further described below, examples of status information from main computer 1006 include health and / or load information.

Figure 12 illustrates an exemplary network load balancing approach that involves health information

<img file="BRPI0402591B1_D0064.tif" />

<img file="BRPI0402591B1_D0065.tif" />

<img file="BRPI0402591B1_D0066.tif" />

<img file="BRPI0402591B1_D0067.tif" />

and / or load (HLI) 1206. The main computers 108 (1), 108 (2) ... 108 (n) are coupled to the load balancing units 106 (1), 106 (2) ... 106 ( u) via a communication link 1210 such as a network.

As illustrated, main computers 108 communicate status information from main computer 1206 to load balancing units 106 using communication link 1210. Bidirectional communication of health and load information 1206, as indicated by the double-headed arrow, refers to a two-way communication from load-balancing units 106 to main computers 108, which provides a certain completeness, consistency , correction, etc., such that the main computers 108 and / or the load balancing units 106 can fail independently of each other. Such two-way communications from load balancing units 106 to main computers 108 are further described below with particular reference to Figure 15.

Health information reflects whether a given main computer and / or application is capable of handling customer requests. The load information reflects the number, quantity and / or level of customer requests that the given main computer and / or application is capable of handling at a particular time. In other words, the load can directly and / or inversely reflect a number, quantity and / or available level of total capacity of the given main computer and / or application. As noted above, implementations described with reference to Figures 12 to 18 focus on the

<img file="BRPI0402591B1_D0068.tif" />

<img file="BRPI0402591B1_D0069.tif" />

health and / or cargo information; however, those implementations are also applicable to general state information for the main computers (including their applications).

<img file="BRPI0402591B1_D0070.tif" />

In a described implementation, each main computer 108 (1), 108 (2) ... 108 (n) includes a respective component 1202 (1), 1202 (2) ... 1202 (n) of the health infrastructure and cargo (H&amp;LI). Each health and load infrastructure component 1202 can optionally be a part of load balancing infrastructure 106 that is resident and runs on each main computer 108. Health and load infrastructure 1206 can be performed on software. When working, each health and load infrastructure 1202 (1), 1202 (2) ... 1202 (n) creates and maintains a respective table 1204 (1), 1204 (2) ... 1204 (n) health and cargo (H&amp;L).

<img file="BRPI0402591B1_D0071.tif" />

These health and load tables 1204 can include application-specific entries. The health and cargo information 1206 that is stored in the health and cargo tables 1204 can be independent of the load balancing infrastructure 106. For example, administrators, designers, etc., can specify criteria for health information and load 1206 at the time of configuration. In addition, entities external to a device that is or has a main computer 108, can contribute to determining health and charge information 1206 for applications 316 on the device. An exemplary health and cargo table 1204 is further described below with reference to Figure 13A.

·· ··· ·· · ·· ·· ♦ · ♦ «* · · &lt;·« ·· · ♦ · ··· ♦ · · · · · · ··· »·· · · ··· · ··· ·· · ·· ···· ·· ft »···

<img file="BRPI0402591B1_D0072.tif" />

Each load balancing unit 106 (1), 106 (2) ... 106 (u) includes a respective consolidated cache 1208 (1), 1208 (2) ... 1208 (n) health and load (H&amp;L) . Each consolidated health and load cache 1208 includes information from each health and load table 1204 (1), 1204 (2) ... 1204 (n). Consequently, each load balancing unit 106 is provided with quick access (for example, with cache) to health and load information 1206 for each main computer 108 for which the load balancing units 106 are performing the load balancing of the network traffic.

In operation, health and cargo infrastructures 1202 push health and cargo information 1206 from health and cargo tables 1204 to consolidated health and cargo caches 1208. The mechanism for providing health and cargo information 1206 is triggered by event, such that changes in the health and load tables 1204 are provided to consolidated health and load caches 1208 in a timed, escalated manner.

<img file="BRPI0402591B1_D0073.tif" />

Figure 13A is an exemplary health and load table 1204, as shown in Figure 12. In an implementation described, health and load table 1204 includes multiple entries 1302 that are each associated with a different application 316. Each entry 1302 can correspond to a row in a health and load table 1204 that has three columns. These columns correspond to the application identifier (ID) 1302 (A), characterization of the application state 1302 (B) and the director of the

<img file="BRPI0402591B1_D0074.tif" />

<img file="BRPI0402591B1_D0075.tif" />

charge 1302 (C).

Because each entry 1302 is associated with a particular application 316, a line is added as each application is run (for example, by an administrator). Likewise, a line is deleted / removed each time an application is closed. Similarly, individual fields in columns 1302 (A), 1302 (B) and / or 1302 (C) are modified / updated when their value changes. For example, when a state characterization value changes for a given application 316, a value in an application state characterization field 1302 (A), 1302 (B) and 1302 (C) B) for data entry 1302 application 316, is updated.

Additions and deletions of entries 1302 for applications 316 can be performed with input from a control manager on main computer 108. For example, an operating system control part of the operating system knows when a 316 application is started and stopped because he is actively involved in starting and stopping 316 applications. Thus, a control manager can identify that he has started, at least in part, a 316 application and the control manager. it can establish that it has stopped, at least in part, application 316. Health and load infrastructure 1202 can therefore be informed of the start and stop of applications 316 by the control manager. Thus, no such explicit communication from applications 316 has to be provided to the health and load infrastructure 1202. An example of a control manager is the Service Control Manager (SCM) of the System

<img file="BRPI0402591B1_D0076.tif" />

·· ·· * ··· • · · · · · ···· · »« * • · · · ♦ Φ ···· · ·

<img file="BRPI0402591B1_D0077.tif" />

Windows® operating system from Microsoft® Corporation.

Application identifier 1302 (A) includes information that is used to uniquely identify application 316 with which entry 1302 is associated. Application identifier 1302 (A) can include one or more of the following for associated application 316: the virtual IP address and port, the physical IP address and port, the protocol used and any protocol-specific information. The protocol can be HTTP, IPsec, SOAP and so on. The protocol-specific information can be a pattern or URL stream to further delineate the application associated with entry 1302. Thus, application identifier 1302 (A) refers, more particularly, to a specific application endpoint on a main computer particular 108.

Other application identifiers can be used alternatively. For example, to reduce communication bandwidth, application identifier 1302 (A) can be a 32-bit number that maps the exemplary information above on health and load infrastructure 1202 and load balancing units 106 . Furthermore,

<img file="BRPI0402591B1_D0078.tif" />

any of the fields in entry 1302 can actually contain a globally unique identifier (9GUID) which is used as a key to search for the true information for the field.

The characterization of application state 1302 (B) includes information that reflects the state of application 316 with which entry 1302 is associated. Characterization of application state 1302 (B) includes the following for associated application 316: application health, application load and application capacity. Application health is an almost Boolean value that indicates whether an application is working. The health of the application can be healthy, deficient or unknown.

<img file="BRPI0402591B1_D0079.tif" />

<img file="BRPI0402591B1_D0080.tif" />

The health of the application is a relatively instantaneous value and is communicated with relatively low latency (for example, approximately one second or a few seconds) to the load balancing units 106 when the health value of the application changes.

- - - The application load is a value that indicates how busy a given application is and, thus, directly or inversely, how much additional load the given application can handle. The application load is a value that changes relatively slowly or is medium, and can be standardized with a hysteresis induction mechanism, if desired, to eliminate transient peaks of greater or lesser load. It is reported at relatively low frequency for load balancing units 106 (for example, approximately one to four times per minute). The value of the application load has a meaning with respect to the capacity of the application.

Application capacity is a value that indicates the maximum application capacity. It is selected in a generic way as being significant for a given context, but still flexible enough for other contexts. The capacity of the application is a limited number, without a unit (for example, 0 to 99) that can be determined at the time of configuration. It can be based on the power of

<img file="BRPI0402591B1_D0081.tif" />

1-0

<img file="BRPI0402591B1_D0082.tif" />

processing, memory size / speed, network access, some of these combinations, and so on. The application capacity expresses the relative capacities among other applications of the same type on a set of main computers 108 (1, 2 ... n).

Thus, with respect to the application's capacity, the application load takes on meaning. The application load for a given application is a percentage of the application's capacity for the given application. Alternatively, the application load can be expressed as a number without a unit from which the percentage can be determined in conjunction with the application's capacity value.

The load balancing director's directive 1302 (C) includes information that reflects the desired and / or expected state of the directive established by the health and load infrastructure 1202 for load balancing units 106 with respect to an application 316 while which entry 1302 is associated with. Load balancing director 1302 (0 includes the following for the associated 316 application: target load balancing state and status

<img file="BRPI0402591B1_D0083.tif" />

current load balancing.

The target load-balancing state reflects the policy status for load-balancing units 106, as desired by the health and load infrastructure 1202. The current load-balancing state reflects that the health and load infrastructure 1202 understands the current state of the directive for load balancing units 106 as being recorded in the load balancing units

<img file="BRPI0402591B1_D0084.tif" />

<img file="BRPI0402591B1_D0085.tif" />

<img file="BRPI0402591B1_D0086.tif" />

load 105. Thus, the current load balancing state reflects the load balancing directive under which health and load infrastructure 1202 expects load balancing units 106 to be currently operating, as dictated using a protocol of communication. Such an exemplary communication protocol is further described below with reference to Figure 15. The interaction and relationship between the target load-balancing state and the current load-balancing state is also further clarified with the description in Figure 15.

The target load balancing state and the current load balancing state can each have an active, inactive or draining value. An active policy indicates that new requests / connections are welcome and can be viewed in the application that is associated with entry 1302. An inactive policy indicates that no additional packages should be forwarded to the associated application. A drain policy indicates that no packets for new requests / connections should be sent to the associated application, but that packages for existing requests / connections should continue to be forwarded to the associated application.

In a described implementation, the final version of the respective health and load information 1206 is stored in the health and load tables 1204 that are located on each respective main computer 108 of the multiple main computers 108. With this implementation, if a main computer 108 breaks down , the health and cargo information 1206 that is lost belongs to those 316 applications that also

<img file="BRPI0402591B1_D0087.tif" />

• ·

999 ··· ·· · ·· ·♦

9« · 9 9 · 9 999

9 99 9999 9 9

999 9 9 9 9999 9 9 9

9999999

999 99 9 ·♦ 9999

<img file="BRPI0402591B1_D0088.tif" />

.... 10 well broke. A measure of high availability, therefore, is gained automatically without duplicating data. However, the final version of health and cargo information 1206 can be stored, alternatively, elsewhere. Other such storage options include load balancing units 106, a main computer 108 which (as its sole task or in conjunction with hosting tasks) stores and maintains health and load information 1206 for multiple other main computers 108 (including all others), another separate and / or external device, and so on.

If the definitive version of health and cargo information 1206 is stored and maintained elsewhere than being distributed by main computers 108 (1, 2, ... n), such health and cargo information 1206 can be stored redundantly (for example). example, also stored on a duplicate device, recorded, etc.) for high availability purposes. Exemplary proxy scenarios for storing health and cargo information 1206 are described below with reference to Figures 17A and 17B. Figure 17A is directed to a proxy scenario for health and load tables 1204 and Figure 17B is directed to a proxy scenario for consolidated health and load caches 1208.

Figure 13B is an exemplary consolidated health and load cache 1208, as illustrated in Figure 12. In an implementation described, each consolidated health and load cache 1208 in each load balancing unit 106 includes at least part of the information stored in each tab-

<img file="BRPI0402591B1_D0089.tif" />

<img file="BRPI0402591B1_D0090.tif" />

<img file="BRPI0402591B1_D0091.tif" />

health and load data 1204 for each health and load infrastructure 1202 on each main computer 108. Health and load information with cache can be organized in any way into the consolidated health and load cache 1208.

As illustrated, the consolidated health and load cache 1208 includes a cache for each main computer 108 (1), 108 (2) ... lQ8 (n) that replicates some or all of the information in the health and load table 1204 for each respective main computer (1, 2 ... n). Specifically, the consolidated health and load cache 1208 includes a cache for main computer # 1 1304 (1), a cache for the computer; main # 2 1304 (2) ... a cache for the main computer #n 1304 (n). Thus, the consolidated health and load cache 1208 illustrated is organized at a broad level by the main computer 108 (1, 2 ... n) with each individual cache 1304 including application specific entries for the respective main computer 108 ( 1, 2 ... n) corresponding.

Alternatively, the consolidated health and load cache 1208 can be organized at a broad level by the type of application 316, with individual blocks that are directed to a type.

<img file="BRPI0402591B1_D0092.tif" />

specific application type additionally divided by main computer 108 (1, 2 ... n). Other data structure formats can also be used.

Figure 14 is a flow diagram illustrating an exemplary method for balancing network load involving health and load information. Flow diagram 1400 includes eight blocks 1402 - 1416. Although actions on flow diagram 1400 can be performed in other environments and

4444 44 with a variety of software schemes, Figures 1 to 3 and 12 and 13B are used in particular to illustrate certain aspects and examples of the method. For example, the actions of two blocks 1402-1404 are performed by a main computer 108 and the actions of six blocks 1406-1416 are performed by a load balancing unit 106.

In block 1402, the health and load information on a main computer is determined. For example, health and cargo information 1206 for applications 316 (2) can be verified by health and cargo infrastructure 1202 (2) and stored in health and cargo table 1204 (2) on main computer 108 (2 ). In block 1404, health and load information is disseminated to load balancing units. For example, health and load infrastructure 1202 (2) can send health and load information 1206 to applications 316 (2) to load balancing units 106 (1), 106 (2) ... 106 (u). As indicated by arrow 1418, the actions of blocks 1402 and 1404 are repeated in such a way that the health and load (application) can be continuously monitored and updated as changes occur.

In block 1406, health and cargo information is received from the main computers. For example, load balancing unit 106 (1) can receive health and load information 1206 from multiple main computers 108 (1), 108 (2) ... 108 (n), including health and load information 1206 for applications 316 (2) from main computer 108 (2). In block 1408, health and cargo information

<img file="BRPI0402591B1_D0093.tif" />

··· ·*· ·· · ·· ·· ···· *· ·

<img file="BRPI0402591B1_D0094.tif" />

received is cached. For example, load balancing unit 106 (1) can store health and load information 1206 from main computers 108 (1), 108 (2) ... 108 (n) in consolidated health and load cache 1208 ( 1) . With reference to Figure 13B, implementation of a consolidated health and load cache 1208 (1), health and load information 1206 for applications 316 (2) on main computer 108 (2), can be cached for the main computer # 2 1304 (2). As indicated by the arrow 1420, the shares of blocks 14.06. and. 1408 are repeated in such a way that health and cargo information (application) can be continuously received and updated as changes occur.

As indicated by the dotted arrow 1422, load balancing units 106 also handle communications from customers 102 at the same time as they deal with health and load issues (application). In 'block 1410, a packet is received requesting a new connection. For example, load balancing unit 106 (1) can receive a TCP SYN packet from client 102 (2) over network 104. In block 1412, the health and load information with cache is queried. For example, load balancing unit 106 (1) can query the consolidated health and load cache 1208 (1). More particularly, the load balancing unit 106 (1) can query entries that are associated with the application to which the TCP SYN packet is directed via the caches to the main computers # 1, # 2 ... 3n 1304 (1, 2 ... n).

In block 1414, a main computer is selected

<img file="BRPI0402591B1_D0095.tif" />

<img file="BRPI0402591B1_D0096.tif" />

. 10

<img file="BRPI0402591B1_D0097.tif" />

<img file="BRPI0402591B1_D0098.tif" />

pal in response to health and load information with cache. For example, load balancing unit 106 (1) can select main computer 108 (2) that has application (s) 316 (2) in response to health and load information 1206 with consolidated cache for health and load 1208 (1). The selected application 316 (and main computer 108) must be healthy and capable of accepting additional load (for example, possibly the least loaded application among those applications that are. type application to which the TCP SYN-packet is directed). - -

<img file="BRPI0402591B1_D0099.tif" />

The query of the health and load information with cache (in block 1412) and the selection of the main computer in response to the health and load information with cache (in block 1414) can be carried out before receiving a specific package requesting a new connection and / or that uses a batch scheme. In addition, the selection can conform to any one of many schemes. For example, a card-based or round robin scheme can be employed. With one scheme or another, the selection may involve a weighting of relative loads between the application options. This consultation and selection, together with the forms based on the form and round robin, are further described below with reference to Figure 18 and in the section whose title is Classification, Shipping and Request Routing Exem25 piares, especially with regard to classification functionality.

After the target host computer is selected in block 1414, the packet requesting a new connection can • · · ··· «·» »* · ··· · · ·· * ··« · · ♦ · • · ··· &lt;«··· • ··· * · · ·· ···· ·· ··

<img file="BRPI0402591B1_D0100.tif" />

be sent to him. In block 1416, the package received from the customer is sent to the selected main computer. For example, the TCP SYN packet is sent from the load balancing unit 106 (1) to the selected main computer 108 (2). The shipment of this initial package can be made directly by a 304 classifier or by a 302 sender, as it is also described further in the section whose title is Exemplary Classification, Shipping and Request Routing.

<img file="BRPI0402591B1_D0101.tif" />

<img file="BRPI0402591B1_D0102.tif" />

For- an implementation- described, health and load infrastructure 1202 is resident in and distributed across multiple main computers 108, as well as located in load balancing units 106 (as represented by the health and load handler314). The health and cargo infrastructure of health and cargo 1202 has three responsibilities. First, it exposes listening point (s) to get application state updates to application state characterizations 1302 (B) from health and load tables 1204. Second, it synthesizes the application state information to determine what load-balancing units 106 must do, which is embodied in the load-balancing director 1302 (C) directive. Third, health and load infrastructure 1202 communicates this directive from main computers 108 to load balancing units 106.

load balancing director directive content 1302 (C) is effectively a compiled version of the information for application state characterizations ··· ··· ·· · ·· ·· ···· ·· · * ··· · ····· · · · • · · ···· · · ··· · · · * · · ···· · · · · · ··· • ········ · · • ··· · «· ·· ···· ·· ·· ·

<img file="BRPI0402591B1_D0103.tif" />

1302 (B). However, load balancing units 106 can also receive raw application state characterization information 1302 (B), as well as this processed directive. The communication of the content of these and other fields of health and cargo tables 1204 is achieved using a message protocol that is described below with reference to Figure 15.

A.Figure 15 illustrates an exemplary 1500 message protocol for communications related to the health and cargo information that are illustrated in Figure 12 among

<img file="BRPI0402591B1_D0104.tif" />

<img file="BRPI0402591B1_D0105.tif" />

main computers 108 and load balancing units 106. In general, an event-driven mechanism is used to push changes to health and load tables 1204 from main computers 108 to load balancing units 106. In in other words, for a described implementation, information is transmitted from the main computers 108 to the load balancing units 106 when the health and load tables 1204 are updated. This avoids periodically sending a snapshot of everything from each 1204 health and load table, which reduces network broadband consumption by the 1202 health and load infrastructure.

1500 message protocol can be implemented using any available message transport mechanism. Such mechanisms include reliable multicast transmission, point-to-point transmission (for example, user datagram protocol (UDO)) and so on. As illustrated, message protocol 1500 includes seven «« · ··· ·· · ·· ·· ···· ·· * • · · · ·· · ·· ·· · · ·· • · · »· · · · · ·· ♦ · · · · ··· · · «····· · · · ··· · • ········· ·· • ··· ·· · * · · ···· ·· ·· ··· message types 1502-1514: a heartbeat message 1502, a goodbye message 1504, a line break message 1506, an instant message from capture table 1508, a message instant shipping table

1510, a postulate table status message 1512 and a postulate error message 1514.

It should be understood that, with the exception of arrows 1516 and 1518, the illustration does not imply any temporal relationship between the different types of messages 1502-1514. For example

<img file="BRPI0402591B1_D0106.tif" />

T0 plo ^ a line change message 1506 does not typically follow a 1504 farewell message.

Heartbeat message 1502 indicates that a particular host computer 108 is functioning and provides some error checking for the contents of a corresponding private health and load table 1204 with respect to a corresponding private cache for private host computer 1304 in the consolidated cache health and cargo 1208. Each health and load infrastructure 1202 on each main computer 108 sends a heartbeat message directly or indirectly to each consolidated health and load cache 1208 on each load balancing unit 106.

Heartbeat messages 1502 address the problem of data aging in consolidated health and load caches 1208 which appears, in part, because a snapshot of the entire health and load table 1204 is not transmitted periodically to each balancing unit load 106. A transmission scheme · «· ··· ·· · ♦♦ ·· ···· ·· · •» · · · * * φ »· · · · · · · · t · · · · ♦ · · · · · · ··· «· · ♦ ···· ι« · »« »· •·········« · • · ♦ · ·· · · &lt;♦ «♦ · ·· · «· * · For heart rate messages 1502 is further described below with reference to Figure 16.

Heartbeat messages 1502 include an identifier for the main computer, error verification data, and optionally a DNS name. The main computer identifier can be a unique number (for example, 32 bits) that is selected at the time of configuration. The error check data can be a test sum, a state change sequence number, a generation number, a ~ “CRC; —etc. , —Which allows a load-balancing unit 106, upon receipt, to validate that the contents of its consolidated health and load cache 1208 behaves with the contents of the health and load table 1204 of the main computer 108 of transmission. If a number generation approach is employed, then multiple generation IDs can be used, with each generation ID assigned to a sample of applications. The messages can then refer to a sample number or a sample number / generation ID pair, depending on the context.

error check data can be a single value for health and load table 1204 or it can be multiple values ​​determined on a per-1302 entry basis. The DNS name can be optionally sent (for example, every x heartbeat) to check or update the current correct network address for the primary computer.

Goodbye message 1504 is sent from a particular host computer 108 to load balancing units 106 to indicate that the host computer

<img file="BRPI0402591B1_D0107.tif" />

«*« * 4 • 1 Μ * * · »* Φ * ·· ι« · ι «« * φ 4 ♦ ♦ «« «· · ·« * · * · # ·· «« φ 4 4 * ·· · ·· · ·· ···· «« «4 * 44

<img file="BRPI0402591B1_D0108.tif" />

particular 108 is planning to stop. The farewell message 1504 includes a host computer identifier that can be indexed / mapped to a network address for the particular host computer 108. The farewell message 1504 is used to clear intentional stops from the host computers 108 to precipitate rapid cleaning. However, if a goodbye message 1504 is lost, the caches eventually age outside the entrances of the main 108 private computers because heart rate messages 15ÜT2nãõ ~ ~ are no longer sent .......

The line change message 1506 is sent from a private main computer 108 to load balancing units 106 to indicate that the health and / or charge for a given application 316 of the private main computer 108 has changed. The line wrap message 1506 includes a main computer identifier, an application identifier, an operation, and data for the operation. Exemplary main computer identifiers are described below with respect to heartbeat messages 1502 and goodbye messages 1504, Exemplary application identifiers are above with respect to application identifier 1302 (A) of an entry associated with application 1302_ of health and load tables 1204.

The wrapping operation can be adding, deleting or updating. In other words, the data for the operation can be added to (for an addition operation) or a replacement for (for an update operation) information already present in the consolidated health caches

<img file="BRPI0402591B1_D0109.tif" />

• ······ • »· · and load 1208 in load balancing units 106. For a clearing operation, no data needs to be provided. Message protocol 1500 is defined in such a way that multiple operations can be stipulated to be performed for a single line-changing message 1506. Thus, for a particular host computer identifier, sets of an application identifier, operation, and operating data can be repeated for multiple applications 316 of host computer 108 which is identified by the particular host computer identifier .------- ------------___________ The capture table instant message 1508 is sent from a private load balancing unit 106 to a consolidated health and load cache 1208, for an individual main computer 108 or main computers 108. This capture table instant message 1508 requests that the health and load infrastructure 1202 on the main computers 108 provide a snapshot of the respective health and load table 1204 for the respective main computer 108. This message includes an identification of the requesting load balancing unit 106 and can be used by a load balancing unit 106: (i) after it has failed and then recovered; (ii) after a main computer fails, recover and start sending 1502 heartbeat messages again; (iii) if a line wrap message 1506 is sent to load balancing unit 106, but the message drops to a lower position, then its consolidated health and load cache 1208 is out

<img file="BRPI0402591B1_D0110.tif" />

synchronization with the respective health and load table 1204 for the respective main computer 108; and (iv) so on.

For the third (iii) situation, the lack of synchronization5 between the consolidated health and load cache 1208 and the respective health and load table 1204 for the respective main computer 108, is discovered by a subsequent heart beat message 1502 from the respective main computer 108 because error checking will indicate that the “10 consolidated health and load cache: 1208 — is— obsolete ^ —So, load balancing unit 106 can send an instant message from capture table 1508 such that its consolidated health and load cache 1208 can be updated. Thus, for any of the three exemplary situations (i, ii, iii) , load balancing unit 106 subsequently replenishes its consolidated health and load cache 1208 using snapshot of capture table 1508. The snapshot of capture table 1508 can be sent repeatedly to each main computer 108 in a point-to-point manner, or it can be sent once to many main computers 108 in a multicast way.

The sending table instant message 1510 is sent from an individual main computer 108 to a private load balancing unit 106 after main computer 108 has received an instant message from capture table 1508 of the private load balancing unit 106, as indicated by arrow 1516. The

<img file="BRPI0402591B1_D0111.tif" />

The contents of an instant message from the shipping table 1510 are prepared by the health and load infrastructure 1202 and include all or at least multiple lines from the health and load table 1204 of the individual main computer 108, such that the load balancing unit private 106 can rebuild its consolidated health and load 1208 cache. The capture table 1510 instant message can be a separately designed message or it can be equivalent to a sequence of addition operations in a line break message ___________________________________________

The postulate table status message 1512 and the wrong postulate table message 1514 are related to the target load-balancing state and the current load-balancing state of the load balancing director 1302 (C) of an entry 1302 in a health and load table 1204. The target load balancing state is the directive under which health and load infrastructure 1202 wants load balancing units 106 to be operating. 0 Current load-balancing state is the directive under which health and load infrastructure 1202 expects or believes that load-balancing units 106 are currently operating. In general, the two load-balancing states are identical.

However, the target load-balancing state may differ from the current load-balancing state during a transition period for a change of state policy. For example, the target load-balancing state and the current load-balancing state are both

<img file="BRPI0402591B1_D0112.tif" />

• ··· • 4 • · 4 ···· ♦♦ initially defined as active. A problem with main computer 108 and / or its application 316 is detected and the target load balancing policy is switched to drain. This drain directive is communicated to load balancing units 106 using a line change message 1506.

A period of time elapses before this policy change is noticed in all consolidated health and load caches 1208 of all load balancing units

ΤΟ 106T During this transition period, _the target load balancing state is draining while the current load balancing state 4 is still active in the health and load table 1204 on main computer 108. Before changing the load balancing state current drain load, the

<img file="BRPI0402591B1_D0113.tif" />

health and cargo infrastructure 1202 wants to ensure that consolidated health and cargo caches 1208 have been updated to the new drain policy state.

To verify that the consolidated health and load caches 1208 of the load balancing units 106 were updated to a new state policy, the health and load infrastructure 1202 sends a postulate table status message 1512 to the balancing units. load 106. Postulate table status message 1512 is sent some time after (for example, a predetermined delay period) a line change message 1506 is transmitted, indicating that the state directive must be changed. The postulate table status message 1512, in this example, indicates that the table state must be ♦ ♦ · ♦ ♦ · »&gt; · ··

<img file="BRPI0402591B1_D0114.tif" />

drainage. As indicated by the dotted arrow 1518, a load balancing unit 106 responds to this postulate table status message 1512 if its consolidated health and load cache 1208 differs from the postulate state directive.

If the policy in the consolidated health and load cache 1208 differs from the postulate state policy, then that load-balancing unit 106 sends an erroneous postulate 1514 message to the infrastructure of sa10_ _ úde_e_ çarga_ .12,02. _of -computer -main- -108- which - issued^_the “postulate table status message 1512. This health and load infrastructure 1202 then periodically sends postulate table status message 1512 again until no other postulate error messages 1514 are received from consolidated health caches and load 1208. At that point, the health and load infrastructure 1202 sends a line change message 1506 with the new current load balancing state. In this sense, consolidated health and load caches 1208 are the definitive determinants of the current load-balancing state and health and load infrastructure 1202 is the definitive determiner of the target load-balancing state.

Figure 16 illustrates an exemplary message transmission scheme for the communications that are illustrated in

Figure 12 between main computers 108 and load balancing units 106. The exemplary message transmission scheme can reduce the bandwidth consumed by heartbeat messages 1502 on the communication link.

<img file="BRPI0402591B1_D0115.tif" />

.1.,

<img file="BRPI0402591B1_D0116.tif" />

::. : r ······ · communication 1210. The message transmission scheme of Figure 16 is particularly adapted for heartbeat messages 1502, but can also be used for other message protocol messages 1500.

A group of main computers 108 ¢ 1),

108 (2), 108 (3) ... 108 (11) and 108 (12) are illustrated together with the load balancing units 106 (1), 106 (2) ...

. 106 (u). Each line represents link or inclusion of the member among the group of main computers 108 (1, 2 ... 12). The group^-de — computers -pr-i-ncipa-is- -1-08 (1, 2, --------— 12) —ma form an association of nodes that work together to propagate heart rate information to the units load balancing 106. Although twelve main computers are shown, they can more or less be part of any given group of main computers. In addition, a total set of main computers 108 being served by a load-balancing infrastructure 106, can be divided into one, two, three or more groups of main computers.

In an implementation described, the association of nodes for the main computer group 108 (1, 2 ... 12) elects a leader who is responsible for transmitting heartbeat messages 1502 to the load balancing units 106. Each main computer (other than leader)

108 in the main computer group 108 (1, 2 ... 12), it sends its 1502 heartbeat messages to the elected leader. The main computer 108 (4) is the chosen leader in this example.

: · '· • V • · * ♦ * · · ♦ ·· · · »·· ♦ * · ri I · ·« · ···· «·« «· • ·· · ·· ·» · « ·&gt; * ·

With the association of nodes, the heart rate information for each main computer 108 in the group of main computers 108 (1, 2 ... 12) propagates to the main computer 108 (4) leader of the group. The main computer 108 (4) collects the heartbeat information and consolidates it into a consolidated heartbeat message 1602. The consolidated heartbeat messages 1602 (1), 1602 (2) ... 1602 (u) are then sent to the respective load balancing units 106 (1), 106 (2)

Γ0^_ 106 (u). These 1602 consolidated heart rate messages can optionally be compressed to further reduce bandwidth consumption.

As another alternative, the leading main computer 108 (4) can only refer changes in group membership 15 to consolidated health and load caches 1208. In other words, in this mode, consolidated health and load caches 1208 deal mainly, if not only, with changes of state in the association. It is the responsibility of the leading host computer 108 (4) to ensure that the first greeting is sent when a host computer 108 goes online and that a goodbye message 1504 is sent when that host computer 108 goes offline. In addition, a main computer 108 may periodically specify that a heartbeat message 1502 should be remitted25. This gives indication to the main computer leader 108 (4) to send it to the consolidated health and load caches 1208, even if it does not represent a change in the association.

99« 9« 9 99 99 9999 99 • 9 9 9 9 9 9 9 9 999 9 9

<img file="BRPI0402591B1_D0117.tif" />

Heart rate messages 1502 (including consolidated heart rate messages 1602) are used by load balancing units 106 when their consolidated health and load caches 1208 are not synchronized with health and load tables 1204. This lack of synchronization can arise, for example, from a block or other failure of the consolidated health and load cache 1208 e / oü of the load balancing unit 106. As described above, each heartbeat message 1502 includes error-check data_.which_ can be used to check the equivalence between a consolidated health and load cache 1208 and health and load tables 1204. If equivalence is not found with With respect to a particular host computer 108 and / or its application 316, the DNS name of the host computer 108 is acquired from heart rate messages 1502.

The DNS name is used by the consolidated health and load cache 1208 to send a capture table instant message 1508 to the private host computer 108 in order to obtain updated health and load information 1206 in the form of a send table instant message. 1510. The same or different capture table instant message 1508 is sent to each main computer 108 for which non-equivalence has been discovered. Eventually, the health and load information 1206 in the consolidated health and load cache 1208 is equivalent to the health and load information 1206 in the health and load tables 1204, as can be verified by the new heart beat messages.

<img file="BRPI0402591B1_D0118.tif" />

·· · «« «··« · · · · 4 ··· * · «&lt;· ϊ ·.

diaco 1502. In this way, a consolidated fail health and load cache 1208 can return to operation without manual supervision using message protocol 1500 and an equivalence check scheme.

Figure 17A and Figure 17B illustrate exemplary health and load information proxy storage scenarios for health and load tables 1204 and for consolidated health and load caches 1208, respectively. In the implementations described above with reference to Figures 12 to —16, the —main — computers —108 — include health and load infrastructure 1202. However, other implementations may entail core computers that do not include health and cargo infrastructure 1202 .

For example, a main computer may be running an application version (s) and / or an operating system for which the health and cargo infrastructure is not implemented or for reasons of guidelines, it may not be installed on the main computer. Consequently, these types of main computers do not have health infrastructure and load 1202 running on them. The main computer 1702 is a main computer that does not run the health and load infrastructure 1202. However, main computer 1702 can use a health and load infrastructure 1202 that is running on one or more proxies, such as proxy 1704.

proxy 1704 has, residing in and running on it, a health and load infrastructure 1202, which includes a health and load table 1204. The main computer

<img file="BRPI0402591B1_D0119.tif" />

<img file="BRPI0402591B1_D0120.tif" />

pal 1702 can use health and load infrastructure functionality 1202 by providing health and load information 1206 to health and load table 1204 for applications running on main computer 1702. Alternatively, proxy 1704 can deduct health and load on main computer 1702 by performing external monitoring actions. Proxy 1704 is illustrated as proxy 1704 (1) and 1704 (2) for redundancy and resulting high availability.

<img file="BRPI0402591B1_D0121.tif" />

___In _implementations- described- ac-ima- -with -reference^- to Figures 12 to 16, and below with reference to Figure 18, load balancing is performed with load balancing units 106 that include consolidated health and load caches 1208. However, other implementations may entail load balancing that does not include consolidated health and cargo caches 1208.

For example, load balancing can be done by monolithic load balancing hardware or other load balancing infrastructure that does not store and / or cannot store or in any way include a consolidated 1208 health and load cache. 0 load balancing 1706 reflects such a device or load balancing devices that do not have a consolidated health and load cache 1208. However, load balancer 1706 can use a consolidated health and load cache 1208 that exists on one or more proxies, such as proxy 1708.

Proxy 1708 includes a consolidated health cache

<img file="BRPI0402591B1_D0122.tif" />

and load 1208, which stores health and load information 1206 for applications that are serviced by load balancer 1706. Load balancer 1706 can use health and load information 12 06 from the consolidated health and load cache 1208 when executing the load balancing functions when accessing such information using native application programming interfaces (APIs) and supported by the 1706 load balancing realizer. Alternatively, the consolidated health and load cache 1208 can invoke APIs to push health and load information 1206, including directives, to the load balancer 1706. Proxy 1708 is illustrated as proxy 1708 (1) and 1708 (2) for redundancy and the resulting high availability.

Figure 18 illustrates an exemplary target application endpoint allocation procedure that involves a classifier 304 and a health and load handler 314 from a load balancing unit 106. After the health and load handler 314 has purchased a consolidated health and load cache 1208, your health and load information 1206 is used in the selection of application endpoints for new requests / connections.

As described above with reference to Figure 13B, the consolidated health and load cache 1208 includes health and load information with cache 1206 for multiple primary computers 108. To facilitate the creation and update of the consolidated health and load cache 1208 from the health and cargo information 1206 from multiple

<img file="BRPI0402591B1_D0123.tif" />

· ♦

<img file="BRPI0402591B1_D0124.tif" />

main computers 108, health and charge information 1206 is organized in such a way that it can be accessed by the identifier of each main computer 108. However, health and charge information 1206 is also organized in such a way that it can be accessed by application type

316 in order to facilitate the selection of the application end point.

In other words, the health and cargo handler

314 is able to access health and cargo information 1206 on a — basis per application 3l-6_for health and cargo information___

1206 for multiple main computers 108. Once the health and load information 1206 for a given application 316 has been accessed for each main computer 108, the allocation of incoming connection requests can be performed according to that health and load information 1206. For example, possible end points for the given 316 application can be allocated for connection requests that arrive by selecting the end points of the given 316 application, taking into account the relative load capacity available between the healthy end points for the given application 316.

In a described implementation, classifier 304 makes a 1802 request for the target application endpoint allocation to the health and load handler 314. As illustrated, the 1802 target application endpoint allocation request includes (i) an address Virtual IP and port, (ii) a protocol, and (iii) protocol-specific information. Therefore, the 1802 endpoint allocation request ·· ··· ·· · · * ·· «· ·· • · · · · · · · • ····· * ·» • * · · · · · • ·· · ·· · «·· application identifies an application type 316 to which incoming connection requests are directed.

The health and load handler 314 receives a 1802 application endpoint allocation request and selects at least one physical endpoint corresponding to the identified type of application 316 using any one or more of many selection mechanisms. To reduce latency, the health and load handler 314 selects an application endpoint allocation for use in a series of

10— sol-rcitations-of connection — that arrives. This allocation is provided from the health and load handler 314 to the classifier 304 using target application endpoint allocation response 1804. As illustrated, the target application endpoint allocation response 1804 includes an allocation of physical IP addresses and ports (such as IP1, IP2, and IP3 endpoints) for the identified application type 316.

The allocation for the target application 1804 endpoint allocation response can be completed using one or more allocation schemes. As an example, a 1806 card allocation scheme and a 1808 percentage allocation scheme are illustrated. The card allocation scheme 1806 is a unit-based allocation scheme and the percentage allocation scheme 1808 is a time-based allocation scheme.

The 1806 token allocation scheme allocates tokens for each healthy endpoint IP1, IP2 and IP3, in response to their relative ratios and load and capacity. For example, as illustrated, of the total available capacity, IP1 has

<img file="BRPI0402591B1_D0125.tif" />

4 4444 ·4 • 4 4 4 4 * 4 4 4 · 4 4 4 44 • 4 4 4 4 4*4 · 4 4· 4 · 4 4

444 φ φ φΦΦ4Φφ 4 4 4 Φ4Φ *

44 4 44 44 4 4 44

444 44 4 ΦΦ 4444 44 44 444

40% of available capacity, ΙΡ2 has 35 of available capacity and IP3 has 25% of available capacity. Thus, the total number of chips is divided according to these percentages. The total number of tokens can be provided as part of the target application 1802 allocation request or determined by the health and load handler 314.

Any value for the total number of chips can be used, such as 10, 45, 100, 250, 637, 1000 and so on. This value can be set depending on the number of connection requests per second and the speed / frequency at which the health and / or load of the application is changing. Classifier 304 uses / consumes a token when responding to each connection request via an application endpoint allocation, until the tokens run out; then, classifier 304 requests another token allocation using the target application endpoint allocation request 1802.

The 1808 percentage allocation scheme determines the relative capacity available in a similar way. However, instead of tokens, these available relative capacities determined by application endpoint are provided to the 304 classifier along with an 1810 duration timer. 0 classifier 304 allocates target application endpoints for incoming connection requests, according to these percentages of relative capacity available until the 1810 duration timer expires.

For the 1808 percentage allocation scheme, the

<img file="BRPI0402591B1_D0126.tif" />

• · ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・»· · ·« · »· ♦ ···· ·· ·· · classifier 304 keeps track of the execution of application endpoint allocations to adhere to the allocated percentages and keeps track of the time for the 1810 duration timer. time expires, classifier 304 so5 then bids another percentage allocation using target application endpoint allocation request 1802.

It should be noted that the 1806 token allocation scheme can also use a time limit. If the allocated chips are too old, they must be discarded and noT0 new — chips — must be purchased. On the other hand, the 304 classifier can consume aged tokens that were previously allocated based on health and load information that is currently very out of date. The use of application endpoint allocations by classifier 304 is further described in the section whose title is Exemplary Classification, Shipping and Request Routing.

Exemplary Session Tracking

This section describes how main computer status information, such as session information, can be collected and used for network load balancing. This section refers mainly to Figures 19 to 24 and clarifies the session affinity preservation functionality, such as that provided by the session tracker 308 (from Figure 3). As described above with reference to

Figures 1 to 3, each main computer 108 houses one or more applications 316 that provide service (s) to customers 102.

session tracker 308 uses session information that relates to contexts for the connections established between

<img file="BRPI0402591B1_D0127.tif" />

·· * · * · ·· «·· ·· ♦ ··· • · ·· · * ··· ·· · · · ··· · · ··· · * · ·· ····· · · * · • «« ······· • ·· «·« · ·· ·· * »· among applications 316 and clients 102 for certain described implementations of network load balancing.

Figure 19 illustrates an exemplary load balancing approach that involves session information 1902. On connection [1], client 102 (1) is shown making a new connection to the main computer 108 (2) via infrastructure. load balancing 106. The load balancing infrastructure 106 can comprise one or more load balancing units 106. When the “connection arrives to us” load balancing infrastructure

<img file="BRPI0402591B1_D0128.tif" />

ga 106, the request is typically routed to a host computer 108 that uses network load balancing functionality in response to health and / or load information from host computers 108 and / or their applications 316 (not shown explicitly in Figure 190.

When connection [1] is made, a session is established between client 102 (1) and service application 316, which, in this example, is on main computer 108 (2). The session provides a context for the communication exchange between the client 102 (1) and the main computer 108 (2). Information for the session context is stored on main computer 108 (2). When connection [1] is completed, the session context cannot be used again. On the other hand, the session context can be useful again if client 102 (1) tries to initiate another connection to the computers. main users 108 for the service provided by the application 316. If this other connection is not routed to the same main computer 108 (2) that stores that &lt;7Q ··· ··· ·· · ·· ·· ···· ·· / 27 · ····· · ·· ·· · ·· • · ·· ···· · ···· · · ··· · · ······ · · ···

(. · · · • ··· ·· text of the session, then the client 102 (1) a new context of the session, which can an intensive processing of data and / or for the human user of the client 102 (1). network load based on health and / or load information, there is no greater probability than the random chance that the second connection will be routed to 108 (2).

However, if load-balancing infrastructure 106 has access to a mapping between session information^{- _}is ~ ^_computers - main _ 10_8_L the _ load balancing infrastructure 106 can route connection requests that relate to previously established sessions to the appropriate host computer 108. Some session information can be inferred from the content of packets that flow through the load-balancing infrastructure 106. However, this approach is inaccurate and accidental for a number of reasons. First, the establishment and termination of the session are merely inferred. Second, some sessions are not officially ended with an appropriate statement that is included in a package. For example, some sessions are simply interrupted. Third, the packets being transmitted from the main computer 108 (2.) To the client 102 (1), can take a path that does not include load-balancing infrastructure 106, which prevents any spying of such packets. load balancing infrastructure 106 for session information.

As shown in Figure 19, computers have to establish time consuming, having can be frustrating • · * «·· '• · ·' • · · · main 108 provide session information (SI) 1902 for the balancing infrastructure load 106. Using session information 1902 from main computers 108, a session affinity preservator 1904 can preserve the affinity between an established session and the main computer 108 on which the session was established. Session information 1902 includes a link between or a mapping from each session established between a client 102 and a particular main computer 108 to that "principal-particular computer. 108 ^ _This_mapping is accessible to the 1904 session affinity preservative as part of the session information mapping of the 1906 main computer. More specific examples of 1902 session information are provided below with reference to the Figures

20, 22, 23A and 23B.

In certain implementations described for session tracking, the logical nature of clients 102 is pertinent. As noted above with reference to Figure 1, a client 102 can be a specific device and / or a specific user of a device. Consequently, the session affinity for a client user 102 who is accessing the main computers 108 from different devices can still be preserved. Session continuations using session information 1902 can, therefore, still be performed in proxy scenarios (for example,

- those of some Internet service providers (ISPs)).

Continuing with the connection example [1], the session

<img file="BRPI0402591B1_D0129.tif" />

established on the main computer 108 (2) is provided to the load balancing infrastructure 106 as session information 1902. Specifically, a link / mapping between (i) the client session context 102 (1) and main computer 108 (2) and (ii) an identifier for main computer 108 (2) is created in the session information mapping of main computer 1906. When a connection request for connection [2] subsequently arrives in the same context as the session, the ses10 affinity preserver^— they are — 1904 —local-i-za- this — context- of session_no_ session information mapping of main computer 1906 and find out which main computer 108 (2) is associated with this session context from connection / mapping.

In response to the host computer mapping

108 (2) for the requested session context, as verified by the affinity preservative of session 1904 of the session information mapping of the main computer 1906, the connection [2] is routed to the main computer 108 (2). In this sense, preserving session affinity is a higher priority for the load balancing infrastructure 106 than network load balancing decisions based on application health and load. However, health and / or load can be a more important network load balancing factor than session tracking when, for example, the load is extremely heavy or when the relevant session and / or main computer applications are on a fault condition.

Many types of connections can be related to

<img file="BRPI0402591B1_D0130.tif" />

·· · ·· ·· ···· ·· • ·· · ·· ·· · • ···· · ····· • ······ · · ··· • · ···· ·· ·· · ·· ···· · · · ·

---- -10

<img file="BRPI0402591B1_D0131.tif" />

session. Examples include: a TCP connection, a transport layer security (TSL) / SSL session, a PPTP session, an IPSec / L2TP session, an ISA session, an HTTP cookie-based session, a Terminal Server session, a defined session by the administrator, and so on. For the sake of clarity, a TCP connection is considered to be a TCP packet session. In addition, a template for defining sessions by an administrator can be enumerated and supported. In addition, sessions based on client IP addresses that — are -delined-by_ interrupts, can also be supported. This is a relatively unintelligent session support, but is expected by some users.

A connection request from a client 102 varies by the type of session desired. For example, for TCP connection type sessions, the connection request comprises a TCP packet. For SSL session type sessions, the connection request comprises a TCP connection. Other such connection requests correspond to other types of sessions. These examples also show how there can be session layers. At a lower session level, a session context for a TCP connection can include a 4-tuple TCP, a session number, the number of bytes sent / received, and so on. At a higher session level, a session context for an SSL session can include a 32-byte session ID, a client public key 102 that is provided to host computer 108, and so on.

Figure 20 illustrates an exemplary network load balancing approach that involves communicating information

<img file="BRPI0402591B1_D0132.tif" />

• · · · ·

<img file="BRPI0402591B1_D0133.tif" />

session using 2006 notifications and 2008 messages. Multiple load balancing units 106 (1), 106 (2) ... 106 (u) and multiple main computers 108 (1), 108 (2) ... 108 (n ) They are shown. Each respective main computer 108 (1), 108 (2) ... 108 (n) includes one or more respective applications 316 (1), 316 (2) ... 316 (n) that are resident and run there. 2006 notifications are used to provide session information from applications 316 and 2008 messages are used to provide information from. session from main computers 108 to load balancing units 106.

As illustrated, each respective main computer 108 (1), 108 (2) ... 108 (n) includes respective session tracking infrastructure (STI) 2002 (1), 2002 (2) ... 2002 (n). Each respective session tracking infrastructure 2002 (1), 2002 (2) ... 2002 (n) includes a respective session table 2014 (1), 2014 (2) ... 2014 (n) (although only the 2014 session table (1) is illustrated explicitly in Figure 19).

Each respective load balancing unit 106 (1), 106 (2) ... 106 (u) includes respective traffic routing functionality (TRF) 2012 (1), 2012 (2) ... 2012 (u).

The 2012 traffic routing functionality may comprise, for example, classification and / or request routing functionality, such as that provided by classifier 304 and request router 306, respectively. Distributed by load balancing units 106 (1), 106 (2) ... 106 (u) is a tracking manager for • ···· · • · ♦ · distributed session 2010.

In an implementation described, the traffic routing functionality 2012 and the distributed session tracking manager 2010 are part of the load balancing infrastructure 106. The 2002 session tracking infrastructure can also be a part (for example , remote) of load balancing infrastructure 106.

A 2004 API is employed to provide session information from 316 applications to the 2002 session tracking infrastructure. Using API, 316 applications have the power to notify the 2002 session tracking infrastructure of session information, including various changes in it. More specifically, each 316 application is capable of providing and the 2002 session tracking infrastructure is capable of 'accepting 2006 notifications.

A notification that a session has been established (or notification of session establishment 2006 (E)) is provided from application 316 when a session has just been established or opened. The 2006 session establishment notification (E) includes a session identifier and optionally, a 316 application identifier. A notification that a session has ended (or 2006 session termination notification (T)) is provided from the 316 application when a session is ended or closed. The 2006 session termination notification (T) also includes the session identifier and, optionally, the 316 application identifier.

When the session tracking infrastructure

<img file="BRPI0402591B1_D0134.tif" />

• ·· ··· «·« ·· ·· ···· ·· · «· a · aa aa aa aaa aa aaa * aa aaa · · aaa aaaaaa aaa« ♦ · a ········ ·· ·· ··· * · · ·············

2002 accepts a 2006 session establishment notification (E), it inserts an entry in the 2014 session table for the new session. An example session table 2014 is further described below with reference to Figure 23A. When the 2002 session tracking infrastructure accepts a 2006 session termination notification (T), it removes the entry in the 2014 session table for the old session.

The 2014 session table (1) is the source of authority for 1902 session information with respect to 316 applications (D “computer node^-main— 10 8 (1). However, it generates too much latency to require the traffic routing functionality 2012 to contact the main computers 108 to access the 2014 session tables when receiving each connection request that arrives having a reference of session. Session information 1902, therefore, is cached in load balancing units 106.

In load balancing units 106, 2010 distributed session tracking manager caches 1902 session information as part of its session tracking management responsibilities. In general, the distributed session tracking manager 2010 is a distributed application and / or virtual service that partially resides on each load balancing unit 106. For each logical session, the distributed session tracking manager 2010 maintains at least one cached copy of session information, in a reliable and scalable way that can be quickly used for traffic routing.

<img file="BRPI0402591B1_D0135.tif" />

ΤΟ traffic as incoming connection requests, which have a session reference, are received by the load balancing infrastructure 106.

Communications between main computers 108 and load balancing units 106 are carried out with a reliable protocol that ensures that messages 2008 sent from a main computer 108 arrive at the desired load balancing unit 106. Each main computer 108 is connected to a specific load balancing unit "Γ06" which "is ^ the unit^- from baTancea-^-

<img file="BRPI0402591B1_D0136.tif" />

target load 106 for 2008 messages. This connection is created by assigning an IP address of a specific load balancing unit 106 to each main computer 108 to send 2008 session tracking messages across the infrastructure. session tracking 2002 and the distributed session tracking manager 2010. To facilitate the high availability of the load balancing infrastructure 106, if one load balancing unit 106 fails, another load balancing unit 106 assumes the IP address of the failed load balancing unit 106. Failure detection by assuming the IP address can be achieved using a heart rate monitoring scheme or another activity monitoring scheme.

Thus, the 2008 messages communicate session information 1902 from the 2002 session tracking infrastructure with the distributed session tracking manager 2010. For example, when the tracking infrastructure ··· ··· ·· · ·· ·· ♦♦ ·· ·· • · · «· * ·« ···· · · · ·· «· · · · ♦ ···· · · · ··· · • ········· · · • ··· ·· · ·· ♦ ··· ·· ·· ··· session 2002 accepts one 2006 session establishment notification (E), it also sends a session establishment 2008 (U) message to the 2010 distributed session tracking manager. The 2008 session establishment message (U) includes the session identifier, a main computer identifier and optionally, other information. The content for a session establishment message 2008 (U) is further described below with reference to Figure 23B with respect to the information that can be stored for each section _p_o_r_ an implementation-of-distributed session tracking manager 2010. When the 2002 session tracking infrastructure accepts a 2006 session termination notification (T), it also sends a 2008 session termination message (D) to the distributed session tracking manager 2010. 2008 messages can be sent before , during or after the 2002 session tracking infrastructure appropriately modifies the 2014 session table in response to 2006 notifications.

Figure 21 is a flow diagram 2100 that illustrates an exemplary method for network load balancing that involves communicating session information using notifications and messages. The flow diagram 2100 includes fifteen blocks 2102 - 2130. Although the actions of flow diagram 2100 can be performed in other environments and with a variety of software schemes, Figures 1 to 3 and 18 and 20 are used in particular to illustrate certain aspects and examples of the method.

:··

For example, the actions of four blocks 2102-2104 and 2118-2120 are performed by an application 316, the actions of six blocks 2106 - 2110 and 2122 - 2126, are performed by the 2002 session tracking infrastructure and the actions of five blocks 2112 - 2116 and 2128 - 2130 are performed by a distributed session tracking manager 2010. The actions of eight of these blocks 2102-2116 are mainly directed to the opening of a session, and the actions of seven of these blocks 2118 - 2130 are mainly directed to the closing of a session .-- In block 2102, a session is opened. For example, application 316 can open a session with a client 102. In block 2104, a session establishment notification is provided. For example, the 316 application can provide a 2006 session establishment notification (E) to the 2002 session tracking infrastructure using API 2004 as a consequence of and / or in conjunction with the session opening.

In block 2106, the session establishment notification is accepted. For example, the 2002 session tracking infrastructure can accept the session establishment notification 2006 (E) from application 316 according to API 2004. In block 2108, an entry is inserted in a session table. For example, the 2002 session tracking infrastructure can insert an entry in the 2014 session table for the open session. Examples of such an insertion are further described below especially with reference to Figure 23A. In block 2110, an establishment message is sent

<img file="BRPI0402591B1_D0137.tif" />

<img file="BRPI0402591B1_D0138.tif" />

session setting. For example, the 2002 session tracking infrastructure can send a session establishment 2008 (U) message to the distributed session tracking manager 2010 using a trusted communication protocol.

In block 2112, the message of establishment of

<img file="BRPI0402591B1_D0139.tif" />

session is received. For example, the distributed session tracking manager 2010 can receive session establishment message 2008 (U) from the session tracking infrastructure 2Õ02 agree^-with reliable protoeo-communication. In block 2114, a session information entry is created. For example, the distributed session tracking manager 2010 can create a session information entry for 1902 session information cached in one or more 106 load balancing units. Examples of such creation and subsequent addition are further described below especially with reference to Figures 22 and 23B.

In block 2116, network traffic is routed with session information. For example, the 2012 traffic routing functionality, in conjunction with the distributed session tracking manager 2010, can use cached 1902 session information, including the created session information entry, to route connection requests that arrive that have a session reference. An example of such traffic routing is further described below especially with reference to Figure 24. Additional examples are described below in the section whose title is Exemplary Classification, Shipping and Request Routing.

QQ * ·· ·· · ·· * ♦ · · ♦ · · · · ··· · a&gt; ·· «·· &lt;

• ···· ♦ · • · t »· · · · · ♦ ··· · *« • · · ··· · · ♦ · • · * · * • a »t« 9 · ···

In block 2118, the session is closed. For example, application 316 can close the session with client 102. At block 2120, a session termination notification is provided. For example, the 316 application can provide a 2006 session termination (T) notification to the 2002 session tracking infrastructure using API 2004 as a consequence of and / or in conjunction with the session close.

At block 2122, session termination notification is accepted. For example, the data tracking infrastructure

Session LÕ 2002 can accept — the notification — of session termination 2006 (T) from application 316 according to API 2004. In block 2124, the entry in the session table is removed. For example, the 2002 session tracking infrastructure can remove the 2014 session table entry for the closed session. In block 2126, a session termination message is sent. For example, the 2002 session tracking infrastructure can send a 2008 session termination message (D) to the distributed session tracking manager 2010 using the trusted communication protocol.

At block 2128, the session termination message is received. For example, the distributed session tracking manager 2010 can receive the ses_ são 2008 (D) end message from the 2002 session tracking infrastructure according to the trusted communication protocol. In block 2130, the session information entry is destroyed. For example, the distributed session tracking manager 2010 can destroy the entry of session information in the 1902 session information cached in any database unit.

<img file="BRPI0402591B1_D0140.tif" />

<img file="BRPI0402591B1_D0141.tif" />

• · · • ····

<img file="BRPI0402591B1_D0142.tif" />

load launch 106 that has the information input d_and session. Examples of such destruction and subsequent removal are further described below especially with reference to Figures 22 and 23B,

Figure 22 illustrates an exemplary approach to

<img file="BRPI0402591B1_D0143.tif" />

manage session information on multiple load balancing units 106. Each respective load balancing unit 106 (1), 106 (2) ... 106 (u) includes a respective part 2202 (1), 2202 (2). .. 2202 (u) of a distributed atom manager ^_(DAM) “~ 2202 ~. ~ Q ~ DAM- 2202 -is_ an exemplary implementation of distributed session tracking manager 2010. Each respective DAM part 2202 (1), 2202 (2) ... 2202 (u) includes a respective part 2206 (1), 2206 (2) ... 2206 (u) of a DAM table (DAMT) 2206.

DAM 2202 is a distributed application or virtual service that manages 1902 session information in a reliable and scalable manner, such that the 2012 traffic routing functionality can use it to preserve session affinity. For example, the 'traffic 2012 routing functionality can access DAM 2202 using an API (not shown specifically) to search for or have searched for DAMT 2206. Function calls 2204, DAM operation 2202 and other aspects of Figure 22 are further described below after the description of Figures 23A and 23B.

Figure 23A is an example session table 2014, as illustrated in Figure 20. The session table 2014 includes “v entries 2302 (1), 2302 (2) ... 2302 (v). Each entry

2302 is inserted by the ses93 tracking infrastructure * · · • · t · ♦ · • · · * · • · * · · • ··· · · ♦ · • ♦ ·· are 2002 in response to a notification of 2006 (E) session establishment that is accepted from a 316 application. Each 2302 entry is removed by the 2002 session tracking infrastructure in response to a 2006 (T) session termination notification, which is accepted from the 316 application.

As described above, each 2006 session establishment notification (E) includes a session identifier and optionally, a 316 application identifier. Each respective entry 2302 (1), 2302 (2) ... 2302 (v) in table 1- 0- session 2014 includes the respective fields of (i) session identifier 2302 (11), 2302 (21) ... 2302 (vi) and (ii) session type and / or application 2302 (1Q), 2302 ( 2T) ...

2302 (vT).

The session type and / or application 2302 (T) can be

TCP, IPSEC, Terminal Server, HTTP cookie, a type of application as noted above and so on. The session identifier 2302 (1) can be &lt;source IP address, source TCP port, destination IP address, destination TCP port, client IP = 172.30.189.122, User = 'joe_user', Coo20 kie {b7595cc9-e68b-4eb0-9bfl -bb717b31d447} ', another application-specific ID for a session, and so on. For TCP connection / session types, the session identifier 2302 (1) can alternatively be a canonical version of TCP 4-tuple (for IPv4 or IPv6). Other values ​​for the 2302 (1) session identifier and 2302 (T) session / application type fields can be used alternatively.

<img file="BRPI0402591B1_D0144.tif" />

Figure 23B is an exemplary distributed atom manager (DAMT) table (DAM) 2206, as shown in Figure 22. Table DAM 2206 includes w entries 2304 (1), 2304 (2) ... 2304 (w). Each session information entry

2304 is created by DAM 2202 in response to a session establishment message 2008 (U), which is received from the 2002 session tracking infrastructure. Each session information entry 2304 is destroyed in response to a session termination message 2008 (D), which is received from the 2002 session tracking infrastructure. As described

1Õ ^_ ã additionally- below, - the session information entries 2304 of DAM 2206 tables can actually be handled by DAM 2202 using function calls 2204.

As described above, the session establishment message 2008 (U) includes the session identifier, the main computer identifier and optionally, other information. Each respective session information entry 2304 (1), 2304 (2) ... 2304 (w) in table DAM 2206 includes respective key fields (i) 2304 (1K), 2304 (2K) ...

2304 (wK), (ii) data 2304 (ID), 2304 (2D) ... 2304 (wD) and (iii) metadata 2304 (1M), 2304 (2M) ... 2304 (wM). For example, values ​​for key fields 2304 (K) can be alphanumeric strings and values ​​for data fields 2304 (D) can be binary bits. The values ​​for key 2304 (K) can be binary bits as well.

Key 2304 (K) can correspond to session identifier 2302 (1). Data 2304 (D) can correspond to the host computer identifier, such as a network address of host computer 108 in which the context exists

<img file="BRPI0402591B1_D0145.tif" />

• · · · · • · · · · · • · · · · · • ···♦·· · • · · · · ·· · ·· ·

<img file="BRPI0402591B1_D0146.tif" />

of the session. The 2304 (M) metadata can correspond to other optional information. Examples of such 2304 (M) metadata include data that is used internally by DAM 2202 to resolve collisions of atoms and to track the vividness of the atom (for example, via the interruption mechanism). (This characterization of 2304 entries as being atomic is described in more detail in the following paragraph.) More specifically, the 2304 (M) metadata includes, among other things, the entity's identity (for example, the case of functionalida10 ““ cie “De-routeamento-de_ .traffito 2012) that added the session information entry 2304 to table DAM 2206.

In an implementation described, each session information entry 2304 is atomic in the sense that DAM 2202 can add, delete, copy, etc., entries 2304 as a whole, but DAM 2202 does not ordinarily modify a part of any integral entry 2304 . Thus, atomic entries 2304 are added, deleted, copied, manipulated in some other way, etc., in tables DAM 2206 by DAM 2202 in order to implement availability and scalability for an implementation of session affinity preservation.

Function calls 2204 (from Figure 22) can be used by DAM 2202 to manipulate atomic entries 2304 from table DAM 2206. Function calls 2204 can be communicated from a load balancing unit 106 to one or more other units of load balancing 106 in a point-to-point or multicast manner. These function calls include adding atom 2204 (A),

<img file="BRPI0402591B1_D0147.tif" />

<img file="BRPI0402591B1_D0148.tif" />

955 ·· delete atom 2204 (D), consult atom 2204 (Q) and return atom 2204 (R.

Add atom 2204 (A) takes the form Add Atom (key, data) and is used to add an atomic entry

2304 in one or more DAM 2206 tables. Thus, a function call to add atom 2204 (A) can be formulated as Add Atom (session identifier, main computer IP address). Erase atom 2204 (D) takes the form Erase Atom (key) and is used to erase an atomic entry

10 “-2304- -in- a -Olu plus_.DAM tables 2206. The function calls Delete atom 2204 (D) can be directed to those DAM tables 2206 known to have a copy of the session that is identified by the key 2304 (K) or you can multicast all DAM 2206 tables to ensure that any copies are deleted.

The atom query 2204 (Q) takes the form AtomQuery (key) and is used by a particular DAM part 2202 when a session identifier, as referred to by an incoming connection request, is not found in table 20 particular local DAM 2206 of the particular DAM portion 2202. Atom query function calls 2204 (Q) are sent to one or more other DAM portions 2202 (including, possibly all). In response, the DAM portion 2202, mutually checks its local DAM table 2206 for the key / session identifier. If the key is located by another DAM portion 2202, this other DAM portion 2202 replicates with a return atom 2204 (R.

Return the atom 2204R takes the form ReturnAtto93 mo (key, data) and is used to replicate an atom query function call 2204 (Q). The atom return function calls 2204R are used when a DAM portion 2202 has a requested atomic entry 2304 in its local DAM table 2206, as identified by a key 2304 (K) specified in the atom query function call 2204 (Q ). The atom return function calls 2204R can be routed back to the DAM portion 2202 that issued the atom query function call 2204 (Q).

- - The - add atom function calls 2204 (A) are used in response to session establishment messages 2008 (U) and / or to replicate an atomic entry 2304 in one or more other DAM 2206 tables. Such replication can be for redundancy and / or scalability.

The atom delete function calls 2204 (D) are used in response to 2008 session end messages (D) and can also be sent to one or more other DAM 2206 tables. After an atomic entry 2304 is deleted, the entry atomic 2304 can enter a zombie state, such that it remains with DAM 2202 and optionally, such that it is still actually stored with table DAM 2206 with a zombie indication in the 2304 (M) metadata field of atomic entry 2304 .

Thus, once an atomic entry 2304 is deleted, it can stay in DAM 2202 and in table DAM 2206 in a zombie state, such that the packages for this session (now dead and closed) are directed to the main computer 108 of the session context for appropriate treatment ······ specific protocol. For example, TCP packets received after a TCP connection has been pulled down, are directed to the host computer 108 that ended the connection. This main computer 108 can respond appropriately - perhaps sending an RST or sending a FIN-ACK again. The time that the 2304 atomic input spends in this zombie state, corresponds (as far as reasonably possible) to the protocol-specific dead time of the reliable communication protocol that is employed.

TO - - - - - An atom query function call 2204 (Q) is used to obtain an atomic input 2304 when a first load-balancing unit 106 receives an incoming connection request that refers to a session that is not stored in local DAM table 2206 of DAM 2202 of the first load balancing unit 106. It should be noted that other DAM portions 2202 can be consulted simultaneously in an atom query function call 2204 (Q) with wide diffusion or sequentially until a positive atom return function call 2204R is received.

An atom return function call 2204R is used by a DAM portion 2202 of a second load balancing unit 106 to provide an atomic input 2304 in DAM portion 2202 of the first charge balancing unit 106, where atomic input 2304 has a 2304 (K) key that is specified by the key / session identifier in an atom query function call 2204 (Q), that was previously issued by the DAM 2202 portion of the first load balancing unit 106. You must

<img file="BRPI0402591B1_D0149.tif" />

«· Φ note that other components, such as 2012 traffic routing functionality, may also be able to call functions 2204, especially an atom query function call 2204 (Q), according to an API or similar,

DAM 2202 portions and DAM 2206 tables can be organized and managed in a variety of ways. Exemplary ways refer to replication / redundancy, local cache at the time of purchase, hashing for location selection, and so on. Zero, one, two or more levels of replication up to full replication can be employed. With a zero level of replication, each atomic entry 2304 is stored in DAM 2202 which receives a session establishment 2008 (U) message without replication to other DAM 2202 portions.

With a first level of replication, each atomic entry 2304 is stored in DAM 2202 that receives a session establishment message 2008 (U) and is also added (copied) to another DAM 2202 portion using an atom add function call 2204 (A). This manipulates one. . fault level for a load balancing unit 106. Similarly, with a second application level, each atomic entry 2304 is stored in DAM 2202 that receives a session establishment message 2008 (U) and is also added to two other DAM 2202 portions. In general, one, two , etc., other DAM 2202 portions for which a given DAM 2202 portion copies atomic inputs 2304, is predetermined or selected at random. Third, fourth, etc., replication levels can also be employed.

<img file="BRPI0402591B1_D0150.tif" />

99»

<img file="BRPI0402591B1_D0151.tif" />

• · t · ·

MMI

In addition, full replication can be employed by having each atomic entry 2304 that is stored in DAM 2202, which receives a session establishment message 2008 (U), also adding the alternate portion DAM

2202. Several factors are impacted by the selection of the replication level: as the replication level increases, availability increases and latency decreases. On the other hand, network traffic and memory usage increase as the level of replication increases.

1Õ “When -total reptraction is not employed, the local cache_ when acquired can be. For example, when a DAM portion 2202 does not find a session identifier referred to in its table portion DAM 2206, the DAM portion 2202 issues an atom query function call 2204 (Q) to obtain the atomic entry 2304 associated with the identifier of the session referred to via callback function of attoifôó 2204R. Rather than discarding the atomic input obtained 2304 after its use, the DAM 2202 portion caches the atomic input obtained 2304 in its DAM 2206 table portion. This option offers a trade-off between the factors listed above.

Another option when full replication is not used, hashing for location selection can be employed. The first atomic entry 2304 for a session is stored in the DAM portion 2202 that receives the session establishment message 2008 (U). Copy or replicated copies are sent via so-called atom addition function 2204 (A) for specific DAM portion (s) 2202 using a hashing function. From a total range of possible values ​​of invalid information, each DAM 2202 portion is assigned a subset of it. Each session identifier is transformed using some hashing function to arrive at a transformation value. This transformation value is mapped to the assigned DAM portion (s) 2202. The DAM portion 2202 that first added atomic entry 2304, then replicates the entry

10 atomic ___ 2304 for the assigned portion (s) -DAM-22Ό2^-. “

With string transformation for site selection, at least one DAM 2202 portion that has a desired atomic entry 2304 with local cache in its DAM 2206 table can be known by the session identifier.

An atom query function call 2204 (Q), therefore, can be directed to the known DAM portion 2202. This usually reduces network traffic and / or latency.

This transformation for site selection can be used with one, two, three or more replication levels, with each range of transformation values ​​mapping to one, two, three, etc., different DAM 2202 portions, respectively. In addition, transformation for location selection can be used with local cache when purchasing.

Figure 24 is a flow diagram 2400 that illustrates an exemplary method for managing session information across multiple load balancing units. The flow diagram 2400 includes eight blocks 2402-2416. Although the actions of the 2400 flow diagram can be performed in other

<img file="BRPI0402591B1_D0152.tif" />

<img file="BRPI0402591B1_D0153.tif" />

<img file="BRPI0402591B1_D0154.tif" />

10} ·· a

• «· •« · * ♦ ···· · · »···· ·· environments and with a variety of software schemes, Figures 1-3, 19, 20, 22 and 23B are used in particular to illustrate certain aspects and examples of the method.

In block 2402, a connection request that arrives with a session reference is analyzed. For example, the 2012 traffic routing functionality may receive an incoming connection request that refers to an open / previously established session of a particular type. In block 2404, a local DAM table is searched using 10 if the session reference. For example, for —a given — joined -____ load balancing 106 and traffic routing functionality 2012, your DAM 2202 portion can fetch its corresponding DAM 2206 table by looking for the session reference.

In block 2406, it is determined whether the session reference corresponds to a key in the local DAM table. For example, the DAM portion 2202 can fetch key fields 2304 (K) from multiple entries 2304 from table DAM 2206 to determine whether the session reference matches any value in key fields 2304 (K). If so, flow diagram 2400 continues at block 2412.

On the other hand, if the session reference does not match any key, flow diagram 2400 continues at block 2408. At block 2408, an atom query function call is made. For example, the DAM portion 2202 can make an atom query function call 2204 (Q) that includes the reference / session identifier as the key. The atom query function call 2204 (Q)

<img file="BRPI0402591B1_D0155.tif" />

4 4 4 4

<img file="BRPI0402591B1_D0156.tif" />

can be sent to at least one other DAM 2202 portion. The number, selection, order, etc., of possible destinations for DAM 2202 portions for the 2204 (Q) atom query, may depend on the options (for example, replication level , transformation for site selection, local cache upon acquisition, point to point versus multicast, etc.) employed by DAM 2202.

In block 2410, a returned atom is received. For example, information from an atom function call returned 2204R that — is — issued to — another DAM portion 2202, may be received. The other DAM 2202 portion successfully located an atomic entry 2304 in its corresponding DAM 2206 table, with the atomic entry located 2304 having a key that corresponds to the session reference. The information from the returned atom function call 2204R includes values ​​from the key field 2304 (K) and data field 2304 (D) for the localized atomic input 2304. These values ​​correspond to the session's session identifier and network address main computer 108 that has an affinity for the session.

In block 2412, an atomic entry is extracted. The atomic entry is taken from the local DAM table if a match is found locally (in blocks 2404 and 2406) or from the returned atom if a match is found elsewhere (in blocks 2408 and 2410). For example, an atomic entry 2304 can be extracted from table DAM 2206 of portion DAM 2202 or from information received by an atom return function call 2204 (R). The entrance

<img file="BRPI0402591B1_D0157.tif" />

103*· * ·· *

<img file="BRPI0402591B1_D0158.tif" />

extracted atomic 2304 can be cached in the local DAM table 2206 if it is received as a result of the callback atom function 2204R.

In block 2414, the main computer that has a session affinity with the referred session, is verified from the atomic entry. For example, a value of the 2304 (D) data field of the extracted atomic input 2304 can be ascertained to thereby ascertain a network address of the main computer 108 with affinity. In block 2416, the so10 1 connection request^-what^-enough ~ is routed -to- the main ______ computer ascertained. For example, the 2012 traffic routing functionality and / or the forwarding functionality can route the incoming connection request having the session reference to the main computer 108 ascertained with affinity. Exemplary classification, order routing and shipping features are described in the following section.

Request Classification, Shipping and Routing

Copies

This section describes how traffic routing can be implemented for network load balancing, including with regard to the high availability of such traffic routing functionality. Traffic routing functionality may include classifier functionality and / or request routing, especially in conjunction with referral functionality. This section refers mainly to Figures 25 to 31. It clarifies the functionality of a 306 request router (from Figure 3), an in104.

<img file="BRPI0402591B1_D0159.tif" />

·« ··♦· ··

I ♦ · · * • ··· · · «· ··· have a relationship between the tracking sessions and the use of health and load information when traffic routing, operational implementations for interacting traffic routing with traffic information session and / or health and load information, back-up (failover) operating procedures for high availability of network load balancing infrastructure (including handling classification failures, delivery and / or request routing components), balance infrastructure configurations10^-network download-additional-and so on -.—------- Figure 25 illustrates exemplary network load balancing infrastructure having request routing functionality, as performed by request router 306 (H /S). As noted above with reference to the 2012 traffic routing functionality, traffic routing can relate to classification (for example, shipping) and / or request routing. Classification at package level, together with shipping; is described above. , with. particular reference to Figure 4. The request routing is described here with particular reference to Figure 25.

request-level routing occurs at a higher level than packet-level routing. A request router 306 typically acts as a proxy for an application 316 that runs on a main computer 108. Request router 306 terminates the connection. TCP, parses (perhaps partially) each request from a client 102 and resubmits each request to the main computer 108. The request router 306 can perform

105

<img file="BRPI0402591B1_D0160.tif" />

perform pre-processing on the connection, such as SSL decryption. In addition, the request router 306 can choose to absorb certain requests (for example, the request router can maintain a response cache) and it can arbitrarily modify requests before forwarding them to the main computers 108.

Request routers 306 are usually application specific; and they can be somewhat open about what they are capable of. Just by way of example, a “unique”^-request-router-class 306 - HTTP / SSL request routers 306 (H / S) - are treated in the following description. As illustrated, a client 102 having a network address C1 is communicating over network 104 with main computers 108 (1) and 108 (2) having network addresses H1 and H2, respectively. Communications are carried out via a load-balancing infrastructure that includes an HTTP / SSL 306 (H / S) request router.

HTTP / SSL request router 306 (H / S) terminates HTTP and SSL traffic, decodes SSL traffic, examines each HTTP request coming from client 102, applies application-specific rules to classify each request, and determines the best end point for that request while taking into account the health and cargo information of the application's end point, and submits the request to the end point. Submission of the request to the endpoint uses a TCP connection separate from that originated by client 102 (the last connection is terminated at the HTTP / SSL request router 306 (H / S)). These actions can be considered25 • ♦ • ·

106 • · ····««

<img file="BRPI0402591B1_D0161.tif" />

logically equivalent to the actions performed by a classifier 304, but a difference appears in that these actions on the HTTP / SSL request router 306 (H / S) are occurring at the logical request level for each request within the TCP connection. The HTTP / SSL request router 306 (H / S) and request routers 306 can generally use the same (i) healthcare infrastructure and application load and (ii). session tracking infrastructure that is used by 304 classifiers.

TO ”The router — of HTTP / SSL 306 (H / S-) soTi-quote - is acting as an intermediary between client 102 and two main computers 108 (1) and 108 (2). It is handling two 102 client requests over a single TCP connection. In an implementation described, the resulting request routing involves a series of actions. First, client 102 establishes an http or https connection [1] to an HTTP / SSL request router 306 (H / S) and sends a request # 1

2502 (1) .

Second, the HTTP / SSL request router

306 (H / S) ends the SSL session (if traffic is encrypted over SSL), analyzes request # 1 2502 (1) and examines the contents of the request at # 1 2502 (1). Taking into account the application's health and load information, as well as session information, the HTTP / SSL request router 306 (H / S) determines that host computer 108 (1) is the best host computer for this request # 1 2502 (1) particular in this example.

Third, the HTTP / SSL request router

107 • ·· ·

306 (H / S) establishes a secondary connection [2] with the main computer 108 (1). Alternatively, he can use an existing connection [2] to the main computer 108 (1). Then, the HTTP / SSL request router 306 (H / S) sends an unencrypted version of request # 1 2502 (1) to The host computer 108 (1). Fourth, main computer 108 (1) replicates with an answer # 1 2504 (1). Fifth, the HTTP / SSL request router 306 (H / S) encrypts this response # 1 2504 (1) and sends it back to client 102 over the TCP connection [1]. ____{__}_________________________________

Sixth, client 102 sends another request, request # 2 2502 (2). Request # 2 2502 (2) is handled in a similar way to handling request # 1 2502 (1), except that the request router

HTTP / SSL 306 (H / S) selects host computer 108 (2). The different selection may be because host computer 108 (1) is now failing or is more heavily loaded, because request # 2 2502 (2) is directed to a different URL than request # 1 2502 (1) and so on. In spite of this, the HTTP / SSL request router 306 (H / S) establishes another secondary TCP connection, but this secondary TCP connection [3] is with the main computer 108 (2).

Request # 2 2502 (2) unencrypted is routed to host computer 108 (2) and a response # 2 2504 (2) is received from it as a result. An encrypted version of response # 2 2504 (2) is then sent to client 102 from the HTTP / SSL request router 306 (H / S).

Seventh, client 102 closes the TCP connection [1] with

108

<img file="BRPI0402591B1_D0162.tif" />

the HTTP / SSL request router 306 (H / S). the HTTP / SSL request router 306 (H / S) (at some point in the future) closes the connections [2] and [3] that it made to the main computers 108 (1) and 108 (2), respectively, on behalf of of client 102. The TCP connection [2] can be closed, alternatively, after the HTTP / SSL request router 306 (H / S) decides to open / use the TCP connection [3] for request # 2 2502 (2 ).

Because a -1Ό HTTP / SSL -3Ú6- (H / S) request router terminates — the— connection — http / https, the HTTP / SSL 306 (H / S) request router can make more than routing requests. For example, the HTTP / SSL request router 306 (H / S) can potentially maintain its own response cache (for example, with an out-of-date mechanism to invalidate the cache). As noted in the example above, the HTTP / SSL request router 306 (H / S) can also potentially route different types of requests to different sets of host computers 108 based, for example, on the requested URL. On the other hand, the HTTP / SSL 306 (H / S) request router can potentially aggregate requests from many short-lived client connections and send them over a few long-lived TCP connections to the primary computers 108. Such connection aggregation can reduce the time spent processing the TCP connection on the main computers 108.

Request routers of other classes can correspond to other exemplary protocols in addition to HTTP. For example, a request router can be a

109 SOAP request router. SOAP request routers work in a similar way to an HTTP / SSL 306 (H / S) request router. However, SOAP request routers are experts in routing SOAP traffic.

SOAP request routers understand SOAP headers and make routing decisions based on SOAP headers, as well as application health and load.

Both routing, classification and shipping at the packet level (or routing at the packet level) and at the packet level^-soTicitationOT — can propose some — 7-way load balancing. The 7-layer load balancing is further described below in the section whose title is Exemplary Connection Migration with Optional Tunneling and / or Application-level load balancing. Packet-level routing provides read-only access to the initial portion of a customer's TCP connection data, and request-level routing provides read and modify access to an entire data stream.

Typically, packet-level routing has several advantages over request-level routing. These advantages include transparency (client packets are delivered to main computers as is, preserving source and destination IP addresses and port numbers), poor processing performance (generally, shipping traffic involves route searching), low latency ( individual packets are forwarded and the packets are not queued once the TCP connection destination has been determined) and high availability (usually a

<img file="BRPI0402591B1_D0163.tif" />

110 ·· ·· * · failure in a sender does not end the TCP connection). On the other hand, request-level routing typically has the following advantages over packet-level routing: an ability to examine an entire flow of flu5 data going to and from the client; and an ability to transform a data stream and even split the data stream between multiple primary computers or aggregate data streams from multiple clients.

Figure 26 is a flow diagram 2600 that illustrates an exemplary method for o-routing _ of incoming packets with respect to &lt;i) session information and (ii) health and cargo information. The flow diagram 2600 includes eight blocks 2602-2616. Although the actions of the 2600 flow diagram are performed in other environments and with a variety of software schemes, Figures 1-3, 12, 18-20, 22 and 23B are used in particular to illustrate certain aspects and examples of the method.

In block 2602, an incoming packet is received. For example, a packet from a client 102 can be received at a sender 302 of a load balancing unit 106. At block 1604, it is determined whether the received packet is for a pre-existing session. For example, sender 302 can consult a local DAM table 2206 () to determine that the received packet is already part of a session

TCP / IP.

Additionally, the sender 302 can consult the local DAM table 2206 () and determine that the received packet is not yet part of a TCP / IP session. In this case, the sender

<img file="BRPI0402591B1_D0164.tif" />

111 • · ·

<img file="BRPI0402591B1_D0165.tif" />

try 302 provides the received packet to a classifier 304, which checks for a higher level session affinity for the received packet if it has a session reference. Examples of these actions are described above with particular reference to Figure 24 and additionally below with particular reference to Figures 27 and 28.

If the received packet is for a pre-existing session (as determined in block 2604), then the flow continues in block 2606. In block 2606, a main computer

<img file="BRPI0402591B1_D0166.tif" />

1-0 - pal — who-has-affinity-with the pre-existing session^-, is ascertained. For example, a main computer 108 with affinity can be ascertained from local DAM 2206 () and / or all DAM distributed 2206 by sender 302 or classifier 304.

In block 2608, it is determined whether the main computer with affinity is healthy. For example, classifier 304 can query a consolidated health and load cache 1208 to determine whether host computer 108 with affinity is healthy, especially for those received packets that are part of sessions that have a higher logical level than TCP sessions / IP. The action (s) of this block can be performed in conjunction with a health and cargo handler 314.

If the main computer with affinity is healthy (as determined in block 2608), then the flow continues in block 2610. At block 2610, the received packet is routed to the main computer with affinity. For example, sender 302 (for TCP / IP sessions) or classifier 304 (for higher level sessions) can route the packet

112 ϊ · · • · ♦ · * ·· * · «·« ···· * · • ** ·

<img file="BRPI0402591B1_D0167.tif" />

for ο main computer 108 with affinity. In an alternative implementation, classifier 304 may return the received packet to sender 302 for routing to host computer 108 with affinity, even for incoming packets that are part of higher level sessions.

If, on the other hand, the main computer with affinity is not healthy (as determined in block 2608), then the flow continues in block 2612. In addition, if on the other hand, the received packet is not for a pre-existing session (as determined in block 2604), then the flow continues in block 2612. In block 2612, a main computer is selected in response to health and load information. For example, classifier 304 may select a host computer 108 and / or use a health and load related application allocation (for example, from a 1804 target application endpoint allocation response) that is obtained from the data handler. health and cargo 314. Examples for these actions are described above with particular reference to Figures 19 and 18 and additionally below with particular reference to Figure 30.

In block 2614, the received packet is routed to the selected main computer. For example, classifier 304 can route (optionally via sender 302) the packet to the selected host computer 108. In block 2616, a route to a connection path to the selected main computer is evaluated. For example, classifier 304 can add a session information entry in table DAM 2206, especially in table DAM 22060 which is

<img file="BRPI0402591B1_D0168.tif" />

♦··

113 • · • * · * ···&lt;

local to sender 302 who provided the received packet to classifier 304. This session information entry can be replicated according to the redundancy guideline instituted for a DAM 2202 (for example, from a 308 session tracker).

The action (s) of block 2613 and those of block 2616 can be performed in the order illustrated specifically, with those of block 2616 being performed before those of block 2614, with the actions overlapping partially or totally in any order and so onwards. It should be noted that the actions performed by classifier 304, as described above, can be performed alternatively by a request router 306 (or more generally, 2012 traffic routing functionality)

Figure 27 illustrates an exemplary traffic routing flow in the absence of failures. As illustrated, one or more load balancing conscious switches 202 (LBA) face the remaining load balancing infrastructure 106 (not indicated separately). Shipping and sorting features are distributed across three devices or nodes. A first device includes the sender 302 (1) and the classifier 304 (1). A second device includes classifier 304 (2). A third device includes sender 302 (2).

• With classifier 304 (2) running on the second device and sender 302 (2) running on the third device, each device can be specially tuned for its respective functions. For example, the

114

<img file="BRPI0402591B1_D0169.tif" />

hardware, software, firmware, some combinations of these, etc., from the second device and the third device, can be adapted to support the desired functionality, without excessive provision. Thus, the third device that includes sender 302 (2), may be similar to a switch and / or router from a hardware capability perspective, and the second device that includes classifier 304 (2), may be more similar to a server and / or personal computer from a hardware capability perspective.

Although shown as three devices that are providing functionality to four components, alternative logical and / or device-level configurations for shipping and classification functionality, they are applicable to the exemplary traffic routing flow that is described here for Figure 27. In addition, although the routing destinations are shown as main computers 108, the descriptions here of routing implementations can alternatively be applied more generally to a next destination node for the packet and not necessarily an end node that consumes the packet.

A DAM 2202 realization of session tracker 308 is used to implement DAM table 2206. However, session affinity preservers 1904 in general are also applicable to the exemplary traffic routing flow in Figure 27. Sender 302 (1 ) includes table portion DAM 2206 (1) and sender 302 (2) includes table portion DAM 2206 (2). Incoming packets are routed to main computer 108 (1) or main computer 108 (2).

• ·· ·

<img file="BRPI0402591B1_D0170.tif" />

115

In a described implementation, DAM 2202 is a table in distributed memory of 2304 atoms (for example, keyword-value pairs, with optional metadata) having session information. DAM 2202 and table DAM 2206 are further described above with particular reference to Figures 22-24. Any node in the 304 classifier group can add, query and delete 2304 atoms. DAM 2202 maintains a highly available DAM table that includes active routes (eg, TCP / IP level) as well as higher level session information.

In (1), load-balanced switches 202 (LBA) direct a packet that arrives at sender 302 (1). In (2), the sender 302 (1) consults its internal routing table, table DAM 2206 (1). When the sender 302 (1) does not find an atomic entry 2304 for this package, he sends the package to his assigned and / or associated classifier, classifier 304 (1).

In (3), the classifier 304 (1) recognizes that the packet in this example is a TCP-SYN packet. Therefore, classifier 304 (1) treats the packet as the start of a new TCP connection from a client 108. Using health and load information from a health and load handler 314 (not explicitly illustrated), classifier 304 (1 ) determines that host computer 108 (1) must receive this TCP connection. 0 classifier 304 (1) updates the DAM table 2206 (1) which serves as the local routing table for the sender 302 (1) and also inserts an atomic entry 2304 that represents the route for the entire DAM 2206. These can be separate operations ,

116 ♦ ··. ♦ ··.: ··· ίί · ί · ϊ; ···· J a unique operation in which the TCP / IP sessions of table DAM 2206 are located at senders 302 and so on. DAM 2202 internally replicates this route to one or more other members of the 304 classifier group, according to its stipulated redundancy guideline.

In (4), the sender 302 (1) directly sends subsequent packets for this connection to the main computer 108 (1), without interacting with the classifier 304 (1). DAM 2202 can be used to mask, at least in part, the failure of a 302 sender, a 304 classifier, or a 302/304 sender / classifier pair. DAM 2202 can also be used, at least in part, to preserve client connectivity if load-balanced 202 (LBA) conscious switches inadvertently start sending packets over a connection established with a different 302 sender.

Figure 28 illustrates an exemplary traffic routing flow in the presence of failure (s). In contrast to the exemplary fault-free traffic routing flow of Figure 27, a failure occurred in a portion of the network load balancing infrastructure 106 (not specifically identified) of Figure 28. Specifically, the first device, in which sender 302 (1) and classifier 304 (1) are resident and executed, fails after the connection that is illustrated in Figure 27 is established. This failure is masked, at least in part, by DAM 2202.

In (1), load-balanced switches 202 (LBA) detect the failure of the sender 302 (1) and begin sending packets to the connection to some other location.

<img file="BRPI0402591B1_D0171.tif" />

117

<img file="BRPI0402591B1_D0172.tif" />

302 in the group. In this example, the other sender 302 is sender 302 (2). Although Figure 28 illustrates a failure situation A, load-balanced switches 202 (LBA) can also send this traffic to sender 302 (2), even though sender 302 (1) is still available. This change induced by the failure of senders 302 can occur, for example, because load-balanced switches 202 (LBA) forget the affinity of this traffic with sender 302 (1). The rating actions (2) - (5) apply to both failure and forgotten affinity situations.

In (2), the sender 302 (2) consults its routing table, table DAM 2206 (2). When he cannot find a route for this packet, he sends the packet to his 304 (2) classifier. In (3), classifier 304 (2) recognizes that this packet is a medium connection TCP packet and classifier 304 (2) queries DAM 2202 as to the route for this packet. DAM 2202 responds with the route for the connection from an atomic input 2304 that is associated with it.

In (4), classifier 304 (2) evaluates the route at sender 302 (2). An exemplary protocol for evaluating routes is further described below. In (5), subsequent packets for this connection that are directed to the sender 302 (2), are routed directly to the correct main computer, than the main computer 108 (1) in this example, without consulting the classifier 304 (2).

In general, a routing assessment protocol for communications between 304 classifiers and senders

118

302 include instructions for adding and removing directions. More specifically, an add route instruction is sent from a classifier 304 to a sender 302 in order to evaluate a route from sender 302 to a destination host computer 108 for a given connection. As an example, an add route instruction can be provided to sender 302 (2) from classifier 304 (2), as indicated in (4) in Figure 28. The route (for example, a key and corresponding value) is added to the local DAM table 2206 (2) for quick access by the sender 302 (2) in the future. In this example, the classifier 304 (2) is a device separate from the sender 302 (2), so the route evaluation protocol can be an inter-device protocol. However, the route assessment protocol can also be used for intra-device communications.

In a described implementation, classifier 304 (2) includes a connection inventory 2802. With connection inventory 2802, classifier 304 (2) keeps track of connections from any 302 sender (such as sender 302 (2)) for which classifier 304 (2) evaluates routes. For¹ allow classifier 304 (2) to control connections, including terminations, sender 302 (2) sends final packets to connections (such as a TCP FIN packet) to classifier 304 (2). The classifier 304 (2) then deletes an entry in connection inventory 2802 that corresponds to the connection and sends an erase route instruction to sender 302 (2). Upon receipt of the delete route instruction, sender 302 (2) removes the corresponding route

<img file="BRPI0402591B1_D0173.tif" />

119 • ·

<img file="BRPI0402591B1_D0174.tif" />

···· ·· :.. : :

• ··· in table DAM 2206 (2). In this way, the classification functionality in conjunction with the session tracking functionality, can control the route tables and their routes, which are used by the shipping functionality. Consequently, shipping functionality that is separated on a different device, can be accomplished using high-speed, but relatively simple hardware.

Figure 29 illustrates additional exemplary back-up (failover) operating procedures for high availability of network load balancing infrastructure 106. Back-up operating mode procedures for two different failures are described, fault 2902 and fault 2906. As illustrated, the network load balancing infrastructure (106) (not separately indicated) includes five components: sender 302 (1), sender 302 (2), sender 302 (3), classifier 304 (1) and classifier 304 (2).

In a described implementation, each of these five components 302 (1), 302 (2), 302 (3), 304 (1) and 304 (2) corresponds to an individual device. However, similar back-up operating mode procedures apply to environments where different load-balancing components share devices.

Initially in [1], router / switch 202 directs an incoming packet which is to a new one with sender 302 (1). Because sender 302 (1) does not have a route for this connection in its local routing table, it sends the packet to classifier 304 (1), as

<img file="BRPI0402591B1_D0175.tif" />

• ··· ·

<img file="BRPI0402591B1_D0176.tif" />

120 ··· «» indicated by the double arrow dotted in (1). Classifier 304 (1) first checks session information with reference to session tracking 308 for possible higher-level session affinity. In this example, the package has no affinity with an existing session, so classifier 304 (1) selects a main computer 108 with reference to health and cargo information with reference to health and cargo handling 314.

Specifically, classifier 304 (1) selects main computer 108 (1) in this example. Assuming that the packet is for a TCP / IP connection, this TCP / IP session as linked to main computer 108 (1), is added to DAM 2202 using an atom addition function call 2204 (A) by classifier 304 (1). The initial package is sent to the main computer 108 (1) by the classifier 304 (1) or subsequently 302 (1). Classifier 304 (1) also evaluates a route in the routing table of sender 302 (1). Subsequent packages are sent to main computer 108 (1) by sender 302 (1) without further interaction with classifier 304 (1).

At some point during the connection [1], there is a failure 2902 at sender 302 (1). With load-balanced conscious router / switch 202 (LBA), this 2902 fault is detected. As a result, at point 2904, router / switch 20 directs subsequent packets, which would have been sent to sender 302 (1) along connection [1] to another sender 302, which is sender 302 (2) on this example.

<img file="BRPI0402591B1_D0177.tif" />

• ·

<img file="BRPI0402591B1_D0178.tif" />

The sender 302 (2) thus receives future packets over a connection [2]. Because sender 302 (2) does not have an entry in its local routing table for packets that were directed first to sender 302 (1), sender 302 (2) sends the first packet received from the connection [2] for the classifier to which it is assigned / associated. In this example, sender 302 (2) is assigned to classifier 304 (2), as indicated by the double dotted arrow in (2).

classifier 304 (2) uses an atom query function call 2204 (Q) to obtain atomic input 2304 (not shown explicitly) of DAM 2202, which is associated with the existing TCP / IP connection. This atomic input 2304 is provided via DAM 2202 of session tracking 308 via an atom return function call 2204R. The classifier 304 (2) extracts the main computer 108 (1) which has an affinity for this TCP / IP connection from the returned atomic input 2304. The classifier 304 (2) sends the first packet received for the connection [2] to the main computer 108 (1) and also evaluates a route in the local routing table of the sender 302 (2). Subsequent packages are sent to main computer 108 (1) by sender 302 (2) without further interaction with classifier 304 (2).

The above descriptions predominantly focus on the failures of individual shipping components 302. However, components of classifier 304 may also fail. For example, at some point, there is a failure 2906 in classifier 304 (2). Sender 302 (2) detects failure 2906 when

122···. ·

<img file="BRPI0402591B1_D0179.tif" />

<img file="BRPI0402591B1_D0180.tif" />

<img file="BRPI0402591B1_D0181.tif" />

he tries to consume classification services or because he notices a lack of any indication of liveliness, such as a heartbeat indicator. To deal with failure 2906, sender 302 (2) is reassigned or associated with a different classifier 304, which is classifier 304 (1) in this example. Future classification functionality is provided to the sender 302 (2) by classifier 304 (1), as indicated by the double dotted arrow in (3).

Figure 30 illustrates an exemplary operational implementation of traffic routing interaction with health and cargo information. The sender 302 and the classifier 304 interact with the health and load handler 314 in order to route packets to the main computers 108 (1), 108 (2) ... 108 (n). Although a 302 sender and a 304 classifier are illustrated, the exemplary operational implementation is also applicable to a 306 request router (or 2012 traffic routing functionality in general).

As illustrated, main computer 108 (1) includes application endpoints IP1, IP3 and IP4 for application # 1, application # 1 and application # 2, respectively. Main computer 108 (2) includes application IP2 and IP6 endpoints for application # 1 and application # 2, respectively. Main computer 108 (n) includes IP5 application endpoint for application # 2. These main computers 108 (1), 108 (2) ... 108 (n) and application endpoints IP1, IP2, IP3, IP4, IP5 and IP6, are monitored by the health and load handler 314 (for example, using health and load infrastructure 1202, consolidated cache of

123..·

<img file="BRPI0402591B1_D0182.tif" />

health and cargo 1208, etc.)

In an implementation described, in (1) the classifier 304 requests one or more application endpoint allocations (for example, via at least one 1802 target application endpoint allocation request) in an environment using an application allocation scheme record 1806. The health and load handler 314, in this example, responds by providing record allocations 3002 (for example, via at least one target application endpoint allocation response 1804).

Specifically, a chip allocation for application # 1 3002 (1) and a chip allocation for application # 2 3002 (2), are available for classifier 304. The allocation of chip for application # 1 3002 (1) initially provides 40 plugs for IP1, 35 plugs for IP2 and 25 plugs for IP3. The chip allocation for application # 2 3002 (2) provides 10 chips for IP4, 72 chips for IP5 and 18 chips for IP6. For each new connection that a routing is allocated to an application endpoint by classifier 304, a token is consumed by classifier 304.

In (2), sender 302 receives an initial arrival packet for a new connection. Because no routing is present for this new connection in table portion DAM 2206 from sender 302, sender 302 sends the initial packet to classifier 304 at (3).

In (4), classifier 304 (for example, after determining that the starter package does not include a session reference for a higher level session), selects a

124

<img file="BRPI0402591B1_D0183.tif" />

application endpoint (and thus, a main computer 108) in response to health and load information. Specifically, for a new connection that must be served by application # 1, classifier 304 can select any one of IP1, IP2 and IP3, if there is still a plug for the respective end point.

classifier 304 can consume tokens in any way, among many possible ways. For example, classifier 304 may use a round-robin approach despite the number of chips per end point. Alternatively, classifier 304 can simply start at IP1 and progress to IP3, while consuming all the chips for each end point before moving to the next end point in a linear approach. In addition, classifier 304 can consume one chip from the set defined by the chip endpoint which currently has the highest number of chips at any one time. Using the latter approach, classifier 304 selects IP1. Other approaches can also be employed.

As illustrated, classifier 304 consumes one plug for the IP2 application endpoint. Consequently, the chip set for IP2 is reduced from 35 chips to 34 chips as one chip is consumed. In addition, the initial packet for the new connection must be routed to the IP2 application endpoint.

In (5A), the initial packet is sent from classifier 304 to ο IP2 from the end point of the main computer application 108 (2). Before, during or after this review

<img file="BRPI0402591B1_D0184.tif" />

125

<img file="BRPI0402591B1_D0185.tif" />

However, classifier 304 in (5B) evaluates a route for this connection in the local DAM table portion 2206. Classifier 304 may also add some atomic entry 304 to this session in DAM table 2206 for distribution and replication purposes. In (6), future packets for this connection / session are forwarded from sender 302 to ο endpoint IP2 of host computer 108 (2) using sender's local routing table 302, as performed by the local DAM table portion 2206 in Figure 30.

Figure 31 illustrates exemplary high availability mechanisms for network load balancing infrastructure 106. Specifically, exemplary failure detection 3104, exemplary failure handling 3106 and exemplary failure recovery 3108 are shown. These exemplary high availability mechanisms are described in relation to different network load balancing infrastructure components 106. The network load balancing infrastructure components 106 include a sender 302, a classifier 304, a request router 306, a session tracker 308 and a health and load handler 314.

In 3102 (A), the sender 302 suffers a local failure. In 3104 (A), at least one switch aware of load balancing, detects the fault. To handle the 3102 (A) local fault, packets are redirected to other sender (s) at 3106 (A) by the load-balanced switch. To recover from sender 302 failure, routes that were stored locally at sender 302 are reconstructed at 3108 (A) at the sender (s) for which

126...

<img file="BRPI0402591B1_D0186.tif" />

... ·· · ·· ·* ···· ♦· · • · · ·· · ·· ·· · ··· • .· ·«·· · ..... . · ·· · · ·.·«·· · . · ··· ♦ ... ·.·· ·· · ·

... ·· · ·· ···· ·· ·· ··· packets are redirected using a distributed session tracking manager and a table of yours, such as DAM and a DAM table. The distributed session tracking manager can therefore include data redundancies of one or more levels.

In 3102 (B), classifier 304 suffers a local failure. In 3104 (B), at least one sender detects the failure. To deal with the 3102 (B) local fault, packets are redirected to other 3106 (B) classifier (s) by the sender who detects the fault. To recover from classifier 304 failure, session information that was stored locally in classifier 304 is reconstructed at 3108 (B) in the classifier (s) to which the packets are redirected using DAM. This session information can be, for example, session information at a higher level than baseline TCP / IP connections. In addition, such session information can be considered as part of the session tracking infrastructure that is resident on the same device as the 304 classifier.

At 3102 (C), request router 306 experiences a local failure. In 3104 (C), at least one sender and / or switch aware of load balancing, detects the failure. To deal with local 3102 (C) failure, packets are redirected to other request router (s) in 3106 (C) by the load-balanced sender and / or switch. Current individual logical requests that request router 306 is working on when local fault 3102 (C) occurs can be per127

444 «given, unless each individual logical request is _ replicated while the request is being fulfilled. To recover from the failure of the request router 306, session information and / or routes that were stored locally on the request router 306 are reconstructed at 3108 (C) on the request router (s) for which the packets ( and thus, new logical requests), are redirected. Reconstruction of session information can be performed using DAM. Again, such session information can be seen as part of the session tracking infrastructure that is resident on the same device as the request router 306.

At 3102 (D), session tracker 308 experiences a local failure. In 3104 (D), at least one sender and / or classifier 15 detects the failure. For example, if session tracker 308 is resident on the same device as a classifier, then a sender or another classifier can detect the failure. If the 308 session tracker is resident on a separate device, then a classifier can detect the failure. To deal with local failure 3102 (D), redundancy of data from one or more levels and distribution across multiple devices, 3106 (D) is instituted for the tracked session information. It should be noted that redundancy and distribution are instituted before failure

3102 (D). To recover from the session tracker failure

308, the session information from the DAM tables can be redistributed and replicated again in 3108 (D) by at least two devices (if not yet distributed and sufficient128

4444 4 • · 4 4 4 4 4

4 444 4 • 4 4 4 4

444 44 44 444 then replicated) to deal with a second level of failure.

THE³

In 3102 (E), the health and cargo handler 314 suffers a local fault. In 3104 (E), at least one classifier and / or request router detects the failure. For example, a component that is receiving health and cargo information from the health and cargo handler 314, can detect a failure if the health and cargo handler 314 starts not responding, especially if the health and cargo handler 314 is resident in a device other than that of the inquiry component. To deal with local fault 3102 (E), health and load data redundancy with cache and intrinsic fault handling are employed in 3106 (E) for health and load information.

For example, each health and cargo handler 314 can include a consolidated cache of health and cargo information 1208 that duplicates information in health and cargo tables 1204 on multiple primary computers 108. In addition, consumers of health and cargo information 1206 of a given health and load handler 314, may be located on the same device as the health and load handler 314, such that failure of the health and load handler 314 is intrinsically acceptable. Similarly, the authorized version of a respective portion of health and cargo information 1206 is located on a respective main computer 108, such that the failure of main computer 108 makes it acceptable to lose the respective portion of health and cargo information.

129

<img file="BRPI0402591B1_D0187.tif" />

To recover from the failure of the health and load handler 314, a given network load balancing component that consumes health and load information, can consult a different health and load handler because each health and load handler includes a consolidated cache of health and cargo handler information. In addition, when the health and cargo handler 314 is accessible again, message protocol 1500 can be used in 3108 (E) to rebuild its consolidated health and cargo information cache. Using these exemplary high availability mechanisms, failures of network load balancing infrastructure components 106 can be detected, manipulated and recovered in order to mask such failures from customers 102.

Exemplary Connection Migration with Tunneling Optionally and / or Load Balancing at Application Level

This section describes how connection manipulation, such as connection migration, can be used in network load balancing. This section mainly refers to Figures 32-39 and clarifies the connection migration functionality such as that provided by connection migrator 310 (from Figure 3). As described above with reference to Figures 3 and 4, each connection arriving at the load balancing infrastructure 106 can be terminated there. After that, the connection can be migrated to a main computer 108 such that the connection is then terminated at the main computer 108. The connection migrator 310 is capable of carrying out this connection migration and may be located

<img file="BRPI0402591B1_D0188.tif" />

130

<img file="BRPI0402591B1_D0189.tif" />

····· «··· · · ··· ·· · ·· ···· ·· * · ·· * partially used on main computers 108 to perform the migration. Such connection migration can be performed in conjunction with load balancing at the application level by a 304 classifier and / or using tunneling via 312 tunneling.

Figure 32 illustrates an exemplary approach to application-level network load balancing with connection migration. Application-level or 7-layer load balancing is about making load balancing decisions with respect to an application that must handle a connection. To perform load balancing at the application level, load balancing infrastructure 106 usually takes into account a portion of data from a connection. Unless a request router is employed, a classifier 304 typically peaks in the initial portion of a connection and then migrates the connection, in conjunction with connection migrator 310, to a selected primary computer 108.

For application-level load balancing in a TCP-based environment, 3.04 classifiers generally take a look at the initial portion of a given client TCP when deciding where to forward the client's TCP connection. Thus, application-level logic examines customer data and makes load balancing decisions based on that data. For example, if a connection is an HTTP (unencrypted) connection, a classifier 304 can scan the HTTP header of the first HTTP request on the connection and can make routing decisions.

<img file="BRPI0402591B1_D0190.tif" />

131

<img file="BRPI0402591B1_D0191.tif" />

based on some portion of the header content (e.g. URL, cookie, etc.). Although application-level load balancing, connection migration and tunneling are applicable to other protocols, TCP / IP is used predominantly in the examples here.

As illustrated, the load-balancing infrastructure 106 (not specifically indicated) includes a sender 302, a classifier 304, a tunneler 312 and a connection migrator 310 (and possibly, for example, a balance-aware router / switches load load (LBA)). The sender 302 corresponds to the virtual IP address and sends packets to main computers 108 according to the selection of main computer made by classifier 304. Although not shown specifically in Figure 32 for clarity, main computers 108 also include connection migrator functionality 310 and tunneling functionality 312.

In a described implementation, sender 302, classifier 304 and connection migrator 310 (in classifier 304 and main computers 108), together with TCP protocol software in classifier 304 and main computers 108, cooperate to provide connection migration. The connection migration illustrated in Figure 32 is for a client connection 102 (1) that is initially terminated in classifier 302. After connection migration, client connection 102 (1) is terminated on main computer 108 (1). Once the connection is complete on the main computer 108 (1), the packets for the connection can be

132 tunneled using tunneler 312 (at sender 302 and main computer 108 (1)).

In (1), client 102 (1) sends a SYN packet to sender 302 to signal the start of a new TCP connection. In (2), sender 302 sends this packet to classifier 304. In (3), classifier 304 accepts the TCP connection on behalf of a host computer 108 (whose identity is not yet known because the host computer 108 () has yet to be selected). In terms of TCP protocol, classifier 304 sends a SYN-ACK packet to client 102 (1).

In (4), client 102 (1) starts sending data. (The initial SYN packet can also contain data.) The data is processed by the 304 classifier, which can query application-specific logic. Application-specific logic can relate to which host computer 108 is capable of handling or better handling which types of requests or connections. Thus, classifier 304 uses the data, as well as application health and load information from health and load handler 314 and, optionally, application session information from session tracker 308, to determine a host computer 108 that is better or more suitable to handle this client connection 102 (1). In this example, main computer 108 (1) is selected.

In (5), classifier 304 sends a binary blob (large object) that represents the state of the TCP connection with the main computer 108 (1). This connection state is a133

<img file="BRPI0402591B1_D0192.tif" />

grouped with cooperation of a TCP stack in classifier 304 by connection migrator 310. The binary blob contains data from client 102 (1), of which classifier 304 and TCP parameters became aware, such as TCP / IP 4-tuple, starting numbers sequentially and so on.

<img file="BRPI0402591B1_D0193.tif" />

In (6), a connection migrator component 310 on main computer 108 (1) (not shown explicitly in Figure 32) injects this connection into a TCP stack on main computer 108 (1). This connection state injection is performed in cooperation with the TCP stack on the main computer 108 (1), making it appear to applications 316 on the main computer 108 (1) that this connection was originally accepted by the main computer 108 (1). 0 client 102 (1) is not aware of connection migration.

In (7), classifier 304, in cooperation with the TCP stack in classifier 304, silently clears the internal state maintained for this connection. Classifier 304 also adds a route to a local routing table for sender 302 that indicates host computer 108 (1) as the destination for packets on this connection.

In (8), subsequent packets for the connection are routed by the sender 302 to the main computer 108 (1). These packets can be handled in the same way by the sender 302 as packets for connections that are classified and routed without using connection migration. These subsequent packages can optionally be tunneled from sender 302 to the main computer

134

<img file="BRPI0402591B1_D0194.tif" />

108 (1) using tunneler 312. Tunneler 312 is also illustrated (using dotted lines) in connection migrator 310 in classifier 304, because certain parameters used by tunneler 312 can be determined during connection integration and / or can be associated with a connection that is migrating. Exemplary implementations for the tunneler 312 are described below with particular reference to Figures 38 and 39.

Figure 33 is a flow diagram 3300 which illustrates a model for migrating a connection from a first device to a second device. Flow diagram 3300 includes seven blocks 3302-3314. Although Figures 32 and 34-37 mainly focus on connection migration in a network load balancing environment, connection migration, as described here, can be performed between two devices in general, each of which includes migration functionality connection, such as that of connection migrator 310.

In block 3302, a connection is accepted on a first device. For example, a first device may terminate an incoming connection, according to one or more protocols of a protocol stack portion of a network stack. In block 3304&gt; data is received for connection to the first device. For example, this data can be received in an initial packet that requests the connection or in one or more packets that are received subsequent to an acceptance of the connection.

In block 3306, a connection state for the connection

135

<img file="BRPI0402591B1_D0195.tif" />

accepted is aggregated from a protocol stack (or, more generally, from a network stack) on the first device. For example, a protocol state of one or more protocols in the protocol stack can be compiled and aggregated with any received data that has been known. In block 3308, the connection status is sent from the first device to a second device. For example, aggregated connection status information can be sent using a trusted protocol to a second device. .

In block 3310, the connection state for the connection to be migrated is received from the first device on the second device. In block 3312, the connection state is injected into a protocol stack (or more generally, the network stack) of the second device. For example, the connection can be hydrated again using the protocol stack protocols of the second device, such that programs above the protocol stack level are unaware that the connection is a migrated connection. More specifically, the protocol state can be infused into the protocol stack. The aggregated connection status data is also incorporated in the second device. In block 3314, the connection is continued on the second device. For example, the connection can be continued on the second device as if the connection had not previously ended anywhere.

Figure 34 illustrates an exemplary approach to connection migration from the perspective of a 3400 source device. Connection migration on the 3400 source device is performed, at least partially, by the migrator

<img file="BRPI0402591B1_D0196.tif" />

connection device 310. In an implementation described, the source device 3400 is a device that is part of the network load balancing infrastructure 106. For example, the source device 3400 may comprise a classifier 304, possibly together with a sender 302 , a 306 request router, and so on.

As illustrated, the source device 3400 includes, as parts of its network stack, a physical network interface (PNI) 3410, a mini port PNI 3408, a protocol-hardware interface 3406, a blade / block of protocol 3404 and a socket layer 3402. The source device 3400 also includes load balancing functionality 106, such as a classifier 304 at an application level and connection migrator 310. Specifically, connection migrator 310 includes an intermediate migration trigger 3414 and a migrating card 3412. Is connection migrator 310 capable *? transferring a connection from the 3400 source device.

In a described implementation, the physical network interface 3410 can be a network interface card (NIC) (for example, an Ethernet NIC), a wireless interface, and so on. Although only one physical 3410 network interface is shown, a given device may actually have multiple physical 3410 network interfaces (i.e., the source device 3400 can have multiple households). Each 3410 physical network interface typically corresponds to one or more physical network addresses.

The PNI 3408 mini-door is a software module that

137 understands and interfaces with the hardware implementation specific to the 3410 physical network interface. The 3406 hardware protocol interface is a layer that includes one or more respective interfaces between one or more respective protocols and PNI 3408 mini-port.

The 3404 protocol stack includes one or more respective modules that are each directed to one or more respective protocols. Examples of such protocols are further described below with reference to Figures 36 and 37. In a transient context, protocol stack 3404 includes a protocol state 3420 for each existing connection on the source device 3400. A socket layer 3402 sits between a program, such as load-balancing functionality 106 and protocol stack 3404. Socket layer 3402 provides APIs between load-balancing functionality 106 and protocol stack 34 04 and £ allows that programs register for connections, among other things.

intermediate migration driver 3414 or, more generally, migratory driver 3414, is located in the protocol-hardware interface layer 3406. The migrator board 3412 is located transparently between the protocol stack 3404 and the socket layer 3402.

When an initial packet (not shown) requesting a new connection is presented to the source device 3400, the packet is routed upwards from the 3410 physical network interface, to the PNI 3408 mini-port, through the protocol interface layer. -hardware 3406 and for the stack

138 • ·· · ♦ · ·· * ··· ·· * ♦ · · · · · · · · · · · ♦ · · · ··· · · · ·· ** ♦♦ · · ♦ ··· ♦ ♦ · · · ♦ ···· ·· ·· * ·· protocol 3404. As the packet traverses the one or more protocols of the 3404 protocol stack, the protocol state 3420 is created there. In addition, as a result of its initial package or as a consequence of load balancing functionality 106 accepting the connection to examine the request, data 3416 arrives at the source device 3400.

In operation, the migrating intermediary trigger 3414 deflects a copy of data 3416 to connection migrator logic 310. When load-balancing functionality 106 issues a migration connection function call, the migration function call is passed to the topmost layer of protocol stack 3404, such that aggregation of connection state 3418 can begin. The protocol state 3420 is compiled from one or more protocols in the 3404 protocol stack. In a TCP / IP implementation, the protocol status 3420 may include (i) TCP ports and source and destination IP addresses (for example, a 4-tuple TCP / IP), (ii) TCP window state, ( iii) initial sequence numbers, (iv) interruption information, (v) IP fragment ID, (vi) routing information and (vii) so on.

The aggregation of connection state 3418 also aggregates data 3416 that has been diverted to connection migrator 310 and that has already received acknowledgment from the source device 3400 (for example, by load balancing functionality 106). This aggregate connection state 3418 includes protocol state 3420 and data 3416 (and,

<img file="BRPI0402591B1_D0197.tif" />

optionally, other information related to the connection).

139

<img file="BRPI0402591B1_D0198.tif" />

Then, the aggregated connection state 3418 is sent as a binary blob (large object) 3422 away from the source device 3400, towards a target device using a reliable protocol. This binary blob 3422 can also be grouped with a flow identifier if the connection must subsequently be tunneled with tunneler 312. The tunneled flow identifiers are further described below with particular reference to Figures 38 and 39.

<img file="BRPI0402591B1_D0199.tif" />

Figure 35 illustrates an exemplary approach to connection migration from the perspective of a target 3500 device. Target device 3500 is similar to the source device 3400 with respect to the various layers / modules illustrated, including connection migrator 310. However, as illustrated, at least one application 316 at an application level interfaces with socket layer 3402. O; target device 3500 can therefore comprise a main computer 108. In addition, connection migrator 310 is able to send (upload) a connection from the source device 3400.

In an implementation described, application 316 is the destination of the packet that initiates the connection, received at source device 3400. From source device 3400, target device 3500 receives binary blob 3422. Binary blob 3422 includes a state of connection associated with the connection migrating to target device 3500 and, optionally, a flow identifier. This connection state includes protocol status 3420 and the data it received

140

<img file="BRPI0402591B1_D0200.tif" />

receipt notice 3416 (and possibly other connection-related information).

In operation, when the binary blob 3422 reaches the protocol-hardware interface layer 3406, the migrating intermediate trigger 3414 recognizes it as a blob for connection migration and bypasses it. The connection state is injected at 3502 to create the appearance for application 316 that the connection was originally terminated at target device 3500.

<img file="BRPI0402591B1_D0201.tif" />

Specifically, the protocol state 3420 of the injected connection state 3502 is infused into the protocol stack. ^:lap 3404. In an implementation described, protocol state 3420 is infused first into higher level protocols and then into lower level protocols in the 3404 protocol stack. After protocol state 3420 is infused into the protocol stack 3404, the data can be entered for the 316 application. This 3416 data can be supplied to the 316 application as if it were part of a recently ended connection and locally.

After connection state injection 3502 is. complete, the connection initiated by the packet received on the source device 3400 is successfully migrated from there to the target device 3500. Subsequent packets for the connection can be forwarded directly to the target device 3500 without passing through the source device 3400 or at least just with simple routing and no application-level analysis being applied to them. Optionally, these packages can be tunneled, such that the trigger interme141 • · ····

<img file="BRPI0402591B1_D0202.tif" />

<img file="BRPI0402591B1_D0203.tif" />

Μ * · ♦ · migrator diary 3414 effectively operates as a software-based virtual NIC that is linked to the virtual IP address.

Figure 36 illustrates an exemplary approach to a 3600 data transfer procedure for connection migration. The migration transfer procedure 3600 illustrates additional exemplary details for a connection migration by a 3400 source device. As illustrated, the general protocol stack 3404 includes a TCP stack 3404 (T), an IP stack 3404 (1) and a address resolution protocol (ARP) stack 3404 (A). However, other 3404 () specific protocol stacks can be employed alternatively.

As an example, the protocol-hardware interface layer 3406 can be realized as a network driver interface specification (NDIS) based layer in a Microsoft® Win- operating system (OS) environment; dows®. In addition, socket layer 3402 can be realized as a Winsock ™ layer in a Microsoft® Windows® OS environment.

In a described implementation, the migrating intermediate driver 3414 includes protocol-hardware interfaces 3406 at the junctions with the ARP 3404 stack (A) and with the PNI 3408 mini-port. The migrating intermediate driver 3414 serves as a transfer target in the transfer procedure migration 3600. The transfer target is a mini-port of the 3406 protocol-hardware interface, as illustrated in this example. In a 3700 migration file submission procedure (as in Figure 37), the migrating intermediate trigger

<img file="BRPI0402591B1_D0204.tif" />

142

<img file="BRPI0402591B1_D0205.tif" />

3414 serves as a file upload retractor.

More specifically, the migrating intermediate trigger 3414 is connected to each physical network interface 3410 through which a TCP connection can migrate. The migrating intermediate trigger 3414 usually operates as a crossover trigger for passing packets up or down the network stack without interacting with the packets. However, the migrating intermediary trigger 3414 interacts with connection-related packets (optionally including packets that subsequently tunnel).

The responsibilities of the intermediary trigger? migrator 3414 include: (i) acceptance of migration transfer requests; (ii) the aggregation of the protocol status information that is related to the TCP connection that migrates as if it were compiled from the specific protocol stacks 3404 (), together with data that received the receipt view to produce the information connection status; and (iii) the transmission of the aggregated connection state to a 3500 target device for a 3700 migration send procedure. A reliable wired protocol for such transmission can be shared with that used by the session tracker components 2002 and 2010 to send and receiving session information messages 2008 (for example, as described above with reference to Figure 20).

Another responsibility of the migrating intermediary trigger 3414 (for example, in a 3700 migration submission procedure) is to initiate the sending of migrated connections it receives from other devices and to temporarily store

<img file="BRPI0402591B1_D0206.tif" />

5^

143 «99 «9» 9· * »· ·· ·♦·♦ ·· ·

9 9 · · · 9 9 · Μ 9 9 * 9 9 · 99 9999 9 9 999 «9 9 99« 9 9 9 9999 9 9 9 9 999 9

999999999 99

999 99 9 99 9999 99 99 999 te (buffer) any incoming packet that is related to the migration connection, while still in the process of being sent. In order to (upload) the connection, the migrating intermediate trigger 3414 sends a sending request to the migrating card 3412. The migrating card 3412 issues an injection call to protocol stack 3404 in TCP stack 3404 (A) to instantiate the connection in protocol stack 3404 of the network stack.

The migrating card 3412 exposes a client interface to the TCP stack 3404 (T) and exposes a provider interface to the socket layer 3402. The migrating card 3412. has two roles: (i) initiate the 3600 connection migration transfer procedure on a 3400 source device and, subsequently, the 3700 migration send procedure on a 3500 target device and (ii) mediate the classification process between a computer application program 316.-; main, a load-balancing classifier program 304 and socket layer 3402. The migrating plate 3412 and the migrating intermediate driver 3414 are both further described below with reference to Figures 36 and 37.

For an exemplary 3600 migration transfer procedure, a TCP connection is migrated after classifier 304 classifies the incoming TCP connection using one, two or more of its packets. The 3600 migration transfer procedure is described in points &lt;

x&gt; to &lt;2&gt;.

In &lt;x&gt;, an initialization is performed before sorting operations. The 3404 protocol stack does • ϋ

144 «·· ·· ♦ ·· · ·· · ♦ ··· * ·· • ····· · · · ···· · · · ··· · · ······ · * * · · «· • ········« ·· • ··· ·· · ·· ···· ·· «* ··· queries in the protocol-hardware interface layer 3406 to determine which transfer capabilities , if any, are available. The migrating intermediate trigger 3414 indicates that the connection migration transfer is available and propagates the query to the PNI 3408 mini-port. If a TCP transfer capability is provided by a 3410 physical network interface, the PNI 3408 mini-port also indicates so. TCP transfer allows some TCP / IP processing to be transferred to the 3410 physical network interface hardware and involves some 3420 protocol state build. Consequently, some build and aggregation logic can be shared between the two transfer mechanisms.

In &lt;2&gt;, once a TCP connection has been classified, classifier 304 initiates a TCP connection migration to a selected host computer 108. Specifically, a migration command indicating a target device 3500 is issued via socket layer 3402 to the migrating plate 3412.

At &lt;3&gt;, the migrating card 3412 initiates the TCP connection migration to compile the TCP protocol state. Specifically, the migrating card 3412 invokes a TCP migration initiation transfer API (or more generally, a migration connection function call or migration connection command). This routine compiles the relevant state for the specific TCP connection that is used to instantiate the connection on target device 3500 again. 0 compiled protocol state 3420 includes state of layers

<img file="BRPI0402591B1_D0207.tif" />

145

<img file="BRPI0402591B1_D0208.tif" />

intermediate stack batteries, including TCP 3404 (T) stack, IP 3404 stack (1) and ARP3404 stack (A).

In &lt;4&gt;, once the 3404 protocol stack has compiled the 3420 protocol state for the TCP connection it is migrating, it invokes a migration transfer API starting at the mini-port to which it is connected; in this example, that mini-port is the 3414 migratory intermediate driver. However, in practice, there may be other intermediate drivers inserted between the proto10 colo stack 3404 and the 3414 migratory intermediate driver, such as IP QoS. If so, those IM triggers can participate in the migration, if relevant, by compiling / aggregating their state to the connection state information for the connection they are migrating. Intermediate triggers continue to propagate the migration initiation transfer call on the network stack, which eventually results in the execution of a migration transfer handler on the migrating intermediate trigger 3414. At this point, the migrating intermediate trigger 3414 also adds any data to the remaining connection status. For transferring the TÒP connection to the target device 3500.

In &lt;5&gt;, after storing / copying the connection status information for the migrating TCP connection, the migrating intermediate trigger 3414 notifies the network stack that the migration is in its final stage by invoking a complete start transfer API of migration. This complete transfer API for migration initiation follows the reverse path to the network stack, through the same triggers

146

<img file="BRPI0402591B1_D0209.tif" />

t!

To intermediaries (if any) and finally to the 3404 protocol stack. As each layer processes this call, the status information that is associated with the migrated connection can be released. Until the processing of this call is complete, each layer can send update notifications to the protocol stack to update any part of the connection state that has changed since the migration was initiated.

In &lt;6&gt;, when the complete transfer initiation migration routine reaches the TCP 3404 (T) stack, TCP silently (that is, no restore is sent to client 108) closes the connection, emptying all the state associated with the connection migrated and propagates the complete transfer transfer initiation call to the 3412 migrating card. At this point, the network stack is free of any residual knowledge of the migrated TCP connection.

In &lt;7&gt;, when the complete migration initiation transfer call returns to the migrating intermediate trigger 3414 (via migrating connection portion 310 of the migrating card 3412), the migration of the TCP connection from the source device 3400 to the device target 3500 can start with transferring the connection state to it. The connection status can be transferred asynchronously and reliably.

Once the migration has started, the source device 3400 is also responsible for ensuring that subsequent data from client 108 is forwarded to target device 3500. Consequently, even

147

<img file="BRPI0402591B1_D0210.tif" />

after the connection has successfully migrated to the target, the originator retains some amount of state for the connection (for example, a routing table entry) in order to properly route subsequent packets to the target. When the connection is terminated, the target notifies the originator to allow it to purge any residual state that remains in the migrated connection.

In addition, as a consequence of the asynchronous nature of connection migration, data packets for the migration connection that are sent by the source device 3400 (or a designated sender for this, if a separate device) can start arriving at the target device 3500 before target device 3500 receives the migrated connection state. The migrating intermediate trigger 3414 on target device 3500 is responsible for buffering packets until the associated migrated connection is established on target device 3500.

Figure 37 illustrates an exemplary approach to a 3700 send procedure for a connection migration. The 3700 migration submission procedure illustrates additional exemplary details for a connection migration by the target 3500 device.

When a migrated connection arrives at target device 3500, it is relayed to the migrating intermediate trigger 3414 for processing. After amalgamating and assimilating the migrated connection state, the migrating intermediate trigger 3414, in conjunction with the migrating plate 3412, injects the migrated connection into the local network stack of a ma-

<img file="BRPI0402591B1_D0211.tif" />

<img file="BRPI0402591B1_D0212.tif" />

148 • · * · · · * · · · · · · · · * «· ·« »··« · »« • · · · · · · · · · · · Transparent line to application 316. exemplary 3700 migration submission procedure, migration of a TCP connection at points &lt;1&gt; to &lt;8&gt; is described.

In &lt;1&gt;, as described above with reference to the migration transfer procedure 3600, an initialization is performed before the accommodation operations of the application. Specifically, the 3404 protocol stack queries as to what transfer capabilities, if any, are available. 0 intermediate driver mi10 grador 3414 fills the query for migration support of the TCP connection to indicate which connection migration transfer is available and also to propagate the query to PNI 3408 mini-port for possible transfer capabilities with TCP wrap.

In &lt;2&gt;, when the connection migration data arrives at the target device 3500, the connection migration information (for example, a clustered 3422 binary blob) is delivered to the migrating intermediate driver 3414. The migrating intermediate driver 3414 reassembles the connection state, matches it to any associated data that arrived during the migration and prepares for transfer on the network stack. Any data coming from client 102 that arrives during the transfer process of the migrated connection, is temporarily stored (buffered) by the migrating intermediate driver 3414. When the migration is complete, the data will be delivered to application 316.

In &lt;3&gt;, to start sending the migrated connection to the LAN stack, the intermediate trigger migrates10

149

<img file="BRPI0402591B1_D0213.tif" />

dor 3414 notifies the migrating card 3412 that the migrated connection request has arrived. The migrating intermediate trigger 3414 also delivers the connection state (or at least the protocol state 3420) to the migrating card 3412.

In &lt;4&gt;, the migrating card 3412 starts sending the migrated connection by invoking a TCP start injection routine (or more generally, a protocol infusion state routine) and by providing the migrated protocol state 3420 to the TCP stack 3404 (T). In &lt;5&gt;, TCP / IP recreates the migrated connection across the 3404 protocol stack using the provided protocol state 3420. This 3420 protocol state can include one or more of the transport state (TCP), path state (IP), neighbor state and the next direct transmission path (ARP), and so on.

<img file="BRPI0402591B1_D0214.tif" />

In &lt;6&gt;, if the migrated connection is successfully reestablished on target device 3500, TCP initiates a connection event with a client portion of the migrating card 3412 to indicate that a new connection has been established. There are several possible reasons for failure, but common reasons can include the lack of corresponding monitoring, routing failure, etc. In these cases, where the network stack is unable to reestablish the migrated connection, no connection event is indicated and a failure state is specified in the complete injection start call. Connection migration 310 is responsible for clearing the migration and sending a restore notification back to client 102 to abandon the connection.

150

In &lt;7&gt;, the migrating card 3412 acts as a provider to propagate the connection event to socket layer 3402 in order to indicate to the monitoring application 316 that a new connection has been established. If the 316 application accepts the connection, it processes requests and responds through normal read and write socket operations; the 316 application may not know that the connection has been migrated. If the connection is not accepted by application 316, TCP terminates the connection but does not send a restore notification back to client 102. Again, a failure state is specified in the complete injection start call and connection migration 310 is responsible for clearing the migration and sending a restore notification back to client 102 to abandon the connection.

A special situation arises when application 316 and classifier 304 are placed on the same device: the migrating plate 3412 can arbitrate between them. When both classes of programs reside on the same main computer 108, both can serve the same IP address (es) and port (s). Typically, however, TCP has one monitor per unique IP address and port. Consequently, the migrating card 3412 can obscure a configuration in which two programs are listening on the same address and IP port by multiplexing the two sockets on a single server at the TCP layer.

In such a case, when connection events arrive at the client portion of the migrating card 3412, the migrating card 3412, as a provider, determines on which monitor socket

<img file="BRPI0402591B1_D0215.tif" />

151 • ·· · · * ·· ···· ·· • ·· · · ♦ ·· · · · • ··· * · ····· · • ·· * · * · · «* *« · · ··· «·· ·· ··· ration deliver connection notification at socket layer 3402. If there is only one socket meeting the corresponding IP address and port, then that socket receives the connection event. If there is more than one monitored socket, then the reception depends on the context in which the connection event is indicated. If the connection event is a new connection to a virtual IP address, then the connection event is delivered to classifier 304; if the connection event is a dedicated IP address. (IP address with unbalanced load) or the result of sending a migrated connection - / - then the connection event is delivered to the target application 316.

In &lt;8&gt;, once the injection of the migrated connection is complete, TCP notifies the migrating card 3412 when invoking the complete injection initiation handler provided. A status code is provided to notify the migrating card 3412 whether the connection was sent successfully or not. If sending of the migrated connection fails, connection migrator 310 is responsible for clearing the migration and notifying client 102 that the connection has been abandoned, sending him a restore. If the migrated connection has been successfully injected into the LAN stack, the migrating intermediate trigger 3414 can begin delivering any temporarily stored data from client 102, passing the received packet (s) through the receiving path. of the 3406 protocol-hardware interface package.

When a migrated connection is terminated (because sending has failed, because the migrated connection is subsequently closed using normal means, etc.), the target device

152

<img file="BRPI0402591B1_D0216.tif" />

3500 notifies the source device 3400. The source device 3400 uses these notifications to more efficiently and reliably clear the slow state for migrated connections, including routing table entries. Therefore, in order to have successful migrated connections that end arbitrarily in the future, the migrating card 3412 can monitor its activity and notify the migrating intermediate trigger 3414 when the sockets for it are closed.

<img file="BRPI0402591B1_D0217.tif" />

<img file="BRPI0402591B1_D0218.tif" />

Figure 38 illustrates an exemplary approach to packet tunneling between a sender 302 and a computer / host 108. Encapsulated packets 3808 can be tunneled from sender 302 to host computer 108 without incurring the time spent for each transmitted packet. As further described below, tunneling is performed using a flow identifier 3814 and 4 'tunnel mapping tables 3806 and 3810 of tunnelers 312 (F) and 312 (H), respectively, from sender 302 and main computer 108, respectively. The flow identifier 3814 is inserted into the encapsulated packets 3808.

As noted above with reference to Figure 32, packets for a connection that arrive after a connection migration can be routed by the sender 302 to the main computer 108 (1) using tunneling performed by a tunneler 312. In (8) ( of Figure 32), sender 302 sends such subsequent packets from sender 302 having an F network address to main computer 108 (1) having an H 1 network address. As described

153

<img file="BRPI0402591B1_D0219.tif" />

<img file="BRPI0402591B1_D0220.tif" />

above with reference to Figure 4, the sender 302 can perform NAT, half NAT, tunneling, etc., in order to route the packets that arrive to the main computer 108 (1).

Such incoming packets include a destination IP address of the virtual IP address (VIP) and a source IP address of Cl for packets arriving from client 102 (1). Packets that are routed to host computer 108 (1) have a destination IP address of H1 and a source address of Cl (for half NAT) or F (for full NAT). This rewriting of addresses may interfere with some protocols that expect both client 102 (1) and main computer 108 (1) to have identical views of the source and destination addresses.

<img file="BRPI0402591B1_D0221.tif" />

Furthermore, at least with respect to full NAT, the return paths from main computer 108 (1) to client 102 (1) that do not run through sender 302 are prohibitive because main computer 108 (1) does not know customer address 102 (1). Direct paths from main computer 108 (1) to client 102 (1) are desirable in situations where traffic from main computer 108 (1) to client 102 (1) is especially high and / or significantly higher than that traffic in the opposite direction (for example, when main computer 108 (1) provides streaming media to the client

Tunneling done by tunnelers 312, as described here, can provide identical views with respect to the source and destination addresses (and ports) for customers25 102 (1))

154 102 and applications 316 on the main computers 108. By way of example and with reference to Figures 34 and 35, the tunneler 312 in each sender 302 and main computer 108 can operate as part of or in conjunction with a 3414 migrating intermediate driver of a connection migrator 310.

In an implementation described for Figure 38, connection migrator 310 provides a 3812 tunnel mapping between a stream identifier 3814 and a 4-tuple TCP / IP 3804. Connection migrator 310 can be associated with a classifier 304 and the connection migrator 310 (optionally together with such a classifier 304) can be located on the same device as sender 302. Alternatively, connection migrator 310 (as well as classifier 304) may be located on a device other than sender 302. Encapsulation mapping 3812 may be provided, alternatively, by or in conjunction with tunneling functionality 312 which is, for example, example, located in and / or associated with a 304 classifier.

Because it is mapped to a 4-tuple TCP / IP 3804 in tunnel mapping 3812, flow identifier 3814 serves to identify a stream of encapsulated packets 3808 for a particular connection. TCP / IP 4-tuple 3804 includes network addresses (and ports, etc.) for the source and destination for a particular connection according to a TCP / IP protocol or any similar or analogous protocol. 0 stream identifier 3814 is 32 bits in an implementation described, because 32 bits are available for connections established according to an IPv4 Internet protocol. However,

155 ·· ··· «·· • · * · · · · ···· · · 3814 stream identifiers of other sizes can be used alternatively, especially for other protocols such as IPv6 Internet, UDP and so on.

3814 flow identifiers can be generated using any appropriate mechanism, such as incrementing the connection count. Furthermore, TCP / IP 4-tuple is, more generally, a source / destination pair. Each source value and each destination value of an individual source / destination pair, can include a network node identifier (for example, network address, port, some combination of them, etc.) for the source and destination, respectively , of a given packet that propagates over a particular connection.

connection migrator 310 provides tunnel mapping 3812 to host computer 108. Tunneler 312 (H) on host computer 108, stores tunnel mapping 3812 in tunnel mapping table 3810 as an entry in tunnel table 3810 (1). The tunneler 312 (H) can, after that, use flow identifier 3814 to map and identify the particular connection corresponding to TCP / IP 4-tuple 3804. Tunnel mapping 3812 can optionally be provided to host computer 108 as part of a 3422 clustered binary blob in a connection migration operation.

sender 302 also includes a tunneling component 312 (F) with an encapsulation mapping table 3806. Encapsulation mapping table 3806 stores an encapsulation mapping entry 3806 (1) that links / maps TCP / IP 4-tuple 3804 to a particular connection to

<img file="BRPI0402591B1_D0222.tif" />

156 a 3814 flow identifier. Tunneler 312 (F) also receives mapping information for tunnel mapping input 3806 (1) from connection migration 310 (for example, as a 3812 tunnel mapping).

Although only one 3806 (1) and 3810 (1) tunnel mapping entry is shown, each of the 3806 tunnel mapping table and 3810 tunnel mapping table can have multiple entries. These 3806 and 3810 encapsulation mapping tables can be combined with other information, such as tables for session tracker session information 308.

When a transmitting device (such as sender 302) and a receiving device (such as host computer 108) for encapsulated packets 3808 only tunnel together, it is likely that your encapsulation mapping tables have the same encapsulation mapping entries . On the other hand, tunnel mapping table 3806 and tunnel mapping table 3810 are likely to have a different total set of tunnel mapping entries 38060 and tunnel mapping entries 3810 (), respectively.

In operation, a packet arriving 3802 for a particular connection is received at sender 302. The private connection is associated with TCP / IP 4-tuple 3804. The packet arriving 3802 includes TCP / IP 4-tuple 3804 with an address Source IP (from a client 102), a destination IP address (the virtual IP), a source TCP port (from client 102) and a destination TCP port.

<img file="BRPI0402591B1_D0223.tif" />

157

<img file="BRPI0402591B1_D0224.tif" />

<img file="BRPI0402591B1_D0225.tif" />

Tunneler 312 (F) accepts incoming packet 3802 for tunneling to main computer 108. Using TCP / XP 4-tuple 3804, tunneler 312 (F) accesses tunnel mapping table 3806 to locate the mapping entry for 3806 package (1). Flow identifier 3814 is taken from tunnel mapping entry 3806 (1) as being bound / mapped to TCP / IP 4-tuple 3804.

To create the 3808 encapsulated packet, tunneler 312 (F) inserts flow identifier 3814 into the source and destination port portions of the 4-tuple TCP / IP header 3804. For an IPv4 Internet implementation, these two TCP port portions provide 32 bits of total space. In addition, for the source portion of the IP address of the 4-tuple TCP / IP header 3804, tunneler 312 (F) inserts the sender's IP address F (forwarder) 302. For the destination portion of the IP address of the 4-tuple TCP / IP header 3804, tunneler 312 (F) inserts the IP address H of the host computer (host) 108.

Sender 302 routes / transmits the encapsulated packet 3808 to the main computer 108 and the main computer 108 receives the encapsulated packet 3808 from the sender 302. The tunneling component 312 (F) in the main computer 108 detects that the encapsulated packet 3808 is a packet that has suffered tunneling, from which the encapsulation must be removed.

flow identifier 3814 is extracted from the encapsulated packet 3808 and is used to search for the corresponding TCP / IP 4-tuple 3804 that is bound to it in the encapsulation mapping entry 3810 (1) of the encapsulation mapping table 3810. TCP / IP 4-tuple 3804 is used by tu25

158

<img file="BRPI0402591B1_D0226.tif" />

«· Nelador 312 (H) to recreate the 4-tuple TCP / IP header 3804 as originally received in the packet that arrives 3802 at sender 302.

Specifically, the sender's IP address F 302

<img file="BRPI0402591B1_D0227.tif" />

is replaced by the source IP address and the IP address H of the host computer 108 is replaced by the destination IP address. In addition, stream identifier 3814 is replaced by the source TCP port and destination TCP port. The package from which the encapsulation was taken is then indicated to the network stack of the main computer 108 for the target application 316.

More generally, a portion of a packet header, including a portion of a source / destination pair, for a given packet that is not necessarily used to communicate the given packet, can be used to load a 3814 flow identifier. By previously providing at least part of the source / destination pair on main computer 108, a flow identifier 3814 can be used for tunneling (for example, encapsulating and / or un-encapsulating) packets without incurring time spent on encapsulation on each package. In addition, packets that are full in size with respect to a given protocol can be tunneled without being split.

Figure 39 is a flow diagram 3900 illustrating an exemplary method for tunneling packet between a first device and a second device. For example, the first device and the second device can correspond to a 3400 source device and a device

159 * · · · • · · · · ······ « • * · · «· · »·

<img file="BRPI0402591B1_D0228.tif" />

target 3500, respectively, of the load-balancing infrastructure 106 and a cluster of main computers 108, respectively. However, tunneling can be used in non-load-balanced implementations.

The 3900 flow diagram includes twelve 39023924 blocks. Although the 3900 flow diagram actions can be performed in other environments and with a variety of software schemes, Figures 1-3, 32, 34, 35 and 38 are used in particular to illustrate certain aspects and examples of the method.

<img file="BRPI0402591B1_D0229.tif" />

In block 3902, a mapping of a stream identifier to TCP / IP 4-tuple 3804 is sent to a target device from a source device. For example, the source device 3400 can send a tunnel mapping 3812 that links a stream identifier 3814 to a TCP / IP 4-tuple 3804. In block 3914, the mapping of the stream identifier to the TCP / IP 4-tuple 3804 is received at the target device from the source device.

For example, target device 3500 receives encapsulation mapping 3812 that links flow identifier 3814 to TCP / IP 4-tuple 3804 from source device 3400.

Alternatively, target device 3500 may receive encapsulation mapping 3812 from another device. As indicated by the dotted arrows 3926 and 3928, the actions of blocks 3904-3912 and blocks 3916-3924 may occur at some point after the actions of blocks 3902 and 3914, respectively.

160

<img file="BRPI0402591B1_D0230.tif" />

At block 3904, an incoming packet is received at a customer's home device. For example, a packet arriving 3802, having a header with TCP / IP 4-tuple 3804, can be received at the source device 34 00 of a client 102. In block 3906, a flow identifier is searched for a corresponding connection to the client packet using TCP / IP 4-tuple 3804 of the incoming packet. For example, flow identifier 3814 can be searched for connection to client 102 using TCP / IP 4-tuple 3804 which is mapped to it in a tunnel mapping entry 3806 (1) of a tunnel mapping table 3806.

In block 3908, the source IP and destination IP of the incoming packet are replaced by a source IP address of the source device and a target IP address of the target device, respectively. For example, the source device 3400 can replace the IP address portions of the TCP / IP 4-tuple portion 3804 of a header of the incoming packet 3802 with IP addresses of the source device 3400 and target device 3500.

In block 3910, the source port and destination port of the incoming packet are replaced by the flow identifier. For example, the source device 3400 can replace the source and destination TCP ports of the TCP / IP 4fold portion 3804 of the incoming packet header 3802 with the flow identifier 3814. At block 3912, the encapsulated packet is sent from the source to the target device. For example, source device 3400 can send an encapsulated packet 3808 to target device 3500.

161

In block 3916, the encapsulated packet is received at the target device from the source device. For example, target device 3500 can receive encapsulated packet 3808 from source device 3400. In block 3918, TCP / IP 4-tuple 3804 is searched for the connection corresponding to the packet received from the client using the flow identifier. For example, target device 3500 can access a tunnel mapping table 3810 on a tunnel mapping entry 3810 (1) that maps stream identifier 3814 to TCP / IP 4-tuple 3804.

In block 3920, the source IP address and the target IP address are replaced by the source IP address and destination IP address, respectively, using the searched TCP / IP 4-tuple 3804. For example, target device 3500 can replace the IP addresses of the source device 3400 and target device 3500 in the encapsulated packet 3808 with the source IP address and destination IP address of the TCP / IP 4tuple 3804, as obtained from the mapping table 3810 package.

In block 3922, the flow identifier is replaced by the source port and the destination port of the incoming packet using the sought-after TCP / IP 4-tuple 3804. For example, target device 3500 can replace flow identifier 3814 in encapsulated packet 3808 with source TCP port and destination TCP port of TCP / IP 4-tuple 3804. In block 3924, the client packet is referred to an application in the target device. For example, a version taken from the encapsulated package 3808, or arrives package162 ·· • ·· • «· • · · • ···· · ·· ··

<img file="BRPI0402591B1_D0231.tif" />

• ···· ·· «· ·· · · • ··· of 3802, is indicated for application 316 of target device 3500.

The actions, aspects, characteristics, components, etc., of Figures 1 to 39 are illustrated in diagrams that are divided into multiple blocks. However, the order, interconnections, design, etc., in which Figures 1 to 39 are described and / or shown, should not be considered as a limitation and any number of blocks can be combined, rearranged, increased, omitted, etc., in any way to implement one or more systems, methods, devices, procedures, media, APIs, devices, arrangements, etc., for network load balancing. Furthermore, although the description here includes references to specific implementations (and the exemplary operating environment in Figure 40), the illustrated and / or described implementations can be implemented on any appropriate hardware, software, firmware or combination and using any organization appropriate network (s), transport / communication protocol (s), application programming interface (APIs), client-server architecture (s), and so on.

Exemplary Operating Environment for Computer or

Other Device

Figure 40 illustrates an operating computing environment (or general device) 4000 that is capable of implementing (fully or partially) at least one system, device, device, component, arrangement, protocol, approach, method, procedure, media, API, some combination of these, etc., for network load balancing, as described

163 on here. The 4000 operating environment can be used in the computer and network architectures described below or in a stand-alone situation.

The exemplary operating environment 4000 is just an example of an environment and is not intended to suggest any limitations on the scope of use or functionality of the applicable device architectures (including computer, network node, entertainment device, mobile accessory, general electronic device, etc.). ). The 4000 operating environment (or its devices) should also not be interpreted as having any dependency or requirement relating to any or any component fuel, as shown in Figure 40.

In addition, network load balancing can be implemented with numerous other environments or device configurations (including computer systems) with general purpose or special purpose. Examples of well-known devices, systems, environments and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, thin clients, thick clients, personal digital assistants (PDAs) or mobile phones, watches , hand-held or laptop devices, multi-processor systems, microprocessor-based systems, coding boxes, consumer programmable electronics, video game machines, game consoles, portable or hand held game units, networked PCs, minicomputers, large computers (mainframe), network nodes,

<img file="BRPI0402591B1_D0232.tif" />

164

<img file="BRPI0402591B1_D0233.tif" />

distributed or multiple processing computing environments, which include any of the above systems or devices, some combinations of these, and so on.

Network load balancing implementations can be described in the general context of instructions executable by the processor. In general, instructions executable by the processor include routines, programs, protocols, objects, interfaces, components, data structures, etc. that perform and / or allow particular tasks and / or implement particular abstract data types. Network load balancing, as described in certain implementations here, can also be practiced in distributed processing environments, where tasks are performed by remotely connected processing devices that are connected via a link and / or communications network. Especially in a computing device environment, instructions executable by the processor can be located on separate storage media, executed by different processors and / or propagated on the transmission media.

Exemplary operating environment 4000 includes a general purpose computing device in the form of a computer 4002, which can comprise any device (e.g., electronic) with computing / processing capabilities. Components of computer 4002 may include, but are not limited to, one or more processors or processing units 4004, a 4006 system memory, and a 4008 system bus that couples several

165

<img file="BRPI0402591B1_D0234.tif" />

system components, including processor 4004, to system memory 4006.

4004 processors are not limited by the materials from which they are formed or the processing mechanisms employed in them. For example, 4004 processors can comprise semiconductors and / or transistors (for example, electronic integrated circuits (ICs)). In such a context, instructions executable by the computer can be instructions executable electronically. Alternatively, the mechanisms for or for 4004 processors and thus for or for computer 4002 may include, but are not limited to, quantum computing, optical computing, mechanical computing (for example, using nanotechnology) and so on.

4008 system bus represents one or more of any of many types of wired or wireless bus structures, including a memory bus or memory controller, a point-to-point connection, a switch, a peripheral bus, an accelerated graphics port and a local processor or bus that uses any of a variety of bus architectures. As an example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA bus (EISA), a Video Electronics Standards Association (VESA) local bus, a Peripheral Component bus Interconnects (PCI), also known as the Mezzanine bus, some combinations of these and so on.

<img file="BRPI0402591B1_D0235.tif" />

166

<img file="BRPI0402591B1_D0236.tif" />

The 4002 computer typically includes a variety of media accessible by the processor. Such media can be any available media that is accessible by the 4002 computer or another device (for example, electronic) and includes both volatile and non-volatile media, removable and non-removable media and storage and transmission media.

System memory 4006 includes storage media accessible by the processor in the form of volatile memory, such as random access memory (RAM) 4040 and / or non-volatile memory, such as read-only memory (ROM) 4012. A basic system of input / output (BIOS) 4014, containing the basic routines that help transfer information between elements inside the computer 4002, such as during startup, is typically stored in ROM 4012. RAM 4010 typically contains data and / or program modules / instructions that are immediately accessible to and / or are currently being operated by processing unit 4004.

The 4002 computer may also include other removable / non-removable and / or volatile / non-volatile storage media. As an example, Figure 40 illustrates a hard disk drive or 4016 disk drive arrangement for reading from and writing to (typically) non-removable, non-volatile magnetic media (not shown separately); a 4018 magnetic disk drive to read from and write to (typically) a removable, non-volatile 4020 magnetic disk (for example, a floppy disk); and a 4022 optical disc drive to read from and / or write to (typically) a device

<img file="BRPI0402591B1_D0237.tif" />

167 ·· ··· ·· · · «·· ···· ·· • ·· ···· · · * ··· · ·· · · ······ · · · ···· · · · »··» ·· ·· ··· removable, non-volatile optical 4024, such as a CD, DVD or other optical media. The 4016 hard disk drive, the 4018 magnetic disk drive and the 4022 optical disk drive are each connected to the 4008 system bus via one or more 4026 storage media interfaces. Alternatively, the hard disk drive 4016, the magnetic disk drive 4018 and the optical disk drive 4022 can be connected to the system bus 4008 by one or more other separate or combined interfaces (ion shown).

Disk drives and their associated media accessible by the processor provide non-volatile storage of instructions executable by the processor, such as data structures, program modules and other data for the 4002 computer. Although the exemplary computer 4002 illustrates a 4016 hard disk, a removable magnetic disk 4020 and a removable optical disk 4024, it should be appreciated that other types of media accessible by the processor can store instructions that are accessible by a device, such as magnetic tapes or other magnetic storage devices, instant memory, compact discs (CDs), digital versatile discs (DVDs) or other optical storage, RAM, ROM, programmable, electrically erasable read-only memories (EEPROM), and so on. Such media may also include special-purpose chips or wired IC. In other words, any media accessible by the processor can be used to make the storage media of the exemplary operating environment 4000.

<img file="BRPI0402591B1_D0238.tif" />

168

<img file="BRPI0402591B1_D0239.tif" />

Any number of program modules (or other units or instruction / code sets) can be stored on hard disk 4016, magnetic disk 4020, optical disk 4024, ROM 4012 and / or RAM 4040, including, by way of general example, a 4028 operating system, one or more 4030 application programs, other 4032 program modules and 4034 program data.

A user can enter commands and / or information on computer 4002 via input devices such as a 4036 keyboard and a 4038 pointing device (for example, a mouse). Other 4040 input devices (not shown specifically) may include a microphone, joystick, game pad, satellite disk, serial port, scanner and / or the like. These and other input devices are connected to the processing unit 4004 via 4042 input / output interfaces that are coupled to the 4008 system bus. However, input devices and / or output devices can be connected, instead, by other interface and bus structures, such as a parallel port, a game port, a universal serial bus (USB) port, a infrared port, an IEEE 1394 (Firewire) interface, an IEEE 802.11 wireless interface, a Bluetooth® wireless interface, and so on.

A 4044 display / monitor or other display device can also be connected to the 4008 system bus via an interface, such as a 4046 video adapter. The 4046 video adapter (or another component) can be either can include a graphics card for

169 ·· ··· ·♦ · .· ·· ···· ·· *···· ····· ·· • ·· »· · ♦ · · ··· · · ·· · · ······ · · · ··· ·······*· · ··· ·· · ·· ···· ·· ♦·

<img file="BRPI0402591B1_D0240.tif" />

process graphics-calculations and to handle demanding display requirements. Typically, a graphics card includes a graphics processing unit (GPU), video RAM (VRAM), etc. to facilitate the expeditious display of graphics and the performance of graphics operations. In addition to the 4044 monitor, other peripheral output devices can include components such as speakers (not shown) and a 4048 printer, which can be connected to computer 4002 via 4042 input / output interfaces.

computer 4002 can operate in a networked environment using logical connection to one or more remote computers, such as a 4050 remote computing device. As an example, the 4050 remote computing device can be a personal computer, a portable computer (for example, laptop computer, tablet computer, PDA, mobile station, etc.), a palm-sized or pocket-sized computer , a clock, a game device, a server, a router, a networked computer; a peer device, another network node, or another type of device as listed above, and so on. However, the remote computing device 4050 is illustrated as a portable computer that can include many of the elements and features described here with respect to computer 4002.

Logical connections between computer 4002 and remote computer 4050 are illustrated as a local area network (LAN) 4052 and a general wide area network (WAN) 4054. Such networked environments are common in offices, corporate computer networks, intranets, Internet, networks of

<img file="BRPI0402591B1_D0241.tif" />

170 landline and mobile phone, networks with wireless and ad hoc infrastructure, other wireless networks, gaming networks, some combinations of them and so on. Such communications networks and connections are examples of transmission media.

When implemented in a LAN networked environment, computer 4002 is usually connected to LAN 4052 via a 4056 network interface or adapter. When implemented in a WAN network environment, computer 4002 typically includes a 4058 modem or other means for establishment, communications on WAN 4054. The 4058 modem, which can be internal or external to computer 4002, can be connected to the system bus 4008 via 4042 input / output interfaces or any other appropriate mechanism. It should be appreciated that the illustrated network connections are exemplary and that other means for establishing communication links between computers 4002 and 4050, can be employed.

In addition, other hardware that is specifically designed for servers, can be employed, for example, SSL acceleration cards can be used to transfer SSL computations. Additionally, especially in

<img file="BRPI0402591B1_D0242.tif" />

a network load balancing operating environment, TCP transfer hardware and / or packet sorters on network interfaces or 4056 adapters (for example, on network interface cards) can be installed and used as server devices.

In a networked environment, such as that illustrated in the 4000 operating environment, program modules or other instructions that are illustrated with respect to com171 • ···· · ····· · • ·· «··· · · · ··· ··· ·· · ·· ·· * · ·· ··

<img file="BRPI0402591B1_D0243.tif" />

put 4002 or parts thereof, can be stored wholly or partially on a remote media storage device. By way of example, remote application programs 4060 reside in a memory component of remote computer 4050 but can be used or accessed via computer 4002. In addition, for purposes of illustration, the 4030 application programs and other instructions executable by the processor, such as the 4028 operating system, are illustrated here as discrete blocks, but it is recognized that such programs, components and other instructions reside at different times in different storage components of the computing device 4002 (and / or remote computing device 4050) and are executed by the processor (s) 4004 of the computer 4002 (and / or those of the computing device remote computing 4050).

<img file="BRPI0402591B1_D0244.tif" />

Although systems, media, devices, methods, procedures, devices, techniques, schemes, approaches, arrangements and other implementations have been described, in specific language for structural, logical, algorithmic, and functional items and / or diagrams, it is understood that the invention defined in the appended claims is not necessarily limited to the features or diagrams described. Instead, specific features and diagrams are described as exemplary ways of implementing the claimed invention.