[컴] Bittorent 의 peer message

아래 글은 ref. 1 > peer messages 에 대한 개인적인 이해에 바탕을 둔 번역입니다. 정확한 내용은 원문을 확인해 주세요.

peer messages

keepalive 메세지 이외(non-keepalive messages)에는 전부 첫 byte 에 type 정보를 가지고 있다.

type 의 종류는 아래와 같다.

• 0 - choke
• 1 - unchoke
• 2 - interested
• 3 - not interested
• 4 - have
• 5 - bitfield
• 6 - request
• 7 - piece
• 8 - cancel

위의 type 중에 0~4 번(   색)은 payload 가 없다.

have

have message 의 payload 는 한개의 index 이다. downloader 가 막 완료하고 hash 를 check 한 index 이다.

bitfield

bitfield(5) 는 항상 처음 메시지(first message) 로 보내진다.
bitfield 의 payload 는 bitfield 인데 downloader 가 보낸 index 는 1이 되고, 나머지들은 0 으로 set 된다.

현재 아무것도 갖고 있지 않은 downloader 들은 bitfield message 를 skip 할 수 있다.

bitfield 의 첫 byte 의 highest bit 이 index 0 이 되고, lowest bit 이 index 7 이 된다. 다음 byte 는 index 8-15 가 된다. 끝에 남는 bit 는 0 으로 set 된다.

실제 packet

request

request message 는 index, begin, 길이(length) 를 갖는다.
begin 과 length 는 byte offset 으로 표현된다.
파일의 끝부분에 걸려서 truncated 되지 않는다면 length 는 일반적으로 "2의 제곱" 이다.
모든 현재의 구현들은 2^14(16 KB) 를 사용한다.
그리고 이 이상의 크기를 요청하는 connection 들은 close 한다.

cancel

cancel 메시지들은 request message 와 같은 payload 를 갖는다. cancel 메시지들은 endgame mode(missing_piece/total_piece < 0.05) 동안에는 일반적으로 download 의 끝에 보내진다.

download 가 거의 끝났을 때, 마지막 몇개의 piece 들이 단일 modem line 에서 떨어진 채로 시간을 많이 소비하면서 다운로드 되어지는 경향이 있다.

downloader 가 자신이 가지고 있지 않은 piece 에 대해 request 를 보내는데, 이 때 이 request 가 pending 되고 있으면, downloader 는 자기가 연결해 download 하고 있는 peer 들에게 piece 에 대한 request 를 보낸다. piece 가 여러개라면, 한 peer 에 여러개의 request 를 보낸다.

이것이 비효율적이 되는 것을 막기위해, downloader 는 piece 가 도착할 때마다 다른 사람들에게 cancel message 를 보낸다.

piece

piece message 는 index, begin, piece 를 포함한다.
암묵적으로 이 piece 는 request message 와 관련이 있다는 것을 명심하자.
만약 빠른 승계(quick succession) 상태에서 choke 와 unchoke message 들을 받았을때나 전송이 너무 느릴때는 예상치못한 piece 가 download 되는 것이 가능하다.

Downloader 들은 일반적으로 piece 들을 random 한 순서로 다운로드 한다.
random 한 순서는 downloader 가 자신이 연결한 어느 peer 의 piece 에 대한 superset 이나 subset 만을 갖게 되는 것을 상당히 막아준다.

interested

interested 는 peer 가 내가 원하는 piece 를 가지고 있어서, 내가 관심있다의 표현이다. downloader 는 peer 에 대한 각 연결마다 am_interested / peer_interested 에 대한 변수를 갖고 있다. 그래서 downloader 가 peer 에게 관심이 있으면 am_interested 를 peer 가 downloader 에게 관심이 있으면 peer_interested 를 set한다.

choking

만약 downloader 가 peer 에게 choke 를 받으면 peer 가 downloader 를 choke 했기때문에 아무런 message 를 주고 받지 않는다. 마찬가지로 downloader 가 peer 에게 choke 를 날리면 그 peer 에게서는 아무것도 요청하지 않고, 받지 않는것이다. 그래서 보통 downloader 가 peer 마다 연결을 가지고 있는데 그 연결마다, downloader 가 peer 를 choke 했는지(am_choking) , 아니면, peer 가 downloader 를 choke 했는지(peer_choking) 에 대한 변수를 가지고 있다.


Choking 은 여러가지 이유로 수행된다. TCP congestion control 은 여러 connection 들을 통해 한번에 보낼 때는 매우 좋지 않게 동작한다. 또한 choking 은 각각의 peer 가 일관된 download rate 을 가지고 있다는 것을 확신할 수 있도록 tit-for-tat-ish algorithm 을 사용하게 해준다.

아래 설명된 choking 알고리즘은 현재 배포된 녀석이다.
모든 새로운 알고리즘들은 "완전하게 그 알고리즘으로 이뤄진 network" 와 "대부분 그 알고리즘으로 이뤄진 network 양쪽 모두에서 잘 동작하는 것"은 매우 중요하다.

좋은 choking 알고리즘이 준수해야 하는 여러 기준이 있다.

1. 그것은 좋은 TCP performance 를 위해 동시 upload 수의 상한을 둬야만 한다.
2. fibrillation : choking 과 unchoking 을 빠르게 피해야만 한다.
3. download 를 하게 해준 peer 들에게 화답해야한다.(reciprocate)
4. optimistic unchoking : 때때로 현재 사용하고 있는 연결보다 더 나은 녀석들을 찾아내기 위해 사용되지 않는 연결들의 성능을 테스트 해 봐야 한다.

현재 배포된 choking 알고리즘

현재 배포된 choking 알고리즘은
단순히 매 10초마다 "한번이라도 choked 된 사람"을 변경하는 것으로 fibrillation 을 피한다.
가장 빠른 download rate 을 가지고 있고, interested 4 명의 peer 를 unchoking 하는 것으로 이 알고리즘은 화답과 upload 의 개수의 상한을 두는것을 한다.

참고로, 여기서 interested 는 peer 가 interested message 를 받은 상태이다. downloader 는 peer 에 자신에게 없는 새로운 piece 가 없다면 peer 에게 not interested message 를 보내게 된다.

4 개의 peer 들을 unchoking 하는 방법으로 화답(reciprocation) 과 upload 개수의 상한을 두는 것을 하는데, 이 4명의 peer 들은 가장 빠른 download rate 을 가지고 있고, interested 이다(are interested)
It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested.

좀더 나은 upload rate 을 가지고 있지만 not interested 한 peer 들은 unchoked 된다. 그리고 만약 그들이 interested 되면, 최악의 uploader 가 choked 된다.
만약에 downloader 가 complete file 을 가지고 있다면,  unchoke 될 대상을 결정할 때 download rate 보다는 upload rate 을 이용한다.

낙관적인 unchoking 을 위해, 그것의 upload rate 와는 상관없이 한 순간에 하나의 unchoked 된 peer 는 존재한다.(만약 interested 라면, 그것은 4명의 허락된 downloader 중 하나로 count 된다.)

peer 가 낙관적으로 unchoked 되는 녀석은 매 30초마다 rotate 한다.
upload 하기위한 complete piece를 얻을 적절한 기회를 주기위해서, rotation 의 어느곳에서나 현재의 낙관적인 unchoke 보다 새로운 연결들을 3배 더 많이 시작하는 경향이 있다.
For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of its upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. To give them a decent chance of getting a complete piece to upload, new connections are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation.

Reference

1. The BitTorrent Protocol Specification > peer messages