P2P applications

DNS Records#

• RR format: (name, value, type, ttl)

  • Type=A (DNS의 가장 기본적인 기능)

    • name = hostname
    • value = IP address
  • Type=NS (도메인을 담당하는 name server)

    • name = domain
    • value = hostname of authoritative name server for this domain
  • Type=CNAME (alias와 alias를 매핑)

    • name = alias name for some “canonical” (the real) name
    • value = canonical name
  • Type=MX (메일 서버)

    • value = name of mailserver associated with name

DNS 서버 분류에 따른 RR저장 정보#

• Local name server
• Root = Top level 도메인을 담당하는 TLD (.com, .net ...) 정보를 가지고있음 ⇒ NS
• TLD = 각 기관을 담당하는 Authoritative서버에 대한 정보를 가지고있음 ⇒ NS
• Authoritative = 자신의 기관내 도메인-IP 매핑 정보를 가지고 있음 ⇒ A

DNS protocol, messages#

• identification = 쿼리를 보낼때 해당 필드에 값을 넣어서 보내면 reply가 해당 값을 복사해서 보냄
• flags

  • query or reply
  • recursion desired (recursion을 필요로 하는가?)
  • recursion available (recursion을 제공해줄 수 있는가?)
  • reply is authoritative
• variable

  • name, type fields for a query
  • RRs in response to query
  • records for authoritative servers
  • additional "helpful" info that may be used

DNS 레코드에 삽입되는 과정#

1. authoritative server를 구입

   1. 웹페이지 접속을 위한 type A레코드를 입력
   2. 메일서버를 위해 type MX와 A를 입력
2. DNS에 등록하기 위해 관리하는 기관에 알려야 함

   1. 자신의 authoritative 주소와 이름을 알려줘야 함
   2. .com을 담당하는 TLD 서버에 두개의 RR을 추가함

1. 네트워크 유토피아라는 회사는 만들어지고 authoritative DNS를 구입한다.

   1. authoritative DNS에 자신의 회사내 컴퓨터들에 대해서 RR을 등록함
2. Network Registrar기관에 authoritative DNS를 등록함
3. 해당 정보를 받은 Network Registrar는 .com TLD에게 2개의 Record를 추가함

   1. 이름을 등록하는 NS와 해당 record의 IP를 나타내는 A레코드를 등록함
4. 어떤 사용자가 네트워크 유토피아에 접속하기 위해 웹브라우저에 요청

   1. 자신의 로컬 DNS에 쿼리를 던짐
5. Local name server의 DNS는 원칙적으로는 Root DNS서버에 DNS 쿼리를 던짐
6. TLD는 해당 요청 받아서 Local name server에 응답쿼리를 전송함
7. 네트워크 유토피아의 authoritative DNS에 A타입의 레코드를 쿼리 요청
8. 다시 A타입의 쿼리 응답을 전송함
9. 일련의 DNS쿼리 과정을 거치고 난 후 다시 클라이언트에게 해당 IP를 전달
10. 브라우저가 IP를 통해서 네트워크 유토피아 홈페이지에 접속

P2P applicaion#

Pure P2P architecture#

• no always-on server
• 임의의 end-systems 끼리 직접연결되어 커뮤니케이션함
• peer ⇒ P2P에 임의 연결된 end-system
• 피어들은 네트워크에 연결되었다 해제되었다하고, IP주소가 바뀌기도함

  • BitTorrent, KanKan, Skype

P2P 구조의 장점#

• 확장성

  • P2P 구조에서는 각 end-system이 service request를 가지고 들어올뿐만 아니라 서비스를 제공하기 때문에 확장성이 있다.

• Us = Server upload capacity

  • 크면 클수록 서버가 단위시간당 upload양은 많아짐
  • 단위 시간당 업로드 양을 의미함
• Di = peer i download capacity

  • 피어의 다운로드 시간다위 양
• Ui = peer i upload capacitiy

  • 일반적으로 서버쪽 upload capacity가 큼

클라이언트-서버 모델의 배포 시간#

• File 하나를 서버가 업로드 시간 = F/Us
• File N개를 서버가 업로드 하는 시간 =NF/Us ⇒ Server가 File을 Trassmit하는데 걸리는 시간
• Dmin = Di중에서 가장 적은값을 가지는 걸 의미함
• 클라이언트가 파일을 다운로드 받는 최대 시간 = F/Dmin

P2P 모델의 배포 시간#

• 서버가 파일을 한번 업로드 해야함 = F/Us
• 클라이언트가 파일울 다운로드 받는 최대 시간 = F/Dmin
• N명의 클라이언트가 있다고 가정할때 = FS bits

  • 최대 업로드 속도 = Us + $\sum_{i=1}^{N} u_i$

클라이언트-서버 VS P2P 모델 배포시간 비교#

• 클라이언트 업로드 시간
• $F/u$ = 1시간
• $u_s$ = $10u$
• $d_{min}\geq u_s$

BitTorrent#

• 비트토렌트에서는 256kb의 청크로 파일을 나눔
• torrent = 파일의 청크를 가지고 교환하는 사용자의 그룹
• tracker = 각 토렌트에 속하는 피어들이 누구인지를 트레킹하는 서버

비트토렌트에 새로운 사용자가 Join했을 경우#

1. tracker 서버를 통해 원하는 file을 가진 토렌트에 참여
2. 참가 당시엔 청크를 가지고있지 않지만, 누군가에게 청크를 받음과 동시에 다른 사용자를 위해 청크를 공유하는 상태가 됨
3. 피어들끼리 청크를 지속적으로 교환해서 결국 파일을 전부 얻게됨
4. 파일을 다운로드 하는 중 피어가 없어지기도 하고 생기기도 함

   1. 이러한 피어의 변화를 churn이라고 함

이러한 시스템에서 중요한 부분#

• 참여자는 정기적으로 이웃들에게 가지고있는 청크를 물어봄

  • 이웃들이 가지지 않는 청크가 있으면 받고
  • 가지고있는 청크중 가장 수가 적은 청크를 먼저 받음
• tic-for-tat 원칙으로 이웃과 청크를 교환함

  • 자기에게 잘 공급해주는 이웃에게 자기도 잘 공급해줌
  • 잘 공급받기 위해서는 좋은 공급자기 되어야함

    • 각 피어는 10초마다 자신에게 공급을 잘해주는 top 4 peer를 선정해 자기도 해당피어에게 잘 공급해줌
  • 계속 top4와 교환하다가도 30초마다 랜덤하게 다른 피어와 교환을 하도록함

    • 새로 참여한 피어를 위한 조치
    • 더 좋은 파트너를 찾기위한 조치기도 함