Bên Renesys có một bài tóm tắt rất hay. Trước khi thả rông mấy cái diplomatic cables, Wikileaks.org dùng 2 nhà cung cấp dịch vụ của Thụy Điển là Bahnhof và PRQ, và một ISP của Pháp là Cursys. Sau đó, cuối tháng 11, họ thêm vào Amazon EC2 cloud để mở rộng cửa đón khách. Nhà to cửa rộng, khách thì đông. Chú Hydra này có vài cái đầu tiếp khách, nhét vào Amazon một cái.

Doanh nhân bụng to Amazon bị Hercules dọa, đến hôm 1 tháng 12 tống cổ một đầu Hydra không chứa chấp nữa. Chú Hydra thêm vào cái đầu mới, nhét vào OVH (ISP của Pháp). Thêm bọn doanh nhân bụng to đầu lắm tóc như Paypal, Visa, Master card cũng phủi tay chạy mất dép, giảm cash flow vào Wikileaks. Rồi đến chú EveryDNS cũng từ chối không trả lời câu hỏi “IP của Wikileaks.org là gì?” luôn.

Mà cái tên miền Wikileaks.org cũng rất tếu. Nếu bạn hỏi bọn root servers, bọ nó sẽ chỉ đến các authoritative name servers của EveryDNS, có nghĩa là chú registrar có trách nhiệm với Wikileaks.org vẫn chưa phủi tay.

[NQH] MFM:~$ dig @d0.org.afilias-nst.org ns wikileaks.org.

; <<>> DiG 9.6.0-APPLE-P2 <<>> @d0.org.afilias-nst.org ns wikileaks.org.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20170
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;wikileaks.org.			IN	NS

;; AUTHORITY SECTION:
wikileaks.org.		86400	IN	NS	ns1.everydns.net.
wikileaks.org.		86400	IN	NS	ns2.everydns.net.
wikileaks.org.		86400	IN	NS	ns3.everydns.net.
wikileaks.org.		86400	IN	NS	ns4.everydns.net.

;; Query time: 111 msec
;; SERVER: 199.19.57.1#53(199.19.57.1)
;; WHEN: Wed Dec  8 11:01:57 2010
;; MSG SIZE  rcvd: 115

Thế nhưng các name servers của EveryDNS thì không trả lời câu hỏi về Wikileaks.org nữa.

Tên thì mất, nhưng mà IP address space thì vẫn sống nhăn răng. Ví dụ bạn có thể truy cập thẳng vào 178.21.20.8 thoải mái, dù có bị DDoS oánh tơi tả. Ngược lại cũng có một số nhóm hackers mũ … nồi, ủng hộ Wikileaks, và tấn cống các chú doanh nhân bụng to chân đất. MasterCard bị oánh sáng nay, chảy máu cam mất mấy tiếng.

Còn anh Hydra thì thêm tên: mọc ra Wikileaks.ch (Thụy Sĩ), wikileaks.de (Đức), wikileaks.eu (EU), wikileaks.fi (Phần Lan), wikileaks.nl (Hà Lan), wikileaks.pl (Ba Lan), wikileaks.se (Thụy Điển), wikileaks.to (Tonga), vân vân; Đám tên mới này trỏ vào khối địa chỉ 88.80.0.0/19 do Bahnhof chứa chấp. Một số tên trỏ vào một khối khác như 78.21.16.0/21 (của Serverius, Hà Lan), 46.59.0.0/17 (của Bahnhof, Thụy Điển), hay 213.251.128.0/18 (của OVH ở Pháp).

Ngoài ra, tìm một tên như wikileaks.ch chúng ta sẽ kiếm ra vài chục authoritative servers, trỏ đến các IPs khác nhau:

[NQH] MFM:~$ dig @dns1.syshack.org a wikileaks.ch.

; <<>> DiG 9.6.0-APPLE-P2 <<>> @dns1.syshack.org a wikileaks.ch.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5067
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 14, ADDITIONAL: 1

;; QUESTION SECTION:
;wikileaks.ch.			IN	A

;; ANSWER SECTION:
wikileaks.ch.		1800	IN	A	178.21.20.9
wikileaks.ch.		1800	IN	A	213.251.145.96
wikileaks.ch.		1800	IN	A	46.59.1.2
wikileaks.ch.		1800	IN	A	178.21.20.8

;; AUTHORITY SECTION:
wikileaks.ch.		1800	IN	NS	ns1.twisted4life.com.
wikileaks.ch.		1800	IN	NS	v217241437.yourvserver.net.
wikileaks.ch.		1800	IN	NS	ns1.buzzernet.net.
wikileaks.ch.		1800	IN	NS	ns1.pcdog.ch.
wikileaks.ch.		1800	IN	NS	lou.porcus.ch.
wikileaks.ch.		1800	IN	NS	dns2.syshack.org.
wikileaks.ch.		1800	IN	NS	dns.wikileaks.ch.
wikileaks.ch.		1800	IN	NS	s2.s3cr3t.de.
wikileaks.ch.		1800	IN	NS	elrido.no-ip.org.
wikileaks.ch.		1800	IN	NS	ns2.easydns.com.
wikileaks.ch.		1800	IN	NS	dns1.syshack.org.
wikileaks.ch.		1800	IN	NS	arjeplog.scnr.ch.
wikileaks.ch.		1800	IN	NS	marmotta.brabbel.ch.
wikileaks.ch.		1800	IN	NS	dns2.easydns.net.

Rồi nếu bạn vào một trong số các tên trên, bạn sẽ thấy một danh sách của hơn một nghìn các mirror sites, có cả IPv6.

Đó là chưa kể đám torrents nhãi nhép đông nhung nhúc không cách chi giết được. Như mấy sợi lông của Tề Thiên.

Hercules. Đừng hòng chặt đầu rắn.

Nhưng, có một điều Hercules có thể làm được. Thả ra nghìn vạn rắn ... giả. Chúng ta sẽ không còn biết rắn nào thật rắn nào giả nữa. Maximize entropy

Dù có viễn kiến vĩ đại, Cerf và Kahn hiển nhiên không phải là những người duy nhất đóng góp vào TCP. Họ chỉ đặt một cái nền. Còn trong vòng 40 năm nay có biết bao nhiêu người đã đóng góp vào cải thiện nhiều mặt của TCP. Thật ra chỉ cần đến khoảng cuối những năm 80 là “diện mạo” của TCP đã rất khác so với hồi Cerf và Kahn thiết kết nó.

Xem qua quá trình tiến hóa của TCP, một điều hiển hiện là việc giữ cho một giao thức hoạt động đúng như ý mình muốn thật là nan giải. Có hai lý do chính, đều liên quan đến sự đa dạng. Thứ nhất là sự đa dạng của các loại mục tiêu khác nhau mà ta muốn giao thức đạt được: hiệu suất cao, tính bảo mật tốt, dùng ít tài nguyên mạng và tài nguyên tính toán, xử lý cực nhanh với tốc độ ánh sáng, giữ cho phiên bản mới của giao thức tương hợp với phiên bản cũ, vân vân. Thứ hai là sự đa dạng (và đa nguyên) của những nhóm nghiên cứu và các công ty đóng góp vào cải tiến về lý thuyết và lập trình giao thức trên thực tế. Làm thế nào để đảm bảo rằng TCP do Microsoft lập trình chạy tốt với TCP của Linux, của BSD, của SunOS, MacOSX, cùng với cơ man nào là các phiên bản khác nhau của chúng. Khó nữa là chúng ta không có một bộ khung lý thuyết nào khả thi để có thể xác minh xem một thiết kế giao thức cho trước là thiết kế “tốt”: các bộ phận hoạt động đồng bộ với nhau, các phiên bản hoạt động không ngáng giò nhau, vân vân.

Khó thế đấy. Vậy mà, khi ta click vào http://www.procul.org/blog ta thấy ngay cái blog này. Bất kể ta chạy máy gì, hệ điều hành gì. Nó cho thấy sự tráng kiện (robustness) của giao thức TCP và của các giao thức mạng nói chung.

