Archive for January, 2008

Venue, a 3D virtual multimedia environment built upon publish/subscribe networking

Sunday, January 6th, 2008

Venue, a 3D virtual multimedia environment built upon pub/sub (publish/subscribe) networking, was developed by Andy Millar, Jack Griffith, Sean Lavelle, Jee Heng and Marten Mark and supervised by Dr Paul Kelly.


The Publish/Subscribe architecture is a well known model that allows for greater scalability due to message filtering which reduces network traffic. One of the network platforms normally associated in investigating this concept would be the massively multiplayer online game. At the same time, the increasing popularity of video conferencing applications has led our group to examine the possibility of integrating these two very different concepts together.
The main aim of this project is to explore the potential for the Publish/Subscribe model to support such an application. By presenting our Performance Analysis results and demonstrating the features and benefits of our multimedia conferencing platform prototype, we have created a proof-of-concept application that supports the notion of the Publish/Subscribe model, one which could possibly have a commercial demand.


Venue, pictured above, is a Proof of Concept application created to demonstrate that publish/subscribe is a viable network architecture for multimedia conferencing including real-time audio and video. This is in no-way a completed product, merely a demonstration of what is possible.

There were two main goals of the project:

  • Produce a working proof of concept application.
  • Produce sufficient performance analysis data to identify if pub/sub is a viable solution.

The project was broken down into multiple components:

  • Broker: responsible for managing subscriptions and routing packets between clients.
  • Client: user-interface to demonstrate the capabilities of the system.
  • AI: framework for performance analysis of both the protocol and the implementation.

The components fit together as shown below:


The broker, which I was responsible for developing, implements a general pub/sub protocol that is non-application specific. This means that any application able to implement this basic protocol would be able to use the broker.

The broker understands 4 packet types:


Any other packets are treated as “user” packets and are published based on rules defined by the above packets. The packet has the following format,


where packetlength is a static 6 bytes long and counts the number of bytes remaining to be read from the socket to fully read the rest of the packet and topic is in the form “,entry[,entry[…]]“.

With the exception of the above 4 packet types, the broker will never examine the payload of a packet. This is ideal as it allows clients to publish any form of data in any format, for example the proof of concept client publishes zlib compressed video data.

To take full advantage of the publish/subscribe concept the client (and AI) broke the world down into small areas, named cubes. As the client moved around the map, it would modify its subscriptions to ensure that it received data from the correct cubes.

The project was a success. As you can see below, we were able to render multiple clients with real-time audio and video onto a relatively large map. There was no significant performance degredation as the number of clients increased during our user-testing.


Since we were able to produce a working multimedia conferencing application we then moved onto our second and final objective, the performance analysis.

Since Dr. Paul Kelly is the groupleader of Imperial College London’s Software Performance Optimisation group, it came as no surprise to us that performance would be involved at some point. Given a throughput target of 50,000 packets per second, the AI kicked into gear and we saw how it performed.


We managed a peak throughput of roughly 20,000 packets per second with optimal parameters. We were later told that the target of 50,000 packets per second was a little optimistic.

We also benchmarked the effectiveness of the pub/sub protocol with varying cube size. The graph below shows the proportion of administrative (subscribe/unsubscribe) packets compared to the total number of packets processed by the system.


More information about this project may be available on request. For more information, please contact me by emailing

New Blackberry PIN

Wednesday, January 2nd, 2008

Ok. My previous phone handset developed a fault with the scroll wheel. Apparently this is a fairly common fault with the Blackberry 8700.

Orange kindly arranged next day delivery of a replacement on New Year’s Eve. Sadly it seems that the courier was unreliable, and didn’t show up. The courier was rearranged for today and the replacement handset has arrived. Kudos to Orange for their swift resolution of handset problems.

The downside of this is that I have a new Blackberry PIN.

My new PIN is: 25241539