Network Game Engine

Networking & Multiplayer
#21

Yes, actually the SuperSerialization API is my own, it’s not at all related to the jdk’s serialization what-so-ever. And yes, you can send only part of the game world if you want by writing only those objects, you just have to make sure that the rest of the game-world isn’t dragged into it by flagging which objects should not be written (using the SSObjectOutputStreram.writeObject(Object obj, ArrayList ssObjectsToIgnore) method). That’s why the SS streams are pretty cool (IMO :slight_smile: ) Right now I’m not doing that for anything except for events, like firing a missile - I send only the missile object without the whole game world, the missile’s reference to the game world is not written to the stream but is assigned to the existing game world. To minimise traffic when I do sync the client and server game worlds by sending the whole thing, I just do it less frequently!

The SS streams are cool because you don’t have to write your own serialization for every game object, it’s all automatic so long as all of your game objects implement SSObject (or extend SSAdapter to get the default functionaility).

Fully sick! :smiley: 8)

So which version of the streams should I use to get the same behaviour as I’ve got currently - where byte arrays are only returned when the whole thing arrives. In other words, which of your API’s streams do all of the byte array book-keeping for me?

Thanks!
Keith

#22

None, that’s why it’s the core :slight_smile:

But are the buffers are turned into streams, prepending a length-buffer is trivial. Compare this to java.io.* Any protocol of your own would be written on top of it.

If you can’t make sense of it, I can write that next ‘layer’ later today.


public void write(ByteBuffer bb)
{
   ByteBuffer b2 = ByteBuffer.allocate(2);
   b2.putShort((short)bb.remaining());
   b2.flip();

   out.write(b2);
   out.write(bb);
}

int nextLen = -1;

public ByteBuffer read()
{
   if(state == READING_PACKET_LENGTH)
   {
      if(in.available() < 2)
         return null;

      int b1 = in.read() & 0xFF;
      int b2 = in.read() & 0xFF;
      nextLen = (b1 << 8) | (b2 << 0);

      state = ...;
   }
   
// ............

if......
   if(in.available() < nextLen)
      return null;

   in.read(ByteBuffer..........);
}

It might look like Kev’s algorithm, but this one has buffering under the hood, to make all NIO reads/writes in large chunks.

#23

That would be good. It might seem like a small thing but it’s really the main requirement in my case, and certainly my main gripe about other people’s network API’s.

Thanks :slight_smile:

#24

Sorry for not having posted the packet-code yet. I’m just home, after ~17h at work! School’s begining in a few weeks, so there are some silly deadlines :-\

#25

Finally…!

url=http://www.songprojector.com/static/riven_nio.jar[/url] url=http://www.songprojector.com/static/nio_riven_doc/[/url]

Greatly simplified. Many times more efficient.

The base is the StreamBuffer, in which you can read what was written to it.

  • the socketchannel writes to streambuffer 1, the user can read from it
  • the user writes to streambuffer 2, the socketchannel can read from it

Layering the packet-support on top of it, was only a few lines of code.

It should be stable, but I’d like to hear when it isn’t :slight_smile:

#26

To explain it a bit further:


PacketStream stream = ((PacketStream)client.attachment());

ByteBuffer packet = stream.readPacket();

stream.writePacket(ByteBuffer packet);

There’s nothing to it! :slight_smile:

#27

Thanks Riven, I’m going to hook up your API to my framework tonight.

By the way, thanks for including the source in that Jar file as well as the classes :).

Keith