Thế nhưng, có khi các bộ phận của TCP thật sự không hoạt động đồng bộ với nhau, thậm chí chỉ vì một byte dữ liệu. Khi điều này xảy ra, nếu không hiểu rõ TCP và các ngóc ngách của nó thì không thể hiểu tại sao lại có những hiện tượng “ma quái” như vậy. Câu chuyện sau đây chỉ là một vị dụ.

Chuyện như sau. Một nhóm kỹ sư muốn thử nghiệm hiệu suất hoạt động của một hệ thống Wifi. Họ viết một chương trình nhỏ để gửi dữ liệu giữa hai máy dùng hệ thống Wifi nọ. Chương trình thiết lập một kết nối TCP giữa hai máy, xong rồi bên gửi gửi đi 100KB, bên nhận gửi lại một gói ký nhận nhỏ, rồi bên gửi lại gửi đi 100KB kế tiếp, vân vân. Mục tiêu là thực hiện gửi nhận như vậy liên tục một thời gian xem tốc độ truyền là bào nhiêu.

Kết quả: hệ thống Wifi này trên Windows XP đạt được tốc độ 3.5Mbps, còn trên MacOSX chỉ đạt được 2.7Mbps. Trong ngữ cảnh của họ thì 3.5Mbps là tốt. 2.7Mbps không tốt.

Vậy Windows XP có bộ TCP tốt hơn MacOSX? (Giả sử thẻ mạng và các thứ khác tương tự nhau.)

Không. Sau vài lần nghịch với các tham số. Họ giảm 100KB xuống còn 99,912 bytes (để gửi một đợt trước khi nhận gói xác minh). Về nguyên tắc, thay vì 100KB một vòng, ta thử 99KB một vòng thì tốc độ không nên có thay đổi gì dáng kể. Thế mà tốc độ của MacOSX tự nhiên tăng lên đến 5.2Mbps: hơn Windows và gần gấp đôi tốt độ cũ. Thú vị hơn nữa, nếu thay 99,912 bytes bằng 99,913 bytes một đợt thì tốc độ của MacOSX lại giảm xuống 2.7Mbps như xưa.

1 byte mà có thể tăng tốc TCP của Mac gấp đôi? Chuyện gì xảy ra?

Số là, trong mấy trăm cái mẹo cải thiện hiệu suất được đưa vào TCP trong 40 năm qua, có 4 cái mẹo tương tác với nhau rất độc đáo tạo ra hiện tượng trên.

Để mô tả 4 cái mẹo này, trước hết chúng ta lược qua xem TCP làm việc thế nào. Đại khái, TCP là một giao thức cung cấp dịnh vụ tin cậy cho “khách hàng” là các ứng dụng (như web browser, server, Media player, và rất nhiều các ứng dụng mạng khác). Để tạo ra dịch vụ tin cậy, TCP gửi dữ liệu giữa hai đầu gửi-nhận và bắt bên nhận gửi lại các mẩu xác minh là đã nhận (acknowledgements, viết tắt là ACK). Các mẩu dữ liệu của TCP tiếng Anh gọi là segments. Các mẩu dữ liệu được nhét vào các “gói dữ liệu”, như là các phong bì mà bên trong chứa dữ liệu còn bên ngoài chứa thông tin điều khiển và địa chỉ gửi nhận. Bao bì tốn khoảng 20 bytes, cộng thêm 20 bytes bao bì của mạng nữa là khoảng 40 bytes cho mỗi gói dữ liệu.

Mẹo 1: kích thước từng mẩu dữ liệu. Một phong bì do TCP gửi không thể chứa nhiều dữ liệu quá. Tại vì các gói dữ liệu đi qua nhiều loại mạng khác nhau. Mỗi loại mạng có kích thước gói tối đa khác nhau. Ví dụ mang Ethernet có kích thước tối đa là 1500 bytes, mạng X25 có kích thước gói tối đa là 576 bytes, vân vân. Một trong các lý do mà các mạng giới hạn kích thước gói dữ liệu là vì nếu kích thước gói lớn quá thì mỗi lần đường truyền bị lỗi gì ta phải gửi lại toàn bộ gói. Gói càng lớn thì xác suất nó bị lỗi càng cao, mà gửi lại gói to thì tốn tài nguyên hơn gửi lại gói nhỏ. Thế cho nên, nếu TCP gửi một cái phong bì khổng lồ thì đến mạng có giới hạn kích thước phong bì nó sẽ bị băm nhỏ ra thành nhiều gói nhỏ. Mỗi gói nhỏ tốn một phong bì riêng. Và như thế thì rất tốn. Túm lại, TCP có một biến số gọi là MSS để lưu trữ kích thước mẩu lớn nhất (của một kết nối). Có các thuật toán để xác định MSS nên là bao nhiêu cho mỗi kết nối. Nếu không chạy thuật toán thì trị mặc định là 576 – 40 = 536, trong đó 576 là do X25, còn 40 là kích thước bao bì của TCP/IP như đã nói ở trên. Nếu chỉ truyền trên Ethernet thì MSS nên là 1500-40 = 1460.

Mẹo 2: thuật toán Nagle. Thử tưởng tượng một khách hàng của TCP cứ thích đưa mỗi lần vài bytes cho TCP để gửi qua bên nhận. Các ứng dụng như telnet, ssh, rlogin lấy inputs từ chúng ta. Chúng ta gõ bàn phím rất chậm (tính theo tốc độ máy). Người gõ nhanh nhất thế giới cũng chỉ gõ được khoảng 150 từ một phút, vị chi là khoảng vài chục đến vài trăm mili-giây một ký tự. Do đó, hoàn toàn có khả năng là ứng dụng sẽ “đưa cho” TCP từng ký tự một, cứ khoảng 100-mili giây một ký tự. Mỗi lần tải một mẩu dữ liệu 1 ký tự, TCP phải tốn ít nhất 40 bytes bao bì cho nội dung thư. Tỉ lệ phí hoài là 40/41, gần bằng tỉ lệ phí hoàn cho Vinashin. Rất tốn băng thông! Do đó, hồi 1984 John Nagle đề nghị là TCP nên tích lũy một ít “hàng họ” (nghĩa là, ký tự) trước khi gửi. Ít nhất, nếu có một phong bì gửi trước đó mà chưa có hồi âm thì khoan hẵng gửi phong bì ít hàng hiện tại. Chờ hồi âm của phong bì trước, xong rồi hẵng gửi phong bì mới. Lý do là, trong thời gian chờ hồi âm, nhỡ đâu chú khách hàng lại tuồn thêm cho vài ký tự để đóng chung vào một gói thì đỡ tốn phí vận chuyển. Còn trong trường hợp phong bì đã đầy (MSS) thì gửi luôn không cần chờ.

(Mấy bác chuyên môn đánh áo phông bàn chải bên Đông Âu hồi xưa chắc chắn đã hiểu rõ bài toán đóng hàng này.)

Mẹo 3: hồi âm muộn (Delayed ACK). Ở phía bên nhận, để tiết kiệm phí vận chuyển thì TCP thường cố gắng đóng gói cả hồi âm lẫn dữ liệu chiều ngược (gọi là piggy-backing) gửi chung vào một gói. Ví dụ như sau khi nhận một thư từ browser, web-server đọc lên một file nào đó (index.html chẳng hạn) và gửi lại cho browser. Nếu TCP đừng hồi âm ngay, chờ một xíu cho chú server đọc đĩa, thì có luôn cả index.html mang cùng với hồi âm về. Do đó, chuẩn TCP có cái mẹo hồi âm muộn, bắt bên nhận chờ khoảng 200ms đến 500ms trước khi hồi âm một mẩu dữ liệu từ bên kia. Nhưng nếu trong thời gian chờ mà nhận thêm được một thư nữa thì hồi âm cả hai ngay. (Nếu không, bên kia tưởng thư mất gửi lại mất công lắm.) Đây là luật hồi âm kép.

