How does AJAX work with non-fixed-length HTTP responses?

April 23, 2009 8:47 AM

AskMe Programming Squad: Need some help with AJAX and a slightly unusual method of communicating with a remote server.

I've been told to investigate the replacing of our product's current Java-based client with a Web-based one. Most of it is pretty straightforward, but I need some help to determine whether our existing client's method of communication with the backend can be replicated with AJAX.

The existing client communicates with the backend via HTTP, using two different threads:

Client thread #1 opens up a socket and sends out a series of POST requests which tell the backend what to do. Each request gets replied to with a standard HTTP 200 (or 403 or whatever) response.

Client thread #2, upon program startup, opens up another socket and sends a single GET request. As events occur on the backend, chunks of data get sent to the client as part of the response to this request. The client doesn't wait for this data in the form of a completed HTTP response, but basically does a select() on the socket and waits until it receives anything.

Thread #1 is easy to implement on the client-side using AJAX. I've done that a few times before. My question is, is it possible to do the same thing for thread #2? I've only used AJAX to fetch HTML documents or DOM elements or whatever from a remote server; this sort of open-ended stuff would be new to me. Changing the communication scheme isn't possible for a couple of reasons; I need to work with what I have.

thanks in advance for any help!

posted by xbonesgt to computers & internet (7 answers total)

It sounds like you might be interested in Comet instead of AJAX.
posted by Civil_Disobedient at 9:01 AM on April 23, 2009

Preemptively nthing Comet!
posted by soma lkzx at 9:04 AM on April 23, 2009

i don't know a lot about comet, but if you need to work with a raw socket on the client, this can be done with a small flash movie that communicates with JS via externalinterface.

worth considering if comet doesn't do it for you.

(btw: though flash's http methods work using the browser's socket, the socket class itself makes direct connections using the plugins own socket. that means any headers that would be appended by the browser for, say, a request by urlloader won't be if you make a request from socket.)
posted by klanawa at 9:25 AM on April 23, 2009

You're describing what the current Java application does, not what the application does. The previous posters are correct that a Comet-style approach is what you want if you need to directly replicate the type of communication currently occurring

Alternatively you could just wrap communication of thread #2 in a separate server-side script that holds the "messages" for the client, which could then use normal Ajax to poll this script at a given interval and fetch any pending messages

Comet is useful for situations in which you need to send data with greater frequency than it's feasible to poll. If the client can wait 5-10 seconds for new data to come in, normal Ajax polling should work just fine, and creating an intermediary server-side script for Ajax polling to talk to may be be easier than using a Comet approach
posted by crayz at 9:42 AM on April 23, 2009

Sorry, should clarify: describing the way the java app is implemented, not what the user requirements of the application are
posted by crayz at 9:43 AM on April 23, 2009

well... it's not really a user requirement that the client behaves the way it does, but it's a functional requirement that any new client uses this sort of two-socket mechanism. And upon re-reading of my post, I realize that the sentence "changing the communication scheme isn't possible" is a pretty vague one. Apologies for not being clearer. I'm looking to do this with as little backend work as possible (the guys in charge of that have enough things to worry about at the moment).
posted by xbonesgt at 10:13 AM on April 23, 2009

Absolutely this can be done, it is sometimes referred to as "long polling". I have worked on a web application with exactly this architecture and it works great. The web app makes an HTTP request saying "are there any events pending?" If there are, they are sent immediately, and the web app immediately makes the same request again. If there are not, the server doesn't respond at all, leaving the client hanging. When an event occurs, the server sends it right down the open connection if there is one, or else, queues it. Apply a few sensible timeouts and retries here and there, and you end up with a near real-time "push" capability without frequent polling or using anything more exotic that XmlHttpRequest.

And as you said, user input from the client-side can go through a separate connection with regular old GETs and POSTs or whatever without causing any problems.
posted by steveminutillo at 11:38 AM on April 23, 2009