P2P applications

• 항상 켜져있는 server가 없다.

• 임의의 end system간의 직접적인 통신을함

• peer들은 연결이 되었다가 끊어졌다를 반복함

  	ex) streaming, void(skype)

  p2p의 장점

  file distirbution

  파일을 배포

  client 방식과 p2p의 차이점

  ex) size F인 file을 N개의 peers에게 배포할때

  client server

• 모든 client들이 server에 요청해서 다운로드 받아야 합니다.

• server은 파일을 n번 보내야함
  하나의 copy를 보내는데 F/us n개를 보내려면 NF/Us

• F/dmin (min은 download가 가장 느린 client)

  최소 단위를 계산하기 위해
  전체 걸리는 시간 Dc-s>- max{NF/Us,F/dmin}

  N에 시간이 비례합니다.

  P2P방식

• server는 적어도 한번은 보내야합니다.
  F/Us

• clinet는 한번은 다운로드 받아야 합니다.
  F/dmin

• N개의 copy가 업로드 되어야 합니다.
  us+시그마ui

  N이 늘어나도 상대적으로 덜 비례함

  p2p를 이용하면 많은 node의 peer들이 파일을 공유하는데 더 짧은 시간이 걸린다.

BitTorrent

• file을 공유하려고 하면 256kb chunks로 나누게 됩니다.

• torrent 안에있는 peer들은 서로 file의 chunk들을 주고받는다.

  	torrent = 어떤 파일의 청크들을 교환하는 그런 peer들의 그룹
  
  	tracker = 어떤 torrent에 참여하는 peer들을 유지하는 server

이미지 첨부

peer가 torrent에 참여하게 되면 chunk가 없습니다.
tracker에게 참여를 알리고 다른 참여자의 정보를 받고 몇명에게 접속을해서 chunk들을 받습니다.
자신이 가진 chunk들을 upload를 하기도 합니다.
받을 chunk를 다받으면 나오게 됩니다. 안나오고 다른 사람들의 chunk를 받는것을 도와줄수 있습니다.

requesting chunks

peer들이 가지고 있는 가장 적은 chunk를 먼저 요청하는 방식

peers은 서로 다른 chunk를 가지고 있습니다. 누가 뭘가진지를 모르니 주기적으로 랜덤하게 물어봅니다.
필요한 chunk를 받을때 몇명에게 요청을해서 받을지를 결정하는 방식 rarest first라는 방식을 사용합니다.

sending chunks : tit for tat

상대방이 나에게 준적이 있으면 주겠다라는 방식

요청이 들어오면 몇명을 골라서 보내줘야하는데 어떻게 고를 것인가 (tit for tat)
현재 나에게 chunk를 주고 있는 peer들내에서 많이 준사람을 기준으로 우선순위를 정합니다. (highest rate)
매 10초마다 top4를 선정합니다.
주던 사람만 줄수 있기때문에 다른 방식또한 사용
30초마다 랜덤으로 한개의 peer을 정해서 보냄 (optimisicall unchoke)
내가 랜덤의 상대에거 줬기때문에 상대방에게 top4가 될수 있습니다.

이미지 첨부

Video streaming and CDNs

internet bandwidth의 가장 큰 소비자이다.

어떻게 많은 사용자에게 video를 보낼수 있는가?

server하나로 유지할수 없습니다.

해결방법 : distribute application level infrastructure
여려군데에 video dat을 저장

Multimedia : video

video는 1초에 24개의 이미지를 보여주면 움직이는 것 처럼 보이는 것
하나의 이미지는 pixel로 이루어져있음

이미지들의 중복이 되는 것들을 활용하면 압축할수 있습니다. 인접한 pixel이 같으면 묶어서 사용되는 데이터를 줄일수 있습니다.
이미지 별로 차이점만 저장하는 방식을 이용하여 데이터를 줄입니다.

