Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  very strange behaviour  (Read 1530 times)
0 Members and 1 Guest are viewing this topic.
Offline HamsterofDeath

Junior Member




Java games rock!


« Posted 2004-08-28 20:43:17 »

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 ?
Offline tom
« Reply #1 - Posted 2004-08-28 22:32:41 »

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.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #2 - Posted 2004-08-30 01:10:23 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline HamsterofDeath

Junior Member




Java games rock!


« Reply #3 - Posted 2004-08-30 09:56:55 »

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 ?
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2004-08-30 10:26:11 »

Quote

"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.

Quote

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).

malloc will be first against the wall when the revolution comes...
Offline abies

Senior Member





« Reply #5 - Posted 2004-08-30 10:44:43 »

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.

Artur Biesiadowski
Offline HamsterofDeath

Junior Member




Java games rock!


« Reply #6 - Posted 2004-08-30 11:38:19 »

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.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2004-08-30 12:16:30 »

Quote
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...

malloc will be first against the wall when the revolution comes...
Offline HamsterofDeath

Junior Member




Java games rock!


« Reply #8 - Posted 2004-08-30 15:30:14 »

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. Smiley
i'm not using any immutable objects.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2004-09-01 00:22:12 »

Quote
No, people DON'T want that.


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

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (37 views)
2014-07-18 06:55:21

Zero Volt (35 views)
2014-07-17 23:47:54

danieldean (28 views)
2014-07-17 23:41:23

MustardPeter (31 views)
2014-07-16 23:30:00

Cero (46 views)
2014-07-16 00:42:17

Riven (47 views)
2014-07-14 18:02:53

OpenGLShaders (36 views)
2014-07-14 16:23:47

Riven (36 views)
2014-07-14 11:51:35

quew8 (32 views)
2014-07-13 13:57:52

SHC (69 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!