토렌트 설정- www.토릴.com

[이용안내] 토렌트 설정

등록일: 2013-06-20 21:33:01

고급설정(Advanced)
"주의": 이 옵션들은 완벽한 이해를 한 후 설정하시기 바랍니다. 한번보고 이해가 되지 않는다면 다음날 다시 읽어보시고 그래도 이해가 되지 않으신다면 기본값으로 두시길 바랍니다. 성능에 큰영향을 미칠 수도 있을 뿐더러 종속성을 갖는 녀석들 역시 많습니다.

"bt.allow_same_ip": 활성화 시, 동일한 IP주소로부터의 다수의 들어오는 연결을 허락합니다. 이 옵션은 하나의 토런트 작업에 대해서만 영향을 미칩니다. 그러므로 서로 다른 토런트 무리(swarms)에 동일한 IP 주소의 연결을 가질 수 있습니다. 이 옵션은 안티-리치 방지(anti-leech protection)를 약화시키지만 비활성화로 두길 권장합니다.
※ swarms : 하나의 토런트 작업에 잠재적인 시더와 피어를 포함한 무리
※ leech : 피어와 비슷하지만 받기만 하는 클라이언트("leecher"라고도 불리긴합니다만 토런트에만 존재하는 단어입니다.)
"bt.auto_ul_factor": 이 옵션은 최대 읽기 속도조절을 하기 위해 분배율을 설정한다. 단위는 (%)입니다.
"bt.auto_ul_interval": 이 옵션은 업로드 속도 제한을 자동으로 하기위해 얼마나 자주 테스트하는지를 조절할 수 있습니다. "interval"이 지날때 마다, μTorrent 는 업로드 속도 제한을 비활성화하고 다시 테스트해서 추출된 속도로 동작합니다. 단위는 (초)입니다.
"bt.auto_ul_min": 이 옵션은 "자동 업로드 속도조절 모드(auto-uplink throttleing mode)"일 때 사용되며 최소 업로드 속도의 한계를 정합니다. 만약 평균 추출(sampled average) 값이 이값보다 작으면, μTorrent 는 평균 추출 값을 무시하고 이 값을 사용할 것입니다. 단위는 (B/s)입니다. 만약 이 값이 너무 낮다면, "자동 업로드 속도 제한자(automatic-upload rate limiter)"가 "다운로드 제한 모드(Download Limited mode)"를 동작시킬 정도로 낮은 수준까지 업로드 속도를 설정 했었을지도 모릅니다.(다시 말해 이 값을 너무 낮게 설정하면 자동 속도를 너무 낮게 검출해서 다운로드 속도 제한이 걸릴 수도 있다는 얘깁니다.)
"bt.auto_ul_sample_average": 이 옵션은 몇초 동안의 총 업로드 데이터의 평균을 구하는가를 설정합니다. 단위는 초입니다.
"bt.auto_ul_sample_window" : 이 옵션은 각 추출이 얼마나 걸리는가를 제어합니다. 단위는 초입니다.
"bt.ban_ratio": 추방당하기 전에 최하로 수락할 수 있는 나쁜 조각에 대한 좋은 조각의 비율(ratio)로 피어는 보낼 수 있습니다.(즉, Bad pieces/Good Pieces) 이 효과를 얻기 위해선 "bt.ban_threshold"를 넘고 bt.use_ban_ratio는 활성화 되어야 합니다.
※ 쉽게 얘기해서 "hashfailed pieces"의 수로 피어가 차단되기전에 한번더 기회를 주는겁니다. (나쁜조각/좋은조각 < "bt.ban_ratio")를 확인해 참이라면 차단이 보류됩니다. 반대로 거짓이라면 리스트에 추가됩니다. 리스트 초기화는 메인 윈도우에 "토런트 작업 리스트->마우스 오른클릭->Advanced->Reset Bans"로 가능합니다.
"bt.ban_threshold": 이 옵션은 반대 조치를 취하기 전에 어떤 하나의 피어(peer)가 보낼 수 있는 "hashfailed pieces"의 최대 수를 기술한다. (어느쪽도 철저히 차단하지만 만약 bt.ban.ratio가 활성화되어 있으면 "bt.ban_ratio"가 시행된다.)
"bt.compact_allocation": 이 옵션을 활성화하면 μTorrent는 디스크에 파일을 미리 할당하여 기록하지 않고 어떤의미로는 데이터가 증가하여 파일이 생성됩니다. 왜냐하면 빽빽하게 기록되므로, 이 옵션이 활성화 되면 파일이 불완전하게 남아 있을 때 디스크 단편화의 증가 수준을 잠재력있게 이끌것이다. 게다가, 이 옵션은 처리중인 파일을 위해 데이터의 순서를 바꿔 기록할 것이므로 이미 낮은(already-low) 확율을 더 줄여주어 파일이 완성되기 전에 미리보기할 수 있다. 여기에 이 옵션을 사용했을 때의 어떤것을 얻을 수 있는지 기록한다.
- μTorrent 에 "모든 파일을 미리 할당" 이 설정되어 있다면 이 옵션은 무시되고 결국 파일을 미리 할당할 것입니다.
- 만약 이 옵션이 활성화되면, 파일을 "생략할 수 없습니다". 만약 토런트 작업이 파일들을 생략하려면, 이 옵션을 사용하지 않아야 합니다다.
※ 요 약을 하자면 하나의 토런트 작업에 대해서 전체적인 기록에 대해 계획을 잡고 기록을 해나가는 겁니다. 파일 미리할당과 비슷하지만 이것은 0으로 채우는 작업을 생략하고 알고리즘에(첫 조각을 기록한 섹터에서부터 순서대로 용량만큼을 기록하는걸로 보입니다.) 의해 비슷한 동작을 하는겁니다. 초기에 파일할당을 하지않아 버벅이지 않겠지만 "Don't Download"를 사용할 수 없으니(즉, 선택한것만 받을 수 없으니) 불편합니다. (sparse files의 경우 파일단위로 비슷한 동작을 수행합니다.(뒤에서 설명합니다) 최근에 추가된 no_zero의 경우는 기존의 sparse files 문제를 해결(역시 뒤에서 설명합니다)했으니 그 옵션을 사용하는게 좋겠습니다. 파일할당 정책은 하나만 활성화 하십시요..)
"bt.connect_speed": 이 옵션은 "net.max.halfopen limit"까지의 초당 연결들의 수를 기술합니다.(즉, max.halfopen 한도내에서 초당연결하는 연결의 수)"
ex) max.halfopen = 10, connect_speed= 5 일 때 처음 1초에 5개의 연결을 하고 다음 1초에 나머지 5개를 연결합니다.
"bt.enable_tracker": 이 옵션을 활성화 하면 μTorrent에 내장된 기본적인 tracker기능을 활성화 할 수 있습니다. 만약 이 트래커를 사용하려면 "http://IP:port/announce" 와 같이 하면되며, IP는 사용자의 공인 IP, 포트는 토런트에 설정된 포트를 입력하면 됩니다.("대체 포트"가 활성화 되어 있다면 그 포트를 사용해도 됩니다) 만약 "Dynamic DNS"를 사용한다면 IP에 사용자의 도메인을 입력해도 됩니다. 내장 트래커는 외부 토런트파일의 트래킹만을 지원하고 제한에 대한 기능은 공급하지 않습니다. 당연한 얘기지만 포트포워딩 등의 환경은 기본적으로 갖춰져야 동작을 합니다.
"bt.graceful_shutdown": 활성화 시, μTorrent 종료 순서(shutdown sequence)를 마치기위해 필요한 시간을 줄 수 있습니다.(처리중인 조각 디스크에 쓰기, 삭제 대기중인 파일 삭제하기, 그리고 응답을 기다리는 트래커에게 종료 메시지 보내기 <== 특히 중요합니다) 이 옵션의 활성화는 깨끗한 종료를 위해 조금의 시간을 갖고 싶어 한다는 것을 의미하기때문에 종료를 길게 기다려 줄것이고 그때가 되서야 메모리에 잔존한 것을 처리할 것입니다. 만약 비활성화 한다면, μTorrent 는 종료 순서(shutdown sequence)의 상태는 고려하지 않고 최대한 13초를 기다려 주고 강제로 종료를 할것입니다.
※ 쉽게 얘기해서 종료에 13초의 여유시간이 있는데 이 시간이 길어지게 될 경우 이 옵션을 활성화 해야만 정상적으로 종료를 하고 그렇지 않으면 그냥 강제로 종료가 된다는 얘깁니다.(트래커에게 종료 메시지를 보내는 기능은 비공개 트래커의 경우는 중요하겠지요. 공개 트래커의 경우야 swarm내에 좀비 피어가 생긴다는것 외엔 문제될게 없을테니..)
"bt.multiscrape": 활성화 시, μTorrent 는 매번 트랙커의 "scrapes"시 다수의 해쉬를 보내는 것을 허락합니다. 이것은 하나의 해쉬를 보내는 것보다 효율적입니다. 대부분의 환경에서 이 옵션을 비활성화할 필요가 없습니다. μTorrent는 "multi-scraping"를 지원하지 않는 트랙커를 발견하면 "single scraping"으로 대체됩니다.
※ 보충설명하자면 여러개의 토런트 작업이 있을 때 그 중에 같은 트래커가 등록된 작업에 해쉬를 몰아서 보내주는겁니다. 어쩌다보면 토런트작업을 시작도 하지 않았는데 hash table(swarm 정보)이 갱신되는 경우가 있습니다. 그것은 이미 시작된 작업에서 같은 트래커가 등록된 파일의 해쉬를 같이 전송했기 때문입니다.
※ scrapes : 클라이언트(Peers)가 자신의 정보(hash 등)를 보내고 트랙커는 합당한 사용자(공개 트래커는 세션이 포화되기전까진 전부 헙당하겠죠)라면 그 해쉬에 대한 피어들의 대한 정보(swarm 정보 등)를 보내주는걸 말합니다.
"bt.no_connect_to_services": 이 옵션은 "bt.no_connect_to_services_list"에 기술된 포트들을 피어와의 연결 포트로 사용하지 않도록 해줍니다. μTorrent 때문에 견딜수 없다는 등의 투덜거리는 메일이 온다면 이것으로 방화벽에 걸리지 않도록합니다.(번역이 이상하네요;; 퍼랭이의 한계가...;; 즉 관리자에게 메일이 온다면 방화벽에 지정된 관심포트를 지정해서 그 포트를 사용하지 않도록 할 수 있다는 내용인듯 합니다.)
"bt.no_connect_to_services_list": 이 옵션은 "bt.no_connect_to_services"가 활성화 되었을 때 어느 포트로 접속이 불가한지에 대해 기술합니다.
"bt.prio_first_last_piece": 이 옵션을 활성화 시, 토런트 작업의 각 파일의 처음과 마지막 조각을 우선 시켜서 다운로드 완성 전에 미리보기를 할 수 있는 기회를 늘립니다. μTorrent 는 파일에서 자료의 처음과 마지막의 1개의 MB에 최고 우선 순위를 매길것입니다.
※ e-mule에서 많이 쓰던 페이크 확인을 가능하게 하기 위한 기능 정도로 생각하시면 되겠습니다.
"bt.scrape_stopped": 활성화 시, 토런트 작업의 시드와 피어의 수를 가져오는 요청(scrape)을 멈춥니다.
"bt.send_have_to_seed": 활성화 시, 다른 시드들에게 얼마나 많은 조각들을 가지고 있는지 메시지를 보내 알려줍니다.
"bt.set_sockbuf": 이 디버깅 옵션은, μTorrent 가 자동으로 TCP 버퍼 크기(so_sndbuf)를 검출하고 그것을 기초로 업로드 속도를 조절하도록 합니다. 업로드 속도는 "latency"에 기초하여 조절되지 않습니다.
"bt.transp_disposition":
"bt.use_ban_ratio": 이 옵션은 μTorrent "bt.ban_threshold"를 넘은 피어를 차단할 때 "bt.ban_ratio"로 결정하고자 할때 사용됩니다.(쉽게 얘기해서 "bt.ban_ratio"를 사용한다는 옵션이다.)
"bt.use_rangeblock": 활성화 했을 때, μTorrent 는 동시에 "hashfailed" 조각을 보내는 개개의 IP들을 차단하는 것 보다 연속된 IP 주소를 차단하는 것을 자동적으로 결정하여 시도할 것이다. μTorrent 가 동일한 "/24 CIDR block" 4개의 IP를 차단할 때, 연속된 "24 CIDR block"으로 차단할 것이다. μTorrent가 동일한 "/16 CIDR block"에서 4개의 "/24 CIDR blocks" 크기를 차단할 때, 연속된 "/16 CIDR block"을 차단할 것이다. 동일한 "/8 CIDR block"에서 4개의 "/16 CIDR blocks" 크기를 차단할 때, 연속된 "/8 CIDR block"을 차단할 것이다.(CIDR 을 설명하기 위해서 좀 극단적으로 기술을 해놨네요 allow IP가 섞여있다면 적용되기 힘듭니다. 허나 조건이 맞는다면 적은 필터링 정책으로 처리는 더 빠르겠지요^^)
"dht.rate": 이 옵션은 DHT가 사용할 대역폭의 양을 지정합니다. 기본 값 "-1"은 μTorrent가 사용자의 최대 업로드 속도를 기초로 자동적으로 관리하여 대역폭을 사용합니다. 자동 값은 사용자의 최대 업로드 속도를 16으로 나눠서 획득합니다. 이 값은 (B/s) 단위입니다.