Mẹo 4: nhãn thời gian (timestamp option). Để đảm bảo độ tin cậy, TCP cần biết xem thư gửi đi đã nhận được chưa. Nếu thư bị mất, hoặc hồi âm bị mất thì không nhận được hồi âm. Do đó, TCP cần có một cái đồng hồ báo mất. Khi đồng hồ reng leng keng thì gửi thư lại. Nếu thời khoảng gửi lại quá bé thì không tốt: tại vì có thể hồi âm đang trên đường về, chưa chi đã gửi lại. Nếu thời khoảng gửi lại quá dài thì cũng không tốt: thư đã mất mà không gửi lại luôn còn chờ gì nữa? Do đó, TCP cần một cơ chế để ước lượng thời gian khứ hồi là bao nhiêu, xong rồi đặt thời khoảng cho đồng hồ gửi lại cỡ chừng thời gian khứ hồi cộng với một khoảng đệm cho chắc. (Thuật toán ước lượng thời khoảng khứ hồi phức tạp hơn một chút, nhưng đại khái là thế.) Làm thế nào để đo thời gian khứ hồi? Cách thứ nhất là gửi thư, rồi khi nhận được hồi âm thì xem đó là thời gian khứ hồi. Nhưng mà nếu thư bị mất, phải gửi lại, rồi nhận được hồi âm, thì mình không biết là hồi âm cho thư cũ hay thư mới. Ngoài ra, nếu bên nhận lại dùng mẹo hồi âm muộn thì ước lượng thời gian khứ hồi của mình bị sai đi. Còn nữa, TCP thường gửi nhiều thư cùng một lúc, và nếu dùng một đồng hồ cho mỗi thư thì rất phức tạp và tốn tài nguyên. Cách thứ hai là mỗi lần gửi thư đi thì dán tem chứa thời điểm hiện tại vào đó. Bên nhận, trước khi hồi âm, lấy tem của thư bỏ vào hồi âm. Khi nhận được hồi âm thì bên gửi chỉ cần lấy thời điểm hiện tại trừ đi giá trị tem là biết thời khoảng khứ hồi. Cách đo thời khoảng khứ hồi dùng nhãn thời gian này tốt hơn, nhưng như thế thì ta lại tốn thêm 12 bytes để làm nhãn và vì thế trên Ethernet thì MSS chỉ còn tối đa là 1500 – 52 = 1448 bytes thay vì 1460 bytes như trước.

Tương tác giữa 4 cái mẹo. Quay lại với câu chuyện thử hiệu xuất giữa Windows và MacOSX trên Ethernet. Khác biệt thứ nhất là Windows XP không dùng nhãn thời gian, cho nên MSS = 1460, còn MacOSX dùng nhãn thời gian cho nên MSS = 1448 (trong môi trường thử nghiệm). Do đó, 100000 bytes được

• TCP của Windows XP băm ra thành 68 mẩu, mỗi mẩu 1460 bytes, cộng với một mẩu 720 bytes.
• TCP của Mac OSX băm ra thành 69 mẩu, mỗi mẩu 1448 bytes, cộng với một mẩu 88 bytes.

Khi Windows XP truyền thì:

• Bên gửi gửi đi 68 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (720 bytes) chờ hồi âm của mẩu 68.
• Bên nhận dùng luật hồi âm kép nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, và cuối cùng khi bên gửi nhận được hồi âm của mẩu 68 sẽ gửi ngay mẩu lẻ cuối cùng.

Khi Mac OSX truyền thì:

• Bên gửi gửi đi 69 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (88 bytes) chờ hồi âm mẩu 69.
• Bên nhận theo luật hồi âm kép, nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, nhưng giữ lại không hồi âm mẩu 69 ngay (trừ phi có thêm hàng họ của khách hàng gửi kèm hồi âm mang về)
• Nhưng hàng họ chỉ có sau 100KB, mà bây giờ bên nhân mới nhận được 100000-88 bytes thôi nên chưa có hàng.
• Bên gửi thì dùng thuật toán Nagle, giữ lại 88 bytes chờ khi mẩu 69 có hồi âm.
• Kết quả là hai bên phải chờ thêm từ 200ms đến 500ms nữa, tùy theo người lập trình TCP chọn giá trị hồi âm muộn là bao nhiêu.
• Kết quả cuối cùng là cứ 100KB thì MacOSX bị chậm lại 200ms!

200ms là một thời khoảng rất lớn. Trên Gigabit Ethernet, với tốc độ 1Gbps thì trong 200ms ta truyền được 200Mb vị chi là 25MB.

#############################################################################
#   $ make           compile and link all C programs specified with PROGS
#   $ make clean     clean objects and the executable file
#   $ make distclean clean objects, the executable and dependencies
# I assume that each .c has a .h of the same name in directory INC_DIR
# You can compile multiple programs by redefining $(PROGS)
#===========================================================================

## Customizable Section: adapt those variables to suit your program.
##==========================================================================
# The pre-processor and compiler options.
MY_CFLAGS = -I./include -DBE_DEBUG -D_REENTRANT -Wall -D__EXTENSIONS__

# Libraries to link to, depending on OS
UNAME = $(shell uname)
ifeq ($(UNAME), SunOS)              # Sun OS
MY_LIBS = -lresolv -lsocket -lnsl
endif
ifeq ($(UNAME), Linux)              # Linux
MY_LIBS = -lresolv -lnsl
endif
ifeq ($(UNAME), Darwin)             # Mac OS
MY_LIBS =
endif

# Directory where your .h files are
INC_DIR := ./include

# The options used in linking as well as in any direct use of ld.
LDFLAGS +=

# The executable file names.
PROGS   = server client iom_client

## Implicit Section: change the following only when necessary.
##==========================================================================

CC := gcc
SRCS := $(wildcard *.c)

# objects other than those in PROGS
ALL_OBJS := ${SRCS:.c=.o}
ALL_NAMES := ${ALL_OBJS:.o=}

# all object files other than those named $(PROGS).o
COMMON_OBJS :=
define APPEND_CO
ifeq (,$(findstring $(1), $(PROGS)))
COMMON_OBJS += $(1).o
endif
endef
$(foreach name,$(ALL_NAMES),$(eval $(call APPEND_CO, $(name))))

.PHONY: all clean distclean

all: $(PROGS)

define PROG_RULE
$(1) : $(COMMON_OBJS) $(1).o
        ${CC} -I${INC_DIR} ${CFLAGS} ${MY_LIBS} ${COMMON_OBJS} $(1).c -o $(1)
endef

$(foreach program,$(PROGS),$(eval $(call PROG_RULE, $(program))))

## Objects are dependent on headers (and implicitly .c files)
##==========================================================================
define OBJ_RULE
$(1) : ${INC_DIR}/${1:.o=.h} ${1:.o=.c}
        ${CC} -I${INC_DIR} ${CFLAGS} -c ${1:.o=.c}
endef

$(foreach obj_file,$(ALL_OBJS),$(eval $(call OBJ_RULE,$(obj_file))))

## clean things up
##==========================================================================
clean:
        @- $(RM) $(PROGS)
        @- $(RM) $(ALL_OBJS)

distclean: clean

1. Purpose and basic requirements

Project 1 hopefully have familiarized you with basic socket programming. Please check out my implementation (source) of project 1. I hope you can build on it or learn something from it. Project 2 is no longer “toyish.” You will implement a basic subset of the BitTorrent protocol, which is one of the (two) most popular P2P file sharing protocols on the Internet. BitTorrent traffic constitutes a large fraction of modern Internet traffic. If you implement the protocol correctly, your “client” should be able to download files from other BitTorrent clients “in the wild,” and there are millions of those peers.

The assignment is to be done in groups of size at most 2. You are responsible for finding your partner (if you need one), for finishing off the assignment in case your partner drops the class or backs out from completing the assignment for whatever reason. The program is to be written in C under a Unix platform such as Linux, SunOS, Solaris, or FreeBSD, or even Mac OS X. Under Windows, it is possible to develop your program with cygwin but you must make sure that:

