p2p-sippeertopeerinternettelephonyusingsip

p2p-sippeertopeerinternettelephonyusingsip内容摘要：

uplicates  Security: How to avoid spies?  How to recover if all responsible nodes leave? 28 Conferencing (further study)  One member bees mixer  Centralized conferencing  What if mixer leaves?  Fully distributed  Many to many signaling and media  Application level multicast  Small number of senders 29 Evaluation scalability  messages depends on  Keepalive and finger table refresh rate  Call arrival distribution  User registration refresh interval  Node join, leave, failure rates M={rs+ rf(log(N))2} + (N) + (k/t)log(N) + (log(N))2/N  nodes = f(capacity,rates)  CPU, memory, bandwidth  Verify by measurement and profiling 30 Evaluation reliability and call setup latency  User availability depends on  Supernode failure distribution  Node keepalive and finger refresh rate  User registration refresh rate  Replicate user registration  Measure effect of each  Call setup latency  Same as DHT lookup latency: O(log(N))  Calls to known locations (“buddies”) is direct  DHT optimization can further reduce latency  User availability and retransmission timers  Measure effect of each 31 Explosive growth (further study)  Cache replacement at supernodes  Last seen many days ago  Cap on local disk usage (automatic)  Forcing a node to bee super node  Graceful denial of service if overloaded  Switching between flooding, CAN, Chord, …  . . . 32 More open issues (further study)  Security  Anonymity, encryption,  Attack/DOSresistant, SPAMresistant  Malicious node  Protecting voics from storage nodes  Optimization  Locality, proximity, media routing  Deployment  SIPP2P vs P2PSIP, Intra, ISP servers  Motivation  Why should I run as supernode? 33 Conclusions  P2P useful for VoIP  Scalable, reliable  No configuration  Not as fast as client/server  P2PSIP  Basic operations easy  Implementation  sippeer: C++, Linux  Interoperates  Some potential issues  Security  Performance C C C C C S P P P P P 427 763 135 365 123 324 564 364 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) Backup slides 35 Napster  Centralized index  File names = active holder machines  Sophisticated search  Easy to implement  Ensure correct search  Centralized index  Lawsuits  Denial of service  Can use server farms P1 P2 P3 P5 P4 S Where is “quit playing games” ? P2 FTP 36 Gnutella  Flooding  Overlay work  Decentralized  Robust  Not scalable.  Use TTL. Query can fail  Can not ensure correctness P P P P P P P P P 37 KaZaA (FastTrack)  Supernodes  Election:  capacity  bandwidth, storage, CPU  and availability  connection time  public address  Use heterogeneity of peers  Inherently nonscalable  If flooding is used P P P P P P P P P P P P 38 FreeNet  File is cached on reverse search path  Anonymity  Replication, cache  Similar keys on same node  Empirical log(N) lookup  TTL limits search  Only probabilistic guarantee  Transaction state  No remove( )  Use cache replacement P P P P P P P 1 12 2 3 4 5 6 7 8 9 10 11 39 Distributed Hash Tables  Types of search  Central index (Napster)  Distributed index with flooding (Gnutella)  Distributed index with hashing (Chord)  Basic operations find(key), insert(key, value), delete(key), no search(*) Properties/types Every peer has plete table Every peer has one key/value Search time or messages O(1) O(n) Join/leave messages O(n) O(1) 40 CAN Content Addressable Network  Each key maps to one point in the ddimensional space  Each node responsib。