Architecture Brainstorming

Today, we are going to spend a lot of time developing a candidate architecture for P2P communication, and hopefully starting to code once we've figured this out. 

Our coding goals by the next SGM (Tuesday, 3/4) are:

• Getting one queue to sync with the queue on another phone

• See the same universal library

In considering strategies to connect between the phones, we are looking at two different approaches. 

The first one is to use the built-in iOS 7 Multipeer Connectivity feature described here. The below picture describes a system using an Audio Queue, to which each phone will send data using NSOutputStream and NSInputStream. 

The blue boxes in the diagram below represent the shared queue into which all connected devices input their music. The white box at the bottom represents the master device that plays music.

Our second idea is to have a system with an intermediate server. Every time someone adds a song to the queue from the universal library, we would somehow extract the media data from the MP3 (MPMediaItem) and encode this audio data with JSON and send it to the server (we think this is possible because one of our friends did something similar in an internship. But we would have to look into this further.)

Once this data is in the server, the phone connected to the bluetooth could query the server for the next song (based on a SQL command). Then, the JSON audio data would come down to the connected phone, which could convert it into an MPMediaItem or some other audio file format (perhaps an AVMediaItem). 

Pros of the iOS multipeer system:

• Although very new, this is a fairly well-documented system, and we have a lot of already-written code that we can use to make this work
• It is theoretically faster than a server-based system, because we would go straight from phone to phone instead of using an intermediary server
• Likely to be easier to achieve MVP using this model

Pros of the server system:

• We don't have to deal with low-level issues like packets and byte streams
• We can organize and query for the songs with simple SQL commands - less needs to be stored on the phone
• The host-guest model wouldn't need to switch around as much since everyone always pushes to the server, which is treated as the master source of all media data
• Fewer assumptions about iOS7 requirements: scalable for making our application functional on multiple platforms (e.g. Android)

Because there is more code and support available for the iOS7 multipeer system, we are going to start with this today. If we run into too many issues with the low-level code, then we will probably switch over to our server idea.