"diskio.coalesce_write_size": 이 옵션은 μTorrent가 한번에 더많은 디스크에 데이터를 기록하여 기록 횟수의 시도를 적게합니다. 이 기능은 다운로드 속도에 조금의 영향도 끼치지 않으나 메모리와 CPU 사용량을 증가시킬지도 모르지만 보다 적게 디스크를 씁니다.
※ 디스크에 기록되는 양을 설정하는 겁니다. 디스크 버퍼(캐시)와 비슷하게 생각되지만 좀 더 저수준 기능입니다. 즉, 밑에서 동작한다는 얘깁니다.
"diskio.coalesce_writes": 이 옵션은 "diskio.coalesce_wite_size"의 사용유무를 설정합니다.
"diskio.flush_files": 이 옵션을 활성화하는 이유는 μTorrent가 매분마다 파일 핸들을 닫기 위해서입니다. 이 기능은 메모리 누수(memory leaks)"의 분명한 원인이고, 어떤 사람들을 위한 윈도우가 관리하는 시스템 캐시의 부정확한 효과를 줄일 수 있게 도와준다.
※ 메모리 누수(memory leaks)"란.. 프로그래밍을 해보신분들은 다들 알고 계실겁니다. 예전의 좁은 메모리 공간에서의 프로그램밍에서는 아주 심각한 문제였지만 요즘은 대용량의 메모리로 인해 장시간 운용되는 서버급의 프로그래밍이 아니라면 크게 문제가 되지는 않습니다. 그러나 반복적인 루틴등에 누수가 발생하면 기하급수적으로 늘어납니다. 그리고 애초부터 프로그램이 쓸데없이 늘려가는건 바람직하지 않지요. 그래서 프로그래밍을 할때 메모리 할당을 해제하는 함수를 신경쓰는 것이고 tracing해서 메모리누수를 검사하는 것입니다.
"diskio.no_zero": 이 옵션을 활성화하는 이유는 파일 할당을 위한 0 채우기(zero-illing)을 생략하기 위해서 입니다. 이 옵션은 윈도우즈 XP이상에서 동작하고 기본적으로 관리자 권한을 요구합니다. 그렇지만, 그것은 윈도우 그룹 정책 에디터(Windows Group Policy Editor)의 정책을 사용해서 "Perform volume maintenance tasks" 설정에 의한 제한된 작업에서의 작업이 가능합니다. 생략한 0 채우기(zero-filling)는 파일 할당 프로세스의 속도를 올려주지만 읽기 접근을 공유하기 때문에 한번이라도 디스크에 존재된 경로를 가질것이므로 민감한 데이터는 위험합니다. 하지만 다른 어플리캐이션과 유저의 읽기에 의한 손실의 위험이 잠재력있게 제거되지 않을이므로 볼륨 관리 권한(volume maintenance priveleges)을 포함하지 않습니다.
※ 대 충 훑어 봤더니 "diskio.sparse_files"에 추가적인 알고리즘(기존의 문제이던 예약된 공간을 다른 파일에게 할당해버리는 문제를 알고리즘에서 0을 리턴해서 속이는걸로 보입니다.)을 적용시켜 단편화를 줄인듯하더군요. 윗글을 요약하자면 기본적으로 관리자 계정에서 수행해야 하지만 제한된 계정이라도 볼륨관리작업 권한을 줘서 사용할 수는 있지만 무결성을 보장하지 않으므로 사용하지 않는게 좋다는 얘깁니다. 그리고 언급은 되지 않았으나 다른 디스크 할당 정책 옵션들을 모두 꺼줘야 하지 않을까 싶습니다. 이 옵션에 우선순위를 줬을지 모르겠네요.
Enabling this option causes μTorrent to skip the zero-filling process for file allocation. This option works only on Windows XP or newer, and requires administrator privileges by default. However, it is possible to make this work on limited accounts by setting the "Perform volume maintenance tasks" policy appropriately in the Windows Group Policy Editor. Skipping zero-filling speeds up the file allocation process, but because the allocated files have shared read access, there is a risk that any sensitive data that may have once existed at that location in disk but isn't wiped will potentially be exposed for other applications and users to read, including those without volume maintenance priveleges
"diskio.smart_hash": 이 옵션은 디스크 플러싱 대신에, 디스크에서 재 읽기, 그리고 해슁할 때에 메모리에 해쉬 데이터를(안에 쓰기 대기열(write queue)이 존재한다면) 만들어 줍니다. 이것은 특히 빠른 속도로 전송할 때 하드 디스크 읽기를 줄이도록 도울것입니다.
※ 이 기능은 디스크 읽기 캐시와 달리 데이터의 해쉬를 캐싱합니다.
"diskio.smart_sparse_hash": 이 옵션은 일부버젼의 윈도우에서 μTorrent의 "sparse files"과 실제적으로 완료되고 있는 총데이터에 관하여 부정확한 데이터를 되돌리는 문제를 우회해 줍니다.
"diskio.sparse_files": 이 옵션을 활성화는 μTorrent 가 오직 데이터 쓰기에 sparse files을 할당하기 위한 이유이지만 파일 시스템에 파일의 크기를 알려줘야 할것입니다. (그렇게 파일에 대한 간격(space out)의 모두를 물리적으로 0(physically zero)으로 채우지 않고 하드 드라이브의 충분한 인접 공간(contiguous space)의 예약을 시도 할 수 있습니다.) 비록 파일을 위해 예약한 공간 일지라도, 공간이 없으면 파일의 기록되어있지 않은 부분(unwriten parts)에게 줄것입니다. 이 옵션을 활성화하면 드믈게(rare cases) 증가하는 디스크 단편화를 잠재력있게 인도(potentially lead)할지 모릅니다. [어디의 드라이브에 "sparse files"을 위한 공간 예약을 이행(honor)함에 대해 이용할 수 있는 충분한 자유 공간을 가질 필요가 없습니다.] 여기 이 옵션을 사용할때의 조금의 주석을 포합합니다. Enabling this option may potentially lead to increased disk fragmentation in rare cases where the drive does not have enough free space available to honor the space reservation for sparse files. Here are some things to take note of when using this option:
- ".Sparse files"은 오직 NTFS로 포맷된 파티션에서만 작동한다.
- zeroed-out 미리할당(pre-allocated) 데이터를 해쉬하지 않았을 때 미리 할당 파일(pre-allocated files)의 해쉬 체킹보다 "sparse files"의 해쉬 체킹이 더 빠른 경향이 있다.
- 윈도우 비스타에서 "sparse files"는 "file system limitation"과 충돌할 수 있습니다.
- 만약 디스크 쿼터와 함께 비 관리자(non-administrator)계정을 사용한다면 "sparse files"는 작동하지 않을 것입니다. 그리고 "sparse files"은 충분히(fully) 할당을 받으려고 할것입니다. 이 윈도우 제한에 대해 μTorrent 는 아무것도 할 수 없습니다.("diskio.no_zero"에서 또 설명했지요.. 날림이라도 이해는 되실겁니다 ㅎㅎ;;)
- 이 옵션은 "모든 파일 미리 할당(pre-allocate all files)"과 동시에 사용할 수 없습니다. 만약 두 옵션을 동시에 활성화한다면, "미리 할당(pre-allocation)"이 우선순위를 가질 것입니다.
- "bt.compact_allocation"과 동시에 사용할 때, μTorrent는 파일시스템의 각 파일을 위한 공간을 예약할 것입니다. 하지만 그것은 "compact writes"를 계속해서 사용할 것입니다.
※ Sparse Files는 NTFS 5이상부터 지원하는 기능으로 이 파일의 특징은 파일내의 0이 아닌부분만을 기록해서 실제적인 데이터는 적게 기록되어있더라도 논리적으로 전체적인 데이터크기로 인식합니다. 하지만 문제는 NTFS 5 파일 시스템이 예약된 공간을 낭비하지않고 다른 파일에게 쓸수 있도록 해주더라도 파일용량을 유지할 수 있기때문에 단편화가 생길 수 있다는 얘깁니다.(파일미리 할당이나 "bt.compact_allocation"에 비해서입니다.) 용량이 충분하다면 단편화 문제도 그다지 없을테고 아무런 정책을 하지않는것보단 훨씬 단편화가 적습니다. 그리고 스파이스 파일을 FAT 계열등의 NTFS5가 아닌 파일 시스템으로 복사하면 전체크기로 생성이 됩니니다. 즉 NTFS에서 보다 전체적인 용량이 늘어나겠죠^^;; 이정도면 이해를 하실걸로 믿습니다.

