3.2.1. Thực nghiệm 1: Mô phỏng Chord, láng giềng gần và giải thuật Vivaldi 3.2.1.1 Cấu hình mô phỏng 3.2.1.1 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 trực tiếp từ tập dữ liệu đã đƣợc MIT Pdos Lab mô phỏng trên 1,700 nút trên topology mạng Internet với tập dữ liệu King. Việc sử dụng tập dữ liệu King đảm bảo rằng độ trễ giữa các nút mạng sẽ gần hơn với thực tế mạng Internet.
- Độ trễ trung bình giữa các nút là 134 ms.
- 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 của hệ thống là 1000ms.
- 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)
Hình 3.1: Sơ đồ mô tả mô phỏng
3.2.2.2 Kết quả mô phỏng
Trong kết quả mô phỏng, chúng tôi sử dụng các ký hiệu Chord để mô tả kết quả cho Chord truyền thống và ChordPNS để mô tả cho lựa chọn láng giềng gần, Vivaldi để mô tả giải thuật Vivaldi.
- 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ị (hình 3.2) nhƣ sau: Tập dữ liệu độ trễ
(dựa vào tập King )
Sinh file topology mô phỏng: lần lƣợt là 128.txt, 256.txt, 512.txt, 1024.txt mô phỏng P2Psim Các tham số mô phỏng Kết quả mô phỏng
Băng thông sử dụng 0 10 20 30 40 50 60 70 80 128 256 512 1024 Số node (by te /s ) Chord Chord PNS Vivaldi Hình 3.2: Đồ thị về băng thông sử dụng
Với kích thƣớc mạng tăng lên thì băng thông sử dụng của Chord, ChordPNS, Vivaldi 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ị hình 3.2, 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 và Vivaldi. So với lựa chọn láng giềng gần, giải thuật Vivaldi sử dụng băng thông mạng gần nhƣ tƣơng đƣơng. Nguyên nhân là do Vivaldi và láng giềng gần luôn duy trì đƣợc trạng thái của nút và giảm đƣợc số chặng định tuyến nên băng thông của chúng thấp hơn Chord truyền thố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 128 256 512 1024 Số node Đ ộ t rễ ( m s) 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 thì 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ề miền đó. Quá trình tìm kiếm sẽ đƣợc thực hiện trên 6 miền lân 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 S ai s ố Vivaldi
Với kích thƣớc mạng tăng lên, đồ thị hình 3.4 cho thấy rằng 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 128 256 512 1024 Số node Tỉ l ệ (% ) Chord ChordPNS Vivaldi
Hình 3.5: Đồ thị so sánh tỉ lệ tìm kiếm không thành công.
Đồ 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 Chord, ChordPNS, Vivaldi là rất hiệu quả. Ngoài ra chúng ta còn thấy rằng ChordPNS và Vivaldi có tỉ lệ tìm kiếm thành công cao hơn Chord, hơn nữa 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, xác suất tìm kiếm của ChordPNS, Vivaldi cũng tăng theo.
Tóm lại, từ những phân tích ở trên chúng ta thấy rằng lựa chọn láng giềng gần và giải thuật Vivaldi đã cải thiện đƣợc hiệu năng của mạng, giảm độ trễ tìm kiếm của mạng, từ đó đã tối ƣu topology của mạng phủ Chord.
3.2.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. thƣớc.
3.2.2.1 Cấu hình mô phỏng
- Ma trận độ trễ đƣợc xây đựng lại đự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. 3.2.2.2 Kết quả mô phỏng - Độ trễ tìm kiếm trung bình 0 100 200 300 400 500 600 700 800 900 1000 0 10 20 40 80 Khoảng cách tăng (s) Đ ộ tr ễ (m s ) Chord ChordPNS Vivaldi
Hình 3.6: Độ trễ tìm kiếm trung bình của mạng 1024 nút
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.2.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
3.2.3.1 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. 3.2.3.2 Kết quả mô phỏng
Độ trễ tìm kiếm trung bình 0 100 200 300 400 500 600 700 800 900 128 256 512 1024 Số node Đ ộ t rễ ( m s ) 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ố.
Kết quả mô phỏng 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ả. 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, đó là giải pháp lựa chọn láng giềng gần và giả thuật Vivaldi. 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 độ trễ tìm kiếm và giảm đƣợc sự sai khác về topo giữa mạng vật lý và mạng phủ. Luận văn cũng cho thấy rằng việc phát triển các ứng dụng trên mạng ngang hàng có yêu cầu về độ trễ tìm kiếm thấp thì Vivaldi và lựa chọn láng giềng gần là những giải pháp thích hợp có thể đƣợc chọn lựa.
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).
- 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).
TÀI LIỆU THAM KHẢO 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”.
2. http://vi.wikipedia.org/wiki/Mạng_ngang_hàng
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 Selection in Structured P2P Network.” Computer and Information Technology, 2006. CIT '06. The Sixth IEEE International
Conference. September 2006.
7. 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.
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/
11.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.
12. Yjang Li, Russ Cox, Frank Dabek, Frans Kaashoek, Robert Morris, “Practical, Distributed Network Coordinates”, MIT Laboratory for Computer Science , 2010
PHỤ LỤC 1. Cài đặt và thực hiện P2Psim
P2Psim đƣợc biên dịch và chạy trên Linux và FreeBSD với GCC 2.95.3 và GCC 3.3.5. Ngoài ra, P2Psim cần thêm các thƣ viện libcrypto và libgmp. Tải về và giải nén, sau đó cấu hình và thực hiện [9]:
$ Wget http://pdos.lcs.mit.edu/p2psim/p2psim- 0.3.tar.gz $ Tar xvfz p2psim-0.3.tar.gz $ Cd p2psim-0.3 $. / Configure $ Make Thực hiện mô phỏng
Trƣớc hết cần tạo ra các file cấu hình để thực hiện mô phỏng - Cấu trúc File Topology:
topology {TOPOLOGY} [KEY=VAL [KEY=VAL [...]]]
failure_model {FAILURE_MODEL} [KEY=VAL [KEY=VAL
[...]]]
<Dòng trắng> <Thông tin nút>
TOPOLOGY có thể nhận các giá trị sau: Euclidean, E2Egraph. Tƣơng ứng với mỗi giá trị thì định dạng thông tin của nút sẽ khác nhau. Đối với tùy chọn Euclidean cấu trúc thông tin nút sẽ là: <id-núti> <xi,yi> (i=1,2,..n) , còn đối với tùy chọn E2Egraph cấu trúc thông tin nút nhƣ sau:
nút <id1> …
nút <idn>
<idi, idj> <latency> trong đó i=1,…n và j=1,..n.
FAILURE_MODEL có thể nhận các giá trị ConstantFailureModel hoặc NullFailureModel.
- Cấu trúc file Protocol:
Trong đó PROTOCOL có thể nhận các giái trị Chord, ChordFingerPNS, Kademlia, VivaldiTest, Tapestry, Koorde, Accordion,… Tƣơng ứng với từng giao thức sẽ có các giá trị KEY khác nhau.
- Cấu trúc file Event:
generator {GENERATOR} [KEY=VAL [KEY=VAL [...]]]
GENERATOR có thể nhận giá trị sau FileEventGenerator,
ChurnFileEventGenerator, ChurnEventGenerator
Sau khi có đƣợc các file cấu hình, việc mô phỏng sẽ đƣợc thực hiện bằng lệnh sau:
p2psim <protocol file> <topology file> <events file>
2. Thông tin về tệp vết
Sau khi thực hiện mô phỏng chúng ta thu đƣợc tệp tin lƣu vết có kết quả nhƣ sau: average RTT = 30ms # 1: k # 2: k_tell # 3: alpha # 4: stabilize_timer # 5: refresh_timer # 6: learn # 7: rcache # ... FAILED_LOOKUPS::lookup_10th:0 lookup_mean:0.000 lookup_median:0 lookup_90th:0 stretch_10th:0.000 stretch_mean:0.000 stretch_median:0.000
stretch_90th:0.000 hops_10th:0 hops_mean:0.000 hops_median:0 hops_90th:0 numlookups:0
OVERALL_LOOKUPS:: lookup_10th:8 lookup_mean:19.273 lookup_median:22 lookup_90th:26 stretch_10th:1.000 stretch_mean:2.182 stretch_median:1.000
stretch_90th:1.000 hops_10th:0 hops_mean:0.091 hops_median:0 hops_90th:0 numlookups:11
TIMEOUTS_PER_LOOKUP:: time_timeout_10th:0
time_timeout_mean:0.000 time_timeout_median:0 time_timeout_90th:0 num_timeout_10th:0.000 num_timeout_mean:0.000 num_timeout_median:0.000 num_timeout_90th:0.000
WORST_BURST:: in:0 out:0 <---ENDSTATS--->
Đây là tệp tin dùng để phân tích kết quả mô phỏng. Sau đây là ý nghĩa của một số từ khóa [9]:
Dòng BW_TOTALS cho biết tổng băng thông sử dụng trong các mô phỏng, Dòng BW_PER_TYPE cho biết tổng số byte sử dụng trong các mô phỏng cho từng loại meseage khác nhau.
BW_PERNODE_IN cho biết tổng số byte trung bình nhận tại mỗi nút trong khoảng thời gian nút tồn tại.
BW_PERNODE cho biết tổng số byte trung bình gửi đi tại mỗi nút trong khoảng thời gian nút tồn tại.
LOOKUP_RATES cho biết cụ thể bao nhiêu tra cứu đã tìm thấy một cách chính xác tƣơng ứng với khóa tìm kiếm trong toàn bộ mô phỏng.
CORRECT_LOOKUPS cho biết độ trễ tra cứu trung bình trong tất cả các tra cứu chính xác.
INCORRECT_LOOKUPS cho biết độ trễ tra cứu trung bình trong tất cả các tra cứu không chính xác.
FAILED_LOOKUPS cho biết độ trễ tra cứu trung bình trong tất cả các tra cứu không thành công.