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 sidewhenever they want. So I had the idea of creating two connections, one for upstream andone for downstream. These connections will have to be kept alive during runtime of theclient 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:

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org