IPFS - BitTorrent
BitTorrent Protocol 의 동작
BitTorrent (BT for short) 는 다운로드하는 동안 각 다운로더가 다른 다운로더에 다운로드 한 데이터를 제공하는 파일 배포 프로토콜 입니다. 일반적인 FTP 및 HTTP 프로토콜에서 모든 다운로더는 중앙 서버에서 데이터를 요청하며 다양한 다운로더 간에는 상호 작용이 없습니다. 많은 수의 다운로더가 동일한 데이터를 동시에 다운로드하면 중앙 서버의 처리 성능 및 대역폭 제한으로 인해 다운로드 데이터가 매우 느려지고 일부 사용자는 서버에 연결할 수 없습니다. BT 다운로드는 다운로드 파일 공유 다운로드 기능이 더 빠르게 다운로드 합니다.
1. BitTorrent 구성
BitTorrent 프로토콜을 기반으로하는 파일 배포 시스템은 다음 구성 요소로 이루어져 있습니다. (1) 웹 서버, (2) 시드 파일, (3) 트래커 서버, (4) 원본 문서 제공자, (5) 웹 브라우저, (6) 다운로더 입니다.
시드 파일은 웹 서버에 저장되며 다운로더는 먼저 웹 서버에서 시드 파일을 다운로드해야 합니다. 시드 파일은 메타 파일이라고도하며 파일 이름, 파일 크기 및 트래커 서버의 주소와 같은 공유 파일에 대한 정보를 저장합니다. 시드 파일은 매우 작으며 일반적으로 1GB 공유 파일의 시드 파일은 100KB 미만이며 시드 파일에는 .torrent 접미사가 붙습니다. 시드 파일의 트래커 서버 주소는 파일을 기록하는 모든 노드의 IP 및 포트입니다. 시드 파일은 원본 파일 제공자가 만듭니다.
제작 프로세스: 먼저 BT 클라이언트를 다운로드 한 다음 새 BT 시드 작업을 만들고 공유 할 파일을 선택한 다음 제작 과정을 클릭하여 시드 파일을 완성합니다. 사용자는 시드 파일을 네트워크에 업로드하고 다른 사용자는 시드 파일을 통해 해당 파일 내용을 가져올 수 있습니다.
사용자가 시드 파일을 다운로드하는 프로세스: 사용자는 먼저 BT 시드 파일을 다운로드 한 다음 다른 다운로드 클라이언트에 새 BT 작업을 만들고 시드 파일을 선택하고 클릭하여 다운로드를 시작합니다. 원칙적으로 클라이언트는 먼저 시드 파일을 구문 분석하고 트래커 서버의 주소를 포함하여 다운로드 할 공유 파일에 대한 정보를 얻습니다. 클라이언트는 트래커에 연결하여 현재 파일을 다운로드하는 모든 다운로더의 IP 및 포트를 가져옵니다. 그런 다음 클라이언트는 IP 및 포트를 기반으로 다른 다운로더에 연결하고 다운로드 합니다.
공유 파일은 일반적으로 크기가 256KB 인 조각이라고하는 동일한 크기의 블록으로 논리적으로 나뉩니다. 공유 파일의 경우 파일의 첫 번째 바이트부터 256K (즉 262144) 바이트가 첫 번째 파일이며 두 번째 파일은 256K + 1 바이트에서 512K 번째 바이트까지 입니다. 해시 파일에는 각 조각의 해시 값이 들어 있습니다. BT 프로토콜은 Sha1 알고리즘을 사용하여 각 조각에 대해 각 조각의 지문으로 20 바이트 해시 값을 생성하도록 지정합니다. 클라이언트가 조각을 다운로드 할 때마다 Peice 는 Sha1 알고리즘을 사용하여 해시 값을 계산하고 시드 파일에 저장된 조각의 해시 값과 비교합니다. 일치하면 완료되고 올바른 조각이 다운로드 됩니다. 조각이 다운로드되면 다른 조각에 다운로드 할 수 있습니다. 실제 업로드 및 다운로드에서 각 조각은 동일한 크기의 조각으로 분할되며 각 조각은 16KB (16384 바이트)로 고정됩니다. 피어 간의 각 전송은 슬라이스 단위입니다.
위 설명으로부터 알 수 있는 바와 같이 BT 클라이언트는 주로 다운로드 할 파일의 일부 정보를 얻기 위해 시드 파일을 파싱하고 피어의 IP 주소 및 포트를 얻기 위해 트래커를 연결하고 피어를 연결하여 데이터를 수행하는 기능을 포함하고 있습니다. 게시할 제공된 공유 파일의 시드 파일을 업로드 및 다운로드하고 생성합니다. 시드 파일과 트래커의 반환 정보는 모두 B 인코딩이라는 간단하고 효율적 방법으로 인코딩됩니다. 클라이언트는 HTTP 프로토콜을 기반으로 추적기와 정보를 교환하며 트래커 자체는 웹 서버로 존재합니다. 클라이언트는 연결 지향적이고 안정적인 전송 프로토콜인 TCP 를 사용하여 다른 피어와 통신합니다.
2. B 인코딩
시드 파일과 트래커에서 반환 한 정보는 모두 B 인코딩 입니다. 시드 파일과 트래커의 반환 정보를 구문 분석하고 처리하려면 먼저 B 인코딩 규칙을 숙지해야합니다. B 인코딩에는 4 가지 유형이 있습니다.
- 정수: 인코딩 형식은 i<십진수>e 입니다. 예를 들어, 10 진수 정수는 8이며 B 코딩 후에는 i8e 이고 -6이 인코딩 된 후에는 i-6e 입니다.
- 문자열 유형: 인코딩 형식은 <길이의 문자열="">:<문자열> 입니다. 예를 들어 hello 문자열은 B:5:hello 로 인코딩 됩니다.
- 목록 유형: 인코딩 형식은 l<모든 B="" 형="" 인코딩="" 조합="">e입니다. l은 목록의 첫 글자입니다. 두 개의 문자열 목록과 같은 문자열은 B 인코딩이 l5:chain5:blocke 이고 B 가 인코딩 된 후 문자열의 정수 목록 3과 문자열 hi 가 li3e2:hie 인 경우 chain, block 입니다.
3. 시드 파일의 구조
시드 파일의 키워드는 다음과 같습니다.
| 이름 | 유형 | 의미 |
|---|---|---|
| announce | string | TrackerServer 주소 |
| announce-list | List of list | TrackerServer 그룹 목록 |
| info | Dict (k/v 컬렉션) | 이 키워드에 해당하는 값은 사전이며이 키워드에 해당하는 값은 사전이며 “singel file”과 “multiple file”의 두 가지 모드, 파일 모드 및 다중 파일 모드가 있습니다. 단일 파일 모드는 공유 할 파일이 하나만 있다는 것을 의미하며 다중 파일 모드는 공유를 위해 둘 이상의 파일을 제공하지만 두 개 이상을 제공하는 것을 의미합니다. BT 소프트웨어를 사용하여 영화를 다운로드하면 영화의 상단과 하단이 별도의 파일에 배치 될 수 있습니다. |
| publisher | string | 시드 게시자 이름 |
| publisher-url | string | 시드 게시자 URL |
| nodes | list | DHT (분산 해시 테이블) 노드 목록 |
| encoding | string | 시드 파일의 문자 인코딩 (예: UTF-8) |
seed 파일에서 가장 중요한 키워드는 info 입니다. 단일 파일 모드, 다중 파일 모드 상관없이 사전에는 다음 표와 같은 키워드가 들어 있습니다.
| 키워드 | 의미 |
|---|---|
| piece length | 각 조각의 길이는 B 코드의 정수이며 일반적으로 256K 또는 512K 또는 128K 인 i262144e 입니다. |
| pieces | 해당 값은 각 조각의 해시 값을 저장하는 문자열이며 이 문자열의 길이는 각 조각의 해시 값이 20 바이트이기 때문에 20의 배수여야 합니다. |
| private | 값이 1이면 클라이언트가 트래커, 즉 피어의 IP 주소와 포트 번호를 연결하여 다른 다운로더를 가져와야 함을 나타내며, 0이면 클라이언트가 다른 방법을 통해 피어의 IP 주소와 포트를 얻을 수 있습니다. DHT는 피어를 분산 방식으로 얻는 방법인 분산 해시 테이블 (Distribute Hash Tabel)입니다. 많은 BT 클라이언트는 이제 피어를 얻기 위해 트래커를 연결하거나 DHT 를 모두 지원합니다. 시드 파일에 개인 키워드가 없으면 트래커를 연결하여 피어를 가져와야 함을 의미합니다. |
단일 파일 모드 시드 파일의 경우 info 값은 다음 표에 표시된 키워드도 포함합니다.
| 키워드 | 의미 |
|---|---|
| name | 공유 파일의 파일 이름, 즉 다운로드 할 파일의 파일 이름 |
| length | 공유 파일의 길이 (바이트) |
| md5sum | 선택적으로 공유 파일의 md5 값입니다.이 값은 BT 프로토콜에서 전혀 사용되지 않습니다. |
다중 파일 모드 시드 파일의 경우 정보 값은 다음 표에 표시된 키워드도 포함합니다.
| 키워드 | 의미 |
|---|---|
| name | 모든 공유 파일이 저장된 폴더 이름 |
| files | 이 값은 여러 개의 사전이있는 목록으로 각 공유 파일은 사전입니다. 사전에는 3 개의 키워드가 포함되어 있습니다. |
Files 의 각 공유 파일의 키워드는 다음 표에 표시된 사전입니다.
| 키워드 | 의미 |
|---|---|
| length | 공유 파일의 길이 (바이트) |
| md5sum | 선택적 |
| path | 공유 파일의 경로와 파일 이름을 저장 |
4. 트래커와 상호 작용
시드 파일을 구문 분석하고 트래커 서버의 URL 을 얻으면 트래커와 상호 작용할 수 있습니다. 트래커와 상호 작용에는 두 가지 주요 목적이 있습니다. 하나는 트래커가 관련 통계를 수행 할 수 있도록 트래커에게 다운로드 진행 상황을 알리는 것이며 다른 하나는 현재 동일한 공유 파일을 다운로드하는 피어의 IP 주소와 포트 번호를 얻는 것입니다. 클라이언트는 HTTP 프로토콜을 사용하여 트래커와 통신합니다. 트래커는 HTTP GET 메소드를 통해 요청을 받고 요청 구성에는 트래커의 URL 이 옵니다. 예) http://tk.greedland.net/announce?param1=value1¶m2=value2. 트래커에 클라이언트가 보낸 GET 요청에서 매개 변수는 일반적으로 아래 표와 같습니다.
| 매개변수 | 의미 |
|---|---|
| info_hash | seed 파일의 info 키워드에 해당하는 값은 Sha1 알고리즘에 의해 계산되며 해시 값은 info_hash 매개 변수에 해당하는 값이며 해시 값의 길이는 20 바이트로 고정 |
| peer_id | 자체를 식별하는 데 사용되는 파일을 다운로드하기 전에 임의의 방식으로 각 클라이언트가 생성 한 20 바이트 식별자 및 길이도 고정 |
| port | 다른 피어의 연결 요청을 수신하는 데 사용되는 수신 포트 번호 |
| uploaded | 현재 총 업로드 (바이트) |
| downloaded | 현재 총 다운로드 (바이트) |
| left | 다운로드 할 바이트 수 (바이트) |
| compact | 매개 변수의 값은 일반적으로 1 |
| event | 시작, 완료, 중지 중 하나입니다. 클라이언트가 Tracker와 처음으로 통신하면 값이 시작됩니다. 다운로드가 완료되면 값이 완료되고 클라이언트가 닫으려고하면 값이 중지됩니다. |
| ip | 선택적으로 클라이언트의 IP 주소가 트래커에 통지됩니다. 트래커는 클라이언트가 트래커에 보내는 IP 데이터 패킷을 분석하여 클라이언트의 IP 주소를 얻을 수 있으므로 선택적입니다. 일반적으로 클라이언트의 IP 는 지정되지 않습니다. |
| numwant | 선택적으로 트래커에 의해 반환 될 피어 IP 주소 및 포트 번호의 수. 이 매개 변수가 기본값이면 50 개의 피어의 IP 주소와 포트 번호가 기본적으로 반환됩니다. |
| key | 선택적으로 이 값은 클라이언트 식별에 사용되는 임의의 숫자입니다. 클라이언트가 peer_id 에 의해 식별 되었기 때문에이 매개 변수는 일반적으로 사용되지 않습니다. |
| trackerid | 선택 사항, 일반적으로 사용되지 않음 |
트래커 서버의 반환 정보는 B-인코딩 된 사전입니다. 아래 표와 같이 키워드가 포함되어 있습니다.
| 키워드 | 의미 |
|---|---|
| failure reason | 키워드에 해당하는 값은 GET 요청 실패의 이유를 나타내는 읽을 수있는 문자열이며, 반환 메시지에이 키워드가 포함되어 있으면 다른 키워드가 포함되지 않습니다. |
| warnging message | 이 키워드에 해당하는 값은 읽을 수있는 경고 문자열입니다. |
| interval | 다음 번에 트래커에 연결하기 전에 클라이언트가 대기하는 시간 (초)을 나타냅니다. |
| min interval | 클라이언트가 다음에 트래커에 연결하기 전에 대기하는 최소 시간 (초)을 나타냅니다. |
| tracker id | 트래커 ID 표시 |
| complete | 현재 얼마나 많은 피어가 전체 공유 파일을 다운로드하고 있는지를 나타내는 정수 |
| incomplete | 공유 파일을 현재 다운로드하지 않은 피어 수를 나타내는 정수 |
| peers | 각 피어의 IP 와 포트 번호를 반환하며, 값은 문자열입니다. 첫 번째는 첫 번째 피어의 IP 주소, 그 다음 포트 번호, 두 번째 피어의 IP 주소, 포트 번호 등입니다. |
다음은 Tracker 서버에 전송 된 HTTP GET 요청의 예입니다: http://tk.greedland.net/announce?info_hash=01234567890123456789&peer_id=01234567890123456789&port=3210&compact=1&uploaded=0&downloaded=0&left=8000000&event=started
다음은 추적기 서버 응답의 예입니다: d8:completei100e10:incompletei200e8:intervali1800e5:peers300:......e
여기서 “…” 은 50 개의 피어의 IP 주소 및 포트 번호가 포함 된 길이 300 의 문자열 입니다. IP 주소는 4 바이트를 차지하며 포트 번호는 2 바이트를 차지합니다. 즉, 한 피어가 6 바이트를 차지합니다.
5. 피어 간의 통신 프로토콜
피어 간의 통신 프로토콜은 피어 연결 프로토콜 (peer wire protocal) 이라고도하며 TCP 프로토콜을 기반으로 한 응용 프로그램 계층 프로토콜 입니다. 일부 피어가 다운로드하지 않고 업로드하지 못하도록하기 위해 BitTorrent 프로토콜은 클라이언트가 가장 빠른 다운로드 속도를 제공하는 4 명의 피어에게만 데이터를 업로드한다고 제안합니다. 간단히 말해, 누가 다운로드를 제공하고, 다운로드 할 데이터를 제공하며, 다운로드 할 데이터를 제공하지 않는 사람은 내 데이터를 업로드하지 않습니다. 클라이언트는 각 피어로부터 10 초와 같은 일정한 간격으로 데이터를 다운로드하는 속도를 재 계산하고 가장 빠른 다운로드 속도로 4 명의 피어의 차단을 해제하여 4 명의 피어가 클라이언트에서 데이터를 다운로드하고 다른 피어를 차단할 수 있게합니다. 예외적으로, 다운로드 속도가 더 빠른 피어를 찾으려면 언제든지 클라이언트가 최적화 된 비 차단 피어를 유지한다는 것, 즉 피어가 다운로드를 위해 클라이언트에 데이터를 제공하는지 여부를 클라이언트가 알 수 있다는 점도 예외입니다. 클라이언트가 여기에서 데이터를 다운로드합니다. 클라이언트가 피어에 데이터를 업로드하기 때문에 피어는 클라이언트가 피어에서 데이터를 다운로드 할 수있게하고 네 개의 논 블로킹 피어 중 하나보다 빠르게 다운로드합니다. 클라이언트는 30 초와 같은 규칙적인 간격으로 최적화 된 비 차단 피어를 다시 선택합니다. 클라이언트가 피어와 TCP 연결을 설정하면 클라이언트가 유지 관리해야하는 몇 가지 상태 변수가 다음 표에 표시됩니다.
| 상태변수 | 의미 |
|---|---|
| am_chocking | 값이 1이면 클라이언트가 원격 피어를 차단 함을 나타냅니다. 이 시점에서 피어가 클라이언트에 데이터 요청을 보내면 클라이언트는이를 무시합니다. 다시 말해 피어가 차단되면 피어는 클라이언트에서 데이터를 다운로드 할 수 없으며 값이 0이면 피어가 차단되지 않았 음을 나타내며 피어가 클라이언트에서 데이터를 다운로드 할 수 있음을 나타냅니다. |
| am_interested | 클라이언트가 원격 피어에 관심이 있음을 나타내는 값 1입니다. 피어가 작품을 소유하고 있고 클라이언트가 그렇지 않은 경우 클라이언트는 피어에 관심이 있다는 것 입니다. |
| peer_chocking | 값이 1 이면 피어가 클라이언트를 차단 함을 나타냅니다. 이 시점에서 클라이언트는 피어에서 데이터를 다운로드 할 수 없습니다. 값이 0 이면 클라이언트가 피어에 데이터 요청을 보내고 클라이언트가 응답합니다. |
| peer_interested | 값이 1 이면 피어가 클라이언트에 관심이 있음을 나타냅니다. 즉, 클라이언트는 조각을 소유하고 있으며 피어는 조각을 소유하지 않습니다. 값이 0이면 피어는 클라이언트에 관심이 없습니다. |
클라이언트가 피어와 TCP 연결을 설정하면 클라이언트는 이 변수의 값을 다음으로 설정합니다. Am_chocking = 1. Am_interested = 0. Peer_chocking = 1. Peer_interested = 0. 클라이언트가 피어에 관심이 있고 피어가 클라이언트를 차단하지 않으면 클라이언트는 피어에서 데이터를 다운로드 할 수 있습니다. 피어가 클라이언트에 관심이 있고 클라이언트가 피어를 차단하지 않으면 클라이언트는 데이터를 피어에 업로드합니다. 달리 명시되지 않는 한, 모든 정수 유형은 핸드 셰이크 이후의 모든 정보의 길이 프리픽스를 포함하여 4 바이트 값 (상위 우선 순위 및 최하위 순위) 으로 이 프로토콜에 인코딩됩니다.
6. BT 다운로드 구현을위한 핵심 알고리즘 및 전략
6.1 파이프 라인 운영
네트워크 프로토콜은 일반적으로 높은 전송 효율을 요구하고, BT 프로토콜은 전송 효율을 제공하기 위해 파이프 라인 동작을 사용한다. 클라이언트가 피어에게 데이터 요청을 보내면 (즉, 요청 메시지를 보내는 경우) 한 번에 여러 슬라이스가 요청됩니다 (즉, 한 패킷이 여러 슬라이스를 요청하기 위해 여러 요청 메시지를 보냅니다). 클라이언트가 한 번에 하나의 슬라이스 요청 만 보내는 경우, 피어는 클라이언트가 데이터 조각을 보내기를 기다리고 클라이언트가 새 데이터 요청을 보내주기를 기다립니다. 한 번에 둘 이상의 슬라이스 요청이 전송되면 피어는 슬라이스를 전송 한 후 다음 슬라이스를 전송하므로 데이터 전송의 효율성을 높이기 위해 대기하지 않습니다. 1.1 버전의 HTTP 프로토콜은 파이프 라인 작업 개념을 널리 사용하여 브라우저와 웹 서버 간의 전송 효율성을 크게 향상시킵니다.
6.2 단편 선택 알고리즘
세그먼트 선택에는 4 가지 전략이 있으며 다운로드 속도를 높이려면 좋은 전략이 중요합니다.
- 한 조각의 조각에 대한 요청이 피어에게 전송되면 조각의 다른 조각도 피어에서 다운로드되므로 가능한 한 빨리 조각으로 다운로드 할 수 있습니다. 피어는 조각에 조각을 소유하기 때문에 조각의 다른 조각을 가져야하며, 피어가 클라이언트에게 조각을 보내려고한다면 조각에있는 다른 조각을 클라이언트에게 보내야합니다.
- 우선 순위. 즉, 피어가 모든 피어 중에서 가장 낮은 소유율을 갖는다면, 피스가 우선적으로 다운로드된다. 이렇게하면이 피스가있는 피어가 갑자기 떠나서 피스가 손실되는 것을 방지 할 수 있으므로 현재 다운로드에 참여한 피어는 완전한 파일을 다운로드 할 수 없으므로 소유권이 낮은 피스를 다운로드하면 다른 피어를 다운로드하면 많은 피어는 클라이언트로 부터 데이터를 요청할 것이고, 클라이언트로 부터 데이터를 다운로드하기 위해, 피어는 다운로드 할 클라이언트에 데이터를 제공 할 것이고, 이것은 또한 클라이언트의 다운로드 속도를 향상 시키는데 도움이 될 것이다. 이 공유 시스템의 경우 소유율이 낮은 부분의 다운로드 우선 순위 지정을 통해 전체 시스템이 각 부분의 소유권을 향상시킬 수 있으며 전체 시스템이 최적의 경향이 있습니다. 모든 피어가 우선적으로 더 높은 소유율로 조각을 다운로드하면 조각 소유율이 낮아져 많은 동료가 전체 파일을받지 못할 수 있습니다.
- 무작위로 다운로드 할 첫 번째 조각 선택. 최소 우선 순위 정책은 다운로드를 시작할 때 사용할 수 없습니다. 조각의 소유권이 매우 낮으면 이 조각으로 다운로드하는 것이 상대적으로 어렵습니다. 당신이 다음 작품을 선택하는 경우 더 쉽게 작품에 다운로드 클라이언트가 완전한 조각에 다운로드되면, 그것은 다른 피어 다운로드에 사용할 수 있으며, 다른 피어 클라이언트 업로드 데이터 때문에, 출시 다른 피어 클라이언트에 빠지게됩니다 블로킹은 초기 단계에서 더 높은 다운로드 속도를 달성하는 데 도움이됩니다. 일부를 다운로드 할 때 클라이언트는 데이터를 다운로드하기 위해 우선 순위가 가장 낮은 전략을 사용해야하며, 이로 인해 단기간에 클라이언트의 다운로드 속도가 감소하지만 다운로드 속도가 크게 향상됩니다.
- 최종 스테이지 모드. 때로는 전송 속도가 느린 피어에서 곡을 다운로드하는 데 시간이 오래 걸릴 수 있습니다. 다운로드 프로세스 중에 큰 문제는 아니지만 다운로드가 거의 완료되면 클라이언트가 지연됩니다. 다운로드가 완료되었습니다. 이 문제를 해결하기 위해 최종 단계에서 클라이언트는 모든 피어에게 피어에게 일부 슬라이스 요청을 보냅니다. 피어에서 보낸 슬라이스가 수신되면 다른 피어로 취소 메시지가 전송되고 현재 피어 만 다운로드됩니다.
6.3 차단 알고리즘
BT 는 리소스를 중앙 집중식으로 할당하지 않으며, 각 피어는 가능한 한 다운로드 속도를 향상시킬 책임이 있습니다. 피어는 연결할 수있는 피어에서 파일을 다운로드하고 상대방이 제공 한 다운로드 속도에 따라 동일한 업로드 보상을 제공합니다. 협력자의 경우 업로드 서비스가 제공되고 협업이 아닌 경우 상대방은 차단됩니다. 차단은 일시적으로 업로드를 거부하는 정책입니다. 업로드가 중지되지만 다운로드는 계속됩니다. 차단을 해제하면 연결을 다시 설정할 필요가 없습니다. 블록 프로세스가 조각 메시지를 전송하는 것을 거부하기 때문에 메시지가있는 것과 같은 다른 메시지는 여전히 수신 된 메시지를 전송할 수 있습니다. 블로킹 알고리즘은 BT 프로토콜의 일부가 아니지만 성능을 향상시킬 필요가 있습니다.
각 클라이언트는 고정 된 수의 피어 (대개 4 개)로 명확하게 유지되므로 피어와 함께 어떤 식으로 명확하게 결정할 수 있습니까? 통상적 인 방법은 현재의 다운로드 속도를 기반으로 어느 피어가 명확하게 유지되어야 하는지를 결정하는 것입니다. 그러나 현재 다운로드 속도를 계산하는 것은 큰 문제입니다. 현재 구현은 대개 지난 10 초 동안 각 피어에서 데이터를 다운로드하는 속도를 계산합니다. 클리어 (즉, 차단 해제) 된 피어는 빈번하게 블로킹 및 블로킹을 피하기 위해 10 초 간격으로 재 선택되므로 자원 낭비가 발생합니다. 연습을 통해 다운로드 속도를 최대화하는 데 10 초가 충분하다는 사실이 입증되었습니다.
가장 높은 다운로드 속도를 제공하는 4 명의 동료에게 업로드 서비스를 제공하면 무료 연결의 다운로드 속도가 더 빨라지는 것을 알 수있는 방법이 없습니다. 이 문제를 해결하기 위해 언제든지 각 피어는 “optimistic unchoking” 피어를 가지고 있으며 연결 속도는 다운로드 속도에 관계없이 항상 명확하게 유지됩니다. 30 초마다 피어를 최적화 된 비 차단 피어로 다시 선택합니다. 30 초는 피어의 업로드 기능을 최대화하기에 충분합니다.
피어가 다운로드를 완료하면 더 이상 다운로드 속도를 통해 업로드 할 피어를 결정할 수 없습니다 (다운로드 속도가 이미 0이기 때문에). 현재의 솔루션은보다 나은 다운로드 속도를 얻은 동료를 우선시하여 명확하게 유지하는 것입니다. 그 이유는 업로드 대역폭을 최대한 활용하기 위해서 입니다. 피어가 다운로드를 완료하면 시드가 됩니다. 시드에는 파일의 전체 복사본이 있으며 다른 피어에게 다운로드 할 수 있습니다. 전체 시스템의 성능을 위해, 각 피어는 전체 시스템에 대한 보상으로 다운로드가 완료된 후에 일정 기간 동안 시드로 존재해야합니다. 원본 시드, 즉 공유를 위해 처음에 제공된 파일이며 시드 파일이 생성되고 시드 파일이 웹 서버에 게시됩니다. 시스템에 다른 시드가 생성 될 때까지 존재해야합니다. 그렇지 않으면 현재 다운로드에 참여하는 모든 피어가 있어야합니다 어느 쪽도 파일의 완전한 복사본을 얻을 수 없습니다.
