Protocol-configurable transaction processing

Abstract

A traffic management device or other intermediate network device is configured to enable the device to support connection splitting and/or connection aggregation or to otherwise process network transactions for an arbitrary transaction-oriented protocol. The configuration may be accomplished by providing one or more traffic management rules defined by way of a scripting language and provided to an interpreter. The traffic management rule may follow a basic approach common to many protocols and is adapted to the particular protocol being supported. The rule may configure the network device to inspect incoming data, extract length and record type specifiers, buffer an appropriate amount of data to determine transactions or transaction boundaries, and perform other operations. Transaction processing may be enabled for various kinds of protocols, including application-level, proprietary, quasi-proprietary, and special-purpose protocols, protocols for which limited information is available, and protocols not natively supported by the network device.

Description

FIELD OF THE INVENTION

The present invention relates generally to network communications, and more particularly, but not exclusively, to employing a traffic management device to process network transactions.

BACKGROUND OF THE INVENTION

Network traffic management mechanisms are typically deployed to mediate data communications between remote client devices and one or more server devices. Depending on the features of the protocol governing the communication, various optimizations may be achieved by a traffic management device or another intermediate network device. For example, some protocols support persistent client connections, in which a client can make multiple requests, and receive multiple responses, on the same network connection. Employing multiple requests on the same connection may be economical because it reduces the setup and teardown time associated with the underlying transport protocol. The traffic management device may then allocate the multiple requests to different backend servers for various purposes, such as load balancing. This process is known as connection splitting or connection multiplexing. In some protocols, the responses from the multiple backend servers to the external client connection must be sent back in order by the traffic management device.

A traffic management device may also be employed for connection aggregation, in which requests from multiple clients are allocated to the same backend server connection. Connection aggregation achieves economies on the backend connection and generally enables a set of servers to scalably handle a larger number of client requests.

Many protocols may be susceptible to some form of connection splitting and/or connection aggregation by an intermediate network device managing transactions that conform to the requirements of those protocols. This may enable clients and/or backend servers to be used more efficiently or scalably. However, traffic management devices have generally not been designed to be adaptable by users or administrators of the devices to support such services for arbitrary protocols, including foreign protocols that the device is not pre-configured to natively support, and including proprietary protocols or protocols for which limited information is available to the user.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified.

For a better understanding of the present invention, reference will be made to the following detailed description of the invention, which is to be read in association with the accompanying drawings, wherein:

FIG. 1 shows a functional block diagram illustrating one embodiment of an environment for practicing the invention;

FIG. 2 shows one embodiment of a server device that may be included in a system implementing the invention;

FIG. 3 illustrates a logical flow diagram generally showing a high-level view of one embodiment of a process for connection splitting of network transactions;

FIG. 4 illustrates a logical flow diagram generally showing a high-level view of one embodiment of a process for connection aggregation of network transactions;

FIG. 5 is a logical flow diagram generally showing a high-level view of one embodiment of a process for configuring network traffic management to support connection splitting and/or connection aggregation for a particular protocol;

FIG. 6 illustrates a logical flow diagram generally showing one embodiment of a process for providing connection splitting for an arbitrary protocol, with respect to client requests;

FIG. 7 illustrates a logical flow diagram generally showing one embodiment of a process for providing connection splitting for an arbitrary protocol, with respect to server responses; and

FIG. 8 illustrates a logical flow diagram generally showing one embodiment of a process for providing connection aggregation for an arbitrary protocol, in accordance with the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. The invention may, however, be embodied in many different forms, and this specification should not be construed to limit the invention to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete and will convey fully the scope of the invention to those skilled in the art. The present invention may be embodied as methods or as devices, among other embodiments. Accordingly, the invention may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. As used herein, the term “or” is used in an inclusive sense, and is equivalent to the term “and/or”, unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meanings of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.”

