1. A P2P-Based Architecture for Secure Software Delivery Using Volunteer Assistance Purvi Shah, Jehan-François Pâris, Jeffrey Morgan and John Schettino IEEE 8 th International Conference on Peer-to-Peer Computing (P2P'08) 69621014 劉家賢 69621020 黃義凱

2. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 2

3. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 3

4. Introduction A content delivery infrastructure distributing and maintaining software packages in a large organization Combines a conventional server and P2P technology A novel load balancing mechanism is included in the system 4

5. Introduction (Cont.) Main contributions: ◦ A trace-based analysis is used to find general principles and properties to devise a better system ◦ A scalable CDN(Content Delivery Network) architecture for delivering software using volunteer nodes ◦ An efficient mechanism for load balancing in the proposed design 5

6. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 6

7. Trace analysis Ten days worth of logs associated with a software delivery system supporting various Linux installations and distributing their updates in a corporate environment 7

8. Central software repository 8

9. Central software repository (Cont.) The repository served system software and updates for ten Linux distributions 9

10. Access patterns Image(.iso) downloads comprise 71% of total server workload As seen in Fig. 4, almost 2/3 of the files uploaded by the server are smaller than 256KB 10

11. Access patterns (Cont.) Flash crowds shows up at the time of new package releases More than 1/3 of all customers requests are received before the end of the day following the package release 11

12. Access patterns (Cont.) The number drops by the third day and is further reduced one week after the release ◦ Increasing the server capacity to control flash crowds is not a practical solution 12

13. Number of identical files They found out 17% of files larger than 1MB were identical and differed from other files only in name ◦ 17% of these identical files were source-code package by more than one Linux distribution 13

14. Similarity Those files may exist among different versions and variants of the same source- code package The majority of packages in the repository are compressed files but compressed in different tools, e.g. gzip and bzip The lack of standard has some very favorable effects on exploiting file similarity using the tools such as rsync 14

15. Similarity(Cont.) Fig. 8 suggests that considerable similarity exists among the uncompressed versions of the same software They also observed that software has variants, that is, different packages for clients with different architectures and operating systems Utilizing the similarity among these variants would greatly benefit any P2P solution as peers could find several more potential neighbors 15

16. Similarity(Cont.) 16

17. Synchronization workload The various departments within the enterprise manage around forty edge nodes that maintain complete or partial mirrors of the software repository for serving updates to a small set of machines The nodes spent average 1.81 hours daily synchronizing its repository with the server 17

18. Synchronization workload (Cont.) 18

19. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 19

20. Software synchronization by the edge nodes Synchronization tool rsync + P2P = Prsync This integration was feasible because all edge nodes use the same rsync tool Using BitTorrent among the edge nodes would allow us to further improve the efficiency and scalability of the synchronization system ◦ With PRsync, server now can reduce the processing on the server repository for multiple edge nodes 20

21. Software synchronization by the edge nodes (Cont.) PRsync separates content delivery from synchronization: ◦ The first task is shared by the edge nodes and the server while synchronization remains the sole responsibility of the server ◦ This separation removes redundant processing at the server and permits the use of P2P protocol 21

22. Software delivery to the customers Since we are providing a delivery service, we should also avoid consuming customer bandwidth if there is an alternative way to obtain the required bandwidth Download Tools

23. Software delivery to the customers The resultant system is not a pure P2P system, but a client-server system based on P2P technology System Design

24. Software delivery to the customers First step is to Collect information on the volunteer nodes and to find out which volunteer nodes have which files Added therefore feedbacks that measure number of active connections maintained by each volunteer peer and will be retrieved at each tracker update interval connections Tracker construct

25. Software delivery to the customers Load balance ◦ Feedback-controlled load balancing mechanism ◦ Peers to add information on their current workload to the messages they already send to the tracker ◦ Can identify the volunteer nodes that are currently overloaded and redirect fewer customers to such volunteer nodes Major Issue

26. Software delivery to the customers Synchronization ◦ Use either dedicated connections or a private high- speed networks Security ◦ MD4 checksums Other Issue

27. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 27

28. Software delivery to the customers JAVA based discrete-event General P2P Simulator (GPS) Idealized performance of TCP Request counting algorithm provided by the Apache load balancer Simulation Environment

29. Software delivery to the customers Evaluation Four volunteer had a much high workload and the other four volunteer had a much light workload

30. Software delivery to the customers Evaluation Some unevenness in the response times

31. Software delivery to the customers Evaluation

32. Software delivery to the customers Evaluation

33. Software delivery to the customers Evaluation

34. Software delivery to the customers Evaluation

35. Outline Introduction Trace analysis Proposed mechanism Evaluation Conclusions 35

36. Conclusions Our proposal consists of supplementing a conventional server with volunteer nodes that expand its scalability. Our system includes a novel load balancing mechanism that considers both the synchronization workload and the customer- generated workload of the volunteer nodes.

37. Future works We plan to study content placement policies that can handle volatile volunteer nodes. We plan to take into account the round trip time as an additional metric when performing load balancing. As the volunteer nodes could be globally distributed, it is desirable to select the volunteer nodes that are near to the customer.

38. Future works We have considered exploiting similarity between different versions of a package.

39. Q & A 39