Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

That's an interesting approach, but it's still pooling, although I wouldn't know better.

Does anyone know what the alternatives are? Can you avoid pooling and still speak HTTP?

Yes, it's definitely still polling. It is polling about once per minute. However, at least it's only polling at the application protocol level, not the connection level. Browsers and the GRIP proxy support keep-alive so the same TCP connection is very likely to be re-used for quite a while.

HTTP by nature is request/response. To speak pure HTTP, there isn't a way around polling that I know of. Avoiding polling means implementing your own protocol over HTTP, or using WebSockets (see Comet or implementations in Socket.IO, Firebase, SignalR, etc).

There is actually a way to do streaming over HTTP without doing WebSockets. It's called "Server Sent Events" and is implemented in the EventSource API in Chrome, Firefox and Safari.

It's quite easy to fall back to long polling in older browsers and it's a very simple and straight forward format.

Yes you can certainly stream and do message passing within HTTP (for some browsers) but you can't, for instance, return headers more than once without your own application protocol.

The most interesting bit about this architecture for me is the 1:1 mapping with a pure HTTP resource. It's a bit like an implicit subscription to a pub-sub enabled resource. In this implementation we are simply calling our API like we normally would (except on the stream domain) and waiting for an update.

Or make life real simple and just use Socket.io

Will people stop writing crap "on" HTTP please and use TCP like you're supposed too! :)

Websockets is a great transport protocol for bi-direction realtime persistent connections. And it's very easy to write your own application protocol or just use WAMP from http://wamp.ws.

There's nothing wrong with using HTTP if it's done in a sensible way.

In the early days of the realtime web, long-polling was used mostly as an underlying hack in the emulation of streams. However, RealCrowd's API isn't a hack. When clients make requests to the server, they are attempting to synchronize a resource. One could argue that this kind of interface is semantically closer to what the client is trying to accomplish than one based around pure message passing.

Yes there are real problems with HTTP. There is a lot of overhead in building a connection and maintaining. It's designed to be a transient, request/response oriented protocol. Things like XmlHttpResponse are a hack and misuse.

I'm not just being pedantic about it either. Just compare server performance of RPC over Websocket to RPC over HTTP at scale.

You can do HTTP streaming, where clients access a resource of indefinite length. This should work well enough with native clients and even some modern browsers (with EventSource aka Server Sent Events, or streaming XmlHttpRequest).

Long-polling with retries is not so bad though. Even with WebSockets you'd still want a periodic heartbeat. It's all the same amount of traffic really.

One approach is to register a callback essentially. The client asks the server to send updates or notifications to a URL. Then the server sends updates to that URL. The client would need to have its own server though so it might not be viable in all situations.

Reply on news.ycombinator.com