2 replies to this topic

[Metalhead]

Although I've been working with java for 10 years now, I've never written a server client application by myself.
I'm now trying to create a two-player game (like supaplex) where two clients can connect to a server.

I think there will be about 4 data-transfers per second from the clients to the server and 4 data-transfers from the server to the clients.

What I've created so far is the data-transfers from the client to the server, and this works well.

- I just don't know when the socket should be closed, or can I keep it open during the whole game?
In most examples I see that the socket is closed after the data-transfer, but I guess it would be very time-consuming to open and close the socket 4 times per second.

- For every client I use two threads that will communicate with the server (a controller thread and a view thread). Can both threads use the same socket, or will that cause problems?

[wim DC]

In your scenario I would also opt to keep the connection open. To me it actually sounds weird to constantly having to connect for the same game..

There is just something, After sending a lot of data, you may get an OutOfMemoryException. Take a look at this thread. There we had this issue, who knows, it may happen to you too. If the sockets stay open long and eventually send a lot of data.
http://forum.codecal...html#post291061

In case your server doesn't work with threads yet, it will have to.

while(true){

    Socket client = serverSocket.accept();  //Make sure you start a new thread from here, so you can handle multiple open connections.

}

I'm not sure about the multiple threads and 1 socket. I guess that for writing it doesn't matter much. For the server there is little difference from which thread the message comes.
But for reading, I'm afraid that thread1 may be reading stuff which thread2 was supposed to read, and thus thread2 won't be reading this message.
So, -just saying something here- if the server sends "Now go to view 2", then the view thread must read that, if it gets read by the controller thread, just because he's allowed to go first, then the view thread won't receive it...
Maybe create 1 thread to communicate, and let this thread decide to where the messages must go.

[Metalhead]

Thanks a lot for the response.
The view will only read data and the controller will only send data, so that shouldn't be a problem...
I was planning to make two threads for the server also, but until now I've only worked with one client.
I don't think I will encounter outOfMemory-errors, because I won't be sending much data; at this moment the controller is only sending one byte (the keyCode) and the data for the view will probably also be a few bytes per update.