The term “network connection” or simply “connection” is directed towards various links, link types, communication interfaces, protocols, or the like, that enable a computing device to communicate with a computing device over a network. One such network connection may be a Transmission Control Protocol (TCP) connection. TCP connections are virtual connections between two network nodes and are typically established through a TCP handshake protocol. The TCP protocol is described in further detail in Request for Comments 793, which is available at http://www.ietforg/rfc/rfc0793.txt?number=793.

Briefly stated, the invention is directed towards enabling a user of an intermediate network device, such as a traffic management device, to configure the device to determine transaction boundaries for network transaction processing, such as connection splitting and/or connection aggregation for an arbitrary transaction-oriented protocol. The configuration may include specifying, in the form of rules defined by way of a scripting language or command language, operations to be performed by the device. The specified rules are evaluated at runtime upon the occurrence of particular triggering network events. In general, the rules, which are adapted to the requirements of a particular protocol, include inspecting incoming data, extracting length and record type specifiers, and buffering an appropriate amount of data to determine transaction boundaries so that transactions may be split and/or aggregated. The configuration provided by the user follows a general approach that reflects elements that are common to many transaction-oriented network protocols (for example, protocol headers containing length specifiers and record type specifiers).

The invention may be employed for such purposes as enabling connection splitting and/or connection aggregation for various protocols, including application-level protocols and including proprietary or quasi-proprietary protocols, protocols for which limited information is available, and foreign protocols. Throughout this specification and the accompanying claims, a protocol is “foreign” with respect to a device if it is not natively supported by the device prior to a configuration of the device by a user. For example, in an embodiment of the invention, rules may be provided for enabling connection splitting for such special-purpose protocols as Internet Inter-ORB Protocol (IIOP), Financial IntereXchange (FIX), and the National Council for Prescription Drug Programs (NCPDP) protocol. The invention thus enables a general-purpose traffic management device to provide connection splitting, connection aggregation, and other services for a particular protocol through configuration of the device by a user, without requiring native support for that protocol to be built into the device beforehand (for example, in the form of a precompiled protocol module). In addition to enabling clients and/or servers to be used more efficiently or in a more scalable manner, embodiments of the invention provide a means for rapidly prototyping connection splitting and/or connection aggregation for a protocol in preparation for a high-performance and maintainable native implementation.

Illustrative Operating Environment

FIG. 1 illustrates one embodiment of an environment in which the invention may operate. However, not all of the depicted components may be required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention.

As shown, environment 100 includes multiple client devices 102-104, network 105, traffic management device (TMD) 106, and multiple backend servers 108-110. Each of client devices 102-104 is in communication with TMD 106 through network 105. TMD 106 is in further communication with backend servers 108-110. TMD 106 may be in communication with backend servers 108-110 through a network infrastructure, not shown, that is similar to network 105.

Generally, client devices 102-104 may include any computing device capable of connecting to another computing device to send and receive information. As such, client devices 102-104 may range widely in capabilities and features. Client devices 102-104 may include any device that is capable of connecting using a wired or wireless communication medium. The set of such devices may include devices that typically connect by way of a wired communication medium, such as personal computers, workstations, multiprocessor systems, microprocessor-based or programmable consumer electronics, and the like. The set of such devices may also include devices that typically connect using a wireless communication medium, such as cellular or other mobile telephones, personal digital assistants (PDAs), radio frequency (RF) devices, infrared (IR) devices, integrated devices combining one or more of the preceding devices, or another kind of mobile and/or wireless device. Each of client devices 102-104 may be configured to execute a client application or the like to perform various actions, including communicating requests to another device by way of a network interface and in accordance with one or more network protocols.

Network 105 couples each of client devices 102-104 with other network devices, such as TMD 106 or any other network-enabled electronic device. In essence, network 105 includes any communication means by which information may travel between any of client devices 102-104 and TMD 106. In one embodiment, network 105 includes or is a part of the set of interconnected networks that comprise the Internet. Network 105 may include local area networks (LANs), wide area networks (WANs), direct network connections, such as through a Universal Serial Bus (USB) port, or any combination thereof. In an interconnected set of LANs, including those based on differing architectures and protocols, a router may serve as a link between LANs, enabling messages to be sent from one LAN to another.

Communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may employ analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communication links known to those skilled in the art. Furthermore, remote devices may be remotely connected to either LANs or WANs by way of a modem and temporary telephone link.

Network 105 may further employ one or more wireless access technologies including, but not limited to, second, third, or fourth generation (2G, 3G, or 4G) radio access for cellular systems, wireless LAN, wireless router (WR) mesh, and the like. Access technologies such as 2G, 3G, or 4G may enable wide area coverage for network devices, such as client devices 102-104, and the like, with various degrees of mobility. For example, network 105 may enable a radio connection through a radio network access such as Global System for Mobile communications (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA), and the like. Network 105 may include an infrastructure-oriented wireless network, an ad-hoc wireless network, or another form of wireless network.

TMD 106 may include any of various kinds of devices that manage network traffic. Such devices may include, for example, routers, proxies, firewalls, load balancers, cache devices, devices that perform network address translation, any combination of the preceding devices, and the like. TMD 106 may, for example, control the flow of data packets delivered to and forwarded from an array of servers, such as backend servers 108-110. TMD 106 may direct a request for a resource to a particular server based on network traffic, network topology, capacity of a server, content requested, and various other traffic distribution mechanisms. TMD 106 may receive data packets from and transmit data packets to a device within the Internet, an intranet, or a LAN accessible through another network. TMD 106 may recognize packets that are part of the same communication, transaction, flow, and/or stream and may perform appropriate processing on such packets, such as directing them to the same server so that state information is maintained. TMD 106 may support a wide variety of network applications.

TMD 106 may receive a request from one of client devices 102-104. TMD 106 may select a server from among backend servers 108-110 to which TMD 106 forwards the request. TMD 106 may employ any of a variety of criteria and mechanisms to select the server, including those mentioned above, load balancing mechanisms, and the like. TMD 106 is further configured to receive a response to the request and to forward the response to an appropriate one of client devices 102-104. Moreover, TMD 106 may receive multiple requests in a pipeline from one of client devices 102-104, in which case TMD 106 may forward the requests to one or more selected servers.

TMD 106 may be implemented using one or more general-purpose or special-purpose computing devices of various kinds. Such devices may be implemented solely in hardware or as a combination of hardware and software. For example, such devices may include application-specific integrated circuits (ASICs) coupled to one or more microprocessors. The ASICs may be employed to provide a high-speed switch fabric while the microprocessors may perform higher-layer processing of packets. One embodiment of a network device that may be employed as TMD 106 is network device 200 of FIG. 2, configured with appropriate software.

Backend servers 108-110 may include any computing device capable of data communication with client devices 102-104. Devices that may operate as backend servers 108-110 include personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, server machines, and the like. Each of backend servers 108-110 may be configured to perform a different operation or function. Data communication may include communication of data packets, which may be sent to establish a connection, to acknowledge a receipt of data, to transport information such as a request or response, and the like. Packets received by backend servers 108-110 may be formatted in accordance with Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), or another transport protocol or the like. The packets may be communicated among backend servers 108-110, TMD 106, and client devices 102-104 in accordance with any of various protocols such as protocols within the TCP/IP protocol suite.

In this specification, unless context indicates otherwise, the term “client” refers broadly to a requester of data or services in a particular transaction, and the term “server” refers broadly to a provider of data or services in a particular transaction. In general, a computing device may be configured to function as a client device, as a server device, or as both a client device and a server device. Accordingly, the present invention is applicable to network communication that employs client-server protocols as well as protocols that do not conform to a client-server model.

Illustrative Traffic Management Device

FIG. 2 shows one embodiment of a network device, in accordance with the present invention. Network device 200 may include many more or fewer components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Network device 200 may represent, for example, TMD 106 of FIG. 1.

