HTTP multiplexor/demultiplexor

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation-in-part of U.S. patent application, Ser. No. 09/882,375, entitled “HTTP Multiplexor/Demultiplexor,” filed on Jun. 15, 2001, which in turn claims priority from U.S. Provisional Patent Application, Ser. No. 60/239,552, entitled “HTTP Multiplexor/Demultiplexor,” filed on Oct. 10, 2000. The disclosures of both these applications are incorporated herein by this reference, in their entirety and for all purposes.

TECHNICAL FIELD

[0002] The present invention relates generally to data transmission on computer networks, and more particularly to a networking device including a Hypertext Transfer Protocol (HTTP) Multiplexor/Demultiplexor.

BACKGROUND OF THE INVENTION

[0003] The Internet has experienced explosive growth in recent years. The emergence of the World Wide Web has enabled millions of users around the world to easily download web resources containing text, graphics, video, and sound data while at home, work, or from remote locations via wireless devices. These web resources often are large in size and therefore require a long time to download, causing the user delay and frustration. Delay often causes users to abandon the requested web page and move on to another web page, resulting in lost revenue and exposure for many commercial web sites.

[0004] One cause of delay is accumulation of Hypertext Transfer Protocol (HTTP) requests within a Transfer Control Protocol (TCP) buffer of a server socket. When a user requests a web page, a web browser sends HTTP requests to a server socket via an established TCP connection. When the server does not process requests to a socket quickly enough, HTTP requests build up in the TCP buffer for that socket, resulting in processing delay in that socket.

[0005] An additional cause of delay is socket-related overhead processing. Conventional networking systems open up a server socket for each client that connects to the server, so that server overhead tends to increase in proportion to the number of connected clients. A given server can efficiently handle only so much overhead at once. Accordingly, the one-socket-per-client approach fundamentally limits the number clients that can simultaneously access a server. This limitation is worse still in secure environments, which, due to key exchanges and other security-related considerations, involve even more overhead per socket.

SUMMARY OF THE INVENTION

[0006] A system, method and device for multiplexing and demultiplexing HTTP requests and responses are provided. The method may include receiving HTTP requests from a plurality of clients and routing those requests to a single socket on a server system. The HTTP requests may be routed to a particular server socket based on socket response time, the type or size of data being requested, and/or on other parameters related to the HTTP requests. The method may also include receiving HTTP responses from the server system, and selectively routing those responses to corresponding clients.

[0007] According to another aspect of the invention, the method typically includes at an intermediate networking device, receiving HTTP requests from multiple originating clients, multiplexing the HTTP requests, and sending the multiplexed HTTP requests to an optimal server socket. The method may further include receiving the HTTP responses from the server system, demultiplexing the HTTP responses, and sending the demultiplexed HTTP responses to corresponding originating clients.

[0008] The system typically includes a server system, plural clients configured to connect to the server system via a computer network, and a computer networking device positioned intermediate the server system and the clients on the computer network. The computer networking device typically has an HTTP multiplexor/demultiplexor configured to receive HTTP requests from more than one of the clients and to distribute those requests as a multiplexed transmission to a socket on the server system via a TCP connection.

[0009] The device typically includes an HTTP multiplexor/demultiplexor configured to receive HTTP requests from a plurality of clients and to distribute those requests in multiplexed form to a server system via a TCP connection. The device typically is further configured to receive HTTP responses from the server system, demultiplex the responses, and route the demultiplexed responses to corresponding clients.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 is a schematic view of a prior art network configuration.

[0011]FIG. 2 is a schematic view of a networking device and system according to the present invention, including an HTTP multiplexor/demultiplexor.

[0012]FIG. 3 is a schematic view of the networking device and system of FIG. 2, showing routing, multiplexing and demultiplexing features that the device and system may be configured to perform.

[0013]FIG. 4 is a schematic view of a client computing device that may be used with the device and system of FIG. 2.

[0014]FIG. 5 is a schematic view of one embodiment of the networking device of FIG. 2.

