P2P architecture
- 서버가 필수 아니다.
- peer가 다른 peer에게 request하고 response받는다. self scalability : 새로운 peer가 들어오면 새로운 service capacity, demands도 가져온다. -> 서버가 감당하기 어려운 부분들을 해결해준다.
client-server VS P2P
client-server : 파일을 upload, download 해주는 것은 서버의 역할이다. 따라서 수가 많아지면 그만큼 시간이 오래걸린다.
P2P : 서버는 최소 한번은 copy하고 업로드를 해야한다. 각 client는 반드시 파일을 다운받아야한다.
client-server구조는 client가 늘어나면 비례하게 시간이 커지고, P2P는 client가 많아져도 시간이 느리게 커진다(Log함수처럼)
따라서 client가 많아지면 P2P가 좋음!
P2P file distribution: BitTorrent
- file devided into 256Kb chunks
- peer join in torrent -> chunks가 없는 상태에서 다른 peer에게 chunk를 받는다.
requesting, sending file chuck
한 chunk가 없을때, 그 chunk를 받기 위해 다른 peer에게 요청한다.
누군가가 나한테 chunk를 요청하면 빠른 속도로 줄 수 있는 chunk를 준다. 이를 반복적으로 계속 chunk를 줘서 파일을 보내게 된다.
Video Streaming and CDNs
- Stream video traffic을 1억이 넘는 사용자에게 어떻게 제공할 것인가?
Solution : distributed, application-level infrastructure을 통해 제공한다
Video
픽셀로 구성된 연속된 이미지를 매우 빨리 보여주는 방식
모든 픽셀을 지속적으로 보내면 성능면에서 너무 떨어진다. 그래서 중복된 부분들은 redundancy하게 보낸다.
시간에 따라서 자꾸 변화하고, packet loss,delay 상황은 어떻게 해결할 것인가?
cient-side buffer을 통해 담아두었다가 재생시킴으로써 대응을 한다.
Multimedia Protocol : DASH
- server : 파일을 chunks들로 나눈다. 다른 비율로 encode한다 chunck들의 url을 제공해주는 manifest file을 제공해준다.
- client : 지속적으로 server-to-client bandwidth를 측정하여, 청크들을 요청한다.
client가 언제 chuck를 요청해야할지 결정한다.
CDNs: Content distribution networks
- single mega server는 성능이 안좋다. 따라서 distributed sites을 통해 분산시킨다.
Socket programming
- goal : learn how to build client-server applications that communicate using socket
두가지의 소켓 type가 있다.
- TCP : reliable datagram, byte stream-oriented
- UDP : unreliable datagram
기록하면서 성장하기!