리브토렌트

libtorrent
libTorrent와 혼동하지 말자.
리브토렌트
Libtorrent-rasterbar-logo.png
개발자아르비드 노르베르크
초기 릴리즈2005년 9월; 16년 전(2005-09)
안정적 해제2.0.5[1] (2021년 12월 4일; 57일 전(2021년 12월 12일-04) [±]
리포지토리github.com/arvidn/libtorrent/
기록 위치C++
다음에서 사용 가능영어
유형비트토렌트 도서관
면허증BSD-3-폐쇄
웹사이트libtorrent.org

libTorrent는 비트토렌트 프로토콜의 오픈 소스 구현이다. 에 기록되어 있으며 메인 라이브러리 인터페이스는 C++로 되어 있다. 가장 눈에 띄는 특징은 메인라인 DHT, IPv6, HTTP 시드, μTorrent의 피어 교환 지원이다. libtorrent는 Boost, 특히 Boost를 사용한다.아시오는 플랫폼 독립을 쟁취한다. 윈도 및 대부분의 유닉스 유사 운영 체제(OS X, 리눅스 및 많은 BSD)를 기반으로 구축되는 것으로 알려져 있다.

libtorrent는 개발자들이 가장 유용하다고 생각하는 bittorrent 확장으로 최신으로 유지되며, 더 넓은 환경에서 작업하도록 적극적으로 최적화되고 있다. 그것의 많은 기능은 특정 사용 사례에서 사용되지 않을 코드를 포함하지 않기 위해 컴파일 시간에 비활성화할 수 있다. 데스크톱 및 시드 서버뿐만 아니라 임베디드 장치에 가장 적합한 libtorrent 구현을 목표로 한다. 구현 세부사항 중 일부는 기능 섹션에 설명되어 있다.

리브토렌트의 원작자는 아르비드 노르베르크다. μTorrent와 함께 확장 프로토콜을 지원하는 최초의 클라이언트로, 현재 다른 많은 확장자가 구축되는 기반이 되고 있다.

특징들

구현된 BEP

BEP는 BitTorrent Enhancement Proposition Process의 일부분이다. BEP는 비트토렌트 커뮤니티에 정보를 제공하거나 비트토렌트 프로토콜의 새로운 기능을 설명하는 설계 문서다. BEP는 형상에 대한 간결한 기술 사양과 형상에 대한 근거를 제공해야 한다. 그것들은 새로운 특징들을 제안하고, 이슈에 대한 커뮤니티의 의견을 수집하고, 비트토렌트에 들어간 설계 결정을 문서화하기 위한 주요 메커니즘이 되려고 의도되었다. BEP 저자는 지역사회에서 합의를 도출하고 반대 의견을 문서화할 책임이 있다.

BEP는 버전 저장소에서 reStructured 텍스트 파일로 유지되기 때문에, BEP의 개정 내역은 피쳐 제안서의[2] 역사적 기록이다.

BEP에는 세 가지 종류가 있다.

  1. 표준 트랙 BEP는 비트토렌트 프로토콜 중 하나에 대한 확장이나 이들 프로토콜에 있는 행위자 중 한 명의 행동 변화를 설명한다. 여기서 행위자들은 현재 클라이언트, 추적자 및 웹 서버들이다.
  2. 정보 BEP는 비트토렌트 설계 문제를 설명하거나 비트토렌트 커뮤니티에 일반적인 지침이나 정보를 제공하지만 연장을 제안하지는 않는다. 정보 BEP는 반드시 BitTorrent 커뮤니티의 합의나 권고를 나타내는 것은 아니므로 사용자와 구현자는 정보 BEP를 무시하거나 그들의 조언을 따를 수 있다.
  3. 프로세스 BEP는 비트토렌트(BitTorrent)를 둘러싼 프로세스를 설명하거나 프로세스의 변경을 제안한다. 프로세스 BEP는 표준 추적 BEP와 유사하지만 BitTorrent 프로토콜 이외의 영역에 적용된다. 그것들은 권고사항 그 이상이며, 사용자들은 일반적으로 그것들을 무시할 자유가 없다. 예를 들어 출시 일정, 절차, 가이드라인, 의사결정 프로세스의 변경, 비트토렌트 개발에 사용되는 툴이나 환경의 변경 등이 있다.
BEP # 제목 참고
3 비트토렌트 프로토콜
5 DHT 프로토콜 추적기 없는 급류, 메인라인 Kademlia DHT 프로토콜
7 IPv6 트래커 확장
9 피어가 메타데이터 파일을 보낼 수 있는 확장명 메타데이터 전송 프로토콜, 자석 링크 활성화
10 확장 프로토콜
11 동위 교환 우토렌트 PEX
12 멀티트랙터 메타데이터 확장 또한 μTorrent 해석을 지원한다.
14 로컬 피어 검색
15 BitTorrent용 UDP Tracker 프로토콜
16 초시딩
17 HTTP 시드 호프만식
19 WebSeed - HTTP/FTP 시드(GetRight 스타일)
21 부분 시드 업로드 전용
24 Tracker가 외부 IP를 반환함
27 토렌츠 일병
29 우토렌트 운송 프로토콜 0.16.0 이후[3]
30 머클 해시 0.15[4] 이후
32 IPv6용 비트토렌트 DHT 확장 1.2년 이후
33 DHT 스크래치 0.16[5] 이후
38 돌연변이 급류 1.1 이후[6]
40 표준 피어 우선 순위 1.0 이후[7]
43 읽기 전용 DHT 노드 1.0.3 이후[8]
44 DHT put/get 1.0 이후[9]
47 패드 파일 및 파일 속성 0.15[10][11] 이후
51 DHT Infohash 인덱싱 1.2년 이후
52 비트토렌트 프로토콜 사양 v2 2.0 이후
53 자석 링크 파일 선택 1.2년 이후
55 홀펀치 익스텐션

기타 피쳐 리스트

  • libtorrent를 수정할 필요 없이 사용자 지정 bittorrent 확장을 구현하기 위한 플러그인 인터페이스
  • μTorrent 피어 교환 프로토콜(PEX)을 지원한다.
  • 로컬 피어 검색 지원(동일한 로컬 네트워크의 피어에 대한 검색)
  • 트래커 스크랩
  • lt_trackers 확장을 지원하여 피어 간에 추적기 교환
  • 트랙터의 부하를 덜어줄 no_lunt_id=1 확장을 지원한다.
  • 콤팩트=1 트래커 파라미터를 지지한다.
  • 머클 해시 트리 급류에 대한 지원 이를 통해 토렌트 파일 크기가 콘텐츠 크기에 맞게 잘 확장된다.
  • 별도의 디스크 I/O 스레드를 사용하여 디스크가 네트워크 또는 클라이언트 상호 작용에서 차단되지 않도록 하십시오.
  • 이를 지원하는 시스템에서 2GB보다 큰 파일을 지원한다.
  • 빠른 재개 지원, 재개된 급류 시작 시 값비싼 부품 점검을 제거하는 방법 스토리지 상태, piss_picker 상태 및 모든 로컬 피어를 별도의 고속 재생 파일에 저장
  • 향상된 디스크 처리량을 위해 조정 가능한 읽기 및 쓰기 디스크 캐시를 가지고 있다.
  • 모든 파일을 병렬로 확인하는 대신 파일 확인을 위한 대기열 급류.
  • 급류에서 작업물 주문에 대한 어떠한 요구 조건도 없는 경우, 해당 주문은 재개된다. 이것은 어떤 고객이 다운로드한 토렌트를 재개할 수 있다는 것을 의미한다.
  • 스파스 파일 및 컴팩트 파일 할당 지원(피스가 Disk에 통합되어 유지되는 경우)
  • 시드 모드(디스크의 파일이 완료된 것으로 가정하고, 각 피스의 해시가 처음 요청될 때 확인됨).
  • 다운로드 속도에 따라 요청 대기열의 길이를 조정한다.
  • 단일 포트와 단일 스레드에서 여러 개의 급류를 사용
  • http 프록시 및 기본 프록시 인증 지원
  • 지퍼가 달린 트래커-트래커 지지대
  • 업로드 및 다운로드 대역폭 사용 및 이유 없는 최대 피어 수를 제한할 수 있음
  • 연결 수를 제한할 수 있는 가능성.
  • 지연은 피어로 보내는 다른 송신 트래픽이 없고 피어가 이미 있는 피어에게 메시지를 보내지 않는 경우 메시지를 가진다. 이렇게 하면 대역폭이 절약된다.
  • 선택적 다운로드 토렌트 중 다운로드할 부분을 선택하는 기능.
  • IP 주소 및 IP 범위의 연결 및 연결을 허용하지 않는 ip 필터
  • NAT-PMP 및 UPnP 지원(지원하는 라우터의 자동 포트 매핑)
  • I2P 익명성 네트워크를 통해 토렌트 트래픽을 대신할 수 있다.

디스크 캐싱

libtorrent의 모든 디스크 I/O는 디스크 io 스레드에 의해 네트워크 스레드에 비동기적으로 수행된다. 블록을 읽으면 블록을 요청하는 피어가 동일한 피스에서 더 많은 블록을 요청한다고 가정하여 디스크 io 스레드는 해당 피스에서 후속 블록을 모두 읽기 캐시로 읽는다. 이것은 데이터를 읽기 위한 syscall의 수를 감소시킨다. 그것은 또한 추구로부터의 지연을 감소시킨다.

마찬가지로 쓰기 요청의 경우 블록이 캐시되고 전체 조각이 완료되면 디스크로 플러시되거나 캐시 공간이 더 필요할 때 가장 최근에 업데이트된 블록이 된다. 캐시는 쓰기 캐시와 읽기 캐시 사이의 공간을 동적으로 할당한다. 쓰기 캐시는 읽기 캐시보다 엄격히 우선시된다.

사용 중인 캐시 블록은 디스크에 페이징되지 않도록 물리적 메모리에 잠겨 있다. 디스크 캐시를 디스크에 페이징할 수 있게 하는 것은 다시 디스크에 플러시되기 위해서만 물리적 메모리로 다시 읽어야 하기 때문에 플러시하는 것이 극도로 비효율적이 된다는 것을 의미한다.

메모리 및 시스템 호출을 보존하기 위해 iovec 파일 작업을 사용하여 한 번의 호출로 여러 캐시 블록을 플러시한다.

저메모리 시스템에서는 메모리를 절약하기 위해 디스크 캐시를 완전히 비활성화하거나 더 작은 한도로 설정할 수 있다.

네트워크 버퍼

L2 캐시가 작은 CPU에서 메모리 복사는 비용이 많이 들 수 있다. 그러한 기계에서는 최소한으로 복사하는 것이 중요하다. 이는 대부분 임베디드 시스템에 적용된다.

수신된 데이터를 복사하는 횟수를 최소화하기 위해 페이로드 데이터의 수신 버퍼를 페이지 정렬 디스크 버퍼로 직접 수신한다. 연결이 암호화된 경우 버퍼의 암호는 인플레이스 방식으로 해독된다. 그런 다음 버퍼가 복사되지 않고 디스크 캐시로 이동된다. 한 조각에 대한 모든 블록을 수신했거나 캐시를 플러시해야 할 경우, 모든 블록을 writev()로 직접 전달하여 단일 syscall로 플러시한다. 즉, userspace 메모리에 대한 단일 복사본과 커널 메모리에 대한 단일 복사본을 의미한다.

일반적으로 시딩 및 업로드 시에는 피어의 송신 버퍼에 한 번 복사되는 정렬된 버퍼에 블록을 캐싱하여 불필요한 복사를 피한다. 피어의 송신 버퍼는 대부분의 시간임에도 정렬이 보장되지 않는다. 그런 다음 전송 버퍼가 피어 특정 키로 암호화되고 전송을 위해 iovec에 체인으로 연결된다. 즉, 비정렬 피어 요청과 피어별 암호화를 허용하기 위한 사용자 공간 복사본이 하나 있다는 것을 의미한다.

피스 선택기

작품 선택기는 양방향 구현의 핵심 구성요소다. libtorrent의 작품 선택기는 가장 희귀한 작품을 빨리 찾을 수 있도록 최적화되어 있다. 그것은 모든 사용 가능한 조각들의 목록을 희소성별로 분류하고, 같은 희소성을 가진 조각들의 목록을 보관한다. 가장 희귀한 첫 번째 모드는 우세한 피스 선택 모드다. 다른 모드도 지원되며 특정 상황에서 동료가 사용한다.

피스 선택기는 피스의 사용 가능성과 우선순위를 결합할 수 있다. 그들은 함께 조각 목록의 정렬 순서를 결정한다. 선택적 다운로드 기능에 사용되는 우선 순위가 0인 작품은 절대 선택되지 않는다.

가능한 한 부분적으로 완성된 조각을 적게 가지기 위해, 피어는 같은 속도 범주의 다른 피어와 동일한 피스에서 블록을 선택하는 것을 선호한다. 속도 범주는 다운로드 속도에 따라 피어를 거칠게 분류하는 것이다. 이는 느린 피어가 같은 피스에서 블록을 선택하고, 빠른 피어가 같은 피스에서 블록을 선택하게 하며, 따라서 느린 피어가 피스의 완성을 방해할 가능성을 감소시킨다.

작품 선택기는 순차적으로 작품을 다운로드하도록 설정할 수도 있다.

머클 해시 트리 급류

BitTorrent 프로토콜의 BEP30 입니다. Merkle 해시 트리 토렌트는 토렌트 파일이 조각 해시를 형성하는 해시 트리의 루트 해시만 포함할 수 있는 확장자다.[12] 이 기능의 주요 이점은 토렌트에 몇 개의 조각이 있든 상관없이 .토렌트 파일은 항상 같은 크기가 된다는 것이다. 파일 이름만 포함하면 되기 때문에 파일 수와 함께 확장된다.

일반적인 토렌트를 사용하는 고객은 일반적으로 서로 다른 피어의 여러 블록을 요청해야 피스 해시에 대해 데이터를 확인할 수 있다. 조각이 클수록 완제품을 내려받아 검증하는 데 시간이 더 오래 걸린다. 조각이 검증되기 전에, 그것은 덩어리들과 공유할 수 없으며, 이것은 조각 크기가 클수록, 동료들이 그것을 다운로드 했을 때 더 느린 반전을 의미한다. 평균적으로 데이터가 검증되기 전에 클라이언트 버퍼에서 대기해야 하므로 데이터를 다시 업로드할 수 있다.

조각 크기가 큰 또 다른 문제는 조각이 고장 났을 때 클라이언트가 악질 또는 버기 피어를 정확히 찾아내는 것이 더 어렵고 조각이 더 클수록 다시 다운로드하여 더 많은 시도를 하는 데 시간이 오래 걸린다는 것이다.

일반 토렌트의 피스 크기는 .토렌트 파일 자체의 크기와 피스 사이즈의 트레이드오프다. 4GB 파일의 경우 .torrent 파일을 너무 크게 만들지 않기 위해 조각 크기가 2 또는 4MB인 경우가 많다.

Merkle torrents는 .torrent 사이즈와 조각 크기 사이의 절충을 제거함으로써 이러한 문제들을 해결한다. 머클 토렌트를 사용하면 피어가 피어로부터 수신한 모든 데이터 블록을 즉시 확인할 수 있는 최소 블록 크기(16KB)가 될 수 있다. 이를 통해 최소한의 전환 시간을 부여하고 악의적인 동료를 식별하는 문제를 완전히 제거할 수 있다.

적용들

libtorrent를 사용하는 일부 응용 프로그램:

참고 항목

참조

  1. ^ "Releases · arvidn/libtorrent". GitHub. Retrieved 4 Dec 2021.
  2. ^ "bep_0001.rst_post". www.bittorrent.org. Retrieved 2020-02-19.
  3. ^ libtorrent 0.16.0 changelog
  4. ^ libtorrent changelog
  5. ^ libtorrent changelog
  6. ^ libtorrent changelog
  7. ^ libtorrent changelog
  8. ^ libtorrent changelog
  9. ^ libtorrent changelog
  10. ^ libtorrent changelog
  11. ^ libtorrent changelog
  12. ^ "Archived copy" (PDF). Archived from the original (PDF) on 2014-12-18. Retrieved 2010-12-06.{{cite web}}: CS1 maint: 타이틀로 보관된 사본(링크)
  13. ^ https://github.com/aldenml/libtorrent4j

외부 링크