Recent Posts
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 깡돼후
- 자원부족
- 오블완
- JanusGateway
- VARCHAR (1)
- PytestPluginManager
- kotlin
- tolerated
- python
- taint
- 헥사고날아키텍처 #육각형아키텍처 #유스케이스
- vfr video
- JanusWebRTCGateway
- terminal
- table not found
- 겨울 부산
- 코루틴 컨텍스트
- Value too long for column
- addhooks
- 티스토리챌린지
- 달인막창
- 개성국밥
- mp4fpsmod
- 코루틴 빌더
- preemption #
- JanusWebRTC
- Spring Batch
- JanusWebRTCServer
- PersistenceContext
- pytest
Archives
너와 나의 스토리
[CH.2] Application Layer - P2P applications 본문
반응형
Pure P2P architecture
- 서버가 항상 온라인인 것 아니다 (no always on server)
- 임의의 end systems이 직접 통신한다
- peer가 간헐적으로 연결되고 IP 주소를 변경합니다.
- 예:
- file distribution (BitTorrent)
- VoIP(Skype)
*P2P: 분산된 어플리케이션이다. 왜냐하면 서로가 정보를 교환하는 다수의 엔드 시스템을 포함하고 있기 때문.
File distribution: client-server vs P2P
하나의 서버가 N명의 peers에게 파일(사이즈 F)을 분배하는데 얼마나 걸리는가?
peer의 upload/download capacity는 제한된 리소스이다.
File distribution: client-server
- server transmission: N개의 파일 사본을 순차적으로 전송(upload)해야한다.
- 하나의 카피를 보내는데 걸리는 시간: F/$u_{s}$
- N개의 카피를 보내는데 걸리는 시간: NF/$u_{s}$
- client: 각 클라이언트들은 파일 사본을 download해야한다.
- $d_{min}$ = min client download rate
- min client download time: F/$d_{min}$
File distribution time: P2P
- server transmission: 최소한 하나의 사본을 upload 해야한다.
- 하나의 카피를 보내는데 걸리는 시간: F/$u_{s}$
- client: 각 클라이언트는 파일 사본을 반드시 download한다.
- min client download time: F/$d_{min}$
- clients: 집합체가 NF bits를 download해야함
- 최대 업로드 속도(최대 업로드 속도로 제한했을 때): $u_s$+$\sum{u_i}$
- 즉, server-client는 N개의 파일을 올릴 때, 서버가 순차적으로(capacity만큼씩) 다 올려야하고, P2P에서는 peers들이 1개 이상씩 올려서 N개가 되면 되니까, P2P의 file distribution time이 더 짧다.
- BitTorrent
- tracker: 토렌트에 참여하는 동료를 track
- torrent: 파일들을 교환하는 peers 그룹
peer-to-peer vs client-server
Distributed Hash Table (DHT)
- DHT: a distributed P2P database
- 데이터베이스는 (key, value) 쌍을 가진다.
- key: 숫자, value: 사람 이름
- key: 영화 타이틀, value: IP 주소
- (key, value) 쌍을 백만명의 peers에게 분배한다.
- peer는 DHT를 key로 쿼리한다.
- DHT는 key에 매치되는 values를 리턴한다.
- peers는 (key, value) 쌍을 삽입할 수 있다.
어떻게 peer에게 key를 할당할까?
- central issue:
- peers에게 (key,value) 쌍 할당
- basic idea:
- 각 key를 정수로 변환
- 각 peer에게 정수를 할당
- 키에 가장 가까운 peer에 (key, value) 쌍을 넣음
DHT identifiers
- 각 peer에게 [0,$2^(n-1)] 범위의 정수 식별자를 부여
- 각 식별자는 n bits로 나타난다
- 각 key가 동일한 범위의 정수이여야 한다.
- 정수 key를 얻으려면 원래 key를 해시해야한다.
- 예: key=hash("Led Zeppelin IV")
- 이것이 분산 해시 테이블이라고 하는 이유이다.
peers에게 keys 할당
- 규칙: ID와 가까운 peer에게 key 할당
- convention in lecture: 가장 가까운 것은 바로 이 key의 후계자이다.
- 예: n=4; peers: 1,3,4,5,8,10,12,14;
- §key = 13, then successor peer = 14
- §key = 15, then successor peer = 1
출처:
반응형
'Computer Networks > 이론' 카테고리의 다른 글
[CH.3] Transport Layer - multiplexing/demultiplexing, Connectionless transport: UDP, principles of reliable data transfer (0) | 2019.10.07 |
---|---|
[CH.2] Socket programming with UDP and TCP (0) | 2019.10.04 |
[CH.2] Application - DNS (0) | 2019.10.03 |
[CH.2] electronic mail - SMTP, POP3, IMAP (0) | 2019.10.03 |
[CH.2] Application Layer - FTP (0) | 2019.10.03 |
Comments