: 임의의 end-system끼리 직접 소통하는 것이 p2p이다. 이때 여기에서의 end-system을 peer라고 한다.
: 예제에서의 bit Torrent = file distribution system.
: p2p구조의 장점은 '확장성'이다.
: 서비스에 요청을 할 뿐만 아니라 서비스를 처리할 능력도 가지고 있기 때문이다.
용어정리
: Us = server upload capacity.
: Di = peer i download capacity (peer는 데이터를 받기도 한다.)
: Ui = peer i upload capacity
==> 당연히 Us > Ui이다.
: 파일의 크기가 F. 서버가 파일 하나 업로드하는데 걸리는 시간(F/Us)
: N개 업로드 하는데 걸리는 시간(NF/Us) == 서버가 업로드해야하는 총량
: 그래서 서버가 파일을 transmit하는데 걸리는 시간이 NF/Us이다. distribution이 완성이 되려면 client가 파일을 받기도 해야함. 여기에 영향을 주는 것이 Di. 이때 i=1~N일 때, Di중 가장 작은 값을 가지는 것을 Dmin이라고 한다. 따라서 클라이언트가 다운로딩하는데 걸리는 최대 시간은 (F/Dmin)이 된다.
: 파일을 distribute하는 시간은 downloading 시간과, 서버에서 uploading하는 시간 중 maximum이 Distribute(c-s)를 결정할 것이다.
: 근데 이때 다운로드 받고자하는 사람(=N)이 계속 커진다면, 당연하게도 서버의 uploading 시간이 끼치는 영향이 더 커질 것이다.(파일 downloading 시간은 고정값이다.)
: P2P 구조이다. 여기서도 서버가 한 번은 업로드해야한다고 가정하자.(그렇지 않은 p2p 시스템도 존재한다.) 서버가 업로드하는 시간이 바로 F/Us
: 클라이언트가 다운받는 최대 시간 F/Dmin
: N명의 클라이언트가 있다고 할 때, 이 사람들이 다 파일을 갖기 위해서는 distribute되는 양이 NF bits이다. 이거 전달하는데 사용되는 uploading capacity는 (Us+모든 클라이언트의 Ui)의 합이다. (i=1~N)
: P2P 구조에서는, N이 늘어나면 늘어날 수록 분모도 늘어나게 된다.
: 결론 P2P 구조의 경우에는 파일을 원하는 클라이언트의 수가 늘어나면 그와 더불어 파일을 업로드할 수 있는 capability도 늘어나므로 원하는 client의 수에 비례해서 파일 업로드의 시간이 늘어나진 않는다. ==> 확장성이 좋다.
BitTorrent
: P2P 구조를 따르는 application인 BitTorrent
: BitTorrent에서는 파일을 256kb의 chunk로 나눈다.
: torrent = 파일의 chunk를 교환하는 사용자들의 그룹
: tracker라는 서버는 각 torrent 별로 torrent에 속하는 peer가 누구인지 keep tracking한다.
: 해당 빗토렌트에 '앨리스'가 들어오면 tracker에 컨택해서 원하는 chunk의 peers 찾음 -> 거기 접속해서 원하는 파일의 청크를 받는다.
: 맨 처음에 앨리스는 청크를 하나도 가지고 있지 않는다.
: 근데 앨리스도 subset of file인 청크를 가지고 있게 됨. (= 청크를 받는 동시에 다른 peer에게 청크를 전송해주는 역할을 하게 된다.)
: Peer들은 system entity가 아니므로 자기 필요에 따라서 움직인다. 파일을 다운 받다가 peer가 없어지기도하고 새로운 애가 들어오기도 한다.(peer가 들어왔다가 나갔다하는 것 = churn = P2P에서의 문제점)
: 그렇다면 churn이 발생했을 때, 다른 peer를 빨리 발견해야할 것이고 또 selfish한 peer가 없도록 만드는 방식이 있어야 한다.
: Alice는 정기적으로 자기 peer에게 '무엇을 가지고 있는지' 묻는다. 이웃이 가지고 있는데 자기는 없는 것이 있으면 request를 통해서 받는다. 근데 downloading capacity가 있으므로 급한 것부터 먼저 받겠지... -> 여기서의 급한 것은 이웃 중에서 갖고 있는 chunk가 가장 적은 애가 제일 급하다고 본다. (churn에 의해서 rare한 chunk를 갖고 있는애가 없어진다면 문제이기 때문에) ==> 그래서 'rarest first'방식으로 요청을 한다.
: 그리고 tit-for-that 방식으로 청크를 교환한다. 나한테 공급을 잘해주는 애한테 나도 잘 주는 것. (selfish한 peer가 살아남지 못하도록 한다.)
: 나한테 제공을 잘해주는 Top 4 peer를 선정하는 것.
==> 이러면 top 4에게만 받는 문제 생길 수 있음.. 상황이 바뀌는데 그것을 캐치하지 못할 수도 있음.
: 그래서 top4랑 교환하면서 30초 마다 아무 peer나 접근해서 choking을 한다! (- 더 좋은 파트너를 계속 찾아나가서 파일을 빠른 시간안에 받아올 수 있게 된다.
: 하지만 저작권 문제가 있음 ㅠ 이게 제일 큰 문제
: 불특정한 서버가 존재하게 되므로 저작권을 강력하게 보호할 방법이 없음.