인코딩 두가지 방법
CBR 고정된 bit rate로 인코딩
VBR 움직임이 많으 ㄴ경우 데이터를 줄일수 없어서 데이터가 많이필요함
변함을 그대로 반영하여 코딩

Streaming stored video

어떻게 보내는지 ?
이미지 첨부

DASH ()

server측에서 하나의 비디오 파일을 여러개의 chunk로 나눕니다.
각각의 chunk는 다른 rate로 encodeing됩니다.
여러개의 server에 나눠서 저장후에 manifest file을 생성합니다. 어떤 chunk가 어디 있는지를 URL로 표시합니다.

client는 server에게 요청해서 manifest file을 요청합니다.
그걸 가지고 언제 누구한테 받을지를 결정해야합니다.
server to client의 bandwidth를 확인해야합니다.
bandwidth에 맞는 chunk를 받습니다.
시간대 별로 다른 rate의 chunk를 요청받습니다.
측정한 시간에 사용가능한 bandwidth에 따라서 달라집니다.

이러한 결정을 하는 것은 client가 합니다.
지능은 client에 존재

• 언제 chunk를 요청할지
• 어떤 rate를 가진 chunk를 요청할지
• 어느 서버에 요청할지
  를 결정해야합니다 . manifest file에 있으므로 보고 결정
  장점
  client가 결정하므로 server의 역할이 줄어들음

server 입장
어떻게 수천만 client에 나의 file을 동시에 보낼수 있는가 ?

1방법 엄청큰 server을 설치

• 얘가 죽으면 아무도 서비스 받지못함
• 트레픽이 몰려서 주변에는 트레픽을 받지 못함
• 서버가 한군대 있으면 멀리있는 client는 오래걸림
• 같은 copy가 여러번 전송이 됩니다.

하나를 가지고 server를 운영하는건 말이안됨

2 방법
CDN사용
지리적으로 분산이 되어있는 site(server)에 video copy를 저장
어디에 site를 둘것인가 2가지 방법
1. enter deep
지구상에 있는 많은 access network에 server을 두는것

2. 적은 수의 커다란 cluster을 만들고 넣음

over the top이라고 부름 ott
여러개의 server을 설치해서 그것들이 file을 가지고 있는 것 분산해서 service함

ott를 구현할때 어려운 것은?
인터넷이 혼잡해질수 있음
(traffic이 많아서 bandwidth가 달라짐)
어떤 노드로 부터 받을지 어떤 content를 어디에 둬야하는지 등을 생각해보아야함

CDN content access
이미지 첨부

Netflix같은 경우
manifest안에는 어느청크가 어디 있다라는 정보를 다 가지고있습니다.

DASH는 HTTP를 사용하여 서비스

socket programming with udp and tcp

socket programming이란?

transprot와 application 사이에 있는 protocol 비유하자면 door process간의 comunication하기 위한 문이다.

socket이 만들어질때 부터 상대방에 대한 정보를 가지고 있어서 보내게됨

사진 첨부

소켓을 만들때 TCP를 쓸것인지 UDP를 쓸것인지 정의해야합니다.
TCP는 reliable, byte oriented stream
UDP는 unreliabl, datagram

client는 characters type의 data를 읽어준다.
UDP는 connection이 없습ㄴ디ㅏ. data를 보내기전에 handshaking하는 경우가 없어서 매번 보낼때마다 ip address와 port를 항상 packet을 보낼때 붙여줘야합니다.

UDP는 data가 lost될수있고 out-of-order sender에서 여러개를 보냈지만 중간에 순서가 바뀔수 있습니다.
groups of byte 내가 원하는 만큼 보내주지만 unreliable하게 보내집니다.

portnumber는 16-bit

TCP를 사용하려면 connection을 먼저 만들어야 합니다.
client가 server에 contect해야합니다.
socket을 만들때 ip address와 port를 명시합니다.
connection이 생성되면 byte를 계속 보냅니다.