Application Architectures Flashcards
1
Q
Application architecture
A
- Main categories of application architecture
– Client-server
– Peer-to-Peer (P2P)
2
Q
Client-server architecture
A
- Server:
– An always-on host
– Permanent IP address
– Can use data centres for scaling - Clients:
– May be intermittently connected
– May have dynamic IP addresses
– Do not communicate directly with each other
3
Q
P2P architecture(s)
A
- No always-on server
- Arbitrary end systems communicate directly
- Peers request service from other peers, provide service in return to other peers
- Self-scalability – as well as making new service demands, new peers typically also bring new service capacity
- Peers are intermittently connected and IP addresses change routinely
– Complex management
4
Q
P2P Networks: Napster
A
- Napster history: the rise
– 1/99: Napster version 1
– 5/99: company founded
– 12/99: first lawsuits
– 2000: 80 million users - Napster history: the fall
– Mid 2001: out of
business due to lawsuits
– Mid 2001: dozens of
decentralized P2P
alternatives
– 2003: growth of pay
services like iTunes
5
Q
How Napster worked
A
- Content location is centralised; but file transfer is decentralised
- Advantages:
– Fast lookup time - Disadvantages
– Single point of failure for lookup
– also: performance bottleneck
– Copyright infringement
6
Q
P2P Networks: Gnutella
A
- Gnutella history
– 2000: J. Frankel & T. Pepper released Gnutella
– Soon after: many other clients (e.g., Morpheus, Limewire, Bearshare)
– 2001: protocol enhancements, e.g., “supernodes/ultrapeers” - Query flooding
– Join: contact a few random(ish) nodes to become neighbours of
– Search: I ask my neighbours, who ask their neighbours - if a node has it, it replies to me
– Fetch: I get file directly from a node that claims to have it
7
Q
How Gnutella worked: Query flooding
A
- Advantages
– Fully decentralised - no bottleneck
– Distributed cost of searching - Disadvantages
– Potentially long search time
– Prone to “free-loading”
8
Q
P2P Networks: Kazaa
A
- KaZaA history
– 2001: created by Dutch company (Kazaa BV)
– A single network called FastTrack was used by other clients as well
– Eventually protocol changed so others could no longer use it - Super-node hierarchy
– Join: on startup, the client contacts a “supernode”
– Publish: client sends a list of its available files to its super-node
– Search: queries flooded among super-nodes
– Fetch: get file directly from one or more peers
9
Q
How KaZaa worked
A
10
Q
P2P Networks: BitTorrent
A
- BitTorrent history
– 2002: debuted by B. Cohen - Emphasis on efficient fetching, not searching
– Distribute same file to many peers
– Single publisher, many downloaders - Preventing “free-loading”
– Incentives for peers to contribute
11
Q
BitTorrent Components
A
12
Q
How BitTorrent works
A
- A new peer joining a torrent:
– registers with tracker to get list of peers, connects to subset of peers (“neighbours”)
– has no chunks initially, but will accumulate them over time from other peers - While downloading, peer uploads chunks to other peers
- Peer may change peers with whom it exchanges chunks
- Churn: peers may come and go
- Once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent
13
Q
P2P Sytems - Unstructured vs Structured
A
14
Q
Content Distribution (streaming)
A
- Challenge: how to stream content to hundreds of thousands of simultaneous users?
- Option 1: single, large “mega-server”
– Single point of failure
– Point of network congestion
– Long path to distant clients
– Multiple copies of video sent over outgoing link - Option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN)
– Close to users
– Resilient
15
Q
Content Distribution Networks
A
- CDN: stores copies of given content at CDN nodes
- Subscriber requests content from CDN
- Is directed to nearby copy, retrieves content
- may choose different copy if network is congested
