Implementing a Multicast Audio Instant Messaging Application

1. Implementing a Multicast Audio Instant Messaging Application By: Charndeep, Chris, Keith

2. Introduction • We would like to

3. Motivation • Increasing popularity of multi-party communication applications. • Audio and Video conferencing prevalent in work and home.

4. Survey of Current Implementations • We chose to survey four popular applications to see how they handle multiparty communication. • Initially we wanted to see if we could extend upon these applications to better support a multicast architecture. • AIM, Yahoo! Messenger, MSN, and Skype.

5. AIM • Supports user extensions through Open AIM API. • Using packet sniffering we found it supports multiparty audio chat by having each participant connect to a central server (AIM server) and only send and receive from that server. • Turned out SDK didn’t allow for the low-level modifications we had initially hoped to work on.

6. MSN and Yahoo! Messengers • Both had no support for multi-party audio/video communication. • MSN allows for multiparty conversations, but a/v communication is disabled when more than two parties are chatting. • Using Wireshark, we found that both applications send a unicast copy to each individual recepient. • Both are closed source, so no modification would be possible

7. Skype • Allows for multiparty multimedia communication. • Using Wireshark, found that unicast packets are sent to each user, meaning we had a perfect candidate. • Unfortunately, Skype is definitely closed source.

8. What we learned from current Implementations • Except for AIM, none of the big IM clients evaluated, implemented any type of multicast communication, even at the application layer. • In order to implement something, we’d have to build our own client. • We would also have to find a way to implement multicast at some level.

9. Universal Multicast • Aim is to provide ubiquitous multicast delivery service on the Internet. • Fully utilize native IP multicast wherever available, while being able to automatically build unicast tunnels to connect IP Multicast “islands” to form a multicast overlay. • Consists of three major components: • An overlay multicast protocol (HMTP) for inter-island routing • An intra-island multicast management protocol (HGMP) to glue overlay multicast and native IP multicast portions together • And a daemon program to implement the functionality at hosts. • We chose to focus on HMTP.

10. Universal Multicast • Each client in our implementation would replace a cloud in figure 1. • Since we had no way to deal with IP multicast Islands, we decided our application would use an application level implementation of the HMTP overlay protocol to connect clients.

11. 1.7.4.2 2.2.8.9 3.4.3.1 1.2.5.3 HMTP Join Algorithm I want to join your multicast session Rendezvous Server Root is 1.2.5.3 Client Request Root Node Child List Reply: 1.7.4.2 2.2.8.9 Join Acknowledged Child List Reply: 3.4.3.1 Client Find Closest Node: RTT to 1.2.5.3 = 34 ms RTT to 1.7.4.2 = 23 ms RTT to 2.2.8.9 = 11 ms Request Child List Request Join at 2.2.8.9 Find Closest Node: RTT to 2.2.8.9 = 12 ms RTT to 3.4.3.1 = 14 ms Request Child List Client is now a child to 2.2.8.9 2.2.8.9 updates its child list Client updates it’s parent list.

12. I want to join your multicast session Root-Rendezvous Interaction Well you’re the 1st to ask, so you’ll be the root! Rendezvous Server 1st node to connect Periodic REFRESH message Who is the Root Node?

13. 1.2.3.4 Repair Algorithm 2.2.3.4 simply has to remove 5.3.2.1 from its child list. 2.2.3.4 8.4.2.3 1.1.3.4 2.4.3.9 asks for 2.2.3.4’s child list LEAVE sent to parent 6.4.2.9 5.3.2.1 I don’t want to be here anymore.... 2.2.3.4 replies with Children: 6.4.2.9 6.4.2.9 replies with a JOIN ACK LEAVE sent to child 2.4.3.9 2.4.3.9 finds closest node: RTT of 2.2.3.4 = 25 ms RTT of 6.4.2.9 = 13 ms 2.4.3.9 must now search for a new parent. 2.4.3.9 has successfully rejoined the tree! 2.4.3.9 sends a JOIN request to 6.4.2.9

14. Rendezvous Server Maintenance and Partition Recovery REFRESH ROOT-A PATH: ROOT ROOT Ok, you’re still the ROOT REFRESH REFRESH ROOT-B PATH: ROOT A B B-D PATH: ROOT B REFRESH B-C PATH: ROOT B REFRESH C D Periodically: Each child sends a REFRESH to its parent. The ROOT sends a REFRESH to the UMRP. • Each Parent replies with a PATH message describing the path from ROOT to parent. • Lack of REFRESHes signal crashed nodes to be removed. Every member must maintain the freshness of its list of children and its root path. If a node crashes, a parent will detect by lack of incoming refresh messages, while a child will detect by lack of path replies. In this case, ROOT would update its child list and C and D would look for new parents

15. Improvement ROOT C A B Request ChildList E D G H Request ChildList Join Request I J As network conditon and group membership change over time, members may need to restructure the tree, by switching to new parents. When Node J’s improvement timer goes off, it selects a random node from its root path to start the join procedure from. Once J knows A’s Children are D and E, it finds the closest of the three. Let’s assume it picks D. J requests D’s children and makes a join request when it finds there are no children. Node J now updates it’s parent list to D, and D updates its child list to include J. Improvement phase is now complete. Join Accepted My Children: D and E My Children: (empty)

16. Other HMTP features not implemented • Loop Detection and Resolution – when a node notices itself in its root path, it rejoins from the root. • Join Delay and Foster Care – Existing members must accept a limited number of temporary children for a short period of time. • U-Turn and Triangle Optimization • Server Backbone