Serialization in multi-player game

[Alfonso Moreno]

Hi, all
I'm currently developing a multi-player card game, based on Server-Client architecture.
The Server controls a "hall" which has 8 "tables". This setup is stored in a class named CS, which implements Serialization.
Every time a client gets into the hall, the server sends if the current state of CS, via serialization. The client receives the object properly. Then, when the client gets into a table, the Server sends every user the refreshed state of CS. But what the clients received is just THE SAME OBJECT they had received for the first time, despite the fact that the CS object has been refreshed properly.
It seems like the clients thread don't 'flush' their ObjectInputStream after they execute readObject().
The CS object is created only once, and it's updated by a thread, but I think only one CS object exists at the same time.
Sorry if the answer is too obvious, but I'm really stuck. If you need some more information, please make me know.
Thanks in advance.

[Cindy Glass]

Moving to the hmmm . . . . IO forum? No let's try the Threads forum.
[ June 23, 2003: Message edited by: Cindy Glass ]

[David Weitzman]

Are you maintaining a persistant connection with a single ObjectOutputStream? If so, you'll need to call ObjectOutputStream.reset() before you can send a different copy of the same object. Otherwise when you try to write an object more than once, the successive calls will simply send a message to the client that translates loosely to: "The next object is an object you've already seen before -- just use the old copy".

[Alfonso Moreno]

Hi David, thanks for your response, but, unfortunately it won't work. These are my classes and methods involved in the problem.
Most of the methods and classes have been omitted, since they can�t be the cause of the problem (unless I am completely wrong)

public class CS implements Serializable{
   ArrayList tables;
   CS(){
      //Construction of the array
   }
   public void update(int i, Table table){
      //Substitutes the i-th element of the
      //ArrayList
   }
}
public class Server{
   public static void main(String[] args){
      Server();
   }
   Server(){
      //Some variable initialization and creation
      //of a ServerSocket
      cs=new CS();
      while(true){
         Socket socket = server_socket.accept();
      Connection c=new Connection(socket,this);
      }
   }
}
public class Connection extends Thread{
   Connection(Socket socket, Server server){
      try {
            in = new ObjectInputStream(socket.getInputStream());
            out = new ObjectOutputStream(socket.getOutputStream());
      }catch(IOException e){}
      start();
   public void run(){
      /*Checks requests from the clients. When a user wants to get into a table... */
      server.cs.updateMesa(indiceMesa,tgtMesa);
      broadcast(server.cs);
   }
   synchronized void broadcast(Object obj){
      //For every user...
      /*thisClient represents the Connection pointing to a user, and userlist2 an ArrayList containing all the users */
      try{
         thisClient.out.reset();
         thisClient.out.writeObject(new Comobj(obj, userlist2));
         thisClient.out.flush();
      }catch(IOException e){}
   }
}
public class Comobj implements Serializable{
   Object myObject;
   ArrayList users;
   Comobj(Object obj, ArrayList users){
      myObject=obj;
      this.users=users;
    }
   public Object getObject(){
       return myObject;
   }
}
   
public class Listener extends Thread{
   /*Every client creates an instance of Listener. An ObjectInputStream in is created in the constructor*/
   public void run(){
      while(true){
         comobj=(Comobj)in.readObject();
         Object obj=comobj.getObject();
         //Do some stuff with obj
   }
}

The first time Listener executes readObject, it works fine, but the second time it retrieves the same Object(it should retrieve the new state of the hall, contained in the CS object, which has been properly modified with server.cs.update(...))
I have also reset the ObjectInputStream once the block of code in Listener has finished, to no avail.
Sorry if the explanation is too short or too long
Regards

[David Weitzman]

Hmmm. One thing I notice is that the broadcast method buries any exceptions that may arise.

try {
   // ...
} catch(IOException e){
   e.printStackTrace();
}

I mention this because if an exception does occur and you fail to take note of it then calling broadcast() would fail to send updated data, perhaps for a perfectly good reason, without you ever knowing. Inserting a log statement in the Listener while() statement that prints out a message along the lines of "A new object arrived. Here's some useful descriptive info: <blah>" might assist the debugging process.
Does the listener.run() loop exist entirely on its own (with a sequence of read, do, read, do) or are there other threads working on the client side that share some of the same data, like "comobj"?

[Alfonso Moreno]

Thanks again, David
I didn`t include any code in the catch block in the interests of clarity, but every possible exception is managed, and every IOException causes the socket to close, but this doesn`t occur.
There is also a typer thread in client side, which sends requests and messages to the server through a Comobj object, but, like Connection, it creates a different Comobj each time, and it doesn't use the same Comobj constructor. It uses another one, which doesn't modify the Object variable in Comobj.

[Alfonso Moreno]

Hi, David
Thanks for your time and efforts. I've found out the solution. A new ObjectOutputStream in the server side and a new ObjectInputStream in the client side must be created every time a communication is performed.
You can see a "draft" code of the solution at

[Scotty Sinclair]

There may be other possibilities too,
for example you could clone the object which is about to be sent, it would then be recognized by the stream as a different object.
But the best approach could be ObjectOutputStream.writeUnshared(Object obj);, this method guarantees that the object is rewritten to the stream even though it may have been previously sent. I haven't used this personally, but I remembered reading up on it in the javadoc.