Network device 200 includes central processing unit 202, main memory 206, input/output interfaces 208, hard disk 210, and network interface 212, some or all of which communicate by way of bus 204. Hard disk 210 is employed for nonvolatile secondary storage and may also be used along with main memory 206 to implement virtual memory, which may be regarded as part of main memory 206. Main memory 206 typically includes both random-access memory (RAM) and read-only memory (ROM). Input/output interfaces 208 enable communication by central processing unit 202 with input and output devices, such as a display, printer, keyboard, mouse, and storage devices such as an optical disk. Network device 200 communicates over a network, such as network 105 in FIG. 1, by way of network interface 212, which may be configured for use with various network protocols, such as the TCP/IP protocol suite. Network interface 212 may include or be connected to a transceiver, a network interface card (NIC), and the like.

Main memory 206 is one example of a computer storage medium, which in turn is one kind of processor-readable medium. Computer storage media and other processor-readable media may include volatile, nonvolatile, removable, and non-removable media implemented in any technology or by way of any method for storage of information, such as machine-readable instructions, data structures, program modules, or other data. Examples of processor-readable media include RAM, ROM, EEPROM, flash memory or other memory technology, optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage devices or media, or any other medium accessible directly or indirectly by a processor and which may be used to store information volatilely or nonvolatilely. Processor-readable media may further include network communication media that embody or encode data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

Main memory 206 stores processor-executable program code and data. In particular, main memory 206 stores operating system 214, which is executed by central processing unit 202 to control the operation of network device 200. A general-purpose or special-purpose operating system may be employed. Additionally, one or more applications 216 of various kinds may be loaded into main memory 206 by way of operating system 214 and executed by central processing unit 202.

Among the applications 216 that may be loaded and run are traffic manager 218 and traffic management rules interpreter 220. Traffic manager 218 is configured to receive a request from a client device and to forward the request to a server selected based on a variety of criteria. For example, traffic manager 218 may select the server based on any of a variety of load balancing mechanisms, including a round trip time, a least connections, a packet completion rate, a quality of service, a topology, a global availability, a hop metric, a hash of an address in a received packet, a static ratio, a dynamic ratio, a source IP address, a destination IP address, a port number, deep-packet inspections including inspections of application-level data, employing historical data and the like, session persistence, and a round robin mechanism. In another embodiment, traffic manager 218 may forward the request based on a type of request. For example, a database request may be forwarded to a predetermined database server, while an email request may be forwarded to a predetermined mail server. Traffic manager 218 is likewise configured to receive responses from servers and to forward the responses to client devices.

Traffic management rules interpreter 220 enables a user of network device 200 to customize the operation of the device by writing traffic management rules, which may be defined by way of commands, scripts, or the like, to configure traffic manager 218 or other aspects or elements of traffic management actions performed by network device 200. For example, a user who operates network device 200 may write a traffic management rule to inspect the header or payload of a packet received from a client device and to direct the packet to a particular backend server based on the results of the inspection. Traffic management rules interpreter 220 interprets a script defining the rule and causes traffic manager 218 to act on network traffic in accordance with the rule.

Main memory 206 may be employed by operating system 214, applications 216, traffic manager 218, traffic management rules interpreter 220, and other programs to store data, including storage of data in buffers 222.

In one embodiment, network device 200 includes at least one ASIC chip (not shown) coupled to bus 204. The ASIC chip may include logic that performs some of the operations of network device 200. For example, the ASIC chip may perform a number of packet processing functions for incoming and/or outgoing packets, and the ASIC chip may perform at least a portion of the logic to enable the operation of traffic manager 218.

Generalized Operation

