C3N Play Network Module

Notice: This is an old article from my years at university. As far as I know, my contribution to the project has been replaced by newer technology, so I'm in NO WAY saying that I'm part of the project anymore.

Mälardalen University, 15 ects, Spring semester 2010.

Keywords:

  • iPad/iOS
  • Objective C
  • C++
  • C
  • BSD Sockets
  • Bonjour/ZeroConfig
  • Open Sound Control (OSC)
  • Xcode
  • Mac OS X

The Project

I was asked to design and implement a network model for a project named C3N Play (back then it was known as C3LOOPS). C3N Play is a collaborative multimedia application, used by DJs and VJs to do live performances, using iPads.

Prior to this project - I had a very limited experience of network programming (one single course at university). So I was a little hesitant at first; then I decided that nothing is more encouraging than a challenge - so I started to learn more about network models, Bonjour/ZeroConfig, collecting data from non-blocking sockets, and more.

The list of requirements was quite short; but here are some examples. One of the requirements I added myself - was “efficiency”. The iPad has a limited amount of RAM - so I decided to design the network module in a memory efficient manner.

  • The solution should be based on Open Sound Control (OSC)
  • The model should support clients connecting and disconnecting during a performance (think “Live set”).
  • Changes made on one client should propagate to other clients, connected to the same server.

A short summary from the report

A network model

The C3N Play Network Module (which I named C3Network) is part of the C3N Play project, owned by Rikard Lindell, Mälardalen University. The main goal of the network model is to enable several C3LOOPS users to use the system collaboratively, using iPads and/or Macintosh computers. The C3Network module is built using the UDP protocol for data transfer, and Open Sound Control (OSC) as a data format/protocol.

Concept

The network model is based on the same network model that is used in the classic FPS game Quake III. It is, in a way, a form of “brute force” networking - that simply works. The reason I chose the Quake III network model to work with, was that it is optimised for low latency - something which is important in both live performances and FPS games.

The Quake III Network Model

The Quake III network model is based on an “aggressive” packet pushing concept; where data is sent continuously to the client - until the client sends an acknowledgement packet back to the server. When the server receives an ack, it only sends states newer than the last acked state of the client. If all clients have acked a state, the state data can safely be discarded on the server, freeing memory for future states.

Limitations

Since the packets may be lost at any time, all “important” packages should be acked. The problem is that the acks might get lost too. This means that no matter how many acks we send (acking an ack, and so on), we’re always risking a lost package - which would require us to resend all the data. Of course the risk of losing a package increases with the number of packages we send. (Since we’re using a wireless connection, it’s very likely that some packets are lost.)

It is therefore important to remember that important messages, like the status of a pushed button, should be sent frequently. If the only packet that tells the server that the button is pushed is lost, the server will keep doing whatever it was doing before, and the user will be upset. If we’re sending 100 packets each second telling the server that the button is pushed - we’d be almost certain that it’ll keep the correct state at the server too.

Result

Thanks to this project - I learned a lot about network programming. I also learned that network programming is FUN! (Although the debugging process is quite painful sometimes.)

The project owner’s summary described the implementation the following way:

“The implementation combined high reliability with good responsivity.”

I was satisfied with the result when I made the final delivery of the software, but getting a positive review of my work, made me feel even better.