very strange behaviour

[HamsterofDeath]

i got a serious problem:
i got a server and one client, each one running a gameworld. the clients sends a command like "i accelerate now". the server gets it, and tells the objects in his world what to do. then, he sends the updated objects to all connected clients - in this case, the command's sender.

the first time, it works well. the second time, the client gets the SAME object. by same, i mean oldobject==newobject. same reference. the one the client reads from his inputstream is the one he already has, which means the worlds are out of sync....

wtf is going on there ?
even wrapping the object in another one (a list for example) doesn't change anything.

i refuse to create thousands of new objects every second just because this stupid stream thinks he's clever...

what can i do ?

[tom]

How are you sending the objects from the server to the clients? Serialization with ObjectInputStream/ObjectOutputStream?

You could create your own protocol. Parse and update the objects yourself.

[swpalmer]

This is probably related to how Object streams are intended to be used.  When archiving state to a file, you want object references to work like that.

Games published by our own members! Check 'em out!

[HamsterofDeath]

i'm writing data into an object, then send it (objectoutputstream).
next time, i modifiy the data, and send the object again.
but the modified data never reaches the other side. not even the old data is send again, which would be caused by buffering.
the inputstream just gives me the same reference again.

"When archiving state to a file, you want object references to work like that."

if i save an object to a file twice, i want the NEW object to be in the file, not the old one.

how to solve this problem ?
use a simple outputstream and send a bytearray instead of an object ?

[blahblahblahh]

"When archiving state to a file, you want object references to work like that."

if i save an object to a file twice, i want the NEW object to be in the file, not the old one.

No, people DON'T want that. That would be disastrous. You're (unintentionally) abusing the API - it is designed for instantaneous saves, or "snapshots", i.e. you serialize "all in one go", then close the stream. It was designed for e.g. saving to disk, or sending a complete set of data in one go - you do NOT want the objects you're saving to change halfway through the save operation!

You are trying to use it as if it were a distributed communications layer, which is a much more complex beast.

how to solve this problem ?
use a simple outputstream and send a bytearray instead of an object ?

You could just close the stream and re-open it when you want to send a new snapshot.

Alternatively, you could try out one of the many distributed-object systems that sounds closer to what you actually want to do, rather than the API you are trying to do it with. For instance, look at RMI (built-in to java).

[abies]

Instead of closing/opening stream, you can just use objectOutputStream.reset(). Unfortunately, it will also flush immutable objects like Strings, so you will end up with retransmitting a lot of already sent data.

If this will prove to be a problem, you might want to reimplement OOS (read - copy/paste Sun version and hack it) and create extra method which does reset except Strings and possibly other application-specific immutables.

[HamsterofDeath]

rmi sounds like remote method invokation.
would be a bit like trying to kill a fly with a nuclear plasma blaster.

i just want to send an object, modifiy it, send the modified data and so on.

[blahblahblahh]

rmi sounds like remote method invokation.
would be a bit like trying to kill a fly with a nuclear plasma blaster.

i just want to send an object, modifiy it, send the modified data and so on.

Well, you could either research it and find out what you can do with it, or you could research how remote communication is normally done (no objects) or you could research DOA's (of which there are many, almost all of which are free), or ... you could just dismiss them out of hand and carry on trying to mis-use a different API (or, in your parlance, "trying to kill a cow with a fork and a steak knife"). Shrug.

Personally, I would either use HeadQuarter or send basic data rather than objects. I might even try ZeroC's Ice. But then again I have no idea what your game is like, so those suggestions could be useless for your particular game...

[HamsterofDeath]

sending raw data manually would be a lot of work...
every class...writethis, writethat, readthis, readthat...oh, thi class contains a list. what am i going to do now ?....

using reset() after sending an object did work.
i'm not using any immutable objects.

[swpalmer]

No, people DON'T want that.

Err..  I think you misinterpreted what I was saying.  I was arguing your point .  I.e. "you want it to work like it does work."