[0015]FIG. 6 is a schematic view of another embodiment of the networking device of FIG. 2.

[0016]FIG. 7 is a flowchart of a method of demultiplexing and multiplexing HTTP requests and responses according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0017] Referring initially to FIG. 1, a prior art networking system is shown generally at <b>10</b>. System <b>10</b> includes a plurality of remote clients <b>12</b> and a server <b>14</b>. In system <b>10</b>, a single Transport Control Protocol (TCP) connection <b>16</b> is established between each remote client <b>12</b> and server <b>14</b>. Each TCP connection <b>16</b> is established between a single socket <b>16</b><i>a </i>on each remote client and a corresponding socket <b>16</b><i>b </i>on server <b>14</b>, such that a one-to-one socket ratio is established. In other words, one server socket is opened for each connected client. Remote clients <b>12</b> send Hypertext Transfer Protocol (HTTP) requests via established TCP connections to a TCP buffer associated with server socket <b>16</b><i>b</i>. Requests received at the TCP buffer are processed only as quickly as the server can respond to them. Often, requests build up in the buffer because the server cannot respond to them quickly enough, and server-side delay (also referred to as latency) often results. This is inefficient and frustrating, and may cause a user to abandon downloading the page.

[0018] In addition, each server socket <b>16</b><i>b </i>opened requires a certain amount of overhead processing by the server. This overhead processing tends to increase in proportion to the number of sockets that are opened, and thus in proportion to the number of clients connecting to the system. To maintain acceptable response times, the server system must limit the number of client computers that may be connected at any given time, typically by periodically timing out established client connections.

[0019] In FIG. 2, a system for processing HTTP requests according to one embodiment of the present invention is shown generally at <b>20</b>. System <b>20</b> typically includes a plurality of remote clients <b>12</b> configured to connect with server system <b>22</b> via computer network <b>24</b> and networking device <b>26</b>. As seen in FIG. 3, server system <b>22</b> may include one or more servers <b>14</b>, including web servers, applications servers and the like. In a typically employed configuration, server system will host and provide access to a website <b>25</b>. As will be explained in detail with reference to FIG. 3, connection between clients <b>12</b> and server system <b>22</b> is established via client TCP connections <b>120</b> on the “client side” of networking device <b>26</b> and server TCP connections <b>124</b> on the “server side” of the networking device. Networking device <b>26</b> may include an HTTP multiplexor/demultiplexor, as explained in more detail below, which is configured to route HTTP requests/responses and other network traffic between clients <b>12</b> and server system <b>22</b>. This routing function may be configured to provide for combining or multiplexing traffic received from multiple client connections onto a single connection to the server system. In these implementations, the system typically is also configured to separate, or demultiplex the traffic received along that single server connection, for selective routing and delivery to the appropriate connected clients.

[0020] Multiplexing and demultiplexing reduces the amount of server sockets necessary to service a given number of connected clients. The resulting reduction in socket-related overhead processing improves system performance and/or frees resources to allow more clients to connect to the system. In addition, where multiple server sockets are available, the system may be configured to further optimize performance through performance-based selection of server sockets. For example, HTTP requests may be selectively routed to a particular server socket based on optimal response time, in order to ensure efficient processing of the requests. It should be appreciated that the term socket, as used in connection with the present invention, refers to a port, buffer, logical node, or object configured to receive data in HTTP and other formats from a remote device via a network connection, and is not limited to a “socket” as defined in the Unix operating system environment.

[0021] Referring now to FIG. 4, remote client <b>12</b> typically is a personal computer including a processor <b>30</b> coupled to a communications bus <b>32</b>. A mass storage device <b>34</b>, such as a hard drive, CD ROM drive, tape drive, etc., and a memory <b>36</b> are also linked to the communications bus <b>32</b>. Memory <b>36</b> typically includes random access memory (RAM) <b>38</b>, and read-only memory (ROM) <b>40</b>. ROM <b>40</b> typically includes a basic input/output system (BIOS) <b>42</b>, which is configured to start up and operate basic functions of the remote client. Remote client <b>12</b> typically is configured to access computer network <b>24</b> via a network interface <b>46</b>. Alternatively, remote client <b>12</b> may be a portable data assistant, web-enabled wireless device, mainframe computer, or other suitable computing device.

