Sơ lược về các dạng DHT (Distributed Hash Table)

II. Kademlia

Kademlia là một hệ thống có tính lan truyền cao và độ trễ thấp, cùng những tính chất lí tưởng khác nên rất thông dụng. Kademlia được sử dụng trong giao thức BitTorrent, với các ứng dụnhg như OpenBitTorrent, uTorrent, Azureus, v.v.
Thay vì sử dụng phép trừ làm khoảng cách như Chord, Kademlia sử dụng phép XOR ⊕ có hai đặc tính ưu việt:

• Tính đối xứng: a ⊕ b = b ⊕ a. Hai node chỉ việc điền ID của nhau vào bảng, chứ không đi vòng vèo như Chord.
• BĐT tam giác: a ⊕ b + b ⊕ c >= a ⊕ c do a + b >= a ⊕ b.

Do nhu cầu thực tế, ngoài IP client còn phải lưu thêm port, nên cặp (ID, IP) trở thành (ID, IP:port). Kademlia sử dụng ID dài 160 bit, và mỗi client có một dãy bucket để lưu các cặp ID, mỗi bucket gồm tối đa k cặp như vậy. Nguyên tắc chọn ID của Kademlia là: ID càng kết nối lâu càng nhiều khả năng sống lâu, được phát biểu như sau:
Với x.alive(t) là biến cố node x sống tại thời điểm t >= 0s, thì P(x.alive(t + 3600s) | x.alive(t)) >= 1/2 và đơn điệu tăng theo t.

Đại diện cho mỗi bucket là một mặt nạ bit, sao cho các ID trong bucket đều khớp với mặt nạ bit đó, giống như 192 168 1 23 ứng với 192.168.1.0/24 vậy. Điều khác biệt là khi X có một bucket đã đủ túc số và tiếp nhận địa chỉ M phù hợp thì có hai trường hợp sẽ xảy ra:

• Nếu X thỏa mặt nạ bit thì bucket sẽ bị chia thành hai nửa: 0 và 1, đưa M vào bucket tương ứng.
• Ngược lại, nếu node cũ nhất (last-recently-used, LRU) bị timeout thì sẽ thêm M vào bucket và đá node cũ ra ngoài. Bằng không, X đưa M vào danh sách dự bị cho bucket và ghi nhận node cũ còn sống.
  Khi vẽ ra sẽ giống một cây nhị phân.

Dễ thấy rằng mỗi bucket thu hẹp khoảng cách hơn một nửa, nên số thông điệp truy vấn sẽ vào khoảng O(logn) với n là số client trong mạng. Ngoài ra, một client sẽ biết rõ những ID gần mình nhất hơn là những ID xa hơn, đây là đặc trưng của DHT, không chỉ của Kademlia.

Kadmlia quy định bốn câu lệnh cơ bản:

• PING: kiểm tra node có đang sống hay không.
• FIND_NODE + ID: lấy thông tin của ID, hoặc (tối đa) k node gần ID nhất.
• STORE + HIDPAIR: lưu (siêu) dữ liệu và HID của nó
• FIND_VALUE + HID: trả về (siêu) dữ liệu, hoặc (tối đa) k node gần ID nhất.

Trong truy vấn lặp, chỉ có máy khởi truy vấn hỏi và máy trung gian trả lời bằng ID trung gian tiếp theo, hoặc đích. Ngược lại, với truy vấn đệ quy, máy trung gian thứ k sẽ hỏi máy trung gian tiếp theo, nhận câu trả lời để trả lời lại cho máy trung gian thứ k-1.

Truy vấn lặp: X <-> 1, X <-> 2, X <-> 3, … , X -> goal
Truy vấn đệ quy: X -> 1, 1 -> 2, 2 -> 3, …, n -> n-1, n-1 -> n-2, …, 1 -> X, X -> goal.

Để tìm một ID, X chọn một bucket của mình gần với ID đó nhất và phát truy vấn ID đến α máy cùng lúc trong bucket đó (tham số a này được chọn cẩn thận và α << k). X tiếp nhận tất cả ID trả về vào bucket của mình. X duy trì α (thường là 3) truy vấn chưa trả lời. Nếu không thể tiến gần đến ID hơn nữa, X sẽ phát lookup tới những node còn lại trong kết quả trả về (tối đa α node cùng lúc) và thất bại sau nỗ lực cuối cùng này. Bạn đọc tinh ý sẽ thấy đây chính là quá trình “leo đồi”.

