Asynchronous Client-Server Communication (Proxy)

Hi!

I need to implement a bidirectional, fully asynchronous client-server
communication. Normally the java.net-API would do fine, but I also have
to deal with firewalls/proxies. So I’m trying to use servlets and HttpClient.

There are many examples of servlet-applet/application communication, but due to the nature
of HTTP everything is a synchronous “client-sends-request server-sends-response”.
In my application client and server will have to send and receive data from the other side
whenever they want. So I had the idea of creating two connections, one for upstream and
one for downstream. These connections will have to be kept alive during runtime of the
client session.

That’s the theory. In practice I don’t get the output-stream client->server to work.
Here’s a little code I wrote with the java.net-API:

In the servlet:

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
BufferedReader in = new BufferedReader(new InputStreamReader(request.getInputStream()));
while(true) {
Object l = in.readLine(); // read anything from the input stream and print it
System.out.println(“recv–>”+l);
if (l==null) return;
}
}

Client-side (output-stream to server):

    url = new URL( "http://127.0.0.1/url_to_servlet" );

URLConnection con = url.openConnection();
con.setDoOutput(true);
con.setDoInput(true);
con.setUseCaches(false);
PrintWriter out = new PrintWriter(con.getOutputStream());
out.println(“Hello?\n”);
out.flush();

This doesn’t work. Nothing is received by the servlet. Only when I add a

con.getInputStream();

to the client code (after out.flush()) the servlet receives the string. But then I cannot
use the output stream anymore.

What am I doing wrong?
Is that asynchronous communication possible at all?

Thank you for reading my post. Any help appreciated.

Thomas

Is this another one of the Java URL only supports HTTP 1.0 type bugs? A streaming upstream to HTTP wasn’t supported til later?

Kev

try with jakarta commons-httpclient

it’s more complete than Sun one
http://jakarta.apache.org/commons/httpclient/features.html

I’m not so sure this is a bug in the spec or related to 1.1 vs 1.0 implementation of HTTP…I seem to recall reading that when you make a URLConnection to send data to the server, the process of ‘writing’ to the output stream doesn’t mean that you have made a connection to the server, rather that you are preparing the buffer of data that will be sent to the server when the connection is established (which happens when you call getInputStream() (which internally makes the connection to the server, posts the raw data, and then reads the response byte stream).

This is just how http transactions work. I think you may be mis-using the URLConnection class to work around a infrastructure issue (ie: firewalls). You may want to find another way. Or re-think how you want your communication architecture. Webservers aren’t built to have a persistant connection open (let alone 2 for inputs and outputs) throughout the life of a session, so you could just be running into a wall with this thought process. What you could do is have a URLConnection that sends data to the server which then queues up requests for that client (and processes it when it’s ready) and another connection to read the results of the requests, but in both cases a connection is opened, data sent, and data recieved, and then the connection is closed. This is the way of HTTP. But this is where persistant connections could save you the trouble of re-opening physical connections to the server transparently.

-Chris