|Publication number||US7047301 B2|
|Application number||US 09/773,427|
|Publication date||May 16, 2006|
|Filing date||Jan 31, 2001|
|Priority date||Jan 31, 2000|
|Also published as||US7707289, US20010047415|
|Publication number||09773427, 773427, US 7047301 B2, US 7047301B2, US-B2-7047301, US7047301 B2, US7047301B2|
|Inventors||Bryan D. Skene, Peter M. Thornewell|
|Original Assignee||F5 Networks, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (62), Non-Patent Citations (3), Referenced by (36), Classifications (24), Legal Events (7)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This utility patent application is a continuation of a previously filed U.S. provisional patent application, U.S. Ser. No. 60/179,051 filed on Jan. 31, 2000, the benefit of the filing date of which is hereby claimed under 35 U.S.C. §119(e).
The present invention relates to persistent access to virtual servers and, more particularly, to persistent access to load balanced virtual servers distributed across a wide area network (WAN).
As the Internet continues to grow, and as more and more users begin to visit Web sites, the demand for Web servers grows. For a small company, one server may be enough to accommodate users accessing the company's website. A medium sized company may have an array of servers located at one site and managed by a SAC (SAC). A SAC receives requests from users to view content on a company's site and then selects a particular server controlled by the SAC, possibly using load balancing metrics. An enterprise sized business often has SACs placed in many different topological locations. Each SAC controls a different array of servers. Ideally, when a user requests a service, a WAN load balancing mechanism refers the user's request to the SAC best able to deal with the user's request.
A problem occurs when a user is engaged in a transaction-oriented process. The user may be shopping online at a retailer's website and filling a shopping cart with items to be purchased later. A SAC responding to requests to the retailer's website will assign the user's request to a server. The user's computer and the server will establish a session. In the middle of a transaction, the user may decide to discontinue the session and visit a different website or engage in another activity which closes the session the user has with the server containing the shopping cart items. Later, the user may decide to complete the transaction and purchase the items previously placed in the shopping cart. When the user returns to the retailer's website, the user may find that the shopping cart no longer contains the items the user previously selected. This may occur because the user's requests are not referred to the same server. When the user returns to complete the transaction, the user's request may be referred to a server that is unaware of the user's previous actions, e.g., placing items in the shopping cart.
Generally, the more layers of load balancing that are employed, the more difficult it becomes to refer a user's request to the same server. For example, when no load balancing is employed, e.g. when a company only employs one Web server and all requests are serviced by the server, the user requests only have one server to go to. To maintain a shopping cart for the user, the Web server needs to recognize that the request comes from a prior user and retrieve the appropriate data, e.g., the items in the shopping cart.
When a company has servers managed by a SAC, more is required to provide that all of one user's requests go to the same server persistence). Merely having the server recognize that a request comes from a prior user is not usually enough. Without information sharing among servers, if the SAC refers a subsequent request to a different server, the different server usually will have no information about what items the user had in a shopping cart. Therefore, in addition to the server recognizing a subsequent request from the user and retrieving the appropriate information, the SAC should refer the subsequent request to the server the SAC referred the user's prior requests to.
When a company has SACs load balanced by a WAN load balancing mechanism, even more is required to provide for persistence. A large company may have server arrays placed in several geographical areas with each server array managed by a SAC. Information available to a SAC such as user IP address may not be available to the WAN load balancing mechanism. If the WAN load balancing mechanism refers a subsequent user request to a different SAC than prior requests were referred to, persistence may be lost.
In accordance with the present invention, there is provided an apparatus and method for providing persistence across multiple requests in a WAN load-balanced environment. The invention replaces a domain name system (DNS) server with one or more extended DNS (EDNS) servers. The EDNS server load balances traffic and maintains information about requests from local domain name system (LDNS) servers.
In one aspect of the invention, modulus arithmetic is used to increase persistence. When an LDNS server requests a domain name resolution, the EDNS server determines which virtual servers in which SACs are available and uses modulus arithmetic to select a virtual server. The LDNS server is then referred to a SAC managing the selected virtual server and user requests are directed to the virtual server. This approach decreases the connections broken between users and servers as servers become available or unavailable.
In another aspect of the invention, topology information is used to increase persistence. When an LDNS server requests a domain name resolution, the EDNS server refers the LDNS server to the SAC servicing requests from that LDNS server. A group of LDNS servers may be referred to the same SAC. Typically, this “topological” approach provides persistence as long as a user uses the same LDNS server. It may also provide persistence even if a user uses a different LDNS server for some requests, provided that the different LDNS server is also mapped to the same SAC.
In yet another aspect of the invention, the EDNS server maintains information about which LDNS server was referred to which SAC. In this dynamic approach, the EDNS server keeps track of which SAC it referred an LDNS server to when the LDNS server requested a domain name resolution. When the LDNS server requests the same domain name resolution again, the EDNS server uses the previous information to refer the LDNS server to the previously referred to SAC. This allows the EDNS server to use more sophisticated load balancing techniques while maintaining persistence.
In another aspect of the invention, more than one EDNS servers are dynamically load balancing requests from LDNS servers. In this aspect of the invention, the EDNS servers periodically share request information so that each EDNS server can refer a subsequent request from a previous LDNS server to the appropriate SAC.
These and various other features as well as advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings.
In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanied drawings, which form a part hereof, and which are shown by way of illustration, specific exemplary embodiments of which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims. Prior to describing the invention in greater detail, a list of some terms and their definitions is provided below.
Definition of Terms
Client/Server—Client refers to a process or electronic device requesting information or services from another process or electronic device. The other process or electronic device is frequently referred to as a server. A server provides requested information or services to another process or electronic device. A process or device that acts as a client at times may at other times act as a server. Conversely, a process or device that acts as a server may at other times act as a client. In addition, a client and a server may physically reside on the same electronic device.
Domain name resolution—A process by which a domain name is translated into an IP address. For one implementation of domain name resolution see Paul Albitiz & Cricket Liu, DNS and BIND (3rd ed. 1998).
Including—Unless explicitly otherwise noted or clear from the context, including means “including, but not limited to.”
Illustrative System for Providing Persistence
SACs 101, 102, and 103 manage virtual server arrays 110, 111, and 112, respectively. SACs 101–103 interface with Internet 170. SAC 101 may be used, for example, to load balance requests to a company's web site to the servers in virtual server array 110. When a request comes for information or services, a server array controller, such as SAC 101, refers the request to one of the servers in the server array it manages, e.g. server array 110. For WAN load balancing, SACs 101–103 may be located in different geographical locations to better handle company web site requests from different geographical locations.
Virtual server arrays 110–112 are connected to SACs 101–103, respectively. A virtual server array may include one or many physical servers. When a virtual server array includes more than one physical server, the physical servers may be of the same processing power or of unequal processing power. Furthermore, when multiple physical servers implement a virtual server array, each physical server may represent a different number of virtual servers.
Client machines, such as clients 150, 151, and the clients in client pools 140 and 141, are sometimes shown interfacing directly with LDNS servers and at other times interfacing with LDNS servers through a web proxy. A client machine is any device capable of sending information to or receiving information from a network. Client machines include personal computers, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.
A web proxy, such as web proxy 130, acts as an interface between a client machine and a network. For outbound messages, the web proxy translates client commands into commands an LDNS server can utilize and into a protocol needed to interface with the network. For inbound messages, the web proxy translates messages into information suitable for the client machine. A web proxy may reside on the same device the client machine does or it may reside on another device that is communicating with the client machine.
An LDNS server, such as LDNS server 120, is generally used to resolve Internet domain names. Resolving Internet domain names involves translating a domain name, such as www.domain.com, into an Internet address, such as 18.104.22.168. An LDNS server typically maintains a table of recent translations in memory so that it can quickly provide IP addresses for recently requested domain names. Frequently, however, the LDNS server does not have the IP address for a particular domain name. When the LDNS server does not have the IP address for a domain name, the LDNS server sends the domain name to another computer and requests the IP address. The other computer may refer the LDNS server to another computer which may refer the LDNS server to another computer, etc. Eventually, the LDNS server obtains an IP address (or an error) for the domain name. After it receives the IP address, the LDNS server stores it in its internal tables and provides it to the requestor.
Generally, an EDNS server, such as virtual EDNS server 160, is the last device an LDNS server is referred to when finding an IP address associated with a domain name. Virtual EDNS server 160 is connected to Internet 170. Virtual EDNS server 160 receives a domain name resolution request and returns an IP address associated with the domain name. A domain name may have several IP addresses associated with it. For example, to serve requests to a high traffic website, a company may have several arrays of servers, e.g., virtual server arrays 110–112, each controlled by a different SAC, e.g., one of SACs 101–103. Each SAC usually has at least one IP address associated with it. Typically, the IP address returned by the EDNS server corresponds to an address of one of the SACs.
Virtual EDNS server 160 may be configured to load balance client requests across the SACs according to a variety of load balancing metrics, including packet rate of each SAC, CPU utilization of the SAC, and number of connections serviced by the SAC. In addition, information about packets between servers in the server array managed by the SAC and clients may be used for load balancing. Such information includes round trip time, packet loss, and hops. These, and other metrics may be used in addition to topological load balancing to refer a request to a particular server.
For example, virtual EDNS server 160 may use topological information calculated from the IP address of the requesting LDNS server to decide which SAC's IP address to return. Alternatively, virtual EDNS server 160 may use a round robin approach to returning a SAC's IP addresses in which the EDNS server loops through available SACs, returns the first available SAC's IP address, and then increments a counter to point to the next SAC's IP address. In another load balancing technique, virtual EDNS server 160 may collect availability information from each of the SACs including such information as number of requests currently being serviced, effective load, and availability to service a request, and then make decisions as to which SAC's IP address will be returned to the client based on this gathered information.
To provide persistence, virtual EDNS server 160 generally refers subsequent requests for the same domain name resolution from a prior requestor to the same SAC virtual EDNS server 160 referred prior requests. Providing persistence depends on the load balancing technique selected and is described in detail in conjunction with
A virtual EDNS server may include one or more physical EDNS servers. When this occurs, depending on the load balancing technique selected, the physical EDNS servers may share information with each other so that each can provide persistence and appear to domain name resolution requestors to be a single EDNS server (a virtual EDNS server). This is described in detail in conjunction with
Internet 170 is a WAN of servers, routers, gateways, switches, and hubs that connects client machines to server machines. Internet 170 may include wireless communication, including satellite systems, radio networks, television broadcasts, microwave transmissions, and the like, and wired communication, including telephone, twisted pair, coaxial cable, wave guides, fiber optic, and the like. In
Clients have many ways of accessing Internet 170.
Alternatively, a client may be dynamically assigned to one of a number of web proxies when connecting to the Internet. Additionally, each web proxy may be dynamically assigned to one of a number of LDNS servers when requesting domain name resolution. This may occur to load balance Internet access and domain name resolution. Providing persistence for this type of configuration is described in more detail in conjunction with
Alternatively, a group of clients may access the Internet directly but may share an LDNS server to resolve domain names. Providing persistence for this type of configuration is described in more detail in conjunction with
Computing systems, such as the ones shown in
Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structure, program modules or other data. Computer storage media includes RAM, ROM, EPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computing device.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.
Illustrative Method for Selecting a Load Balancing Mode
At block 210, load balancing configuration data is retrieved. Load balancing configuration data includes information about what type of load balancing has been selected, e.g. dynamic, topological, stripe, etc., SAC IP addresses to load balance requests to, and time to live for connection objects. For example, referring to
At block 215, a determination is made as to whether the load balancing configuration data indicates that dynamic load balancing should be performed. When dynamic load balancing should be performed, the yes branch is followed and processing continues at block 220. Otherwise, the no branch is followed and processing continues at block 225.
At block 220, dynamic load balancing is performed as described in more detail in conjunction with
Alternatively, when the determination at block 215 is negative, the process continues at block 225 where a determination is made as to whether static topological load balancing is selected. If affirmative, processing continues at block 230. For example in
At block 230, topological load balancing is performed. Topological load balancing does not necessarily mean that all requests from one physical region, e.g., the United States, will be resolved to one SAC while all requests from another physical region, e.g., Europe, will be resolved to another SAC. An LDNS server, such as LDNS server 121, does not typically provide its physical location when requesting a domain name resolution from an EDNS server, such as virtual EDNS server 160. Normally, an LDNS server provides its IP address and a domain name that needs to be resolved. While it may be possible to map an LDNS server IP address to a physical location, topological load balancing refers more to load balancing requests based on the requesting LDNS server IP address than upon the physical location of the LDNS server. Thus, using topological load balancing, requests from LDNS servers with IP addresses in one set of IP addresses are resolved to one SAC and requests from LDNS servers with IP addresses in another set of IP addresses are resolved to another SAC. For example, referring to
Also, when the determination at block 225 is found to be negative, the process continues at block 235 where a determination is made as to whether static stripe load balancing should be performed. When the determination is negative at block 235, the processing continues at end block 245 and returns to processing other actions.
Alternatively, when static stripe load balancing is determined to be selected at block 235, processing continues at block 240 where the static stripe load balancing is performed (described in detail in conjunction with
The remainder of this disclosure describes methods and systems for providing persistence when either dynamic or static load balancing mechanisms are used. First, a method and system for providing persistence when a dynamic load balancing system is employed is disclosed. Then, a method and system for providing persistence using static stripe load balancing is disclosed.
Illustrative Method and System for Providing Persistence During Dynamic Load Balancing
Virtual server arrays 110, 111, and 112 are connected to SACs 101, 102, and 103 and operate as described in conjunction with
Persistent connection stores 460, 465, and 470 store information associated with previous domain name resolution requests as described in more detail in conjunction with
Periodically, physical EDNS servers 440, 445, and 450 exchange information contained in persistent connections data stores 460, 465, and 470. An LDNS server may request resolution for a domain name from one physical server with one request and may then request resolution for the domain name from another physical server with another request. By sharing persistent connections information, the physical EDNS servers are able to avoid losing persistence.
This can be explained through the following example. Suppose that LDNS server 120 first requested domain name resolution of www.domain.com from EDNS server 440. EDNS server 440 performs load balancing calculations and determines that SAC 101 is best able to satisfy future client requests for information or services. Subsequently, EDNS server 440 returns the IP address of SAC 101 to LDNS server 120 which then returns it to client 405.
Network conditions may require LDNS server 120 to shortly thereafter again request domain name resolution for www.domain.com. For example, LDNS server 120 may be servicing several domain name resolutions requests. Although an LDNS server generally has local storage to store the results of domain name resolutions requests, this storage may fill up quickly when the LDNS server is servicing several domain name resolution requests. When the storage is full, the LDNS server begins to overwrite older entries. Thus, if enough requests to resolve domain names come to LDNS server 120 between client 405's first and second request to resolve www.domain.com, LDNS server 120 may no longer have the IP address associated with www.domain.com in its local storage and may be required to return to an EDNS server to resolve the domain name.
Alternatively, time to live settings may cause LDNS server 120 to again request domain name resolution for www.domain.com. For example, an EDNS server may set a relatively short time to live for domain name resolutions it fulfills in response to requests from LDNS server 120. This may cause LDNS server 120 to expire its local mapping to the domain name between a first and a second request because the time to live has expired. When its local mapping has expired, LDNS server 120 returns to an EDNS server for domain name resolution. An EDNS server may be configured to set a short time to live on domain name resolutions to force LDNS servers to frequently return for domain name resolution so that the EDNS server may re-route requests in the event of a SAC outage.
When LDNS server 120 searches for an IP address for www.domain.com, it may connect to a different physical EDNS server than the physical EDNS server it first asked for resolution of www.domain.com. For example, it may connect to physical EDNS server 445. If physical EDNS server 445 is unaware that physical EDNS server 440 previously satisfied a domain name resolution request for www.domain.com for LDNS server 120, physical EDNS server 445 may perform load balancing calculations and determine that SAC 102 is best able to satisfy future client requests for information or services. When physical EDNS server 445 does this, a potential for losing persistence is created because client 405 could be attempting to complete a transaction with a virtual server in virtual server array 110 (the one managed by SAC 101).
This embodiment of the invention avoids the problem discussed above by periodically sharing persistent connections data between the physical EDNS servers. Updates are provided to the persistent connections data store of each physical EDNS server so that each physical EDNS can correctly recognize a subsequent request to resolve the domain name. Once recognized, the EDNS server can use the shared persistent connections data to provide the previous SAC IP address to the requesting LDNS server. Thus, by periodically sharing persistent connections data, the physical EDNS servers appear to act as one “virtual” EDNS server. For example, physical EDNS server 445 recognizes that the request from LDNS server 120 to resolve www.domain.com is the second domain name resolution request by LDNS server 120 for this domain name and returns the IP address of SAC 101 to LDNS server 120, foregoing the actions necessary to separately load balance each request.
In another embodiment of the invention, each of clients 405, 410, and 415 represent a pool of clients. The pool of clients in client 405, repetitively use LDNS server 120 for domain name resolution. Likewise, the pools of clients in client 410 and 415 repetitively use LDNS servers 124 and 125, respectively, for domain name resolution. Because virtual EDNS server 160 relies on the requesting LDNS server's IP address (rather than the client's IP address) persistence is provided to each client in each client pool, so long as each client continues to request domain name resolution through the same LDNS server.
The embodiment shown in
When a domain name request from one of the LDNS servers in the list is sent to any of the physical EDNS servers in virtual EDNS server 160, the physical EDNS server determines if the request is a subsequent request for a prior domain name resolution request or is a new request. When the later condition is true, load balancing calculations are performed and the LDNS server is given the IP address of a selected SAC. When the former condition is true, the persistent connections data is used to give the LDNS server the IP address of the previously selected SAC.
Other information may also be included in the Request_t object, such as information identifying whether the LDNS server is part of a group of LDNS servers that should be grouped together to provide persistence. One candidate for such information, for example, is when a client may use multiple LDNS servers to resolve domain names as described in conjunction with
The time to live field may be set when load balancing configuration data (not shown) is loaded. For example, a user may set a relatively short time to live value by modifying a file containing the load balancing configuration data. The effect of a short time to live is that Request_t objects become invalid more quickly. This causes an EDNS server to more frequently load balance requests when subsequent requests arrive, even if related to the same transaction, because the Request_t object becomes invalid more quickly.
Alternatively, the time to live field may be modified dynamically by an EDNS server. For example, at certain hours, the time to live may be automatically increased while at other hours, the time to live may be decreased to meet transactional needs.
At block 710, an EDNS server load balances the client's request to a server associated with the domain name. This process is described in more detail in conjunction with block 710 of
For example, referring to
At block 725, processing ends. At this point a request has been load balanced and a subsequent request recognized and sent to the appropriate server.
At block 910, a domain name resolution request is received. For example, referring to
At block 915, a determination is made as to whether the request matches a Request_t object in a persistent connections data store. The request matches a Request_t object if the request is made by the same LDNS server that made a prior request and if the request and the prior request requested a domain name resolution that would resolve to the same SAC or set of SACs. When the request matches a prior Request_t object, the yes branch is followed to block 920. Alternatively, the no branch is followed to block 930. For example, referring to
At block 920, a determination is made whether the current request is a timely continuation of a previous request matching the current request. When the current request is a timely consideration, the yes branch is followed. Alternatively, the no branch is followed from block 920 to block 935. For example, referring to
At block 925, the Request_t object is updated and the LDNS server is referred to the server identified by the wide IP key field of the Request_t object. For example, referring to
At block 930, load balancing occurs. For example, referring to
At block 935, the Request_t object is deleted in preparation for adding a new Request_t object at block 940. For example, referring to
At block 940, a Request_t object is added to the persistent connections data store associated with the EDNS server. This allows the EDNS server to recognize subsequent requests to resolve the same domain name from the same LDNS server as described earlier. For example, referring to
Illustrative Method for Providing Persistence Using Static Stripe Load Balancing
At block 310, a request to resolve a domain name is received. The request includes the domain name to be resolved and the IP address of the requesting LDNS server. For example, referring to
At block 315, modulus arithmetic is employed to select at least one SAC that manages virtual server arrays containing virtual servers that can service a client's requests for resources. A virtual server array may be dedicated to servicing requests for more than one domain name. As a result, a SAC may manage virtual servers associated with more than one domain name, such as www.domain.com and www.subsidiary.domain.com. The N in block 315 corresponds to the number of virtual servers that are currently marked “up” servicing requests for resources. For the purposes of this discussion, up means the number of virtual servers that are accepting new connections for the resources requested by the client.
One method for employing modulus arithmetic is to perform a calculation using the LDNS server's IP address and the number of virtual servers that are marked up (N). The calculation involves converting the LDNS server's IP address into an integer, dividing the integer by N, taking the remainder, and adding one. The number obtained (X) by this calculation is then used to advance through a circularly linked list of virtual servers. With each advancement through the linked list, when a virtual server is marked up, X is decremented; when a virtual server is marked down, X is not decremented. A virtual server is assumed up until it is marked down. If the last virtual server in the linked list is reached, advancing continues at the beginning of the linked list. When X reaches zero, advancing stops and a candidate virtual server has been found. For example, referring to
At block 320, it is determined whether the candidate virtual server is up. Although, the virtual server may have been marked up, it may have gone down since it was marked. When the selected virtual server is up, processing continues at block 330; otherwise, processing continues at block 325. For example, referring to
At block 325, N is decremented by one indicating that a virtual server that was marked up should be marked down. For example, referring to
At block 330, the EDNS server sends the address of the SAC managing the candidate virtual server to the LDNS which then sends it to the client. When block 330 is reached, this implies that the most recent candidate virtual server selected at block 315 was actually up. For example, referring to
At block 335, processing returns to the calling process. At this point a client has been referred to a SAC providing access to an up virtual server according to the modulus arithmetic described above.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3950735||Jan 4, 1974||Apr 13, 1976||Honeywell Information Systems, Inc.||Method and apparatus for dynamically controlling read/write operations in a peripheral subsystem|
|US4644532||Jun 10, 1985||Feb 17, 1987||International Business Machines Corporation||Automatic update of topology in a hybrid network|
|US4965772||Jun 15, 1987||Oct 23, 1990||International Business Machines Corporation||Method and apparatus for communication network alert message construction|
|US5023826||Jan 11, 1990||Jun 11, 1991||Bull Hn Information Systems Inc.||Apparatus for skipping arithmetic calculations involving leading zeros|
|US5053953||Jan 5, 1990||Oct 1, 1991||Bull Hn Information Systems Inc.||Apparatus for aligning arithmetic operands during fetch|
|US5299312||Nov 15, 1990||Mar 29, 1994||Massachusetts Institute Of Technology||Network fault recovery by controllable switching of subnetworks|
|US5327529||Sep 9, 1992||Jul 5, 1994||Geoworks||Process of designing user's interfaces for application programs|
|US5367635||Aug 29, 1991||Nov 22, 1994||Hewlett-Packard Company||Network management agent with user created objects providing additional functionality|
|US5371852||Oct 14, 1992||Dec 6, 1994||International Business Machines Corporation||Method and apparatus for making a cluster of computers appear as a single host on a network|
|US5406502||Jun 29, 1993||Apr 11, 1995||Elbit Ltd.||System and method for measuring the operation of a device|
|US5475857||Nov 18, 1994||Dec 12, 1995||Massachusetts Institute Of Technology||Express channels for diminishing latency and increasing throughput in an interconnection network|
|US5517617||Jun 29, 1994||May 14, 1996||Digital Equipment Corporation||Automatic assignment of addresses in a computer communications network|
|US5519694||Feb 4, 1994||May 21, 1996||Massachusetts Institute Of Technology||Construction of hierarchical networks through extension|
|US5519778||Sep 26, 1994||May 21, 1996||Silvio Micali||Method for enabling users of a cryptosystem to generate and use a private pair key for enciphering communications between the users|
|US5521591||Mar 25, 1994||May 28, 1996||Massachusetts Institute Of Technology||Switching networks with expansive and/or dispersive logical clusters for message routing|
|US5528701||Sep 2, 1994||Jun 18, 1996||Panasonic Technologies, Inc.||Trie based method for indexing handwritten databases|
|US5581764||May 2, 1994||Dec 3, 1996||Novadigm, Inc.||Distributed computer network including hierarchical resource information structure and related method of distributing resources|
|US5596742||Apr 2, 1993||Jan 21, 1997||Massachusetts Institute Of Technology||Virtual interconnections for reconfigurable logic systems|
|US5606665||Jul 1, 1994||Feb 25, 1997||Digital Equipment Corporation||Buffer descriptor prefetch in network and I/O design|
|US5611049||Jun 3, 1992||Mar 11, 1997||Pitts; William M.||System for accessing distributed data cache channel at each network node to pass requests and data|
|US5663018||May 28, 1996||Sep 2, 1997||Motorola||Pattern writing method during X-ray mask fabrication|
|US5752023||Apr 24, 1996||May 12, 1998||Massachusetts Institute Of Technology||Networked database system for geographically dispersed global sustainability data|
|US5761484||Apr 1, 1994||Jun 2, 1998||Massachusetts Institute Of Technology||Virtual interconnections for reconfigurable logic systems|
|US5768423||Oct 19, 1995||Jun 16, 1998||Panasonic Technologies Inc.||Trie structure based method and apparatus for indexing and searching handwritten databases with dynamic search sequencing|
|US5774660||Aug 5, 1996||Jun 30, 1998||Resonate, Inc.||World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network|
|US5790554||Oct 4, 1995||Aug 4, 1998||Bay Networks, Inc.||Method and apparatus for processing data packets in a network|
|US5875296||Jan 28, 1997||Feb 23, 1999||International Business Machines Corporation||Distributed file system web server user authentication with cookies|
|US5892914||Feb 26, 1997||Apr 6, 1999||Pitts; William Michael||System for accessing distributed data cache at each network node to pass requests and data|
|US5919247||Jul 24, 1996||Jul 6, 1999||Marimba, Inc.||Method for the distribution of code and data updates|
|US5936939||May 22, 1995||Aug 10, 1999||Fore Systems, Inc.||Digital network including early packet discard mechanism with adjustable threshold|
|US5946690||Dec 16, 1997||Aug 31, 1999||Inca Technology, Inc.||NDC consistency reconnect mechanism|
|US5949885||Aug 29, 1997||Sep 7, 1999||Leighton; F. Thomson||Method for protecting content using watermarking|
|US5959990||Mar 12, 1996||Sep 28, 1999||Bay Networks, Inc.||VLAN frame format|
|US5974460||Jun 16, 1997||Oct 26, 1999||International Business Machines Corporation||Apparatus and method for selecting an optimum telecommunications link|
|US5983281||Apr 24, 1997||Nov 9, 1999||International Business Machines Corporation||Load balancing in a multiple network environment|
|US6006260||Jun 3, 1997||Dec 21, 1999||Keynote Systems, Inc.||Method and apparatus for evalutating service to a user over the internet|
|US6006264||Mar 30, 1998||Dec 21, 1999||Arrowpoint Communications, Inc.||Method and system for directing a flow between a client and a server|
|US6026452||Aug 31, 1998||Feb 15, 2000||Pitts; William Michael||Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data|
|US6028857||Jul 25, 1997||Feb 22, 2000||Massachusetts Institute Of Technology||Self-organizing network|
|US6051169||Aug 27, 1997||Apr 18, 2000||International Business Machines Corporation||Vacuum baking process|
|US6078943 *||Feb 7, 1997||Jun 20, 2000||International Business Machines Corporation||Method and apparatus for dynamic interval-based load balancing|
|US6078956||Sep 8, 1997||Jun 20, 2000||International Business Machines Corporation||World wide web end user response time monitor|
|US6085234||Jul 23, 1998||Jul 4, 2000||Inca Technology, Inc.||Remote file services network-infrastructure cache|
|US6092196||Nov 25, 1997||Jul 18, 2000||Nortel Networks Limited||HTTP distributed remote user authentication system|
|US6108703||May 19, 1999||Aug 22, 2000||Massachusetts Institute Of Technology||Global hosting system|
|US6111876||Aug 30, 1996||Aug 29, 2000||Nortel Networks Limited||VLAN frame format|
|US6484143 *||Aug 18, 2000||Nov 19, 2002||Speedera Networks, Inc.||User device and system for traffic management and content distribution over a world wide area network|
|US6671259 *||Mar 30, 1999||Dec 30, 2003||Fujitsu Limited||Method and system for wide area network load balancing|
|US6754706 *||Aug 11, 2000||Jun 22, 2004||Speedera Networks, Inc.||Scalable domain name system with persistence and load balancing|
|US20020040400 *||Dec 4, 2001||Apr 4, 2002||F5 Networks, Inc.||Method and system for storing load balancing information with an HTTP cookie|
|EP0744850A2||May 21, 1996||Nov 27, 1996||Fore Systems, Inc.||Digital network including early packet discard mechanism with adjustable threshold|
|WO1991014326A2||Mar 5, 1991||Sep 19, 1991||Massachusetts Institute Of Technology||Switching networks with expansive and/or dispersive logical clusters for message routing|
|WO1995005712A2||Aug 12, 1994||Feb 23, 1995||Frank Thomson Leighton||Secret key exchange|
|WO1997009805A1||Aug 23, 1996||Mar 13, 1997||Massachusetts Institute Of Technology||Scalable, self-organizing packet radio network having decentralized channel management providing collision-free packet transfer|
|WO1997045800A1||May 30, 1997||Dec 4, 1997||Massachusetts Institute Of Technology||Querying heterogeneous data sources distributed over a network using context interchange and data extraction|
|WO1999005829A1||Jul 23, 1998||Feb 4, 1999||Massachusetts Institute Of Technology||Cost based routing protocol|
|WO1999006913A1||Jun 10, 1998||Feb 11, 1999||Arrowpoint Communications, Inc.||Content-aware flow switching|
|WO1999010858A2||Aug 28, 1998||Mar 4, 1999||Leighton F Thomson||Method for protecting content using watermarking|
|WO1999039373A2||Jan 29, 1999||Aug 5, 1999||Trustees Of Princeton University||Fabrication of organic semiconductor devices using ink jet printing|
|WO1999064967A1||Jun 8, 1999||Dec 16, 1999||Telefonaktiebolaget Lm Ericsson (Publ)||A method and a system for transmitting a cookie|
|WO2000004422A2||Jul 19, 1999||Jan 27, 2000||Leighton F Thomson||Method for image processing to facilitate copy protection|
|WO2000004458A1||Jul 14, 1999||Jan 27, 2000||Massachusetts Institute Of Technology||Global document hosting system utilizing embedded content distributed ghost servers|
|1||"A Process For Selective Routing Of Servlet Content To Transcoding Modules," Research Disclosure 422124, IBM Corporation, pp. 889-890, Jun. 1999.|
|2||"Servlet/Applet/HTML Authentication Process With Single Sign-On," Research Disclosure 429128, IBM Corporation, pp. 163-164, Jan. 2000.|
|3||*||P. Vixie, "Domain Name Anarchy: Extension Mechanism for DNS," RFC 2671, Aug. 1999.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7346693 *||Dec 8, 2003||Mar 18, 2008||Fujitsu Limited||Load balancing server to determine optimum value of number of permanent connections with server|
|US7478158 *||Mar 1, 2004||Jan 13, 2009||Adobe Systems Incorporated||Bandwidth management system|
|US7647461 *||Jan 12, 2010||Netapp, Inc.||Method and apparatus for allocating resources among virtual filers on a filer|
|US7706782||Mar 1, 2004||Apr 27, 2010||Adobe Systems Incorporated||System and method for developing information for a wireless information system|
|US7814180 *||Mar 12, 2004||Oct 12, 2010||Infoblox, Inc.||Domain name service server|
|US7822428||Mar 1, 2004||Oct 26, 2010||Adobe Systems Incorporated||Mobile rich media information system|
|US7831712||Nov 9, 2010||F5 Networks, Inc.||System and method for performing application level persistence|
|US7958246 *||Jun 7, 2011||Kount Inc.||Establishing unique sessions for DNS subscribers|
|US7996886||Aug 9, 2011||F5 Networks, Inc.||Method and system for providing persistence in a secure network access|
|US8064890||Nov 22, 2011||Adobe Systems Incorporated||System and method for developing information for a wireless information system|
|US8103770||Jan 24, 2012||F5 Networks, Inc.||System and method for performing application level persistence|
|US8132177 *||Dec 18, 2007||Mar 6, 2012||AT & T Intellectual Property II, LP||System and method for load-balancing in server farms|
|US8140689 *||Apr 28, 2011||Mar 20, 2012||Kount Inc.||Establishing unique sessions for DNS subscribers|
|US8230085||Jul 24, 2012||Netapp, Inc.||System and method for supporting block-based protocols on a virtual storage appliance executing within a physical storage appliance|
|US8332522 *||Feb 22, 2012||Dec 11, 2012||Kount Inc.||Establishing unique sessions for DNS subscribers|
|US8380831 *||Feb 19, 2013||Kount Inc.||Establishing unique sessions for DNS subscribers|
|US8392563||Dec 29, 2011||Mar 5, 2013||F5 Networks, Inc.||System and method for performing application level persistence|
|US8407771||Mar 26, 2013||F5 Networks, Inc.||Method and system for providing persistence in a secure network access|
|US8566452||Jul 31, 2007||Oct 22, 2013||F5 Networks, Inc.||Intelligent HTTP based load-balancing, persistence, and application traffic management of SSL VPN tunnels|
|US8762574||Jan 18, 2013||Jun 24, 2014||Kount Inc.||Establishing unique sessions for DNS subscribers|
|US8769265||Mar 4, 2013||Jul 1, 2014||F5 Networks, Inc.||Method and system for providing persistence in a secure network access|
|US8776052 *||Feb 16, 2007||Jul 8, 2014||International Business Machines Corporation||Method, an apparatus and a system for managing a distributed compression system|
|US8782232||Jun 30, 2008||Jul 15, 2014||Netapp, Inc.||Method and apparatus for encapsulating a virtual filer on a filer|
|US9210163||May 30, 2014||Dec 8, 2015||F5 Networks, Inc.||Method and system for providing persistence in a secure network access|
|US20030149755 *||Feb 6, 2002||Aug 7, 2003||Emek Sadot||Client-controlled load balancer|
|US20030191810 *||Apr 7, 2003||Oct 9, 2003||Mark Muhlestein||Method and apparatus for allocating resources among virtual filers on a filer|
|US20040133691 *||Dec 8, 2003||Jul 8, 2004||Fujitsu Limited||Server-load-balancing program, server-load-balancing method, and server-load-balancing apparatus|
|US20040210672 *||Mar 12, 2004||Oct 21, 2004||Infoblox, Inc.||Domain name service server apparatus and method|
|US20050228835 *||Apr 12, 2004||Oct 13, 2005||Guillermo Roa||System and method for supporting block-based protocols on a virtual storage appliance executing within a physical storage appliance|
|US20080201718 *||Feb 16, 2007||Aug 21, 2008||Ofir Zohar||Method, an apparatus and a system for managing a distributed compression system|
|US20080281967 *||Jun 30, 2008||Nov 13, 2008||Mark Muhlestein||Method and apparatus for encapsulating a virtual filer on a filer|
|US20090043900 *||Aug 11, 2008||Feb 12, 2009||Barber Timothy P||System and method for establishing unique sessions for DNS subscribers|
|US20090158290 *||Dec 18, 2007||Jun 18, 2009||Sylvia Halasz||System and Method for Load-Balancing in Server Farms|
|US20110202665 *||Aug 18, 2011||Kount Inc.||Establishing Unique Sessions for DNS Subscribers|
|US20120151024 *||Jun 14, 2012||Kount Inc.||Establishing Unique Sessions for DNS Subscribers|
|US20120151072 *||Feb 22, 2012||Jun 14, 2012||Kount Inc.||Establishing Unique Sessions for DNS Subscribers|
|U.S. Classification||709/226, 709/219, 709/225, 709/203, 709/217, 709/220, 709/223, 709/238|
|International Classification||H04L29/06, H04L29/08, G06F15/16|
|Cooperative Classification||H04L67/101, H04L69/329, H04L67/14, H04L67/1002, H04L67/1027, H04L67/1008, H04L29/06, H04L2029/06054|
|European Classification||H04L29/08N9A1C, H04L29/08N9A5, H04L29/08N9A1B, H04L29/06, H04L29/08N13|
|Apr 23, 2001||AS||Assignment|
Owner name: F5 NETWORKS, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SKENE, BRYAN D.;THORNEWELL, PETER M.;REEL/FRAME:011741/0785
Effective date: 20010320
|Feb 23, 2006||AS||Assignment|
Owner name: F5 NETWORKS, INC., WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SKENE, BRYAN D.;THORNEWELL, PETER M.;REEL/FRAME:017285/0303
Effective date: 20060221
|Nov 21, 2006||CC||Certificate of correction|
|Sep 28, 2009||FPAY||Fee payment|
Year of fee payment: 4
|Dec 27, 2013||REMI||Maintenance fee reminder mailed|
|Jan 13, 2014||SULP||Surcharge for late payment|
Year of fee payment: 7
|Jan 13, 2014||FPAY||Fee payment|
Year of fee payment: 8