90 likes | 102 Views
Protect important data collections by trading storage space in a peer-to-peer system through auctions and negotiations.
E N D
Bidding for storage space in a peer-to-peer data preservation system • Protect important data collections from failure by making multiple copies. • Sites “trade” space, each site contributes storage resources to others and uses storage at others. • bid trading: mechanism where sites conduct auctions to decide who to trade with. • Constraints: limited resources and preserve autonomy (no central decision maker). • Negotiation and agreement in auction system in economics and computer science, first price, sealed bid auction. Every site is both producer and consumer. Profit is max reliability. • Mechanism (bid trading), different policies, simulation and exam results.
Bid Trading: • archive site: autonomous provider of storage service to replicate data collection. • Local site proposes a trade request S bytes of space to remote sites. • If remote site agrees, two site swap deeds , the right of one site to use space at another site. • price B will be determined in trading negotiating, in fixed-price trading, S = B.
Freedom in bidding: 1 Fixed-priced Bid: S=B 2 Adaptive Bids: follow same policy but take into account local condition. Example: f(R, S), free space R, and request S. 3 Multiple Policies: partitioned into classes, example: f1, f2,… 4 Maverick Site: same as multiple policies but with singe “maverick” site that has its own policy. 5 Free Market: each site has its own policy. 6 Malevolent Sites: Some sites break basic trading rules to subvert the system. PS: 5 and 6 called permissive scenarios are very hard to study.
Reliability: • Each site calculate the local MTFF (mean time to failure); the expected time before one site collection is lost. • Trading:
Adaptive Bid scenario: • Auction calling policy: rules for automatically deciding when to call and for what collection (1 CallForAll, or 2 CallForRare). • Bid policy: rules for automatically calculating the bid for each auction. • Selective I-P policies : I interval of potential bids (min and max bids), and P() the policy function. • General form: B = S * ( I * P() + (1 – I/2) ) • if P()=0, then symmetric bid policy. • P() policy function: • 1). FreeSpace: P() = K/T • 2). UsedSpace: P() = (T-K)/T • 3). AbundantCollection: P() = C/G • 4). RareCollection: P() = (G-C)/G • PS: K: local free space, T: local space, C: # of copies of rarest collections, G: goal # of copies
Rheeve: A Plug-n-Play Peer-to-Peer Communication Platform • Platform supports HTTP-enabled, efficient and fault tolerant P2P application. • P2P is distributed system where nodes play equal roles and have ability to discover and connect each other and share information and services. Example: Napster, SETI@HOME. • Peer discover: 1) Centralize algorithm; file indexing server to direct P2P file sharing. 2) Distributed algorithm: gossip to discover peers and services. 3) Hybrid version. • System Architecture: • Each peer is identified by an UCI (Universal Connection Identifier); consists a protocol name, address, and port #. • Four layers: • 1) Lowest layer: HTTP over internet, • 2) Second layer: programming platform and OS,
3) third layer: Rheeve’s peer platform which handles peer management, service management, and utilities. • 4) top layer: P2P application via visual interface or API. • Connection Management • When a node starts, it connects to well-known server which maintains an up-to-date list of locations UCI of on-line peers. • Download the list so it can connect to other peers. • The server maintains small # of peer UCIs. • Using HTTP query to download UCIs in FIFO order. • Starting peer broadcast in LAN to notify all other peers by UDP. • Since finding disjoint peer has smaller probability, Rheeve uses mobile agent-enabled approach to connect disjoint peer groups.
The mobile agent-enabled auxiliary server (such as IBM’s Aglets) download UCIs from well-known server, dispatch a mobile agent traveling across nodes, capture UCIs and create another mobile agent and continue to travel. • Periodically record UCIs into a log file; it is used when a peer shutdown and restarted. • Periodically downlown UCI list from known peers as a backup for connection instability. • Service Discovery: • Periodically announce services to its known peers and receiving peers registers the service and provider. • Forward new service to other known peers. • Service Delivery: • Search local registration list first, if not found, ask service source from the forward.
Resource Management: • To efficiently manage local resource on peer node, Rheeve has three modules. • 1) Listener Manager module: handle all incoming requests • 2) Updater: updating for piece of code that need to be executed periodically. • 3) File Manager: abstraction over file system so P2P is independent of file system and security. • Application Control: • Control the execution of P2P applications such as loading and stopping operations, also coordinates with file manager. • Communication Mechanism: • Use HTTP (crossing firewalls) and XML.