1. 1 LYU0502 P2P Digital TV Recorder Supervisor: Professor Michael R. Lyu Prepared by:Ho Tsz Wing, Andy Lau Wai Shun, Jack

2. 2 Outline Motivation Objective Development Platform Approach Performance Enhancement Erasure Code Analysis Future Work Conclusion Q&A

3. 3 Motivation Watching TV is a major entertainment activity for people People often miss their favorite program because they have to work overtime or go out to travel People need to schedule the recording of the programs

4. 4 Objective Allow people view to back previous TV program without doing scheduling themselves Let the user view the program on demand Increase the availability of the TV program Achieve load balancing among the participating peers

5. 5 Develop Platform Windows XP Media Center Edition First released in Aug. 2003 Capable of watching DVD, recording TV, listening to music and sharing digital photos Media Center Edition 2005 SDK – Click-To- Record Feature Enables applications to programmatically schedule the recording of TV programs Supported in Visual C#.Net

6. 6 Windows XP Media Center Edition Need an Electronic Program Guide (EPG) in order to schedule the recording Use TVxb to convert the schedule obtained from webpage to an XML format Use Quickguide to convert the XML schema to the EPG

7. 7 Approach Interface of the application

8. 8 Approach There are different types of peer-to-peer file sharing architectures according to their “degree of centralization” Hybrid decentralized architectures (Napster) Purely decentralized P2P architectures (Gnutella) Partially centralized systems (KaZaA)

9. 9 Approach In this term, we choose to implement our system using the hybrid decentralized architectures There is a centralized server maintaining the list of online peers and the directories of the shared files The server is also responsible to schedule the recording to the online peers in a fair and efficient way

10. 10 Approach On the other hand, the peers are responsible to handle the scheduling request made by the server Also, they need to serve the downloading request from other peers

11. 11 Approach Reasons to choose the hybrid decentralized architectures It is simpler to implement It serves as a model for us to investigate the feasibility of the project and measure the performance of the system under different peers behavior After implementing our system using the hybrid decentralized architectures, it is relatively easier for us to deploy it to the purely decentralized P2P architectures

12. 12 Approach Component of the server p2p.mdb – database which maintains the peer table and share table Login.asp – make entries in the peer table and share table when a user login Search.asp – search the file requested by the user and generate suitable response Userlist.asp – return the list which contains the information of the currently logged-in peers Updateshare.asp – update the share table after a user recorded or downloaded a program Xml.asp – return the schedule of all the channels in a particular date Logout.asp - delete entries in the peer table and share table when the user logout

13. 13 Approach The client side application Start Login to the system through login.asp Listen to incoming connection Upload request Recording request Upload the requested file to the peers Schedule the recording Using click-to-record feature Download request Search peers using search.asp Connect to the peers and start downloading No Yes Logout the system through logout.asp Stop

14. 14 Approach Alice Bob Suppose Alice wants to see the program “The Apprentice (III) “ She will send a query to the server The server will reply to Alice with the list of peers (Bob) that have a copy of “The Apprentice (III) “ She will then make a direct connection to Bob to get the file The Apprentice (III)

15. 15 Performance enhancement How to schedule the recording tasks to the peers effectively? How to increase the availability of the video files? How to improve the performance of retrieving the video files from peers?

16. 16 Scheduling policies Policies: Do scheduling 15 minutes before the program start Select the peers randomly N peers will be scheduled In this project, N is assigned to be 2 Assumptions: The selected peers will not leave manually The peer who gets the whole video file has the responsibility to do the encoding process

17. 17 Scheduling policies The server side application Start Obtain the schedule of all channel at 5:40 am everyday Schedule the recording of all program Send the xml recording request to the selected peers Get 2 randomly selected peers from userlist.asp 15 minutes before the start of a program

18. 18 Scheduling policies Alice Bob 15 minutes before the program starts, the server will randomly send it’s schedule to any two of the online peers