• Your submission compiles and runs under both Linux and Solaris/SunOS. We will test your submission on both Linux and Solaris/SunOS machines.
• Except for C++ (which is still not at all recommended), no other language is allowed. I have good pedagogical reasons for this requirement.

For portability, please use the Makefile I provided in my Project 1 implementation, so that we can compile your program under these two platforms.

2. UBTorrent — overview of the protocol

Let’s refer to the subset of the BitTorrent protocol that we (i.e. you and I) will implement the UBTorrent protocol. It is BitTorrent with some advanced features stripped off. For simplicity, we will also name the program to be implemented ubtorrent, each instance of which is called a UBTorrent peer, or just a peer for short. For convenience, when we talk about the behavior of a particular peer, we will call it a (UBTorrent)client, to distinguish it from other peers.

The “official” BitTorrent protocol specification written by Bram Cohen is vague is some areas. Thus, I will copy materials from a more detailed specification of BitTorrent 1.0. You do not need to read the official specifications, because UBTorrent is (hopefully) simpler.

Peers collaborate to download files. Let’s say some client has a file to be shared named “Simon and Garfunkel – Sound of Silence.mp3“. Actually, let’s rename it “SS.mp3” for short. The client first needs to create a metainfo file containing information about SS.mp3. The metainfo file has the .torrent extension, and is often referred to as the “dot torrent” file of SS.mp3. The precise format of the metainfo file will be described below. Roughly, it contains the file name, keywords (if any), the URL of a program called a tracker, which is responsible for keeping track of all the peers who are collaborating in downloading SS.mp3.

2.1 Creating the metainfo file

In the wild, you will typically have to upload the metainfo file to some webserver, allowing others to search for it, and download it. But in Project 2, we will assume that every peer has the metainfo file already, bypassing the search step. (Feel free to implement a web search engine, in which case you should drop out of UB right about now.) In particular, we’ll just create the metainfo file for SS.mp3 and “give” it to each participating peer.

You can create the metainfo file using a command line utility that Bram Cohen wrote in Python a while back, named btmakemetafile. Here’s a directory containing the utility (and supporting files). Download, gunzip and untar it, you will get a directory named MMT containing the utility. To create a metafile for SS.mp3, you can type something like this:

UBTorrent/MMT/btmakemetafile SS.mp3 http://127.0.0.1:6969/announce

The first argument is the file name (or path to file name if you’re not running the utility in the directory where the file resides). The second argumenthttp://127.0.0.1:6969/announce is called the URL of the tracker, which basically consists of the IP address and the port number that the tracker is running and listening on. Note that the tracker will run the HTTP protocol, and hence there’s the http:// in the beginning.

Important note: you might need to edit the first line of btmakemetainfo to point to the right path of python for btmakemetainfo to work. Typewhich python to get the path.

2.2. The tracker

It would be nice if we wrote your own tracker, but that would be too easy to do in 2 months. So, let’s not do that. We will use probably the most well-known tracker out there: the opentracker written by Dirk Engling. It is (was?) used by PirateBay.com and even a Norwegian state TV broadcaster.

To download and compile opentracker, download these files, unzip and untar them, you’ll get two directories named libowfat and opentracker. You MUST put the two directories under the same parent directory for the compilation to work. Then, cd into libowfat and type make, and cd intoopentracker and type make. Alternatively, you can just follow Dirk Engling direction on his opentracker website:

cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co
libowfat
cd libowfat
make
cd ..
cvs -d:pserver:anoncvs@cvs.erdgeist.org:/home/cvsroot co opentracker
cd opentracker
make

There are two versions, opentracker and opentracker.debug, and you can run either of them. For instance,

hungngo@MYMACHINE:~/UBTorrent/opentracker$ ./opentracker.debug -i 127.0.0.1
Binding socket type TCP to address [127.0.0.1]:6969... success.
Binding socket type UDP to address [127.0.0.1]:6969... success.

will tell it to listen to port 6969 (default port) on the local interface.

Note: if make reports some error, please try gmake.

2.3. The protocols

Once the tracker is running (on the URL specified in the metainfo file for SS.mp3), peers can start collaborating on downloading this file. To get to know other peers, a client talks to the tracker using the Tracker HTTP Protocol, which is simply a tiny subset of the HTTP protocol. The tracker maintains and updates information about the torrent or the swarm, which is the set of participating peers. Every shared file corresponds to a swarm. A new peer can join the swarm by informing and querying the tracker.

Once knowing each other, peers can talk directly to each other using the Peer Wire Protocol over TCP to exchange pieces of SS.mp3. A swarm can be large, containing any where from tens to thousands of peers. Thus, a client only connects to a subset of those. The original client which had the file SS.mp3 to share is called a seeder. Peers who do not have the entire file yet are called leechers. There might be multiple seeders for the same file, because once a leecher has downloaded the entire file, it will become a seeder. Peers can leave a swarm at any time, on their own terms.

While the Tracker HTTP Protocol is very simple both conceptually and practically, the Peer Wire Protocol (PWP) is only conceptually simple: a client requests pieces of the file from other peers until it got the entire file. If everyone was as enlightened as Buddha, PWP would have been extremely simple and there would be no Nobel prize in economics. Unfortunately, in the wild PWP has to solve the free rider problem while keeping the download efficient.

For efficiency, PWP uses a simple strategy called rarest first in which, given the current list of missing pieces, the client requests a rarest one first (i.e. a piece which fewest — but non-zero — of its neighboring peers have). Typically, there are many pieces which are equally rare. In this case it is also important to randomly pick one of them to download. This way, the availability of pieces are spread out and thus even when all seeders go to heaven, chances are better that no piece goes extinct.

To solve the free rider problem, PWP uses something called choke algorithms. A client gives pieces to good guys and “chokes” guys who haven’t given the client much. This is also called a tit-for-tat strategy. However, to avoid peers choking each other to death, especially in the beginning, a client also randomly unchokes some (potentially) bad guy too. This is called optimistic unchoking.

Recent studies have shown that rarest first and choke algorithms are pretty good at solving both the free rider problem and the download efficiency problem. However, these mechanisms are far from perfect and there are a lot of potentials for further research and new protocol design. I hope some of you will get interested in this problem and start experimenting with new ideas. You could be the next Bram Cohen! (I’ll gladly accept a small stake in the new company.)

3. The ugly details

A large part of this section is copied (selectively) from the BitTorrent protocol specification. However, I have also stripped off many requirements. When in doubt, ask me (via the blog), don’t consult the official BitTorrent protocol specification. After all, we are implementing UBTorrent, not BitTorrent.

3.1 Bencoding

Bencoding is a way to specify and organize data in a terse format. It supports the following types: byte strings, integers, lists, and dictionaries.

3.1.1 Byte strings

Byte strings are encoded as follows: <string length encoded in base ten ASCII>:<string data>
Note that there is no constant beginning delimiter, and no ending delimiter.

Example: 4:spam represents the string “spam”

3.1.2 Integers

Integers are encoded as follows: i<integer encoded in base ten ASCII>e
The initial i and trailing e are beginning and ending delimiters. You can have negative numbers such as i-3e. You cannot prefix the number with a zero such as i04e. However, i0e is valid.

Example: i3e represents the integer “3″

3.1.3 Lists

Lists are encoded as follows: l<bencoded values>e
The initial l and trailing e are beginning and ending delimiters. Lists may contain any bencoded type, including integers, strings, dictionaries, and other lists.

Example: l4:spam4:eggse represents the list of two strings: [ "spam", "eggs" ]

3.1.4 Dictionaries

Dictionaries are encoded as follows: d<bencoded string><bencoded element>e
The initial d and trailing e are the beginning and ending delimiters. Note that the keys must be bencoded strings. The values may be any bencoded type, including integers, strings, lists, and other dictionaries. Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics). The strings should be compared using a binary comparison, not a culture-specific “natural” comparison.

Example: d3:cow3:moo4:spam4:eggse represents the dictionary { “cow” => “moo”, “spam” => “eggs” }

Example: d4:spaml1:a1:bee represents the dictionary { “spam” => [ "a", "b" ] }

