Socket communication of server with two different applications, Java

I am writing the code for a server that would help two different applications in different platforms communicate with each other. To visualize it a bit it would be something like this :

App1<------>Server<------>App2

What server does is rear var1 from app2, write it to app1, then read var2 from app1 and write it to app2. Like this :

while(true){

var1 = app2stream.readInt();

app1stream.writeInt(var1);

var2 = app1stream.readDouble();

app2stream.writeDouble(var2);

}

My problem is that at some point i have this code at my server :

app1.accept();

app2.accept();

What this means is that no matter what, and given the fact t开发者_JS百科hat the server is always running, app1 is the one that should connect first since app1.accept() is a blocking method.

Is there any way around this? It would be great to allow the two applications to connect to the server regardless of who "came" first and then wait for the server to proceed with the above code. Can i use threads just for the accept() part and then pass the streams to the other thread? I read a bit about channels but got a bit buffled, any examples would be great.

---

Use NIO

It allows you to do non-blocking sockets (including accept) using the Selector class.

Basically, it gives you much more native access to the system libraries and the ability to handle your task without having to multi-thread.

---

Only have one accept call, and one server socket. You can make the determination which app has connected once they connect. If you can't get it from the connection details, have them send an authcode (probably a good idea anyway) which you can map to your app.

---

You should probably treat them both the same unless they say otherwise.

For example when the each socket connects send a "what client?" message.

Then check whether the client responds with 1 or 2.

If both respond with 1 or something just disconnect both.

---

I think the "standard" way to do this is to have the server listening on a port, and when a message comes in, immediately spin off a new thread to handle it, then go back to listening for another message. Then, as Glowcoder says, make all the connections in the same loop and make it figure out which is which after connecting.

I suppose the alternative is to have multiple threads, each listening on different ports. I've never tried to do that, I'm not sure if one would block until a connection was made and so you'd never get to the other thread.