CH2. Application Layer (3)

5. P2P applications

 - properties

-> 중앙 관리 체제가 아니다.

-> 계층 구조가 아니다. (모든 node들이 client 나 server가 될수가 있다.)

-> 확장성을 가지고 있다.

-> 어떤 peer에서든 사용이 가능하다.

-> System globally unrelible

 

 - Napster : centralized directory

-> File-sharing system      -> 대게 분산된 시스템을 가지고 있다.           : The location of a document is centralized           : 전송은 peer간에 일어난다.           : querying과정이 빠르게 일어날수 있다. (cetralized directory server에서 해당 데이터를 가진 IP addr를 받아 그 피어와 통신을 하게 된다.)

 

 - Gnutella : Query flooding

-> 완전히 분산된 P2P protocol

-> public domain protocol

-> Gnutella protocol

    : Based on broadcast/back-propagation mechanism over an overlay network

    : Message type (ping/pong : 그룹 멤버간에 서로 살아 있는지 확인하는 종류, Query/Query Hit: 데이터를 찾기 위해 사용이 된다.)

-> 매우 단순하다, 하지만 원하는 정보를 찾기까지의 시간이 오래 걸리는 단점이 존재한다.

-> 너무많은 query traffic 이 발생할수도 있는데 이는 TTL(TTL이 0이 되면 해당 query를 버린다.)을 이용하여 방지한다.

-> query flooding을 제한하다보면 데이터가 다른곳에 있더라도 TTL 보다 더 먼곳에 있다면 없다고 판단을한다.

-> Maintenace of overlay network

-> Free riding : 많은 사람들이 데이터를 받아가긴 하지만 그중  실제 데이터를 제공하는 사람은 전체의 1%가량 밖에 되지 않는다.

Join operation      -> 5 번의 과정에서는 user C가 자신과 연결된 peer들에게 ping을 보내는 것으로 ping 을 받게된 neighbor들은 해당 ping을 자신의 neighbor에게도 보내게 된다.      -> ping을 보내는 과정중 userB는 userA에게도 user C로 부터 출발한 ping을 보내게 되고 user A는 user C의 존재를 새로이 알게 된다.      -> ping(초기 발신자의 IP addr이 포함되어 있다.) 통해 user A는 userC의 IP address를 알수가 있고 해당 정보를 이용하여 user C와 연결이 되게 된다.        -> 이러한 과정을 통해 약 3개의 neighbor들을 가질수가 있다.

 

- Search      -> query message : 존재하는 TCP연결을 통해 전송이된다.      -> query hit : 원래 왔던 경로의 반대로 전달이된다.      -> Scalability : limited scope flooding           => flooding의 횟수를 제한을 두어 계속해서 query가 다른 neigthbor에게 넘어가는것을 막게 된다. 이는 너무 많은 query가 생성 되는 것을 막게 해준다.

 

 - Compare Cient-server, P2P architectures

N : 연결된 peer(client)들의 갯수      -> P2P를 통해 전송하는것이 여러개가 연결이 됐을때 Client-server형식보다 좋은 효율을 낼수 있음을 보여준다.

 

 - Distributed Hash Table(DHT)

-> A distributed P2P database

-> centralized directory 없이 Hash table들을 분산시켜 저장을 시킨 것으로 기존의 centralized P2P형식보다 더 빠르다.

-> 해당 hash table들이 어떻게 분산되어 저장이 되었는지를 잘 정의를 해야한다.

-> database는 (object id, value)쌍을 가지고 있다.

    => object id : hashing function을 돌리게 되면 key값이 나오게 된다.

    => value : 해당 object id(key)에 해당하는 값을 가지고 있게 된다.(데이터)

->  DB들은 key값에 맞는 value값들을 반환하게 되고 각 피어들은 전체 DB에 대한 정보를 조금씩 나누어 가지게 된다.

 

 - Basic idea of assingning keys to peers

-> Peer ID와 object(item) ID는 같은 범위를 사용하여야 한다. : [0,(2^n)-1]

1. 각각이 아이템들과 node들에 적절한 key값들을 설정하여 준다.      2. 각각의 node들을 적절히 연결을 시켜준다. (ring 구조, tree구조가 존재한다.)      3. node들에 적절히 아이템들을 등록시켜준다        -> 이때 각각의 node 번호에 Item의 key값이 가장 가까운것을 assign을 해주는 방식으로 해준다.

 

 - Consistent hashing using a ring