Để hòa mạng, client M xưng danh với client X, gửi FIND_NODE(M) cho X và thực hiện quá trình vừa nêu trên. Sau đó M thực hiện “Làm tươi” những bucket không thể có X trong đó.

Để phát hành (HID, value) X phát lệnh STORE cho bucket gần HID nhất. Một HID được lan truyền bằng cách: nếu một node Y phát hiện Z gần với HID hơn (xor nhỏ hơn) thì Y phát STORE cho Z. Đồng thời, trong quá trình tìm kiếm, ID gần nhất mà không trả lời được sẽ nhận STORE từ ID yêu cầu, nếu tìm được để giảm số yêu cầu trong mạng. Ở đây có hai loại client:

• Client loại 1 lưu trữ HID phải phát lệnh STORE sau mỗi khoảng thời gian nhất định.
• Client loại 2 chỉ cache tạm HID, sau một khoảng thời gian tùy vào khoảng cách với HID sẽ loại bỏ nó khỏi bộ nhớ, bao gồm tất cả client tiếp nhận STORE ban đầu.

Để duy trì mạng, client tiến hành “làm tươi” các bucket với những bucket đã nguội lạnh bằng cách thực hiện một truy vấn FIND_NODE với một ID ngẫu nhiên ứng với mỗi bucket đó.

Trình bày xong phần Kademlia.

Nói thêm: Dùng truy vấn đệ quy thì các node tham gia sẽ phải duy trì kết nối trong khoảng thời gian dài, và còn dễ bị lợi dụng (amplification) nữa. Nhưng dùng truy vấn lặp thì không phải máy nào cũng liên lạc trực tiếp được.
Với các mạng lưu metadata, có thể cân nhắc cho client loại 2 (ứng với HID cụ thể, không phải role đặc biệt) cũng có thể kích hoạt STORE (phát tán) nhưng vẫn bị hết hạn. Loại 3 (cache) mới không phát tán và chỉ lưu trữ trong thời gian ngắn.
Ngoài ra, các node phải ưu tiên cho những range IP gần mình hơn để tránh bị ISP tuýt còi. Tapestry và Pastry bổ sung bảng neighbor vào để phần nào giải quyết vấn đề này.

III. Tapestry

Tapestry và Pastry là hai DHT thuộc họ Plaxton. Mỗi node trong Tapestry có một ma trận định tuyến (gọi tắt là “ma trận”) Mx gồm m dòng [0…m-1] và 2^w cột đánh số [0…2^w - 1].

• Dòng thứ i có chung ít nhất w*i bit đầu với ID của node.
• Ô Mx[i][j] có bit thứ w*i+1 là j.
• Mỗi ô gồm 1 node chính và 2 node dự bị, node có ping thấp nhất làm node chính.

VD: Trong ma trận của node 687, ID 631 sẽ nằm ở dòng 1, cột 3; 682 là dòng 2 cột 2; 793 là dòng 0 cột 7.

Để tìm một node, client so sánh ID với ID đang tìm để tìm cột cho đúng. Nếu ô đó không có ID nào thì dùng những ô lân cận.
VD: lookup(4807): 3622 -> 4931 -> 4824 -> 4806, dòng 3 hết.

Để phát hành một HID, client X xác định node nào có ID “liền sau” (không giống Chord & Pastry, 2999 và 3000 thuộc về hai mạch khác nhau) HID sẽ trở thành root R (hay surrogate) của HID này. Nguyên tắc là 1 HID chỉ được có 1 surrogate, nhưng nhiều client có thể phát hành một HID. Các client trung gian lưu cặp (HID, X) cho đến R thì dừng lại. Để tìm một HID, client phát lệnh tìm kiếm HID cho đến khi gặp một client có cặp (HID, X). Do mỗi ô trong bảng định tuyến có ping thấp nhất cục bộ, nên client tìm được cũng có ping nhỏ nhất.
Các client lưu dữ liệu phải định kì “làm tươi” HID đang giữ, để đảm bảo root không mất.

