Giới thiệu tổng quan về ngạng ngang hàng và mạng ngang hàng có cấu trúc Chord. Nghiên cứu một số phương pháp tối ưu hóa Topology mạng ngang hàng có cấu trúc Chord. Mô phỏng và đánh giá các giải pháp. Đưa ra kết luận, những vấn đề nảy sinh và hướng nghiên cứu tiếp theo.
Trang 1Đánh giá các giải pháp tối ưu hóa topology cho
mạng ngang hàng có cấu trúc
Đỗ Phương Dung
Trường Đại học Quốc gia Hà Nội; Trường Đại học Công nghệ Chuyên ngành: Truyền dữ liệu và mạng máy tính; Mã số: 60 48 15
Cán bộ hướng dẫn khoa học: PGS.TS Hồ Sĩ Đàm
Năm bảo vệ: 2012
Abstract Giới thiệu tổng quan về ngạng ngang hàng và mạng ngang hàng có cấu trúc
Chord Nghiên cứu một số phương pháp tối ưu hóa Topology mạng ngang hàng có cấu trúc Chord Mô phỏng và đánh giá các giải pháp Đưa ra kết luận, những vấn đề nảy sinh và hướng nghiên cứu tiếp theo
Keywords: Truyền dữ liệu; Mạng truyền thông; Mạng hàng ngang; Cấu trúc
Content
Chương 1: Mạng ngang hàng
Mạng ngang hàng có cấu trúc sử dụng hệ thống DHT(Distributed Hash Table - Bảng băm phân tán) Hệ thống này định nghĩa liên kết giữa các nút mạng trong mạng phủ theo một thuật toán cụ thể, xác định chặt chẽ mỗi nút mạng sẽ chịu trách nhiệm đối với một phần dữ liệu chia sẻ trong mạng Dựa trên cấu trúc bảng băm phân tán đã có nhiều nghiên cứu và đề xuất ra các mô hình mạng ngang hàng có cấu trúc ví dụ như : Chord, Pastry, CAN,…
Chord được mô tả dưới dạng một vòng tròn và không gian định danh phân bố đều trên một vòng tròn tăng dần hướng theo chiều kim đồng hồ Trong một không gian định danh m bit sẽ có 2 mũ
m định danh Mỗi nút trên Chord có một định danh id và có khả năng duy trì liên kết 2 chiều với các
nút đứng liền trước và liền sau nó theo chiều kim đồng hồ, tạo thành 1 mạch kiên kết vòng Nút liền
trước được gọi là Successor(id), và nút liền sau được gọi là Predecessor(id) Thêm vào đó, mỗi nút sẽ
lưu một bảng thông tin định tuyến gọi là Finger Table, cho phép nút đó định tuyến tới các nút ở xa Mỗi dòng trong bảng Finger Table sẽ lưu thông tin về 1 nút ở xa, gọi là 1 entry Không gian định danh có bao nhiêu bit thì Finger Table có bấy nhiêu entry
Tuy nhiên, ngoài ưu điểm tìm kiếm dữ liệu nhanh và cân bằng tải giữa các nút, nó còn bộc lộ một số nhược điểm để khắc phục điều đó tập trung vào 2 vấn đề chính: sự khác biệt về topo và tối
ưu bảng định tuyến
Trang 2Sự khác biệt về topo: hai nút ở rất gần nhau về topo vật lý nhưng lại có thể xa nhau trên mạng chord và ngược lại Trong ngang hàng Chord, truy vấn ngắn thường có tần suất lớn hơn các truy vấn dài do cơ chế ưu tiên trong quá trình tìm kiếm
Khi xây dựng bảng định tuyến nút được chọn chỉ phụ thuộc vào topo hiện tại của mạng Chord
Sự thiếu mềm dẻo khi xây dựng bảng định tuyến làm cho độ trễ truy vấn lớn, chi phí truyền thông cao
Chương 2 - Một số phương pháp tối ưu hóa Topology trên mạng ngang hàng
có cấu trúc Chord
Đã có nhiều nghiên cứu nhằm cải tiến và tối ưu hiệu năng của Chord: Lựa chọn láng giềng
gần và giải thuật Vivaldi
2.1 Lựa chọn láng giềng gần:
2.1.1 Xây dựng không gian tọa độ 2 chiều
Mỗi nút trong mạng sẽ có một tọa độ tương ứng trong không gian tọa độ 2 chiều C và không gian tọa độ 2 chiều này sẽ được chia đều thành các vùng bằng cách sử dụng các vòng tròn đồng tâm Sau đó, mỗi vùng lại được chia nhỏ thành các miền có diện tích bằng nhau (tối đa có 2i-1 miền) Các vùng trên ri được ký hiệu là di,j, với di,j là vùng thứ j trong ri bắt đầu từ mốc 0 độ theo hướng ngược chiều kim đồng
2.1.2 Tối ưu bảng định tuyến
Trong bảng định tuyến Chord, entry của Finger thứ i cần được điền bằng nút có định danh sau , k là định danh nút Áp dụng cho chiến lược xây dựng bảng định tuyến một cách linh hoạt với các nút có độ trễ thấp hơn mà định danh của chúng nằm trong khoảng gần nút đang xét nhất
2.1.3 Nhận xét
Việc phân hoạch để tạo ra không gian tọa độ 2 chiều giúp các nút mạng có được tọa độ của mình và có thể dự đoán được RTT mà không cần thực hiện việc thăm dò trên toàn mạng
Dựa vào toạ độ 2 chiều của mạng ảo, các nút gần nhau sẽ được nhóm vào trong cùng một miền và miền kế nhau sau khi ánh xạ từ không gian toạ độ của mạng sang không gian định danh của DHT, chính vì vậy mà quan hệ gần gũi của các nút mạng trong hệ thống sẽ không bị thay đổi
Nhờ vào việc tìm kiếm trên vùng id tương ứng bằng RPC trong Chord, các nút sẽ tìm được láng giềng gần một cách nhanh chóng trong vùng phân tán đó Từ đó giảm được độ trễ tìm kiếm trên mạng
2.2 Giải thuật Vivaldi
Vivaldi là một thuật toán giúp các nút trong mạng có thể tự dự đoán RTT Đây là một thuật toán phân tán không yêu cầu hạ tầng mạng và không phụ thuộc vào các nút
2.2.1 Không gian tọa độ
Trang 3- Xây dựng không gian tọa độ thỏa mãn: khoảng cách trực tiếp giữa hai nút A và C phải nhỏ hơn hoặc bằng với khoảng cách dọc theo đường đi từ A đến B và B đến C
- Sử dụng tọa độ 2-chiều với các hàm khoảng cách Euclide chuẩn
2.2.2 Giải thuật:
Việc xây dựng thuật toán Vivaldi dựa trên việc mô phỏng hệ thống lò xo
Giả sử đặt một lò xo giữa 2 cặp nút (i,j), độ dài của lò xo là Lij
Fij là vector lực của lò xo giữa các nút i và j mà nó tác dụng trên nút i Theo định luật Hooke:
là khoảng cách dịch chuyển
Vector đơn vị u (xi-xj) cho biết hướng của lực tại i
Tính cường độ lực của các vector lực lò xo tác động lên nút i trong toàn mạng:
Điều chỉnh lại tọa độ của i theo hướng của lực:
Khó khăn chính trong việc thực hiện Vivaldi là đảm bảo rằng nó hội tụ đến tọa độ mà dự đoán được RTT tốt Để giải quyết điều này, Vivaldi sẽ điều chình tỷ lệ hội tụ bằng bước nhảy δ: giá trị δ lớn thì Vivaldi dùng để điều chỉnh tọa độ trong bước nhảy lớn Giá trị δ có thể được tính bằng:
hoặc
2.2.3 Tối ưu Chord dựa vào giải thuật Vivaldi
Trước hết, các nút trong hệ thống sẽ tự cập nhật tọa độ của mình đến tọa độ mới theo thuật toán Vivaldi sao cho việc dự đoán RTT chính xác nhất
Một nút A sẽ duy trì một danh sách các nút ứng cử viên của nó Việc lựa chọn Successor của nút A sẽ thực hiện đo khoảng cách tứ nó đến các nút ứng viên để tìm ra nút có RTT ngắn nhất Và nút đó sẽ được chọn làm Successor của A Khi có một nút mới tham gia vào hệ thống, thuật toán Vivaldi sẽ được thực hiện để các nút lại tự cập nhật tọa độ của mình
Ngoài ra cần thay đổi Chord để có thể sử dụng Vivaldi đó là: Bất cứ khi nào một nút gửi RPC yêu cầu hoặc trả lời nút khác, nó sẽ gửi tọa độ của nó vào trong RPC đó Dựa vào thông tin có trong RPC, Vivaldi sẽ tính độ trễ tới các nút khác Cũng nhờ vậy, Vivaldi có thể thu thập thông tin mà không làm tăng chi phí của mạng Ngoài ra, bất cứ khi nào các nút trao đổi thông tin định tuyến, chúng sẽ gửi thêm tọa độ cũng như địa chỉ IP của chúng Do đó Chord luôn luôn biết tọa độ của nút
mà không phải “nói chuyện” với nút đó trước
(2.
4)
(2.5)
( 2.6)
( 2.8) ( 2.9)
Trang 42.2.4 Nhận xét:
- Vivaldi là thuật toán phân tán vì mỗi một thủ tục Vivaldi giống nhau sẽ được thực hiện trên mỗi nút Và nó sẽ được thực hiện lại khi có một nút mới tham gia vào mạng
- Tính hiệu quả của thuật toán: Mỗi nút cung cấp thông tin để một nút khác cập nhật tọa độ của nó
Do vậy, khi có những thay đổi cấu trúc topology thì các nút sẽ cập nhật tọa độ của chúng một cách tự nhiên và phù hợp
- Vivaldi đã giúp Chord cải tiến được hiệu năng của mạng, tối ưu trong quả trình tìm kiếm lặp
3 Mô phỏng
3.1 Mục đích:
- Đánh giá tính hiệu quả của các giải pháp cũng như đánh giá được những cải tiến về hiệu năng của các giải pháp tối ưu trên mạng Chord thông các độ đo như: Độ trễ tìm kiếm, băng thông sử dụng, tỉ lệ tìm kiếm thành công
- Từ đó chọn lựa các giải pháp phù hợp để xây dựng các ứng dụng dựa trên mạng Chord
3.2 Các vấn đề cần giải quyết:
Xây dựng topo và kịch bản mô phỏng nhằm giải quyết các vấn đề sau:
+ Đánh giá ảnh hưởng của kích thước mạng tới độ trễ tìm kiếm và băng thông sử dụng của các nút cũng như tỉ lệ tìm kiếm thành công ứng với từng giao thức
+ Đánh giá ảnh hưởng của topo mạng tới độ trễ tìm kiếm ứng với từng giao thức
3.3 Thực nghiệm mô phỏng
3.3.1 Thực nghiệm 1: Mô phỏng Chord, ChordPNS và Vivaldi
Cấu hình mô phỏng:
- Kích thước mạng lần lượt là 128, 256, 512, 1024 nút
- Ma trận độ trễ tương ứng với từng kích thước mạng được xây dựng từ tập dữ liệu King Độ trễ trung bình giữa các nút là 159ms
- Giao thức mô phỏng lần lượt là Chord, láng giềng gần và Vivaldi
- Thời gian sinh thông báo là 10ms
- Một số tham số mô phỏng cho từng giao thức:
Chord: Tập hàng xóm bao gồm 16 nút (neighbors=16);
Láng giềng gần: Tập successors là 16 (successors =16); số lần lấy mẫu tối đa là 10 (Samples = 10)
Vivaldi: Không sử dụng vector chiều cao( using-height-vectors=0), sử dụng không gian 2 chiều ( model-dimension=2); Tập hàng xóm là 16 (neighbors=16)
Kết quả mô phỏng:
- Băng thông sử dụng: là tổng số byte gửi đi bởi tất cả các nút (bao gồm cả dữ liệu điều khiển) chia
cho khoảng thời gian trung bình mà các nút tồn tại trong hệ thống Sau khi thực hiện mô phỏng ta có
đồ thị như sau:
Trang 5Băng thông sử dụng
0 10 20 30 40 50 60 70 80
Số node
Chord PNS Vivaldi
Hình 3.2: Băng thông sử dụng Dựa vào đồ thị hình 3.2 với kích thước mạng tăng lên thì băng thông sử dụng của Chord và ChordPNS cũng tăng lên Tuy nhiên khi kích thước mạng tăng lên thì tỉ lệ tăng đó cũng không nhiều Dựa vào đồ thị thì chúng ta cũng thấy rằng băng thông sử dụng của Chord cao gấp 2 lần so với lựa chọn láng giềng gần So với lựa chọn láng giềng gần, thuật toán Vivaldi sử dụng băng thông mạng gần như tương đương Nguyên nhân đó là do khi thực hiện Vivaldi, thông tin các nút được trao đổi trên mạng được gửi đi trong các message của RPC chính vì vậy nó sẽ không làm tăng chi phí của mạng
- Độ trễ tìm kiếm trung bình: Là thời gian trung bình mà các nút sử dụng trong các tìm kiếm thành
công
Độ trễ tìm kiếm trung bình
0 50 100 150 200 250 300 350 400 450 500
Số node
Chord Chord PNS Vivaldi
Hình 3.3: Đồ thị về độ trễ tìm kiếm trung bình Dựa vào đồ thị hình 3.3 chúng ta thấy rằng với số nút trong mạng tăng gấp đôi thì độ trễ tìm kiếm trung bình của chord, chordPNS và Vivaldi cũng tăng lên Tuy nhiên đối với Chord, độ trễ tìm kiếm tăng 1.5 lần khi kích thước mạng tăng gấp đôi trong khi đó với ChordPNS và Vivaldi, độ trễ tìm kiếm chỉ tăng tuyến tính Ngoài ra, so với Chord, ChordPNS, Vivaldi có độ trễ thấp hơn ứng với cùng số nút như nhau Nguyên nhân chính của kết quả này là do việc tối ưu trong quá trình chọn successor của ChordPNS và Vivaldi Việc chọn nút làm successor có khoảng cách ngắn nhất trong danh sách các nút ứng viên làm láng giềng gần đã làm giảm đáng kể độ trễ tìm kiếm Đối với lựa chọn láng giềng gần việc ánh xạ các nút vào các miền đã cải thiện đáng kể việc lưu thông tin trong bảng định tuyến và rút ngắn thời gian định tuyến Mỗi nút lưu lại định danh của miền mà nó thuộc về
Trang 6miền đó Quá trình tìm kiếm sẽ được thực hiện trên 6 miền lan cận và việc chọn định danh nút hàng xóm sẽ nằm trong khoảng [k+2i-1
, k+2i), với k là định danh nút hiện tại
Tuy băng thông sử dụng mạng là tương đương nhau so với lựa chọn láng giềng gần (trong đồ thị hình 3.2) nhưng Vivaldi đã cải thiện đáng kể độ trễ tìm kiếm trung bình của mạng Dựa vào đồ thị hình 3.3 có thể thấy rằng độ trễ tìm kiếm trung bình của mạng đã giảm hơn ½ lần Có được kết quả như vậy là do Vivaldi thực hiện cập nhật lại tọa độ từ đó tối ưu được độ trễ dự đoán
- Sai số tương đối của lỗi dự đoán: giá trị này được tính theo công thức
Sai số tương đối = abs(measured-predicted) / min (measured; predicted)
Đây là đại lượng chỉ ra sự sai khác giữa độ trễ dự đoán và khoảng cách giữa cặp nút trong hệ thống
Sai số tương đối
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35
128 256 512 1024
Số node
Vivaldi
Hình 3.4: Đồ thị về sai số tương đối của Vivaldi Với kích thước mạng tăng lên, đồ thị hình 3.4 cho thấy sai số tương đối giảm dần Điều này cho thấy rằng với kích thước mạng càng lớn khả năng hội tụ của các nút về những vị trị mới lý tưởng càng cao Như vậy khả năng dự đoán RTT của các nút càng chính xác
- Tỉ lệ tìm kiếm không thành công: là tỉ số giữa số lần tìm kiếm không thành công chia cho tổng số
lần tìm kiếm Ta có kết quả như sau:
Tỉ lệ tìm kiếm không thành công
0 0.2 0.4 0.6 0.8 1 1.2 1.4
Số node
ChordPNS Vivaldi
Hình 3.5: Đồ thị so sánh tỉ lệ tìm kiếm không thành công
Trang 7Đồ thị hình 3.5 cho ta thấy rằng, tỉ lệ tìm kiếm không thành công của Chord, ChordPNS và Vivaldi khá thấp (chưa đến 1.5%) Điều này cho thấy việc tìm kiềm của cả ba giải pháp khá hiệu quả Ngoài ra chúng ta còn thấy rằng ChordPNS (tương đương Vivaldi) có tỉ lệ tìm kiếm thành công cao hơn Chord và khi kích thước mạng tăng lên thì tỉ lệ tìm kiếm thành công cũng tăng theo Có được điều này là do khi kích thước mạng tăng lên thì xác suất tìm kiếm của các giải pháp tối ưu cũng tăng theo
3.3.2 Thực nghiệm 2: Tăng khoảng cách giữa các nút trong mạng cùng kích thước
Cấu hình mô phỏng:
- Kích thước mạng 1024 nút
- Ma trận độ trễ được xây đựng lại dựa trên ma trận trong thực nghiệm 1, thay đổi khoảng cách giữa từng cặp nút bằng cách gia tăng độ trễ giữa chúng lần lượt là 10, 20, 40, 80 (giây)
- Các tham số còn lại giống với thực nghiệm 1
Kết quả mô phỏng như sau:
- Độ trễ tìm kiếm trung bình
0 100 200 300 400 500 600 700 800 900 1000
Khoảng cách tăng (s)
Chord ChordPNS Vivaldi
Hình 3.6: Độ trễ tìm kiếm trung bình của mạng 1024 nút
Dựa vào hình 3.6 với kích thước mạng 1024 nút, khi tăng khoảng cách từng cặp nút thì độ trễ tìm kiếm trung bình của Chord và ChordPNS tương ứng cũng tăng lên Tuy nhiên đối với Vivaldi việc tăng là không đáng kể Điều này cho thấy rằng độ trễ tìm kiếm trung bình của Chord và ChordPNS phụ thuộc vào khoảng cách giữa các nút Vì vậy việc xây dựng được mạng phủ phù hợp
sẽ giàm được khá nhiều chi phí tìm kiếm
3.3.3 Thực nghiệm 3: Tăng khoảng cách trong các mạng có kích thước khác nhau
Cấu hình mô phỏng:
- Kích thước mạng sử dụng lần lượt là 128, 256, 512, 1024
- Ứng với mỗi kích thước mạng, lần lượt tăng khoảng cách giữa từng cặp nút lên 1.5 và 2 lần
- Các điều kiện mô phỏng giống ở thực nghiệm 1
Kết quả mô phỏng như sau:
- Độ trễ tìm kiếm trung bình:
Trang 8Độ trễ tìm kiếm trung bình
0 100 200 300 400 500 600 700 800 900
Số node
Chord, a=1 Chord, a=1.5 Chord, a=2 ChordPNS, a=1 ChordPNS, a=1.5 ChordPNS, a=2 Vivaldi, a=1 Vivaldi, a=1.5 Vivaldi, a=2
Hình 3.7: Độ trễ tìm kiếm trung bình khi tăng khoảng cách theo hệ số
Đồ thị hình 3.7 cho thấy rằng khi hệ số a=1.5 và a=2 (tăng khoảng cách 1.5 và 2 lần), tương ứng với từng kích thước mạng độ trễ tìm kiếm trung bình tăng nhanh ứng với Chord và ChordPNS Đối với Vivalđi, độ trễ tìm kiếm tăng không đáng kể
Nhận xét: Trong thực nghiệm mô phỏng 2 và 3, khi tăng khoảng cách giữa các nút nhìn chung Chord và ChordPNS có độ trễ tìm kiếm tăng nhanh Tuy nhiên với Vivaldi giá trị này lại không tăng Sự khác biệt này là do Vivaldi thực hiện cập nhật lại tọa độ của các nút về tọa độ mong muốn, giảm thiểu độ trễ tìm kiếm
KẾT LUẬN
Tất cả các hệ thống P2P được xây dựng dựa trên tầng ứng dụng, các liên kết trên đó là độc lập với mạng vật lý bên dưới Trong mạng ngang hàng không có cấu trúc, một nút mới sẽ chọn ngẫu nhiên một số các nút hiện có của các hệ thống để làm các láng giềng của nó, trong khi ở mạng ngang hàng có cấu trúc, một nút mới sẽ nhận được một giá trị nhất định được xác định bởi hàm băm và xây dựng kết nối với các nút khác dựa trên các quy tắc cụ thể của DHT Kết quả là, mối quan hệ giữa hai nút trên mạng phủ sẽ không phản ánh được sự gần gũi trong mạng vật lý Chính vấn đề này là một trở ngại lớn trong việc xây dựng mạng có quy mô lớn hiệu quả Chính vì vậy, việc nghiên cứu tối ưu hóa topology trên mạng ngang hàng là vấn đề quan trọng để xây dựng các mạng ngang hàng
Luận văn đã tập trung trình bày về mạng ngang hàng có cấu trúc Chord và những giải pháp tối ưu hóa topology trên mạng ngang hàng có cấu trúc Những kết quả nghiên cứu trong luận văn đã cho thấy rằng, các giải pháp tối ưu topology trên mạng Chord đã khắc phục được những nhược điểm của mạng Chord truyền thống, giảm thiểu được sự sai khác về topo giữa mạng vật lý và mạng phủ
HƯỚNG NGHIÊN CỨU TIẾP THEO
Trên cơ sở đã đạt được, trong thời gian tới chúng tôi dự kiến sẽ nghiên cứu những vấn đề sau:
- Tối ưu topology trên mạng có cấu trúc khác như Pastry, Kademlia, Tapestry dựa vào giải thuật Vivaldi
- Đánh giá các phương pháp lựa chọn láng giềng trên mạng ngang hàng có cấu trúc: Lựa chọn láng giềng gần, lựa chọn định danh gần (Proximity Identifier Selection)
Trang 9- Các đề xuất xử lý vấn đề sai khác topology trên mạng ngang hàng khác: F-Chord, Giao thức tối ưu định tuyến thông qua trao đổi Peer (Peer-exchange Routing Optimization Protocols - PROP)
References
Tiếng Việt
1 PGS.TS Nguyễn Đình Việt (2009), bài giảng “Đánh giá hiệu năng mạng máy tính”,
Tiếng Anh
3 Frank Dabek, Russ Cox, Frans Kaashoek, and Robert Morris “Vivaldi: A
Decentralized Network Coordinate System.” In the Proceedings of the ACM SIGCOMM '04
Conference, Portland, Oregon, August 2004
4 Frank Dabek, Emma Brunskill, M Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, and Hari Balakrishnan, “Building Peer-to-Peer Systems With Chord, a Distributed Lookup
Service”, Proceedings of the 8th Workshop on Hot Topics in Operating Systems
(HotOS-VIII), May 2001
5 F Dabek, J Li, E Sit, J Robertson, M F Kaashoek, and R Morris “Designing a DHT for
low latency and high throughput.” In Proceedings of the 1st USENIX Symposiumon
Networked Systems Design and Implementation (NSDI ’04), San Francisco, California, March
2004
6 Hancong Duan, Xianliang Lu, Hui Tang; Xu Zhou, Zhijun Zhao “Proximity Neighbor
'06 The Sixth IEEE International Conference September 2006
7 Ion Stoica, Robert Morris, David Karger, M Frans Kaashoek, Hari Balakrishnan “Chord: A
Conference on Applications, Technologies, Architectures, and Protocols For Computer Communications (San Diego, California, United States) SIGCOMM „01 ACM, New York,
NY, 149-160 2001
8 R Cox and F Dabek “Learning Euclidean coordinates for Internet hosts.”
http://pdos.lcs.mit.edu/˜rsc/6867.pdf, December 2002
9 T Gil, J Li, F Kaashoek, and R Morris Peer-to-peer simulator, 2003
http://pdos.lcs.mit.edu/p2psim
10 http://pdos.csail.mit.edu/chord/
Tiếng Việt
11 PGS.TS Nguyễn Đình Việt (2009), bài giảng “Đánh giá hiệu năng mạng máy tính”
Trang 10Tiếng Anh
13 Frank Dabek, Russ Cox, Frans Kaashoek, and Robert Morris “Vivaldi: A
Decentralized Network Coordinate System.” In the Proceedings of the ACM SIGCOMM '04
Conference, Portland, Oregon, August 2004
14 Frank Dabek, Emma Brunskill, M Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, and Hari Balakrishnan, “Building Peer-to-Peer Systems With Chord, a Distributed Lookup
Service”, Proceedings of the 8th Workshop on Hot Topics in Operating Systems
(HotOS-VIII), May 2001
15 F Dabek, J Li, E Sit, J Robertson, M F Kaashoek, and R Morris “Designing a DHT for
low latency and high throughput.” In Proceedings of the 1st USENIX Symposiumon
Networked Systems Design and Implementation (NSDI ’04), San Francisco, California, March
2004
16 Hancong Duan, Xianliang Lu, Hui Tang; Xu Zhou, Zhijun Zhao “Proximity Neighbor
Selection in Structured P2P Network.” Computer and Information Technology, 2006 CIT
'06 The Sixth IEEE International Conference September 2006
17 Ion Stoica, Robert Morris, David Karger, M Frans Kaashoek, Hari Balakrishnan “Chord: A
scalable peer-to-peer lookup service for internet applications.” In Proceedings of the 2001
Conference on Applications, Technologies, Architectures, and Protocols For Computer Communications (San Diego, California, United States) SIGCOMM „01 ACM, New York,
NY, 149-160 2001
18 R Cox and F Dabek “Learning Euclidean coordinates for Internet hosts.”
http://pdos.lcs.mit.edu/˜rsc/6867.pdf, December 2002
19 T Gil, J Li, F Kaashoek, and R Morris Peer-to-peer simulator, 2003
http://pdos.lcs.mit.edu/p2psim
20 http://pdos.csail.mit.edu/chord/
21 Yong Ma, Song Wang, Gang Wang, and Xiaoguang Liu, “A New Structured Peer-to-Peer
Architecture Based On Physical Distance”, 2010 16th International Conference on Parallel
and Distributed Systems
22 Yjang Li, Russ Cox, Frank Dabek, Frans Kaashoek, Robert Morris, “Practical, Distributed Network Coordinates”, MIT Laboratory for Computer Science , 2010