[0022] Remote client <b>12</b> typically is configured to run an operating system (OS) <b>48</b> to manage programs or applications. Operating system <b>48</b> is stored in mass storage device <b>34</b>. Examples of suitable operating systems include UNIX, Windows, MacOS, VMS, and OS/2, although virtually any suitable operating system may be used. Remote client <b>12</b> includes a browser program <b>50</b> stored in mass storage device <b>34</b> configured to display requested web resources to a user of remote client <b>12</b>. Exemplary browser programs <b>50</b> include the Netscape browser commercially available from Netscape Communications Corporation of Santa Clara, Calif. and the Internet Explorer browser commercially available from Microsoft Corporation of Redmond, Wash.

[0023] Server <b>14</b> also typically is a computer similar to that shown in FIG. 4. Server <b>14</b> typically includes a server program configured to communicate with remote clients using the HTTP protocol. The server program typically is configured to receive HTTP requests, and, in response send HTTP responses to browser <b>50</b> on remote client <b>12</b> via computer network <b>24</b>.

[0024] Networking device <b>26</b> may be connected to server system <b>22</b> and remote clients <b>12</b> in various ways. On the client side, device <b>26</b> typically is connected to remote clients <b>12</b> via a public-type network, such as wide area network (WAN) <b>24</b>, as seen in FIGS. 5 and 6, which may form part of the Internet. The server-side link between device <b>26</b> and server system <b>22</b> typically is a private network such as an intranet or local area network (LAN) <b>84</b>.

[0025] Web site <b>25</b> typically includes a collection of web resources typically located at a web address called a URL (Uniform Resource Locator), or at another form of URI (Uniform Resource Identifier). The term “web resource” refers generally to a data resource that may be downloaded or accessed by a web browser. Web resources may include web pages, executable code, scripts, graphics, video, sounds, text, and/or other data. Web resources may be static (e.g. stored file) or dynamic (e.g. dynamically generated output). Web resources may be stored on and served by a single server <b>14</b> or a number of servers <b>14</b>. For example, images may be stored on one server while code may be stored in another server, and alternatively, copies of images and code may be stored on multiple redundant servers.

[0026] As shown in FIG. 5, networking device <b>26</b> typically includes a controller <b>70</b> having a memory <b>72</b> and processor <b>74</b> linked by a bus <b>76</b>. Also coupled to bus <b>76</b> is a mass storage device <b>78</b> including a multiplexor/demultiplexor <b>80</b>, which may also be referred to as a “mux/demux.” Networking device <b>26</b> also typically includes a network interface <b>82</b> coupled to bus <b>76</b>. Network interface <b>82</b> is configured to enable networking device <b>26</b> to communicate with client <b>12</b> via WAN <b>24</b> and with server system <b>22</b> via LAN <b>84</b>. An example of a suitable network interface is the Intel Ethernet Pro <b>100</b> network card, commercially available from Intel Corporation of Santa Clara, Calif.

[0027] In FIG. 6, another embodiment of a networking device according to the present invention is shown generally at <b>26</b>′. Networking device <b>26</b>′ typically includes an integrated circuit board <b>90</b>. The integrated circuit board contains a bus <b>92</b> connecting a network interface <b>94</b>, memory <b>96</b>, processor <b>98</b>, Application Specific Integrated Circuit (ASIC) <b>100</b>, and mass storage device <b>102</b>. Network interface <b>94</b> is configured to enable networking device <b>26</b>′ to communicate with remote client <b>12</b> via WAN <b>24</b> and with server system <b>22</b> via LAN <b>84</b>. ASIC <b>100</b> typically contains a multiplexor/demultiplexor <b>104</b>. ASIC <b>100</b>, processor <b>98</b>, and memory <b>96</b> form a controller <b>106</b> configured to process requests for web resources according to the methods described below. It will be appreciated that the embodiments of networking device <b>26</b>, <b>26</b>′ may be a stand-alone network appliance or may be integrated with a web server. Additionally, the mass storage device of networking device <b>26</b>, <b>26</b>′ is typically Flash memory, ROM, or other form of non-volatile memory, although it will be appreciated that a hard drive or other drive may also be used.

