CA2385899C - System and method for managing connections between a client and a server - Google Patents
System and method for managing connections between a client and a server Download PDFInfo
- Publication number
- CA2385899C CA2385899C CA 2385899 CA2385899A CA2385899C CA 2385899 C CA2385899 C CA 2385899C CA 2385899 CA2385899 CA 2385899 CA 2385899 A CA2385899 A CA 2385899A CA 2385899 C CA2385899 C CA 2385899C
- Authority
- CA
- Canada
- Prior art keywords
- client
- server
- connection
- origin server
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
- H04L67/1078—Resource delivery mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/2871—Implementation details of single intermediate entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
- H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
Abstract
An adapter card (108) for managing connections between clients (109) and a network server (106) off-loads the connection management burden from the server (106). The adapter card (108) includes a memory (124) with an embedded proxy application (132) and a communication protocol stack (134), a processing unit (126) for executing the application code, a network controller (129) for interfacing with an internetwork (102), and a bus protocol bridge (128) for interfacing with the internal bus (120) of the network server (106). The proxy application (132) receives client requests on behalf of the server (106) over relatively slow and unreliable network connections, and submits the requests to the server over fast, reliable bus connections.
Description
SYSTEM AND METHOD FOR MANAGING
CONNECTIONS BETWEEN A CLIENT AND A SERVER
Jack J. Smith; Richard T. Burright; W. Spencer Worley, III;
Eoin B. MacDonell; John A. Vastano; and William T. Weatherford BACKGROUND OF THE INVENTION
Field of the Invention This invention relates generally to network servers and more particularly to servers that host a large number of client connections. Even more particularly, the present invention relates to servers (e.g., internet web servers) which host a large number of relatively slow client connections.
Description of the Background Art It is common for network file servers such as internet web servers to host a large number of relatively slow client connections. The large number of open connections places a substantial burden on the server central processing unit (CPU), just to manage the open connections. For example, managing the open connections on a loaded server can consume 30-40 % or more of the CPU's operating capacity. This burden substantially reduces the percentage of CPU cycles available to perform the primary function of the server, i.e., providing data to clients.
The connection management burden on the server CPU degrades the performance of the server software routines and reduces the maximum number of client connections that can be open at one time. As a result, web-hosting companies must provide additional, redundant servers to serve an increased number of clients. The cost of acquiring and maintaining additional web servers is substantial.
Proxy servers perform some client connection management functions, and are known in the art. However, it is well-known and commonly accepted in the art that such proxy servers must be housed separately from the server, and thus must communicate with the server over relatively slow, error prone network connections which the server must manage.
See for example, Ari Luotonen, Web Proxy ~-:ervers (Prentice Hall, 1997), What is needed, therefore, is a system and method for relieving the server CPU
of the connection management burden, thus allowing the server to more efficiently host an increased number of clients.
.
SUMMARY
The present invention overcomes the problems associated with the prior art by providing a system and method for managing connections between a plurality of clients and a server. The invention facilitates off-loading the connection management burden from the host CPU to an adapter card interposed between the network and the host bus.
The adapter card includes a network controller, a memory device, a processing unit, and a protocol adapter. The memory device provides storage for data and code.
The code includes a proxy application that conununicates with clients on the network via the network controller, and communicates with the server via the protocol adapter, which is coupled directly to the server bus.
When executed by the processing unit, the proxy application manages client connections by establishing network connections between the proxy application and clients via the network, and by establishing bus connections between the proxy application and the server via the server bus. Additionally, the memory device provides data buffering, which allows many network connections to be oper_ with clients, while a relatively few bus connections are open to the server. In a particular embodiment, the proxy accumulates client data in the buffers from the large number of slow client connections, and then submits the client data to the server over the fast bus connections. Conversely, the proxy receives server data via the fast bus connections, temporarily stores the server data, and then forwards the server data to the clients via the slow client connections.
~ In a more particular embodiment, the code includes a communications protocol stack that is employed by the application proxy to communicate with the clients and the server. In an even more particular embodiment, the communications protocol stack is a Transmission Control Protocol/Internet Protocol (TCP/IP) stack.
CONNECTIONS BETWEEN A CLIENT AND A SERVER
Jack J. Smith; Richard T. Burright; W. Spencer Worley, III;
Eoin B. MacDonell; John A. Vastano; and William T. Weatherford BACKGROUND OF THE INVENTION
Field of the Invention This invention relates generally to network servers and more particularly to servers that host a large number of client connections. Even more particularly, the present invention relates to servers (e.g., internet web servers) which host a large number of relatively slow client connections.
Description of the Background Art It is common for network file servers such as internet web servers to host a large number of relatively slow client connections. The large number of open connections places a substantial burden on the server central processing unit (CPU), just to manage the open connections. For example, managing the open connections on a loaded server can consume 30-40 % or more of the CPU's operating capacity. This burden substantially reduces the percentage of CPU cycles available to perform the primary function of the server, i.e., providing data to clients.
The connection management burden on the server CPU degrades the performance of the server software routines and reduces the maximum number of client connections that can be open at one time. As a result, web-hosting companies must provide additional, redundant servers to serve an increased number of clients. The cost of acquiring and maintaining additional web servers is substantial.
Proxy servers perform some client connection management functions, and are known in the art. However, it is well-known and commonly accepted in the art that such proxy servers must be housed separately from the server, and thus must communicate with the server over relatively slow, error prone network connections which the server must manage.
See for example, Ari Luotonen, Web Proxy ~-:ervers (Prentice Hall, 1997), What is needed, therefore, is a system and method for relieving the server CPU
of the connection management burden, thus allowing the server to more efficiently host an increased number of clients.
.
SUMMARY
The present invention overcomes the problems associated with the prior art by providing a system and method for managing connections between a plurality of clients and a server. The invention facilitates off-loading the connection management burden from the host CPU to an adapter card interposed between the network and the host bus.
The adapter card includes a network controller, a memory device, a processing unit, and a protocol adapter. The memory device provides storage for data and code.
The code includes a proxy application that conununicates with clients on the network via the network controller, and communicates with the server via the protocol adapter, which is coupled directly to the server bus.
When executed by the processing unit, the proxy application manages client connections by establishing network connections between the proxy application and clients via the network, and by establishing bus connections between the proxy application and the server via the server bus. Additionally, the memory device provides data buffering, which allows many network connections to be oper_ with clients, while a relatively few bus connections are open to the server. In a particular embodiment, the proxy accumulates client data in the buffers from the large number of slow client connections, and then submits the client data to the server over the fast bus connections. Conversely, the proxy receives server data via the fast bus connections, temporarily stores the server data, and then forwards the server data to the clients via the slow client connections.
~ In a more particular embodiment, the code includes a communications protocol stack that is employed by the application proxy to communicate with the clients and the server. In an even more particular embodiment, the communications protocol stack is a Transmission Control Protocol/Internet Protocol (TCP/IP) stack.
In one embodiment, the server connections are opened only after the proxy determines that a complete client request has been received. The server connections are then closed after the proxy receives a response to the client request from the server.
Optionally, a predetermined number of persistent server connections are opened at system start-up, and the proxy uses these persistent connections to communicate with the server.
The proxy application optionally includes a number of application specific proxies, including but not limited to an HTTP proxy, a security proxy, and/or a pass-through proxy. In a particular embodiment, a master process module of the proxy discerns an application identifier (e.g., a well known port number) form the client data, and invokes one or more of the application specific proxies corresponding to the value of the identifier.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is described with reference to the following drawings, wherein like reference numbers denote substantially similar elements:
FIG. 1 is a block diagram of a server and an adapter card according to the present invention;
FIG. 2 is a block diagram of the working memory of the adapter card of FIG. 1, showing the proxy module in greater detail;
FIG. 3 is a block diagram showing the application proxies module of FIG. 2 in greater detail;
FIG. 4 is a block diagram showing exemplary data structures for at least some of the data stored in the data buffer of FIG. 2;
FIG. 5 is a flow chart summarizing one method for managing connections between a client and a server according to the present invention;
FIG. 6 is a flow chart summarizing one method for performing the first step of the method of FIG. 5;
FIG. 7 is a flow chart summarizing one method for performing the second step of the method of FIG. 5;
FIG. 8 is a flow chart summarizing one method for performing the third step of the method of FIG. 5;
Optionally, a predetermined number of persistent server connections are opened at system start-up, and the proxy uses these persistent connections to communicate with the server.
The proxy application optionally includes a number of application specific proxies, including but not limited to an HTTP proxy, a security proxy, and/or a pass-through proxy. In a particular embodiment, a master process module of the proxy discerns an application identifier (e.g., a well known port number) form the client data, and invokes one or more of the application specific proxies corresponding to the value of the identifier.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is described with reference to the following drawings, wherein like reference numbers denote substantially similar elements:
FIG. 1 is a block diagram of a server and an adapter card according to the present invention;
FIG. 2 is a block diagram of the working memory of the adapter card of FIG. 1, showing the proxy module in greater detail;
FIG. 3 is a block diagram showing the application proxies module of FIG. 2 in greater detail;
FIG. 4 is a block diagram showing exemplary data structures for at least some of the data stored in the data buffer of FIG. 2;
FIG. 5 is a flow chart summarizing one method for managing connections between a client and a server according to the present invention;
FIG. 6 is a flow chart summarizing one method for performing the first step of the method of FIG. 5;
FIG. 7 is a flow chart summarizing one method for performing the second step of the method of FIG. 5;
FIG. 8 is a flow chart summarizing one method for performing the third step of the method of FIG. 5;
FIG. 9 is a flow chart summarizing one method for performing the fourth step of the method of FIG. 5;
FIG. 10 is a flow chart summarizing one method for performing the fifth step of the method of FIG. 5; and FIG. 11 is a flow chart summarizing one method for performing the sixth step of the method of FIG. 5.
DETAILED DESCRIPTION
The present invention overcomes the problems associated with the prior art, by off-loading much of the connection management burden from the server's main processor with a proxy application run on a different processing unit. In the following description, numerous specific details are set forth (e.g., particular communications protocols, particular software and data structures, etc.) in order to provide a thorough understanding of the invention.
Those skilled in the art will recognize, however, that the invention may be practiced apart from these specific details. In other instances, details of well known network components and programming practices (e.g., establishing connections via a communications protocol stack) have been omitted, so as not to unnecessarily obscure the present invention.
FIG. I is a block diagram showing a system 100 coupled to an intemetwork 102 via a physical network media 104. In a particular implementation, system 100 is an internet web server, and internetwork 102 is the Internet, but those skilled in the art will recognize that the present invention may be implemented in any type of network server.
System 100 includes a file server (e.g., an HTTP web server) 106 and an adapter card 108. File server 106 provides data to and receives data from clients 109(1-n) on internetwork 102, via adapter card 108. Adapter card 108 establishes and maintains network connections between clients 109(1-n) and adapter card 108, and establishes bus connections between server 106 and adapter card 108. Thus connected, adapter card 108 receives communications from clients 109(1-n) on behalf of server 106, forwards the communications to server 106, receives responsvs from server 106 on behalf of clients 109, and forwards the responses to clients 109. Those skilled in the artwill recognize that file server 106 is an origin server, because file ~ E1 server 106 hosts resources (e.g., web pages) for ciients.109.
Server 106 includes non-volatile memory 110, working memory 112, server mass data storage 114, a processing unit 116, and one or inore user input/Output (ItO) devices 118, all intercommunicating via a server bus 120 (e.g., PCI bus). Non-volatile memory 110 (e.g., read-only memory and/or one or more hard-disk drives) provides storage for data and code which is retained even when server 106 is powered down. Working memory 112 (e.g., random access memory) provides operational memory for server 106, and includes executable code (e.g., an operating system) which is loaded into working memory 112 during start-up.
Among other programs, working memory 112 includes server applications 121 and a communication protocol stack 1-22. Server applications 121 include network software applications (e.g., FTP, HTTP, etc.) which allow server 106 to function as a network server.
Communications protocol stack 122 is a standard protocol stack (e.g., TCP/IP) which facilitates communication with other machines over an internetwork. Standard protocol stacks are well known in the art. See, for example, W. Richard Stevens, TCP/IP
Illustrated, li'o1. 1(Addison-Wesley, 1994), Server mass data storage 114 provides data storage (e.g., one or more hard disk dri ves) for data (e.g.. HTML
pages, graphics files, etc.), which the server provides to clients 109(1-n) attached to intemetwork 102. Processing unit 116 executes the instructions in working memory 112 to cause server 106 to carry out its primary function (e.g., providing data to and receiving data from clients). I/O devices 118 typically include a keyboard, a monitor, and/or such other devices which facilitate user interaction with server 106. Each of the above described components is typically found in a network server such as an internet web server.
Adapter card 108 includes non-volatile memory 123, working memory 124, a processina unit 126, a bus protocol bridge 128, and a network controller 129, all intercommunicating via an adapter bus 130. Non-volatile memory 123 provides storage for data and code (e.g., boot code) which is retained even when adapter 108 is powered down.
Processing unit 126 imparts functionality to adapter card 108 by executing the code present in working memory 124. Bus protocol bridge 128 provides an interface between adapter bus 130 and server bus 120, and network controller 129 provides an interface between adapter bus I30 and network media 104.
Vv'orkin~.memor~- 124 provides operational memorv for adapter 108, and includes a ~ _ -proxv applicatiop 132 and a communication protocol stack 134. Proxy 132 and protocol stack 134 are loaded from non-volatile memoi-v 12; into working memory 124 at start-up.
Optionally, proxy 132 and protocol stack 134 can be loaded from one or more alternative sources, including but not limited to non-volatile memory 110 or server mass data storage 114 of server 106. Proxy 132, when executed by processing unit 126, establishes and manages the above described connections between adapter 108 and server 106 and between adapter 108 and clients 109.
In this particular embodiment of the invention, protocol stacks 122 and 134 are standard (e.g., TCP/IP) protocol stacks. Employing a standard communication protocol stack in adapter 108 facilitates the use of the standard communication software (e.g., protocol stack 122) already present in the vast majority of network servers. Those skilled in the art will recognize, however, that this particular element (as well as other described elements, even if not explicitly stated) is not an essential element of the present invention.
For example, the present invention may be practiced with custom communication software (e.g., direct communication between server applications 121 and either protocol stack 134 or proxy 132) in both server 106 and adapter 108. Further, in particular embodiments of the invention, this element may be omitted by providing proxy 132 with direct access to the resources (e.g., server mass data storage 114) of server 106.
Adapter card 108 is coupled to server 106 via a bus connection 136 between bus protocol bridge 126 and server bus 120. In this particular embodiment, bus connection 136 is a typical bus expansion slot, for example a PCI slot. Those skilled in the art will recognize, however, that the present invention may be implemented with other types of bus connections, including but not limited to an ISA slot, a USB port, a serial port, or a parallel port. Bus connection 136 facilitates high speed, large packet size, relatively error free (as compared to network connections) communication between proxy 132 and server applications 121, greatly reducing the connection management burden on processing unit 116 of server 106. In summary, proxy 132 (running on processing unit 116) communicates with clients 109 over slow, error prone network connections, and then communicates with server applications 121 on behalf of clients 109 over high speed bus connection 136.
FIG. 2 is a block diagram of working memory 124 showing proxy 132 and protocol stack 134 in greater detail. Those skilled in the art will recognize that while the various software modules of proxy 132 are shown as interconnected functional blocks, the software modules are actually blocks of executable code stored in working memory 124 that can communicate with one another when executed by processing unit 126 (FIG. 1).
FIG. 10 is a flow chart summarizing one method for performing the fifth step of the method of FIG. 5; and FIG. 11 is a flow chart summarizing one method for performing the sixth step of the method of FIG. 5.
DETAILED DESCRIPTION
The present invention overcomes the problems associated with the prior art, by off-loading much of the connection management burden from the server's main processor with a proxy application run on a different processing unit. In the following description, numerous specific details are set forth (e.g., particular communications protocols, particular software and data structures, etc.) in order to provide a thorough understanding of the invention.
Those skilled in the art will recognize, however, that the invention may be practiced apart from these specific details. In other instances, details of well known network components and programming practices (e.g., establishing connections via a communications protocol stack) have been omitted, so as not to unnecessarily obscure the present invention.
FIG. I is a block diagram showing a system 100 coupled to an intemetwork 102 via a physical network media 104. In a particular implementation, system 100 is an internet web server, and internetwork 102 is the Internet, but those skilled in the art will recognize that the present invention may be implemented in any type of network server.
System 100 includes a file server (e.g., an HTTP web server) 106 and an adapter card 108. File server 106 provides data to and receives data from clients 109(1-n) on internetwork 102, via adapter card 108. Adapter card 108 establishes and maintains network connections between clients 109(1-n) and adapter card 108, and establishes bus connections between server 106 and adapter card 108. Thus connected, adapter card 108 receives communications from clients 109(1-n) on behalf of server 106, forwards the communications to server 106, receives responsvs from server 106 on behalf of clients 109, and forwards the responses to clients 109. Those skilled in the artwill recognize that file server 106 is an origin server, because file ~ E1 server 106 hosts resources (e.g., web pages) for ciients.109.
Server 106 includes non-volatile memory 110, working memory 112, server mass data storage 114, a processing unit 116, and one or inore user input/Output (ItO) devices 118, all intercommunicating via a server bus 120 (e.g., PCI bus). Non-volatile memory 110 (e.g., read-only memory and/or one or more hard-disk drives) provides storage for data and code which is retained even when server 106 is powered down. Working memory 112 (e.g., random access memory) provides operational memory for server 106, and includes executable code (e.g., an operating system) which is loaded into working memory 112 during start-up.
Among other programs, working memory 112 includes server applications 121 and a communication protocol stack 1-22. Server applications 121 include network software applications (e.g., FTP, HTTP, etc.) which allow server 106 to function as a network server.
Communications protocol stack 122 is a standard protocol stack (e.g., TCP/IP) which facilitates communication with other machines over an internetwork. Standard protocol stacks are well known in the art. See, for example, W. Richard Stevens, TCP/IP
Illustrated, li'o1. 1(Addison-Wesley, 1994), Server mass data storage 114 provides data storage (e.g., one or more hard disk dri ves) for data (e.g.. HTML
pages, graphics files, etc.), which the server provides to clients 109(1-n) attached to intemetwork 102. Processing unit 116 executes the instructions in working memory 112 to cause server 106 to carry out its primary function (e.g., providing data to and receiving data from clients). I/O devices 118 typically include a keyboard, a monitor, and/or such other devices which facilitate user interaction with server 106. Each of the above described components is typically found in a network server such as an internet web server.
Adapter card 108 includes non-volatile memory 123, working memory 124, a processina unit 126, a bus protocol bridge 128, and a network controller 129, all intercommunicating via an adapter bus 130. Non-volatile memory 123 provides storage for data and code (e.g., boot code) which is retained even when adapter 108 is powered down.
Processing unit 126 imparts functionality to adapter card 108 by executing the code present in working memory 124. Bus protocol bridge 128 provides an interface between adapter bus 130 and server bus 120, and network controller 129 provides an interface between adapter bus I30 and network media 104.
Vv'orkin~.memor~- 124 provides operational memorv for adapter 108, and includes a ~ _ -proxv applicatiop 132 and a communication protocol stack 134. Proxy 132 and protocol stack 134 are loaded from non-volatile memoi-v 12; into working memory 124 at start-up.
Optionally, proxy 132 and protocol stack 134 can be loaded from one or more alternative sources, including but not limited to non-volatile memory 110 or server mass data storage 114 of server 106. Proxy 132, when executed by processing unit 126, establishes and manages the above described connections between adapter 108 and server 106 and between adapter 108 and clients 109.
In this particular embodiment of the invention, protocol stacks 122 and 134 are standard (e.g., TCP/IP) protocol stacks. Employing a standard communication protocol stack in adapter 108 facilitates the use of the standard communication software (e.g., protocol stack 122) already present in the vast majority of network servers. Those skilled in the art will recognize, however, that this particular element (as well as other described elements, even if not explicitly stated) is not an essential element of the present invention.
For example, the present invention may be practiced with custom communication software (e.g., direct communication between server applications 121 and either protocol stack 134 or proxy 132) in both server 106 and adapter 108. Further, in particular embodiments of the invention, this element may be omitted by providing proxy 132 with direct access to the resources (e.g., server mass data storage 114) of server 106.
Adapter card 108 is coupled to server 106 via a bus connection 136 between bus protocol bridge 126 and server bus 120. In this particular embodiment, bus connection 136 is a typical bus expansion slot, for example a PCI slot. Those skilled in the art will recognize, however, that the present invention may be implemented with other types of bus connections, including but not limited to an ISA slot, a USB port, a serial port, or a parallel port. Bus connection 136 facilitates high speed, large packet size, relatively error free (as compared to network connections) communication between proxy 132 and server applications 121, greatly reducing the connection management burden on processing unit 116 of server 106. In summary, proxy 132 (running on processing unit 116) communicates with clients 109 over slow, error prone network connections, and then communicates with server applications 121 on behalf of clients 109 over high speed bus connection 136.
FIG. 2 is a block diagram of working memory 124 showing proxy 132 and protocol stack 134 in greater detail. Those skilled in the art will recognize that while the various software modules of proxy 132 are shown as interconnected functional blocks, the software modules are actually blocks of executable code stored in working memory 124 that can communicate with one another when executed by processing unit 126 (FIG. 1).
Proxy 132 includes a master process module 202, a plurality of client process modules 204(1-n), a data buffer 206, and an application proxies module 208. Master process module provides overall control and coordination of the various modules of proxy 132.
Responsive to a connection request from a client 109 on internetwork 102 (FIG. 1) master process 202 accepts the connection request, initializes a data structure for that client connection in data buffer 206, initiates a new, separate client connection process 204 to handle the connection, and then notifies application proxies 208 that the particular client connection has been established. Each client process 204 handles one such client connection.
Application proxies 208 establish and manage bus connections with server 106. Data buffer 206 provides storage for data received from clients 109 and destined for server 106, for data received from server 106 and destined for clients 109, and for connection data relating to established client and/or server connections. Those skilled in the art will recognize that proxy 132 is reverse proxy application, because proxy 132 is a proxy for server 106 servicing client requests on behaif of the server 106.
Communications protocol stack 134 is a TCP/IP stack including a sockets layer 210; a TCP layer 212, an IP layer 214, and a device layer including a network driver 216 and a 1-5 server bus driver 218. The functionality of each of the individual layers of protocol stack 134 is well known in the art, and will not, therefore, be discussed in detail herein. Connections between the various modules of proxy 132 and server applications 121 are established through sockets layer 210, TCP layer 212, IP layer 214 and server bus driver 218.
Connections between the various modules ot'proxy T32 are established with clients 109 ?0 through sockets layer 210, TCP layer 212, IP layer 214 and network driver 216.
FIG. 3 is a block diagram showing application proxies module 208 to include a plurality of application specific proxies 208( l-f), including a hypertext transfer protocol .
(HTTP) proxy 208(1), a pass-through proxy 208(2), a security proxy 208(3), and an "other"
proxy 208(f). Master process 202 notifies application proxies 208 of an established client 25 connection, bv configuring one or more of the application specific proxies 208(1-f) to service the client connection. One means of configuring an application specific proxy (e.g., HTTP
proxy 208(1)) is to enter a client process identifier in the processing queue of the application specific proxy.
Master process 202 determines which of the application specific proxies to implement '10 for a particular client process from the port number inclucled in the client connection request.
It is standard practice to use well known port numbers to identify particular network applications and/or protocols (e.g., file transfer protocol (FTP), HTTP, etc.). For example, port number 80 corresponds to an HTTP connection request. Master process 202 therefore notifies HTTP proxy 208(1) of all client process' 204 initiated in response to a connection request indicating port 80.
HTTP proxy 208(1) monitors each of the client processes of which it is notified.
When HTTP proxy 208(1) determines that a complete HTTP request is received and stored in data buffer 206 by a client process (e.g., 204(n)), HTTP proxy 208(1) opens a connection to the server, transmits the request to the server, receives a response from the server, stores the response in data buffer 206 and then closes the server connection. The server response is then transmitted to client 109(n) by the associated client process 204(n).
When master process 202 receives a connection request with a port number that does not correspond to any of the other application specific proxies, master process 202 notifies pass-through proxy 208(2). Pass-through proxy 208(2) simply opens a server connection, transfers the data received from the associated client process 204 from data buffer 206 to server 106, and then closes the server connection.
Master process 202 may notify some application specific proxies of all client connections, regardless of the associated port number. For example, security proxy 208(3) is operative to screen all client connection requests by, for example, terminating any client process initiated in response to a connection request lacking some indicia of authorization, prior to implementing one of the other application specific proxies.
"Other" proxy 208(f) is included in FIG. 3 to show that application proxies 208 can include any currently known or future developed proxy that is desirable for a particular application, including but not limited to, caching HTTP proxy applications, electronic mail applications, and file transfer applications.
FIG. 4 shows an example of client data structures 402( l-n) and proxy data structures 404(1-f), implemented in data buffer 206 to effect the transfer of data through proxy 132.
Master process 202 creates and initializes one client data structure 402 for each client process 204, and one proxy data structure 404 for each application specific proxy in application proxies 208.
Each client data structure 402 includes a client socket 406, a server socket 408, a connection state 410, an input queue 412, an output queue 414, and application proxy data 416. For each client connection (e.g., connection (n)), client socket 406(n) and server socket 408(n) each include the IP address and port number of the client 109(n) and server 106, respectively, thus uniquely associating each client data structure 402(n) with a single one of client processes 204(n). Connection state 410(n) indicates the current status (e.g., complete request received, response received, etc.) of the connection (n). Input queue 412(n) is used to store and accumulate data received from client 109(n) by the client process 204(n) associated with the particular data structure 402(n). Output queue 414(n) is used to store data from application proxies 208 which is to be forwarded to client 109(n) by client process 204(n).
Application proxy data 416(n) is provided to store any information specific to a particular application proxy (e.g., flags, etc.).
Each proxy data structure(e.g., 404(f)) includes a client queue 418(f), a client ready queue 420(f), and a read pending queue 422(f). Client queue 418(f) includes a client process descriptor (e.g., a pointer to a related client data structure 402) for each client process 204 associated with the particular application proxy (f) to which the proxy data structure 404(f) corresponds. Client ready queue 420(f) includes a client process descriptor for each client data structure 402 that has data in its input queue 412 that is ready to be processed (e.g., transferred to server 106) by the associated application proxy (f). Read pending queue 422(f) includes the client process descriptor for each client process that is awaiting a response from server 106.
Those skilled in the art will understand that the above described client data structure 402 and proxy data structure 404 are exemplary in nature, and that other data structures may be employed with the present invention. The configuration of such alternate data structures will necessarily depend on the function and structure of the particular application specific proxies that are employed.
FIG. 5 is a flowchart summarizing a particular method 500 of managing connections between clients and a server according to the present invention. In a first step 502 proxy 132 establishes a network connection with a client 109, and then in a second step 504 receives a communication (e.g., an HTTP request) from client 109 via the network connection. Next, in a third step 506, proxy 132 establishes a bus connection with server 106, and then in a fourth step 508 forwards the received client communication to server 106 via the bus connection.
Then, in a fifth step 510, proxy 132 receives a response (e.g., HTML data) to the client communication from server 106, and in sixth step 512 transmits the response to client 109 via the client network connection. Finally, in a seventh step 514, proxy 132 determines whether there is a signal to terminate (e.g., shut down), and if there is a signal to terminate, then method 500 ends. If there is no signal to terminate in seventh step 514, then method 500 returns to first step 502, to establish a network connection with another client 109.
FIG. 6 is a flow chart summarizing one particular method 600 of performing first step 502 (establishing a network connection with a client) of method 500. In a first step, master process 202 connects to internetwork 102. Then in a second step 604 master process 202 listens to the traffic on internetwork 102 to determine if there is a connection request from a client 109. If there is no client connection request, then method 600 ends. If there is a connection request from a client 109(n), then in a third step 606, master process 202 accepts the connection request form client 109(n), initiates a client process 204(n) to handle the connection, and initializes a client data structure 402(n) in data buffer 206.
Next, in a fourth step 608, master process 202 discerns a proxy application identifier (e.g., a port number) from the client connection request and notifies one or more of application proxies 208(1-f), depending on the value of the identifier, by writing the client process descriptor (e.g., pointer to client data structure 402(n)) into the client queues 418 of the respective proxy data structures 404. Finally, in a fifth step 610, master process 202 determines whether the maximum allowed number of client connections are open. If the maximum number of client connections are open, then method 600 ends. If the maximum number of client connections are not open, then method 600 returns to second step 604, to listen for another connection request.
FIG. 7 is a flow chart summarizing a method 700 of performing second step 504 (receiving a communication from a client 109) of method 500. In a first step 702, master process 202 determines whether there are any client processes 204 to be processed to receive data. If master process 202 has already processed all of client processes 204(1-n), then method 700 ends. If not, then in a second step 704, master process 202 calls the first client process 204(1). Then, in a third step 706, client process 204(1) checks its client connection (e.g., the TCP buffer) to determine whether there is any data coming in from client 109(1). If there is no incoming data for the first client process 204(1), then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If, in third step 706, client process 204(1) determines that there is incoming data from client 109(1), then in a fourth step 708, client process 204(1) checks client data structure 402(1) to determine if input queue 412(1) is available to receive client data. If input queue 412(1) is not available, then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If in fourth step 708, client process 204(1) determines that input queue 412(l) is available to receive data, then in a fifth step 710, client process 204(1) transfers the incoming client data into input queue 412(1). Then, in a sixth step 712, client process 204(1) determines whether the data accumulated in input queue constitutes a complete request (i.e., data ready to be transferred to server 106, for example a complete HTTP request). If the data does not constitute a complete request, then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If, however, client process 204(1) determines in sixth step 712 that the data in input queue 412(1) constitutes a complete request, then, in a seventh step 714, client process notifies proxy applications 208 that there is a complete request by, for example, setting connection state 410( l) to so indicate. Then, method 700 returns to first step 702 to determine whether there are any more client processes 204(2-n) to process.
FIG. 8 is a flow chart summarizing a method 800 of performing third step 506 (establishing a bus connection with server 106) of method 500. In a first step 802, a first one of application proxies 208(1) retrieves the first client descriptor from client queue 418(1) of its proxy data structure 404(l). Then in a second step 804, proxy 208(1) checks the connection state 412 of the client data structure 402 identified by the first client descriptor to determine if the first client has a complete request in its input queue 412.
If connection state 412 indicates a complete request, then in a third step 806, proxy 208(1) adds the client descriptor to its client ready queue 420(1). Next, in a fourth step 808, proxy 208(1) determines whether the maximum number of connections to server 106 are open.
If the maximum number of server connections are already open, then method 800 ends.
If the maximum number of server connections are not already opened, then in a fifth step 810, proxy 208(1) opens a bus connection with server 106 and writes connection information in server socket 408 of the associated client data structure 402. Next, in a sixth step 812, proxy 208(1) determines whether it has checked the last client descriptor in its client queue 418(1).
If the last descriptor has been checked, then method 800 ends. Otherwise, method 800 returns to first step 802 to retrieve the next descriptor in client queue 418(1). If, in second step 804, proxy 208(1) determines that a complete client request has not been received, then method 800 proceeds directly to sixth step 812. Once all of the descriptors in client queue 418(1) of proxy data structure 404(l) have been processed, method 800, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 9 is a flow chart summarizing a method 900 of performing fourth step 508 (forwarding a client communication to server 106) of method 500. In a first step 902, proxy 208(1) retrieves the first client descriptor from the client ready queue 420(1) of its proxy data structure 404(1). Then, in a second step 904, proxy 208(l) checks the server socket 408 of the first client's data structure 402 to determine whether a server connection is open. If a server connection is open, then in a third step 906, proxy 208(1) transfers the client data (e.g., HTTP request) from the client input queue 412 to server 106 over the open server connection.
Next, in a fourth step 908, proxy 208(1) moves the client descriptor from the client ready queue 420(1) to the read pending queue 422(1). Then in a fifth step 910, proxy 208 (1) determines whether the last client in the client ready queue 420(1) has been checked. If not, then method 900 returns to first step 902 to check the next client in client ready queue 420(1).
If the last client has been checked, then method 900 ends. If, in second step 904, proxy 208(1) determines that there is no server connection open for a particular client, then method 900 proceeds directly to fifth step 910 to determine whether the last client in the client ready queue 420(1) has been checked. Once all of the descriptors in client ready queue 420(1) of proxy data structure 404( I) have been processed, method 900, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 10 is a flow chart summarizing a method 1000 of performing fifth step 510 (receive a response from server 106) of method 500. In a first step 1002, proxy 208(1) determines whether read pending queue 422(l) is empty, and if so method 1000 ends. If read 2 5 pending queue 422(1) is not empty, then in a second step 1004 proxy 208 (1) retrieves the first client descriptor from the read pending queue. Next, in a third step 1006, proxy 208(1) checks the open server connection identified in server socket 408 of the client data structure 402 identified by the first client descriptor, to determine whether there is any incoming server data (i.e., a response to the client request) on that connection. If there is no incoming server data on that connection, then method 1000 returns to second step 1004 to check the next client in the read pending queue. If there is incoming server data, then in a fourth step 1008, proxy 208(1) checks to determine whether output queue 414 of the client data structure 402 identified by the client descriptor is available. If output queue 414 is not available, then method 1000 returns to second step 1004 to check the next client descriptor in read pending queue 422(1). If output queue 414 is available, then, in a fifth step 1010, proxy 208(1) moves the incoming server data into the output queue 414 of client data structure 402. Next, in a sixth step 1012, proxy 208(1) determines whether the server data includes an "end of file"
indicator. If not, then in a seventh step 1014, proxy 208(1) checks to determine whether the last client descriptor in read pending queue 422(1) has been processed. If so, method 1000 ends. If not, method 1000 returns to step 1004 to read the next client descriptor from read pending queue 422(1).
If, in sixth step 1012, proxy 208(1) determines that the server data includes an end-of-file indicator, then method 1000 proceeds to an eighth step 1016, wherein proxy 208(1) removes the client descriptor from the read pending queue, and then in a ninth step 1018 closes the server connection. After ninth step 1018, method 1000 returns to seventh step 1014. Once all of the descriptors in read pending queue 422(1) of proxy data structure 404(1) have been processed, method 1000, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 11 is a flow chart summarizing a metliod 1100 of performing sixth step (transmitting data to clients 109) of method 500. In a first step 1102, master process 202 calls first client process 204(1). Then, in a second step 1104, first client process 204(1) determines whether there is any data in output queue 414(1) of client data structure 402(1). If there is no data in output queue 414(1), then method 1100 returns to first step 1102 where master process 202 calls the next of the remaining client processes 204(2-n). If, however, in second step 1104, client process 204(1) determines that there is data in output queue 414(1), then in a third step 1106, client process 204(1) determines whether the client network connection is ready to receive data. If the client network connection is not ready, then method 1100 returns to first step 1102. If the client network connection is ready, then in a fourth step 1108, client process 204(1) moves at least a portion of the data in output queue 414(1) to the client connection (e.g., the TCP output buffer). Next, in a fifth step 1110, master process 202 determines whether the last client process has been called. If so, method 1100 ends. If not, method 1100 returns to first step 1102 to call the next of the remaining client processes 203(2-n).
The description of particular embodiments of the present invention is now complete.
Many of the described features may be substituted, altered or omitted without departing from the scope of the invention. For example, the operative components of adapter 108 (e.g., processing unit 126 and proxy 132) can be incorporated directly into a server instead of being provided in a removable adapter card. Further, alternate data structures may be substituted for the exemplary data structures provided. Additionally, the particular orders of methods and routines disclosed herein are not considered to be essential elements of the present invention. As yet another example, master process 202 can be configured to open a predetermined number of persistent bus connections with server 106 at start-up, and manage the use of those connections by application proxies 208(1-f), thus eliminating the need for server 106 to repetitively open and close the bus connections. These and other deviations from the particular embodiments shown will be apparent to those skilled in the art, particularly in view of the foregoing disclosure.
Responsive to a connection request from a client 109 on internetwork 102 (FIG. 1) master process 202 accepts the connection request, initializes a data structure for that client connection in data buffer 206, initiates a new, separate client connection process 204 to handle the connection, and then notifies application proxies 208 that the particular client connection has been established. Each client process 204 handles one such client connection.
Application proxies 208 establish and manage bus connections with server 106. Data buffer 206 provides storage for data received from clients 109 and destined for server 106, for data received from server 106 and destined for clients 109, and for connection data relating to established client and/or server connections. Those skilled in the art will recognize that proxy 132 is reverse proxy application, because proxy 132 is a proxy for server 106 servicing client requests on behaif of the server 106.
Communications protocol stack 134 is a TCP/IP stack including a sockets layer 210; a TCP layer 212, an IP layer 214, and a device layer including a network driver 216 and a 1-5 server bus driver 218. The functionality of each of the individual layers of protocol stack 134 is well known in the art, and will not, therefore, be discussed in detail herein. Connections between the various modules of proxy 132 and server applications 121 are established through sockets layer 210, TCP layer 212, IP layer 214 and server bus driver 218.
Connections between the various modules ot'proxy T32 are established with clients 109 ?0 through sockets layer 210, TCP layer 212, IP layer 214 and network driver 216.
FIG. 3 is a block diagram showing application proxies module 208 to include a plurality of application specific proxies 208( l-f), including a hypertext transfer protocol .
(HTTP) proxy 208(1), a pass-through proxy 208(2), a security proxy 208(3), and an "other"
proxy 208(f). Master process 202 notifies application proxies 208 of an established client 25 connection, bv configuring one or more of the application specific proxies 208(1-f) to service the client connection. One means of configuring an application specific proxy (e.g., HTTP
proxy 208(1)) is to enter a client process identifier in the processing queue of the application specific proxy.
Master process 202 determines which of the application specific proxies to implement '10 for a particular client process from the port number inclucled in the client connection request.
It is standard practice to use well known port numbers to identify particular network applications and/or protocols (e.g., file transfer protocol (FTP), HTTP, etc.). For example, port number 80 corresponds to an HTTP connection request. Master process 202 therefore notifies HTTP proxy 208(1) of all client process' 204 initiated in response to a connection request indicating port 80.
HTTP proxy 208(1) monitors each of the client processes of which it is notified.
When HTTP proxy 208(1) determines that a complete HTTP request is received and stored in data buffer 206 by a client process (e.g., 204(n)), HTTP proxy 208(1) opens a connection to the server, transmits the request to the server, receives a response from the server, stores the response in data buffer 206 and then closes the server connection. The server response is then transmitted to client 109(n) by the associated client process 204(n).
When master process 202 receives a connection request with a port number that does not correspond to any of the other application specific proxies, master process 202 notifies pass-through proxy 208(2). Pass-through proxy 208(2) simply opens a server connection, transfers the data received from the associated client process 204 from data buffer 206 to server 106, and then closes the server connection.
Master process 202 may notify some application specific proxies of all client connections, regardless of the associated port number. For example, security proxy 208(3) is operative to screen all client connection requests by, for example, terminating any client process initiated in response to a connection request lacking some indicia of authorization, prior to implementing one of the other application specific proxies.
"Other" proxy 208(f) is included in FIG. 3 to show that application proxies 208 can include any currently known or future developed proxy that is desirable for a particular application, including but not limited to, caching HTTP proxy applications, electronic mail applications, and file transfer applications.
FIG. 4 shows an example of client data structures 402( l-n) and proxy data structures 404(1-f), implemented in data buffer 206 to effect the transfer of data through proxy 132.
Master process 202 creates and initializes one client data structure 402 for each client process 204, and one proxy data structure 404 for each application specific proxy in application proxies 208.
Each client data structure 402 includes a client socket 406, a server socket 408, a connection state 410, an input queue 412, an output queue 414, and application proxy data 416. For each client connection (e.g., connection (n)), client socket 406(n) and server socket 408(n) each include the IP address and port number of the client 109(n) and server 106, respectively, thus uniquely associating each client data structure 402(n) with a single one of client processes 204(n). Connection state 410(n) indicates the current status (e.g., complete request received, response received, etc.) of the connection (n). Input queue 412(n) is used to store and accumulate data received from client 109(n) by the client process 204(n) associated with the particular data structure 402(n). Output queue 414(n) is used to store data from application proxies 208 which is to be forwarded to client 109(n) by client process 204(n).
Application proxy data 416(n) is provided to store any information specific to a particular application proxy (e.g., flags, etc.).
Each proxy data structure(e.g., 404(f)) includes a client queue 418(f), a client ready queue 420(f), and a read pending queue 422(f). Client queue 418(f) includes a client process descriptor (e.g., a pointer to a related client data structure 402) for each client process 204 associated with the particular application proxy (f) to which the proxy data structure 404(f) corresponds. Client ready queue 420(f) includes a client process descriptor for each client data structure 402 that has data in its input queue 412 that is ready to be processed (e.g., transferred to server 106) by the associated application proxy (f). Read pending queue 422(f) includes the client process descriptor for each client process that is awaiting a response from server 106.
Those skilled in the art will understand that the above described client data structure 402 and proxy data structure 404 are exemplary in nature, and that other data structures may be employed with the present invention. The configuration of such alternate data structures will necessarily depend on the function and structure of the particular application specific proxies that are employed.
FIG. 5 is a flowchart summarizing a particular method 500 of managing connections between clients and a server according to the present invention. In a first step 502 proxy 132 establishes a network connection with a client 109, and then in a second step 504 receives a communication (e.g., an HTTP request) from client 109 via the network connection. Next, in a third step 506, proxy 132 establishes a bus connection with server 106, and then in a fourth step 508 forwards the received client communication to server 106 via the bus connection.
Then, in a fifth step 510, proxy 132 receives a response (e.g., HTML data) to the client communication from server 106, and in sixth step 512 transmits the response to client 109 via the client network connection. Finally, in a seventh step 514, proxy 132 determines whether there is a signal to terminate (e.g., shut down), and if there is a signal to terminate, then method 500 ends. If there is no signal to terminate in seventh step 514, then method 500 returns to first step 502, to establish a network connection with another client 109.
FIG. 6 is a flow chart summarizing one particular method 600 of performing first step 502 (establishing a network connection with a client) of method 500. In a first step, master process 202 connects to internetwork 102. Then in a second step 604 master process 202 listens to the traffic on internetwork 102 to determine if there is a connection request from a client 109. If there is no client connection request, then method 600 ends. If there is a connection request from a client 109(n), then in a third step 606, master process 202 accepts the connection request form client 109(n), initiates a client process 204(n) to handle the connection, and initializes a client data structure 402(n) in data buffer 206.
Next, in a fourth step 608, master process 202 discerns a proxy application identifier (e.g., a port number) from the client connection request and notifies one or more of application proxies 208(1-f), depending on the value of the identifier, by writing the client process descriptor (e.g., pointer to client data structure 402(n)) into the client queues 418 of the respective proxy data structures 404. Finally, in a fifth step 610, master process 202 determines whether the maximum allowed number of client connections are open. If the maximum number of client connections are open, then method 600 ends. If the maximum number of client connections are not open, then method 600 returns to second step 604, to listen for another connection request.
FIG. 7 is a flow chart summarizing a method 700 of performing second step 504 (receiving a communication from a client 109) of method 500. In a first step 702, master process 202 determines whether there are any client processes 204 to be processed to receive data. If master process 202 has already processed all of client processes 204(1-n), then method 700 ends. If not, then in a second step 704, master process 202 calls the first client process 204(1). Then, in a third step 706, client process 204(1) checks its client connection (e.g., the TCP buffer) to determine whether there is any data coming in from client 109(1). If there is no incoming data for the first client process 204(1), then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If, in third step 706, client process 204(1) determines that there is incoming data from client 109(1), then in a fourth step 708, client process 204(1) checks client data structure 402(1) to determine if input queue 412(1) is available to receive client data. If input queue 412(1) is not available, then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If in fourth step 708, client process 204(1) determines that input queue 412(l) is available to receive data, then in a fifth step 710, client process 204(1) transfers the incoming client data into input queue 412(1). Then, in a sixth step 712, client process 204(1) determines whether the data accumulated in input queue constitutes a complete request (i.e., data ready to be transferred to server 106, for example a complete HTTP request). If the data does not constitute a complete request, then method 700 returns to first step 702 to process any remaining client processes 204(2-n). If, however, client process 204(1) determines in sixth step 712 that the data in input queue 412(1) constitutes a complete request, then, in a seventh step 714, client process notifies proxy applications 208 that there is a complete request by, for example, setting connection state 410( l) to so indicate. Then, method 700 returns to first step 702 to determine whether there are any more client processes 204(2-n) to process.
FIG. 8 is a flow chart summarizing a method 800 of performing third step 506 (establishing a bus connection with server 106) of method 500. In a first step 802, a first one of application proxies 208(1) retrieves the first client descriptor from client queue 418(1) of its proxy data structure 404(l). Then in a second step 804, proxy 208(1) checks the connection state 412 of the client data structure 402 identified by the first client descriptor to determine if the first client has a complete request in its input queue 412.
If connection state 412 indicates a complete request, then in a third step 806, proxy 208(1) adds the client descriptor to its client ready queue 420(1). Next, in a fourth step 808, proxy 208(1) determines whether the maximum number of connections to server 106 are open.
If the maximum number of server connections are already open, then method 800 ends.
If the maximum number of server connections are not already opened, then in a fifth step 810, proxy 208(1) opens a bus connection with server 106 and writes connection information in server socket 408 of the associated client data structure 402. Next, in a sixth step 812, proxy 208(1) determines whether it has checked the last client descriptor in its client queue 418(1).
If the last descriptor has been checked, then method 800 ends. Otherwise, method 800 returns to first step 802 to retrieve the next descriptor in client queue 418(1). If, in second step 804, proxy 208(1) determines that a complete client request has not been received, then method 800 proceeds directly to sixth step 812. Once all of the descriptors in client queue 418(1) of proxy data structure 404(l) have been processed, method 800, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 9 is a flow chart summarizing a method 900 of performing fourth step 508 (forwarding a client communication to server 106) of method 500. In a first step 902, proxy 208(1) retrieves the first client descriptor from the client ready queue 420(1) of its proxy data structure 404(1). Then, in a second step 904, proxy 208(l) checks the server socket 408 of the first client's data structure 402 to determine whether a server connection is open. If a server connection is open, then in a third step 906, proxy 208(1) transfers the client data (e.g., HTTP request) from the client input queue 412 to server 106 over the open server connection.
Next, in a fourth step 908, proxy 208(1) moves the client descriptor from the client ready queue 420(1) to the read pending queue 422(1). Then in a fifth step 910, proxy 208 (1) determines whether the last client in the client ready queue 420(1) has been checked. If not, then method 900 returns to first step 902 to check the next client in client ready queue 420(1).
If the last client has been checked, then method 900 ends. If, in second step 904, proxy 208(1) determines that there is no server connection open for a particular client, then method 900 proceeds directly to fifth step 910 to determine whether the last client in the client ready queue 420(1) has been checked. Once all of the descriptors in client ready queue 420(1) of proxy data structure 404( I) have been processed, method 900, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 10 is a flow chart summarizing a method 1000 of performing fifth step 510 (receive a response from server 106) of method 500. In a first step 1002, proxy 208(1) determines whether read pending queue 422(l) is empty, and if so method 1000 ends. If read 2 5 pending queue 422(1) is not empty, then in a second step 1004 proxy 208 (1) retrieves the first client descriptor from the read pending queue. Next, in a third step 1006, proxy 208(1) checks the open server connection identified in server socket 408 of the client data structure 402 identified by the first client descriptor, to determine whether there is any incoming server data (i.e., a response to the client request) on that connection. If there is no incoming server data on that connection, then method 1000 returns to second step 1004 to check the next client in the read pending queue. If there is incoming server data, then in a fourth step 1008, proxy 208(1) checks to determine whether output queue 414 of the client data structure 402 identified by the client descriptor is available. If output queue 414 is not available, then method 1000 returns to second step 1004 to check the next client descriptor in read pending queue 422(1). If output queue 414 is available, then, in a fifth step 1010, proxy 208(1) moves the incoming server data into the output queue 414 of client data structure 402. Next, in a sixth step 1012, proxy 208(1) determines whether the server data includes an "end of file"
indicator. If not, then in a seventh step 1014, proxy 208(1) checks to determine whether the last client descriptor in read pending queue 422(1) has been processed. If so, method 1000 ends. If not, method 1000 returns to step 1004 to read the next client descriptor from read pending queue 422(1).
If, in sixth step 1012, proxy 208(1) determines that the server data includes an end-of-file indicator, then method 1000 proceeds to an eighth step 1016, wherein proxy 208(1) removes the client descriptor from the read pending queue, and then in a ninth step 1018 closes the server connection. After ninth step 1018, method 1000 returns to seventh step 1014. Once all of the descriptors in read pending queue 422(1) of proxy data structure 404(1) have been processed, method 1000, or a similar method, is repeated for each of the other application proxies 208(2-f).
FIG. 11 is a flow chart summarizing a metliod 1100 of performing sixth step (transmitting data to clients 109) of method 500. In a first step 1102, master process 202 calls first client process 204(1). Then, in a second step 1104, first client process 204(1) determines whether there is any data in output queue 414(1) of client data structure 402(1). If there is no data in output queue 414(1), then method 1100 returns to first step 1102 where master process 202 calls the next of the remaining client processes 204(2-n). If, however, in second step 1104, client process 204(1) determines that there is data in output queue 414(1), then in a third step 1106, client process 204(1) determines whether the client network connection is ready to receive data. If the client network connection is not ready, then method 1100 returns to first step 1102. If the client network connection is ready, then in a fourth step 1108, client process 204(1) moves at least a portion of the data in output queue 414(1) to the client connection (e.g., the TCP output buffer). Next, in a fifth step 1110, master process 202 determines whether the last client process has been called. If so, method 1100 ends. If not, method 1100 returns to first step 1102 to call the next of the remaining client processes 203(2-n).
The description of particular embodiments of the present invention is now complete.
Many of the described features may be substituted, altered or omitted without departing from the scope of the invention. For example, the operative components of adapter 108 (e.g., processing unit 126 and proxy 132) can be incorporated directly into a server instead of being provided in a removable adapter card. Further, alternate data structures may be substituted for the exemplary data structures provided. Additionally, the particular orders of methods and routines disclosed herein are not considered to be essential elements of the present invention. As yet another example, master process 202 can be configured to open a predetermined number of persistent bus connections with server 106 at start-up, and manage the use of those connections by application proxies 208(1-f), thus eliminating the need for server 106 to repetitively open and close the bus connections. These and other deviations from the particular embodiments shown will be apparent to those skilled in the art, particularly in view of the foregoing disclosure.
Claims (75)
1. In an interface device operatively coupled to an internal bus of an origin server, a method for managing connections between at least one client and said origin server, said method comprising the steps of:
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
accumulating one or more separate transmissions from said client in a buffer;
establishing a bus connection with said origin server via an internal bus of said origin server after a complete client request is accumulated in said buffer;
forwarding said client communication to said origin server via said bus connection;
receiving a response to said client communication from said server via said bus connection; and forwarding said response to said client via said network connection.
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
accumulating one or more separate transmissions from said client in a buffer;
establishing a bus connection with said origin server via an internal bus of said origin server after a complete client request is accumulated in said buffer;
forwarding said client communication to said origin server via said bus connection;
receiving a response to said client communication from said server via said bus connection; and forwarding said response to said client via said network connection.
2. A method according to Claim 1, wherein said step of receiving said response from said server includes storing said response in a buffer.
3. A method according to Claim 2, wherein said step of receiving said response from said server includes terminating said bus connection after said response is received.
4. A method according to Claim 1, wherein said client communication includes an HTTP request.
5. A method according to Claim 4, wherein said response from said server includes an HTML page.
6. A method according to Claim 1, wherein said step of establishing a network connection with a client includes establishing a separate network connection with each of a plurality of clients via said network.
7. A method according to Claim 6, wherein said step of establishing said bus connection with said server includes establishing a plurality of connections with said server via said internal bus of said server.
8. A method according to Claim 7, wherein the maximum number of simultaneous client connections exceeds the maximum number of simultaneous server connections.
9. A method according to Claim 1, further comprising performing a security operation on said client communication prior to forwarding said client communication to said server.
10. A method according to Claim 1, wherein:
said step of receiving said client communication includes discerning an application identifier from said client communication; and said step of forwarding said client communication to said server includes invoking one of a plurality of proxy applications based on said application identifier.
said step of receiving said client communication includes discerning an application identifier from said client communication; and said step of forwarding said client communication to said server includes invoking one of a plurality of proxy applications based on said application identifier.
11. A method according to Claim 10, wherein said application identifier is the connection port number.
12. A method according to Claim 1, wherein said step of receiving said client communication includes receiving at least a portion of an HTTP request.
13. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 1.
14. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 2.
15. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 3.
16. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 4.
17. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 5.
18. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 6.
19. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 7.
20. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 8.
21. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 9.
22. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 10.
23. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 11.
24. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 12.
25. An adapter card for operatively coupling to an internal bus of an origin server for managing origin server communication with a network, said adapter card comprising:
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server; and wherein said reverse proxy application is operative to establish a network connection with a client on said network, to receive a communication from said client via said network connection, to store said communication in said memory device by accumulating one or more separate transmissions from said client in said memory device, to establish a bus connection with said origin server after a complete client request is accumulated in said memory device, to receive a response to said client communication from said origin server via said bus connection, and to forward said response to said client via said network connection.
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server; and wherein said reverse proxy application is operative to establish a network connection with a client on said network, to receive a communication from said client via said network connection, to store said communication in said memory device by accumulating one or more separate transmissions from said client in said memory device, to establish a bus connection with said origin server after a complete client request is accumulated in said memory device, to receive a response to said client communication from said origin server via said bus connection, and to forward said response to said client via said network connection.
26. An adapter card according to Claim 25, wherein said code further comprises a communication protocol stack.
27. An adapter according to Claim 26, wherein said communication protocol stack comprises a standard TCP/IP protocol stack.
28. An adapter card according to Claim 25, wherein said proxy application includes a security proxy.
29. An adapter card according to Claim 25, wherein said proxy application includes a pass-through proxy.
30. An adapter card according to Claim 25, wherein said proxy application includes an HTTP proxy.
31. An adapter card according to Claim 25, wherein said proxy application includes a master process module responsive to a connection request received from one of said clients, and operative to establish a connection with said client and to initiate a new client process module to maintain said established connection.
32. An adapter card according to Claim 31, wherein said master process module is further operative to notify said proxy application of said established connection.
33. An adapter card for operatively coupling to an internal bus of an origin server for managing origin server communication with a network, said adapter card comprising:
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application and a master process module;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server; and wherein said master process module is operative to discern an application identifier from a communication received from one of said clients and to invoke one of a plurality of proxy applications based on said application identifier.
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application and a master process module;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server; and wherein said master process module is operative to discern an application identifier from a communication received from one of said clients and to invoke one of a plurality of proxy applications based on said application identifier.
34. An adapter card according to Claim 33, wherein said application identifier is the connection port number.
35. In an interface device operatively coupled to an internal bus of an origin server, a method for managing connections between at least one client and said origin server, said method comprising the steps of:
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
establishing a bus connection with said origin server via an internal bus of said origin server; and forwarding said client communication to said origin server via said bus connection; and wherein said step of receiving said client communication includes discerning an application identifier from said client communication; and said step of forwarding said client communication to said server includes invoking one of a plurality of proxy applications based on said application identifier.
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
establishing a bus connection with said origin server via an internal bus of said origin server; and forwarding said client communication to said origin server via said bus connection; and wherein said step of receiving said client communication includes discerning an application identifier from said client communication; and said step of forwarding said client communication to said server includes invoking one of a plurality of proxy applications based on said application identifier.
36. A method according to Claim 35, wherein said application identifier is the connection port number.
37. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 35.
38. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 36.
39. In an interface device operatively coupled to an internal bus of an origin server, a method for managing connections between at least one client and said origin server, said method comprising the steps of:
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
establishing a bus connection with said origin server via an internal bus of said origin server;
forwarding said client communication to said origin server via said bus connection;
receiving a response to said client communication from said origin server via said bus connection; and forwarding said response to said client via said network connection.
establishing a network connection with one of said clients via a network;
receiving a communication from said client via said network connection;
establishing a bus connection with said origin server via an internal bus of said origin server;
forwarding said client communication to said origin server via said bus connection;
receiving a response to said client communication from said origin server via said bus connection; and forwarding said response to said client via said network connection.
40. A method according to Claim 39, wherein said step of receiving a communication from said client includes storing said communication in a buffer.
41. A method according to Claim 40, wherein said step of storing said communication in a buffer includes accumulating one or more separate transmissions from said client in said buffer.
42. A method according to Claim 41, wherein said step of establishing a bus connection with said origin server includes waiting until a complete client request is accumulated in said buffer before establishing said bus connection with said origin server.
43. A method according to Claim 39, wherein said step of receiving said response from said server includes storing said response in a buffer.
44. A method according to Claim 43, wherein said step of receiving said response from said server includes terminating said bus connection after said response is received.
45. A method according to Claim 39, wherein said client communication includes an HTTP request.
46. A method according to Claim 45, wherein said response from said server includes an HTML page.
47. A method according to Claim 39, wherein said step of establishing a network connection with a client includes establishing a separate network connection with each of a plurality of clients via said network.
48. A method according to Claim 47, wherein said step of establishing said bus connection with said origin server includes establishing a plurality of connections with said origin server via said internal bus of said origin server.
49. A method according to Claim 48, wherein the maximum number of simultaneous client connections exceeds the maximum number of simultaneous server connections.
50. A method according to Claim 39, further comprising performing a security operation on said client communication prior to forwarding said client communication to said origin server.
51. A method according to Claim 39, wherein said step of receiving said client communication includes receiving at least a portion of an HTTP request.
52. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 39.
53. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 40.
54. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 41.
55. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 42.
56. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 43.
57. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 44.
58. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 45.
59. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 46.
60. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 47.
61. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 48.
62. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 49.
63. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 50.
64. A computer readable medium having code embodied therein for causing an electronic device to perform the steps of Claim 51.
65. An adapter card for operatively coupling to an internal bus of an origin server for managing origin server communication with a network, said adapter card comprising:
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server, and wherein said reverse proxy application is operative to establish a network connection with a client on said network, to receive a communication from said client via said network connection, to establish a bus connection with said origin server, to receive a response to said client communication from said origin server via said bus connection, and to forward said response to said client via said network connection.
a network controller for communicating with clients on said network;
a memory device for storing data and code, said code including a reverse proxy application;
a processing unit coupled to said memory device for executing said code; and a protocol adapter coupled to said processing unit, and adapted to couple to said internal bus of said origin server, for communicating with said origin server, and wherein said reverse proxy application is operative to establish a network connection with a client on said network, to receive a communication from said client via said network connection, to establish a bus connection with said origin server, to receive a response to said client communication from said origin server via said bus connection, and to forward said response to said client via said network connection.
66. An adapter card according to Claim 65, wherein said code further comprises a communication protocol stack.
67. An adapter according to Claim 66, wherein said communication protocol stack comprises a TCP/IP protocol stack.
68. An adapter card according to Claim 65, wherein said proxy application includes a security proxy.
69. An adapter card according to Claim 65, wherein said proxy application includes a pass-through proxy.
70. An adapter card according to Claim 65, wherein said proxy application includes an HTTP proxy.
71. An adapter card according to Claim 65, further comprising a data buffer for storing data received from said clients.
72. An adapter card according to Claim 65, wherein said proxy application includes a master process module responsive to a connection request received from one of said clients, and operative to establish a connection with said client and to initiate a new client process module to maintain said established connection.
73. An adapter card according to Claim 72, wherein said master process module is further operative to notify said proxy application of said established connection.
74. An origin server comprising:
a memory device for storing a server application;
a processing unit for running said server application;
data storage for a resource to be provided to clients on an internetwork by said server application;
a bus for operatively coupling said processing unit and said memory device;
and an adapter card coupled to said bus, said adapter card including a network adapter for connecting to said internetwork, a memory device having a reverse proxy application stored therein, and a processing unit for running said reverse proxy application; and wherein said reverse proxy application is operative to establish a network connection with at least one of said clients on said internetwork, to receive a communication from said at least one of said clients via said internetwork connection, to establish a bus connection with said bus, to receive a response to said communication from said origin server via said bus connection, and to forward said response to said client via said internetwork connection.
a memory device for storing a server application;
a processing unit for running said server application;
data storage for a resource to be provided to clients on an internetwork by said server application;
a bus for operatively coupling said processing unit and said memory device;
and an adapter card coupled to said bus, said adapter card including a network adapter for connecting to said internetwork, a memory device having a reverse proxy application stored therein, and a processing unit for running said reverse proxy application; and wherein said reverse proxy application is operative to establish a network connection with at least one of said clients on said internetwork, to receive a communication from said at least one of said clients via said internetwork connection, to establish a bus connection with said bus, to receive a response to said communication from said origin server via said bus connection, and to forward said response to said client via said internetwork connection.
75. An origin server according to Claim 74, further comprising a plurality of said adapter cards coupled to said bus.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/405,608 US6877036B1 (en) | 1999-09-24 | 1999-09-24 | System and method for managing connections between a client and a server |
US09/405,608 | 1999-09-24 | ||
PCT/US2000/026097 WO2001022195A2 (en) | 1999-09-24 | 2000-09-22 | System and method for managing connections between a client and a server |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2385899A1 CA2385899A1 (en) | 2001-03-29 |
CA2385899C true CA2385899C (en) | 2010-02-16 |
Family
ID=23604408
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA 2385899 Expired - Fee Related CA2385899C (en) | 1999-09-24 | 2000-09-22 | System and method for managing connections between a client and a server |
Country Status (8)
Country | Link |
---|---|
US (3) | US6877036B1 (en) |
EP (1) | EP1226482A4 (en) |
JP (2) | JP4896328B2 (en) |
CN (1) | CN1288575C (en) |
AU (1) | AU4019601A (en) |
CA (1) | CA2385899C (en) |
TW (1) | TW475114B (en) |
WO (1) | WO2001022195A2 (en) |
Families Citing this family (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6920637B2 (en) * | 1995-11-17 | 2005-07-19 | Symbol Technologies, Inc. | Method and apparatus for implementing alerts on a browser running on a portable handheld device |
JP3974276B2 (en) * | 1998-11-30 | 2007-09-12 | ペンタックス株式会社 | Method for producing ceramic composite and ceramic composite |
US6877036B1 (en) * | 1999-09-24 | 2005-04-05 | Akamba Corporation | System and method for managing connections between a client and a server |
US7272649B1 (en) * | 1999-09-30 | 2007-09-18 | Cisco Technology, Inc. | Automatic hardware failure detection and recovery for distributed max sessions server |
US6854018B1 (en) * | 2000-03-20 | 2005-02-08 | Nec Corporation | System and method for intelligent web content fetch and delivery of any whole and partial undelivered objects in ascending order of object size |
US7392282B2 (en) * | 2001-03-14 | 2008-06-24 | International Business Machines Corporation | Method for ensuring client access to messages from a server |
US20020156841A1 (en) * | 2001-04-13 | 2002-10-24 | Bjorn Landfeldt | Accessing distributed proxy configurations |
US7200679B2 (en) | 2001-04-13 | 2007-04-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Creating distributed proxy configurations |
US8090866B1 (en) * | 2002-01-18 | 2012-01-03 | Cisco Technology, Inc. | TCP proxy connection management in a gigabit environment |
US20040105445A1 (en) * | 2002-06-19 | 2004-06-03 | Jeremy Wyn-Harris | Internet protocol for resource-constrained devices |
US7426535B2 (en) * | 2002-10-08 | 2008-09-16 | Telecommunication Systems, Inc. | Coordination of data received from one or more sources over one or more channels into a single context |
JP2004145392A (en) * | 2002-10-21 | 2004-05-20 | Kddi Corp | Moving image file distributing device |
CN100452014C (en) * | 2003-06-02 | 2009-01-14 | 美国在线服务公司 | Page views for proxy servers |
CN1302364C (en) * | 2004-02-11 | 2007-02-28 | 财团法人资讯工业策进会 | Application interface bridge method, system and storage media |
US20050228509A1 (en) * | 2004-04-07 | 2005-10-13 | Robert James | System, device, and method for adaptively providing a fieldbus link |
GB0425966D0 (en) * | 2004-11-25 | 2004-12-29 | Vodafone Plc | Server functionality within a client |
US9055088B2 (en) * | 2005-03-15 | 2015-06-09 | International Business Machines Corporation | Managing a communication session with improved session establishment |
WO2006126221A1 (en) * | 2005-05-27 | 2006-11-30 | Telecom Italia S.P.A. | System and method for performing mobile services, in particular push and pull services, in a wireless communication network |
EP1833206B1 (en) * | 2006-03-10 | 2013-12-04 | Mitel Networks Corporation | Method for distributing connection attempts to a server |
US7649902B2 (en) * | 2006-11-22 | 2010-01-19 | Sun Microsystems, Inc. | Method and apparatus for performing syntax-directed application layer data buffering |
US20080309665A1 (en) * | 2007-06-13 | 2008-12-18 | 3D Systems, Inc., A California Corporation | Distributed rapid prototyping |
CN101383879B (en) * | 2007-09-07 | 2011-05-18 | 米特尔网络公司 | Method for allocating connection attempt to server |
US20090097470A1 (en) * | 2007-10-12 | 2009-04-16 | Collier David S | Methods and systems for communicating data |
CN101996288A (en) * | 2009-08-18 | 2011-03-30 | 精品科技股份有限公司 | Information security management system |
CN102118390B (en) * | 2011-01-07 | 2015-07-22 | 杭州华三通信技术有限公司 | Method for linkage of application systems of multi-network card equipment and equipment thereof |
US8327005B2 (en) | 2011-02-24 | 2012-12-04 | Jibe Mobile | Method to set up application to application communication over a network between applications running on endpoint devices |
CN102439946B (en) * | 2011-06-23 | 2014-05-21 | 华为技术有限公司 | Data transmission method and device |
US9154580B2 (en) * | 2012-02-01 | 2015-10-06 | Tata Consultancy Services Limited | Connection management in a computer networking environment |
CN103516851B (en) * | 2012-06-30 | 2016-05-25 | 北京新媒传信科技有限公司 | A kind of wireless product cloud test platform system |
KR102090493B1 (en) * | 2013-01-22 | 2020-03-18 | 삼성전자주식회사 | Device and method of HTTP Proxy to reduce the HTTP protocol transmission delay and the HTTP processing load in Mobile Communication Networks |
US11222001B2 (en) * | 2013-03-15 | 2022-01-11 | Sap Se | Augmenting middleware communication services |
US9559896B2 (en) * | 2013-07-08 | 2017-01-31 | Cisco Technology, Inc. | Network-assisted configuration and programming of gateways in a network environment |
US10230770B2 (en) * | 2013-12-02 | 2019-03-12 | A10 Networks, Inc. | Network proxy layer for policy-based application proxies |
CN105915658B (en) * | 2016-07-04 | 2019-07-23 | 优刻得科技股份有限公司 | Obtain data calling method, the data transmission method of client ip address |
Family Cites Families (70)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH01226059A (en) * | 1988-03-04 | 1989-09-08 | Matsushita Graphic Commun Syst Inc | Communication adaptor |
JPH0476752A (en) | 1990-07-19 | 1992-03-11 | Nec Corp | Buffer control system |
JPH04326227A (en) | 1991-04-25 | 1992-11-16 | Nippon Telegr & Teleph Corp <Ntt> | High-speed line controller |
US5426639A (en) | 1991-11-29 | 1995-06-20 | At&T Corp. | Multiple virtual FIFO arrangement |
JPH05225094A (en) | 1992-02-10 | 1993-09-03 | Nec Corp | Buffer pool control system for communication control system |
FR2699706B1 (en) | 1992-12-22 | 1995-02-24 | Bull Sa | Data transmission system between a computer bus and a network. |
JP2963298B2 (en) * | 1993-03-26 | 1999-10-18 | 富士通株式会社 | Recovery method of exclusive control instruction in duplicated shared memory and computer system |
JPH0787100A (en) | 1993-09-17 | 1995-03-31 | Hitachi Ltd | Communication adaptor |
US5550981A (en) | 1994-06-21 | 1996-08-27 | At&T Global Information Solutions Company | Dynamic binding of network identities to locally-meaningful identities in computer networks |
US5678007A (en) | 1994-11-22 | 1997-10-14 | Microsoft Corporation | Method and apparatus for supporting multiple outstanding network requests on a single connection |
US5896508A (en) | 1995-02-23 | 1999-04-20 | Advanced Micro Devices, Inc. | Hub-network adapter device for a file server personal computer |
JPH08314779A (en) | 1995-05-16 | 1996-11-29 | Hitachi Ltd | Server system |
US5898830A (en) | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
US5878213A (en) * | 1996-02-15 | 1999-03-02 | International Business Machines Corporation | Methods, systems and computer program products for the synchronization of time coherent caching system |
US5754774A (en) | 1996-02-15 | 1998-05-19 | International Business Machine Corp. | Client/server communication system |
US5832512A (en) | 1996-04-15 | 1998-11-03 | Sun Microsystems, Inc. | Apparatus and method for file number re-mapping for disconnected operations in a client-server network |
US5918013A (en) | 1996-06-03 | 1999-06-29 | Webtv Networks, Inc. | Method of transcoding documents in a network environment using a proxy server |
US5867650A (en) | 1996-07-10 | 1999-02-02 | Microsoft Corporation | Out-of-band data transmission |
US6091737A (en) * | 1996-11-15 | 2000-07-18 | Multi-Tech Systems, Inc. | Remote communications server system |
JP3217002B2 (en) | 1996-11-19 | 2001-10-09 | 株式会社日立製作所 | Digital studio apparatus and control method thereof |
US5852717A (en) | 1996-11-20 | 1998-12-22 | Shiva Corporation | Performance optimizations for computer networks utilizing HTTP |
US6185625B1 (en) | 1996-12-20 | 2001-02-06 | Intel Corporation | Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object |
US6182141B1 (en) * | 1996-12-20 | 2001-01-30 | Intel Corporation | Transparent proxy server |
US5974496A (en) | 1997-01-02 | 1999-10-26 | Ncr Corporation | System for transferring diverse data objects between a mass storage device and a network via an internal bus on a network card |
US6122514A (en) | 1997-01-03 | 2000-09-19 | Cellport Systems, Inc. | Communications channel selection |
US5941988A (en) | 1997-01-27 | 1999-08-24 | International Business Machines Corporation | Session and transport layer proxies via TCP glue |
US6138162A (en) | 1997-02-11 | 2000-10-24 | Pointcast, Inc. | Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request |
US5935249A (en) * | 1997-02-26 | 1999-08-10 | Sun Microsystems, Inc. | Mechanism for embedding network based control systems in a local network interface device |
US6119161A (en) | 1997-02-28 | 2000-09-12 | International Business Machines Corporation | Managing connection requests in a dialup computer network |
US6237031B1 (en) | 1997-03-25 | 2001-05-22 | Intel Corporation | System for dynamically controlling a network proxy |
US6104716A (en) | 1997-03-28 | 2000-08-15 | International Business Machines Corporation | Method and apparatus for lightweight secure communication tunneling over the internet |
US5924116A (en) | 1997-04-02 | 1999-07-13 | International Business Machines Corporation | Collaborative caching of a requested object by a lower level node as a function of the caching status of the object at a higher level node |
JP3173418B2 (en) | 1997-04-18 | 2001-06-04 | 日本電気株式会社 | Stream playback control method and machine-readable recording medium recording program |
JP3688464B2 (en) * | 1997-05-06 | 2005-08-31 | 株式会社東芝 | Terminal device, server device, communication device, and control method |
US5872919A (en) | 1997-05-07 | 1999-02-16 | Advanced Micro Devices, Inc. | Computer communication network having a packet processor with an execution unit which is variably configured from a programmable state machine and logic |
US6072483A (en) | 1997-06-02 | 2000-06-06 | Sony Corporation | Active frame scroll interface |
JP2998701B2 (en) | 1997-06-27 | 2000-01-11 | 日本電気株式会社 | Server access method in data communication |
US6098108A (en) * | 1997-07-02 | 2000-08-01 | Sitara Networks, Inc. | Distributed directory for enhanced network communication |
US6006268A (en) * | 1997-07-31 | 1999-12-21 | Cisco Technology, Inc. | Method and apparatus for reducing overhead on a proxied connection |
JPH1165969A (en) * | 1997-08-19 | 1999-03-09 | Toshiba Corp | Server equipment, communication connecting method and recording medium recording program for connecting communication |
US6222533B1 (en) | 1997-08-25 | 2001-04-24 | I2 Technologies, Inc. | System and process having a universal adapter framework and providing a global user interface and global messaging bus |
US6035324A (en) | 1997-08-28 | 2000-03-07 | International Business Machines Corporation | Client-side asynchronous form management |
US6226642B1 (en) * | 1997-09-11 | 2001-05-01 | International Business Machines Corporation | Content modification of internet web pages for a television class display |
US6247050B1 (en) | 1997-09-12 | 2001-06-12 | Intel Corporation | System for collecting and displaying performance improvement information for a computer |
US6631402B1 (en) * | 1997-09-26 | 2003-10-07 | Worldcom, Inc. | Integrated proxy interface for web based report requester tool set |
US6088803A (en) | 1997-12-30 | 2000-07-11 | Intel Corporation | System for virus-checking network data during download to a client device |
US6101328A (en) | 1997-12-31 | 2000-08-08 | Intel Corporation | System for preventing multiple instances of the same dynamic executable module |
US6822955B1 (en) | 1998-01-22 | 2004-11-23 | Nortel Networks Limited | Proxy server for TCP/IP network address portability |
US6185598B1 (en) * | 1998-02-10 | 2001-02-06 | Digital Island, Inc. | Optimized network resource location |
US6094699A (en) * | 1998-02-13 | 2000-07-25 | Mylex Corporation | Apparatus and method for coupling devices to a PCI-to-PCI bridge in an intelligent I/O controller |
US6115755A (en) * | 1998-04-09 | 2000-09-05 | Novaweb Technologies, Inc. | Integrated apparatus for interfacing several computers to the internet through a single connection |
JPH11306053A (en) | 1998-04-24 | 1999-11-05 | Hitachi Ltd | Data transfer method and information processor for executing the method |
US6745243B2 (en) * | 1998-06-30 | 2004-06-01 | Nortel Networks Limited | Method and apparatus for network caching and load balancing |
US6088796A (en) * | 1998-08-06 | 2000-07-11 | Cianfrocca; Francis | Secure middleware and server control system for querying through a network firewall |
PT1030244E (en) * | 1998-09-16 | 2014-10-16 | Mitsui Bussan | A multimedia direct communication system linked with http protocol |
US6330605B1 (en) * | 1998-11-19 | 2001-12-11 | Volera, Inc. | Proxy cache cluster |
US6389462B1 (en) * | 1998-12-16 | 2002-05-14 | Lucent Technologies Inc. | Method and apparatus for transparently directing requests for web objects to proxy caches |
US6718390B1 (en) * | 1999-01-05 | 2004-04-06 | Cisco Technology, Inc. | Selectively forced redirection of network traffic |
US6529937B1 (en) * | 1999-01-29 | 2003-03-04 | International Business Machines Corporation | System and method for communicating client IP addresses to server applications |
US6081900A (en) * | 1999-03-16 | 2000-06-27 | Novell, Inc. | Secure intranet access |
US6553422B1 (en) * | 1999-04-26 | 2003-04-22 | Hewlett-Packard Development Co., L.P. | Reverse HTTP connections for device management outside a firewall |
US6226752B1 (en) * | 1999-05-11 | 2001-05-01 | Sun Microsystems, Inc. | Method and apparatus for authenticating users |
US7275086B1 (en) * | 1999-07-01 | 2007-09-25 | Intellisync Corporation | System and method for embedding a context-sensitive web portal in a computer application |
US6567857B1 (en) * | 1999-07-29 | 2003-05-20 | Sun Microsystems, Inc. | Method and apparatus for dynamic proxy insertion in network traffic flow |
US6401125B1 (en) * | 1999-08-05 | 2002-06-04 | Nextpage, Inc. | System and method for maintaining state information between a web proxy server and its clients |
JP3478200B2 (en) * | 1999-09-17 | 2003-12-15 | 日本電気株式会社 | Two-way communication system between server and client |
US6877036B1 (en) * | 1999-09-24 | 2005-04-05 | Akamba Corporation | System and method for managing connections between a client and a server |
US6308238B1 (en) | 1999-09-24 | 2001-10-23 | Akamba Corporation | System and method for managing connections between clients and a server with independent connection and data buffers |
US6801927B1 (en) * | 1999-09-24 | 2004-10-05 | Akamba Corporation | Network adaptor card with reverse proxy and cache and method implemented therewith |
AU2002227168A1 (en) | 2000-10-23 | 2002-05-06 | Akamba Corporation | System and method for managing connections between clients and a server using cache memory to store server responses |
-
1999
- 1999-09-24 US US09/405,608 patent/US6877036B1/en not_active Expired - Lifetime
-
2000
- 2000-09-22 JP JP2001525498A patent/JP4896328B2/en not_active Expired - Fee Related
- 2000-09-22 CA CA 2385899 patent/CA2385899C/en not_active Expired - Fee Related
- 2000-09-22 AU AU40196/01A patent/AU4019601A/en not_active Abandoned
- 2000-09-22 EP EP00963734A patent/EP1226482A4/en not_active Withdrawn
- 2000-09-22 CN CNB00814155XA patent/CN1288575C/en not_active Expired - Fee Related
- 2000-09-22 WO PCT/US2000/026097 patent/WO2001022195A2/en active Application Filing
- 2000-10-05 TW TW89119604A patent/TW475114B/en not_active IP Right Cessation
-
2005
- 2005-03-22 US US11/085,999 patent/US9009326B2/en not_active Expired - Fee Related
-
2011
- 2011-10-24 JP JP2011233379A patent/JP5364773B2/en not_active Expired - Fee Related
-
2015
- 2015-04-13 US US14/685,270 patent/US9729664B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN1408089A (en) | 2003-04-02 |
JP5364773B2 (en) | 2013-12-11 |
CA2385899A1 (en) | 2001-03-29 |
WO2001022195A2 (en) | 2001-03-29 |
TW475114B (en) | 2002-02-01 |
US20050198311A1 (en) | 2005-09-08 |
EP1226482A2 (en) | 2002-07-31 |
JP4896328B2 (en) | 2012-03-14 |
JP2012018699A (en) | 2012-01-26 |
WO2001022195A3 (en) | 2001-08-23 |
US9009326B2 (en) | 2015-04-14 |
US20150215419A1 (en) | 2015-07-30 |
US6877036B1 (en) | 2005-04-05 |
AU4019601A (en) | 2001-04-24 |
US9729664B2 (en) | 2017-08-08 |
JP2003523552A (en) | 2003-08-05 |
EP1226482A4 (en) | 2009-09-02 |
CN1288575C (en) | 2006-12-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2385899C (en) | System and method for managing connections between a client and a server | |
US6308238B1 (en) | System and method for managing connections between clients and a server with independent connection and data buffers | |
US6801927B1 (en) | Network adaptor card with reverse proxy and cache and method implemented therewith | |
US8458280B2 (en) | Apparatus and method for packet transmission over a high speed network supporting remote direct memory access operations | |
US7461160B2 (en) | Obtaining a destination address so that a network interface device can write network data without headers directly into host memory | |
US7502826B2 (en) | Atomic operations | |
US8023520B2 (en) | Signaling packet | |
EP1565826B1 (en) | Network interface and protocol supporting mappings of virtual memory locations at different processing devices | |
US8713180B2 (en) | Zero-copy network and file offload for web and application servers | |
US7171464B1 (en) | Method of tracing data traffic on a network | |
EP1086421A1 (en) | Method and computer program product for offloading processing tasks from software to hardware | |
US7499966B2 (en) | Web server architecture for improved performance | |
EP1759317B1 (en) | Method and system for supporting read operations for iscsi and iscsi chimney | |
US8539112B2 (en) | TCP/IP offload device | |
US6742075B1 (en) | Arrangement for instigating work in a channel adapter based on received address information and stored context information | |
US7580410B2 (en) | Extensible protocol processing system | |
US20030110377A1 (en) | Method of and apparatus for data transmission | |
US6834307B2 (en) | Event-based application layer switching for high-speed protocol processing | |
US7213074B2 (en) | Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet | |
WO2002035366A1 (en) | System and method for managing connections between clients and a server using cache memory to store server responses | |
KR100440663B1 (en) | Network system and operating method for the same including web acceleration technology | |
Pietikainen | Hardware-Assisted Networking Using Scheduled Transfer Protocol On Linux | |
Stoess | Porting LibRIPC to iWARP |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |
Effective date: 20180924 |