Để hòa mạng:

• Client M liên lạc với client X trong mạng,
• X so sánh M với ID X của mình xem M sẽ rơi vào dòng thứ mấy [i]. X trả về dòng tương ứng kèm những dòng phía trên [0…i], và báo cho những node ở những dòng sau [i+1…n-1] để thêm M vào ma trận.
• Trên đường tìm ID M, node nào tiếp nhận sẽ trả về dòng ứng với M, đồng thời tranh thủ điền M vào ma trận định tuyến của mình.
• Sau cùng, M tìm một node có ID gần nó nhất có thể và yêu cầu nhượng root HID nếu có. Đây là một cách nữa để lan truyền HID. Khi nhượng root thành công, root cũ M’ sẽ trở thành cache và M là root. M’ thông báo cho tất cả ID trong ma trận của mình node M này.

VD: Node 168 chọn node 840 làm bootstrap

Q168: join 168 -> A840: id {273 439 504 667 301 194}
Q168: lookup 168 -> A301: id {184 124}, A667: id {100}
Q168: rank 168 -> A184: id {131 175 154 109 124} A194: {154 109 116 100}
Q168: lookup 168 -> A175: id {167 164}, A116: id {}
Q168: rank 168 -> A167: id {160 164}, A164: id {160 167}.
Q168: knock 168 -> A167: hid {163 839} {163 031} hoặc hid {}
Q168: lookup 163 … (166 không tồn tại)
Q168: reg 166 -> A839: OK A031: OK
Ma trận 168:
031 194 273 301 439 504 667 --- 839 --- 109 116 124 131 --- 154 --- 175 184 194 160 --- --- --- 164 --- --- 167 168 ---

Khi rời mạng, client gửi m ID (bằng 5 là ổn) từ những dòng thấp nhất để gửi cho tất cả ID ở phía trên dòng đó. Sau đó, nếu client đang là root thì client chọn một ID gần HID nhất trong bảng, yêu cầu tiếp nhận các HID mình đang giữ. Client đáp lại thực hiện như những bước trên.

Để ổn định mạng:

• Khi thực hiện bất cứ lệnh nào, nếu gặp một node bị timeout, thì client đặt 1 cooldown ngắn để kết nối lại một lần nữa (second wind). Trong khi đó, client đọc ô tiếp theo có ID.
• Nếu một ô đang còn cooldown thì sử dụng node dự bị, khi nào node dự bị timeout thì mới đọc ô tiếp theo.
• Client định kì “làm tươi” các ô trống và bỏ qua những ô có ID, trừ những ô có cooldown hết hạn sẽ được ping một lần nữa. Nếu tiếp tục timeout thì xóa và “làm tươi” sao cho đủ túc số.

IV. Pastry

Ngoài ma trận định tuyến đã trình bày ở phần III, mỗi client Pastry còn lưu trữ thêm u node “hàng xóm” (leaf set) ở hai bên ID của mình (giống Chord: khoảng cách tính bằng phép trừ), kèm theo u’ node có ping thấp (neighborhood set). Thường chọn u bằng w hoặc 2w và u’ bằng 8w hoặc 16w.

Tìm node: Pastry sử dụng truy vấn đệ quy, nếu ID cần tìm rơi vào u node trong leaf set thì có thể kết luận ngay; ngược lại, nếu ID ứng với ô trống trong ma trận thì (hiếm) sẽ chọn 1 node trong neighborhood set càng gần ID càng tốt.
Sau đó, nếu ô ứng với ID cần tìm bị timeout thì việc sửa chữa sẽ tiến hành qua việc lookup qua ô tiếp theo.

Hòa mạng: Để client M hòa mạng, M chọn một bootstrap node X gần mình nhất và phát một yêu cầu đặc biệt, có ID của M.

1. M tiếp nhận neighborhood set của X, vì X cũng gần M.
2. Mỗi node từ sau đầu X tới cuối M’ (gần M nhất) trao ma trận, leaf set và neighborhood set cho X. [spoiler]Thực ra chỉ cần ma trận và leaf set thì có thể xem là tạm đủ.[/spoiler]
3. M’ tiếp nhận leaf set của M.
4. Sau khi tối ưu dựa trên những thông tin thu được, M hồi đáp cho tất cả các node từ sau X tới M’ cả ma trận, leaf set và n. set. M đã hòa mạng thành công.
5. M phát “hello” cho tất cả các node trong leaf set và n.set của mình.

