Khóa luận Nghiên cứu ảnh hưởng của hiện tượng tham gia mà không đóng góp lên hệ thống chia sẻ file ngang hàng Bittorrent

n tham gia upload file lên mạng (original seed) là làm sao có thể phát tán tất cả các piece của file vào mạng 1 cách nhanh nhất có thể. Khi đó, chiến lược LRF được áp dụng cho seed là, trong các yêu cầu pieces từ các nút kết nối đến nó, nó sẽ ưu tiên phục vụ piece nào có số lượng được phục vụ ít nhất. Đơn vị đầu tiên ngẫu nhiên(Random First Piece): Khi một nút mới gia nhập mạng, nó sẽ chọn ngẫu nhiên 1 piece để tải về. Quy tắc này để khiến cho nút có được mẩu đầu tiên một cách nhanh nhất để bắt đầu upload. Chế độ kết thúc(Endgame Mode): Để giúp nút có thể kết thúc nhanh quá trình download, nút có thể yêu cầu piece cuối từ tất cả các nút liên kết với nó. 2.2.3. Thuật toán Choking BitTorrent là một hệ thống chia sẻ file ngang hàng, do đó sự tham gia của các nút vào quá trình up và download ảnh hưởng rất lớn đến sự sống còn của mạng. Nút trong mạng sẽ không đáp ứng tất cả các yêu cầu download các piece từ các nút liên kết với nó, mỗi yêu cầu đó chỉ được đáp ứng khi nút có yêu cầu đảm bảo được những điều kiện nhất định. Quy tắc được đặt ra để nhằm khuyến khích các nút tham gia upload vào mạng nhiều hơn, được gọi là cơ chế thúc đẩy (Incentive Mechanism) của BitTorrent. Thông thường, một nút chỉ đáp ứng yêu cầu của 4 nút hàng xóm cung cấp cho nó tốc độ download cao nhất, và quá trình xác định tốc độ download của các nút liên kết với nó được thực hiện 10 giây một lần. Khi chiến lược này được áp dụng, nút nào có tốc độ upload vào mạng càng cao thì càng có được tốc độ download cao. Chiến lược này gọi là chiến lược ăn miếng trả miếng (Tit-for-tat Strategy). Optimistic Unchoking: Nếu chỉ áp dụng quy tắc như trên sẽ bó hẹp sự trao đổi dữ liệu giữa các nút liên kết với nhau. Để tạo cơ hội tìm kiếm các nút có cung cấp tốc độ download cao hơn cũng như để cho nút mới tham gia vào mạng có thể có được đáp ứng về piece đầu tiên, BitTorrent sử dụng “optimictic unchoke” 30 giây 1 lần. Optimistic unchoke sẽ mở đáp ứng cho một kết nối ngẫu nhiên mà không tính đến tốc độ download cũng như upload. Trong Khóa luận này, chúng ta sẽ nghiên cứu kĩ hơn tác dụng của cơ chế thúc đẩy của BitTorrent trong việc hạn chế hiện tượng free-riding trong BitTorrent. 2.3. Optimistic Unchoking và Free-Rider Free-rider là nút không upload đến các nút khác, do đó theo chiến lược TFT, nó cũng không nhận được dữ liệu từ các nút khác. Tuy nhiên do có Optimistic Unchoke như đã nói ở trên, free-rider vẫn có được cơ hội nhận được dữ liệu từ hệ thống. Chúng ta sẽ xem xét cụ thể hơn vấn đề này. Gọi G{p0,p1, …, pxn-1, q0,q1, …, qxf-1 } là tập hợp các nút trong mạng BitTorrent. Trong đó xn là số lượng các nút bình thường (non free-rider) và xf là số lượng của free-rider trong mạng. Giả sử tất cả các nút trong mạng có cùng một băng thông upload , và không có seed trong G. Gọi µ là băng thông upload của mỗi nút, như vậy tổng băng thông upload của hệ thống là µxn. Gọi u là số lượng kết nối upload của nút trong mạng, trong đó có 1 kết nối là optimistic unchoking. Tốc độ của mỗi kết nối bị giới hạn bởi µ/u. Theo quy tắc Optimistic Unchoking, mỗi nút bình thường sẽ chọn ngẫu nhiên một nút khác để gửi dữ liệu, từ đó tổng số kì vọng tốc độ download của free-rider trong G là: (1) Trong trường hợp xn+xf >> u Từ (1) cho thấy rằng mặc dù không đóng góp cho hệ thống như free-rider vẫn nhận được tốc độ download được tính bởi (1). Gọi ρ là tỉ lệ của tổng tốc độ download của free-rider so với tổng băng thông upload của các nút bình thường. ta có: (2) Với 0 ≤ ρ ≤ 1. Từ (2) cho thấy free-rider vẫn có được một phần tốc độ download của cả hệ thống. Nói cách khác, cơ chế của BitTorent không thể loại trừ hoàn toàn hiện tượng free-riding, và free-rider có thể nhận được tài nguyên từ các nút bình thường thông qua optimistic unchoking. Để rút ra kết luận trên và các đẳng thức (1) và (2), tôi đã tham khảo trong [13]. 2.4. So sánh BitTorrent và một số hệ thống chia sẻ file ngang hàng khác Phương pháp dùng để phân phối tệp giữa mạng eDonkey2000 và BitTorrent là giống nhau, như các máy trong mạng eDonkey thường chia sẻ và tải về rất nhiều tệp, làm cho băng thông cho mỗi vận chuyển trở nên ít hơn. Ngược lại, vận chuyển BitTorrent nhanh hơn nhiều do các máy tập trung vào một tệp hay một nhóm tệp cụ thể. Giao thức eDonkey2000 nguyên thủy cung cấp rất ít khả năng chống free-riding, các phiên bản client mới của eDonkey2000 có cài đặt hệ thống khuyến khích tải lên nhiều hơn. Ví dụ chương trình eMule có hệ thống điểm (credits system) để thưởng các máy tải lên nhiều. Một máy sẽ ưu tiên các máy vận chuyển cho mình trước đây bằng cách chuyển vị trí các máy này lên đầu của hàng đợi làm cho thời gian chờ ít hơn. Hệ thống này tỏ ra khá hiệu quả vì hàng đợi trong mỗi máy khách sử dụng eMule thường lên đến hàng trăm, thậm chí hàng ngàn. KaZaA là một giao thức gần giống với giao thức BitTorrent nhưng nó có một điểm khác đó là nó phân biệt các máy trạm theo cấp cống hiến (Participation Level). Cấp cống hiến tăng khi bạn tải lên và giảm khi bạn tải về. Khi bạn tải lên một tài nguyên thì người có cấp cống hiến cao nhất nhận đầu tiên sau đó người có cấp cống hiến cao nhất này tải lên cho người có cấp cống hiến thấp hơn và cứ tiếp tục như vậy. Mô hình này tương tự như mô hình kim tự tháp, với người tải lên nhiều nhất ở vị trí đỉnh của kim tự tháp, và người ít tải lên ở các vị trí đáy của kim tự tháp. Mô hình KaZaA chỉ thích hợp phân phối tài nguyên cho một số lượng lớn người dùng, nó đã được chứng minh là người ở đáy kim tự tháp tải tệp về nhanh hơn trường hợp tải tệp về bằng phương pháp HTTP (trong trường hợp tệp rất lớn). Nhưng mô hình KaZaA có một nhược điểm nhỏ đó là nó tin tưởng vào báo cáo của các máy trạm về cấp cống hiến vì vậy các máy trạm có thể gian lận cấp cống hiến với rất nhiều các máy trạm không chính thức. Chương 3. Mô hình hóa và xem xét ảnh hưởng của free-riding lên hệ thống chia sẻ file BitTorrent 3.1. Một số nghiên cứu liên quan BitTorrent là hệ thống chia sẻ file ngang hàng phổ biến nhất hiện nay, vì thế nó cũng dành được sự quan tâm nghiên cứu của rất nhiều nhà khoa học. Có nhiều nghiên cứu nhằm cải tiến nâng cao hiệu năng của hệ thống BitTorrent với nhiều đề xuất khác nhau. Tuy nhiên đa số những khảo sát, cả về mô phỏng lẫn theo dõi thực thế [4][6][7][10][11] đều cho thấy rằng hệ thống BitTorrent tỏ ra rất hiệu quả trong việc tận dụng tài nguyên hệ thống và hỗ trợ số lượng lớn người sử dụng. Và vấn đề tối ưu hóa hệ thống BitTorrent thường tập trung hơn vào vấn đề đảm bảo tính công bằng trên mạng. Một vài nghiên cứu về “cơ chế thúc đẩy” của BitTorrent được trình bày trong [4][8][9][12]. Các thử nghiệm trong [4] đã chỉ ra rằng cơ chế của BitTorrent không thể đảm báo được tính công bằng trong hệ thống. Jun và Ahamad [8] xem xét hệ thống BitTorrent dưới lý thuyết trò chơi (vấn đề song đề tù nhân lặp lại – Iterated Prisoner’s Dilemma) và cho thấy rằng free-rider không bị trừng phạt thích đáng và những nút đóng góp cho hệ thống cũng không được đền đáp tương ứng. Qiu và Skirant [12] đã mô tả sơ lược ảnh hưởng của optimistic unchoking đối với hiện tượng free-riding, và cho thấy optimistic unchoking có thể dẫn đến hiện tượng free-ring trong hệ thống. Locher và các tác giả khác [9] cũng đã cho thấy trong BitTorrent một nút có thể tải file về thành công mà không có sự đóng góp gì cho mạng. Trong nội dung của khóa luận này, tôi sử dụng mô hình của các tác giả Jiadia Yu, Minglu Li, Jie Wu được giới thiệu trong [13]. Mô hình chia các downloader trong mạng thành 2 loại chính free-rider và non free-rider và xem xét ảnh hưởng của free-rider trong hệ thống BitTorrent một cách khá toàn diện. 3.2. Mô hình và các tham số Dựa trên các kết luận trình bày trong phần 4.1.1, chúng ta sẽ xây dựng một mô hình mạng trong đó các nút trong mạng được chia làm 3 loại chính: seed, free-rider và non free-rider. Các nút non free-rider được xem là đóng góp cho mạng ngang nhau trong khi các nút free-rider hoàn toàn không có đóng góp gì cho hệ thống. Seed không phân biệt free-rider hay non free-rider trong quá trình upload. Hệ thống được mô tả bởi các tham số (mô hình “Fluid model”) sau: xn(t) : số lượng của non free-rider trong hệ thống tại thời điểm t xf(t): số lượng của free-rider trong hệ thống tại thời điểm t y(t): số lượng seed trong hệ thống tại thời điểm t λn: Tốc độ tham gia vào mạng của non free-rider λf: Tốc độ tham gia vào mạng của free-rider µ: Băng thông upload của một nút c: Băng thông download của một nút θ: Tốc độ rời mạng của nút bình thường γ: Tốc độ rời mạng của seed η: Hiệu năng của quá trình chia sẻ file [3] ρ(t): Tỉ lệ của tổng tốc độ download của free-rider so với tổng tốc độ upload của non free-rider tại thời điểm t. κ(t): Tỉ lệ của số lượng free-rider trên tổng số lượng của free-rider và non free-rider tại thời điểm t. Mô hình trên được mở rộng từ mô hình trong [3] và được trình bày trong [4]. Ta giả sử free-rider rời mạng ngay sau khi download hoàn thành(bởi vì free-rider khi đó có ở lại mạng cũng không có ý nghĩa gì). Như vậy, trong hệ thống tồn tại 3 trạng thái: Seed, free-rider và non free-rider. Quan hệ giữa các trạng thái được trình bày như hình sau: Hình 2: Mô hình chung biểu diễn 3 trạng thái trong hệ thống chia sẻ file BitTorrent Hình vẽ trên cho ta thấy quan hệ giữa 3 trạng thái, tốc độ các nút tham gia và rời khỏi các trạng thái và thành phần phân phối băng thông của 3 trạng thái trong hệ thống BitTorrent. Trong mô hình này, tốc độ gia nhập mạng của free-rider và non free rider tương ứng là λf và λn. Tham số η biểu thị hiệu quả của việc chia sẻ file và được tính toán là rất gần với 1 trong [8]. Hiệu năng chia sẻ file của free-rider bằng 0. Tại thời điểm t, tốc độ upload của toàn bộ hệ thống là µ(ηxn(t) + y(t)). Tất cả các nút trong mạng cùng chia sẻ tốc độ upload được cung cấp bởi non free-rider và seed. ρ(t) cho biết tỉ lệ băng thống upload của non free-rider bị chiếm vởi free-rider. Áp dụng đẳng thức (2) ta có (3) Với 0 ≤ ρ(t) ≤ 1. Với seed khi upload không phân biệt free-rider hay non free-rider, do đó, tỉ lệ băng thông upload của seed bị chiếm bởi free-rider là: (4) Với 0 ≤ κ(t) ≤ 1. Do đó, tổng tốc độ download của non free-rider là : µ[(1-ρ(t))ηxn(t) + (1-κ(t))y(t)] Và tổng tốc độ download của free-rider là : µ[ρ(t)ηxn(t) + κ(t)y(t)] Tuy nhiên, tốc độ download của free-rider và non free-rider bị giới hạn bởi cxn(t) và cxf(t). Ta có : (5) Trong đó Dn(t) và Df(t) biểu thị tương ứng là tổng tốc độ download của non free-rider và free-rider tại thời điểm t(tốc độ non free-rider và free-rider rời khỏi các trạng thái tương ứng sau khi download xong). θxn(t) và θxf(t) tương ứng là tốc độ của non free-rider và free-rider rởi khỏi các trạng thái tương ứng khi đang download dở. Non free-rider chuyển sang trạng thái seed với tốc độ Dn(t) sau khi download xong. Seed rời bỏ trạng thái với tốc độ γ. Từ đó, tốc độ thay đổi của 3 trạng thái được xác định tương ứng bằng phương trình sau : (6) 3.3. Nghiên cứu hệ thống ở trạng thái ổn định (steady-state) Để nghiên cứu hệ thống ở trạng thái ổn định, chúng ta giả sử limt→∞xn(t), limt→∞xf(t), limt→∞y(t) tồn tại và : Trong đó xn, xf , và y là các giá trị cân bằng tương ứng của xn(t), xf(t) và y. Ở trạng thái ổn định t→∞ ta có : (7) Để đơn giản, chúng ta giả sử nút không bao giờ rời mạng khí chưa download xong (θ =0) và sẽ rời mạng ngay sau khi download hoàn thành (γ→∞). Với giả sử trên, từ (6) và (7) phương trình biểu thị trạng thái ổn định được viết lại thành : (8) Với (9) là giá trị cân bằng của ρ(t) và 0 ≤ ρ ≤ 1 Dễ thấy, với điều kiện thực tế c > µ thì và . Kết hợp với (8) ta thu được : (10) Với và Định lý 1 : Gọi Tn và Tf là thời gian download trung bình tương ứng của non free-rider và free-rider trong hệ thống. Trong một hệ thống không có seed, chúng ta có kết quả sau : (11) Chứng minh : Trong [12], áp dụng Little Law[3]. Ta có thời gian download trung bình cho một nút ở trạng thái ổn định được xác định bởi: Với T là thời gian download trung bình. Tương tự, trong mô hình của chúng ta, thời gian download trung bình tương ứng của non free-rider và free-rider được tính bởi Khi có một nút hoàn thành download, khả năng nó là free-rider là ρ , và khả năng nó là non free-rider là 1 – ρ. Do đó thời gian download trung bình của toàn bộ hệ thống là: Thay tương ứng các giá trị trong các biểu thức (9), (10), ta được kết quả của định lý. Nhận xét: Thông qua việc mô hình hóa hệ thống BitTorrent, chúng ta đã thấy được hiệu năng của hệ thống ở trạng thái ổn định và ảnh hưởng của hiện tượng free-riding lên hệ thống BitTorrent. Từ kết quả của định lý 1, xét trong điều kiện số lượng liên kết upload của một nút u=5, và với giá trị hiệu năng chia sẻ file η được xem xét trong [12] là gần như bằng 1, chúng ta thu được đồ thị biểu diễn sự phụ thuộc thời gian download trung bình của non free-rider, free-rider và hệ thống thông qua sự biến thiên của α: Thời gian download trung bình Hình 3: Thời gian download trung bình của non free-rider, free-rider và hệ thống theo sự biến thiên của α. Từ đồ thị trên cho thấy thời gian download trung bình Tf của free-rider luôn luôn lớn hơn thời gian download trung bình Tn của non free-rider. Đồng thời, giá trị của Tf cũng tăng rất nhanh khi α tăng lên, ngược lại Tn hầu như không tăng khi giá trị α nhỏ. Hơn nữa, khi α đạt giá trị 0.2 (=1/u) thì Tf không tồn tại (có nghĩa là một số free-rider không có đủ tài nguyên để kết thúc quá trình download).Ngược lại, non free-rider luôn luôn có thể hoàn thành quá trình download. Từ đó, có thể kết luận là cơ chế của BitTorrent có khả năng chống lại hiện tượng free-riding trong hệ thống không có seed, và thông qua Optimistic Unchoking, free-rider cũng không gây ảnh hưởng lớn đối với hiệu năng của toàn hệ thống. Từ đẳng thức (11) ta cũng thấy một điều rằng có thể tăng thời gian Tf bằng cách tăng số liên kết upload của mỗi nút u, tuy nhiên, điều này khó có thể thực hiện trong thực tế do nếu tăng số lượng kết nối TCP sẽ tăng thời gian trễ và ảnh hưởng đến hiệu năng của mạng. Ở trên, chúng ta đã giả sử γ→∞, có nghĩa là nút non free-rider sẽ rời mạng ngay sau khi quá trình download hoàn thành. Tuy nhiên, trong thực tế, sau khi hoàn thành download vẫn có một số lượng các nút vẫn ở lại hệ thống và đóng vai trò như seed. Do đó, free-rider vẫn có cơ hội nhận được thêm tài nguyên từ seed và có thể hoàn thành dược quá trình download. Bây giờ, chúng ta sẽ xem xét ảnh hưởng của hiện tượng free-riding lên hiệu năng của hệ thống khi giá trị γ thay đổi. Khi có tính đến γ, phương trình biểu diễn trạng thái ổn định của hệ thống được viết lại thành: (12) Trong đó Với ρ và κ là giá trị cân bằng tương ứng của ρ(t) và κ(t), 0 ≤ ρ, κ ≤ 1. Sau khi giải phương trình (12) ta thu được: (13) Khi Ngược lại, nếu tốc độ rời mạng γ của seed nhỏ hơn thì băng thông download c sẽ quyết định hiệu năng của mạng nếu giá trị của c là rất lớn []. Từ đó, ta có: (14) Khi Định lý 2: Gọi Tn và Tf là thời gian download trung bình tương ứng của non free-rider và free-rider trong hệ thống có seed, chúng ta có kết quả sau : (15) Khi Và (16) Khi Chứng minh: Dễ dàng chứng minh được định lý 2 tương tự như chứng minh định lý 1. Nhận xét: Khi tốc độ rời mạng của seed giảm, đồng nghĩa với việc số lượng seed có trong hệ thống tăng lên, số lượng tài nguyên dành cho các nút download cũng nhiều hơn. Từ kết luận của định lý 2, ta có đồ thị sau: Tỉ số giữa thời gian download trung bình Tn/ Tf Hình 4: Tỉ số giữa thời gian download trung bình của non free-rider trên thời gian download trung bình của free-rider biến thiên theo γ. Biểu đồ trong hình 4 biểu thị sự thay đổi về tỉ lệ giữa Tn và Tf khi thay đổi giá trị của γ. Ta thấy rằng, tỉ số này tăng lên khi tốc độ rời mạng của seed giảm đi. Và khi γ giảm đến 1 giá trị xác định () thì thời gian download trung bình của non free-rider và free-rider lúc đó là ngang nhau (thời gian này được xác định bởi băng thông download c). Khi γ tăng lên, thời gian download của free-rider dần dần tăng lên do đó, tỉ số giữa Tn và Tf giảm xuống. Từ đồ thị trên ta cũng thấy được một điều nữa là khi giá trị của α tăng lên, tỉ số giữa Tn và Tf cũng giảm xuống do thời gian download Tf tăng lên tương tự như trong hệ thống không có seed đã xét ở phần trước. Từ nhận xét trên, chúng ta có thể kết luận rằng cơ chế của BitTorrent không có hiệu quả trong việc hạn chế free-riding khi hệ thống có nhiều seed. Khi số lượng seed trong hệ thống tăng lên đến một giá trị nhất định, thời gian download của free-rider và non free-rider là ngang nhau. Chương 4. Chương trình mô phỏng OctoSim 4.1. Cài đặt và sử dụng chương trình 4.1.1. Giới thiệu, cách thức cài đặt và thiết lập môi trường để chạy chương trình OctoSim OctoSim : A BitTorrent Simulator là một ứng dụng viết bằng ngôn ngữ C# bởi các tác giả Ashwin Bharambe, Cormac Herley và Venkat Padmanabhan. Mã chương trình được các tác giả viết ra để thực hiện các thử nghiệm trong [4]. Có thể tìm và download chương trình tại địa chỉ trang web của Microsoft Research ( và tìm với từ khóa BitTorrent Simulator). Chương trình mô phỏng lại hệ thống BitTorrent theo các chi tiết sau: File được chia nhỏ thành các pieces, và không thể chia nhỏ hơn nữa, đồng thời, thuật toán Choking của BitTorrent cũng được triển khai một cách chính xác. Tuy nhiên, chế độ kết thúc (EndGame Mode) không được tính đến, tuy nhiên điều này cũng không ảnh hưởng nhiều đến các kết quả thử nghiệm. Để cài đặt và chạy chương trình, trên Linux, cần có mono và mcs (để biên dịch ngôn ngữ C#), trên Windows, sử dụng bộ công cụ lập trình Visual Studio. Để thực hiện các thử nghiệm trong khóa luận này, tôi đã sử dụng Visual Studio 2005 trên hệ điều hành Windows XP để build và chạy chương trình mô phỏng. Cấu hình cần thiết để chạy được chương trình mô phỏng này là máy tính có thể cài và chạy được Visual Studio, tuy nhiên, chương trình sử dụng các hàm tính toán và xử lý khá nhiều sự kiện nên một máy tính có CPU với tốc độ xử lý cao có thể giúp rút ngắn thời gian tiến hành các thử nghiệm. Đối với môi trường Windows, sau khi tải về mã nguồn chương trình từ Microsoft Research (sẽ được 1 file có đuôi là .msi), sau khi bung nén, chúng ta sẽ được một thư mục chứa mọi file liên quan đến chương trình (địa chỉ mặc định khi bung nén của thư mục thường là “C:\Program Files\Microsoft Research\MSR Simulator for the BitTorrent Protocol”, trong đó chúng ta cần chú ý đến 2 thư mục con là OctoSim chứa mã nguồn C# của chương trình và workloads chứa các file mẫu đầu vào của chương trình mô phỏng. 4.1.2. Đầu vào và đầu ra của chương trình mô phỏng Về mặt thực thi, OctoSim là một ứng dụng dòng lệnh (Console Application) cho phép nhập các giá trị đầu vào thông qua các tham số dòng lệnh hoặc file text. Các kết quả thử nghiệm được hiện một phần ngay trong cửa sổ Console và kết xuất trong các file text. Bây giờ chúng ta sẽ mô tả ngắn gọn về các file text đầu vào và đầu ra của chương trình. File đầu vào: Một vài mẫu của file đầu vào có thể tìm thấy trong thư mục workloads. Các file có phần mở rộng là .wl. Trong file này các lệnh được bố trí theo dòng, các dòng bắt đầu bằng # chỉ đó là những dòng chú thích, và chương trình sẽ bỏ qua khi đọc đến những dòng này. Cấu trúc của một dòng bình thường được xử lý bởi chương trình mô phỏng như sau: [end] Có thể hiểu một cách khái quát nội dung của 1 dòng sẽ xác định một sự kiện (một lệnh) được thực hiện vào thời điểm nào trong quá trình mô phỏng. Chi tiết cụ thể sẽ được mô tả kĩ hơn trong phần sau, khi chúng ta nói về nội dung file mã nguồn WorkloadProcessor.cs File đầu ra: Khi chạy chương trình mô phỏng OctoSim sẽ kết xuất ra 4 file text đầu ra có phần mở rộng lần lượt là .out.prm, .out.nds, .out.bw, .out.gph. Trong đó: File .out.prm lưu thông tin về giá trị của các tham số sử dụng trong chương trình như thời gian tiến hành thử nghiệm, thời gian và tốc độ tham gia vào mạng của các nút, kích cỡ file chia sẻ … File .out.nds có chứa các thông tin chung về các sự kiện xảy ra với các nút. Cấu trúc chung của một dòng trong file này là: [time] [node] [event] Có thể hiểu nội dung của dòng này là thời gian diễn ra sự kiện đối với nút, nút diễn ra sự kiện là nút nào, sự kiện đó là sự kiện gì và các thông tin chi tiết tương ứng với mỗi loại sự kiện. Thông tin chi tiết về từng loại sự kiện đối với 1 nút chúng ta có thể xem thêm trong file Logger.cs File .out.bw, file này chính xác đóng vai trò là file log của hệ thống. Cấu trúc của file chia thành các khối, mỗi khối bắt đầu bằng một dòng có nội dung là “time ”. Các dòng tiếp theo trong khối mô tả một cách vắn tắt về tình trạng của toàn bộ các nút trong mạng tại thời điểm xét, mỗi nút trên 1 dòng, cụ thể, thông tin trên mỗi dòng sẽ là: #d #u p s #p D Muốn biết chi tiết và hiểu hơn các khái niệm, có thể xem trong phương thức Dump của class Node trong file Node.cs. 4.2. Cấu trúc và chức năng của chương trình mô phỏng Tại thư mục được tạo ra sau khi bung nén chương trình, có chứa các thư mục con như sau: + cmu_scripts + exp_scripts + OctoSim + plotscripts + scripts + workloads. Tuy nhiên, khi xem xét và thực thi chương trình ta chỉ cần chú ý và tác động vào các file trong 2 thư mục OctoSim và workloads. Thư mục OctoSim chứa toàn bộ mã nguồn C# của chương trình. Sau đây, chúng ta sẽ mô tả một vài file mã nguồn quan trọng của chương trình 4.2.1. File Main.cs: Chức năng chính của file này là xử lý các tham số dòng lệnh và lưu vào một mảng tĩnh để xử lý sau. Về mặt cấu trúc trong file chứa class MainWrapper là class chứa hàm public static int Main(String[] args) sẽ được gọi đến đầu tiên khi chạy chương trình. Ngoài ra, trong lớp này còn khai báo một mảng tĩnh public static ArrayList cmdline_arguments dùng để lưu giá trị các tham số dòng lệnh. Nhiệm vụ chính trong hàm Main là đọc vào các tham số dòng lệnh, lưu nó vào mảng tĩnh đã được khai báo ở trên (chi tiết các tham số và ý nghĩa của các tham số có thể xem cụ thể trong file mã nguồn), sau đó tạo ra một thực thể new WorkloadProcessor(workload_file) để xử lý file nằm trong thư mục workloads đã nói ở trên. Nội dung chi tiết về WorkloadProcessor sẽ được nêu ngay sau đây. 4.2.2. File WorkloadProcessor.cs: Chức năng của file này là đọc nội dung file workload (*.wl), dịch nội dung các dòng tương ứng thành các chức năng hoặc gán tham số cho chương trình, tạo ra một thực thể Simulator và khởi động vòng lặp để xử lý các sự kiện của chương trình mô phỏng Về mặt cấu trúc, trong nội dung của file mã nguồn chỉ có 3 phương thức: void ProcessWorkload(string workloadfile): Đọc vào nội dung của file workload theo từng dòng, bỏ qua những dòng nào bắt đầu bằng kí tự ‘#’ (kí tự # để chỉ những dòng đó chỉ là những dòng chú thích), gọi phương thức GetTimeOfJob để lấy ra thời gian lệnh đó được thực hiện và kiểm tra kiểm tra xem thời gian thực hiện lệnh trong nội dung của dòng đó có còn hiệu lực hay không, nếu còn thì gọi đến hàm ProcessJob để thực hiện. public void ProcessJob(string jobstring):Xử lý nội dung trong từng dòng và thực hiện các chức năng tương ứng với từ khóa. Khi xem nội dung của phương thức này, chúng ta có thể hiểu thêm ý nghĩa của các từ khóa chứa trong file workload, đồng thời cũng biết được cách thức viết một dòng trong file workload sao cho chính xác và phù hợp với ý định của mình. Hai từ không thể thiếu khi viết file workload đó là "process_cmdline_args" dùng để chỉ cho chương trình biết cần xử lý các tham số dòng lệnh (đã được xử lý và lưu bởi hàm Main()), và "initialize" dùng để bắt đầu “chạy” chương trình mô phỏng. Thiếu đi 2 từ khóa này thì chương trình mô phỏng không hoạt động được như ý. Như thế, 2 dòng luôn luôn phải có trong file workload “now process_cmdline_args end” là và “now initialize end” . Ngoài ra còn có từ khóa "setparam" dùng để gán giá trị các tham số của chương trình. Chi tiết hơn có thể xem trong file mã nguồn. Thông tin và ý nghĩa của các tham số trong chương trình sẽ được nêu trong phần mô tả file SimParameter.cs. private long GetTimeOfJob(string job): Phương thức đọc lấy thời gian thực hiện của mỗi dòng lệnh trong file workload (lấy giá trị đầu tiên từ trái sang phải – chính là giá trị time được mô tả trong cấu trúc file workload đầu vào đã nói ở phần trước). 4.2.3. File Sim.cs: Chứa lớp đại diện cho sự mô phỏng của chương trình, với hàng đợi các sự kiện và xử lý sự theo băng thông. Về mặt cấu trúc, trong file có chứa 2 lớp và một giao diện: public interface TimerEvent: Khai báo mẫu cho một sự kiện được xử lý trong chương trình, để được lưu vào hàng đợi và xử lý, các sự kiện cần tuân theo mẫu này. public class WorkloadGenerator : Tạo ra các thông số môi trường cho các thử nghiệm ( ví dụ như sự phân phối băng thông của các nút, thời gian tham gia và rời khỏi mạng của các nút … tùy thuộc các tham số đầu vào). public class Sim: Đây chính là lớp đại diện cho toàn bộ một chương trình mô phỏng. Trong lớp này cần chú ý đến: private EventQueue triggers : Cây lưu giữ các sự kiện sẽ được xử lý của chương trình mô phỏng. Khi chương trình chạy sẽ duyệt cây từ gốc và xử lý các sự kiện. private SortedList nodes : Chứa danh sách toàn bộ các nút tham gia trong hệ thống. public void RaiseS