Chương 1: 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 đó 14 đâ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. Mặc dù các ứng dụng quy mô nhỏ như video conferences, videophone…, đã được giải quyết khá tốt với các giao thức ALM khác nhau, chúng lại gặp vấn đề khi triển khai trên các ứng dụng lớn như IPTV. Với bài toán chi phí nặng nề khi sử dụng các giao thức IP Multicast truyền thống, việc nghiên cứu và ứng dụng để giải quyết các họ bài toán kể trên với chi phí và chất lượng hợp lý là vấn đề cấp thiết hiện nay.
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. Với phương pháp tree-first, Paul Francis đã đề xuất ra giải pháp Yoid (trước đó gọi là Yallcast) vào năm 1999. Tác giả đã xây dựng một kiến trúc Yoid để phục vụ cho cả 2 nhánh multicast là space-based và time-based.
Thế mạnh chính của kiến trúc này là nó cho phép một nhóm các end-host có khả năng tự cấu hình trên mạng overlay để phục vụ cho mục đích phân phối thông tin. Ngoài ra, Yoid còn có thể chạy độc lập trên một hạ tầng IP multicast. Cũng ở hướng này, B. 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ư 15 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. 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 16 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. 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… Bên cạnh những ưu điểm vừa trình bày, XCAST 6 vẫn còn một số mặt hạn chế gây ảnh hưởng không nhỏ đến hiệu suất của toàn hệ thống. Thứ nhất, XCAST 6 sử dụng kĩ thuật truyền dữ liệu theo dạng daisy-chain.
Và điều này rõ ràng sẽ không tận dụng hiệu quả hệ thống mạng overlay giữa các thành viên trong nhóm multicast. Hơn nữa, trên các hệ thống có hỗ trợ các router XCAST (chức năng XCAST được cài đặt trên các router thông thường), XCAST 6 vẫn hoạt động bình thường và không tận dụng được sự hỗ trợ này. Chính vì những lý do đó, nhóm tác giả gồm Khoa T. Ettikan (PANASONIC) đã đề xuất ra giao thức XCAST 6 Treemap vào tháng 2 năm 2009.
XCAST 6 Treemap là một giao thức cải tiến từ XCAST 6. Do vậy, ngoài những ưu điểm kế thừa từ XCAST 17 6, nó còn cải thiện luôn những nhược điểm của giao thức này và tỏ ra không hề thua kém những giao thức ALM khác như Narada, NICE… Trong quá trình phát triển giao thức XCAST 6 Treemap, các nhà nghiên cứu phát hiệ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. Thật vậy, cũng như XCAST 6, XCAST 6 Treemap dùng cùng một phương pháp là điều chỉnh trường IP Header của các gói dữ liệu nhằm tối ưu hóa quá trình truyền dẫn. Tuy nhiê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 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ỏ với nhau. Giao thức XCAST 6 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 qua node trung gian. Khi đó, giao thức được triển khai trên quy mô lớn này được gọi là giao thức DXCAST.
Vào thời điểm hiện tại (2012), DXCAST, một giao thức được phát triển từ Xcast6 Treemap, tỏ ra khá thích hợp để giải quyết họ các ứng dụng với quy mô lớn dạng như video streaming. Việc nghiên cứu DXcast và áp dụng vào các ứng dụng dạng này hiện đang tỏ ra nhiều điểm hấp dẫn. Trong các cách tiếp cận để giải quyết các bài toán dạng video streaming, DXCAST có nhiều điểm hấp dẫn.