Many network computer users want access to their corporate network or the like through the Internet. In order to access such a network, the concept of tunneling is used. In general, tunneling encapsulates one protocol within another protocol that is supported over the Internet, e.g., HTTP, such that the encapsulating protocol appears as ordinary data, whereby the encapsulated protocol (that by itself is unsupported) is allowed to pass through proxies, firewalls and so forth.
One protocol that is desirable to encapsulate within HTTP is Remote Procedure Call (RPC). RPC generally refers to a protocol that allows a program running on one networked computer to have a procedure executed therefor on another networked computer, e.g., a remote procedure call is initiated by a client caller and received at a remote server, which then executes a procedure based on data in the call and returns a result to the client caller. As can be appreciated, RPC provides a number of benefits in networked computing.
In order to encapsulate RPC within HTTP, e.g., so that applications and the like can use RPC whether a client computer is directly (actually through a proxy) connected to the corporate network or is connected through the Internet, contemporary operating systems map RPC data streams on top of HTTP primitives. This mapping suffers from a number of severe limitations.
By way of background, conventional mapping maps the RPC data stream on top of a pseudo-SSL (Secure Sockets Layer)-encrypted HTTP data stream, where the data stream is declared to be SSL encrypted, but actually is not. This is done so that HTTP proxies do not look into the data, since they assume that it is encrypted. Note that the RPC Proxy uses the same HTTP request to send all of its requests/replies, which is in direct violation of the HTTP standards. Also, the HTTP data stream is directed to port 80, the defined standard port for conventional HTTP communication, even though the standard port defined for SSL is port 443. This is because SSL is verified on port 443, i.e., true SSL is required or the proxy does not allow the data stream.
This method of mapping suffers from several major limitations and/or problems. One limitation is that the method requires SSL tunnelling to be enabled on port 80 of the HTTP Proxy, for reasons described above. However, the vast majority of proxies that are available do not enable this by default, and most network administrators are very reluctant to enable it, especially the Internet Service Provides (ISPs) to which many users subscribe. However, unless enabled, the conventional RPC to HTTP mapping method is not deployable, which is the situation in most environments.
Another problem is that the conventional method of mapping assumes that the Web Server will allow an infinite amount of bi-directional traffic (requests and replies) to be mapped to the same HTTP request. This is no longer the case with contemporary Internet severs, (e.g., Microsoft Corporation's IIS6.0 product), and consequently the conventional mapping method simply does not work with such servers.
Yet another significant problem with the conventional mapping method is that most elements of the HTTP infrastructure do not allow idle connections to stay open for a long time. However, RPC allows any amount of time between making RPC Requests on the same binding handle. As a result, RPC usage patterns in which there is a significant delay between requests are rejected by the underlying HTTP infrastructure, resulting in application errors.
In sum, HTTP has a number of limitations including its finite, unidirectional and time-limited qualities, which do not match up with the requirements of RPC and/or other protocols having data streams that need bidirectional communication over essentially unlimited sizes and with essentially unlimited connection times. At the same time, transporting RPC and other data streams over HTTP would be highly desirable to meet the needs of many computer users.
USPTO Backgrounds
USPTO Backgrounds