Flashback: A Peer-to-Peer Web Server for Flash Crowds Presented by Tom Batkiewicz CS 587x Fall ‘07

Problem - Web Flash Crowds Unpredictable spike in demand Website capacity exceeded CPU Bandwidth Websites can either… Downgrade content on the fly Lose page hits as users are forced to wait

Motivation - Existing Solutions Caching Remote servers share load with web server Limitations Website sets no-cache on page Finding a cache with the desired content Cache must be recent enough Outside of host’s control

Motivation - Going Forward Cacheless Complementary solution to web caches, not a replacement Where to find the additional bandwidth? End users Peer-to-Peer Solution

Flashback - Overview Creates a P2P network from users that request the web object Based on some BitTorrent concepts Chunked content delivery Chunk management / Metadata Can serve more end-users within existing bandwidth limitations

Flashback - Goals 1. Easy to deploy server-side 2. Does not interrupt end-user experience No setup/install Works within web browser Across different operating systems Works behind NAT Devices 3. Use existing infrastructure No required changes in HTTP, for example

Flashback - Implementation Server distributes two Java applets Transported Frame Hack Visible Frame – displays webpage Invisible Frame P2P Client Basic web server Pixel height 0 Why Two?

Flashback - Implementation

Flashback – Pygmy Simple web server Why? Marshal HTTP requests from visible frame into P2P requests and back again Relative links can be served here Continue using P2P approach External links fetched normally by browser

Flashback – Hole punching Behind NAT, end-user doesn’t know their own internet IP address Uses the web-server to establish P2P connection for peers behind NAT A and B want to talk A&B create UDP connection with server Server has well-known IP Server forwards IP/port information to A&B It sees their external addresses

Flashback – Hole punching A&B can now communicate Functions more reliably over UDP NAT Devices track TCP state, etc… Flashback chose to use UDP for this fact rather than TCP Flashback needs to implement own flow control & handshaking

Flashback – Peers & Data Basis in BitTorrent Typically used for large files Peers in group for many hours, even days Flashback Smaller files (html/images/etc..) Peers in group only while visiting the page

Flashback – Extreme churn Peer group composition changes rapidly 90% of peer overlay changes in 10 seconds BitTorrent’s peer selection completely unworkable Tries to find ‘best’ peers over time Instead, find many peers and trade data

Flashback - Finding peers Initially, request from seed (web server) From existing neighbors, request a ‘referral’ for a new neighbor When asked for a referral, respond with stochastic selection from most-recently used peers Detecting overlay partitions If no new data in 500ms, request new neighbor from the seed Prevents overlay from fragmenting

Flashback – Data trading Interval metadata (gaps) BitTorrent uses a bit vector Send only top intervals of data we have First handshake Exchange metadata Second handshake Request data

Flaskback – Data trading Tit-for-Tat (TFT) policy Handshakes are silently dropped if neighbor has downloaded more than uploaded Gives the neighbor time to upload before re-request is sent If re-request fails, neighbor is removed

Flashback – Data trading Flow control Default burst size = Send default size 2. Increased by 1 if whole burst sent OK 3. If whole burst not sent OK, send only as many as were successfully received Not completely efficient between peers, but many peers compensates for this

Flashback - Scalability

Flashback - Limitations Dynamic content Streaming content End-users may have issues Assumes Java installation Hole-punching not 100% Firewalls, NAT Devices, etc…