P2P Multicast Library

Technology

In Depth

Menu
Overview
This is an overview of the functionality of a P2P application (servent) sharing a resource:
  • A servent determines (by test or configuration) that it supports IP multicast
  • The servent receives a large number of unicast download requests for a segment A of resource R
  • The servent checks in its P2P message cache to see whether segment A of resource R is already being multicasted by another servent
  • The servent sends out a P2P broadcast message that he will start multicasting segment A with Tigerhash Ta and a size of B bytes of resource R with Tigerhash Tr to Source Specific Multicast group (S,G) starting in X seconds with FEC algoritm F using an overhead of `O'% at a transmission rate of R Kbit/s. Other servents will forward the P2P broadcast message
  • The servent sends every second a session description message to (S,G) until X lapses
  • The servent computes a bytestream F(A) by using the FEC algoritm F on A.
  • After X lapses the servent will start multicasting F(A) to (S,G) at rate R Kbit/s
  • In each packet it sends a Datagram Sequence Number (DSN) that is incremented with each packet being transmitted
  • The servents listens to P2P messages reporting success or failure in receiving the multicast transmission, based on which it may decide to stop the transmission
  • After the bytestream F(A) has been completely transmitted it stops the transmission
A servent interested in retrieving segment A of resource R performs the following steps:
  • The servent receives the P2P broadcast message announcing the details of the multicast session
  • The servent validates that Tr is the same as the TigerTree hash of the resource it wants to retrieve
  • The servent joins the multicast group (S,G) using IGMPv3
  • Initially it will receive the session description message through (S,G) until the start of the actual transmission starts
  • During the session the servent sends periodic reports to the sending servent using P2P messages about the level of success receiving the multicast session. Other servents periodically forward these reports using multiplexing to the sending servent.
  • If the servent notices that while receiving the transmission it loses more then `O'% of the packets during a period P then it leaves the multicast session and considers the transmission to have failed. It reports this using the P2P message to the sending servent.
  • Using FEC it computes the original segment A
  • When it has completed computing the original segment A it stops listening to (S,G)
  • It computes the Tigertree hash of A and validates that to Ta.

A servent can fail to receive a segment that has been multicasted because of congestion in the network. However, unless the congestion in the network was very close to the sender of the multicast session, other servents will have received the segment succesfully. The servent can then retrieve the missing segment from the other servents using the standard unicast resource sharing capabilities of the P2P network, assuming that this P2P network supports Partial File Sharing.

The transmission rate of a single multicast session will be kept low because of the limited upstream capacity of most Internet users. However, a servent can join multiple multicast sessions to retrieve multiple segments of a resource simultaneously and thus still achieve high download speeds.
Technologies used in PML
The following technologies are used in the P2P Multicast Library
Copyright (C) 2003, 2004 Steven Hessing