19. 19 Availability enhancement Whole file replication (WFR)  Advantages:1) Multiple access of the video files 2) No decoding needed  Disadvantages:1) Storage overhead is large 2) Replication time is long Erasure Code replication (ECR)  Advantages:1) Multiple access of the video files 2) Storage overhead is small  Disadvantages:1) Encoding and decoding time 2) Difficult to implement

20. 20 TVBNews.dvr-ms Whole File Replication Do replication on the whole file Redistribute the file to other peers

21. 21 Replication factor  r Peers availability  P Total Number of Peers  N Availability Independent of N When P  1, A(w)  1 When r , A(w)  1 Whole File Replication

22. 22 Erasure Code - Background Message n blocks Encoding (to m blocks, where m > n) Decoding (Requires any n blocks) Message n blocks

23. 23 Erasure Code - Implementation Divide the video file into n fragments Code these n fragments in m (m>n) Any n (unique) fragments are able to reconstruct the video files Send the fragments to random peers

24. 24 TVBNews.dvr-ms Erasure Code Do encoding on the whole file Redistribute part of file to other peers

25. 25 Erasure Code - Analysis Replication factor  r Divide the video file into n fragments Code these n fragments in m (m>n) Stretch factor  s = m/n Any n (unique) fragments are able to reconstruct the video files

26. 26 Comparison – WFR Vs. ECR Whole File Replciation - Availability Erasure Code Replciation - Availability

27. 27 Availability Analysis - µ = 0.1

28. 28 Availability Analysis - µ = 0.3

29. 29 Availability Analysis - µ = 0.5

30. 30 Availability Analysis - µ = 0.5

31. 31 Availability Analysis - Conclusion If the storage is not limited, ECRperforms better than WFR in most cases. When peer availability large than 0.5, the performance of WFR tends to ECR if the replication factor increases. However, the storage is limited in real world

32. 32 Storage Analysis - µ = 0.7

33. 33 Storage Analysis - Conclusion If the peers availability is high, ECR is more storage-effective than WFR. Adopted from : Replication Strategies for Highly Available Peer to Peer Networks, Ranjita Bhagwan et. al,

34. 34 Block Size Analysis – r = 2 If the storage is limited, the performance of erasure code replication will highly depends on the peer availability Adopted from : Erasure Code Replication Revisited, W.K. Lin, D.M. Chiu, Y.B. Lee

35. 35 Future Work Implement the system in Server-less way Design a algorithm for placing the encoded check blocks Investigate the relationships between popularity and download frequency of a TV program (Dynamic replication factor) Implement choking algorithm to encourage users to share their own contents.

36. 36 Conclusion We have implemented the P2P system in the Server-Client model. The availability of the TV Programs are enhanced by using Erasure Code Replication.

37. 37 ~ END ~

38. 38 Q&A Session Thank you very much

39. 39 Backup Slide

40. 40 Availability Analysis - µ = 0.1 Whole File Replication Replication factor (r)File Availability (A) 50.40951 100.65132 150.79411 200.878423 Erasure Code Replication rNo of data blockTotal No of blockAvailability 54200.13295 104400.57687 154600.86260 204800.96469

41. 41 Availability Analysis - µ = 0.3 Whole File Replication Replication factor (r)File Availability (A) 50.83193 100.97175 150.99525 200.99920 Erasure Code Replication rNo of data blockTotal No of blockAvailability 54200.89291 104400.99940 154600.99999 204800.99999

42. 42 Availability Analysis - µ = 0.5 Whole File Replication Replication factor (r)File Availability (A) 50.968750 100.999023 150.999969 200.999999 Erasure Code Replication rNo of data blockTotal No of blockAvailability 54200.998712 104400.999999 154600.999999 204800.999999

43. 43 Availability Analysis - µ = 0.7 Whole File Replication Replication factor (r)File Availability (A) 20.910000 40.991900 60.999271 80.999934 Erasure Code Replication rNo of data blockTotal No of BlockAvailability 2480.942032 34120.998308 44160.999966 54200.999999