Example: d9:publisher3:bob17:publisher-webpage15:www.example.com18:publisher.location4:homee represents { “publisher” => “bob”, “publisher-webpage” => “www.example.com”, “publisher.location” => “home” }

3.1.5 You don’t have to implement a bendecoder

You can use a bendecoder written in C by Mike Frysinger here. Feel free to write your own. After downloading the entire directory, you can test the bendecoder by make and then try

hungngo@MYMACHINE:~/tmp/bencode$ ./test i1234e
DECODING: i1234e
int = 1234
hungngo@MYMACHINE:~/tmp/bencode$ ./test l4:spam4:eggse
DECODING: l4:spam4:eggse
list [
    str = spam (len = 4)
    str = eggs (len = 4)
]
hungngo@MYMACHINE:~/tmp/bencode$ ./test d3:cow3:moo4:spam4:eggse
DECODING: d3:cow3:moo4:spam4:eggse
dict {
    cow => str = moo (len = 3)
    spam => str = eggs (len = 4)
}

Obviously, you should look into the code to see how to use the functions. But the decoder is there, no coding needed. This decoder is the bulk of the metainfo command that you’re supposed to implement.

3.2. Metainfo file structure

All data in a metainfo file is bencoded. The content of a metainfo file (the file ending in “.torrent”) is a bencoded dictionary, containing the keys listed below. All character string values are UTF-8 encoded.

• announce: The announce URL of the tracker (string)
• info: a dictionary that describes the file(s) of the torrent. There are two possible forms: one for the case of a ‘single-file’ torrent with no directory structure, and one for the case of a ‘multi-file’ torrent (see below for details)
• a few other optional keys such as, creation date, comment, created by, and encoding. When you read the metainfo file, ignore these keys.

The info dictionary contains the following fields:

• length: length of the file in bytes (integer)
• name: the filename. This is purely advisory. (string)
• piece length: number of bytes in each piece (integer)
• pieces: string consisting of the concatenation of all 20-byte SHA1 hash values, one per piece (byte string, i.e. not urlencoded)

Notes:

• The piece length specifies the nominal piece size, with default value 256KB = 2¹⁸ bytes = 262144 bytes. In practice, the piece length is typically chosen based on the total amount of file data in the torrent, and is constrained by the fact that too-large piece sizes cause inefficiency, and too-small piece sizes cause large .torrent metainfo file. Historically, piece size was chosen to result in a .torrent file no greater than approx. 50 – 75 kB (presumably to ease the load on the server hosting the torrent files).
  • Current best-practice is to keep the piece size to 512KB or less, for torrents around 8-10GB, even if that results in a larger .torrent file. This results in a more efficient swarm for sharing files. The most common sizes are 256 kB, 512 kB, and 1 MB.
  • Every piece is of equal length except for the final piece, which is irregular. The number of pieces is thus determined by ‘ceil( total length / piece size )’.
• Each piece has a corresponding SHA1 hash of the data contained within that piece. These hashes are concatenated to form the pieces values in the above info dictionary. Note that this is not a list but rather a single string. The length of the string must thus be a multiple of 20.
• Look carefully at my implementation of Project 1 for how to compute SHA1 hashes. (After a piece is downloaded, you will need to compute its SHA1 hash to verify its integrity!)

3.3. Tracker HTTP Protocol

The tracker is an HTTP service which responds to HTTP GET requests. The requests include metrics from clients that help the tracker keep overall statistics about the torrent. The response includes a peer list that helps the client participate in the torrent. The base URL consists of the “announce URL” as defined in the metainfo (.torrent) file. The parameters are then added to this URL, using standard CGI methods (i.e. a ‘?’ after the announce URL, followed by ‘param=value’ sequences separated by ‘&’).

Note that all binary data in the URL (particularly info_hash and peer_id) must be properly escaped. This means any byte not in the set 0-9, a-z, A-Z, ‘.’, ‘-’, ‘_’ and ‘~’, must be encoded using the “%nn” format, where nn is the hexadecimal value of the byte. (See RFC1738 for details.) This is called the urlencoding of the data.

For a 20-byte hash of

\x12\x34\x56\x78\x9a\xbc\xde\xf1\x23\x45\x67\x89\xab\xcd\xef\x12\x34\x56\x78\x9a

the right encoded form is

%124Vx%9A%BC%DE%F1%23Eg%89%AB%CD%EF%124Vx%9A

3.3.1 Tracker Request Parameters

The parameters used in the client->tracker GET request are as follows:

• info_hash: urlencoded 20-byte SHA1 hash of the value of the info key from the metainfo file. Note that the value will be a bencoded dictionary, given the definition of the info key above.
• peer_id: urlencoded 20-byte string used as a unique ID for the client, generated by the client at startup. This is allowed to be any value, and may be binary data.
• port: The port number that the client is listening on.
• uploaded: The total number of bytes uploaded (since the client sent the ‘started’ event to the tracker) in base ten ASCII.
• downloaded: The total number of bytes downloaded (since the client sent the ‘started’ event to the tracker) in base ten ASCII.
• left: The number of bytes this client still has to download, encoded in base ten ASCII.
• compact: Setting this to 1 indicates that the client accepts a compact response. The peers list is replaced by a peers string with 6 bytes per peer. The first four bytes are the host (in network byte order), the last two bytes are the port (again in network byte order). It should be noted that some trackers only support compact responses (for saving bandwidth) and either refuse requests without “compact=1″ or simply send a compact response unless the request contains “compact=0″ (in which case they will refuse the request.)
• event: If specified, must be one of started, completed, stopped, (or empty which is the same as not being specified). If not specified, then this request is one performed at regular intervals.
  • started: The first request to the tracker must include the event key with this value.
  • stopped: Must be sent to the tracker if the client is shutting down gracefully.
  • completed: Must be sent to the tracker when the download completes. However, must not be sent if the download was already 100% complete when the client started. Presumably, this is to allow the tracker to increment the “completed downloads” metric based solely on this event.

A request from the (original) seeder looks something like this:

GET /announce?info_hash=_tWL%26%BD%C4%BDsEn%FD%7E1%2CJ3%40s%1B&peer_id=M3-4-2--5ffd511f4079&port=6881&key=585b8345&uploaded=0&downloaded=0&left=0&compact=1&event=started HTTP/1.1

A request from a leecher looks something like this:

GET /announce?info_hash=_tWL%26%BD%C4%BDsEn%FD%7E1%2CJ3%40s%1B&peer_id=M3-4-2--f8c7df8ee1b9&port=6882&key=a6fa9e7e&uploaded=0&downloaded=0&left=90112&compact=1&event=started HTTP/1.1

Note: 90112 is the size of SS.mp3. A GET request typically consists of the GET request line (as shown above) and an empty line. The last two characters of an HTTP request line must be \r\n. The “empty” line must consist of two characters \r\n. Those are “carriage-return” and “line-feed” characters.

3.3.2 Tracker Response

The tracker responds with “text/plain” document consisting of a bencoded dictionary with the following keys:

• failure reason: If present, then no other keys may be present. The value is a human-readable error message as to why the request failed (string).
• warning message: (new, optional) Similar to failure reason, but the response still gets processed normally. The warning message is shown just like an error.
• interval: Interval in seconds that the client should wait between sending regular requests to the tracker
• min interval: (optional) Minimum announce interval. If present clients must not reannounce more frequently than this.
• tracker id: A string that the client should send back on its next announcements. If absent and a previous announce sent a tracker id, do not discard the old value; keep using it.
• complete: number of peers with the entire file, i.e. seeders (integer)
• incomplete: number of non-seeder peers, aka “leechers” (integer)
• peers: (dictionary model) The value is a list of dictionaries, each with the following keys:
  • peer id: peer’s self-selected ID, as described above for the tracker request (string)
  • ip: peer’s IP address either IPv6 (hexed) or IPv4 (dotted quad) or DNS name (string)
  • port: peer’s port number (integer)
• peers: (binary model) Instead of using the dictionary model described above, the peers value may be a string consisting of multiples of 6 bytes. First 4 bytes are the IP address and last 2 bytes are the port number. All in network (big endian) notation.

