The Comet/Ajax Request Router serves to decouple application back-end servers from the web-server for applications with a browser-based client. This enables high-performance client-server communication using application protocols layered over HTTP transport. Because the Comet/Ajax Request Router does not buffer requests or replies, and does not inspect the content of requests or replies, it operates at minimum latency. Because the Request Router creates new threads or processes to balance routing load, it scales to the capacity of the server on which it resides. Because the Request Router limits the number of threads or processes forked, it never allows incoming connections to overwhelm the system with cache- and scheduler-thrashing, which can otherwise result from excessive context-switching.
The request router will hold open HTTP persistent connections for any configured period, to allow client-size XmlHTTPRequest objects to block waiting for notification of events by a server. Thus it provides support for Comet-style server-push messaging and bi-directional asynchronous message passing applications. Basic Ajax functionality is transparent to the Request Router, which will connect an XmlHTTPRequest to its appropriate service provider, immediately as the request header unambiguously matches one of it's routing rules. There is no delay in data delivery while the request's content body is read. When pre-existing backend connections are available, they are re-used to avoid a handshake delay while creating a new connection to a back-end service.
We feel that the current project state completely fulfills all but the last of these goals. The final goal is an evolving one, which develops with the range of applications using the request router.
Many other reverse-proxy solutions exist, and some can be configured to distribute requests over back-end servers for application routing and for load-balance. Our survey of such solutions concluded that all of them suffered from one or more of the following deficits, which made them unsuitable for our Comet/Ajax service implementations:
While many of these projects are excellent for their intended domain of application, they do not meet the criteria required in order to support a performant application in cases where user-experience or system throughput are sensitive to latency, and indeed often impose legalistic correctness criteria on the application developer which are spurious, and inhibit rapid development. Apache and Lighttpd proxy modules, and the Pound reverse proxy, as well as ISA Proxy Server and IIS were all unsuited to our latency-sensitive applications, thus motivating the development of the Request Router to enable full-scale production deployment of browser-based applications, including those relying exclusively on MSXML or XPCOM for communication, as well as those using Java applets and communicating via HttpURLConnection objects, over HTTP or HTTPS.
The Request Router fully supports all manner of proxy, at all levels of HTTP protocol support. The bottom line is that if your client can connect to your website, they should also be guaranteed to be able to use your service. The Request Router allows applications to make this guarantee without imposing any requirement of software installation on the client computer in order to transit intervening NAT, Firewall, or Request Proxy servers. If you should become aware of any case in which a NAT, Firewall, or Request Proxy fails to allow HTTP traffic to an application front-ended by the Request Router, we ask that you would please send an email to rr_bug (at) southoftheclouds (dot) net, or submit a bug to the sourceforge project.
The Request Router currently supports the following platforms:
Windows NT >= 4.0sp6a support is planned.