nếu nó là successor của khóa, hoặc sẽ chuyển tiếp truy vấn cho một nút gần nhất sau khóa trong bảng định tuyến bằng cách tiếp tục gọi đệ quy phương thức findSuccessor trên nút đó.
Lớp FingerEntry gồm các đối tượng là các mục trong bảng định tuyến của mỗi nút. Mỗi nút chứa fingerTable là tập hợp các đối tượng FingerEntry tạo nên bảng định tuyến của nút đó.
Lớp Network: Là lớp chứa toàn bộ thông tin về mạng mô phỏng. Sau khi khởi tạo các đối tượng miền và nút được thêm vào đối tượng network để xây dựng mô hình mạng. Đối tượng này tiếp tục thực hiện tất cả các quá trình phân bố tài nguyên vào các nút, sinh ra các truy vấn và thực hiện các truy vấn này. Các phương thức quan trọng là:
o nodeBirth, nodeDeath o fixFingerTables
o getNodeDistance
Lớp InputGenerator: Là lớp đảm nhận việc sinh các dữ liệu cần thiết cho mạng hoạt động gồm thông tin về mạng, nút, vị trí của nút.
Lớp ResourceGen: Là lớp đảm nhận việc sinh tài nguyên và các truy vấn theo phân phối Zipf.
Lớp DoSchedule: Đảm nhận nhiệm vụ lên lịch và thực thi lần các thao tác của chương trình mô phỏng.
Quá trình thực thi:
Quá trình thực thi chương trình sẽ được phân ra làm nhiều bước và thực hiện tuần tự: đầu tiên là việc sinh ra các dữ liệu về mạng, tiếp đến là dữ liệu về tài nguyên và các truy vấn. Sau khi hoàn tất việc sinh các dữ liệu cần thiết, chương trình sẽ tiếp tục thực hiện các truy vấn, sau quá trình truy vấn các thông tin về mạng và kết quả thu được sẽ được tổng hợp và xuất ra file hoặc màn hình.
Quá trình sinh dữ liệu: Ban đầu một đối tượng Network được khởi tạo. Tiếp đó các thông tin về các đối tượng miền và nút được tạo ra từ các hằng số như số lượng miền, số lượng nút… Thời gian, thứ tự thực hiện truy vấn cũng như khả năng chịu tải của nút sẽ được sinh ngẫu nhiên bằng quá trình Poisson. Các thông số này được lưu lại thành file. Sau đó các đối tượng Areas và Node được sinh ra từ các file thông số đó. Sau khi tất cả các nút được sinh bằng cách gọi phương thức nodeBirth, bảng định tuyến của tất cả các nút được tính toán dựa vào phương thức fixFingerTables. Tiếp đến lớp ResourceGen được sử dụng để tạo số lượng các tài nguyên, cũng như danh sách truy vấn tương ứng.
Quá trình thực thi: Chương trình khởi tạo đối tượng thuộc lớp DoSchedule ứng với các thông số đã khởi tạo trước đó. Các thao tác thực hiện được đọc từ file schedule, bắt đầu bằng việc gán các tài nguyên vào từng nút, tiếp đến thực hiện các truy vấn từ file danh sách đã tạo ra trước đó. Quá trình thực hiện truy vấn theo đúng thiết kế của Chord thông qua hàm findSuccessor của lớp Node.
5.1.2. Các thay đổi đã áp dụng
Để cài đặt phương pháp điều khiển tắc nghẽn đã nêu, ta tiến hành một số thay đổi trên chương trình:
Cấu trúc chương trình: với lớp FingerEntry ta thêm biến lưu trữ thông tin về nút đích ban đầu.
Quá trình sinh dữ liệu: ngoài các dữ liệu ban đầu, ta sinh thêm một số dữ liệu như: giới hạn khả năng đáp ứng của các nút, thời gian thực hiện các truy vấn, thứ tự các nút thực hiện các truy vấn.
Quá trình thực thi: thay đổi chủ yếu được thực hiện trên lớp Node bao gồm các phương thức nhằm thực hiện:
o Phát hiện tắc nghẽn: trên mỗi nút duy trì một vector có kích thước bằng giới hạn khả năng đáp ứng của nút, chứa thời gian các truy vấn tới nút. Dựa vào vector này ta tính toán được tại thời điểm có một truy vấn tới nút đang trong tình trạng không tắc nghẽn, tắc nghẽn mềm hay tắc nghẽn hoàn toàn.
o Xử lý tắc nghẽn: Ta tạo ra phương thức tìm kiếm Successor cho một khóa mới. Nếu nút đang nhận truy vấn không bị tắc nghẽn việc thực hiện tương tự như phương thức findSuccessor ban đầu. Nếu nút xảy ra tắc nghẽn “mềm” sẽ tiến hành đặt lại fingerTable trên nút gửi truy vấn: chuyển tất cả các mục có đích là nút tắc nghẽn thành nút lân cận. Đồng thời lưu định danh nút gửi truy vấn vào danh sách các nút đã tiến hành thay đổi định tuyến: nodeChangedRoute. Với mỗi truy vấn sau đó nếu khóa cần tìm thuộc khoảng nút đích ban đầu và nút đích đã thay đổi ta thực hiện hàm tìm kiếm successor trên nút đích ban đầu, ngược lại ta thực hiện trên nút đích mới. Nếu nút tắc nghẽn hoàn toàn truy vấn sẽ bị hủy bỏ và ghi lại để tiện thực hiện việc nhận xét sau này.
o Xử lý khi nút hết tắc nghẽn: Khi một nút hết tắc nghẽn, sẽ thay đổi lại bảng fingerTable của một số nút thuộc danh sách nodeChangedRoute. Số lượng nút thay đổi lại fingerTable được
tính bằng kích thước danh sách nodeChangedRoute nhân với một hằng số quy định trước.
5.2. Kết quả
5.2.1. So sánh với mô hình Chord chuẩn
Để xác định hiệu quả của phương pháp đã đưa ra chúng ta tiến hành so sánh với mô hình Chord truyền thống. Với cùng một số bộ dữ liệu ta sẽ chạy lần lượt hai chương trình, trong đó một là chương trình truyền thống, hai là chương trình có áp dụng việc điều khiển tắc nghẽn. Việc đánh giá sẽ dựa trên số lượng gói tin bị loại bỏ và số gói tin trung bình phát sinh thêm với mỗi một truy vấn thành công trong toàn quá trình thực thi.
Mạng được xây dựng với một số thông số cơ bản như sau: số lượng node: 1000, độ dài khóa là 16 bit, số lượng query 10000, giá trị lambda để sinh ngẫu nhiên khả năng chịu tải của các nút trong mạng là 10.
Ta lần lượt thay đổi tốc độ truy vấn của các nút trên mạng và quan sát sự thay đổi về số lượng truy vấn bị loại và số gói tin phát sinh. Kết quả thu được được trình bày ở biểu đồ dưới. Cột x thể hiện tốc độ truy vấn tính bằng số truy vấn gửi đi mỗi ms, cột y thể hiện phần trăm số query bị loại bỏ do được gửi đến nút bị tắc nghẽn hoàn toàn. Đường đứt thể hiện trường hợp Chord truyền thống, đường liền thể hiện trường hợp sử dụng phương pháp điều khiển tắc nghẽn.
Hình 21: Biểu đồ số lượng gói tin bị loại bỏ khi áp dụng và không áp dụng việc điều khiển tắc nghẽn
Thông qua biểu đồ trên ta có thể thấy phương pháp điều khiển tắc nghẽn đưa ra có khả năng làm giảm số lượng truy vấn bị loại bỏ qua đó tăng khả năng phục vụ
của toàn hệ thống. Tuy nhiên cũng có thể thấy rõ ràng rằng phương pháp đưa ra không có khả năng ngăn chặn việc mạng sụp đổ khi chịu tải quá cao do không có phương pháp điều khiển tắc nghẽn đi kèm.
Tiếp đến ta xét tới số lượng trung bình gói tin mà một truy vấn thành công sử dụng nhằm đánh giá mức độ ảnh hưởng của việc sử dụng phương pháp điều khiển tắc nghẽn đã nêu.
Hình 22: Biểu đồ thể hiện số gói tin trung bình phải sử dụng với mỗi truy vấn thành công
Ở biểu đồ trên cột x ứng với tốc độ truy vấn, cột y thể hiện số gói tin trung bình trên mỗi truy vấn thành công. Ta tính toán giá trị một cách tương đối bằng cách chia tổng số gói tin sử dụng cho số truy vấn thành công. Qua biểu đồ có thể thấy khi tốc độ truy vấn tăng, tương ứng với mức độ tắc nghẽn tăng, số lượng các gói tin điều khiển và gói tin phát sinh thêm khi thay đổi đường định tuyến sẽ tăng. Tuy nhiên mức độ tăng có thể thấy là không quá lớn, chủ yếu là do các gói tin điều khiển. Qua đó có thể thấy mức độ ảnh hưởng khi sử dụng phương pháp là không quá lớn so với phương pháp định tuyến tham lam của Chord truyền thống.
5.2.2. Đánh giá hiệu năng khi tiến hành tùy chỉnh các tham số và cải tiến phương pháp
Đầu tiên ta xét tới tham số xác định khi nào xảy ra hiện tượng tắc nghẽn “mềm” tính bằng số phần trăm mức chịu tải của từng nút.
Hình 23: Ảnh hưởng của việc thay đổi giá trị xác định mức độ tắc nghẽn mềm của nút
Ở biểu đồ trục x thể hiện giá trị xác định tắc nghẽn đã để cập bên trên, cột kẻ chéo thể hiện số truy vấn bị loại bỏ do tắc nghẽn, cột đặc thể hiện số gói tin trung bình trên một truy vấn thành công. Hai cột cuối tương ứng với việc không sử dụng việc điều khiển tắc nghẽn. Có thể thấy nếu ta thay đổi giá trị xác định tắc nghẽn lên quá cao sẽ khiến cho nút phản ứng chậm khi bị tắc nghẽn dẫn tới số lượng gói tin bị loại bỏ cao, nếu đặt giá trị này quá thấp làm nút phản ứng quá sớm với việc tắc nghẽn, làm tăng đột biến số lượng gói tin, đặc biệt là gói tin điều khiển, khiến cho tải trên các nút ngày càng cao và sẽ làm cho tình trạng tắc nghẽn trầm trọng hơn. Giá trị phù hợp nhất nằm trong khoảng từ 50% đến 70%. Khi đó ta giảm thiểu được số lượng truy vấn bị loại bỏ mà không làm số lượng gói tin phát sinh thêm tăng cao.
Một tham số quan trọng khác đã được nhắc đến ở phần trước là số lượng các nút sẽ được phục hồi lại bảng định tuyến khi nút đích hết tắc nghẽn. Ta tiến hành thay đổi tham số này và quan sát kết quả thu được
Hình 24: Ảnh hưởng của số lượng nút được khôi phục bảng định tuyến lên hiệu năng của hệ thống
Qua biểu đồ trên có thể thấy số lượng gói tin bị loại bỏ do tắc nghẽn giảm khi ta tiến hành phục hồi chậm trên các nút hết tắc nghẽn. Tuy nhiên cũng phải xét đến ảnh hưởng khi một nút phục hồi quá chậm mà ở đây chương trình mô phỏng chưa thể hiện được.
Ta tiếp tục xét đến một hình thức cải tiến của phương pháp đã đưa ra. Trên một nút ta duy trì thêm một giá trị xác định tắc nghẽn thứ hai nhỏ hơn giá trị xác định mức độ tắc nghẽn “mềm” đã có. Khi một nút có lượng truy vấn đến vượt qua giá trị tắc nghẽn thứ hai, nút đó sẽ thực hiện việc gửi yêu cầu thay đổi bảng định tuyến đến các nút ở “xa”, khi nút đạt đến mức tắc nghẽn “mềm” nó sẽ gửi yêu cầu thay đổi bảng định tuyến đến tất cả các nút. Việc xác định một nút xa hay gần được dựa trên ID của các nút đó. Dưới đây là một số kết quả thu được khi áp dụng phương pháp này
Hai cột đầu tiên mô tả phương pháp ban đầu với mức tắc nghẽn mềm được đặt là 75% khả năng của nút. Hai cột tiếp theo mô tả phương pháp cải tiến với giá trị tắc nghẽn mềm được đặt là 75%, giá trị tắc nghẽn thứ hai được đặt là 50%. Hai cột cuối mô tả phương pháp ban đầu với mức tắc nghẽn mềm được đặt là 50%. Qua biểu đồ có thể thấy khi sử dụng phương pháp cải tiến sẽ cho kết quả tốt hơn thể hiện bằng việc có số lượng truy vấn bị loại bỏ nhỏ nhất, đồng thời không sử dụng thêm quá nhiều các gói tin điều khiển như trường hợp sử dụng phương pháp ban đầu với mức tắc nghẽn mềm là 50%.
6. Kết luận và hướng phát triển
Luận văn đã đề xuất một phương thức điều khiển tắc nghẽn dựa vào việc điều chỉnh định tuyến trong mạng ngang hàng có cấu trúc. Tuy còn dừng ở mức đơn giản tuy nhiên thông qua thực nghiệm trên chương trình mô phỏng đã chứng tỏ khả năng giải quyết tắc nghẽn cục bộ, qua đó tăng thông lượng đạt được trên mạng.
Phương pháp đưa ra vẫn còn một số vấn đề cần phát triển thêm như việc tính toán các thông số phù hợp để đem lại hiệu quả cao nhất.
Ngoài ra có thể kết hợp phương pháp đã nêu với một phương pháp điều khiển tắc nghẽn dựa trên điều khiển lưu lượng nhằm giải quyết triệt để vấn đề tắc nghẽn khi mạng chịu tải cao, tránh bị sụp đổ do tắc nghẽn mà vẫn đảm bảo được khả năng phục vụ của toàn mạng.
Reference
1. Stephanos Androutsellis-Theotokis and Diomidis Spinellis. “A survey of peer-to-peer content distribution technologies”. ACM Computing Surveys,
36(4):335–371, December 2004.
2. R. Huebsch, B. N. Chun, J. M. Hellerstein, B. T. Loo, P. Maniatis, T. Roscoe, S. Shenker, I. Stoica, and A. R. Yumerefendi. “The architecture of pier: an internet-scale query processor”. In CIDR, pages 28–43, 2005.
3. F. Klemm, Jean-Yves Le Boudec, Dejan Kosti´c, and Karl Aberer, “Handling Very Large Numbers Of Messages In Distributed Hash Tables”, Proceeding
COMSNETS'09 Proceedings of the First international conference on COMmunication Systems And NETworks, 2009.
4. F. Klemm, J.-Y. Le Boudec, and K. Aberer. “Congestion control for distributed hash tables”, In The 5th IEEE International Symposium on
Network Computing and Applications (IEEE NCA06), 2006.
5. F. Klemm, J.-Y. Le Boudec, D. Kostic, and K. Aberer. “Improving the throughput of distributed hash tables using congestion-aware routing”. In
International Workshop on Peer-to-Peer Systems (IPTPS), 2007. Ecole
Polytechnique F´ed´erale de Lausanne (EPFL), Lausanne, Switzerland
6. Rüdiger Schollmeier, “A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications”, Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).
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. C. Tang and S. Dwarkadas. “Hybrid global-local indexing for efficient peer-to-peer information retrieval”. In NSDI, pages 211–224, 2004.