The list of peers is length 50 by default. If there are fewer peers in the torrent, then the list will be smaller. Otherwise, the tracker randomly selects peers to include in the response. The tracker may choose to implement a more intelligent mechanism for peer selection when responding to a request. For instance, reporting seeds to other seeders could be avoided. Since we are not implementing the tracker, we just take whatever the tracker gives.

Clients may send a request to the tracker more often than the specified interval, if an event occurs (i.e. stopped or completed) or if the client needs to learn about more peers. However, it is considered bad practice to “hammer” on a tracker to get multiple peers.

A reply from the tracker may look something like this:

HTTP/1.0 200 OK
Content-Length: 27
Content-Type: text/plain
Pragma: no-cache

d8:intervali1800e5:peers0:e

In general, the reply from the tracker follows the format specified here. You should print out the first line of the response. If the status code (e.g. the number 200 above) is anything other than 2xx, then something is wrong, don’t read and parse the content. The content of the reply is everything after the blank line. Note: if you didn’t do anything special (like having a persistent-connection request along with the GET line), the tracker will close the connection right after sending the reply. Don’t be surprise! You should try telnet localhost 6969 after running opentracker, and then cut-and-paste a sample request shown in the previous section to see the tracker’s response. Important note: The readline() function provided in the sample codes can be used, but it has to be used with extreme care, because it can read past the EOL character (for efficiency). Please read the code before using it!

3.4. Peer Wire Protocol (over TCP)

3.4.1 Overview

The peer protocol facilitates the exchange of pieces as described in the metainfo file. To request a piece, a client will actually send multiple requests for parts of the piece, called blocks.  A block size is typically divisible by the piece size. It is recommended to set the default block size to be 16KB =  2¹⁴ = 16384 bytes. Feel free to set the default block size to be equal to the piece size if you want. However, since the last piece may not have full size, some block requests will inevitably have to be of small sizes.

A client must maintain state information for each connection that it has with a remote peer:

• choked: Whether or not the remote peer has choked this client. When a peer chokes the client, it is a notification that no requests will be answered until the client is unchoked. The client should not attempt to send requests for blocks, and it should consider all pending (unanswered) requests to be discarded by the remote peer.
• interested: Whether or not the remote peer is interested in something this client has to offer. This is a notification that the remote peer will begin requesting blocks when the client unchokes them.

Note that this also implies that the client will also need to keep track of whether or not it is interested in the remote peer, and if it has the remote peer choked or unchoked. So, the real list looks something like this:

• am_choking: this client is choking the peer
• am_interested: this client is interested in the peer
• peer_choking: peer is choking this client
• peer_interested: peer is interested in this client

Client connections start out as “choked” and “not interested”. In other words:

• am_choking = 1
• am_interested = 0
• peer_choking = 1
• peer_interested = 0

A block is downloaded by the client when the client is interested in a peer, and that peer is not choking the client. A block is uploaded by a client when the client is not choking a peer, and that peer is interested in the client. It is important for the client to keep its peers informed as to whether or not it is interested in them. This state information should be kept up-to-date with each peer even when the client is choked. This will allow peers to know if the client will begin downloading when it is unchoked (and vice-versa).

3.4.2 Data type

Unless specified otherwise, all integers in the peer wire protocol are encoded as four byte big-endian values. This includes the length prefix on all messages that come after the handshake.

3.4.3 Message flow

The peer wire protocol consists of an initial 2-way handshake. After that, peers communicate via an exchange of length-prefixed messages. The length-prefix is an integer as described above.

3.4.4 Handshake

The handshake is a required message and must be the first message transmitted by the client. It is (49+len(pstr)) bytes long.

handshake: <pstrlen><pstr><reserved><info_hash><peer_id>

• pstrlen: string length of <pstr>, as a single raw byte
• pstr: string identifier of the protocol.
  • In the UBTorrent protocol, as in the BitTorrent protocol, pstrlen = 19, and pstr = “BitTorrent protocol”.
• reserved: eight (8) reserved bytes. All current implementations use all zeros. Each bit in these bytes can be used to change the behavior of the protocol. An email from Bram suggests that trailing bits should be used first, so that leading bits may be used to change the meaning of trailing bits.
• info_hash: 20-byte SHA1 hash of the info key in the metainfo file. This is the same info_hash that is transmitted in tracker requests.
• peer_id: 20-byte string used as a unique ID for the client

The initiator of a connection is expected to transmit their handshake immediately. The recipient may wait for the initiator’s handshake, if it is capable of serving multiple torrents simultaneously (torrents are uniquely identified by their info_hash). However, the recipient must respond as soon as it sees the info_hash part of the handshake. If a client receives a handshake with an info_hash that it is not currently serving, then the client must drop the connection.

If the initiator of the connection receives a handshake in which the peer_id does not match the expected peer_id, then the initiator is expected to drop the connection. Note that the initiator presumably received the peer information from the tracker, which includes the peer_id that was registered by the peer. The peer_id from the tracker and in the handshake are expected to match.

3.4.5 Messages

All of the remaining messages in the protocol take the form of <length prefix><message ID><payload>. The length prefix is a four byte big-endian value. The message ID is a single decimal byte. The payload is message dependent.

keep-alive: <len=0000>

The keep-alive message is a message with zero bytes, specified with the length prefix set to zero. There is no message ID and no payload. Peers may close a connection if they receive no messages (keep-alive or any other message) for a certain period of time, so a keep-alive message must be sent to maintain the connection alive if no command have been sent for a given amount of time. This amount of time is generally two minutes.

choke: <len=0001><id=0>

The choke message is fixed-length and has no payload.

unchoke: <len=0001><id=1>

The unchoke message is fixed-length and has no payload.

interested: <len=0001><id=2>

The interested message is fixed-length and has no payload.

not interested: <len=0001><id=3>

The not interested message is fixed-length and has no payload.

have: <len=0005><id=4><piece index>

The have message is fixed length. The payload is the zero-based index of a piece that has just been successfully downloaded and verified via the SHA1 hash.

Implementer’s Note: That is the strict definition, in reality some games may be played. In particular because peers are extremely unlikely to download pieces that they already have, a peer may choose not to advertise having a piece to a peer that already has that piece. At a minimum “HAVE suppression” will result in a 50% reduction in the number of HAVE messages, this translates to around a 25-35% reduction in protocol overhead. At the same time, it may be worthwhile to send a HAVE message to a peer that has that piece already since it will be useful in determining which piece is rare.

A malicious peer might also choose to advertise having pieces that it knows the peer will never download. Due to this attempting to model peers using this information is a bad idea.

bitfield: <len=0001+X><id=5><bitfield>

The bitfield message may only be sent immediately after the handshaking sequence is completed, and before any other messages are sent. The bitfield needs not be sent if a client has no pieces.

The bitfield message is variable length, where X is the length of the bitfield. The payload is a bitfield representing the pieces that have been successfully downloaded. The high bit in the first byte corresponds to piece index 0. Bits that are cleared indicated a missing piece, and set bits indicate a valid and available piece. Spare bits at the end are set to zero. A bitfield of the wrong length is considered an error. Clients should drop the connection if they receive bitfields that are not of the correct size, or if the bitfield has any of the spare bits set.

request: <len=0013><id=6><index><begin><length>

The request message is fixed length, and is used to request a block. The payload contains the following information:

• index: integer specifying the zero-based piece index
• begin: integer specifying the zero-based byte offset within the piece
• length: integer specifying the requested length.

piece: <len=0009+X><id=7><index><begin><block>

The piece message is variable length, where X is the length of the block. The payload contains the following information:

• index: integer specifying the zero-based piece index
• begin: integer specifying the zero-based byte offset within the piece
• block: block of data, which is a subset of the piece specified by index.

cancel: <len=0013><id=8><index><begin><length>

The cancel message is fixed length, and is used to cancel block requests. The payload is identical to that of the “request” message. It is typically used during “End Game” (see the Algorithms section below).

3.5 Algorithms