[0028] As indicated above, networking device <b>26</b> typically is connected to server system <b>22</b> via LAN <b>84</b>. Because the server-side connection is a private-type connection, while the client connections are public-type connections (e.g., WAN <b>24</b>), networking device <b>26</b> may be considered a server-side proxy server. A proxy server is a program or device that acts as an intermediary between a browser and a server. Networking device <b>26</b> acts as an intermediary by receiving HTTP requests from remote clients <b>12</b> and sending those requests to a socket on server system <b>22</b>, and by receiving server-generated HTTP responses and sending those responses to the remote client that originated the requests. The networking devices of the present invention typically are provided with a software or firmware multiplexor/demultiplexor configured to route network traffic between remote clients and a server system. Typically, this is done by multiplexing HTTP requests received at network device <b>26</b> via multiple client TCP connections <b>120</b>, so that those requests may be forwarded from device <b>26</b> as a multiplexed transmission to server system <b>22</b>. This multiplexed transmission normally occurs via a single server TCP connection <b>124</b>, so that only one socket is opened on the server side. Server system <b>22</b> in turn generates HTTP responses corresponding to the various requests of the remote clients <b>12</b>. These responses are provided along a single server TCP connection <b>124</b> to device <b>26</b>, where they are demultiplexed so that they may be selectively routed and delivered to the appropriate originating client <b>12</b>.

[0029] The above description contemplates routing of all traffic from multiple client TCP connections onto a single server-side TCP connection. Alternatively, as will be seen with reference to FIG. 3, requests and responses may be routed to and from more than one server socket. It is preferable, however, that the number of server sockets used be fewer than the number of client connections, in order to reduce the per-socket overhead occurring on the server side of the system. As indicated above, overhead processing can significantly affect overall performance. One of the advantages of the present system is a reduction of socket-related server overhead, which permits individual servers to handle more client connections.

[0030] Referring now to FIG. 3, each remote client <b>12</b> has an associated client TCP connection <b>120</b> established with networking device <b>26</b>, typically via a telecommunications network such as WAN <b>24</b> (FIG. 2). Each client connection <b>120</b> includes a client socket <b>120</b><i>a </i>associated with one of client computers <b>12</b> and a client-side device socket <b>120</b><i>b </i>(or, simply client-side socket <b>120</b><i>b</i>) associated with networking device <b>26</b>. Remote clients <b>12</b> are typically configured to send HTTP requests/responses <b>122</b> via connections <b>120</b>.

[0031] Server system <b>22</b> is coupled with networking device <b>26</b> via various server TCP connections <b>124</b>. Similar to the client side, each server connection <b>124</b> includes a server-side device socket <b>124</b><i>b </i>(or, simply server-side socket <b>124</b><i>b</i>) associated with networking device <b>26</b> and a server socket <b>124</b><i>a </i>associated with server system <b>22</b>. As indicated, server system <b>22</b> may include a plurality of servers <b>14</b> configured to perform various functions. Server connections <b>124</b> and their associated sockets may be in a one-to-one relationship with servers <b>14</b>, or multiple connections <b>124</b> may be associated with a given individual server.

