File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Serialization in multi-player game Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Serialization in multi-player game" Watch "Serialization in multi-player game" New topic
Author

Serialization in multi-player game

Alfonso Moreno
Greenhorn

Joined: Jun 23, 2003
Posts: 6
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
"The Hood"
Sheriff

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

"JavaRanch, where the deer and the Certified play" - David O'Meara
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
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
Greenhorn

Joined: Jun 23, 2003
Posts: 6
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)

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
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Hmmm. One thing I notice is that the broadcast method buries any exceptions that may arise.

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
Greenhorn

Joined: Jun 23, 2003
Posts: 6
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
Greenhorn

Joined: Jun 23, 2003
Posts: 6
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
Greenhorn

Joined: Jun 26, 2003
Posts: 17
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Serialization in multi-player game
 
Similar Threads
Very strange behavior in Socket Server
What comes out of the ObjectOutputStream is not what goes into the ObjectInputStream
Implement Serializable judiciously?
What comes out of the ObjectOutputStream is not what goes into the ObjectInputStream
Eclipse applet vs web applet network performance