3.5.1 Piece downloading strategy

Download pieces in rarest first order. The client can determine this by keeping the initial bitfield from each peer, and updating it with every havemessage. Then, the client can download the pieces that appear least frequently in these peer bitfields. Note that any Rarest First strategy should include randomization among at least several of the least common pieces, as having many clients all attempting to jump on the same “least common” piece would be counter productive.

3.5.2 Choking and Optimistic Unchoking

The choke algorithm was introduced to guarantee a reasonable level of upload and download reciprocation. As a consequence, free riders, i.e., peers that never upload, should be penalized. For the sake of clarity, we describe without loss of generality the choke algorithm from the point of view of the local peer. In this section, interested always means interested in the local peer, and choked always means choked by the local peer.

The choke algorithm difers in leecher and seed states. We describe first the choke algorithm in leecher state. At most 4 remote peers can be unchoked and interested at the same time. Peers are unchoked using the following policy.

1. Every 10 seconds, the interested remote peers are ordered according to their download rate to the local peer and the 3 fastest peers are unchoked.
2. Every 30 seconds, one additional interested remote peer is unchoked at random. We call this random unchoke the optimistic unchoke.

In the following, we call the three peers unchoked in step 1 the regular unchoked (RU) peers, and the peer unchoked in step 2 the optimistic unchoked (OU) peer. The optimistic unchoke peer selection has two purposes. It allows to evaluate the download capacity of new peers in the peer set, and it allows to bootstrap new peers that do not have any piece to share by giving them their first piece.

In seed state, the choke algorithm is the same as that in leecher state except that in seed state the ordering performed in step 1 is based on upload rates from the local peer.

4. What you are supposed to implement

You’re probably overwhelmed by the above description. However, keep in mind that you can use existing codes for many important functionalities have been implemented already: the SHA1 hash, the bendecoder, the tracker, etc. I will simplify things further by requiring you to implement clients which support only one single .torrent file, given as an input to the program ubtorrent. It is not difficult to extend the implementation to support multiple torrents, and you are encourage to do so in your spare time after this course is over. In fact, run your implementation “in the wild” to see how it measures up to other professional ones. Your ubtorrent is supposed to implement all of the above requirements though. The sequence of tasks looks something like this:

• Download and compile the opentracker program. Run it.
• Create the .torrent file for SS.mp3 (or any reasonably sized file). We will test your program with files up to 20MB in size, but not more. When you implement ubtorrent, you probably should write pieces down to disk, don’t keep everything in memory.
• Create several directories, perhaps name them 1, 2, 3, 4, 5 and so on. Then put SS.mp3 in one of them. And, put a copy of ubtorrent in each of them. Thus, the copy of ubtorrent running inside directory 1 will be the original seeder. Other copies of ubtorrent can write temporary files inside that local directory. Clean up the temp files after the downloading is done, or if the user types quit
• ubtorrent takes two parameters: the first argument is the .torrent file name, and the second argument is the port number that other peers can connect to. For example,

  ubtorrent SS.mp3.torrent 6881

• Note that the tracker information is contained in the metainfo file. Upon starting, a client checks the local directory to see if the file is there already. (Check the file name and file size.) If the file is there, the client is running in the seeder state. Otherwise, it is running in the leecher state. The client then issues a GET request to the tracker rightaway. If the tracker is not running, the client reports an error and quit.
• At this point, if the seeder was already started, or if other peers have downloaded some pieces, the current client can start requesting blocks and start downloading. It should fully implement the rarest first and choke algorithms. If you run only 5 peers in total, choke algorithms should not take effect, and thus the peers download blocks/pieces from each other until they are completed. The rarest first algorithm should still be in place though. I personally would recommend writing a function which tells you which piece(s) to request, given the current list of pieces that the peers have. Initially, the function would just return any missing piece (i.e. without the rarest first algorithm). Once this works, you can change the function to return a random rarest piece.

What follows is the list of commands to be implemented: ubtorrent takes commands from users. I will be more precise on the output formats of these commands in the next few days.

4.1. metainfo

This command asks the client to show the information about the metainfo file. The output format looks something like this:

ubtorrent> metainfo
  my IP/port    : 127.0.1.1/9999
  my ID         : bcd914c766d969a772823815fdc2737b2c8384bf
  metainfo file : Dan Hill & Rique Franks - Sometimes When We Touch.mp3.torrent
  info hash     : 4a060f199e5dc28ff2c3294f34561e2da423bf0b
  file name     : Dan Hill & Rique Franks - Sometimes When We Touch.mp3
  piece length  : 262144
  file size     : 1007616 (3 * [piece length] + 221184)
  announce URL  : http://test/abc
  pieces' hashes:
    0  064b493d90b6811f22e0457aa7f50e9c70b84285
    1  d17cb90e50ca06a651a84f88fde0ecfb22a90cca
    2  20e82d045341032645ebe27eed38103329281175
    3  568c8a0599a7c1e2b3c70d8b8c960134653d497a

ubtorrent>

Everything is in the metainfo file or available locally (IP/port), except for the info hash value which you have to compute. (This has to be computed anyhow in order to send tracker requests.) The value of info hash is the SHA1 hash of the value of the info key in the metainfo dictionary.

Like in Project 1, your program should handle errors graciously. If the input .torrent file does not exist or if there were some errors in reading the file, for example, please do not crash. You can assume that the metainfo file (that we will test) is not greater than 8KB = 8192 bytes. If the given metainfo file is larger than that, you can quit the program and complain (to the screen). In the wild, metainfo files are often kept small, not more than 50KB.

Now, sometimes for debugging purposes you might want to display the metainfo file to the screen. However, as there are hash values in it, many characters cannot be displayed, causing the terminal to behave in unpredictable manner (e.g., change to Korean or Chinese fonts or something). To be safe, you should use hexdump to display a metainfo file:

hungngo@MYMACHINE:~/tmp$ hexdump test.torrent -c
0000000   d   8   :   a   n   n   o   u   n   c   e   1   5   :   h   t
0000010   t   p   :   /   /   t   e   s   t   /   a   b   c   1   3   :
...

I cut the rest of the output. You may find the functions strtol() helpful when trying to get the value of the info key out.

4.2. announce

This command asks the client to send a GET request to the tracker. When the response comes back, update the information to be used later. It also prints out the status line of the response (the first line which looks something like HTTP1.0 200 OK). The output may look like this:

ubtorrent> announce
++++ Tracker responded: HTTP/1.0 200 OK
 complete | downloaded | incomplete | interval | min interval |
---------------------------------------------------------------
 1        | 0          | 0          | 1686     | 843          |
---------------------------------------------------------------
++++ Peer List :
 IP               | Port
-------------------------------
 127.0.0.1        | 9999
   ... Tracker closed connection

(I suggest you store the dictionary in some be_node. Remember to be_free the node the next time an announce is called. The be_node is used in processing the command trackerinfo.)

4.3. trackerinfo

Prints the information contained in the latest tracker response. This is a subroutine which should have been called when announce is typed. So, the output is just part of the (last sucessful) announce output, without the status line:

ubtorrent>trackerinfo
 complete | downloaded | incomplete | interval | min interval |
---------------------------------------------------------------
 1        | 0          | 0          | 1686     | 843          |
---------------------------------------------------------------
++++ Peer List (self included):
 IP               | Port
-------------------------------
 127.0.0.1        | 9999
 127.0.0.1        | 9998
 127.0.0.1        | 9997

4.4. show

Prints the status of all current peer connections, including the choked/interested states and upload/download rates. The format looks something like this:

ubtorrent> show
ID | IP address | Status | Bitfield         | Down/s   | Up/s     |
--------------------------------------------------------------------
 0 | 127.0.0.1  | 0101   | 1111111111111111 | 0        |  59271
 1 | 127.0.0.1  | 0101   | 1111111111111111 | 0        |  59271

Down/s is the number of bytes downloaded per second on that connection. The status field has 4 bits, corresponding to the status of that connection: iam_choking (peer), iam_interested (in peer), peer_choking (me), peer_interested (in me).

4.5. status

