Java Networking! Chat in Game

Call Me Jimmy

Hey, I'm doing an online poker game for a college assignment and I think I understand the whole threads / networking deal pretty well. I wrote a test chat app and that worked out fine.

What I don't understand is how it's possible to have a chat app implemented in my game?

How is it possible to send Strings back and forth over the network AND send game updates
even if they are in different threads? Each client has one socket connection... this is fine in the chat app where it only reads and write strings and only expects this but what happens when, while one thread is waiting for the next string in the chat box and another is waiting for a game update, no text is entered to send in the chat box and the game update is sent. Then the thread waiting for a string could possibly read the game update from the connection stream and produce an error.

Sorry, it's been really hard to articulate. If ye don't understand I'll try to clear it up.

Thanks in advance

azzeretti

Is it just your client that has one socket connection or do the real clients have only one connection too?

I don't know Java but I would imagine with other languages you would fork the connections and create new threads for each connections. Is this what you want to avoid?

Call Me Jimmy

Thanks for the reply. In java, as far as I understand, sockets are used to connect a server and client. Each client can only have one connection to the server I think. Ultimately, it boils down to the fact that no matter how I split the processing into separate threads, there is still only one connection to read and write data on.

I don't understand how in one thread a connection can call the read() method and process a string, while another thread at the same time can read() or write() anything else on that connection.

srsly78

Just define two different types of message. One for game updates, another for messages. In the receiving thread, handle the messages differently. You already have the hard stuff figured out, this bit is easy.

With sockets you can have lots of connections open. I wrote an mmo prototype that used UDP for some high-speed messages, but TCP for other stuff that needed guaranteed delivery but wasn't so time critical. You don't need to do anything complicated like this, just use tcp only.

Maybe the asynchronous part is confusing you? Don't block your threads if possible. Are you using a high level library or low level sockets?

Procasinator

I agree with srsly78. You don't need to think of this in terms of multi-threads/connections, but rather a protocol for all types of communication.

You should be able to tell what is a chat message and what is a game message. You only need the one point of entry for this (one thread, connection, etc), and it can process the request and dispatch to the responsibility to the appropriate handler.

Having 2 threads accessing the same shared resource (network connection) directly is bound to complicate your system.

fasty

If you use a thread pool, a thread from the pool could handle the request as soon as it came in so your sender/receiver threads wouldn't block and would be ready to receive more connections.

Or if you have access to some higher level job/task library in Java (Like Task Parallel Library in C#.Net and GCD in C/ObjC) you could just farm out the work that way.

Pygmalion

Call Me Jimmy wrote: »

How is it possible to send Strings back and forth over the network AND send game updates
even if they are in different threads? Each client has one socket connection... this is fine in the chat app where it only reads and write strings and only expects this but what happens when, while one thread is waiting for the next string in the chat box and another is waiting for a game update, no text is entered to send in the chat box and the game update is sent. Then the thread waiting for a string could possibly read the game update from the connection stream and produce an error.

So you have two Threads?
Say ChatThread and GameThread, for arguments sake.

I wouldn't have them both wait on the socket, but have a third thread (e.g. ListenerThread) wait on the socket, then when it receives a message it should decide whether it's a Chat message or a Game update and then pass it on to the appropriate thread somehow.
e.g. You could have listener thread add the messages to one of two (thread-safe) buffers and have the ChatThread and GameThread wait on them rather than on the socket directly.