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

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

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

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

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

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

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

8. Flashback - Implementation

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

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

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

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

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

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

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

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

17. Flashback – Data trading Flow control Default burst size = 16 1. 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

18. Flashback - Scalability

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