Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  SocketChannel vs Socket and Serializable question  (Read 7184 times)
0 Members and 1 Guest are viewing this topic.
Offline zero

Junior Duke





« Posted 2002-11-06 14:15:20 »

hi all,
i'm wondering, whehter a client-server game archicteture needs java.nio.channels.(Server)SocketChannel(s) for a high performance ?

how about your experience ? are a non-blocking connection,.. a must be or not ?

second question is about serialization:
why is an is an object-reference only serialized ones, calling ObjectStream's write/readObject methods several times ? is there a way to overcame this ?
(I create a new instance of a 'message-class' containing only a reference to the real data object to avoid huge memory allocs, but it looks like a hack for me..)

greets
-Michael Nischt
Offline markuskidd

Junior Duke


Medals: 1



« Reply #1 - Posted 2002-11-06 17:49:26 »

If you call flush() and then reset() on your ObjectOutputStream, you can resend the same object.
Offline zero

Junior Duke





« Reply #2 - Posted 2002-11-06 20:50:25 »

thanks a lot Smiley - tried flush but not reset..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #3 - Posted 2002-11-07 06:48:45 »

I currently do a network system for a distributed simulation action game based on nio.channel.

This is particularly nice for the non-blocking/selector stuff (handling 2 threads on a server is error-prone enough!) and the use of ByteBuffers, which I feel are VERY handy for setting up custom messages.

I didn't go for serialization bc. the overhead is huge and the gain is minimal. Typically, for a game, the messages send are flat value objects which can very easily be serialized/deserialized by hand.

I struggled to minimize bandwith usage fighting for every byte not to send, so serialization (that sends complete classnames AFAIK) would really hurt me!

Without bandwith/latency worries, RMI would have been my friend, which IMHO is one of the nicest features bases on serialization.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #4 - Posted 2002-11-07 06:55:46 »

Quote
why is an is an object-reference only serialized ones, calling ObjectStream's write/readObject methods several times ? is there a way to overcame this ?
(I create a new instance of a 'message-class' containing only a reference to the real data object to avoid huge memory allocs, but it looks like a hack for me..)


I didn't get that. You want to ENFORCE multiple serialization on the same object? One of the key features of ObjectStreams IMHO is that they AVOID exactly that!?

What about serializing with a local ObjectOutputStream to a byte array and doing the actual network transmission with a DataOutputStream ot ByteArrayOutputStream? Or an nio.channel?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline markuskidd

Junior Duke


Medals: 1



« Reply #5 - Posted 2002-11-07 14:52:28 »

Quote


I didn't get that. You want to ENFORCE multiple serialization on the same object? One of the key features of ObjectStreams IMHO is that they AVOID exactly that!?

What about serializing with a local ObjectOutputStream to a byte array and doing the actual network transmission with a DataOutputStream ot ByteArrayOutputStream? Or an nio.channel?


I've actually never had a situation where I *didn't* want it to be reserialized. If I'm trying to send the object again, it's because I have chosen to darn it! Cheesy I'd be interested to hear what the applications are where you would call writeObject() but you wouldn't want to researialize if you had already sent it.

What you have written about serializing to a byte array would work, but just calling flush() and reset() will avoid that extra work to get the object out the door.
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #6 - Posted 2002-11-07 15:08:04 »

Quote


I'd be interested to hear what the applications are where you would call writeObject() but you wouldn't want to researialize if you had already sent it.


That's typically the case when you are serializing object networks where more than one serialization path meets a certain subobject. Then you won't have to send it again and thereby loose it's identity, so the object network cannot be reconstructed on the receiving side.

Just imagine serializing an object with a member object  that holds a reference back to the one you start with. Without the ObjectOutputStream mechanism the serialization progress would end in an endless loop/recursion!

That's also why people often noted that ObjectOutputStream have to be reset() after use in order to avoid memory leaks. Until reset(), OOS holds references to the objects it serialized!

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #7 - Posted 2002-11-07 15:12:19 »

Oh, excuse me, after reading your post twice - yes, you're right.

Calling writeObject() explicitely multiple times will have re-serialization in mind in most cases.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline markuskidd

Junior Duke


Medals: 1



« Reply #8 - Posted 2002-11-07 15:50:09 »