[0032] The previously described multiplexing, demultiplexing and routing capabilities are more clearly seen with reference to FIG. 3. For, example, with respect to the top three client computers on the right side of the figure, the figure depicts combining (e.g., by multiplexing) the traffic associated with those client computers (e.g., request/response streams R<b>1</b>, R<b>2</b> and R<b>3</b>) into an individual server TCP connection <b>124</b>. This allows multiple clients <b>12</b> to connect to server system <b>22</b> using only one server socket <b>124</b><i>a</i>. This provides a significant advantage over conventional client-server connection schemes, which would require three separate server sockets to provide connections for all three clients. By using only one server socket, instead of three, socket-related overhead processing on the server side is reduced, allowing a greater number of connected clients to be serviced at one time.

[0033] As indicated, networking device <b>26</b> is configured to selectively route HTTP requests and responses between client and server sockets. For example, as indicated by HTTP request/response streams R<b>1</b>, R<b>2</b> and R<b>3</b>, networking device <b>26</b> is configured to receive HTTP requests from one or more of client computers <b>12</b>, and selectively route those requests via one of server connections <b>124</b> to an individual server socket <b>124</b><i>a</i>. Networking device is also configured to receive HTTP responses from server system <b>22</b>, and route those responses back to the appropriate originating client <b>12</b>.

[0034] Networking device <b>26</b> may be configured to multiplex requests from multiple clients, for example by taking HTTP requests from multiple clients and routing those requests to server system <b>22</b> via a single server connection <b>124</b>. For example, FIG. 3 depicts multiplexing of HTTP requests from the topmost three clients onto a single server connection <b>124</b>. The process is typically referred to as multiplexing because the traffic from a number of client-side connections <b>120</b> is routed to a smaller number of server-side connections <b>124</b>, and also because plural client-side connections <b>120</b> may be routed to a single server-side connection <b>124</b>.

[0035] Various methods may be used to combine the requests for transmission via a single server-side connection <b>124</b>. Typically, a multiplexing state agent, shown at M<b>1</b>-M<b>6</b>, is assigned to each client-side socket <b>120</b><i>b </i>on the networking device. Each multiplexing state agent is configured to, for each request received from the client, route the request to an optimal server-side socket <b>124</b><i>b </i>on the networking device, for transmission to a server <b>14</b> of server system <b>22</b>. When a response to the request is received from the server on the server-side socket <b>124</b><i>b</i>, the multiplexing state agent is configured to route the request back to the client-side socket <b>120</b><i>b </i>for the requesting client. The multiplexing state agent is free to route subsequent requests from the same client to an optimal server-side socket <b>124</b><i>b</i>, whether that be a different server socket, or the same server socket as used for previous requests. While typically each multiplexing state agent is configured to route requests from only one client-side socket <b>120</b><i>b </i>to an optimal one of a plurality of server-side sockets <b>124</b><i>b</i>, it will be appreciated that alternatively a single multiplexing state agent may be configured to route requests from more than one client-side socket <b>120</b><i>b </i>to (1) an optimal one of a plurality of server-side sockets <b>124</b><i>b </i>and/or (2) a single server-side socket <b>124</b><i>b. </i>

[0036] Networking device <b>26</b> may be further configured to demultiplex the response stream received from server-side sockets <b>124</b><i>b </i>in response to the client requests. Specifically, a series of responses received from a particular server socket is processed by the multiplexing state agents managing transactions with that socket, to unbundle the response stream into discrete responses or streams corresponding to an individual one of clients <b>12</b>. Each multiplexing agent is configured to detect those responses on the server-side socket <b>124</b><i>b </i>that correspond to requests from the client with which the agent is associated, and route the responses back to the originating client, via the client-side socket <b>120</b><i>b </i>for the originating client. This process is referred to as demultiplexing because a series of responses from a single server-side connection <b>124</b> is broken up and routed over a plurality of client connections <b>120</b> to a plurality of clients <b>12</b>.

