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


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.

Abstract:

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 

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:

Venue

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:

  • LOGIN
  • LOGOUT
  • SUBSCRIBE
  • UNSUBSCRIBE 

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,

[packetlength][topic]=[payload]“, 

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.

Venue

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.

Venue

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.

Venue

More information about this project may be available on request. For more information, please contact me by emailing andy@andymillar.co.uk.

Leave a Reply