-> hashing을 구성하는 과정중 새롭게 node가 참여하거나 빠지는 상황을 잘 대처할수 있도록 짜는 것이 중요하다.

1. 먼저 키들을 같은 범위내에서 설정하여 각각의 node와 item들에 설정을 해준다.     2. 각각의 node들을 연결시켜준다. (이때 연결 순서는 작은 수에서 높은수로 갈수 있도록한다, 각각의 node는 next node가 누군지에 대해 아는정도이다.)     3. succ(x) 라는 함수와 함께 item들이 node에 맵핑되게 된다.         => succ(x)는 item의 key 값보다 크거나 같은 node에 저장이 되는 형식이다.          => 만약 item의 key가 1,5,9이고 node가 0,5,12라면 item1,5 는 node5로 맵핑이 되고 item 9는 node 12로 맵핑이 되는 형식이다.

-> 만약 여기서 하나의 node가 사라지게 된다면 그곳에 맵핑된 item은 가장 가까운(자신보다 큰곳으로) 맵핑이 새로이 이루어 지게 된다.

-> 데이터를 찾는데 O(N) (N=node의 갯수)가 걸리지만 binary search를 이용할시 O(logN)이 될수가 있다.

 

6. Video Streaming and content distribution networks(CDNs)

    : 요즘 internet bandwidth의 대부분은 비디오에 의해 사용이 되어지고 있다.

 - Video Encoding

-> 비디오는 수많은 연속적인 이미지를 지속적인 rate로 표시하여 주는 것이다.

-> 이미지의 경우 digital image를 사용하는데 이는 수많은 pixel 들로 이루어 져있다.

-> 많은 pixel들을 계속 표현하기에는 많은 데이터가 필요하기에 필요 부분만 새로이 전송하는등의 방식을 사용한다.(?)

-> Encoding 방식 : CBR(encoding rate가 고정적인것), VBR(encoding rate가 가변적인것)

 

 - Streaming multimedia

-> Traditional streaming service

     : RTSP(Real-Time Streaming Protocol)을 기본으로 했다.

     : 서버에 주로 많은 부담이 되게 됐다.

-> Streaming over HTTP (TCP사용)

-> Streaming multimedial : DASH(Dynamic, Adaptive Streaming over HTTP)

     : client가 bandwidth를 측정하고 chunk file을요구하는 방식으로 client에게 부담을 주게 된다.

     : buffer starvation, overflow does not occur

     : higer quality when more bandwidth available

     : can request from URL server that is "close" to client or has high available bandwidth

Server      -> video file을 chunk로 나누어 저장하여 둔다.      -> 각각의 chunk는 서로 다른 rate로 encod되어 저장이 되어진다.            (한 chunk에 여러 종류의 rate chunk가 있는것)      -> manifest file : 각각의 chunk들에 대한 URL을 제공한다.

Client      -> manifest file을 가장 먼저 요청을 하게 된다.           (In MPEG-DASH, called as a MPD)      -> 지속적으로 서버와 클라이언트 사이의 bandwidth를 측정한다.      -> manifest file을 보고 해당 URL로 chunk를 요청을 한다.      -> 현재 주어진 bandwidth를 보고 지속가능한 최대의 coding rate를 선택한다.      -> 시간에 따라 다른 coding rate의 chunk file을 받을수가 있다.           (각 시간마다 적절한 bandwidth에 따른다.)

 - CDN (Content Distribution Networks)

    : 동시에 여러명의 유저가 비디오를 요청시 어떻게 대응을 할것인가에 대한 해결책

-> 지역적으로 분산된 서버에 여러개의 복사된 비디오들을 저장해 두는것.

     => Enter deep : 서버를 세계 곳곳의 네트워크에 접속을 시키는 형식이다(user에게 가까워 user는 빠르다고 느끼게 된다.)

     => Bring home : 적은 수의  용량이 큰 클러스터를 세우고 네트워크에 접속을 시키는 형식이다. (ISP 근처에 만들어 둔다.)

-> OTT(over the top) : 인터넷을 통해 방송 프로그램·영화·교육 등 각종 미디어 콘텐츠를 제공하는 서비스