Prints the status of the current  download: which pieces have been downloaded, which pieces are missing, the number of downloaded, uploaded, and remaining bytes. The format is something like this:

 ubtorrent> status
 Downloaded | Uploaded | Left | My bit field
------------------------------------------------
 1007616    | 0        | 0    | 1111111111111111

or

ubtorrent> status
 Downloaded | Uploaded | Left    | My bit field
---------------------------------------------------
 0          | 0        | 1007616 | 0000000000000000

Problem 1. In this question, we explore how potentially a P2P design is more efficient than a central sever design for file distribution. However, to make it juicier, we will explore this issue from a computer worm propagation context.

The Slammer worm was a very famous computer worm, very destructive, infected 75000 victims within 10 minutes in January of 2003. Each instance of the worm has size 404 bytes. We will simplify the problem for the worm writer a little. Let’s assume that once an infected computer A transmitted the worm (404 bytes) to computer B, computer B is infected and thus can propagate the worm further on its own. If you were a worm writer wanting to design an infection strategy for your worm, you’ll have to do some back-of-the-envelop computation similar to this problem.

Suppose the worm writer wants to infect 1 million home computers, each of which has an ADSL connection whose upload speed is 400Kbps and whose download speed is 1.4Mbps. This population of 1 million computers is called the vulnerable population. Also suppose that the propagation delay from any machine to another machine on the Internet is 50ms.

Consider the following two scenarios:

• Suppose initially a really fast server is infected. The server’s up-link (i.e. the link to send data to the Internet) is an OC12 link, whose speed is roughly 622 Mbps. Let the server infect each of the vulnerable hosts one by one. How long does it take until all vulnerable hosts are infected?
• Now, suppose initially a computer with an ADSL connection as above is infected. The worm writer decides to use a P2P-type of strategy for infection. The infection strategy can be visualized as a tree, whose root is the originally infected host. A parent node, upon infected, will infect each of its children one-by-one in some order. This tree has a million and one nodes. Let denote the minimum infection time of a tree with n nodes whose root is infected. We are interested in computing .

  – Write a recursive formula for computing .

  – What is , according to your recursive formula? (You may need to write a very short piece of code to compute this. If the code is recursive, it might never terminate. Think of a way [very simple] to write an iterative one, with a for loop.)

Problem 2. Repeat the above question with a 4 GB file instead of the 404 worm bytes.

Cuối cùng thì có vẻ như các tin tức về chủ quyền trên server đã được/bị hủy bỏ. Ví dụ như

http://211.88.5.96/cvweb/vcc/info/Article.jsp?a_no=180804&col_no=550

không còn chứa các tuyên bố chủ quyền này nọ nữa.

Chắc là domain name www.vietnamchina.gov.vn sẽ được hồi phục nay mai. Còn thiếu mỗi việc … quy trách nhiệm là đóng sổ vụ này.

Cập nhật 15 tháng 5:

Có vẻ như giải pháp bỏ DNS entry đã được thực hiện.

 > server vdc-hn01.vnn.vn
Default Server:  vdc-hn01.vnn.vn
Address:  203.162.0.11

> www.vietnamchina.gov.vn.
Server:  vdc-hn01.vnn.vn
Address:  203.162.0.11

*** vdc-hn01.vnn.vn can't find www.vietnamchina.gov.vn.: Non-existent host/domain

Nếu vào thẳng IP thì có vẻ như các công văn yêu cầu đội bạn bỏ tài liệu không có tác dụng:

http://211.88.5.96/cvweb/vcc/index.jsp

http://211.88.5.96/cvweb/vcc/info/Article.jsp?a_no=180804&col_no=550

Cũng đáng chú ý là một bình luận (số 113) của bác Trương Thái Du bên blog Osin:

Tôi tò mò vào trang web nói trên. Bất ngờ với cách dùng hai hình ảnh tượng trưng cho VN (khuê văn các) và TQ (thiên đàn). Chắc chắn người TQ đã chọn ảnh. Ý tưởng rất rõ ràng THIÊN TRIỀU và HỌC TRÒ. Chơi với TQ mà lơ tơ mơ về lịch sử và văn hóa thì hậu quả tự đồng hóa luôn nhãn tiền.

14 tháng 5
Bác Lê Tuấn Huy có công rất lớn với đất nước, phát hiên ra vụ “nằm vùng” của vietnamchina.gov.vn. Nhiều blogs khác cũng đã đăng lại tin này (Ô Sin, Linh, NVP, v.v.), cùng với một bài trên BBC Việt Ngữ.

Là dân kỹ thuật, có cái cần thử ngay:

[NQH] MFM:~$ nslookup
> set type=a
> www.vietnamchina.gov.vn
...
Non-authoritative answer:
Name:   www.vietnamchina.gov.vn
Address: 211.88.5.96
> set type=ns
> gov.vn.
Server:         24.92.226.40
Address:        24.92.226.40#53

Non-authoritative answer:
gov.vn  nameserver = d.dns-servers.vn.
gov.vn  nameserver = a.dns-servers.vn.
gov.vn  nameserver = f.dns-servers.vn.
...
> server d.dns-servers.vn
Default server: d.dns-servers.vn
Address: 203.119.44.105#53
> vietnamchina.gov.vn.
Server:         d.dns-servers.vn
Address:        203.119.44.105#53

Non-authoritative answer:
*** Can't find vietnamchina.gov.vn.: No answer

Authoritative answers can be found from:
vietnamchina.gov.vn     nameserver = hcm-server1.vnn.vn.
vietnamchina.gov.vn     nameserver = vdc-hn01.vnn.vn.

> set type=a
> server vdc-hn01.vnn.vn
Default server: vdc-hn01.vnn.vn
Address: 203.162.0.11#53
> www.vietnamchina.gov.vn.
Server:         vdc-hn01.vnn.vn
Address:        203.162.0.11#53

Name:   www.vietnamchina.gov.vn
Address: 211.88.5.96

Theo http://www.ip2location.com/free.asp thì 211.88.5.96 nằm ở Bắc Kinh. Như vậy là web server nằm ở Bắc Kinh, còn nameservers là của bọ (dĩ nhiên rồi! tên miền .vn mà).

Nếu chúng đã “muốn làm gì thì làm” với webserver thì bọ cũng phải được “muốn làm gì thì làm” với nameserver của bọ chứ: đừng trả lời DNS query cho www.vietnamchina.gov.vn là xong. Dĩ nhiên vấn đề phức tạp hơn như thế. Chẳng biết hai bên ký kết cái gì khi thành lập website này. Nhỡ khi ký rằng: “Iem bỏ entry vào name server, anh cung cấp nội dung website, chúng ta cân bằng cán cân thương mại nhé, … Nếu mà cắt hợp đồng này thì anh kiện iem” thì sao?

Do đó, bỏ cái entry này ra khỏi DNS RR, chỉ dễ dàng về mặt kỹ thuật mà thôi.

When Swedish authorities raided The Pirate Bay and its servers in 2006 — paving the way for ongoing criminal trial that ended Tuesday — the pirates were unbowed, quickly resurrecting the site and setting their reverse-DNS to read: “hey.mpaa.and.apb.bite.my.shiny.metal.ass.thepiratebay.org.”

“Even though no one spreads more culture than we do, it is the film and music-mob that are trying to close us down,” co-founder Fredrik Neij said, in a speech outside Swedish Parliament after the raid. “This time we’re firing with the big cannons and saying, ‘In your face, Hollywood!’”

But all that swagger evaporated like salt water on a beached schooner once The Pirate Bay landed on the witness stand in Stockholm, Sweden, where the three admitted founders — and a fourth man accused of financing them — face up to two years in prison each on allegations of facilitating copyright infringement. The trial wrapped up Tuesday, and a verdict is expected in April.

In the courtroom, the defendants quickly abandoned their revolutionary, free-culture ideals in favor of the simpler philosophy embraced by criminal defendants since time immemorial: I’m Not Responsible.

Một tin khác liên quan mật thiết: Obama picks Net neutrality backer as FCC chief