Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Asynchronous Client-Server Communication (Proxy)  (Read 2051 times)
0 Members and 1 Guest are viewing this topic.
Offline thofoer

Innocent Bystander

Java games rock!

« Posted 2005-03-24 06:52:31 »


I need to implement a bidirectional, fully asynchronous client-server
communication. Normally the 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

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
       if (l==null) return;

Client-side (output-stream to server):

       url = new URL( "" );

URLConnection con = url.openConnection();  
PrintWriter out   = new PrintWriter(con.getOutputStream());

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


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.

Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #1 - Posted 2005-03-24 09:32:52 »

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?


Offline vrm

Junior Devvie

where I should sign ?

« Reply #2 - Posted 2005-03-25 06:57:24 »

try with jakarta commons-httpclient

it's more complete than Sun one
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cknoll

Junior Devvie

Flame On!

« Reply #3 - Posted 2005-03-30 15:31:50 »

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.

Pages: [1]
  ignore  |  Print  

EgonOlsen (74 views)
2018-06-10 19:43:48

EgonOlsen (55 views)
2018-06-10 19:43:44

EgonOlsen (74 views)
2018-06-10 19:43:20

DesertCoockie (254 views)
2018-05-13 18:23:11

nelsongames (154 views)
2018-04-24 18:15:36

nelsongames (154 views)
2018-04-24 18:14:32

ivj94 (895 views)
2018-03-24 14:47:39

ivj94 (156 views)
2018-03-24 14:46:31

ivj94 (808 views)
2018-03-24 14:43:53

Solater (172 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!