1 / 14

Data types in P2P systems

Data types in P2P systems. Henning Schulzrinne Columbia University. Data issues. What do we store and fetch? How do we protect it? separate topic: CMS, homebrew, ... Analogies file system (meta data, ACL, blob) some had/have data types (e.g., VMS records) hash libraries (e.g., hcreate())

ghada
Download Presentation

Data types in P2P systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data types in P2P systems Henning Schulzrinne Columbia University IETF 71 (P2PSIP)

  2. Data issues • What do we store and fetch? • How do we protect it? • separate topic: CMS, homebrew, ... • Analogies • file system (meta data, ACL, blob) • some had/have data types (e.g., VMS records) • hash libraries (e.g., hcreate()) • database libraries (e.g., gdbm) • language features such as arrays and dictionaries • Tcl, Perl, PHP, Python, Ruby, ... ID data crypto wrapper IETF 71 (P2PSIP)

  3. Requirements • Need to be able to store any data item • of reasonable size • New types MUST NOT require rewriting node software • otherwise, little chance to generalize • ID (“database key”) must allow non-AOR values • otherwise, doesn’t generalize to VoD and other uses • Allow both “standard” data objects and application-specific ones • e.g., SIP registration records and vendor-specific configuration data or I-D 00 experiments • Provide access control • e.g., only creator can read • should work with semi-trusted nodes • Provide policy control per node or overlay • e.g., maximum size of objects IETF 71 (P2PSIP)

  4. Data typing • RELOAD -03: 32-bit integer • with some TBD allocation scheme • e.g., similar to IANA ports registry • compromise between space efficiency and extensibility • a “usage” may define one or more data types IETF 71 (P2PSIP)

  5. Multiple objects with same “key” (ID) • What happens if there’s a hash collision? • Possibilities • global space • {“egg”} is • may cause DOS attacks if ID = AOR • creator • e.g., ID space could be local to creator • {“egg”, alice} and {“egg”, bob} are two different objects • allows “only AOR can register AOR” policy • data type • {“egg”, 17, alice} and {“egg”, 42, alice} are two different objects • auxiliary data • {“egg”, 17, alice, label1} and {“egg”, 17, alice, label2} are two different objects IETF 71 (P2PSIP)

  6. Access control & versioning • Basic access control policy: only owner (= creator) can replace (or delete) object • enforced by peer • can’t prevent peer from disobeying policy • Do we need more elaborate policies? • similar to Unix ACLs or chmod bits? • unbounded complexity IETF 71 (P2PSIP)

  7. Versioning & timestamps • Do objects have timestamps? • Option 1: Just metadata • Option 2: Cannot replace newer object with older one • prevents replay attack • does not require synchronized clock in overlay • as long as all instances of owner have roughly synchronized clocks or fetch current value IETF 71 (P2PSIP)

  8. Compound data structures • Should there be compound data structures? • Options (at least) • But also STL (see next slide) • Scripting languages (PHP, Tcl, Ruby, ...) • Need data structures AND operations • e.g., enumeration, traversal (iterator), insertion at beginning/end, ... • Interaction with policies and replication IETF 71 (P2PSIP)

  9. Example: STL containers IETF 71 (P2PSIP)

  10. Example: Tcl • set name(first) "Mary” • Fake two-dimensional arrays: name(a,b) • No ordering guarantees • PHP differs, for example (insertion order) IETF 71 (P2PSIP)

  11. Proposed simple type • Uniquely identified by H(data) • within {“ID”, owner, type} • Operations • replace • list all {“ID”, owner, type} hashes (?) IETF 71 (P2PSIP)

  12. Other proposals • Three types: • singleton • numeric array • dictionary • Issues that need to be resolved: • operations beyond single-element • replication • access control for [x] separate from data? IETF 71 (P2PSIP)

  13. Example applications • registrations • multiple handsets for same AOR • voicemail • may generally use a server (announcement), not just storage • multiple writers? • but probably want to hide meta data • TURN servers • possibly indexed by some location indication IETF 71 (P2PSIP)

  14. Summary • Data model independent of DHT and protocol • But if more complicated, may need additional operations beyond store & fetch • or at least additional sub-operations (“last”) • Security issues -- what gets exposed to the (untrusted) server? IETF 71 (P2PSIP)

More Related