That's an interesting situation, and as I figured, not one I have had to deal with yet...

So say you've got

class Building which contains a reference to class Street, which you send to a client using Serialization. Later on, you're sending class City which also has a reference to that Street you sent earlier. The serialization mechanism realizes it has already sent this Street and therefore just sends some kind of ID which is interpreted on the client side and the reference is pointed to the Street which was sent earlier? That's pretty neat.

But in general, how often is it the case that objects whose states do not change are being sent through serialization? I'm trying to think of areas that are the farthest from my experience, but I can't think of any where the default behavior would make sense to be "if the client code calls writeObject on a reference that has already been written, do nothing," rather than "if the client code calls writeObject, write it." Do you know why this is not the default behavior of serialization?
Offline rreyelts

Junior Duke




There is nothing Nu under the sun


« Reply #9 - Posted 2002-11-07 19:39:41 »

Probably because writeObject is written in terms of itself, so it can't distinguish a first client call against another internal call. You certainly don't want to write multiple copies of the same object out to the same stream on the same invocation.

God bless,
-Toby Reyelts


About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #10 - Posted 2002-11-07 19:52:14 »

This kind of OOS is meant to be able to transmit even highly complex object graphs. So you can have the whole city with references on buildings an streets, the buildings pointing to streets, the streets keeping collections of theire buildings and the city they belong to.....

This the very fundamental task of the OOS.

The ONLY behaviour how this can be accomplished is be NOT serializing multiply referenced objects! For that, it is not so important wether writeObject() is called once by the client or in some portions. I assume that writeObject() is used also internally during serialization of the graph. The OOS has to keep an internal state until someone tells it to give it up -> reset().
So the fundamental reason for its being causes its default behaviour.

I think you too much have the sending of a single, flat object in mind when thinking of network transfer, bc. thats what games typically do. Think more in the context of RMI, where who-knows-what can be an argument of a function call, and such.

For sending flat messages only, serialization and OOS would not have been invented. There are easier means to perform that.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline markuskidd

Junior Duke


Medals: 1



« Reply #11 - Posted 2002-11-07 20:44:10 »

I follow what you're saying about flat objects, but are most applications really not going to have objects that change state that need to be resent? I'm just trying to understand the "why", I've a good grip on the "what." It seems to me that write object should have to forms, like serializeObject() and writeObject() so that you could take advantage of both scenarios... it seems like if, to continue with that example, one of the buildings was altered, the only real way to send it would be to make a new Building with a copy constructor and send that (if this was happing often, could be a big slowdown) or to call reset()... but if you used reset() then your Building's reference to the street would cause the entire city to be resent.
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #12 - Posted 2002-11-08 10:50:30 »

Hm, yes, I see. Don't have a true clue to this.

I imagine the inventors did not have in mind to implement a shared object state. They just wanted to be able to transfer complex objects at a given state, not keeping track of that state over time.

Maybe an additional method like updateObject() would be nice, that transmits the stored reference as well as the changed content...

They key point of my growing network system is exactly that of keeping track of objects identities in a shared environment....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2002-12-10 01:01:32 »

Without nio.* and nio.channels.*, you are pretty much limited to a game server that can only handle 100-350 client connections (note: e.g. Windows 2000 DIES HORRIBLY with more than a few hundred threads. Not gracefully; HORRIBLY)

This is standard behaviour for most OS's - java's NIO stuff is largely just providing access to the same mechanisms that EVERYONE else uses to write server applications in other languages. Note, different OS's have highly different strategies (implementations, APIs etc) for achieving large numbers of opne sockets) - for a long time there was good reason to believe that Java would never get an NIO-type package because the common functionality doesn't exist across platforms. This is one biiiiig reason why NIO is so infuriatingly buggy in 1.4 - because in many cases the underlying OS-proferred API's are very different, and it is a pretty horrendous task trying to make them all act the same way Sad.

[This is a gross over-simplification Smiley intended for people who don't have the time to go and learn about the details - if you want to read up on it, look for "select()" based schemes (often found in Unix) and "completion sockets" (I think?! - found in Windows). There's at least two other ways of doing things in Unix, apart from select() (which seems to have inspired  NIO), but I cannot remember names off the top of my head.]

malloc will be first against the wall when the revolution comes...
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.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (35 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!