1. Field of the Invention
The present invention is generally related to network communications systems and, in particular, to enterprise class client-server systems capable of supporting real-time, bidirectional communications over an HTTP-based network.
2. Description of the Related Art
While the development and use of Web applications continues to grow, a significant limitation exists in that the widely used HTTP protocol only supports half-duplex communication. As in the case of conventional client-server application use models, a continuous tier-to-tier bidirectional, or full-duplex, communications connection is highly desirable, if not required to enable client interaction with various backend systems. The demand for realtime services on the Web, such as to display realtime stock feeds, permit ad-hoc information updates, enable active participation among multiple users in realtime operations, particularly as encountered in bidding, chat, games, and other applications, is substantial and increasing.
Although other protocols, supported by proprietary client and server applications, might be utilized, the fact that the Web-browser client is ubiquitous effectively requires use of the basic HTTP protocol. Natively, conventional Web-browser based client applications have been basically constrained to communications where data requests and responses flow only in one direction at a time. Conventional attempts to emulate bidirectional communications typically involve the use of polling techniques, such as implemented in Comet and Reverse Ajax. In essence, a server, under select circumstances, is able to push information to the client. These techniques, however, suffer from many limitations, such as lack of standardization, inadequate performance, and limited scalability.
For example, a direct polling technique requires a client application, typically implemented in the context of a Web-browser, to repeatedly send HTTP requests at regular intervals to a target Web-server. Each request immediately receives a server generated response, potentially returning updated real-time information depending on whether the server has any updated information. Depending on the polling interval, the received information may not be really received in real-time and, conversely, may only be obtained subject to a high overhead of server requests frequently for no responsive information. This overhead impacts both client and server performance and consumes network bandwidth.
To avoid the overhead of direct polling, a variant known as long-polling has been developed. In long-polling, also known as asynchronous polling, the client application, again typically a Web-browser, issues a request to a target Web-sever system. Rather than providing an immediate response, the target server will delay for up to some defined interval, waiting to have some new information to provide as a response. If some new, i.e., real-time data is obtained by the server during the delay interval, a server response containing the real-time information is then sent to the client. If no new information is received, an empty response is returned to the client application, terminating the pending request. Long-polling thus has the potential to reduce latency in the delivery of real-time data and may reduce the number of request/response cycles to some degree. Long-polling does not, however, provide any substantial performance improvements over traditional polling due to the still significant number of request/response cycles required and the similar number of HTTP headers, present in both long-polling and polling, that must be exchanged between client and server.
Streaming is another conventional variation. Where streaming is used, the client Web-browser sends a complete request, but the target server responds in a manner that allows the connection to be maintained open for at least a defined interval. In effect, the target server holds off acknowledging that the response is complete. This allows the target server to continue the response with additional real-time information as received by the target server. A benefit of establishing a streaming connection is reduced overhead on the part of the client and server systems. Network traffic is also reduced, since the client and server systems only send HTTP header packets once to establish the streaming connection. Response continuance network packets are only sent as needed and then only contain data, thereby imposing minimal overhead. Unfortunately, streaming is encapsulated in HTTP and, thereby, entirely dependent on how low-level HTTP transfers are routed through the network at large. Streaming is therefore subject to unpredictable connection-breaking and substantial buffering latencies wholly determined by the myriad of systems that any given connection may be routed through. Conventional streaming is, therefore, not reliable.
As an alternative, the proposed HTML5 draft specification defines new protocol features, including WebSockets, Server-Sent Events, and associated access security requirements, as a way of enabling reliable bidirectional communications using the HTTP protocol. While the HTML5 specification is intended to standardize, among other things, full-duplex, direct TCP communication, a final specification is likely a year, if not several years from being formally adopted. Functional incorporation and operationally uniform adoption into the next generation of Web-browsers will not likely occur for many years. Further, resistance to update existing in-place Web-browsers due to practical, business, and other limitations, will likely prevent wholesale adoption for many more years.
Consequently, a need exists for a way to provide real-time, full-duplex communications capabilities substantially independent of the client Web-browsers that may be used to access Web services of all natures, including business and other commercial services, recreational, and informational.