[0037] As indicated, client-side connections <b>120</b> may correspond with server-side connections <b>124</b> in various ways. For example, the system may be operated so that all client connections are multiplexed to an individual server connection. Where multiplexing is employed, networking device <b>26</b> is configured to multiplex HTTP requests provided from two or more client connections (e.g., the connections corresponding to R<b>1</b>, R<b>2</b> and R<b>3</b>) into a single server connection, such that only one server socket need be opened. Alternatively, multiple server connections may be employed, where each server connection corresponds either to an individual client connection, or is multiplexed so as to correspond to multiple client connections. In any event, it will normally be desirable that the server connections be fewer in number than the client connections, in order to achieve an optimal reduction of socket-related overhead processing on the server side of the system. Regardless of the particular multiplexing configuration, networking device <b>26</b> is further configured to demultiplex the responses generated by server system <b>22</b>, and cause those responses to be selectively routed to the appropriate originating client <b>12</b>.

[0038] Where multiple server connections are available, various optimization schemes may be employed to reduce delay and otherwise improve performance. In particular, networking device <b>26</b> may be configured to route HTTP requests to an optimal server socket, which typically is a least busy server socket. To determine the optimal server socket, multiplexor/demultiplexor <b>80</b> (FIG. 5) may be configured to detect the response time at each server socket <b>124</b><i>a </i>by monitoring corresponding server-side sockets <b>124</b><i>b </i>on the networking device. The server socket with the fastest response time may be determined to be the least busy server socket. Alternatively, or additionally, various sockets may be monitored to determine which server socket has the fewest unfulfilled requests. In addition, routing may be effected based on which of the server sockets was the last to be accessed.

[0039] In addition to or instead of the above-described optimization techniques, networking device <b>26</b> may be configured to determine the type of request being made and/or the type of data being requested and use that information to effect optimal routing. For example, all image requests may be handled by a predetermined set of sockets on server system <b>22</b>, while all HTML requests may be handled by a different predetermined set of sockets. In addition, certain sockets may be designated to handle specified protocols or protocol versions. For example, one set of sockets could be designated for all HTTP 1.0 requests, with another set being designated to handle HTTP <b>1</b>.<b>1</b> requests.

[0040] Regardless of the particular implementation, these optimization techniques increase the overall efficiency and response time of server system <b>22</b> by adjusting the flow of requests away from slow, congested server sockets and toward fast congestion-free server sockets. These optimization techniques may be employed in the described networking devices of the present invention, in addition to or instead of the routing, multiplexing and demultiplexing features discussed above.

[0041] Typically, the connections between networking device <b>26</b>, server system <b>22</b> and clients <b>12</b> (e.g., connections <b>120</b> and <b>124</b>) are persistent TCP connections. Persistent TCP connections are connections that remain open until explicitly commanded to close or until the server times-out the connection. Alternatively, a connection other than a persistent TCP connection may be used. Effective use of persistent connections is a significant advantage of the present invention over prior systems. Often the persistence feature is not used in conventional networking systems, or is only partially used, because of the significant amount of per-connection overhead placed on the system. As discussed above, this overhead fundamentally limits the number of clients that can be connected at any one time. Thus, to provide access to a large number of potential connected clients, many existing systems periodically terminate client connections, to allow others access to the system. This effectively is a disabling of the persistence feature available in newer networking protocols. The failure to leverage persistence is particularly a drawback in secure environments, such as SSL, where setting up and tearing down TCP connections involves key exchanges and other overhead intensive tasks relating to security. By reducing the excessive overhead that necessitates periodic terminating of client connections, networking device is able to establish and maintain persistent connections with clients and servers.

[0042] It will be appreciated that the described networking devices and systems are extremely flexible, and may be configured in a nearly limitless number of ways to enhance the performance of client-server networking systems. Other network device implementations are described in co-pending U.S. patent applications Ser. Nos. 09/680,675, 09/680,997, and 09/680,998, filed Oct. 6, 2000, Nos. 60/239,552 and 60/239,071, filed Oct. 10, 2000, No. 60/287,188, filed Apr. 27, 2001, and No. 60/308,234 filed Jul. 26, 2001, and No. 60/313,006 filed Aug. 16, 2001, the disclosures of each of which are herein incorporated by reference, in their entirety and for all purposes. The features of these devices may variously be implemented in connection with the networking devices and systems of the present invention.

