CODEWITHSUNDEEP
javascriptajaxcross-browserxmlhttprequestcomet
kristopolous
kristopolous

Reputation: 1848

Persistent upstream Comet style connections

There are many methods to have persistent downstream connections. You can use a hidden iframe for instance; or a sophisticated XHR model that utilizes the onreadystate to push partial information through your application while maintaining the connection. However, I have been unable to find a way to do persistent upstream in the same spirit.

If you utilize Connection: Keep-Alive in your upstream pushes, then you don't actually tear down the connection and rebuild each time; that's good. You could even then encode your upstream pushes in a GET query that would return an empty document

However, even though it's close, you still don't have quite the performance, low latency, and throughput that you can get with the persistent, long-polled downstream connections.

Unless, that is, there is another way of doing this.

Here's some theories on what a solution of this type would look like;

It's worth noting that although this may be possible with HTML5 or Flash, it would be eminently useful if one could pull it off without plugins on the ecosystem of browsers that are prominent today. One of my aspirations is an experiment to be able to fluidly implement Knuth's coroutines between the client and server.

Anyone have any insight on this? Thanks.

~chris.

Upvotes: 4

Views: 221

Answers (1)

Anton
Anton

Reputation: 4584

The only way to do "true" bi-directional communications in a web browser is with WebSockets. That's their primary advantage - that you can do both upstream and downstream communications without the overhead of HTTP.

If your downstream connection is delivered with long-polling, then your upstream connection is going to be regular old HTTP requests.

However, unless you have LOTS of requests, I would consider whether you are trying to optimize something that doesn't really need optimization. Even the smallest available servers today are more than capable of handling thousands of HTTP requests per second. And since most real-time client applications listen more than they send, it's fast writing to the downstream connections that will really impact server performance. On the upstream side, as long as you are using "Connection: Keep-Alive" to avoid the overhead of socket setup/teardown, most applications will see a negligible performance advantage by moving to WebSockets.

(I work for the company that builds WebSync.)

Upvotes: 2

Related Questions