The operation of certain aspects of the invention will now be described with respect to FIGS. 3-8. Aspects of the illustrated processes may be performed at an intermediate network device such as network device 200, and may be performed by traffic manager 218 as configured by traffic management rules interpreter 220, which performs operations specified in a script provided by a user to adapt connection splitting and/or connection aggregation to a particular protocol. FIG. 3 illustrates a logical flow diagram generally showing a high-level view of one embodiment of a process for connection splitting of network transactions. FIG. 4 illustrates a logical flow diagram generally showing a high-level view of one embodiment of a process for connection aggregation of network transactions. In general, the transactions include incoming requests sent by way of one client connection, or the like.

Turning to FIG. 3, process 300 begins, after a start block, at block 302, where data arriving from the connection is received. Processing next flows to block 304, at which transaction boundaries are determined. Process 300 next proceeds to block 306, at which transactions are split across one or more destination connections, which may be backend server connections. Depending on the features of the particular protocol, a transaction split may occur after a response to a first request has been processed. Processing then returns to a calling process to perform other actions.

As shown in FIG. 4, process 400 begins, after a start block, at block 402, at which transactions arriving from multiple connections are determined. Processing next flows to block 404, where multiple determined transactions are allocated to the same destination connection. Depending on the features of the particular protocol, the determination of a transaction may occur after a response to a first request has been processed. Process 400 then returns to a calling process to perform other actions.

FIG. 5 is a logical flow diagram generally showing a high-level view of one embodiment of a process for configuring network traffic management to support connection splitting and/or connection aggregation for a particular protocol. Following a start block, process 500 begins at block 502, at which a traffic management rule is provided. The rule is adapted to the features and requirements of a particular protocol. The rule may be defined by way of a script that is provided to an interpreter, such as traffic management rules interpreter 220. Next, process 500 flows to block 504, where operations are performed on network traffic in accordance with the configuration rule to enable connection splitting and/or connection aggregation of network transactions. Processing then returns to a calling process to perform other actions.

FIG. 6 illustrates a logical flow diagram generally showing one embodiment of a process for providing connection splitting for an arbitrary protocol, with respect to client requests. Process 600 begins, after a start block, at block 602, where data is received from a client connection. Processing flows next to decision block 604, where a determination is made whether the protocol is one that is known to employ fixed-length headers. If not, processing branches to block 606; otherwise, processing proceeds directly to block 608. At block 606, received data, which may be stored in a buffer, is inspected to determine a header length specifier, after which process 600 steps to block 608.

At block 608, the header for the incoming request is examined by inspecting header_length bytes of the received data. If the header_length bytes are received in multiple segments, the received data is buffered until all the bytes are received. Processing then continues to block 610, where the record type and record length of the request are determined based on inspection of the header. Depending on the protocol, there may be many possible record types.

Process 600 next flows to decision block 612. In general, some records for a given protocol are session-specific. For a session-specific record, one particular backend server might have the information associated with the session, while other backend servers would not. Accordingly, at decision block 612, a determination is made whether the record type is session-specific. If not, processing steps directly to block 616. If, however, the record type is determined to be session-specific, process 600 branches to block 614, where additional inspection is performed on the header or, if necessary, the payload of the request to extract session-related information, after which processing advances to block 616.

At block 616, an appropriate server connection from among one or more server connections is selected. In some cases the appropriate server connection will already have been established. Otherwise, various considerations and criteria may be employed to select the server connection, including determining the currently least-loaded server, determining which server has the fewest connections, a round robin technique, the use of a weight or ratio, the use of an appropriate metric, or any other suitable criteria.

Process 600 continues to block 618, where record_length bytes of payload data are released from buffering and forwarded to the selected server connection. Next, processing advances to decision block 620, where a determination is made whether multiple outstanding requests and responses are supported by the protocol. If so, the process loops back to block 602 and receives further data. If, however, the protocol does not support multiple outstanding requests and responses, processing steps to block 622, where subsequent requests are buffered until a response to the processed request is completed. Alternatively, a subsequent request may be sent over a different backend connection; if in-order responses are required, the responses may be buffered as necessary. After the appropriate response is received and forwarded to the client, processing loops back to block 602 and process 600 receives additional data.

