ReadableByteChannel & ObjectInputStream

[vrm]

I'm trying to use a ReadableByteChannel and a  damn ObjectInputStream fropm serverside trying to read a serialized object (an array of object parameters) sent by a client
the client simply write the object to a socket :

ObjectOutputStream oos=new ObjectOutputStream(socket.getOutputStream());
oss.write(new Param(arrayOfObjects)); // write my objects to the network

From the server side, I use selectors & keys, when I recieve my first read key, i'm
recieving a 4 bytes ByteBuffer !?, how nasty is this ObjectOutputStream ?

of course when I try to read the 4bytes with an ObjectInputStream I got an header exception

I start to think java  serialization & network aren't that friends, you know alternatives ?

[blahblahblahh]

I'm trying to use a ReadableByteChannel and a  damn ObjectInputStream fropm serverside trying to read a serialized object (an array of object parameters) sent by a client
the client simply write the object to a socket :

ObjectOutputStream oos=new ObjectOutputStream(socket.getOutputStream());
oss.write(new Param(arrayOfObjects)); // write my objects to the network

From the server side, I use selectors & keys, when I recieve my first read key, i'm
recieving a 4 bytes ByteBuffer !?, how nasty is this ObjectOutputStream ?

of course when I try to read the 4bytes with an ObjectInputStream I got an header exception

I start to think java  serialization & network aren't that friends, you know alternatives ?

1. Are you sure the server isn't in non-blocking mode? That would explain why you received very little data in your first read...

2. WTF are you trying to do this? If you want to transfer objects, 99% of the time you're better off using RMI (and it's got a lot of useful features!). I know lots of people who are genuinely in the 1% situation (e.g. people who've needed more efficient implementations) but they tend to be pretty hard core situations. I'm not saying you definitely shouldn't be doing this, just that you *probably* shouldn't be .

3. There are numerous documented (by Sun,usually in the API docs, usually quite in-your-face) incompatibilities with serialization between different VM versions. Are your client and server both using EXACTLY the same JVM version? e.g. 1.4.2_04, not merely 1.4.2, nor 1.4.x

[blahblahblahh]

I start to think java  serialization & network aren't that friends, you know alternatives ?

1. RMI (it's part of java, look in the API docs)
2. Don't use serialization (it's overkill for many situations); either use a purpose-built network protocol (e.g. for games you normally need a UDP-based network protocol, not a high-level niche system like java's built-in serialization), or create a simple custom protocol of your own.

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

[vrm]

yes I'm in non-blocking mode and thats why  

well got the same JVM on server & client side, but I'm going to kick serialization out, I just need it for big objects transfered 1 time like maps. I'm going to write my own externalization code for those, rest is mainly integer,strings and little basic types

[blahblahblahh]

yes I'm in non-blocking mode and thats why  

well got the same JVM on server & client side, but I'm going to kick serialization out, I just need it for big objects transfered 1 time like maps. I'm going to write my own externalization code for those, rest is mainly integer,strings and little basic types

Make sure you add either an explicit "this object takes up the following N bytes in the stream" or an explicit "End-of-object" symbol in the stream. That way, with NIO, you just keep reading and checking whichever of those you chose until you've read in enough data that you KNOW you can deserialize the object (I mean "deserialize" in a general way, not specifically using JDK serialization).