TÓM TẮT LUẬN VĂN Đề tài luận văn có yêu cầu chính là cải tiến giao thức DXCAST sẵn có với một giao thức DXCAST mới phù hợp hơn trong các ứng dụng video streaming như: IP TV, e-learning…
GIỚI THIỆU
Mạng Internet hiện đã và đang ngày càng có nhiều đóng góp trong cuộc sống hiện đại Tuy nhiên mạng Internet hiện nay vẫn chưa thể đáp ứng được nhu cầu của người dùng vì vẫn còn khá nhiều nhược điểm cần phải khắc phục Vấn đề mà chúng ta quan tâm nhất hiện nay là làm sao triển khai các dịch vụ trên mạng Internet với chất lượng đảm bảo và chi phí chấp nhận được
Cho đến nay những vấn đề về mạng vẫn chưa khắc phục được là do chúng ta vẫn chưa có một phương thức truyền dữ liệu vừa phù hợp với yêu cầu kĩ thuật lại vừa phù hợp với điều kiện kinh tế Đặc biệt phải kể đến các ứng dụng truyền thông đa phương tiện, đa điểm như là hội nghị trực tuyến (video-conferencing), giải trí đa phương tiện, lớp học từ xa (e-learning), vô tuyến truyền hình qua mạng Internet (Internet Protocol Television),… Đặc điểm chung của những ứng dụng này là đều yêu cầu giải pháp truyền dẫn dữ liệu và các luồng đa phương tiện từ một điểm đến đồng thời nhiều điểm cùng lúc
Có hai cách tiếp cận để giải quyết họ bài toán vừa nêu trên Cách tiếp cận thứ nhất người ta sử dụng các giao thức IP Multicast được hỗ trợ trên các router hiện nay (2012) Cách tiếp cận còn lại là phát triển các giao thức Application Layer Multicast (ALM), hay còn gọi là end-host multicast
Giao thức IP Multicast hiện được xem là giải pháp có thể đáp ứng được các vấn đề về chất lượng dịch vụ cho những ứng dụng kể trên nhưng vô cùng tốn kém trong việc triển khai rộng rãi giao thức này Dù đã được nghiên cứu và phát triển trong vòng
20 năm nhưng IP Multicast vẫn chưa được triển khai rộng rãi qua mạng Internet Lý do chính là các ứng dụng sử dụng giao thức IP Multicast buộc phải có sự hỗ trợ từ các thiết bị định tuyến (router, switch layer 3) trên mạng Đối với các giao thức ALM, cơ chế truyền dẫn dữ liệu được thực hiện ở end- host thay vì trên các router Không giống như IP Multicast, ALM không đòi hỏi sự hỗ trợ của hạ tầng mạng, lại có thể dễ dàng triển khai trên mạng Internet hiện nay Do đó đây là một hướng phát triển đầy tiềm năng Vấn đề hiện tại là chúng ta nên chọn một ALM nào để đảm bảo được chất lượng và chi phí cho các dịch vụ trên mạng Internet hiện nay
Các giao thức ALM được ra đời nhằm mục đích tối ưu hóa vấn đề truyền dữ liệu hiện nay, đặc biệt là việc truyền dữ liệu trong các ứng dụng như Internet Protocol Television (IPTV), video conferences, videophones… Các ứng dụng này ngày càng được mọi người ưu chuộng hơn vì tính tiện lợi của nó Ví dụ chúng ta có thể trò chuyện với người thân đang ở cách xa nửa vòng trái đất mà vẫn có thể nhìn và nghe người ấy nói giống như họ đang ngồi gần kế bên Những người khiếm thính hoặc khiếm thị vẫn có thể dễ dàng giao tiếp với người ở xa thông qua videophone… Mọi người sẽ trao đổi thông tin một cách tiện lợi và dễ dàng hơn khi sử dụng các dịch vụ này
Các ứng dụng quy mô nhỏ như video conference và videophone đã có giải pháp với các giao thức ALM khác nhau Tuy nhiên, khi áp dụng vào các ứng dụng quy mô lớn như IPTV thì các giao thức này lại gặp bất cập Vì vậy, nhiệm vụ trước mắt là cần nghiên cứu những giao thức truyền phát nội dung mới với chi phí hợp lý nhưng vẫn đảm bảo chất lượng để giải quyết bài toán chi phí lớn khi sử dụng giao thức IP Multicast truyền thống.
Về vấn đề Application Layer Multicast, hiện nay đã có khá nhiều cách tiếp cận khác nhau để giải quyết vấn đề này Vào thời điểm hiện tại (2012), các giao thức ALM được phân loại vào 3 chủ đề chính : tree-first, mesh-first và implicit
Năm 1999, Paul Francis đã phát triển phương pháp tree-first và đề xuất giải pháp Yoid (trước đây gọi là Yallcast) để hỗ trợ cả hai nhánh multicast là không gian và thời gian Điểm độc đáo của kiến trúc Yoid là nó cho phép một nhóm các máy chủ đầu cuối tự cấu hình trên mạng phủ để phân phối thông tin Ngoài ra, Yoid còn có khả năng chạy độc lập trên hạ tầng IP multicast.
Cũng ở hướng này, B Zang, S Jamin và L Zhang đã đề xuất ra giải pháp Host Multicast Tree Protocol (HMTP) vào năm 2001 Giải pháp này cũng tương tự như
Yoid trong việc cho phép các thành viên trong multicast group có khả năng tự tìm kiếm các node tổ tiên trên cây chia sẻ Tuy nhiên, khác với Yoid, HMTP ưu việt hơn với việc sử dụng kĩ thuật loop-resolution thay vì loop-avoidance trong việc xây dựng cấu trúc cây giữa các thành viên trong nhóm multicast
Với phương pháp mesh-first, nhóm nghiên cứu gồm Yang-hua Chu, Sanjay G Rao, Srinivasan Seshan và Hui Zhang đã đề xuất ra giao thức Narada vào năm 2002 Giao thức Narada là một trong những giao thức ALM đầu tiên minh họa được tính khả thi của việc triển khai các chức năng multicast trên lớp application Narada xây dựng một cấu trúc overlay giữa các end-systems trên tinh thần self-organizing và fully distributed Ngoài ra, Narada có khả năng thích ứng rất tốt với những sự cố của hệ thống và đưa ra những thay đổi linh hoạt trong nhóm các thành viên multicast Hơn nữa, Narada còn đưa ra những cơ chế để hỗ trợ cho việc liên tục tinh chỉnh hệ thống overlay giữa các thành viên bất kì khi nào thích hợp
Cũng vào năm 2002, các tác giả S Bannerjee, B Bhattacharjee, và C Kommareddly cũng giới thiệu giao thức NICE NICE được phát triển theo hướng implicit và tỏ ra rất thích hợp khi triển khai trên những ứng dụng dạng low-bandwidth, data streaming với một tập receiver lớn Mô hình này được xây dựng dựa trên một clustering phân cấp của các peers ALM và có thể hỗ trợ một số lượng lớn các cây phân phối dữ liệu với các đặc tính khác nhau Một điểm tích cực nữa của giao thức này là nó sinh ra control overhead khá nhỏ trên mạng khi triển khai trên các ứng dụng có khi lên đến hàng chục ngàn các receiver
Vào tháng 8 năm 2001, nhóm tác giả Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp và Scott Shenker đã đề xuất ra giải pháp Content-Addressable Network (CAN) CAN cũng là giải pháp ALM được liệt vào nhóm implicit Bắt nguồn từ ý tưởng bảng băm trong các hệ thống phần mềm hiện đại, các tác giả xây dựng ra giao thức CAN tương tự như một hạ tầng phân tán Chính vì lí do đó, CAN có khả năng hỗ trợ các chức năng tựa như bảng băm trên nền Internet CAN được đặc trưng bởi tính mở rộng, fault-tolerant và hoàn toàn self-organizing như hầu hết các giao thức ALM khác
Cho đến năm 2002, giao thức Scribe lại ra đời Nhóm tác giả Miguel Castro, Peter Druschel, Anne-Marie Kermarrec và Antony Rowstron đã dựa trên nền Pastry, một phương pháp được dùng để xây dựng và quản lý các nhóm cũng như để xây dựng các cây multicast hỗ trợ cho việc quảng bá các thông điệp tới các nhóm một cách có hiệu quả, để đề xuất ra hướng ALM implicit mới này Cũng như những giao thức ALM theo hướng implicit khác, Scrice có khả năng hỗ trợ các nhóm lớn multicast Ngoài ra, Scribe còn nổi bật với khả năng đảm bảo về tính realiability trong các ứng dụng multicast
Vào tháng 11 năm 2007, nhóm nghiên cứu gồm R Boivie (IBM), N Feldman (IBM), Y Imai (WIDE / Fujitsu), W Livens (ESCAUX) và D Ooms đã đề xuất ra giao thức Explicit Multicast (XCAST) Đây cũng là một giao thức theo nhánh ALM, tuy nhiên nó lại khá giống với IP Multicast ở việc can thiệp vào IP Header của các gói tin trong nhóm multicast Điểm nổi trội của giao thức XCAST 6 là nó có khả năng hỗ trợ một số lượng rất lớn các session multicast nhỏ Chính vì vậy, XCAST 6 tỏ ra rất phù hợp khi triển khai trên các ứng dụng như video conferences, video phone…
KIẾN THỨC CƠ SỞ
Unicast
Khái niệm truyền thông điểm tới điểm chỉ sự trao đổi thông tin theo hướng một chiều, từ nguồn đến điểm nhận và không thông qua bất kỳ thiết bị trung gian nào Trong mô hình này, nút A gửi dữ liệu đến các nút B, C và D, tương ứng tạo ra ba gói dữ liệu để truyền đến mỗi nút.
Hình 2.1: Ho ạt động của Unicast
Ví dụ như bạn cung cấp dịch vụ xem video trực tuyến, nếu sử dụng unicast server chất lượng của bộ phim sẽ tuyệt vời nhưng sẽ phải trả giá là tại một thời điểm chỉ có một client được truy cập tới dịch vụ của bạn
Khi router nhận được một gói tin unicast, nó sẽ truyền gói tin đi dọc theo con đường duy nhất và ngắn nhất từ nguồn đến đích Do đó quá trình định tuyến sẽ đơn giản hơn
Tạo ra các vấn đề quá tải cho server cũng như phí phạm băng thông vì trong cùng một lúc phải cung cấp một lượng lớn dữ liệu giống nhau cho nhiều host khác nhau.Khi mạng Internet mới ra đời, người ta cho rằng unicast có lẽ đã đủ phục vụ thế giới Internet Tuy nhiên với đà phát triển và nhu cầu đòi hỏi chất lượng truyền phát tới client ngày càng cao cũng như phát xuất từ một nhu cầu rất cao về streaming digital media content thì những ứng dụng trên đã không còn đủ hữu hiệu để đáp ứng, từ đó sẽ làm giảm chất lượng và tạo các phiền phức cho clients khi cần xử lý các dữ liệu dạng real time như video conferencing, video on-demand, và các dạng multimedia khác.
IP Multicast
IP Multicast là khái niệm chỉ chế độ trao đổi thông tin trong đó thông tin được gửi từ một điểm tới một tập các điểm khác còn lại trong một nhóm, tức là một nguồn và nhiều đích
Khi nút A gửi dữ liệu đến nút B và D, bộ định tuyến R1 tạo hai gói tin riêng biệt Các gói tin này được định tuyến đến các bộ định tuyến đích R2 và R3 thông qua các đường truyền khác nhau Quá trình này dựa trên nhóm mà nút B và D tham gia vào.
Hình 2.2: Hoạt động của IP Multicast
Với giải pháp cung cấp dịch vụ xem video trực tuyến, doanh nghiệp có thể đảm bảo mọi người dùng đều nhận được dữ liệu để xem video, đồng thời đảm bảo chất lượng video ở mức chấp nhận được.
Tăng hiệu suất sử dụng băng thông IP Multicast đã giảm thiểu số lượng gói tin truyền đi không cần thiết nên làm giảm băng thông rõ rệt
Các router phải có hỗ trợ IP Multicast, có nghĩa là router có khả năng định tuyến địa chỉ lớp D Điều này là một khó khăn cho sự mở rộng mạng
Quá trình định tuyến phức tạp hơn unicast vì các gói multicast được truyền đi dựa trên bảng định tuyến multicast có chứa nhiều địa chỉ đích.
Application Layer Multicast (ALM)
Kỹ thuật Multicast để gửi các gói tin từ một nguồn tới đồng thời nhiều đích, trong ALM chỉ sử dụng truyền dẫn Unicast TCP/UDP giữa những node tham gia Đây là dạng giao thức mà trong đó các chức năng của Multicast được thực hiện ở các end- host Để node nguồn có thể phân phối các gói tin này tới đồng thời nhiều đích trong ALM, điều đầu tiên cần làm là xây dựng một lớp định tuyến Overlay giữa các node tham gia Việc thiết kế giải thuật và xây dựng Overlay này nhằm đảm bảo phân phối các gói tin tới đích hiệu quả tin cậy, quản lý các node vào ra và thiết lập lại cấu trúc Overlay Có hai cách tiếp cận trong việc xây dựng Overlay này như Tree first (eg NICE) hay Mesh first (eg Narada)
Theo hình 2.3, node A gửi đi 2 gói dữ liệu cho B và C, sau đó C gửi 1 gói dữ liệu đến cho D
Hình 2.3: Hoạt động của ALM
Trong thực tế, việc yêu cầu dữ liệu trực tiếp từ source quá nhiều thì server sẽ không đủ khả năng đáp ứng, vì vậy các client có thể chia sẻ dữ liệu với nhau theo kiểu peer-to-peer
Vì sự hiện thực các giao thức ALM đều ở trên các end-host nên ưu điểm lớn nhất của nó là không cần thay đổi router trong cơ sở hạ tầng mạng hiện nay, dễ dàng kết hợp chặt chẽ với nhau
Việc truyền nhận dữ liệu chủ yếu dựa vào các host và cấu trúc của giao thức Dễ dàng điều chỉnh giao thức cho phù hợp với yêu cầu của từng ứng dụng cụ thể
Việc nắm giữ các thông tin các end-host với nhau trong một topology là có giới hạn cho nên đây là một vấn đề lớn trong việc xây dựng một cấu trúc overlay tốt
Hiệu suất thực thi trong việc sử dụng cấu trúc overlay đối với các giao thức cũng bị giảm đi vì các ALM không tận dụng được các router có hỗ trợ Multicast
Không giảm hoàn toàn lưu lượng trên mạng như IP Multicast.
CÁC GIAO THỨC LIÊN QUAN
Giao thức Xcast6 Treemap
Giao thức Xcast6 Treemap là giao thức được phát triển từ giao thức Xcast6 Phương thức truyền dữ liệu của giao thức Xcast6 Treemap khi có sự hỗ trợ của Xcast router giống giao thức Xcast6 khi có hỗ trợ Xcat router, và giống với phương thức truyền IP Multicast Chúng ta đều biết hiện nay vấn đề triển khai cơ sở hạ tầng mạng trong mạng Internet còn gặp nhiều khó khăn, do đó việc triển khai router hỗ trợ giao thức Xcast6 và Xcast6 Treemap được xem là phương án không lạc quan Vì vậy, trong quá trình nghiên cứu giao thức Xcast6 Treemap, DXCAST truyền thống,và DXCAST cải tiến, tôi chỉ tập trung vào các mô hình mạng khi không có sự hỗ trợ của Xcast router
Như chúng ta đã biết, giao thức Xcast6 khi không có sự hỗ trợ của Xcast router thì nó hoạt động dựa trên trường Bitmap tương ứng với các địa chỉ host được lưu trong header packet Giao thức Xcast6 Treemap được phát triển dựa trên giao thức Xcast6 nên quá trình hoạt động của nó ngoài việc căn cứ vào trường Bitmap và địa chỉ host ra, nó còn phụ thuộc vào trường Treemap cũng được lưu tương ứng với các địa chỉ host trong header packet Trong Xcast6, khi một node muốn gửi các gói tin tới các node khác trong một nhóm thì danh sách các địa chỉ đích đều được lưu vào trường header của gói Nếu có Xcast router thì các gói sẽ được nhân ra và forward cho các router khác một cách tối ưu nhất, nhưng khi không có Xcast router thì việc truyền các gói trong mô hình mạng có thể trở nên kém hiệu quả vì quá trình truyền sẽ có thể tốn rất nhiều thời gian Từ vấn đề này, Xcast6 Treemap đã được phát triển để cải tiến quá trình truyền gói tin giữa các host trong trường hợp không có Xcast router bằng cách thêm vào trong header của gói dữ liệu truyền đi một trường thông tin Treemap
Trong định tuyến overlay, để tránh trường hợp một node trong cây định tuyến có quá nhiều node con cùng yêu cầu dữ liệu gây tắc nghẽn và hoạt động không hiệu quả, mỗi node sẽ được cấu hình cố định với lượng node con lớn nhất có thể Xét trong header packet của node source, ở đây chúng ta dùng 4 bit trong trường Treemap để lưu trữ các giá trị Treemap cho mỗi node con, tức là mỗi node source chỉ truyền dữ liệu cho tối đa 15 node cùng lúc Và trường treemap có chiều dài cố định 32 byte tương ứng với tối đa 64 node trong một nhóm (một nhóm tương ứng với một cây định tuyến)
3.1.2 Thiết lập các thông số header:
Như đã đề cập trong phần trên, ở đây chúng ta chỉ xét trường hợp giao thức Xcast6 Treemap hoạt động khi không có sự hỗ trợ của Xcast router
Giả sử chúng ta có cây định tuyến như hình 3.1
Hình 3.1: Sơ đồ cây định tuyến Xcast6 Treemap
Trong sơ đồ cây định tuyến hình 3.1, chúng ta thấy các node B, C, D, E, F, G đều yêu cầu dữ liệu từ node A Khi node A nhận được tín hiệu yêu cầu dữ liệu, nó tạo ra một packet với header có các thông số như bảng 3.1
Bảng 3.1: Treemap và bitmap tương ứng với các node hình 3.1
Trường Treemap có các giá trị treemap là 1 2 1 2 0 0 0 Mỗi giá trị treemap mang ý nghĩa tượng trưng cho số packet mà mỗi node được yêu cầu dữ liệu cần gửi đi Cụ thể trong mô hình trên, B yêu cầu một packet từ A nên A có treemap là 1, C và D mỗi node yêu cầu một packet từ B nên B có treemap là 2, E yêu cầu một packet từ C nên C có treemap là 1, F và G mỗi node yêu cầu một packet từ D nên D có treemap là 2 Các node E, F, G không có node nào yêu cầu dữ liệu nên chúng có treemap bằng 0
Trường Bitmap có các giá trị là 1 1 1 1 1 1 Mỗi giá trị 1 đại diện cho một node yêu cầu dữ liệu nhưng chưa nhận được dữ liệu như đã yêu cầu Giá trị 1 này sẽ được thiết lập lại bằng 0 khi node đó đã nhận được dữ liệu
Trường address dùng để lưu các địa chỉ host đã yêu cầu dữ liệu từ node source Khi mô phỏng, chúng ta đặt tên cho mỗi host là A, B, C,… hoặc số thứ tự 1, 2, 3, … nhưng trên thực tế các địa chỉ này được lưu dưới dạng địa chỉ Ipv6
3.1.3 Sơ đồ khối hiện thực giải thuật:
Hình 3.2: Sơ đồ khối giải thuật hiện thực hàm sendmsg ()
Create packet (*) bao gồm việc thiết lập các thông số header :treemap, bitmap, address như mục 3.1.2
Giải thuật đọc các giá trị treemap từ dòng lệnh như hình 3.3
Hình 3.3: Sơ đồ khối hiện thực code setTreemap
Trong hình 3.3, tmp[] là mảng một chiều chứa các giá trị treemap đọc từ dòng lệnh như trong các bảng treemap đã đề cập, sub[][] là mảng 2 chiều chứa các giá trị treemap của từng nhánh cây định tuyến của source hoặc subroot Ví dụ, ta có mảng các giá trị treemap từ dòng lệnh tmp[]= 2 1 0 2 0 0 thì sub[][] có giá trị như sau: sub[0][]=1 1 0 sub[1][]=1 2 0 0 Khi đó các địa chỉ host từ dòng lệnh cũng tương ứng với thứ tự giá trị treemap từ dòng lệnh Và việc lấy địa chỉ host được thực hiện thông qua các câu lệnh tcl sau:
Tcl & tcl = Tcl::instance(); const char* tclresult = tcl.result(); tcl.evalf("%s get-dstaddr %d", name(), i); tcl.evalf("%s get-dstport %d", name(), i);
Giải thuật hàm setbitmap() như hình 3.4
Hình 3.4: Sơ đồ khối hiện thực hàm setbitmap()
Hàm setbitmap() này có các thông số truyền vào là số nguyên i chỉ vị trí của host đang gọi hàm, mảng bitmap[] chứa các giá trị bitmap hiện tại của các host, mảng icount[] được tính thông qua công thức sau: icount[0] = treemap[0], icount[i] = icount[i-1]+treemap[i]
Hình 3.5: Sơ đồ khối hiện thực hàm receive()
Quá trình truyền dữ liệu khi không có hỗ trợ Xcast router được miêu tả cụ thể hơn thông qua mô hình Hình 3.6:
Hình 3.6: Mô hình hoạt động giao thức Xcast6 Treemap
Các router X1, X2, X3 trong mô hình trên là các router bình thường làm nhiệm vụ forward packet Các packet mang cùng tên host là packet mà chúng cần được truyền đến địa chỉ host đã yêu cầu dữ liệu
Theo mô hình 3.3, host A có treemap là 1 nên nó gửi đi một packet tới host B với các thông số:
B:[src=A | dest=(B C D E F G) | bitmap=(1 1 1 1 1 1) | treemap=(1 2 1 2 0 0 0)] Khi host B nhận được dữ liệu, bitmap tương ứng của B được thiết lập lại bằng 0, đồng thời treemap của B bằng 2 nên B gửi đi hai packet cho C và D với bitmap tương ứng là 0 1 0 1 0 0 và 0 0 1 0 1 1
C:[src=A | dest=(B C D E F G) | bitmap=(0 1 0 1 0 0) | treemap=(1 2 1 2 0 0 0)] D:[src=A | dest=(B C D E F G) | bitmap=(0 0 1 0 1 1) | treemap=(1 2 1 2 0 0 0)] Tương tự, host C nhận được dữ liệu, bitmap của C bằng 0, và treemap của C bằng
1 nên C gửi một packet cho E:
E: [src=A | dest=(B C D E F G) | bitmap=(0 0 0 1 0 0) | treemap=(1 2 1 2 0 0 0)] Host D nhận được dữ liệu, bitmap của D bằng 0 và treemap của D bằng 2 nên D gửi đi hai packet cho F và G:
F:[src=A | dest=(B C D E F G) | bitmap=(0 0 0 0 1 0) | treemap=(1 2 1 2 0 0 0)] G:[src=A | dest=(B C D E F G) | bitmap=(0 0 0 0 0 1) | treemap=(1 2 1 2 0 0 0)] Các host E, F, G vì có treemap bằng 0 nên sau khi nhận được dữ liệu, chúng chỉ thiết lập lại các giá trị bitmap tương ứng bằng 0 và quá trình truyền dữ liệu kết thúc.
Giao thức DXCAST tĩnh
Trong quá trình phát triển giao thức Xcast6 Treemap, chúng ta nhận ra một nhược điểm lớn của giao thức này là không thể triển khai trên mô hình có số lượng node lớn Trường Treemap trong header của mỗi gói dữ liệu chỉ dùng 4 bit để lưu trữ các giá trị treemap, do đó số lượng node tối đa tương ứng có thể lưu được trong một packet là 15 node Chúng ta cũng không thể tăng vùng lưu trữ các node lên quá nhiều vì như vậy sẽ làm tăng kích thước của packet hoặc làm giảm vùng lưu trữ dữ liệu Do đó để khắc phục nhược điểm này, chúng ta có thể kết hợp truyền dữ liệu trên các nhóm nhỏ lại với nhau Giao thức Xcast6 Treemap vẫn sẽ được giữ nguyên trong từng nhóm nhỏ, và các nhóm nhỏ sẽ trao đổi liên lạc với nhau thông qua các node trung gian (subroot) Khi đó, giao thức được triển khai trên quy mô lớn này được gọi là giao thức DXcast
3.2.1 Sơ đồ khối hiện thực giải thuật:
Hình 3.7: Sơ đồ khối hiện thực DXcast trong hàm receive()
Quá trình hoạt động của giao thức DXcast cũng tương tự như giao thức Xcast6 Treemap, nhưng nó có thêm thành phần node trung gian gọi là subroot làm nhiệm vụ quản lý và truyền dữ liệu trong từng nhóm nhỏ trong mô hình Để dễ dàng hình dung được sự hoạt động của giao thức DXcast, chúng ta xét một cây định tuyến gồm 18 node như Hình 3.8:
Hình 3.8: Sơ đồ cây định tuyến Dxcast
Trong mô hình, node A (gốc) cung cấp dữ liệu cho 17 node khác Tuy nhiên, giao thức Xcast6 Treemap chỉ truyền được 15 node Giải pháp là chọn hai node làm "gốc phụ" (subroot), chẳng hạn như G và I Node A gửi tín hiệu cho G và I để lấy dữ liệu từ các node con tương ứng Sau đó, các gốc và gốc phụ sẽ lưu trữ thông tin về các node mà chúng truyền dữ liệu.
Bảng 3.2: Treemap của root A và các subroot G, I của cây định tuyến Hình 3.8
Quá trình truyền dữ liệu được bắt đầu khi node A gửi các packet đến cho các node con mà nó quản lý là B, C, D, E, F, G, H, I, J, N theo sơ đồ cây treemap tương ứng là 2 1 2 3 0 0 0 0 1 0 Khi các subroot G và I nhận được packet từ A, chúng sẽ thay đổi các địa chỉ node trong header của packet vừa nhận thành các địa chỉ node con mà nó quản lý, giá trị treemap cũng thay đổi tương ứng với các địa chỉ node mới Cụ thể node G sẽ truyền packet đến cho các node K, L, O, P, R theo các giá trị treemap 2 0 2 1
0 0 Node I sẽ truyền packet đến các node M, Q theo treemap 1 1 0 Địa chỉ source và nội dung dữ liệu vẫn không thay đổi trong quá trình truyền Như vậy, quá trình truyền dữ liệu từ source A sẽ được đảm bảo liên tục và truyền đến đúng các node đã yêu cầu.
TRIỂN KHAI GIAO THỨC DXCAST*
Giao thức DXcast
Để mở rộng bài toán Xcast6 Treemap, người ta đã đưa ra khái niệm subroot Về bản chất, subroot có vai trò giống như root trong Xcast6 Treemap Tuy nhiên, điểm khiến DXcast làm tăng được khả năng mở rộng của mình là nó cho phép một hệ thống có nhiều subroot
Có 3 thông số chính quyết định tính hiệu quả của một hệ thống ALM là: stress, path length và thời gian hội tụ mạng Việc chọn bao nhiêu subroot trong hệ thống mạng và host nào đóng vai trò subroot sẽ ảnh hưởng đáng kể đến các thông số mạng trên Thật vậy, việc chọn subroot trong bài toán DXcast phải thoả mãn các yêu cầu sau: thời gian hội tụ mạng phải nhanh, các tham số mạng stress và path length phải ở mức chấp nhận được
Về mặt lý thuyết, ta có thể chọn subroot theo hai cách: random hoặc vét cạn Phương pháp vét cạn yêu cầu mỗi host tham gia vào hệ thống phải tìm ra toàn bộ đường đi trung gian từ host được yêu cầu gửi dữ liệu đến các host yêu cầu dữ liệu Trên cơ sở đó, hệ thống sẽ tính toán ra được việc chọn subroot nào là tối ưu cho một topology cụ thể Còn đối với phương pháp random, đúng như tên gọi của nó, subroot được chọn ngẫu nhiên trên tổng số host mà root đang quản lý Đối với trường hợp vét cạn, chi phí tìm đường đi tối ưu trong mạng overlay có sẵn là quá lớn Các host tham gia vào hệ thống thực hiện phương pháp vét cạn phải trace tới các host yêu cầu dữ liệu từ nó Quá trình này sẽ tốn rất nhiều thời gian và băng thông trên toàn hệ thống Nhất là trong môi trường mạng Internet, sự thay đổi đường đi trung gian giữa các router trung gian từ host này sang host khác là hoàn toàn có thể xảy ra Chi phí cao cho một vấn đề không chắc chắn kết hợp với kết quả nhận được không hoàn hảo (stress và path length của phương pháp vét cạn sẽ tối ưu, tuy nhiên thời gian hội tụ mạng là quá lâu cho các ứng dụng thời gian thực) chính là lý do phương pháp vét cạn không được triển khai trong thực tế
Cách tiếp cận ngẫu nhiên trong mạng overlay cho phép host chọn subroot ngẫu nhiên mà không cần cân nhắc đến mạng vật lý bên dưới Tuy nhiên, điều này dẫn đến việc không kiểm soát được các thông số căng thẳng và độ dài đường dẫn, dẫn đến kết quả không nhất quán trên các topo mạng khác nhau.
B1 Lấy ngẫu nhiên một host bất kì (không phải là host lá) trong hệ thống làm subroot
B2 Nếu tổng số host mà root và subroot quản lý đều < 16 thì thuật toán kết thúc Còn nếu:
B2.1 Nếu tổng số host mà root đang quản lý >= 16 thì quay lại bước 1 cho bài toán cục bộ
Khi tổng số host mà subroot đang quản lý lớn hơn hoặc bằng 16, cần quay lại bước 1 để giải bài toán cục bộ Ví dụ minh họa: với Root A như trong Hình 4.1.
0 trong mô hình đang quản lý 17 host, trong khi giới hạn của giao thức Xcast6 Treemap chỉ cho phép root được quản lý tối đa 15 host
Hình 4.1: Sơ đồ cây định tuyến DXCAST
Rõ ràng để có thể thực hiện việc gửi dữ liệu cho toàn bộ số host trong hệ thống, root 0 phải chọn subroot để chia sẻ số host mà nó phải quản lý Giả sử theo phương phức random, subroot mà hệ thống chọn được sẽ là host 14 Lúc này chúng ta sẽ thu được cây định tuyến như Hình 4.2
Hình 4.2: Sơ dồ cây định tuyến DXCAST sau khi đã chọn host 14 làm subroot
Theo thuật toán ngẫu nhiên, tổng số host còn lại mà root quản lý sau khi chọn subroot 14 là 16 Để giảm số host quản lý xuống dưới 16, root sẽ tiếp tục chọn subroot ngẫu nhiên Giả sử subroot tiếp theo được chọn là host 8, thì cây định tuyến mới sẽ có dạng như mô tả ở Hình 4.3 Lúc này, root chỉ còn quản lý duy nhất host 8.
Hình 4.3: Sơ đồ cây định tuyến DXCAST sau khi đã chọn thêm host 8 làm subroot Đến lúc này, root 0 và các subroot 14, subroot 8 sẽ quản lý số host lần lượt là 14,
1, 2 Điều này cũng là giới hạn mà Xcast6 Treemap cho phép các root và subroot được quyền truyền dữ liệu
4.1.2 Các cơ chế phục hồi tự động khi hệ thống mạng có sự thay đổi:
Khi hệ thống mạng hoạt động bình thường, các sự cố làm thay đổi hệ thống mạng bao gồm các vấn đề phát sinh trên mạng Internet do gián đoạn hoặc tắc nghẽn mạng và do sự thay đổi số lượng host kết nối vào hệ thống làm thay đổi lưu lượng truy cập cũng như cấu hình mạng.
Về vấn đề phát sinh trên mạng Internet, chúng ta sẽ xem xét các vấn đề sau: khi các router trung gian giữa các host thay đổi, băng thông mà các host đang sử dụng có sự thay đổi đột ngột Vấn đề sự thay đổi giữa các router trung gian có thể hiểu theo hướng: khi các interface của các router bị rơi vào trạng thái down hoặc up, các router khác trên mạng Internet đi trung gian qua interface của router đó sẽ phải xây dựng lại bảng định tuyến của mình Còn vấn đề sự thay đổi đột ngột của băng thông, chúng ta có thể hiểu theo hướng: trong môi trường mạng Internet, băng thông mà các host trong hệ thống XCAST sử dụng là băng thông dùng chung, chính vì vậy khi các ứng dụng ngoài XCAST có sự yêu cầu tăng cao hay giảm xuống về băng thông, chắc chắn các ứng dụng XCAST cũng sẽ bị ảnh hưởng
Qua 2 vấn đề chính liên quan đến Internet mà chúng ta vừa đề cập, rõ ràng là chúng ta không có phương pháp nào để kiểm soát vấn đề này Đứng trên quan điểm của người phát triển các ứng dụng Application Layer Multicast, điều mà chúng ta có thể làm được chỉ là thích ứng cho phù hợp với hạ tầng mạng Internet mà thôi
Còn về vấn đề khi số lượng các host tham gia vào hệ thống Xcast có sự thay đổi về số lượng, chúng ta sẽ tập trung khảo sát vào các hai vấn đề chính sau: kịch bản dành cho một host mới gia nhập vào hệ thống và kịch bản dành cho host muốn ra khỏi hệ thống
Trường hợp thêm host mới vào hệ thống: Đối với trường hợp thêm host mới vào hệ thống XCAST, câu hỏi được đặt ra là chúng ta nên thêm host vào đâu? Về vấn đề này, chúng ta có các cách tiếp cận như sau:
1 Nếu ưu tiên vào việc không làm tăng băng thông giữa các router, chúng ta nên thêm host vào host có sẵn trên mạng overlay sao cho khoảng cách giữa host cũ và mới là gần nhất (xét trên bảng định tuyến giữa các router) Điều này lại liên quan đến vấn đề tính toán các tham số trên mạng Internet, do đó độ phức tạp của phương pháp này là rất cao
2 Nếu ưu tiên về thời gian hội tụ của thuật toán, chúng ta nên thêm host vào host lá trên mạng overlay Vấn đề phát sinh trong trường hợp này là: trong một hệ thống DXCAST có rất nhiều host lá, chúng ta nên thêm host mới vào đâu để đạt được tính hợp lý cao Kịch bản cho vấn đề này sẽ được xây dựng như sau: 2.1 Đầu tiên, host mới sẽ liên lạc với root để biết subroot nào đang quản lý ít host nhất trong hệ thống các subroot
Giao thức DXCAST*
Tinh thần chính của giao thức DXCAST* là làm giảm tối đa thông số thời gian hội tụ mạng của hệ thống Sau đây chúng ta sẽ xem xét cụ thể cách giao thức DXCAST* làm điều đó như thế nào
4.2.1 Kỹ thuật chọn subroot Ý tưởng của việc chọn subroot trong giao thức DXCAST* tương đối khác so với giao thức DXCAST Mục tiêu mà giao thức này đặt ra là: phân chia công việc giữa root và subroot phải có độ chênh lệch thấp nhất Với mục tiêu này, subroot mà giao thức DXCAST* chọn được luôn là hằng số trong từng cây định tuyến riêng biệt
Chi tiết về việc chọn subroot trong giao thức DXCAST* sẽ diễn ra theo các bước sau:
1 Đầu tiên root sẽ tính số con yêu cầu nó truyền dữ liệu
2 Kế đến, đối với mọi host con trong hệ thống của mình, root sẽ tính số con của host đang xét
3 Độ chênh lệch về số con giữa root và các host trong hệ thống của nó sẽ được so sánh đối với từng host cụ thể
4 Cuối cùng, sau khi duyệt qua danh sách các host trong hệ thống của mình, root sẽ tìm ra được một host mà số con yêu cầu host này truyền dữ liệu có độ chênh lệch thấp nhất với mình để làm subroot
5 Nếu tổng số host mà root và subroot quản lý đều < 16 thì thuật toán kết thúc Còn nếu:
6 Nếu tổng số host mà root đang quản lý >= 16 thì quay lại bước 1 cho bài toán cục bộ
7 Nếu tổng số host mà subroot đang quản lý >= 16 thì quay lại bước 1 cho bài toán cục bộ Để làm rõ lý thuyết, chúng ta sẽ xem xét một sơ đồ cây định tuyến cụ thể như ở Hình 4.53
Hình 4.53: Sơ đồ cây định tuyến DXCAST trước khi chọn subroot
Sau khi giao thức DXCAST* chạy xong thuật toán chọn subroot, chúng ta sẽ được danh sách các subroot như sau:
4.2.2 Các cơ chế phục hồi tự động khi hệ thống mạng thay đổi
Về phần này, giao thức DXCAST* được hiện thực tương tự như giao thức DXCAST Tuy nhiên do đặc trưng của quá trình chọn subroot trong giao thức DXCAST*, việc thêm host mới vào hệ thống có thể sẽ phát sinh thêm công việc tái tạo lại hệ thống cây temptree của root Điều này là do số lượng host mà các subroot trong giao thức DXCAST* là chênh nhau không nhiều, dẫn đến việc subroot có ít host nhất trong hệ thống cũng khá gần với ngưỡng 16 mà một hệ thống XCAST 6 Treemap cho phép truyền dữ liệu
4.2.3 Giải pháp cho bài toán có số lượng host lớn Đối với một hệ thống có số lượng host lớn, giao thức DXCAST* cũng chọn cách tiếp cận giống như giao thức DXCAST Tuy nhiên, đối với một trường hợp cụ thể là ứng dụng e-learning, giờ bắt đầu học thì học sinh thông thường sẽ vào lớp với số lượng nhiều Ánh xạ sang hệ thống DXCAST sẽ là: các primarySubroot sẽ phải tiếp nhận nhiều yêu cầu gia nhập của các host muốn gia nhập hệ thống của mình Một lớp học e- learning với vài nghìn học sinh sẽ làm cho khối lượng công việc phải xử lý của các primarySubroot là rất nhiều, cụ thể là quá trình chọn subroot của các primarySubroot
Và điều này cũng là đặc tính nổi trội của giao thức DXCAST* so với giao thức DXCAST
4.2.4 Sơ đồ khối hiện thực giải thuật
Cấu trúc dữ liệu và các hàm hỗ trợ của giao thức DXCAST* hoàn toàn giống giao thức DXCAST ngoại trừ hai hàm sau:
1 int ChooseSubrootByHeuristic(int root): trả về vị trí thích hợp nhất để làm subroot
2 void RenewTreeByHeuristic(int root,int subroot): hiệu chỉnh lại số con của root và subroot cho đến khi số lượng host có trong hệ thống của root và subroot đều 24 gia nhập hệ thống của root 0 như Hình 4.58
Hình 4.58: Sau thời điểm 0.15, các host trên toàn mô hình mới được truyền dữ liệu
Khi nhận được tín hiệu gia nhập, root 0 sẽ xây dựng lại hệ thống các subroot của mình như sau:
Giả sử đến thời điểm 0.16 có 3 host lần lượt là 17, 15, 3 muốn ra khỏi hệ thống Root sẽ cập nhật lại cây treemap của các subroot như Hình 4.51
Hình 4.59: Sơ đồ cây định tuyến tại thời điểm 0.16
Tuy nhiên, phải đến thời điểm trên 0.25 ta mới thấy sự thay đổi diễn ra trong subroot “3” như Hình 4.59
Hình 4.60: Host 7 lúc này đã trở thành subroot
SO SÁNH DXCAST VÀ DXCAST*
So sánh ngắn gọn giao thức DXCAST* với một số giao thức
5.1.1 So sánh DXCAST* với IP Multicast
Tất cả các router cần được nâng cấp để có thể sử dụng IP Multicast, trong khi DXCAST* cho phép triển khai lâu dài nhờ khả năng hỗ trợ ALM khi không có Xcast router Đối với IP Multicast, router phải lưu bảng trạng thái cho từng nhóm multicast nên không linh hoạt với số lượng nhóm nhiều Đối với DXCAST*, router không cần lưu bảng trạng thái cho từng nhóm, vì vậy thích ứng linh hoạt với số lượng lớn các nhóm multicast
5.1.2 So sánh DXCAST* với Xcast 6 Treemap
Về mặt số lượng host trong hệ thống, Xcast 6 Treemap chỉ có khả năng hỗ trợ 16 host Trong khi đó, giao thức DXCAST*, được nâng cấp từ giao thức DXCAST tĩnh có khả năng hỗ trợ lên đến vài nghìn host trong hệ thống Ngoài ra, DXCAST tĩnh là giao thức được phát triển từ giao thức Xcast 6 Treemap, nên giao thức DXCAST* cũng kế thừa được trọn vẹn các ưu điểm của giao thức Xcast 6 Treemap
5.1.3 So sánh DXCAST* với DXCAST Điểm khác nhau duy nhất giữa giao thức DXCAST* và giao thức DXCAST là kỹ thuật chọn subroot
Nếu ưu tiên về việc giảm thiểu tác hại lan truyền của hệ thống, chúng ta nên chọn giao thức DXCAST Điều này là do trong một hệ thống hoạt động dựa trên giao thức DXCAST thường có nhiều subroot Và các subroot ngang hàng không ảnh hưởng đến nhau trong quá trình truyền nhận dữ liệu Do vậy, khi một host hoặc một subroot bị ngưng hoạt động, các host và các subroot ngang hàng còn lại vẫn hoạt động bình thường
Nếu ưu tiên về các thông số mạng của hệ thống, chúng ta nên chọn cách tiếp cận giao thức DXCAST* Khác với giao thức DXCAST, giao thức DXCAST* không phải trải qua quá trình thử và sai để chọn subroot Subroot trong giao thức DXCAST* được chọn thông qua một quá trình tính toán nên danh sách các subroot trong hệ thống DXCAST* thường ít Kết quả: thời gian hội tụ mạng trong giao thức DXCAST* sẽ rất nhanh.
So sánh DXCAST* và DXCAST
5.2.1 Định nghĩa metric đo đạc
Link stress: link stress của một liên kết (link) là số packet giống nhau được gửi bởi một giao thức qua liên kết đó Đối với multicast lớp mạng (network layer multicast), không có sự nhân bản packet dư thừa nên link stress là 1
Link stretch: Thông số này được định nghĩa trên từng host nhận dữ liệu và được tính bằng tỉ số giữa chiều dài đường đi từ nguồn (source) tới host đích theo cây overlay và chiều dài đường đi từ nguồn đến host đích theo cách truyền unicast Theo định nghĩa này, link stretch của unicast và IP multicast là 1
Path length: path length của một host là số link hoặc số hop mà packet truyền từ nguồn đến host đó trải qua
Thời gian hội tụ mạng: Thông số này được tính trên tổng thời gian mà hệ thống xây dựng danh sách cây temptree mới khi có host muốn gia nhập Để hiểu rõ hơn về 2 metric link stress và link stretch, ta quan sát các ví dụ minh họa host source A truyền dữ liệu cho các host đích B, C, D theo các cách khác nhau :
Hình 5.1: sử dụng IP multicast, không có sự nhân packet ở các host, mỗi liên kết chỉ truyền một packet và truyền theo đường unicast sử dụng nên link stress và link stretch đều là 1
Hình 5.2: source A sử dụng unicast truyền packet đến các host B,C,D, link stress ứng với từng host đích là 1, link (A,1) có stress là 3, những liên kết tham gia truyền packet khác có stress là 1 Trong trường hợp tổng quát khi cần truyền dữ liệu cho một nhóm gồm N thành viên, nếu sử dụng cách truyền unicast thì link stress cực đại là N tại host nguồn và link stretch của các host đích là 1
Hình 5.3: biểu diễn overlay ứng với multicast vòng (ring multicast).B có stretch là 1, stretch C = 6/4 = 1.5, stretch D = 9/3 = 3 Stress trên mỗi link là 1 Trong trường hợp tổng quát, nếu sử dụng “ring multicast” để truyền dữ liệu cho N host đích thì link stress trên mỗi link là 1 và link stretch cực đại là N
Hình 5.4 minh họa một lớp phủ trung gian giữa hai lớp phủ ở hình 2 và 3 B có độ co giãn là 3/3 = 1, C có độ co giãn là 6/4 = 1,5, D có độ co giãn là 3/3 = 1 Liên kết (A,1) có độ ứng suất là 2, các liên kết khác có độ ứng suất là 1.
Hình 5.4: Application Layer Multicast (3) Ở đây, ta sử dụng số link để tính toán metric path length Trong hình 5.1, path length của host B là 3, host C là 4, host D là 3 Trong hình 5.2, host B, C, D có path length lần lượt là 3, 4, 3 Trong hình 5.3 là 3, 6, 9 và hình 4 là 3, 6, 3
5.2.2 Phương pháp đo đạc Để thể hiện được tính linh hoạt của mô hình DXCAST động, tôi xây dựng các mô hình bằng cách thêm và xây dựng cây treemap tự động Ứng với mỗi số lượng host trong một mô hình, tôi sẽ dùng thuật toán phát sinh 5 cây treemap theo chiều rộng, 5 cây treemap theo chiều sâu Với mỗi mô hình động thu được, tôi sẽ cho chạy cả hai giao thức DXCAST và DXCAST* Mỗi lần chạy giao thức DXCAST và DXCAST* trên một mô hình, tôi sẽ tiến hành đo 3 thông số: link stress, path length và thời gian hội tụ mạng Số liệu dùng để tham chiếu sẽ được tính trung bình cộng của các kết quả đo đạc từ 10 mô hình ứng với số lượng host cụ thể
Kết quả dưới đây thu từ được mô phỏng mô hình mạng với số lượng router biến thiên dựa trên số lượng host trong hệ thống Mỗi router sẽ cho phép tối đa gắn tối đa 4 node Các router được lựa chọn ngẫu nhiên kết nối với các host Số lượng các host biến thiên từ 30 đến 120 host
Sau khi tiến hành đo đạc, ta rút ra kết luận:
1 Nếu chỉ có một host gửi tín hiệu muốn gia nhập hệ thống tại một thời điểm, tham số thời gian hội tụ mạng gần như bằng 0
2 Nếu có nhiều hơn 16 host gửi tín hiệu muốn gia nhập hệ thống tại một thời điểm, sự chênh lệch về thông số thời gian hội tụ mạng giữa giao thức DXCAST và DXCAST* bắt đầu xuất hiện
3 Với mô hình có số lượng host muốn gia nhập hệ thống ít ( 30), sự chênh lệch về thông số thời gian hội tụ mạng giữa giao thức DXCAST và DXCAST* tăng dần
5 Ngoài thông số thời gian hội tụ mạng, các thông số còn lại là link stress và path length của giao thức DXCAST* cũng tốt hơn giao thức DXCAST
Bảng 5.1: Bảng link stress trung bình của DXCAST và DXCAST*
Bảng 5.2: Đồ thị so sánh link stress trung bình của DXCAST và DXCAST*
Bảng 5.3: Bảng path length của giao thức DXCAST* và DXCAST
Bảng 5.4: Đồ thị so sánh path length của DXCAST và DXCAST*
Bảng 5.5: Đồ thị so sánh thời gian hội tụ mạng của DXCAST và DXCAST*
Bảng 5.6: Bảng thời gian hội tụ mạng của DXCAST và DXCAST*