Well it sort of depends. If you're using TCP (which I'm guessing you will be) then TCP can lock while waiting for lost packets, which can freeze up everything. Multiple threads will help here, but there are other ways to get get the same functionality. The problem with using multiple threads for networking is that if TCP locks in another thread, the main thread probably shouldn't do anything either. In a more common example, if two players are playing Tic Tac Toe and one is waiting for another to make a move, it doesn't really make much sense to let the waiting player do anything when it isn't their turn... therefore the multi-threading just becomes pointless. You can also think of games like Warcraft III where you get a "Waiting for Players..." box that pauses the game if communications have been lost for too long. I don't know what will work best in your case, but a Wizard of Oz scenario will probably need to appear seamless in any case, so it may indeed make sense to have another thread that will delegate the work to a simple Simon AI in case the controller player is lagging.

In the end, though, stuff like UI should probably be in its own thread anyway, so that the waiting dialog can still be properly updated while another thread is locked waiting for input from the other player.

An easier route would be to use the java.nio stuff which gives you non-blocking sockets so you don't have to punt your networking into a separate thread.

Are you serious? This guy says he's new to Java, and is struggling with threads, and you recommend java.nio?

I'd recommend him to read the Sun Java Tutorial, which explains both threads and networking.

To keep it thread safe in the most basic way, simply pass all incoming packets from the TCP streams to a (synchronized) queue, and handle it from the Even Dispatch Thread. It will work, and you can always refactor it later to a 'proper design' - the main priority should be to get it to work though.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Yes, absolutely every source of input and output has to have it's own thread, so it can blockindependantly of all the others. That includes arranging that all outgoing chatter is queuedand transmitted by an output pusher thread, rather than sending it from whatever threadgenerated it. Remember that mouse events, window events, and keyboard events are "sources of input" too.

And once separated, those threads should do absolutely NOTHING else. To be specific, they shouldnot parse messages, update displays, attempt error recovery or anything else.

Most important of all, don't try to refresh your displays in the system's event generator thread.

Ideally, you will have one run loop in which all significant processing occurs. Other threads willonly feed it events through queues.

I would say you usually have one thread for each independent communication. When you have an established dialog of request and response, you only need one thread wjich will send and receive in turns. If you want to handle each direction of communication on its own, you have two threads.

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