※ 여기서 한번 정리를 하자면 파일 할당 정책 알고리즘에는 4가지가 있습니다. 우선 기본적으로 아무설정도 안하는게 있겠죠^^;; 다음으로 단편화를 줄이기 위해서 첫번째로 파일미리 할당이 있습니다. 이 경우 파트가 완성되어 파일을 생성할때 파트를 제외한 나머지 부분은 0으로 채워서 파일을 완성시켜 놓고 나중에 0부분에 해당하는 데이터는 완성되는대로 교체를 하는겁니다. 문제는 0으로 값을 채워 파일을 만드는 동안에 엄청난 디스크 자원을 사용하게 된다는 겁니다.
그걸 해결하기 위해 두번째로 "bt.compact_allocation"이 있습니다. 이건 토런트가 작업파일의 크기를 측정해서 그 만큼을 쓰겠다고 처음과 끝을 표시를 하는겁니다. 이건 토런트 작업에서 파일을 생략할 수가 없습니다. 이미 할당을 해놨으니 써야하게때문에 ㅎㅎ;;
그리고 세번째로 그것보다 지능적인 방법이 diskio.sparse_files입니다. 이것은 윈도우 파일 시스템에서 지원되는 기능을 사용하는 것으로 파일당 처리가 가능하기 때문에 파일의 생략도 가능하고 0으로 채우지 않고도 예약이 가능합니다만 예약된 공간을 보장을 해주지 않습니다. 원래의 단편화를 줄이기 위한 용도가 아니기때문에 공간이 부족하게 되면 다른 파일을 예약된 공간에 씁니다. 물론 파일의 무결성은 문제가 없습니다만 애초의 계획에서 틀어지기 때문에 상대적으로 단편화가 더 생길 수 있습니다.
그리고 네번째로 diskio.sparse_files을 업그래이드한 diskio.no_zero입니다. 예약된 공간을 파일 시스템을 속여서 다른 파일이 쓰지 못하도록 해서 단편화를 줄이는 겁니다.
마 지막으로 이 기능들이 디스크 과부화를 줄여준다는 잘못된 정보가 퍼져있습니다. 단편화를 줄이기 위해 "파일 미리 할당"을 사용하는 과정에서 원래는 생길이유가 없는 디스크 과부하가 생기는걸 기능을 유지하면서 생기지 않도록 해주는것입니다. 아무 정책도 걸지 않는다면 원래는 과부화가 생기지 않을 것이었던 겁니다. 즉, 다른 (근본적인)문제로 과부화가 생긴다면 디스크 캐시등을 조정해야 하는것입니다.
"diskio.use_partfile": 이 옵션은 사용자가 "Don't Download(skip)"한 파일에 해당하는 다운로드된 저장데이터에 사용됩니다. 이 기능은 할당중인 파일을 위해 필요한 예방을 합니다. μTorrent는 연속된 조각의 무결성(uncorrupted)을 확인하기 위한 명령을 사용하여 다운로드와 저장을 진행하고 그 조각들에 딸려온 "생략된 파일의 부분(parts of the skipped files)"을 개별적으로 저장합니다. 그리고 각 조각은 여러 파일의 데이터를 포함 할 수 있습니다. "parfile"은 토런트 작업 리스트에서 토런트 작업을 제거할때 제거됩니다.
※ 번역이 이상한것도 있지만 개발자가 너~~~무 자세히 설명을 했네요. 정리하자면 특정파일을 생략할 경우 μTorrent가 그 부분을 받지 않는것이 아닙니다. 모든 부분을 전부 받아서 제일 앞부분과 뒷부분만을 part파일에 저장을 합니다. 그리고 part파일로 받았다는 표시를 해서 다시 받는 일이 없도록 하는겁니다. 이 옵션을 해제 하고 생략을 하면 다운로드 생략 기능이 정상적으로 동작하지 않습니다.
"gui.bypass_search_redirect": 이 옵션을 활성화시 "http://serch.utorrent.com" 통하여 재지정 되지않고 선택된 검색엔진으로 직접 검색됩니다.
※ 특별히 경유해서 검색 사이트에 접속 된다는것 빼곤 차이가 없습니다. 해보시면 바로 이해하실겁니다 ㅎㅎ
"gui.compat_diropen": 만약 사용자가 μTorrent 에서 디렉토리들을 브라우징 하는 동안 브라우징 다이알로그가 공백으로 나오는 이상 행동 경험한면 이 옵션을 활성화를 시도해보랍니다.
※ 특별한 윈도우 버젼에서 나타나는 문제는 아닌듯 합니다. 프로그래밍 할때 윈도우 버젼을 검출해서 자동으로 적용을 할 수 있는데 옵션을 별도로 추가한걸 보면 말이죠...
"gui.default_del_action": 이 옵션은 "제거 버튼"이나 키보드의 "delete 키"를 눌렀을 때 토런트 작업이 어떻게 삭제가 될것인가를 설정합니다. 값이 "3" 을 초과하면 "제거 버튼"이나 "delete 키"를 눌렀을 아무동작도 하지 않을 것입니다. 안전하게하려면, GUI를 통하여 툴바 메소드에 이 옵션을 세팅하는게 최고입니다.
※ 메인윈도우의 X버튼(Remove)을 오른 클릭하면 메뉴가 나타납니다.
- "0" means "제거(Remove)"
- "1" means "제거하고 .torrent 삭제(Remove and delete .torrent)"
- "2" means "제거하고 데이터 삭제(Remove and delete Data)"
- "3" means "제거하고 .torrent+데이터 삭제(Remove and delete .torrent + Data)"
"gui.delete_to_trash": 활성화 시, μTorrent에서 삭제 파일을 휴지통에 넣지 않고 디스크에서 바로 지우기를 시도합니다. 만약 이 옵션을 쉽게 세팅하고 싶다면 GUI를 통해 툴바 메소드에 세팅하랍니다.
※ 메인윈도우의 X버튼(Remove)을 오른 클릭하면 메뉴가 나타납니다. 위에 기능 해보셨으면 이미 아셨겠죠^^
"gui.graphic_progress": 이 옵션은 토런트 작업 리스트의 각 토런트 작업을 프로세스바로 표시해줍다. "Done" column에 표시됩니다.(쉽게말해 이 체크를 해제하면 파란 게이지가 사라집니다.)
"gui.log_date": 이 옵션은 "Logger" 탭의 이벤트에 날짜를 보여준다. 해제시에는 시간만 표시.(로깅 할때 편하기 위한..)
"gui.piecebar_progress": 이 옵션은 토런트 작업 리스트의 각 토런트 작업을 저수준 다운로드 바로 바꿔서 표시해줍니다. "Done" column에 표시됩니다. 이 옵션은 "gui.graphic_progress"가 활성화 되어야하며, 그리고 "Done"column에서 "%"가 숨겨질 것입니다.
※ 퍼센트 게이지 대신 파트표시가 되는 게이지로 변경됩니다. %까지 사라지는걸로 봐서는 오버랩 시키는것 같습니다.
"gui.tall_category_list": 이 옵션은 카테고리 리스트(Category List )의 길고 짧은 높이 사이를 전환합니다. 길게 했을 때, 카테고리 리스트(Category List)와 상세 정보 창(Detailed Info Pane's)의 왼쪽 부분(left-hand side)이 서로 바뀝니다. 짧게 했을 때, 카테고리 리스트(Category List's)의 아랫부분(lower section)과 상세 정보 창(Detailed Info Pane's)이 서로 바뀝니다. 긴 리스트는 많은 레이블(labels)과 RSS 지원(feeds)와 함께 유저들에게 더 최선의 목록을 제공할지도 모른답니다.
※ 설정하면서 메인 윈도우에 오른쪽 카테고리 리스트를 보십시요. 백문이 불여일견 입니다.
"gui.update_rate": 이 옵션은 μTorrent 메인 윈도우의 각 업데이트 사이의 총시간을 제어합니다. 너무 높다면 메인 윈도우는 빈번하지 않게 갱신될 것입니다. 만약 사용자가 1000을 선택했다면 현재화면은 최대 1000 밀리초(1 초) 지난 메인 윈도우 정보 화면(displayed)을 의미합니다. 느린 컴퓨터를 가진 사용자는 메인 윈도우 출력 때 이 숫자를 늘려서 자원(resource)의 사용을 줄일 수 있을 것입니다. 500 미만의 임의의 값을 입력시 그 값은 무시고 대신의 500의 값이 사용될 것입니다.
"ipfilter.enable": 활성화 시, μTorrent 는 "ipfilter.dat"를 로드하고 로드된 필터링 룰(rules)이 접속에 적용될 것입니다. 이 옵션의 비활성화 후 재활성화를 사용하여 강제로 "ipfilter.dat"를 리로드(reload) 할 수 있습니다.
"isp.bep22": 이 옵션은 "로컬 트래커 발견(Local Tracker Discovery)"을 활성화 합니다, "reverse DNS lookups" 시리즈에 의해 허락된 "ISP-local trackers" 발견을 시도합니다. "ISP-local tracker"는 피어와 캐시(아마 ISP-local)의 목록을 되돌릴 수 있습니다. 만약 사용자의 ISP가 BitTorrent traffic을 방해하는지에 대해 알고있다면, 이 옵션의 활성화에 대한 결정에 대해 조심성 있게 고려해야 할것이다. [사용자가 사용하고있는 BitTorrent와 방해하는 ISP에 대해 쉽게 만들 수있는 알려진 "ISP-hosted tracker"는 ISP에 대해 가리킬 것이다.]<= "다들 이해하셨겠지만 날림 표십니다 ㅎㅎ;;" 비공개 토런트 작업은 "local trackers"에게 알리지 않는다.
This option enables Local Tracker Discovery, allowing μTorrent to attempt to discover ISP-local trackers via a series of reverse DNS lookups. The ISP-local tracker can return a list of peers and caches (most likely ISP-local). Note that if your ISP is known to interfere with BitTorrent traffic, careful consideration should be taken in deciding to enable this option. Announcing to a ISP-hosted tracker indicates to the ISP that you are using BitTorrent, and as such, can make it easier for the ISP to interfere. Private torrent jobs are not announced to local trackers.
"net.bind_ip": 만약 사용자 컴퓨터의 설정이 필요하다면 들어오는 연결을 위해 NIC의 IP 주소를 이곳에 기술하여 사용할 수 있습니다.
※ NIC가 여러개인 즉, Default G/W가 아닌 incomming traffic만을 별도로 처리할 때 사용됩니다. load blancing 기능으로 생각하시면 됩니다.
"net.calc_overhead": 이 옵션을 사용하는 이유는 μTorrent 정보교환(communication) 오버헤드(overhead) 전송율(transfer rate) 추정(calculation)을 포함하기 위해서입니다. TCP/IP 오버헤드 율 추정을 추가해줍니다.
※ communication에 사용되는 TCP 프래임의 overhead를 계산하겠다는 얘깁니다.
"net.low_cpu": 활성화 시, 약간의 CPU 사용율 감소시켜줍니다. 사용자는 빠른 속도를 이루기 위해 이 옵션을 비활성화 해야 할 것입니다. 일반적으로, 대다수의 사람들은 극단적으로 빠른 연결들을 갖기위해 이 옵션을 사용하지 않는답니다.
※ 즉, 시스템 성능이 떨어질 경우 네트