Duy trì:

• Sau mỗi khoảng thời gian d, M kiểm tra leaf set của mình. Những node bị timeout sẽ bị thay bằng cách gửi yêu cầu leaf set tới node xa nhất (khoảng cách lớn nhất) trong leaf set.
• Các ô trong ma trận sẽ được thay thế sau mỗi khoảng thời gian d’ > d bằng một node trong neighborhood set để giảm ping.
• Cũng sau mỗi khoảng thời gian d’, M kiểm tra lại neighborhood set của mình. Những node bị timeout sẽ bị thay bằng cách gửi yêu cầu đến node được chọn ngẫu nhiên trong neighborhood set.

Đó là phần lõi của Pastry. Phần lưu file được hiện thực bằng một “app” của Pastry gọi là PAST. Ý niệm là một HID được lưu trữ (không chỉ là quản lí như Tapestry) bởi một “surrogate” và toàn bộ leaf set của nó. Điều này làm cho ping thấp hơn, do ID rải đều khắp các vùng địa lí.

Hết phần III và IV.

Ngoài tính bất đối xứng, do khoảng cách giữa các ID không phân bố đều, một số node Chord phải lưu rất nhiều HID vì có khoảng cách với pred lớn hơn bình thường. Kademlia thông dụng hơn hẳn, với phần định tuyến đơn giản, cách chọn kết nối linh động và khoảng cách có tính đối xứng.

Để hiện thực hóa một mạng P2P, ngoài DHT còn có thể dùng hình thức gossip: các node liên lạc và trao đổi liên kết một cách ngẫu nhiên với nhau; thông qua việc tối ưu cục bộ, dữ liệu sẽ tập trung ở các node có băng thông lớn và sống lâu: Việc tạo node và hòa mạng dễ dàng mở ra khả năng tạo ra thật nhiều client phá hoại trong mạng. Những mạng có dùng DHT phải đối mặt với kiểu tấn công đặc trưng: để cô lập một node S, chỉ cần đánh sập S để tất cả kết nối từ S đều bị timeout, sau đó tạo nhiều ID (có thể cùng trên một máy vật lí) gần với S và kết nối với S. Với số node tạo ra lên đến hàng nghìn, node S bị cô lập hoàn toàn. Điều này cực kì nguy hiểm với những ứng dụng tài chính.

Ngoài ra, cấu trúc DHT làm cho việc phục hồi kết nối trong tình huống chia cắt và cô lập bị hạn chế rất nhiều, và tình trạng đó vẫn kéo dài sau khi kết nối tầng thấp hơn được tái lập. DHT có khả năng tìm kiếm nhanh và chọn lọc, nhưng gossip có thể tìm theo từ khóa, thay vì phải tag vào hash. Như vậy, nghiên cứu kết hợp gossip trên nền DHT là hướng thật sự có tiềm năng và lí thú. (Chấm hết)

Tài liệu tham khảo

Antony Rowstron, Peter Druschel, Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems, 2001.
Ben Y. Zhao, Ling Huang, et al. Tapestry: A Resilient Global-Scale Overlay for Service Deployment, IEEE Journal on Selected Areas in Communications, Vol. 22(1), 2004.
Eng Keong Lua, Jon Crowcroft, et al. A Survey and Comparison of Peer-to-Peer Overlay Network Schemes, IEEE Communication Surveys and Tutorial, Vol. 7(2), 2005.
Heiko Niedermayer, Simon Rieche, et al., On the Distribution of Nodes in Distributed Hash Tables, 2005.
Ion Stoica, Robert Morris, David Karger, et al., Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, 2001.
Marin Bertier, François Bonnet, et al., D2HT: the best of both worlds, Integrating RPS and DHT. European Dependable Computing Conference, 2010.
Petar Maymounkov, David Mazières, Kademlia: A Peer-to-peer Information System Based on the XOR Metric, 2002.
Yuval Marcus, Ethan Heilman, Sharon Goldberg, Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network, 2018.