Transcript notes

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
Easy to deploy server-side
Does not interrupt end-user experience
1.
2.


No setup/install
Works within web browser


Across different operating systems
Works behind NAT Devices
Use existing infrastructure
3.

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)



First handshake


BitTorrent uses a bit vector
Send only top intervals of data we have
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


1.
2.
3.

Default burst size = 16
Send default size
Increased by 1 if whole burst sent OK
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…