Kalman Graffi - Disputation Talk - Monitoring and Management of P2P Systems - 2010
•
0 likes•378 views
This is the disputation talk fo Dr.-Ing. Kalman Graffi - Monitoring and Management of P2P Systems
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Kalman Graffi - Disputation Talk - Monitoring and Management of P2P Systems - 2010
Similar to Kalman Graffi - Disputation Talk - Monitoring and Management of P2P Systems - 2010 (20)
More from Kalman Graffi
More from Kalman Graffi (20)
Recently uploaded
Recently uploaded (20)
Kalman Graffi - Disputation Talk - Monitoring and Management of P2P Systems - 2010
- 1. Monitoring and Management of Peer-to-Peer Systems
- 25. Thank You for Your Attention!
- 28. P2P Overlays: Structured and Unstructured Peer ID space Object ID space Structured P2P Overlay Unstructured P2P Overlay q q L L q q L L
- 39. Selected Results from the Testbed Evaluation
- 40. Comparison of Benchmark Signals
- 44. Additional Slides on Management
- 45. Comparison of C/S Solution with SkyEye.KOM
Editor's Notes
- Create a new overlay/mechanism for every case? Reuse existing overlays / mechanisms
- “ The well-defined and controllable behavior of a system with respect to quantitative parameters ” Does the system meet the expectations? How can we know? Download counter? Application GUI?
- GRAFIK: CAPACITY reservation Challenges Use cases: various applications, large-scale general Scale: up to millions of peers decentralized Environment: peer heterogeneity fair, efficient Dynamism, unreliability: user behavior, churn self-organizing
- Tree topology characteristics All peers part of spanning tree Peer positions calculated Churn-resistant protocols based on IDs
- | | November 19, 2007
- Model: behavior synthesis Simulation: large scale, detailed Testbed: accurate prototype
- MODELL! Log_beta(N) * UI = ???
- MODELL für Kosten? Warum 3KB/s ?
- | | November 19, 2007
- Roter Faden: Nun Übergang zu unserer Lösung: Eine zusätzliche Schicht auf strukturierte P2P Overlays (die durch die Common API einheitlich angesprochen werden können). Die Query Form die unsere Architektur bietet, wird vorgestellt Evtl. Unklare Details: Common API, Paper von “F. Dabek and B. Zhao and P. Druschel and I. Stoica“ zum Vereinheitlichen der Services von DHTs, wichtig hier: Route(ID, Msg) – mittels der eine Nachricht (Msg) zu einem Peer geroutet werden kann der für eine ID (ID) zuständig ist.
- -Both figures at the top display the amount of solved queries in relation to the level of the initiator and the level of the solver. Concerning the level of the initiators, one can observe, that the amount depends on the number of peers, which are located at that level (many peers at a level result in many originated queries at that level). This does not hold for the resolution of queries, since 87,3% on the centralized DHT overlay (80.6% on the Chord overlay) of solved queries are solved from 1,3% of nodes out of 5001 (this comprises the peers between the root and the 5 th level) -Though, some queries are solved beneath the aforementioned region. To characterize the complexity of solved queries in relation to the level, we display the figures at the bottom. For the simulations, whose statistics are depicted at the bottom, we use for every query the same conditions, but with a changing amount of requested peers. The amount of the peers ranges between 10 and 200 peers in steps of 10 peers. The pictures show the average complexity of queries, which were solved at that level. One can draw the conclusion, that the average complexity of solved queries is inversely proportional to the depth of a peer. November 19, 2007 | |