[0043] Turning to FIG. 7, a method <b>140</b> may be practiced according to the present invention. The steps of method <b>140</b> are typically accomplished by networking device <b>26</b>, in connection with remote clients <b>12</b> and server system <b>22</b> communicating via the described network connections. Alternatively, the method may be accomplished by dedicated software on server system <b>14</b>, or by some other suitable software or hardware device. At <b>142</b>, the method typically includes establishing persistent TCP connections between networking device <b>262</b> and one or more sockets on server system <b>14</b>. At <b>144</b>, the method typically includes establishing persistent TCP connections between networking device <b>26</b> and one or more remote clients <b>12</b>. At <b>146</b>, the method further includes listening for HTTP requests from originating remote clients <b>12</b> and/or for HTTP responses from various server sockets.

[0044] When HTTP requests are detected at networking device <b>26</b>, method <b>140</b> continues, at <b>148</b>, with receiving HTTP requests at one or more client-side sockets <b>120</b><i>b</i>. Method <b>100</b> further includes, at <b>150</b>, multiplexing HTTP requests so that the multiplexed requests may be transmitted to the server system via a single TCP connection. At <b>152</b>, the method further includes routing the requests to the server system, typically by sending the multiplexed requests to an optimal server socket.

[0045] Prior to step <b>152</b>, method <b>140</b> may also include monitoring server sockets to determine an optimal server socket. The optimal server socket may be determined by identifying a server socket with a least-lengthy response time. Alternatively, the optimal server socket may be determined by determining a last-accessed server socket, determining a server socket with the fewest number of unfulfilled requests, determining the type or size of data being requested or other parameters related to the HTTP requests, or by weighing all or some of these conditions. By determining an optimal server socket, the multiplexor/demultiplexor is able to improve performance by facilitating more efficient use of server resources.

[0046] When HTTP responses are detected at the multiplexor/demultiplexor at step <b>146</b>, method <b>140</b> proceeds to <b>154</b>, and includes receiving HTTP responses from the server system. The multiplexor/demultiplexor typically is configured to determine the destination of the HTTP responses. At <b>156</b>, the method includes demultiplexing HTTP responses received from server system, in order to permit selective routing and delivery of certain of those responses to the appropriate originating client. At <b>158</b>, method <b>140</b> includes sending the demultiplexed responses to the originating remote client.

[0047] When there is a new remote client or server detected at <b>160</b>, the method includes returning to step <b>144</b> to establish a persistent TCP connection with the new remote client, or returning to step <b>142</b> to establish a persistent TCP connection with the new server, respectively. It will also be appreciated that networking device <b>26</b> may be configured to establish a plurality of TCP connections with a plurality of servers and a plurality of remote clients, and therefore may be configured to handle HTTP requests and HTTP responses from multiple servers and remote clients at once.

[0048] Similar to the devices and systems described above, the described method enhances the performance of client-server networking systems. This is accomplished through multiplexing and demultiplexing of HTTP requests/responses, in order to reduce overhead processing that results in conventional systems from opening a server socket for each client computer connecting to the server. This also allows for fuller utilization of the persistent connection features that are now available in connection with HTTP and other protocols. Additionally, or alternatively, the method may include selection of optimal server sockets, in order to further enhance server sufficiency.

[0049] While the present invention has been particularly shown and described with reference to the foregoing preferred embodiments, those skilled in the art will understand that many variations may be made therein without departing from the spirit and scope of the invention as defined in the following claims. The description of the invention should be understood to include all novel and non-obvious combinations of elements described herein, and claims may be presented in this or a later application to any novel and non-obvious combination of these elements. Where the claims recite “a” or “a first” element or the equivalent thereof, such claims should be understood to include incorporation of one or more such elements, neither requiring nor excluding two or more such elements.