U.S. patent application number 11/124830 was filed with the patent office on 2005-12-01 for managing the flow of data traffic.
This patent application is currently assigned to ZEUS TECHNOLOGY LIMITED. Invention is credited to Flowerday, Crispin Edward Harold, Garrett, Owen John, Mansell, Ben Ross, Reeves, Damian John.
Application Number | 20050265317 11/124830 |
Document ID | / |
Family ID | 32482803 |
Filed Date | 2005-12-01 |
United States Patent
Application |
20050265317 |
Kind Code |
A1 |
Reeves, Damian John ; et
al. |
December 1, 2005 |
Managing the flow of data traffic
Abstract
Flow of data traffic between at least one server and a plurality
of clients is managed. Client-side connections are provided and
server-side connections are provided. An isolated processing
environment is created responsive to instructions specific to the
environment. Isolated environment specific instructions are
received, defining a traffic management rule. A request from a
client, via an established client-side connection, is received and
a response is made following the environment specific
instructions.
Inventors: |
Reeves, Damian John;
(Cambridge, GB) ; Mansell, Ben Ross; (Cambridge,
GB) ; Garrett, Owen John; (Ely, GB) ;
Flowerday, Crispin Edward Harold; (Cambridge, GB) |
Correspondence
Address: |
HARNESS, DICKEY & PIERCE, P.L.C.
P.O. BOX 828
BLOOMFIELD HILLS
MI
48303
US
|
Assignee: |
ZEUS TECHNOLOGY LIMITED
CAMBRIDGE
GB
|
Family ID: |
32482803 |
Appl. No.: |
11/124830 |
Filed: |
May 9, 2005 |
Current U.S.
Class: |
370/235 ;
370/401; 707/E17.001; 707/E17.107 |
Current CPC
Class: |
H04L 67/1019 20130101;
H04L 67/1002 20130101; H04L 67/1017 20130101; H04L 67/1034
20130101; H04L 43/0817 20130101; H04L 67/1023 20130101; H04L
67/1008 20130101; H04L 29/12066 20130101; H04L 61/1511 20130101;
H04L 69/40 20130101; H04L 41/0681 20130101 |
Class at
Publication: |
370/352 |
International
Class: |
H04L 012/66 |
Foreign Application Data
Date |
Code |
Application Number |
May 7, 2004 |
GB |
04 10 151.5 |
Claims
1. A method of managing the flow of data traffic between at least
one server and a plurality of clients, comprising the steps of
providing browser-side connections; providing server-side
connections; creating an isolated processing environment responsive
to instructions specific to said environment; receiving isolated
environment-specific instructions defining a traffic management
rule; receiving a request from a client via an established
browser-side connection; and responding to said request in response
to said environment-specific instructions.
2. A method according to claim 1, wherein said environment-specific
instructions result in communication with said server via a
server-side connection.
3. A method according to claim 1, wherein said environment-specific
instructions identify a requirement for additional information, the
further execution of said instructions is placed in a wait state
and a request is made for said additional information.
4. A method according to claim 3, wherein other requests are
serviced while said execution is in said wait state.
5. A method according to claim 3, wherein said execution is resumed
upon receiving the requested information.
6. A method according to claim 3, wherein said additional
information is requested from said requesting client.
7. A method according to claim 3, wherein said additional
information is requested from an independent source.
8. A method according to claim 7, wherein the communication of data
from said independent source is a secure communication.
9. A method according to claim 7, wherein said independent source
is a database.
10. A method according to claim 1, wherein said environment
specific instructions are obtained in response to a compilation of
a high level script.
11. Apparatus for managing the flow of data traffic between at
least one server and a plurality of clients, comprising a
processor, memory and network connections, wherein said processor
is configured to: provide browser-side connections; provide
server-side connections; create an isolated processing environment
responsive to instructions specific to said environment; receive
isolated environment-specific instructions defining a traffic
management rule; receive a request from a client via an established
browser-side connection; and respond to said request in response to
said environment-specific instructions.
12. Apparatus according to claim 11, wherein said
environment-specific instructions result in communication with said
server via a server-side connection.
13. Apparatus according to claim 11, wherein said
environment-specific instructions identify a requirement for
additional information, the further execution of said instructions
is placed in a wait state and a request is made for said additional
information.
14. Apparatus according to claim 13, wherein other requests are
serviced while said execution is in said wait state.
15. Apparatus according to claim 13, wherein said execution is
resumed upon receiving the requested information.
16. Apparatus according to claim 13, wherein said additional
information is requested from said requesting client.
17. Apparatus according to claim 13, wherein said additional
information is requested from an independent source.
18. Apparatus according to claim 17, wherein the communication of
data from said independent source is a secure communication.
19. Apparatus according to claim 17, wherein said independent
source is a database.
20. Apparatus according to claim 11, wherein said environment
specific instructions are obtained in response to a compilation of
a high level script.
21. A computer-readable medium having computer-readable
instructions contained thereon, wherein when executed by a computer
said instructions configure said computer to: provide browser-side
connections to and from a plurality of clients; provide server-side
connections to and from at least one server; create an isolated
processing environment responsive to instructions specific to said
environment; receive isolated environment-specific instructions
defining a traffic management rule; receive a request from a client
via an established browser-side connection; and respond to said
request in response to said environment-specific instructions.
22. A computer-readable medium according to claim 21, wherein said
environment-specific instructions result in communication with said
server via a server-side connection.
23. A computer-readable medium according to claim 21, wherein said
environment-specific instructions identify a requirement for
additional information, the further execution of said instructions
is placed in a wait state and a request is made for said additional
information.
24. A computer-readable medium according to claim 23, wherein other
requests are serviced while said execution is in said wait
state.
25. A computer-readable medium according to claim 23, wherein said
execution is resumed upon receiving the requested information.
26. A computer-readable medium according to claim 23, wherein said
additional information is requested from said requesting
client.
27. A computer-readable medium according to claim 23, wherein said
additional information is requested from an independent source.
28. A computer-readable medium according to claim 27, wherein the
communication of data from said independent source is a secure
communication.
29. A computer-readable medium according to claim 27, wherein said
independent source is a database.
30. A computer-readable medium according to claim 21, wherein said
environment specific instructions are obtained in response to a
compilation of a high level script.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to managing the flow of data
traffic between at least one server and plurality of clients.
BACKGROUND OF THE INVENTION
[0002] A problem concerning data traffic managing systems is that
of how to define functionality. The design of such systems is
complicated greatly if it is necessary to access external sources,
such as client databases to determine, for example, appropriate
levels of client access. The situation is complicated further in
that the implementation of standard engineering techniques could
easily undermine requirements for security and resistance to
unauthorised communications.
BRIEF SUMMARY OF THE INVENTION
[0003] According to an aspect of the present invention, there is
provided a method of managing the flow of data traffic between at
least one server and a plurality of clients, comprising the steps
of providing browser-side connections, providing server-side
connections, creating an isolated processing environment responsive
to instructions specific to said environment, receiving isolated
environment-specific instructions defining a traffic management
rule, receiving a request from a client via an established
browser-side connection, and responding to the request in response
to said environment-specific instructions.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0004] FIG. 1 shows an environment in which communication is
provided between a server and browsing clients;
[0005] FIG. 2 shows a hardware platform for implementing traffic
management instructions;
[0006] FIG. 3 shows operations performed by the traffic management
system;
[0007] FIG. 4 shows procedures for configuring the traffic
management system;
[0008] FIG. 5 shows an illustration of a compilation process;
[0009] FIG. 6 shows an example of main memory contents;
[0010] FIG. 7 shows a table of active connections;
[0011] FIG. 8 shows the execution of traffic management
instructions;
[0012] FIG. 9 shows operations performed by a listener object;
[0013] FIG. 10 shows client management procedures;
[0014] FIG. 11 shows procedures for ending client management;
[0015] FIG. 12 shows ongoing client request processing;
[0016] FIG. 13 shows server management processing;
[0017] FIG. 14 shows the ending of server management;
[0018] FIG. 15 shows details of a client connection object;
[0019] FIG. 16 shows the processing of a cached server connection
object;
[0020] FIG. 17 shows a typical set of relationships;
[0021] FIG. 18 details procedures for implementing script-based
processing shown in FIG. 10;
[0022] FIG. 19 details procedures for the execution of a script
instruction shown in FIG. 18;
[0023] FIG. 20 shows an example of steps performed to obtain data
during FIG. 18;
[0024] FIG. 21 shows details steps taken during FIG. 21 to process
an Internet access manager object;
[0025] FIG. 22 shows an example of the syntax used in the high
level language for defining traffic management; and
[0026] FIG. 23 shows a further example of the syntax used in the
high level language.
WRITTEN DESCRIPTION OF THE BEST MODE FOR CARRYING OUT THE
INVENTION
[0027] FIG. 1
[0028] An environment in which communication is provided between a
server and many clients is illustrated in FIG. 1. In this example,
a network connection is provided via the Internet and the invention
is (although not exclusively) applicable to this environment, given
that situations often arise where many (many thousands for example)
of browsing clients are requesting data from the same Internet
address or website; whereupon a substantial resource is required at
the server in order to provide service to all of these requesting
browsers at an appropriate level. However, in other embodiments
clients could be using other protocols such as Web-Services or
SOAP, or could be HTTP clients on networks other than the Internet.
The Internet is used here merely as an example of a popular
application of the invention.
[0029] In this example, clients 102 to 106 are shown, although it
should be appreciated that this is merely representative of the
many thousands of clients requesting data from the server. These
browsing clients include personal computers equipped with browsing
software, such as "Internet Explorer", "Mozilla", "Firefox" and
"Safari" for example. Browsing devices also include mobile wireless
connected devices, such as personal digital assistants (PDAs),
smart phones and any other form of equipment with Internet
connection functionality.
[0030] Server 107 provides services such as the provision of
webpages and secure online sales to connected clients, including
clients 102 to 106. Secure data store 108 stores details concerning
regular customers (in this example including some of clients 102 to
106) who have, for example, accounts relating to online sales and
levels of privileged access to services provided by the site or
sites hosted by server 107. A server may be any processing system
configured to service client requests of some kind, such as
requests for information or requests to write to a database.
[0031] Server site 107 includes physical serving devices (servers)
109 to 116 organised into three server pools consisting of, in this
example, a first pool 117, a second pool 118 and a third pool 119.
The first pool 117 is for the secure servers running secure
protocols, suitable for online sales and other secure transactions.
The second pool 118 provides dynamic webpage content requiring a
relatively high level of server processing and the third pool 119
includes a collection of inexpensive commodity servers for the
serving of static webpages.
[0032] A traffic management system 120 monitors client requests and
directs requests to an appropriate server pool. To do this, the
system is provided with functionality enabling it to analyse client
requests in detail. Furthermore, additional operations are carried
out by the traffic management system (during and after request
analysis), in order to maintain a high number of simultaneously
connected clients without overloading any of the servers 109 to
116.
[0033] In order to facilitate the configuration of the servers and
the traffic management system 120, an administration station 121 is
provided, having human interface peripheral equipment including a
monitor and a keyboard etc.
[0034] A data-carrying medium such as a CD-ROM or DVD etc is
illustrated at 122 as a means for supplying executable instructions
for the traffic managing process to a traffic management platform.
Alternatively, traffic managing instructions may be loaded onto the
traffic management platform from the Internet and the transfer of
such instructions may be controlled via the administration station
121. An network 123 connects the servers 109 to 116 with the
traffic management system 120 and the Internet 101. Thus, in the
embodiment, the traffic management system is implemented by a
programmable platform having executable instructions
installed-thereon.
[0035] In an alternative embodiment, it is possible for several
traffic management systems to be provided, all of which are
configured to manage what is perceived as the same Internet site.
Each traffic management system would be connected to all of the
servers. In the following description, reference is made to a
single traffic management system but it should be appreciated that
the following description also applies to situations in which a
plurality of traffic management systems are provided. When multiple
traffic management systems are used, each system is assigned a
different address or addresses, or alternatively multiple servers
can share the same IP address. The URL for the site is assigned a
range of addresses, one of which is selected by the client browser,
resulting in the substantially random selection of systems among
multiple clients, which is the technique known as round-robin
DNS.
[0036] A difficulty associated with the design of sophisticated
traffic management systems concerns the amount of processing
overhead that is required, both in the traffic management systems
and in the connected servers, to support large numbers of
simultaneous client connections. Slow client connections such as
those provided by dial-up modems worsen the problem because each
connection is held open for the duration of a longer period of data
transfer, thereby increasing the number of simultaneous connections
that must be held open for the same number of connected
clients.
[0037] It is well known that servers (such as servers 109 to 116)
have limits as to the number of simultaneous connections that can
be made. For example, in the case of the widely used APACHE
webserver, a maximum number of simultaneous connections is two
hundred and fifty-six and this number can be used up relatively
easily when a significant number of dial-up modems are connected or
when an even larger number of high-bandwidth digital subscriber
line (DSL) connected clients are accessing the same webpages.
[0038] FIG. 2
[0039] Instructions for the implementation of traffic management
are executed on a hardware platform such as that illustrated in
FIG. 2. The traffic management platform is controlled by the
administration station 121 and therefore does not require its own
output monitor or input keyboard etc. Typically, hardware of this
type is in the form of a rack-mounted unit and several such units
may be provided within a rack so as to provide a degree of
redundancy in case of hardware failure. It should also be
appreciated that servers 109 to 116 may be configured in a similar
fashion.
[0040] A central processing unit 201 is provided such as a Pentium
IV running at 3.2 gigahertz and including on chip primary and
secondary cache, facilitating the provision of access to frequently
used instructions and data.
[0041] Main memory 202 may comprise two gigabytes of dynamic RAM
facilitating the storage of instructions and data to allow regular
access while the system is in operation. A hard disk drive 203 of
typically sixty gigabytes provides non-volatile storage of
instructions and configuration data. In addition, disk 203 also
provides access to infrequently used data during operation. Upon
system initialisation, configuration files and executable
instructions are loaded from disk drive 203 and stored in main
memory 202.
[0042] For the optional loading of traffic managing instructions
from data carrying media, a CD-ROM/DVD drive 204 is provided,
configurable to receive instructions from an instruction carrying
medium, such as disk 122. In addition, one or more network
connections are provided by at least one network interface 205
thereby allowing the traffic management system to connect to the
network 123 and the Internet 101. Internally, the devices 201 to
205 are connected by a data bus 206.
[0043] FIG. 3
[0044] Operations performed with respect to the traffic management
system 120 are illustrated in FIG. 3. At step 301 power is supplied
to the system and a question is asked at step 302 as to whether
instructions have been installed. When answered in the negative, a
question is asked at step 303 as to whether a network installation
is to be performed. When answered in the affirmative, instructions
are installed from the network at step 304 or, alternatively, when
answered in the negative, instructions are installed from CD-ROM at
step 305.
[0045] At step 306 a question is asked as to whether the traffic
management system is to be configured and when answered in the
affirmative, system configuration is performed at step 307. When
answered in the negative or upon completion of step 307, the
traffic management instructions run at step 308.
[0046] Upon completion of the run, a question is asked at step 309
as to whether reconfiguration is required which, when answered in
the affirmative, results in control returning to step 307 for the
reconfiguration to be performed. When answered in the negative, the
system is powered down at step 310.
[0047] FIG. 4
[0048] Procedures 307 shown in FIG. 3 for the configuration of the
traffic management system are detailed in FIG. 4. At step 401
server configuration is performed which involves accessing
configuration parameters for each of the servers 109 to 116. The
individual servers are assigned to pools and this pool
configuration data is then supplied to the traffic management
system.
[0049] At step 402 traffic management configuration scripts are
generated and edited as appropriate. The scripts are written in a
high level language to simplify the definition of the decision
making processes for traffic management and routing.
[0050] At step 403 the traffic management scripts are compiled by
the execution of a compiler on the administration station 121.
Thus, following this compilation exercise, binary executable
instructions are generated for execution on a virtual processor,
described below, running on the traffic management system 120.
[0051] The compilation of scripts may result in the generation of
syntax or other errors which are identified by the compiler during
the execution of step 403 and displayed to an operator at the
administration station 121. If compilation is not successful, it is
necessary for the errors to be fixed by an editing operation being
performed on the offending script or scripts. Thus, at step 404 a
question is asked as to whether compilation has been successful and
if answered in the negative control is returned to step 402.
[0052] At step 405, following successful compilation, compiled
scripts are uploaded to the traffic management system 120. The
uploaded scripts are stored on hard disk drive 203, for subsequent
loading into main memory 202 when the system 120 is operating. In
an alternative embodiment, the traffic management system 120
includes a compiler and is passed the source text of the rule for
compilation.
[0053] It is also possible for operational errors to be detected
during the testing of new scripts, during trial runs of the traffic
management system. Thus, when these situations occur, it is also
necessary for an editing and recompilation process to be performed
by an operator of the administration station. Alternatively, the
editing and compilation may be performed at a different site,
whereafter compiled instructions may be returned to the server
environment, preferably via a secure link.
[0054] FIG. 5
[0055] An illustration of the compilation process is shown in FIG.
5. High level language configuration scripts 501 to 503 are
compiled (by process 403) into respective files of binary
executable code 504, 505 and 506 containing instructions for a
virtual processor running on the traffic management system 120.
[0056] FIG. 6
[0057] An example of the data content of main memory 202 is given
in FIG. 6. At 601, an operating system is stored, such as
Linux.RTM. or another appropriate OS.
[0058] At 602 traffic management instructions are stored, derived
possibly via an installation process from CD-ROM as previously
described.
[0059] At 603 configuration data is stored, such as that defining
the grouping of servers into pools, plus the IP address or
addresses assigned to the traffic management system.
[0060] Compiled scripts, such as scripts 504, 505 and 506
previously described with reference to FIG. 5 are stored at
604.
[0061] At 605 a table of active connections is stored. Connections
are made (typically TCP/IP connections) between the traffic manager
120 and the client browsers, which may be referred to as
client-side connections. In addition, the traffic management system
120 also makes separate connections to the servers, which may be
referred to as server-side connections. All of the established
connections, client-side and server-side, are listed in the table
of active connections, as detailed in FIG. 7.
[0062] At 606 worker objects are stored. Each connection has an
associated worker object and these worker objects come in different
forms, such that each has a specialised task. When the traffic
management system starts up, it starts with a single worker object,
specialised as a listener, illustrated at 607. The listener object
607 has the sole task of listening for incoming new connections
from clients. The listener creates a new worker object (608) when
it gets a new client trying to make such a connection. This new
object is specialised as a "client manager" and client manager
objects typically require access to the server so that these in
turn create a "server manager" object 609.
[0063] Thus, the traffic management instructions make provision for
the inclusion of a worker-based class, from which several other
specialised classes inherit common functionality, such as the
ability to read from and write to the TCP/IP connection. These
derived classes are customised into different variants but
generally, the worker objects, regardless of specialisation, are
treated equally.
[0064] A client connection cache is provided at 611. The cache 611
stores connections from clients that can be reused by the client
rather than establishing new connections. In the example shown, the
client connection cache 611 includes cached client connections 612
to 617. These are connections that have been maintained by HTTP
keep alive protocols, or are simply those which have not yet been
disconnected by the client.
[0065] At 618 there is provided a server connection cache. Cache
618 stores details of cached connections to servers that can be
reused. The cache includes details of cached server connections 619
to 623 and these connections are reused preferably on a
most-recently-used (MRU) basis. Thus the cache operates an
MRU-cache policy, since more recently used connections are less
likely to be broken by the server through a timeout. The cached
connections can only be reused if they provide connection to the
required pool, so that the cache includes server-pool assignment
information. Thus, in this way, it is possible to reuse at least
one of the server-side connections for one or more of the
client-side connections. This makes better use of the limited
number of server-side connections available (effectively allowing
them to be shared over a number of browsers) while at the same time
minimising the re-establishment of connections which in turn
reduces processor overhead.
[0066] At 624 instructions for virtual processors are stored,
including virtual processors 625, 626 and 627. These virtual
processors are created and deleted as required by the worker
objects 606. Typically, a virtual processor object is created when
a new client connection is made. The virtual processor object
executes the compiled scripts 604, to determine whether traffic
management actions need to be taken for the new connection. These
actions include the possible instant discarding of the connection,
without making connection to the server at all, which may occur,
for example, for security reasons.
[0067] At 628 a connection work list is stored. During operation,
the traffic management system may or may not require processing to
be performed on each of the connections in the table of active
connections. The connection work list indicates which of the active
connections require work to be done. It also defines whether the
work to be done includes a read, or write operation for the active
connection.
[0068] A table of active connections 605 is detailed in FIG. 7.
[0069] FIG. 7
[0070] Each TCP/IP connection used by the traffic management system
120 is assigned a file ID by the operating system 601. The
numerical value of the file ID is arbitrary and is provided as a
unique way of identifying a connection.
[0071] The table of active connections associates active
connections 701 with worker objects 702 that handle the
connections. For example, the listener worker object 607 is
associated with a connection that has a numerical file ID value
(1). The client manager 608, the server manager 609 and another
client manager 610 are each associated with a file ID (7, 8 and 40
respectively) for a particular connection.
[0072] When the traffic management system is started, only the
listener object is present. However, as clients make requests, many
hundred of such entries will exist in the table of active
connections 605.
[0073] FIG. 8
[0074] The execution of traffic manager instructions 308
(identified in FIG. 3) is detailed in FIG. 8.
[0075] At step 801 data structures are initialised and at step 802
a single worker object is created that specialises in listening
(usually on port 80) for incoming client requests. This is the
listener object 607.
[0076] At step 803 a connection work list 628 is initialised by
asking each of the worker objects what it needs to do next, that is
to say, whether the object needs to read, write or do nothing.
Initially, there will only be the listener object, which always
requests a read operation, on the basis that its purpose is to
identify attempts made by clients to make open a connection.
[0077] There is a procedure for checking all connections using the
operating system call select( ). This is called with three
arguments, in the form select(arg1, arg2, arg3). When considered at
the operating system level, connections of this type are usually
referred to as "sockets" and when making this call, arg1 is the
pointer to a bit field that specifies (by means of which bits are
set and which bits are clear) which of the file IDs are to be read
from. File IDs are numerical values such that, if bit1 is set in
arg1, that means "read from the connection assigned to file ID No
1". By setting several of the bits, a request is made to see
whether there is data available to be read from the corresponding
connection. This operation does not read the data. What happens is
that the set bits are cleared if there is no data to be read from
that file ID. Thus, upon return from execution, the system is
provided with a pattern of bits in arg1 that identify the requested
connections from which data is available to be read.
[0078] A similar operation is performed for arg2 with respect to
writing. Thus, connections for writing to are specified by setting
bits and those that are still set in arg2 upon exit are those which
are ready for writing to.
[0079] For the argument arg3, upon exit, bits are set for those
connections where an exception (an error) condition has occurred.
The connection work list 628 effectively supplies arguments arg1
and arg2 on entry to step 804. On exit from step 804, the
connection work list has now been updated. Thus, having started
with a list of connections for which work would like to be done, a
list of connections is provided that are now ready for work to be
done.
[0080] At step 805 a connection in the updated connection work list
is selected. At step 806 the worker object associated with that
connection is identified by consulting the table of active
connections 605, as detailed in FIG. 7.
[0081] At step 807 processing is performed in response to the
instructions of the worker object. Thus, this involves object
processing for the worker types listener, client manager, server
manager, cached client connection, cached server connection and
Internet access manager. The cached connections have worker objects
as various maintenance operations are required even though these
connections are effectively dormant. In particular, an unused
connection may be broken by the other party, meaning that it can no
longer be used and should therefore be removed from the cache. Each
client request includes information on whether the connection
should be kept alive or closed. This information is removed by a
traffic manager before the request is forwarded to a server.
Similar information is included in server responses, and is
likewise removed.
[0082] At step 808 a question is asked as to whether all
connections in the work list have been serviced and when answered
in the negative control is returned to step 805 whereupon the next
connection is selected.
[0083] When the question asked at step 808 is answered in the
affirmative, to the effect that all of the connections have been
serviced, a question is asked at step 809 as to whether traffic
management is to continue. When answered in the affirmative,
control is returned to step 803 resulting in the re-initialisation
of the connection work list. Alternatively, if the question asked
at step 809 is answered in the negative, the traffic management
system is shut down at step 810.
[0084] Thus, the operations shown in FIG. 8 represent the top-level
procedures for the traffic management. Step 807 includes the
creation and deletion of additional specialised worker objects as
necessary. The performance of reading and writing data, using
non-blocking I/O calls, is performed at step 807 and is detailed
below.
[0085] In this embodiment, the system operates using a single
operating thread or process thereby providing an advantage to the
effect that operating system overheads associated with large
numbers of threads are avoided. Typically, existing traffic
managers and servers operate one thread per connection, thereby
increasing the amount of memory and system processing required to
set up, manage and maintain each connection. The system outlined in
FIG. 1 avoids the need to do this and furthermore provides a
framework within which non-blocking reads and writes to TCP/IP (and
possibly UDP/IP) socket connections can be applied efficiently.
[0086] It is possible for multiple instantiations of the process
shown in FIG. 8 to be provided on one or several processors or
traffic managing systems, thereby maintaining these advantages even
within a multi-processor system or other distributed processing
environment.
[0087] Operations performed at step 807 for a listener work object
are detailed in FIG. 9.
[0088] FIG. 9
[0089] At step 901 a new request is received from a client. A
listener object listens on port 80 (the standard port for making a
new client request). A client issuing a request can either reuse an
existing keep alive connection to the traffic manager or create a
new TCP/IP connection on which to transmit the request.
[0090] Thus at step 902 a question is asked as to whether this
request has been received by the listener object, meaning that a
new connection is required, or by a client manager object in the
connection cache. If it has been received by a client manager
object then the cached connection for that object is to be used and
so this procedure is completed.
[0091] If it is received by the listener object then at step 903 a
new worker object specialising as client manager is created. Thus,
for example client manager 608 would be created at this step
because there is a client making a request for some data, such as a
webpage, to be supplied from the server.
[0092] At step 904 a new connection (socket) is created and the
file ID for this connection is entered in the table of active
connections. To achieve this, a system call accept( ) is made. This
takes the incoming client request, accepts it as a valid TCP
request and sets up a new additional socket for the connection. The
new worker object is associated with the client connection at step
905. The connection has its own unique file ID and a new entry is
made in the table of active connections 605, associating the file
ID for the connection with the new worker object which, in this
example, is a worker object specialised as a client manager object
608.
[0093] The effect of steps 903 to 905 is to set up a client manager
object for an incoming client request on a new channel. The client
manager object has its own connection with the client that can be
read from and written to as required. At this stage, it is not yet
known which server is to be assigned to the new client.
[0094] Once the new client manager object has been created and is
present in the list of active connections, it will be processed
eventually as one of the worker objects and thereby dealt with in
the main loop of steps 805 to 808.
[0095] The processing procedures implemented by a client manager
object are detailed in FIG. 10.
[0096] FIG. 10
[0097] At step 1001 a question is asked as to whether a server has
already been assigned to handle the client request. Initially, when
a client manager object 608 has been created, it will only have a
connection with the client. It uses this connection to receive the
request in full and to analyse it. Based upon this analysis, a
server pool is chosen based on the nature of the request being made
(for a secure transaction, dynamic content or static web content
for example). The client manager object does not itself communicate
directly with the server and this communication is facilitated by a
server manager created for the purpose.
[0098] If the question asked at step 1001 is answered in the
affirmative, to the effect that a server has already been assigned,
control is directed to step 1013 for the ongoing client request
processing. If the question asked at step 1001 is answered in the
negative, a non-blocking read of the client request is made at step
1002.
[0099] At step 1002 the data from the client is read, so a certain
amount of data is received but control is never interrupted,
regardless of the quantity of data that is supplied by the client
connection.
[0100] At step 1003 script-based processing of the client request
is made, resulting in the request being analysed in accordance with
the compiled scripts 604.
[0101] At step 1004 a question is asked as to whether the
script-based processing is conclusive and when answered in the
negative control is directed to step 808. It is possible that not
enough data has been received from the client to analyse the
request conclusively. If the script-based processing requires more
data, processing states are stored for later recovery once more
data has been received. However, for the time being, this concludes
the client manager's processing operations given that no more can
be done without the data.
[0102] At step 1005 a question is asked as to whether a server is
required and when answered in the negative, this results in the end
of client management at step 106 and again control effectively
directed to step 808.
[0103] To reach step 1005, the script-based processing must have
been successful and this typically results in an indication to the
effect that a server from a particular pool is required. However,
this is not always the result and sometimes a request is malformed
or a time-out expires before enough data is received. In these
cases, a server is not required and the client is discarded.
[0104] If a server is required, as identified at step 1005, the
script-based processing will have defined which pool the server
should belong to. It may also define other parameters, including
specifying how requests should be modified before being passed to
the server and also how server data should be modified before being
passed to the client. In the embodiment, such modification
procedures are important because the traffic manager must operate
transparently between the client and server. However, this is often
requires at least some modification of client requests. Complex
modifications can occur, even to the extent that secure connections
may be established between the client and the traffic management
system and between the traffic management system and the server, so
as to establish full end-to-end security, even when the traffic
management system is analysing each new client request.
[0105] In response to the question asked at step 1005 being
answered in the affirmative, control is directed to step 1007. At
step 1007 a new worker object is created that specialises as server
manager object. Thus, a server manager object is created to provide
communication with a selected server.
[0106] At step 1008 a question is asked as to whether to reuse a
connection in the server connection cache. Although the traffic
manager generally uses the most-recently-used connection in the
cache in preference to using any other cached connection or
establishing a new connection, the answering of this question
depends also on an analysis of which server will serve the client
most quickly. Thus it may be quicker to open a new connection to a
server that is currently processing only a few requests than to use
a cached connection. Other factors could be that a server recently
processed a similar request and thus might be expected to have the
required information in its RAM, or that one server is known to be
more reliable than another. Thus the traffic manager first decides
whether there are available connections in the cache to be reused,
and then decides between them or considers whether it would be
better to use a new connection based on which server is likely to
respond fastest to the client.
[0107] If the question asked at step 1008 is answered in the
affirmative, to the effect that a cached connection is to be
reused, control is directed to step 1010 resulting in the reuse of
an existing server connection identified from the server connection
cache.
[0108] If the question asked at step 1008 is answered in the
negative, a new socket is created and its file ID is put in the
table of active connections at step 1009.
[0109] The completion of step 1009 or step 1010 results in control
being directed to step 1011. At step 1011 a new worker object is
associated with the server connection.
[0110] At step 1012 the client manager object is associated with
the new server manager object. Thus, at this stage, two worker
objects have been established. The client manager 608 handles the
connection between the traffic management system 120 and the client
103. The server manager object handles the connection between the
system 120 and a server 115. An association with each other to
allow data to pass between them is achieved in this example by each
object having a pointer to the other. Data may be passed by
exchanging pointers to buffers. The buffers may be circular buffers
of limited size, thereby providing a flow control mechanism.
[0111] At step 1013 ongoing client request processing is conducted.
Having set up the server manager object, there is now the potential
for communication between the client and a server, which occurs at
this stage. This is mainly the transfer of data from the server
which is then subsequently modified by the traffic management
system and supplied to the client.
[0112] At step 1014 a question is asked as to whether an error
occurred while processing the client request. This can occur
particularly when a cached connection is selected for reuse at the
same time as the server decides to close the connection, for
example due to a timeout. The traffic management system will
receive an error when it attempts to issue a request down this
closed connection. Thus if this question is answered in the
affirmative control is returned to step 1007 to identify a new
connection.
[0113] Procedures 1006 for ending client management are detailed in
FIG. 11.
[0114] FIG. 11
[0115] When ending client management, the previously used client
connection can be put back into the client connection cache for
possible reuse. Cached client connections have their own
specialised worker objects in the form of cached client connection
objects.
[0116] At step 1101 a cached client connection object is created as
a new worker object specialised for this purpose.
[0117] At step 1102 the new worker object is associated with a
client connection. Thus, in the table of active connections 605,
the object associated with the client connection is changed from
the client connection manager object to the new cached client
connection object.
[0118] At step 1103 the new worker object is placed in the client
connection cache. To implement this, a pointer to the new client
connection object is stored in the client connection cache 611 (the
client connection cache is configured to store pointers to these
worker objects, not to the connections themselves).
[0119] At step 1104 the client manager object is deleted; the
connection has been cached and the client manager is no longer
required.
[0120] Step 1013 for ongoing client request processing was
identified in FIG. 10 and this is now detailed in FIG. 12.
[0121] FIG. 12
[0122] Steps identified in FIG. 12 are not completed in a single
iteration. Each time the process detailed in FIG. 12 is
encountered, the current processing context is retrieved at step
1201 and processing may then re-establish at any of steps 1202 to
1205, effectively where it left off previously.
[0123] Thus, at step 1201 the current client request processing
context is retrieved. The client request processing context is a
pointer to any of steps 1202 to 1205 identifying the point where
processing in a previous iteration of the steps terminated. Thus,
after step 1201, processing is resumed at any point in steps 1202
to 1205.
[0124] At step 1202 a non-blocking read operation is performed from
the client connection so as to read as much data as is presently
available on the client connection.
[0125] At step 1203 a client request is modified as necessary and
supplied to the associated server manager. In the embodiment, this
modification process may include decrypting a secure HTTPS
connection.
[0126] At step 1204 served data is modified as necessary and
supplied to the client. Served data is received from the associated
server manager object and supplied to the connection client. Again,
in the embodiment, this may include encrypting data for a secure
HTTPS client connection.
[0127] At step 1205 the client management process ends.
[0128] FIG. 13
[0129] Server manager object processing is detailed in FIG. 13.
This represents the processing performed in response to the object
created at step 1007 and again the steps are not completed in a
single pass. Each time the processing is picked up, it continues
after the point in steps 1302 to 1306 that it previously
reached.
[0130] At step 1301 the current server object context is received,
thereby resulting in the recommencement of processing from one of
steps 1302 to 1305.
[0131] At step 1302 client request data is received from the client
manager object until the request has been completed or until the
buffer is full. The client manager object coupled with the server
manager object it creates at step 1007. At step 1302, the server
manager object picks up data (having been modified as necessary)
from the client manager. It tries to get the full request so it can
pass this on to the server. However, the request may not
necessarily be complete or may be too long to fit in the buffer
that is used to communicate between the client and server manager
objects; there is a limit, given that there can be large numbers of
worker-object pairs communicating in this way. If the request is
not fully received, the context is saved and processing picks up at
the same point in the next iteration.
[0132] At step 1303 a non-blocking write is made to the server
connection of the client request, possibly in modified form. Thus,
another non-blocking connection operation is provided, this time
writing to the server connection.
[0133] At step 1304 a non-blocking read from the server connection
is made, which is the point at which data is picked up from the
server, ready to be supplied to the client.
[0134] At step 1305, data is transmitted to the client manager
object. The client and server managers communicate with each other.
This time, the server object supplies the data it has received from
the server to the client manager object using internal memory
buffers in main memory to facilitate this communication.
[0135] At step 1306, the server management ends. Once the full
request and receive cycle is over (even if it is just for a single
graphic for example) the server manager object is deleted and the
connection it created (or re-used) is put in the server connection
cache.
[0136] This process is described for protocols such as HTTP where
the client "talks first". When using protocols where the server
"talks first", such as SMTP or FTP, this process is slightly
different.
[0137] Procedure 1306 for ending server management is detailed in
FIG. 14.
[0138] FIG. 14
[0139] At step 1401, as part of the server management ending
procedure 1306, a question is asked as to whether the connection is
to be cached. A possible reason why a traffic manager might decide
not to cache a connection is because it has a lot of cached
connections to a server with a small concurrency limit, and caching
more connections could result in other traffic managers being
unable to access that server. Thus if the question is answered in
the negative control is directed to step 1406 to discard the
connection.
[0140] If the question is answered in the affirmative, then the
connection is recorded as the most recently used server connection.
Server connections are reused in part according to a MRU-cache
policy, and therefore it is necessary to note the recency of
connections as they are placed in the cache. This can be achieved,
for example, by the ordering of a linked list of cached
objects.
[0141] At step 1403, a worker object is created that specialises as
a cached server connection object. Cached server connections
require maintenance, and therefore each has its own specialised
worker object as described below.
[0142] At step 1404, the new worker object is associated with the
server connection. Thus, in the table of active connections 605 the
object association is changed with the server connection from the
server management object to the new cached server connection
object.
[0143] At step 1405, the new cached server connection object is
placed in the server connection cache 618. Thereafter, at step
1406, the server manager object is deleted.
[0144] FIG. 15
[0145] A worker object 612 in the client connection cache,
representing a client connection, is detailed in FIG. 15.
Maintenance may be required on cache connections in situations
where the client breaks the connection. Thus, the procedures
represent the object processing performed for a cached client
connection.
[0146] At step 1501 a question is asked as to whether the client
has broken the connection, with the procedure terminating if the
question is answered in the negative.
[0147] If the question asked at step 1501 is answered in the
affirmative, to the effect that the client has broken the
connection, the client connection object is removed from the client
connection cache at step 1502.
[0148] At step 1503 the socket is deleted and at step 1504 the
connection's row entry in the table of active connections is
removed. Thereafter, at step 1505 the cached client connection
object is deleted.
[0149] FIG. 16
[0150] The processing of a cached server connection object is
detailed in FIG. 16. This is required because a server may also
break a connection (due to hardware failure for example) in which
case the connection is not available and must be removed from the
cache. Thus, the processing is similar to that required for cached
client connections.
[0151] At step 1601 a question is asked as to whether the server
has broken the connection. If answered in the negative, the
procedure is terminated.
[0152] If the question asked at step 1601 is answered in the
affirmative, to the effect that the server has broken the
connection, the server connection object is removed from the server
connection cache at step 1602.
[0153] At step 1603 the MRU precendence ordering for the server
connection cache is updated. Thus, in this embodiment, the server
connection cache preserves the recency ordering so that it knows
which is the most recently used connection in each server pool.
This may be implemented by a linked list, ordered according to
recency. When a connection is removed from the cache, the next
connection up and next connection down in the linked list are
linked together, thereby excluding the unwanted connection.
[0154] At step 1604 a socket is deleted and at step 1605 the
connection's file row entry ID is removed from the table of active
connections. Thereafter, at step 1606, the cached server connection
object is deleted.
[0155] In this embodiment, connections are reused whenever possible
and server connections are reused multiple times. The effect of
this is that for a client who is connected over several seconds (or
even minutes), requests and responses are buffered by the traffic
management system. The system picks up the most appropriate
available server connection swiftly, sends the requests quickly and
receives a quick response. The slow communication with the client
can be continued. Meanwhile, the server and its connection have
gone on to be reused, possibly by a different client altogether.
Thus a layer of "network buffering" is provided between each client
and server, meaning that each server application can operate very
efficiently. By rewriting client requests and data, the servers
need not be specifically programmed to take account of the presence
of the traffic management.
[0156] The traffic management system itself is highly configurable
in this embodiment and makes traffic management decisions according
to sophisticated scripted configurations. In this way, it is
possible to make best use of available server resources, both in
terms of their suitability to particular serving operations
(secure/dynamic/static) and also in terms of their available
bandwidth. Servers have a limit to the number of simultaneous
transactions they can maintain. Thus, by shortening the attention
span required for each server request transaction, the total number
of clients handled in a given time period is significantly
increased for the same server capability.
[0157] FIG. 17
[0158] A typical set of relationships of clients and servers, along
with objects facilitating their communication on the traffic
management system is illustrated in FIG. 17. Thus, client 103 is
communicating with server 115 by the operations performed by a
client manager object 608 and server manager object 609.
[0159] Client 104 wishes to establish communication and its request
is identified by listener object 607. This results in the creation
of a client manager object 610. Client connection with client 104
has been cached as recorded at 612. Similarly, connections to
server 112 have been established and are presently inactive as
illustrated by their cached server objects 619 and 620.
[0160] FIG. 18
[0161] From the description previously given, it can be understood
that the traffic manager 120 manages the flow of data traffic
between the servers and the clients. It provides, when required,
browser-side connections and similarly, when required it provides
server-side connections. A further problem exists, however, in that
the traffic manager itself must receive instructions such that it
has information telling it how to respond to specific requests. In
particular, it may need to interrogate external data store 108 in
order to determine to which server pool (117, 118 or 119) to convey
a request. A problem therefore exists in terms of providing an
environment which is relatively straightforward for instructions to
be created while at the same time ensuring that the environment
remains secure and not susceptible to unwanted third party
interrogations.
[0162] In this embodiment, an isolated processing environment is
provided, preferably in the form of a virtual machine, responsive
to instructions specific to that environment. Isolated
environment-specific instructions are received defining a traffic
management rule. A request from a client via an established
browser-side connection is received and a response is made to the
request in accordance with the environment-specific
instructions.
[0163] Procedures for implementing script-based processing are
illustrated in FIG. 18. At step 1801 a question is asked as to
whether this is the start of compiled script instructions
processing.
[0164] If the question is answered in the affirmative, to the
effect that this is the start of processing of this type, a new
virtual processor is instantiated at step 1802. Thus, procedures
for executing the virtual processor are created to perform script
instruction execution. Furthermore, after the instantiation of the
new virtual processor at step 1802, the program counter forming
part of that object is set to zero.
[0165] At step 1803 the script is read and the next script
instruction is executed on the virtual processor.
[0166] At step 1804 a question is asked as to whether the
instructions have been successfully completed. Instruction
execution on the virtual processor can result in one of three
possible outcomes, namely: a success (a completed instruction), a
wait (waiting to read or write data), or an exception (that is an
error). In this embodiment, an instruction is allowed to wait for
more data without blocking other processing operations that are
being performed. Thus, at this step, the procedure waits to see
what the outcome of attempting to execute a single instruction has
been. If the question asked at step 1804 is answered in the
negative, control is directed to step 1807.
[0167] If the question asked at step 1804 is answered in the
affirmative, to the effect that the instruction has successfully
completed, the program counter is incremented at step 1805. Thus,
if the instruction was successfully executed, the procedure moves
on to the next one.
[0168] At step 1806 a question is asked as to whether this is the
end of the script and when answered in the negative, control is
returned to step 1803 for the next script instruction to be
executed. Eventually the script will complete and will specify a
traffic managing action, typically identifying which of the
available pools of server to request service from.
[0169] If an instruction is not successfully completed, resulting
in the question asked at step 1804 being answered in the negative,
a question is asked at step 1807 as to whether an instruction is
waiting for data transfer. If this question is answered in the
negative, a script execution error is generated at step 1808.
Alternatively, when answered in the affirmative, to the effect that
an instruction is waiting for data transfer and therefore an action
is to be taken but cannot be completed at this stage, the virtual
processor operation is suspended at step 1809. Thus, it is not
possible to do anything further at this time so an exit from the
process takes place. However, processing will be resumed from the
same place the next time around, as more data becomes
available.
[0170] Procedures 1803 for the execution of a script instruction
are detailed in FIG. 19.
[0171] FIG. 19
[0172] At step 1901 data is read or written as required. The reason
for a WAIT state could be that the instruction is waiting for data.
The data could be obtained by using a non-blocking I/O to read data
from the client connection, either from a connection that has
already been established with the client or to analyse part of the
request that the client has made. The data could be obtained from
an external source. Since in this embodiment connections are made
via the Internet, data could be required from somewhere else on the
Internet. However, it could also be from a device installed on the
traffic manager or a local software service. This is a relatively
more complicated issue in that, in order to obtain this
information, a separate connection to the Internet must be
established. Alternatively, for example, the WAIT might be for
confirmation that data has been written to a database or that a
request has been made.
[0173] It should be understood that the steps being performed here
are those of a virtual processor, having instruction primitives for
accessing data (or a service) via a network, such as the Internet.
The provision of a processor of this type, in this embodiment,
virtually ensures that a malicious attack cannot malform the
instruction to gain access to the traffic manager's data. Thus, by
running the traffic management scripts on a virtual processor, both
the scripts and the virtual processor can be kept simple in design
while providing a high level of functionality without compromising
security. The scripting language itself may be made relatively
user-friendly given that it is created within the environment of a
high-level language. The actual instruction primitives as encoded
remain proprietary and are effectively known only to the compiler.
Thus, the virtual machine exists in a substantially isolated
environment where it understands only its own unique primitives
supplied to it via a process of compilation specific to it.
[0174] At step 1902 an attempt is made to execute the instruction,
and at step 1903 a question is asked as to whether the instruction
has been completed successfully. On many occasions, sufficient
information will have been received, from the client or from an
external source, thereby allowing the instruction to execute.
However, it is possible that further information may be required
therefore the question asked at step 1903 may be answered in the
negative resulting in control being directed to step 1907.
[0175] When the question asked at step 1903 is answered in the
affirmative, to the effect that the instruction has been completed
successfully, an instruction exit condition is set to "completed"
at step 1904 and the process exits.
[0176] In response to an unsuccessful execution, a question is
asked at step 1905 as to whether the instruction needs more data.
In response to this question being answered in the affirmative, the
instruction exit condition is set to "waiting" at step 1906.
Alternatively, if the question is answered in the negative, the
instruction exit condition is set as "error" at step 1907.
[0177] One of the possible procedures performed at step 1902 is
obtaining data from the Internet. Instructions performed for this
purpose are detailed in FIG. 20.
[0178] FIG. 20
[0179] At step 2001 a question is asked as to whether it is
necessary to start a virtual processor Internet access. It is
possible that the Internet access processor has been started,
because there could have been a partially completed Internet access
operation that did not obtain sufficient data to complete, in which
case it is not necessary to set up a further Internet access
manager and its connection. Thus, when the question asked at step
2001 is answered in the negative, control is directed to step
2006.
[0180] In response to the question asked at step 2001 being
answered in the affirmative, a new worker object specialised as an
Internet access manager object is created at step 2002.
[0181] At step 2003 a new socket is created and a file ID for this
connection is placed in the table of active connections.
[0182] At step 2004 a new connection is associated with the new
worker object by updating a new row in the table of active
connection with a pointer to a newly created Internet access
manager object.
[0183] At step 2005 a URL specified in a script instruction is
supplied as an argument to the Internet access manager object, so
that said object knows where to go on the Internet to obtain its
data. The procedure then exits. The URL system is commonly used on
the Internet, but any service naming scheme could be used. It may
describe a service local to the machine as well as on an external
machine.
[0184] At step 2006 data is read from the Internet access manager
object and at step 2007 a question is asked as to whether all of
the data has been obtained. When this question is answered in the
affirmative, the Internet access connection is deleted at step
2008, else the process exits.
[0185] At step 2009 the Internet connection file ID is removed from
the table of active connections and at step 2010 the Internet
access manager object is deleted.
[0186] It should be appreciated that the above steps do not read
any data from the Internet. These procedures create an Internet
access manager object which will read from the URL specified. The
data from the Internet access manager object is transferred at step
2006.
[0187] FIG. 21
[0188] The processing of an Internet access manager object is shown
in FIG. 21. This is a further sequence of operations that usually
only partly completes in each iteration. Thus, the first step
(2101) consists of retrieving the current Internet access manager
processing state, thereby allowing the procedure to pick up where
it left off by loading the context. Procedures then continue in one
of steps 2102 to 2106 until all of the data has been obtained. The
procedure can exit at any of steps 2102, 2104 and 2105 back to step
2007 in a "wait" state if the instruction could not complete.
[0189] At step 2101 the current object's processing state is
retrieved and at step 2102 the DNS lookup of the specified URL is
performed using non-blocking I/O. At step 2103 a new connection may
need to be established (or a cached connection reused where the
protocol provides such functionality).
[0190] A step 2104 a non-blocking write is formed of a request to
the Internet site. Thereafter at step 2105 a non-blocking read from
the Internet site is performed in order to read the data, and at
step 2106 server data is stored for the virtual processor.
[0191] FIG. 22
[0192] An example of the syntax used in the high level language for
defining traffic management is illustrated in FIG. 22. This code
represents an example of the use of the Internet access function as
it is written in the high-level language.
[0193] In this example, a URL is specified in the first line 2201.
A variable is set to the data returned from that URL.
[0194] In the second line 2202, the data obtained from the URL is
supplied straight back to the connected client, without
intervention from a server.
[0195] FIG. 23
[0196] Further high level code is illustrated in FIG. 23, which
represents the second form of the Internet access instruction. This
allows the specification of data used in the POST function of HTTP.
These two examples of forms are only instances of how an operation
could be invoked for the HTTP protocol. Other protocols would use
other functions.
[0197] At line 2301, a variable has been filled with account
information obtained from an analysis of the client request. This
is supplied to the URL specified. The URL then supplies back a
response, this time dependent upon the client account details.
[0198] In lines 2302 and 2303, a conditional statement selects a
pool of servers that has (elsewhere) been named, which in this
example is "gold". If the account details supplied include the word
"gold" at the end, a server from this pool is used.
[0199] These high level statements are compiled into executable
binary instructions that are executed on a virtual processor at
step 1803. Request.get and request.post functions each compile to
corresponding individual instructions for the virtual processor.
Each individual instruction is capable of being partially executed
when insufficient data is obtained at a first attempt. Thereafter,
instead of blocking a thread, processing continues for other
connections, utilising a single overall processing thread for many
such operations, with the possibility of many such virtual
processors being executed in sequence according to their
intermediate status.
[0200] The system described in this embodiment facilitates the
implementation of a relatively straightforward processing language,
as shown in the examples of FIGS. 22 and 23, while providing an
underlying framework that is efficient both in the utilisation of
available server resources and the versatility of traffic
management. Servers connected to the traffic manager are configured
as if the traffic manager were not present. The traffic manager
load balances servers that are available in each pool. Servers may
break down or become unavailable but the traffic manager will
continue to operate successfully.
* * * * *