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 | |