FIG. 7 illustrates a logical flow diagram generally showing one embodiment of a process for providing connection splitting for an arbitrary protocol, with respect to server responses. In some respects, process 700 is symmetrical to the client request side of connection splitting illustrated in FIG. 6. Process 700 begins, after a start block, at block 702, where data is received from a server connection. Processing then flows to decision block 704, at which it is determined whether the protocol employs fixed-length headers. If so, process 700 steps directly to block 708. Otherwise, if the protocol does not or is not known to feature fixed-length headers, process 700 branches to block 706, at which received data is buffered and inspected to determine a header length specifier, after which processing flows to block 708.

At block 708, header_length bytes of data are inspected. Next, at block 710, the record type of the response is determined. Process 700 then flows to decision block 712, where it is determined whether there is a record length. If there is not a record length, the server connection will not be reused, and processing accordingly branches to block 714, at which the server connection is closed for further transactions. Processing then advances to a return block and performs other actions.

If the determination at decision block 712 is affirmative, process 700 flows to block 716, at which an appropriate client connection is determined for forwarding the server response. Processing then advances to block 718, where record_length bytes of the response payload are released to the determined client connection. Process 700 then loops back to block 702 to receive additional data from the same server connection.

FIG. 8 illustrates a logical flow diagram generally showing a simplified view of one embodiment of a process for providing connection aggregation for an arbitrary protocol. The process is similar to, albeit different from, the connection splitting process, and is simpler in some respects. Process 800 begins, after a start block, at block 802, where data is received from a connection for client 1. Processing then flows to decision block 804, where it is determined whether the protocol employs fixed-length headers. If so, process 800 steps to block 808. However, if the determination is negative, process 800 branches to block 806, where buffered data is inspected to determine a header length specifier, following which process 800 advances to block 808.

At block 808, header_length bytes of response data are inspected. Next, at block 810, the record type and record length are determined based on the inspected header. Processing then flows to block 812, at which record_length bytes of buffered payload data are released to a particular server connection (server 1). Process 800 then advances to block 814, where any subsequent requests from the first client connection are buffered until a server response is complete. Processing flows next to decision block 816, at which it is determined whether the connection for server 1 is reusable. For example, the connection to client 1 might now be closed, or subsequent requests from client 1 might be directed to a different server. If the server 1 connection is not reusable, process 800 flows to a return block and performs other actions. If, however, the server 1 connection can be reused, processing branches to block 818, where data is received from a connection for client 2. The process loops back to decision block 804, thus enabling the connection for server 1 to be reused by client 2.

It will be appreciated by those skilled in the art that the flow diagrams of FIGS. 6-8 are simplified for illustrative purposes. For example, processes such as those illustrated in these figures may have additional logic to handle transitions for error states, unexpected connection closures, early responses, and the like.

Example Rule

Presented below is an example of a rule definition that may be employed in an embodiment of the invention. The syntax of the rule is similar to that of iRules, which enable the configuration of a device in the BIG-IP® family of traffic management devices provided by F5 Networks, Inc. of Seattle, Wash. Further information on iRules is available at http://www.f5.com. The example rule specifies several event declarations which determine when aspects of the defined rule are evaluated. As presented, the rule provides load balancing of multiple client requests on one connection across multiple backend servers for an arbitrary TCP-based protocol.

