So, I'm trickling through this network layer for the latest prototype. I've pretty much decided to make it available as a new library after it's up and running, support it like Slick and Phys2D through the forums - hopefully find the bugs and API issues quickly that way. I realise JGN exists, I've used it, never really felt comfortable when integrating with my stuff - now I've been prodded so many times to writing some networking library for Slick, pointed people at JGN. They're still prodding so I guess I'm going to write it and probably get it in the neck from all sides. Now, I'm going to prattle on about the library development here - feel free to switch off or turn to another channel...

Still here? Wow.

So some of the goals of the new library are:

a) To provide a quick way to get syncrhonization of some game data between clients
b) Integration with the existing data model in that you don't need to convert your game model into a network model
c) Pluggable delta application (more on this later)
d) Pluggable transport

Since I already have some code running I'm slowly morphing the existing stuff into this library. The first bit I'm looking at is abstracting out the transport. I've never felt the need in this recent game to work in anything but TCP. However, generically thats not the case and for prototyping purposes it'd be nice to be able to switch between the two and try stuff out.

So, I have a stream based API at the moment. On top of that I layer a packet/message system. Stupid huh? The real question is how to game developers want to work, do they seem streams or do they seen discrete packets? I think I've always worked with packets (apart from for stream resources - which isn't what this API is for). Why is this imporant? If you're abstracting UDP and TCP into transport layer you can either:

a) Go stream based, use TCP and emulate it over UDP by combining packets
b) Go packet based, use UDP and emulate it over TCP by encoding discrete packets with their length

Note that this isn't to do with order/unordered or reliable/unreliable. That comes off the interesting bit is whether we think in packets or streams. This API is going to be packet based. The other bit that I've just looked at (which is what this blog post was meant to be about) was reliable transit over UDP.

I wanted to use a NACK approach, i.e. negative acknowledgement, if you recieve a packet and you're waiting for one before it you send a NACK for the one you're waiting for. On recieving a NACK you resend the requested packet. This has the potential to be much lighter on the network but had issues
at connection time. I'll probably need to revisit. So I've fallen back onto the standard ACK approach, i.e. send packet and keep resending (at a fixed interval) until you get an ACK for it. Seems like it'll get heavy on the network bursts but limited how far you write resends should keep congestion under control.

As a user they'll be several levels at which you can interact with the system:

1) You'll be able to open a transport channel or server directly and send/recieve raw data
2) You'll be able to send "Message" objects back and forth. Things that'll be able to encode themselfs
3) You'll be able to send normal java beans back and forth
4) You'll be able to add objects to a "network space"

The network space bit is the one thats interesting me at the moment. In physics land I have an "CollisionSpace", you drop bodies into it and the physics and collision takes place. In my entitiy engines I normally have a "GameSpace", a space in which the game entities get dropped and which is updated to cause the interactions. Most cases recently have had me having a CollisionSpace held in the GameSpace in which the physical world interacts.

The NetworkSpace takes this same route. You drop your networkable elements into the space, update it and the underling network attempts to syncrhonize them. I like this idea alot though I've seen it implemented before in several places, I've never felt in control of how updates are applied. Thats where this "pluggable delta application" comes in.

Guess thats for another day though, this blog post is already too long