Protocol-configurable transaction processing

• US 9,225,479 B1
• Filed: 09/13/2012
• Issued: 12/29/2015
• Est. Priority Date: 08/12/2005
• Status: Active Grant

• Current Assignee: F5 Networks, Inc. (F5 Incorporated)
• Original Assignee: F5 Networks, Inc. (F5 Incorporated)
• Inventors: Rothstein, Jesse A.
• Primary Examiner(s): Shaw, Peter
• Application Number:
  US13/615,007
• Time in Patent Office: 1,202 Days
• Field of Search: 709/223
• US Class Current: 1/1
• CPC Class Codes: H04L 5/00 Arrangements affording multiple use of the transmission path
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 69/18 Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

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.

Claims

1. A network device, comprising:

a memory device that stores an interpreter; and

a 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; and

reusing 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; and

using 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; and

when 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; and

further 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; and

reusing 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; and

using 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; and

if 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; and

further 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; and

a 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; and

reusing 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; and

using 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; and

if 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; and

further 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.