rule oneconnect_rule {

when CLIENT ACCEPTED {

• • TCP::collect
  • set response_done 0

}

when CLIENT_DATA {

• • # find the end of the request
  • set index [string first “\n\n” [TCP::payload]]
  • if {$index>0} {
    • TCP::release [expr $index+2]
    • TCP::notify request
  • }

}

when SERVER_DATA {

• • if {$response_done} {
    • TCP::notify response
    • set response_done 0
    • TCP::collect

}

# find the end of the response

set index [string first “\r\n\r\n” [TCP::payload]]

set len 0

if {$index>0} {

• • # get the content length
  • regexp {Content-Length:\s*(\d+)} [TCP::payload]→len
  • # send up the headers
  • TCP::release [expr $index+4]
  • if {[TCP::offset]==$len} {
    • # we already have the complete response
    • TCP::release $len
    • TCP::notify response
  • }
  • else {
    • # skip the remaining data
    • set len [expr $len−[TCP::offset]]
    • TCP::release
    • puts “skip $len”
    • TCP::collect 0 $len
    • set response_done 1
  • }

}

}

when USER_REQUEST {

• • puts “USER_REQUEST”

}

when USER_RESPONSE {

• • puts “USER_RESPONSE”
  • LB::detach

}

The above specification provides 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.

Claims

1. A network device, comprising: a memory device that stores an interpreter; anda processor configured to execute the interpreter and perform actions, including: receiving a configuration rule change adapted to a protocol that is foreign to the network device where the protocol is not natively supported by the network device without the configuration rule change to the network device;employing the configuration rule change to detect a boundary of a transaction in received traffic;inspecting one or more portions of the received traffic to determine a header length of the transaction, wherein the header length is employed to determine a header of the transaction;determining a record type and a record length that correspond to the transaction based on contents of the header;managing a connection splitting using the record type, the record length, and the detected boundary of the transaction to allocate two or more requests within the received traffic on a same input connection to two or more different backend servers having different backend server connections, wherein a destination backend server is chosen from among the two or more different backend servers based on at least the configuration rule change and at least one criteria for load-balancing the destination backend server; andreusing at least one connection to the two or more backend servers for a second client application when responses by the two or more backend servers to a first client application are complete.

2. The network device of claim 1, wherein the processor performs actions, further including: when a record type for the protocol is determined to be session-specific based on inspection of a protocol header record: extracting session-related information from the received traffic; andusing the extracted session-related information in part to select one of the backend server connections.

3. The network device of claim 1, wherein the processor performs actions, further including: determining at least one requirement of the protocol based on an inspection of the received traffic in at least one request;when the protocol is determined to support multiple outstanding requests based on the at least one requirement, receiving additional traffic without waiting for a response to the at least one request; otherwise,buffering subsequent traffic requests until the response to the at least one request is completed.

4. The network device of claim 1, further comprising: receiving subsequent traffic from one of the different backend server connection;determining when there is a record length within a header of the subsequent traffic; andwhen the record length is undetected within the header of the subsequent traffic, closing the one backend server connection to any subsequent transaction.

5. The network device of claim 1, wherein the processor performs actions, further including: employing the configuration rule change to detect another boundary of another transaction; andfurther managing a multiple-client connection aggregation using the other detected boundary of the other transaction to direct two or more other requests from two or more different client devices to a same backend server connection to a particular backend server.

6. The network device of claim 5, wherein managing multiple-client connection aggregation further comprises sending a subsequent request from a first client device in the two or more client devices, to a different backend server connection based on a third detected boundary of a third transaction.

7. The network device of claim 1, wherein the protocol is an application-level protocol situated above a Transmission Control Protocol.

8. An apparatus comprising a non-transitory computer readable medium, having computer-executable instructions stored thereon, that in response to execution by a network device, cause the network device to perform operations, comprising: receiving a configuration rule change adapted to a protocol that is foreign to the network device where the protocol is not natively supported by the network device without the configuration rule change to the network device;employing the configuration rule change to detect a boundary of a transaction in received traffic;inspecting one or more portions of the received traffic to determine a header length of the transaction, wherein the header length is employed to determine a header of the transaction;determining a record type and a record length that correspond to the transaction based on contents of the header;managing a connection splitting using the record type, the record length, and the detected boundary of the transaction to allocate two or more requests within the received traffic on a same input connection to two or more different backend servers having different backend server connections, wherein a destination backend server is chosen from among the two or more different backend servers based on at least the configuration rule change and at least one criteria for load-balancing the destination backend server; andreusing at least one connection to the two or more backend servers for a second client application when responses by the two or more backend servers to a first client application are complete.

9. The apparatus of claim 8, wherein the network device performs actions, further including: when a record type for the protocol is determined to be session-specific based on inspection of a protocol header record: extracting session-related information from the received traffic; andusing the extracted session-related information in part to select one of the backend server connections.

10. The apparatus of claim 8, wherein the network device performs actions, further including: determining at least one requirement of the protocol based on an inspection of the received traffic in at least one request;when the protocol is determined to support multiple outstanding requests based on the at least one requirement, receiving additional traffic without waiting for a response to the at least one request; otherwise,buffering subsequent traffic requests until the response to the at least one request is completed.

11. The apparatus of claim 8, further comprising: receiving subsequent traffic from one of the different backend server connections;determining if there is a record length within a header of the subsequent traffic; andif the record length is undetected within the header of the subsequent traffic, closing the one backend server connection to any subsequent transactions.

12. The apparatus of claim 8, wherein the network device performs actions, further including: employing the configuration rule change to detect an other boundary of an other transaction; andfurther managing a multiple-client connection aggregation using the other detected boundary of the other transaction to direct two or more other requests from two or more different client devices to a same backend server connection to a particular backend server.

13. The apparatus of claim 8, wherein the configuration rule change is defined using a scripting language that is evaluated at runtime upon an occurrence of a defined network event.

14. The apparatus of claim 8, wherein network device operates as a traffic management device that is interposed between one or more client devices and a plurality of backend servers.

15. A system, comprising: a plurality of backend server devices having processors and arranged to receive requests and provide responses; anda network device having one or more processors that perform actions, including: receiving a configuration rule change adapted to a protocol that is foreign to the network device where the protocol is not natively supported by the network device without the configuration rule change to the network device;employing the configuration rule change to detect a boundary of a transaction in received traffic;inspecting one or more portions of the received traffic to determine a header length of the transaction, wherein the header length is employed to determine a header of the transaction;determining a record type and a record length that correspond to the transaction based on contents of the header;managing a connection splitting using the record type, the record length, and the detected boundary of the transaction to allocate two or more requests within the received traffic on a same input connection to two or more different backend server devices in the plurality of server devices having different backend server connections, wherein a destination backend server is chosen from among the two or more different backend servers based on at least the configuration rule change and at least one criteria for load-balancing the destination backend server; andreusing at least one connection to the two or more backend servers for a second client application when responses by the two or more backend servers to a first client application are complete.

16. The system of claim 15, wherein the network device performs actions, further including: when a record type for the protocol is determined to be session-specific based on inspection of a protocol header record: extracting session-related information from the received traffic; andusing the extracted session-related information in part to select one of the backend server connections.

17. The system of claim 15, wherein the network device performs actions, further including: determining at least one requirement of the protocol based on an inspection of the received traffic in at least one request;when the protocol is determined to support multiple outstanding requests based on the at least one requirement, receiving additional traffic without waiting for a response to the at least one request; otherwise,buffering subsequent traffic requests until the response to the at least one request is completed.

18. The system of claim 15, further comprising: receiving subsequent traffic from one of the different backend server connections;determining if there is a record length within a header of the subsequent traffic; andif the record length is undetected within the header of the subsequent traffic, closing the one backend server connection to any subsequent transactions.

19. The system of claim 15, wherein the network device performs actions, further including: employing the configuration rule change to detect an other boundary of an other transaction; andfurther managing a multiple-client connection aggregation using the other detected boundary of the other transaction to direct two or more other requests from two or more different client devices to a same backend server connection to a particular backend server.

20. The system of claim 15, wherein the configuration rule change is defined using a scripting language that is evaluated at runtime upon an occurrence of a defined network event.