Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (592)
Games in Android Showcase (168)
games submitted by our members
Games in WIP (645)
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  
  new serialization classes  (Read 1585 times)
0 Members and 1 Guest are viewing this topic.
Offline Nate

« JGO Bitwise Duke »

Medals: 164
Projects: 4
Exp: 14 years

Esoteric Software

« Posted 2011-05-21 11:39:36 »

I've had a binary serialization project called Kryo for a while now. Kryo has the idea of a "serializer" which, for a specific class, knows how to go from an object to bytes and vice versa. Kryo also has a way to register serializers for a type. Using these two ideas, serializers can be written to serialize any object graph in various ways. Eg, FieldSerializer uses reflection to do serialization in the same way you would if you were hand writing code using DataInputStream/DataOutputStream.

Kryo originally started as a contribution to the JGN library and later got rewritten for KryoNet. Both are NIO networking libs, so Kryo uses ByteBuffer to write/read to/from. This causes problems when trying to do serialization with streams. To read from a stream, it has to be copied into a ByteBuffer, at which point you aren't really streaming any more. To compound this problem, ByteBuffers do not grow, so you must allocate a large enough buffer beforehand. I would like to rewrite Kryo and remedy these problems (as well as a few other unrelated issues).

Most of the time you don't need random access for serialization and a stream works just fine. However, occasionally you need it, eg to write a length and then some data. If an object's field is compressed with deflate, you might want to compress the data for the field, write out the number of compressed bytes, then write out the compressed bytes. You might do this by skipping a few bytes and then coming back later and filling in the length. This isn't possible with a stream, so some sort of buffering is required. Another way might be to write the serialization and compression of the field value to a separate buffer and then copy it. A copy isn't ideal and neither is having many (potentially very large) scratch buffers.

I came up with an idea for a hybrid stream/buffer monster. A class called WriteBuffer has methods similar to DataOutputStream and writes bytes to a byte array. When the byte array is filled, it is processed (eg, written to an OutputStream) and then reused. You can set any number of "marks", write some bytes, and then later jump back to a mark. A mark prevents the byte array from being processed and reused. Instead, if the byte array is filled while a mark is set, an additional byte array will be allocated. Once the marks are used, the filled byte arrays are processed and reused. This ArrayList<byte[]> mechanism for growing the buffer without a copy is used in PyroNet and Netty, WriteBuffer just adds processing/marks to the idea.

WriteBuffer itself doesn't actually process the bytes arrays, it will just keep allocating more byte arrays as they are filled. OutputStreamBuffer extends WriteBuffer and writes the byte arrays to an OutputStream as they are filled. If no marks are ever set, a single byte array will be continuously reused and the OutputStreamBuffer acts like a BufferedOutputStream. NIOWriteBuffer extends WriteBuffer and writes the byte arrays to a ByteBuffer (a better name is welcome... ByteBufferBuffer? maybe rename WriteBuffer?).

Another class called ReadBuffer is similar to DataInputStream and reads from a byte array. When the byte array has been completely read, it is refilled and reused for more reading. Similar to WriteBuffer, marks can be set, so instead of the byte array being refilled and reused, a new byte array will be allocated and filled. This allows you to jump back and read the same bytes again.

ReadBuffer itself uses a single byte array as a data source. InputStreamBuffer extends ReadBuffer and fills the bytes arrays using an InputStream. NIOReadBuffer extends ReadBuffer and fills the bytes arrays using a ByteBuffer.

I've written some code for the above, you can check it out here:
All the files in that package are the new stuff, files in other packages are the old Kryo stuff. No javadocs yet!

Do you guys have any feedback on this buffer/stream idea? Maybe there are alternate/better solutions? I want to make sure I'm headed in a decent direction before going off and building lots of stuff on top of this foundation.

Offline Riven
« League of Dukes »

« JGO Overlord »

Medals: 1000
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #1 - Posted 2011-05-21 11:59:55 »

The problem of writing 'packets' of undetermined length has been long solved: chunked encoding.

You basically prepend a 'length' integer before *any* write you do. A length of 0 means you reached the end of the 'packet'.

So instead of this:

You'd do:

Surely there is some overhead, but it allows for unbuffered streaming (both reading and writing) of unknown-length packets.

Needless to say, you can easily nest this encoding.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Nate

« JGO Bitwise Duke »

Medals: 164
Projects: 4
Exp: 14 years

Esoteric Software

« Reply #2 - Posted 2011-05-23 11:33:40 »

Thanks Riven! You're right, I can use chunked encoding where I need to first write a length and use a stream everywhere else. Currently I have KryoByteArrayInputStream/KryoByteArrayOutputStream that are similar to DataInputStream/DataOutputStream but with more serialization methods and they work on a byte array rather than wrap another stream. I extend these to make KryoInputStream/KryoOutputStream and KryoByteBufferInputStream/KryoByteBufferOutputStream that fill or empty the byte[] to another stream or ByteBuffer as needed. Buffering the data in the byte[] makes it fast.

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

Za\'Anzabar (15 views)
2015-06-29 05:44:54

TritonDreyja (31 views)
2015-06-24 17:10:40

CopyableCougar4 (27 views)
2015-06-23 00:34:45

BurntPizza (32 views)
2015-06-21 20:36:46

cookiecompiler (74 views)
2015-06-11 15:42:53

cookiecompiler (38 views)
2015-06-11 15:41:14

NegativeZero (63 views)
2015-06-11 09:49:18

Fairy Tailz (88 views)
2015-06-11 01:59:47

chrislo27 (60 views)
2015-06-06 18:12:44

Burnsalan20 (72 views)
2015-06-05 03:00:51
How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14 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‑
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!