Luận văn -Xây dựng ứng dụng video streamming dựa trên mạng ngang hàng Chord

ựng ứng dụng sao cho phù hợp với những mục tiêu đó. Trong đó, trình bày chi tiết về thiết kế hệ thống, thiết kế giao thức và thiết kế chương trình của ứng dụng. Chương 4: Kết quả đánh giá hệ thống Sau các nghiên cứu ở các phần trên, chương 4 trình bày về môi trường chạy thử chương trình, các kết quả và đánh giá thu được sau quá trình thử nghiêm. Chương 5: Kết luận Chương I: Tổng quan về video streaming multicast 1.1. Giới thiệu về video streaming Video là một loại dữ liệu đa phương tiện quan trọng phục vụ cho truyền thông hoặc cho nhu cầu giải trí của con người trong nhiều thập niên. Trong thời kỳ đầu video được xử lý và truyền dưới dạng tín hiệu tương tự (analog). Với sự phát triển không ngừng của mạch điện tử và máy tính dẫn đến việc số hóa video và mở ra một cuộc cách mạng về nén và truyền thông video. Sự phát triển và phổ biến của Internet giữa những năm 90 đã định hướng truyền thông video qua mạng chuyển mạch gói best-effort. Video qua mạng qua mạng Internet gặp phải rất nhiều yếu tố bất lợi về băng thông, độ trễ và mất gói tin, cùng với một số vấn đề như làm thế nào để chia sẽ tài nguyên mạng giữa các luông hay làm thế nào có thể triển khai hiệu quả phương thức truyền thông một- nhiều ( truyền dữ liệu từ một nguồn đến nhiều đích cùng một lúc). Từ đó đã có rất nhiều giải pháp được nghiên cứu và phát triển nhằm khác phục những vấn đề này. Video streaming được định nghĩa là một “dòng chảy” video , nghĩa là dữ liệu video được truyền liên tục từ một nguồn đến một đích nào đó. Ý tưởng cơ bản của video streaming đó là chia video thành từng frame, sau đó liên tục truyền những phần được chia ra và bên nhận có thể hiện thị những phần video đã nhận được mà không phải đợi cho đến khi toàn bộ video được truyền xong. Tuy nhiên có một vài vấn đề ảnh hưởng trực tiếp đến video streaming. Video streaming qua mạng Internet gặp rất nhiều khó khăn bởi Internet chỉ cung cấp dịch vụ truyền best-effort (cố gắng tối đa). Do đó, nó không đảm bảo về băng thông, độ trễ, jitter hay sự mất gói tin. Những nhân tố này thường không đoán trước được và động. Chính vì vậy, mục tiêu chính của việc xây dựng một ứng dụng video streaming là phải thiết kết một hệ thống phân phát video chất lượng cao đáng tin cây qua mạng Internet. Các ứng dụng video streaming thường được nhiều người dùng cùng một lúc, tức là video phải được truyền cùng lúc tới nhiều người như video conference hay truyền hình trực tuyến. Truyền tin multicast là một giải pháp thích hợp cho những ứng dụng đó. Phần dưới đây sẽ trình bày chi tiết về multicast. Cấu thành nên một hệ thống video streaming gồm có 6 yếu tố cơ bản: cơ chế nén video, cơ chế điều khiển chất lượng dịch vụ tầng ứng dụng, dịch vụ phân phát video, máy chủ streaming, cơ chế đồng bộ dữ liệu và giao thức dành cho video streaming [10]. Hình 1 cho ta thấy được mối liên hệ giữa các yếu tố này với nhau. Hình 1: Cấu trúc ứng dụng video streaming ƒ Cơ chế nén video. Dữ liệu video nguyên gốc cần phải được nén trước khi được truyền nhằm tiết kiệm băng thông. ƒ Cơ chế điều khiển chất lượng dịch vụ tầng ứng dụng. Để đối phó với sự biến thiên của tài nguyền mạng hoặc để cung cấp chất lượng hình ảnh thay đổi theo từng người dùng, nhiều kỹ thuật điều kiển chất lượng dịch vụ tầng ứng dụng đã được đưa ra. Kỹ thuật đó bao gồm điều khiển tắc nghẽn và điều khiển lỗi. Điều khiển tắc nghẽn được triển khai để ngăn ngừa việc mất gói tin và giảm độ trễ. Trong khi đó, điều khiển lỗi cải thiện chất lượng hình ảnh khi có gói tin bị mất. ƒ Dịch vụ phân phát video trên đường truyền. Được xây dựng trên nền của Internet ( giao thức IP), dịch vụ phân phát video trên đường truyền cho phép đạt được QoS ( chất lượng dịch vụ) và hiệu quả cho việc phân phát video qua mạng Internet. ƒ Máy chủ streaming. Máy chủ streaming đóng vai trò quan trọng trong việc cung cấp dịch vụ streaming. Máy chủ streaming được yêu cầu phải xử lý các dữ liệu video với sự rằng buộc về thời gian, đồng thời hỗ trợ các hành động tương tác như dừng (pause), tua (fast forward). Một server streaming gồm 3 hệ thống con: bộ truyền tin (communicator) ví dụ như giao thức tầng giao vận, hệ điều hành và hệ thống lưu trữ. ƒ Cơ chế đồng bộ dữ liệu. Với cơ chế đồng bộ, ứng dụng tại bên nhận có thể hiển thị video gần giống như khi nó được khởi tạo tại bên gửi. Một ví dụ của cơ chế đồng bộ là cử động môi của người nói phải phù hợp với tiếng nói họ phát ra. ƒ Giao thức dành cho video streaming. Giao thức được thiết kế và chuẩn hóa cho truyền thông giữa máy khách và máy chủ streaming. Giao thức có thể được chia làm 3 loại: giao thức tầng mạng như Internet Protocol (IP), giao thức tầng giao vận như User Datagram Protocol (UDP) và giao thức điều khiển phiên như Real-time Streaming Protocol (RTSP). 1.2. Giới thiệu multicast Trong hệ thống mạng của chúng ta hiện nay có 3 cách truyền tin cơ bản đó là unicast, multicast và broadcast (Hình 2). Unicast là phương thức truyền tin cơ sở của IP network. Với unicast một máy truyền và chỉ có một máy nhận theo kiểu point to point. Hiện nay hầu hết các ứng dụng mạng được phát triển và sử dụng trên nền phương thức unicast như HTTP, Telnet, FTP … Nhưng với những ứng dụng đòi hỏi phải truyền tin từ một nguồn cho một nhóm người dùng như video streaming thì việc triên khai trên unicast là không hiệu quả và truyền tin multicast là giải pháp thay thế. Multicast là cách truyền dữ liệu từ một – nhiều (one-to-many) tức là dữ liệu được gửi từ một node nguồn và một nhóm node đích sẽ nhận được cùng dữ liệu đó. Cách truyền này khác với unicast– gửi thông tin trên mạng theo cách truyền gói tin một- một (one – to – one). Nếu multicast có thể so sánh với cuộc gọi chung cho nhiều người (conference call) thì unicast có thể so sánh với cuộc gọi riêng giữa hai người. Broadcast được mô tả như truyền thông tin cho toàn mạng, tất cả các điểm trong mạng đều nhận được thông báo này. Trong trường hợp này chỉ một người gửi nhưng tất cả người trong mạng đều nhận được. Broadcast được hỗ trợ trong mạng LAN (ví dụ Ethernet) và được sử dụng để gửi những gói tin giống nhau đến các máy trong mạng LAN (ví dụ ARP được sử dụng gửi địa chỉ đến toàn bộ máy trong mạng LAN). Network protocol (như IP) hỗ trợ khuôn dạng gói tin để gửi đến bất kỳ hệ thống nào trong logical network. Có thể nói, multicast là cách thức hiệu quả nhất để truyền dữ liệu đến một nhóm người trên Internet. Chúng ta cũng có thể sử dụng unicast để truyền tin lần lượt từ nguồn đến từng node trong nhóm. Tuy nhiên, với cách này thì node nguồn sẽ phải lặp đi lặp lại việc truyền 1 gói tin cho rất nhiều node khác, dẫn đến việc tiêu tốn tài nguyên của node nguồn ( CPU, memory …). Đồng thời, sẽ có rất nhiều gói tin không cần thiết được lưu thông trên mạng, dẫn đến lãng phí tài nguyên mạng. Với multicast, một cây multicast sẽ được hình thành với nguồn là gốc của cây và các thành phần còn lại của cây có thể là node đầu cuối ( end – host ) hoặc có thể là router tùy vào từng công nghệ multicast khác nhau. Thay vì việc node nguồn nhân bản gói tin và gửi đến từng node trong nhóm thì nó chỉ truyền cho 1 hoặc vài node nhất định và các node này có nhiệm vụ sao chép và truyền gói tin theo cây multicast. Hình 2: Các phương thức truyền tin trên mạng 1.3. IP multicast IP multicast (Hình 3) là chuẩn mở của IETF (Internet Engineering Task Force)[3], dùng để truyền dữ liệu tới nhiều người nhận. Trong IP multicast, các router sẽ đóng vai trò là node trung gian trong cây multicast và có trách nhiệm sao chép gói tin rồi truyền cho các node ứng dụng - ở đây, các node này sẽ đóng vai trò là ngọn của cây. Hình 3: Thành phần của IP multicast Trong IP multicast mỗi node sẽ gửi yêu cầu một router gắn với nó khi muốn ra nhập hoặc rời khỏi nhóm. Sau đó các router multicast sẽ trao đổi các thông tin về việc quản lý nhóm thông qua cây multicast. Tất cả các công việc như tạo nhóm, nhập nhóm, rời nhóm đều được thực hiện bởi giao thức IGMP (Internet Group Membership Protocol)(Hình 4)[4]. IP multicast sử dụng địa chỉ IP lớp D để định danh các nhóm multicast. Đây là dạng địa chỉ IP đặc biệt dành riêng cho multicast. Tất cả các máy nối kết vào Internet phải có địa chỉ IP thuộc lớp A, lớp B, hoặc lớp C. Một máy có thể có một hoặc nhiều địa chỉ multicast lớp D tùy thuộc vào số nhóm multicast mà nó tham gia. Địa chỉ lớp D có độ dài là 32 bit. 4 bit đầu tiên được dùng để xác định nó thuộc lớp D, 28 bit còn lại được dùng để xác định nhóm multicast. Một địa chỉ lớp D có thể so sánh với một kênh trên tivi. Khi bạn truy cập một địa chỉ lớp D, bạn sẽ nhận được tất cả thông tin được multicasting đến địa chỉ đó. Hình 4: Internet Group Management Protocol – Thông điệp Query IGMP chỉ có trách nhiệm quản lý các nhóm multicast và việc phân phát các gói tin multicast từ router nội bộ đến các node trong nhóm. Việc gói tin làm thế nào để đi được từ nguồn đến các router biên ( các router trực tiếp nối với node) phụ thuộc vào giao thức định tuyến multicast chạy trên các router trong mạng. Hiện nay có một vài giao thức định tuyến được phát triển dành riêng cho IP multicast như DVMRP (Distance Vector Multicast Routing Protocol) – giao thức định tuyến multicast đầu tiên hay như PIM (Protocol Independent Multicast) – giao thức multicast được dùng phổ biến nhất hiện nay. Với các giao thức định tuyến multicast trong IP multicast, số lượng gói tin phải sao chép nhân bản trên đường truyền được giảm thiểu so với các phương thức truyền tin khác từ đó tiết kiệm đáng kể băng thông mạng. Tuy nhiên một nhược điểm khiến nó không được sử dụng nhiều và không có khả năng mở rộng đó là các router trong mạng phải hỗ trợ multicast. Đồng thời, IP multicast chỉ hỗ trợ các ứng dụng chạy trên nền UDP – giao thức truyền tin không tin cậy. Nhằm khắc phục những nhược điểm này, truyền tin multicast tầng ứng đã và đang được nghiên cứu, phát triển rất nhiều trong những năm gần đây. Phần tiếp của khóa luận sẽ trình bày về phương thức truyền tin multicast tầng ứng dụng. 1.4. Multicast tầng ứng dụng ( ALM – Application-layer Multicast) 1.4.1. Giới thiệu Khái niệm multicast tầng ứng dụng chỉ đơn giản là việc thi hành multicasting như một dịch vụ tầng ứng dụng chứ không phải như một dịch vụ tầng mạng. Hình 5 mô tả việc truyền multicast cho cùng một nhóm người nhận và người gửi của multicast tầng ứng dụng và IP multicast. Ở đây, cây multicast được hình thành ở tầng ứng dụng. Với việc chỉ sử dụng phương thức truyền tin unicast của tầng mạng, node nguồn S gửi hai gói tin cho D1 và D2; tại D1, D2 gói tin được nhân bản và chuyền tiếp cho D4,D3. Hình 5: (a) IP multicast (b) Multicast tầng ứng dụng IP multicast được triên khai tại các node mạng ( Router) trong khi đó muticast tầng ứng dụng được triển khai tại các node ứng dụng ( end host hoặc proxy ). Do các node ứng dụng biết ít thông tin về tầng mạng hơn là các router nên cây multicast tầng ứng dụng thường không có độ tối ưu bằng IP multicast. Trong multicast tầng ứng dụng, các công việc điều khiển như ra nhập nhóm, rời nhóm, sao lưu và chuyển tiếp gói tin, định tuyến multicast… đều được thực hiện tại điểm đầu cuối (end system hoặc proxy) chính vì vậy mà không yêu cầu cần có những router hỗ trợ multicast ở mạng lõi. 1.4.2. Một số giải pháp truyền tin multicast trên tầng ứng dụng Dựa vào cấu trúc mạng hoặc cách tạo cây multicast mà ta có các giải pháp truyền tin multicast tầng ứng dụng khác nhau: Proxy-based ALM và end system ALM; mesh first và tree first [7] ƒ Proxy-based ALM và end system ALM Hình 6: (a) Proxy-based ALM (b) End-system ALM Trong mô hình Proxy-based ALM (Hình 6a), yêu cầu triển khai nhiều proxy hoặc server trên Internet, các proxy hay server này sẽ tự thành lập một mạng phủ (overlay network) với nhau và cũng cấp dịch vụ multicast trong suốt cho các người dùng cuối (end-user). Ngược lại, mô hình end-system ALM (Hình 6b) chỉ yêu cầu hạ tầng mạng phía dưới cũng cấp duy nhất dịch vụ truyền tin unicast, việc truyền multicast sẽ được thực hiện bởi các node đầu cuối (end-system). Với mô hình proxy-based ALM thì các ứng dụng chạy trên node đầu cuối sẽ ít phức tạp hơn bởi vì dịch vụ multicast trong suốt với chúng. Một điểm mạnh nữa của mô hình này đó là băng thông tại các proxy thường lớn hơn tại các node đầu cuối chính vì vậy mà tránh xảy ra hiện tượng “nút thắt cổ chai” như trong mô hình end-system ALM. Nhược điểm của mô hình này là chi phí phải trả cho hệ thống proxy hay server là rất cao. ƒ Mesh-fist và tree-first Trong mô hình mesh-first, các node muốn tham gia vào quá trình truyền hoặc nhận multicast sẽ tham gia vào một mạng phủ hình thành nên một tô pô dạng lưới liên kết các node với nhau (Hình 7a). Sau khi tô pô mạng được hình thành thì node nguồn sẽ sử dụng thuật toán định tuyến để truyền multicast thông qua mạng đó (Hình 7b). Thông thường cây multicast tạo ra từ phương thức không được tối ứu do gặp phải vấn đề vấn đề “nút cổ chai” khi một node có tài nguyên kém mà phải chịu tải cao. Hơn nữa việc duy trì mạng phủ cũng đòi hỏi một phần băng thông cho các thông tin điều khiển mạng. Tuy nhiên lợi thế của mô hình này là khả năng chịu lỗi cao bởi các node trong cây không chỉ biết đến node cha của nó mà còn biết thông tin về các node khác. Mô hình này thường được sử dụng với các ứng dụng đa nguồn multicast như video conference. Với mô hình tree-first, cây multicast được hình thành mà không cần các node tạo thành mạng phủ với nhau. Một node chọn cha của nó từ một số thành viên đã biết trong cây. Mô hình này cần có thuật toán phát hiện và tránh lặp xảy ra trong cây multicast. Các node trong cây sẽ chọn được vị trí tối ưu nhất tránh hiện tượng nút thắt cổ chai. Tuy nhiên điều này có thể dẫn đến cây bị lệch. Hơn nữa khi một node bị lỗi hoặc rời mạng thì việc khôi phục lại cây multicast sẽ khó khăn hơn rất nhiều so với mô hình mesh-first. Hình 7: (a) Mạng phủ 7 node (b) Cây multicast tạo từ mạng phủ Chương II: Truyền tin multicast trên nền mạng ngang hàng có cấu trúc Chord 2.1. Giới thiệu mạng ngang hàng 2.2.1. Khái niệm Một mạng máy tính ngang hàng (Peer-to-peer hoặc P2P) chủ yếu dựa trên sức mạnh tính toán và băng thông của các máy tham gia trong mạng hơn là tập trung vào một số lượng nhỏ các máy chủ (server). Mạng P2P được sử dụng điển hình cho việc kết nối các node thông qua những kết nối ad-hoc lớn. Những mạng như vậy có ích cho nhiều mục đích sử dụng. Chia sẻ file chứa audio, video, data hoặc mọi thứ ở định dạng số, các dữ liệu thời gian thực, ví dụ như truyền tải giọng nói, video streaming đều có thể thực hiện với công nghệ P2P. Một mạng P2P thuần túy sẽ không có khái niệm về khách (client) và chủ (server), mà chỉ có những node ngang hang thực hiện cả hai chức năng của một máy chủ và máy khách đối với những node khác trong mạng. Mô hình mạng này khác với mô hình mạng khách-chủ mà việc giao tiếp thường là với các máy chủ trung tâm. Một ví dụ điển hình cho việc truyền file theo mô hình khách-chủ là giữa một FTP Client và một FTP Server, hai chương trình FTP Client và FTP Server có vai trò rất khác nhau, client khởi tạo việc download/upload file, còn server thì tiếp nhận và phục vụ các yêu cầu đó. 2.2.2. Ưu thế của mạng ngang hàng Mục đích quan trọng của mạng ngang hàng là trong mạng tất cả các máy tham gia đều đóng góp tài nguyên, bao gồm băng thông, lưu trữ, và khả năng tính toán. Do đó khi càng có nhiều máy tham gia mạng thì khả năng tổng thể của hệ thống mạng càng lớn. Ngược lại, trong mô hình máy khách-chủ, nếu số lượng máy chủ là cố định, thì khi số lượng máy khách tăng lên khả năng chuyển dữ liệu từ các máy chủ cho mỗi máy khách sẽ giảm xuống. Tính chất phân tán của mạng ngang hàng cũng giúp cho mạng hoạt động tốt khi một số máy gặp sự cố. Đối với cấu trúc tập trung, chỉ cần máy chủ gặp sự cố thì cả hệ thống sẽ ngưng trệ. 2.2.3. Phân loại mạng ngang hàng Mạng ngang hàng P2P được chia làm hai loại chính: mạng ngang hàng thuần túy và mạng ngang hàng lai ghép (Hình 8). Hinh 8: Phân loại mạng ngang hàng ƒ Mạng ngang hàng thuần túy được chia làm 2 loại: mạng ngang hàng có cấu trúc và mạng ngang hàng không cấu trúc. ƒ Mạng ngang hàng không cấu trúc là khi các liên kết giữa các nút mạng trong mạng phủ được thiết lập ngẫu nhiên (tức là không theo qui luật nào). Những mạng như thế này dễ dàng được xây dựng vì một máy mới khi muốn tham gia mạng có thể lấy các liên kết có sẵn của một máy khác đang ở trong mạng và sau đó dần dần tự bản thân nó sẽ thêm vào các liên kết mới của riêng mình. Khi một máy muốn tìm một dữ liệu trong mạng đồng đẳng không cấu trúc, yêu cầu tìm kiếm sẽ được truyền trên cả mạng để tìm ra càng nhiều máy chia sẻ càng tốt. Sự hiểu biết về mạng của các node trong mạng không cấu trúc là rất ít, mỗi node chỉ nắm bắt thông tin về nhưng node kết trực tiếp và một số ít các node khác, thông tin về những node còn lại hoàn thông qua broadcast. Chính vì vậy với những ứng dụng cần có sự liên kết chặt chẽ giữa các node với nhau như multicast thì mạng ngang hàng không cấu trúc không phải là sự lựa chọn tối ưu. ƒ Mạng ngang hàng có cấu trúc khắc phục nhược điểm của mạng không cấu trúc bằng cách sử dụng hệ thống DHT (Bảng Băm Phân Tán, tiếng anh: Distributed Hash Table). Hệ thống này định nghĩa liên kết giữa các nút mạng trong mạng phủ theo một Peer-to-Peer Thuần túy Lai ghép Không cấu trúc Có cấu trúc ChordGnutella CAN Napster thuật toán cụ thể, đồng thời xác định chặt chẽ mỗi nút mạng sẽ chịu trách nhiệm đối với một phần dữ liệu chia sẻ trong mạng. Với cấu trúc này, khi một máy định tuyến thông báo, nó chỉ cần áp dụng một giao thức chung để xác định nút cần thông báo và sau đó liên lạc trực tiếp đến nút mạng đó. Bởi vậy việc tao cây multicast sẽ diễn ra rất dễ dàng và việc quản lý cậy cũng có nhiều thuận lợi khi các node đều được liên kết chặt chẽ với nhau. Một số mạng ngang hàng có cấu trúc nổi tiếng bao gồm Chord, CAN, Kademlia, Pastry và Tapestry.[5,6,9] ƒ Mạng ngang hàng lai ghép: Trong mô hình mạng ngang hàng lại ghép, tồn tại một server trung gian có trách nhiệm điều khiển hoạt động của mạng. Server này lưu dữ các chỉ mục bao gồm thông tin về các node nó quản lý và vị trí các cặp key-value trên mạng. Các node trong mạng phải tạo liên kết với server này. Một node muốn trao đổi thông tin với một node khác thì nó sẽ phải liên lạc trực tiếp với server, sau đó server sẽ tìm kiếm trong cơ sở dữ liệu và gửi lại địa chỉ node đích. Quá trình trao đổi thông tin sau đó được diễn ra trực tiếp giữa 2 node. Việc triển khai truyền tin multicast trên mạng ngang hàng lai ghép gần giống như mô hình proxy-base ALM. Nhược điểm chính của nó vẫn là chi phí cao cho các server trung gian. Ứng dụng điển hình cho mô hình mạng này là Napster. 2.2. Mạng ngang hàng có cấu trúc Chord 2.2.1. Giới thiệu chung Giao thức Chord là một giao thức định tuyến DHT bởi một nhóm sinh viên từ trường Đại học California ở Berkeley và MIT nhằm mục đích phân tán và tìm kiếm dữ liệu một cách tốt nhất với nhiều đặc trưng như scalability (khả năng mở rộng), complete decentralization (phân tán hoàn toàn), load blancing (cân bằng tải), và simplicity (đơn giản). Chord[6] được mô tả dưới dạng một vòng tròn và có không gian định danh cỡ m, với m là số bit định danh của không gian. Mạng Chord sẽ có tối đa 2m định danh. Một Chord node (hay một phần tử - một máy tính trong mạng Chord) có một định danh id, và các id trong mạng Chord sắp xếp thành vòng tròn và tăng theo chiều kim đồng hồ. Mỗi node trên vòng tròn sẽ biết thông tin về node trước và sau nó trên vòng tròn gọi là predecessor và successor của node đó. Thêm vào đó, mỗi node sẽ lưu một bảng định tuyến gọi là bảng Finger table, cho phép node đó định tuyến tới các node ở xa. Mỗi dòng trong bảng Finger table sẽ lưu thông tin về 1 node ở xa, gọi là 1 entry. Không gian định danh có bao nhiêu bit thì Finger Table có bấy nhiêu entry. Ví dụ trong hình 9 predescessor của node 1 sẽ là node 6 và successor của nó là node 3. Kĩ thuật Consistent hashing cấp cho mỗi node và key m-bit định danh dựa trên cơ sở hàm băm SHA-1[1]. Định danh của một node được xác định bằng cách băm địa chỉ IP node đó, định danh của một key xác định bắng cách băm key đó (Ở đây chúng ta quy ước từ khóa “key” vừa là key gốc vừa là định danh của key). Chiều dài của định danh cần đủ lớn để khi băm tránh xảy ra trường hợp 2 key hoặc node có định danh giống nhau. Hình 9: Vòng tròn Chord Giao thức Chord hỗ trợ duy nhất một hoạt động : đưa ra 1 key, nó sẽ ánh xạ key đó vào một node. Tùy thuộc vào ứng dụng sử dụng Chord ( văn bản, hình ảnh, media..), node đó sẽ lưu trữ một giá trị kết hợp với key. Chord sử dụng kí thuật consistent hashing để cấp key cho các node. Consistent hashing dùng để phân bổ các node cũng như các key đều trên vòng tròn từ đó nâng cao khả năng cần bằng tải, mỗi node sẽ nhận được số lượng key gần ngang nhau, đồng thời giúp cho việc ổn định mạng khi có node tham gia hay rời khỏi hệ thống. Trong mạng Chord mỗi node không cần biết thông tin về tất cả các node khác. Mỗi node Chord chỉ cần biết một lượng nhỏ thông tin định tuyến về các node khác. Vì những thông tin này là phân tán, một node sẽ sử dụng finger table để giao tiếp với các node khác. Khi mạng được thiết lập, một hệ thống Chord gồm N-node, trong đó mỗi node chứa thống tin về O(log N) node xung quanh nó, và tìm kiếm các node khác thông qua O(log N) thông điệp tới các node đó. Chord cần phải cập nhập lại thông tin định tuyến khi các node tham gia/rời khỏi hệ thống, với sự tham gia hay vào mạng của một node cũng chỉ cần không quá O(log2 N) thông điệp được gửi đi để cập nhập lại thông tin định tuyến. 2.2.2. Finger table Trong mạng Chord, mỗi node cần một lượng nhỏ thông tin định tuyến trong 1 môi trường phân tán. Chord node chỉ cần biết node successor của nó trong mạng. Các truy vấn đến một định danh ( một key hoặc một node) nào đó được truyền theo vòng tròn thông qua các node successor cho đến khi tìm được node biết thông tin về định danh đó. Với việc mỗi node đều duy trì một điểm successor của nó cũng đủ đảm bảo mọi truy vấn tìm kiếm đều được thực hiện chính xác. Tuy nhiên giải pháp này tỏ ra không hiệu quả khi một truy vấn có thể phải lan truyền qua toàn bộ các node mạng để tìm được node ánh xạ với nó. Để đẩy quá trình này, mỗi node Chord duy trì thêm một số thông tin định tuyến. Với chiều dài định danh key/node là m bit, mỗi node n sẽ duy trì một bảng định tuyến với m entry, được gọi là bảng finger table. Entry thứ i trong bảng finger table chứa định danh của node đầu tiên, s, mà tiếp sau n ít nhất 2i -1 trên vòng tròn định danh, s = successor(n + 2i - 1 ), với 1 ≤ i ≤ m. Node s được gọi là finger thứ i của node n và ký hiệu là n.finger[i].node. Một entry trong bảng finger table còn bao gồm địa chỉ IP, định danh, cổng của node finger đó. Có thể nhận thấy rằng, entry đầu tiên trong bảng finger table của node n chính là successor của node n. Hình 10: Bảng Finger table và các key gán cho từng node 0, 1, 3 Nhìn vào hình 10 ta thấy được mỗi entry trong bảng finger table của node 1 trỏ đến successor node của các định danh (1+20) mod 23 = 2, (1+21) mod 23 = 3, (1+22) mod 23 = 5. Successor của định danh 2 là node 3, nó chính là node đầu tiên theo sau 2 trên vòng tròn Chord; successor của định danh 3 chỉnh là node 3 và successcor của định danh 5 là node 0. 2.2.3. Node tham gia/ rời mạng và quá trình đồng bộ ( stabilization) Trong mạng Chord, mỗi node sẽ chạy định kỳ thuật toán đồng bộ mạng nhằm cập nhập bảng finger table và các thông tin về successor, predecessor của nó. Việc này sẽ giúp cho mạng Chord luôn hoạt động chính xác kể cả khi có node mới tham gia/rời mạng hay một node bị lỗi. Khi một node mới muốn tham gia vào mạng, nó sẽ trải qua các bước sau: ƒ Bước 1: Node mới sử dụng consistent hashing băm địa chỉ IP của chính nó để một định danh ID. ƒ Bước 2: Node mới gửi thông điệp join với định danh ID của nó cho một node nào đó đã tồn tại trên mạng – gọi là bootstrap node ƒ Bước 3: Bootstrap node sử dụng bảng finger table để tìm kiếm successor của định danh ID – successor(ID) và sau đó sẽ gửi kết quả tìm kiếm cho node mới. ƒ Bước 4: Sau khi biết được successor của mình, node mới sẽ gửi thông điệp cảnh bảo về việc gia nhập mạng của mình cho successor đó. Successor nhận được thông điệp cảnh báo đó nó sẽ trỏ đến predecessor mới là node mới gia nhập mạng. ƒ Bước 5: Node mới sử dụng thuật toán đồng bộ để cập nhập các thông tin về mạng. Thuật toán đồng bộ chạy định kỳ tại mỗi node Chord. Giả sử node A đang định kỳ chạy thuật toán đồng bộ. A sẽ yêu cầu successor của nó gửi thông tin về predecessor ( predecessor của successor của A). Nếu không có node nào join vào giữa node A và successor của A thì kết quả trả về chính là định danh của node A. Ngược lại nếu có một node mới join vào giữa node A và successor của nó thì kết quả trả về sẽ là định danh của node mới, từ đó node A có thể nhận biết được có node mới tham gia vào mạng. Và đến lần đồng bộ tiếp theo, node A sẽ gửi thông báo đến node mới, node mới sẽ cập nhập lại predecessor của nó trở thành node A. Quá trình một node Chord rời mạng diễn ra đơn giản hơn khi một node tham gia mạng. Trước khi rời mạng, node sẽ gửi toàn bộ dữ liệu của nó – các cặp (key - value) cho successor. Sau đó nó sẽ thông báo cho successor cập nhập lại predecessor và thông báo cho predecessor cập nhập lại successor. Cuối cùng node sẽ giải phóng các tài nguyên của nó và thoát khỏi mạng. Trong trường hợp, một node rời mạng không đúng theo quy tắc ( node bị lỗi) thì toàn bộ dữ liệu mà node đó nắm dữ sẽ bị mất và phải nhờ đến quá trình đồng bộ thì mạng mới phát hiện và khôi phục được lỗi. 2.3. Thuật toán truyền tin multicast dựa trên nền mạng Chord Một trong những vấn đề quan trọng nhất của multicast đó là tạo nhóm multicast, tham gia và rời nhóm. Thay vì liên lạc với Router để tham gia hoặc là rời nhóm multicast như IP multicast, tất cả các node muốn tham gia vào nhóm multicast sẽ hình thành một mạng phủ ( overlay network) . Trong trường hợp này mạng phủ chính là mạng Chord. Node nguồn khởi tạo mạng Chord. Các node trong nhóm multicast tham gia vào nhóm bằng cách kết nối vào mạng Chord mà node nguồn vừa tạo. Từ đó việc truyền multicast trở thành việc truyền broadcast trên toàn mạng Chord. Phần dưới đây mô tả chi tiết thuật toán truyền broadcast trong mạng Chord [8]. Thuật toán truyền tin broadcast trên mạng Chord Mô hình hệ thống và ký hiệu Chúng ta giả thiết hệ thống của chúng ta gồm tập hợp N node hình thành một mạng Chord và bảng finger tại mỗi node đã được cập nhập đầy đủ. Thuật toán phân tán được chạy trên mỗi node của hệt thống được miêu tả dưới dạng một “luật” có dạng sau: receive(Sender: Receiver: Message(arg1….argn)) action(s)… “Luật” này miêu tả sự kiện khi một node nhận được một thông điệp (Message) và hành động action(s) sẽ được gọi với sự kiện đó. Node gửi sẽ gọi lệnh send(Sender: Receiver: Message(arg1….argn)) để gửi một thông điệp cho node nhận. Khơi tạo một phiên broadcast Broadcast có thể được khởi tạo ở bất kỳ node nào nếu như lớp ứng dụng trên lớp đó yêu cầu. Đó là khi, một thực thể ứng dụng multicast tại node Q có thể yêu cầu node Q một thông điệp InitBroadCast(Info) với Info là một phần của thông tin cần được broadcast ví dụ như một phần của hình ảnh cần được gửi đi trong ứng dụng video streaming. Hình 11: Node Q ứng với định danh 0 khởi tạo broadcast và finger table của node 0 Trong hình 11, hành động của node Q với định danh là 0, khi nhận được yêu cầu gửi thông điệp InitBroadCast(Info) từ ứng dụng P: receive(P : 0 : InitBroadcast(Info)) send(0 : 2 : Broadcast(Info, 5)) send(0 : 5 : Broadcast(Info, 11)) send(0 : 11 : Broadcast(Info, 16)) send(0 : 16 : Broadcast(Info, 0)) Node Q sẽ hoạt động như gốc của một cây không lặp. Như trong hình 11, node Q thực hiện việc đó bằng cách gửi một thông điệp broadcast tới tất cả các hàng xóm của nó trong bảng finger table. Thông điệp Broadcast(Info, Limit) chứa đựng thông tin Info cần được broadcast và một tham số giới hạn Limit. Limit được sử dụng để hạn chế không gian chuyển tiếp gói tin của node nhận được gói tin. Limit của finger[i] chính là finger[i+1], ( 1 ≤ i ≤ M - 1) start int. succ. 1 [1, 2) 2 2 [2, 4) 2 4 [4, 8) 5 8 [8, 16) 11 16 [16, 32) 16 ….. với M là số entry trong bảng finger table. Giới hạn cho entry cuối cùng trong bảng finger table là một trường hợp đặc biệt khi Limit được đặt là định danh của chính node gửi gói tin. Xứ lý một thông điệp Broadcast Khi node Q nhận được một thông điệp Broadcast(Info, Limit) , node Q phải chịu trách nhiệm chuyển tiếp thông điệp cho cây con được xác định trong khoảng (Q, Limit). Node Q sẽ chuyển tiếp thông điệp cho bất cứ finger nào mà có định danh đứng trước Limit (nhỏ hơn Limit). Hơn nữa, khi chuyển tiếp cho mỗi finger, node Q sẽ áp đặt một giới hạn mới NewLimit để định nghĩa một cây con nhỏ hơn cho node nhận tiếp theo. NewLimit được xác định trong bảng finger table tương tự như tại node nguồn. Chú ý là, NewLimit chỉ được xác định khi NewLimit vẫn còn thuộc khoảng (Q, Limit). Hình sau đây mô tả luật khi một node nhận được một thông điệp broadcast (a) (b) Hình 12: (a)Hành động của các node khi nhận được gói tin broadcast (b)finger table của node 5 Trong hình 12, khi node 5 nhận được thông điệp Broadcast(Info, 11) từ node 0 thì nó sẽ gửi chuyển tiếp gói thông điệp đó cho node 7 với giới hạn Limit vẫn là 11. receive(0 : 5 : Broadcast(Info,11)) send(5 : 7 : Broadcast(Info, 11)) start int. succ. 6 [6, 7) 7 7 [7, 9) 7 9 [9, 13) 11 13 [13, 21) 13 21 [21, 37) 22 ….. Phản hồi (Reply) Việc phản hồi thông điệp broadcast nhận được phụ thuộc vào loại thông tin chứa đựng trong nó hoặc phụ thuộc vào yêu cầu của ứng dụng. Có 2 cách phản hồi đó là: (i) Gói tin phản hồi sẽ được gửi ngược lại theo cây broadcast đã được hình thành từ trước (ii) Gói tin phản hồi được gửi trực tiếp đến node nguồn của broadcast. Chương III: Xây dựng ứng dụng truyền tin video streaming multicast thời gian thực trên nền mạng ngang hàng có cấu trúc Chord 3.1. Mục tiêu và yêu cầu của việc xây dựng ứng dụng Hiện nay trên thế giới có rất nhiều ứng dụng truyền video streaming, hầu hết trong số chúng sử dụng mô hình khách – chủ (client – server) dựa trên unicast, tức là máy khách gửi yêu cầu đến máy chủ, máy chủ gửi dữ liệu cho từng máy khách sử dụng truyền tin unicast; hoặc có số ít ứng dụng video streaming sử dụng truyền tin IP multicast cho việc phân phát video cho người dùng ví dụ như Cisco IPTV. Các ứng dụng trên đều có nhược điểm của nó. Đó là, với mô hình khách – chủ dựa trên unicast đơn thuần thì máy chủ sẽ bị quá tải khi có quá nhiều người dùng, với IP multicast thì cần có những router hỗ trợ multicast. Ứng dụng được xây dựng trong khóa luận này phải đáp ứng được những yêu cầu sau: ƒ Tối ưu hóa băng thông của máy chủ, máy chủ không phải chịu tải quá nhiều khi số lượng người sử dụng tăng lên. Các máy khách chia sẻ tải cùng máy chủ. ƒ Xây dựng một phương thức truyền tin multicast tầng ứng dụng theo kiểu end- system ALM, không cần sự hỗ trợ của router hay proxy chuyên dụng. Việc tham gia vào cây multicast phải được diễn ra một cách nhanh chóng, dễ dàng. Cây multicast có khả năng khôi phục lỗi khi có một node bị lỗi. Thông tin để duy trì và điểu khiển cây multicast càng nhỏ càng tốt. ƒ Với đặc thù là một ứng dụng về video nên hình ảnh hiển thị tại máy khách phải tương đối rõ ràng không gây khó chịu cho người dùng. Với những yêu cầu trên, mục tiêu của khóa luận đặt ra là: ƒ Đưa ra giải pháp và thiết kế giao thức truyền video streaming. ƒ Xây dựng chương trình thử nghiệm dựa trên giải pháp và thiết kế được đưa ra. ƒ Cuối cùng, đánh giá chương trình đã xây dựng để kiểm tra xem ứng dụng có đạt được những yêu cầu đặt ra ban đầu hay không. 3.2. Ý tưởng Như đã trình bày ở những phần trên, giao thức Chord là một giao thức mạng ngang hàng có cấu trúc đơn giản và mạnh mẽ, lượng thông tin được truyền để duy trì mạng là thấp; Chord có cơ chế phục hồi khi một node hoặc nhiều node bị lỗi. Thuật toán truyền multicast trên nền Chord cũng rất đơn giản và hiệu quả. Chính vì vậy, truyền video streaming multicast được xây dựng trên nền mạng Chord. Giao thức UDP được sử dụng để truyền dữ liệu video. UDP có ưu điểm là truyền dữ liệu nhanh nhất có thể. Tuy nhiên nhược điểm của nó là không có cơ chế sắp xếp lại gói tin đến không đúng thứ tự. Ý tưởng được đưa ra ở đây là sử dụng thêm một số giải pháp trong giao thức RTP (Real-time Transport Protocol) – một giao thức hỗ trợ truyền ứng dụng thời gian thực như đánh số thứ tự gói tin [2]. 3.3. Thiết kế hệ thống Hình dưới đây mô tả các chứa năng của hệ thống. Hình 13: Các chức năng của hệ thống 3.3.1. Tạo cây multicast Giao thức Chord được sử dụng để tạo nhóm multicast. Qua trình tạo nhóm mulicast gồm các bước: ƒ Node nguồn khỏi tạo mạng Chord. ƒ Các node khác tham gia vào mạng Chord. ƒ Node nguồn sử dụng thuật toán truyền broadcast trên mạng Chord để tạo cậy multicast. Như trong ví dụ Hình 12(a) ta thu được cây multicast như hình dưới đây. Hệ thống truyền video streaming thời gian thực multicast nền Chord Tạo cây multicast Tạo dữ liệu video thời gian thực Xử lý và hiển thị hình ảnh Truyền hình ảnh Hình 14: Cây multicast thu được từ mạng Chord Nhìn vào hình 14 ta thấy được, cây multicast được xây dựng là cây lệch phải. Do các node ở cuối vòng tròn Chord thường có độ sâu lớn hơn nhiều so với các node ở đầu vòng tròn. Chính vì vậy, độ trễ tương đối của dữ liệu nhận được giữa các node là không đều nhau. Tuy nhiên, nếu hàm băm được xây dựng tốt thì có thể làm giảm đáng kể sự chênh lệch trên. 3.3.1. Tạo dữ liệu thời gian thực Trong ứng dụng video streaming, video có thể là các bản ghi sẵn từ trước hoặc có thể được bắt lấy trức tiếp theo thời gian thực với các thiết bị thu hình. Hệ thống đã sử dụng webcam để tạo dữ liệu thời gian thực. Hình ảnh sẽ được bắt lấy (capture) từ webcam theo những khoảng thời gian liên tiếp. Việc tính toán khoảng thời gian giữa 2 lần capture phụ thuộc vào nhiều yếu tố như băng thông mạng, khả năng xử lý của máy, chất lượng hình ảnh thu được. 3.3.2. Truyền hình ảnh Truyền hình ảnh là một trong những bước quan trọng nhất trong video streaming. Kỹ thuật truyền không tốt sẽ ảnh hưởng trực tiếp đến chất lượng của hình ảnh thu được. Thực chất việc truyền video stream là việc truyền một chuỗi liên tiếp các hình ảnh (frame). Mồi hình ảnh nguyên gốc thường có dung lượng lớn. Nén ảnh là giải pháp được nghĩ tới nhằm tối ưu hóa đường truyền, tiết kiệm băng thông. JPEG là một chuẩn nén ảnh mà chất lượng của hình ảnh không thay đổi nhiều so với nguyên bản. Với JPEG hình ảnh thu được có dung lượng giảm đáng kể. Do mỗi đường truyền mạng đều có một giá trị MTU ( Maximum Transmission Unit) giới hạn kích thước gói tin gửi trên đường truyền nên không thể gửi cả frame lên đường truyền cùng một lúc. Cách khắc phục duy nhất đó là phân mảnh frame ra thành cách gói tin nhỏ hơn đủ để truyền trên mạng. Việc này đòi hỏi cơ chế đánh số thứ tự cho từng gói tin nhàm đảm bảo các gọi tin sẽ được ghép theo đúng thứ tự tại bên nhận. 3.3.3. Xử lý và hiển hình ảnh Sau khi được phân mảnh tại máy gửi dữ liệu bắt đầu được gửi đến máy nhận. Trong quá trình gửi có thể có sự mất mát gói tin, hoặc các gói tin đến không theo đúng thứ tự. Chính vì vậy tại máy nhận có cơ chế sắp xếp lại gọi tin đến không đúng thứ tư, đồng sử dụng timeout để không phải chờ quá lâu gói tin bị mất. Để hỉnh ảnh hiện thị không gây khó chịu cho người dùng, các hình ảnh sau khi được ghép lại sẽ được lưu trong buffer và hiển thị trong những khoảng thời gian đều nhau. 3.4. Thiết kế giao thức 3.4.1. Giao thức máy chủ Quy trình hoạt động của máy chủ được biểu diễn dưới hình sau: ƒ Tạo nhóm multicast Máy chủ sử dụng hàm create() với địa chỉ IP và port để khởi tạo một mạng Chord. Máy khách sẽ liên lạc với máy chủ bằng địa chỉ IP và port được khai báo ở trên. ƒ Tạo dữ liệu thời gian thực Dữ liệu thực được tạo ra bằng cách bắt lấy (capture) hình ảnh thu được từ webcam trong những khoảng thời gian định kỳ. Với mỗi lần capture ta thu được một frame dưới dạng một chuỗi byte. ƒ Phân mảnh hình ảnh Đầu vào của quá trình phân mảnh là hình ảnh dưới dạng một chuỗi byte. Chuỗi byte đó sẽ được chia thành các phân nhỏ hơn để có thể gửi được trên mạng. ƒ Khởi tạo multicast Sau khi hình ảnh được phân mảnh thành các phần nhỏ, nó sẽ được thêm vào một số trước rồi đóng gói trong gói tin UDP và cuối cùng sẽ được gửi đi đến node phù hợp. Cấu trúc gói tin multicast tầng ứng dụng: Tạo nhóm multicast Hiển thị hình ảnh Khởi tạo multicast Phân mảnh frame Tạo dữ liệu thời gian thực LimitID ImageID NumberOfParts PartID Data - LimitID (8 byte) : ID giới hạn không gian chuyển tiếp gói tin tại node nhận - ImageID (2 byte): ID của ảnh capture từ webcam - NumberOfParts (2 byte): số lượng phần được chia ra từ ảnh - Data : một phần của ảnh được chia ra Theo thuật toán multicast đã được trình bày ở trên trong quá trình khởi tạo multicast, bảng finger table có bao nhiêu entry thì máy chủ sẽ phải gửi gói tin đến bấy nhiêu node, những entry giống nhau sẽ được gửi một lần duy nhất. Các entry trong finger table chính là lớp đầu tiền của cây multicast. 3.4.2. Giao thức máy khách ƒ Tham gia mạng Chord Mỗi node muốn tham gia vào quá trình nhận dữ liệu từ máy chủ thì bước đầu tiên là phải tham gia vào mạng Chord do máy chủ tạo ra. Hàm join() trong giao thức Chord được gọi khi một node muốn ra nhập mạng. Thông tin hệ thống yêu cầu là địa chỉ IP và cổng kết nối của máy chủ. ƒ Nhận gói tin Tham gia nhóm multicast Xử lý gói tin Chuyển tiếp gói Nhận gói tin Hiển thị hình ảnh Máy khách sẽ khởi tạo một cổng UDP để luôn luôn lắng nghe gói tin gửi đến từ máy chủ hoặc từ một máy khách khác. Khi nhận được gói tin thì một hàng đợi được sử dụng để lưu trữ gói tin phục vụ cho việc xử lý về sau. ƒ Chuyển tiếp gói tin Cứ mỗi khi nhận được một gói tin thì hàm decodePacket() được gọi để bóc tách gói tin và lấy về trường LimitID – quy định giới hạn chuyển tiếp. Sau đó gói tin sẽ được chuyển tiếp cho các finger trong bảng Finger table với ID trong khoảng ID từ chỉnh nó cho đến LimitID. Định dạng gói tin chuyển tiếp newLimitID imageID numberOfParts partID data - newLimitID là giới hạn mới được áp dụng cho node nhận tiếp theo - Các trường còn lại sẽ được dữ nguyên như khi gói tin được nhận ƒ Xử lý gói tin Do mỗi frame đều được phân mảnh tại nguồn nên tại máy khách cần thực hiện quá trình ghép các gói tin lại với nhau để tạo thành frame gốc. Quá trình đó được thực hiện bởi 2 lớp Image và ProccessImage. Giả sử ta nhận được gói tin với trường imageID là i, numberOfParts là n, partID là j. Quá trình ghép ảnh thực hiện theo nguyên tắc sau: - Nếu đây là lần đầu tiên nhận được gói tin với imageID là i thì khởi tạo danh sách Li có chiều dài bằng n và lưu gói tin mới nhận vào vị trí j trong danh sách. - Ngược lại, lưu gói tin vào vị tri j trong danh sách Li đã tồn tại từ trước, kiểm tra xem danh sách đã đầy hay chưa. Gọi hàm merge() để ghép các gói tin khi danh sách đầy hoặc khi hết thời gian timeout. Hình ảnh thu được sau khi ghép dưới dạng chuỗi byte sẽ được lưu vào hàng đợi phục vụ cho việc hiện thị. ƒ Hiển thị hình ảnh Để tránh hiện tượng hiển tượng tốc độ hình ảnh thay đổi một cách đột ngột, lúc quá nhanh, lúc quá chậm, thay vì hiển thị ngay lập tức hỉnh ảnh khi nó được nhận đủ thì hình ảnh đó sẽ được lưu vào hàng đợi cùng với thời gian bức ảnh đó được nhận đủ. Giả sử ta quy định cứ 150 ms thì hiển thị một hình ảnh, tức ≈ 7 hình/s. t1 t2 t3 t4 frame1 frame2 frame3 frame4 Hiện tại có 4 frame trong hằng đợi với t1, t2, t3, t4 lần lượt là thời gian các frame đó được nhận đủ. Ta có Δ1, Δ2, Δ3, Δ4 lần lượt là khoảng thời gian từ khi nhận được mảnh đầu tiền cho đến khi nhận được mảnh cuối cùng. Sau khi hiển thị frame1 ta sẽ đợi một khoảng thời gian là (150 – (t2 - t1 ) - Δ2 ) rồi tiếp tục hiển thị frame2. Tương tự với frame3 và frame4. Giá trị 150 có thể được thay đổi bằng các giá trị khác tùy thuộc vào từng loại mạng. 3.5. Thiết kế chương trình Chương trình gồm 4 lớp chính MessageHandler, Node và lớp WebcamServer triển khai tại máy chủ (Hình 15a) và lớp WebcamClient tại máy khách (Hình 15b). MessageHandler là lớp nền dùng để trao đổi tin cậy các thông tin điều khiển, quản lý mạng giữa các node với nhau. Node là lớp chính trong giao thức Chord. Node này chịu trách nhiệm triển khai các thuật toán giao thức trong Chord như tìm successor, thuật toán đồng bộ … Hai lớp Node và MessageHandler đã được xây dựng trong giao thức Chord nên sẽ không được trình bày dưới đây. WebcamServer và WebcamClient là 2 lớp ứng dụng, thực hiện trên nền giao thức Chord. Cụ thể WebcamServer và WebcamClient sử dụng bảng finger table của giao thức Chord để thực hiện định tuyến multicast giữa các node với nhau. (a) (b) Hình 15: (a) Cấu trúc chương trình máy chủ (b) Cấu trúc chương trình máy khách 3.5.1. Lớp WebcamServer Hình 16: Thuộc tính và các phương thức của lớp WebcamServer Lớp WebcamServer (Hình 16) là lớp duy nhất của ứng dụng truyền video multicast dựa trên nền Chord tại máy chủ. WebcamServer chịu trách nhiệm tạo luồng dữ liệu video thời gian thực. Cụ thể WebcamServer sẽ định kỳ bắt hình ảnh thu được từ webcam, sau đó tiến hành gửi broadcast trên toàn mạng Chord. Một số phương thức chính //Hàm khởi tạo //Tham số: // localNode: một thể hiện của lớp Node public WebcamServer(Node localNode) // Bắt lấy hình ảnh từ webcam // Hàm trả về hình ảnh dưới dạng chuỗi byte public byte[] captureImage() // Phân mảnh hình ảnh thu được ở hàm captureImage() thành những phần nhỏ // Giá trị trả về là danh sách các phần mảnh của hình ảnh public List fragmentImage(byte[] image) // Đóng gói gói tin tầng ứng dụng với các trường khác nhau // Tham số: // limitID: giới hạn chuyển tiếp dành cho node nhận // imageID: số thứ tự của bức ảnh // numberOfPart: số phần bị phân ra từ bức ảnh gốc // partID: số thứ tự của phân mảnh // fragment: dữ liệu của một phần bức ảnh // Hàm trả về gói tin tầng ứng dụng dưới dạng chuỗi byte public byte[] PacketToByte(long limitID, short imageID, short numberOfPart, short partID, byte[] fragment) // Hàm khởi tạo broadcast // Tham số: // image: chuỗi byte dữ liệu của hình ảnh // Hàm sử dụng thuật toán truyền broadcast để gửi hình ảnh cho các máy khách public void SendBroadcastImage(byte[] image) // Gửi một gói tin tầng ứng dụng cho một node // Tham số: // desIP: IP của node nhận // limitID: giới hạn chuyển tiếp dành cho node nhận // iID: số thứ tự của bức ảnh // part: dữ liệu của một phần bức ảnh // partID: số thứ tự của phân mảnh // numberOfPart: số phần bị phân ra từ bức ảnh gốc public void send(string desIP, long limitID,short iID, byte[] part, short partID, short numberOfPart) 3.5.2. Lớp WebcamClient (a) (b) (c) Hình 17: (a) Các thuộc tính (b) Các phương thức (c) Lớp lồng Tại mỗi node, lớp WebcamClient (Hình 17) thực hiện 2 công việc: xử lý và hiển thị luồng hỉnh ảnh thu được từ máy chủ, đồng thời chuyển tiếp hình ảnh cho các node khác. Một số phương thức quan trọng // Hàm khởi tạo // Tham số: // gui: giao diện chương trình // localNode: thể hiện của lớp Node public WebcamClient(MainForm gui, Node localNode) // Lắng nghe kết nối đến và lưu dữ liệu vào hàng đợi listReceivePackets public void receive() // Hàm xử lý gói tin nhận được public void processPacket() // Hàm lấy giá trị các trường từ gói tin nhận được // Tham số: // packet: gói tin nhận được dưới dạng chuỗi byte // limitID: lưu thông tin về giới hạn chuyển tiếp // imageID: lưu số thứ tự của frame // numberOfPart: lưu số phần của frame đó // partID: lưu số thứ tự của phân mảnh // fragmentImage: lưu dữ liệu của phân mảnh public void decodePacket(byte[] packet, ref long limitID, ref short imageID, ref short numberOfPart, ref short partID, ref byte[] fragmentImage) // Hàm đóng gói dữ liệu để gửi đi trên mạng // Tham số: // limitID: giới hạn chuyển tiếp // imageID: stt của frame // numberOfPart: số phân mảnh của frame // partID: stt của phân mảnh // fragment: dữ liệu phân mảnh // Hàm trả về dữ liệu dạng chuỗi byte để gửi qua mạng public byte[] PacketToByte(long limitID, short imageID,short numberOfPart, short partID, byte[] fragment) // Hàm hiển thị video public void show() // Hàm hiển thị từng hình ảnh // Tham số: // image: hình ảnh dạng chuỗi byte public void showRemoteWebcam(byte[] image) // Hàm gửi chuyển tiếp gói tin theo thuật toán multicast public void forwardPacket(long limitID, short imageID,short numberOfPart, short partID, byte[] fragmentImage) Khắc phục nhược điểm của UDP là không có cơ chế sắp xếp lại gói tin đến không đúng thứ tự, lớp WebcamClient đã sử dụng 2 lớp con Image và ProcessImage (Hình 18) để thực hiện việc đó. Lớp Image được sử dụng để lưu các mảnh của cùng một frame. Lớp ProcessImage thực hiện kiểm tra xem đã nhận đủ các phần chưa hoặc đã hết thời gian timeout chưa rồi tiến hành ghép các phần lại với nhau.  Hình 18: Lớp Image và lớp ProcessImage Chương IV: Kết quả đánh giá hệ thống 4.1. Kết quả thử nghiệm 4.1.1. Môi trường chạy thử Chương trình được chạy thử trên môi trường mạng LAN với tốc độ đường truyền trong điều kiện lý tưởng là 100 Mbps. Mỗi máy khách kết nối mạng qua cổng Ethenet tốc độ 100 Mbps, RAM 1 G, CPU 2.4 GHz. Máy chủ có cấu hình RAM 3G, CPU 2x2.4, kết nối Ethenet 100 Mbps. Quá trình chạy thử diễn ra nhiều lần với số lượng máy khách tăng dần bắt đầu với 2 máy và tối đa là 7 máy. 4.1.2. Kết quả đạt được Qua quá trình quan sát ta có thể thấy được từng hình ảnh hiển thị rõ nét, tuy nhiên về thời tốc độ hiển thị hình ảnh vẫn còn chậm ( số hình / s) chính vì vậy gây ra hiện tượng dật hình gây khó chịu cho người xem. 4.2. Kết quả đánh giá hiệu năng Với mô hình 7 máy tính cả máy chủ, ta có băng thông tiêu tốn của các máy đo được (số liệu trong bảng giá trị trung bình): Node ID Upload Download 3724 110 KB/s 110 KB/s 7620 0 110 KB/s 8598 (server) 0 330 KB/s 13347 110 KB/s 110 KB/s 15105 0 110 KB/s 19948 110 KB/s 110 KB/s 21901 0 110 KB/s Ta có dễ dàng nhận thấy rằng, server có trách nhiệm phải truyền video cho 6 máy mà bằng thông tiêu tốn chỉ là 330 KB/s. Nếu sử dụng phương pháp truyền tin unicast thông thường thì băng thông tiêu tốn phải là 660 KB/s. Chương V: Kết luận Trên thế giới, các ứng dụng mạng ngang hàng nói chung và multicast trên mạng ngang hàng đang được nghiên cứu và phát triển một cách mạnh mẽ. Nó sẽ và đang dần thay thế các mô hình mạng truyền thống như mô hình khách – chủ hay IP multicast. Trong khóa luận đã trình bày một cách ngắn gọn về cách thứ hoạt động của mạng ngang hàng, cụ thể là Chord để từ đó ta có thể thấy được những lợi thế của nó số với mô hình mạng truyền thống đó là khả năng phân tán, không phụ thuộc quá nhiều vào hạ tầng mạng phía dưới… Để làm rõ hơn ưu điểm của mạng ngang hàng, khóa luận đã xây dựng thử ứng dụng truyền video streaming multicast thời gian thực trên nền mạng Chord. Trong ứng dụng đã sử dụng webcam để tạo luồng dữ liệu thời gian thực, sử dụng Chord để tạo cây multicast. Qua bước đầu thử nghiệm trên mạng LAN ta có thể thấy được ưu điểm của nó là máy chủ không phải chịu tải quá nặng và việc truyền multicast hoàn toàn không phụ thuộc vào router. Tuy nhiên ứng dụng xây dựng vẫn còn một số nhược điểm, không có cơ chế mã hóa video, mới chỉ nén từng frame theo dạng JPEG, chính vì vậy tỷ lệ nén vẫn còn thấp. Một nhược điểm nữa là độ trễ giữa các node ở lớp dưới cây multicast so với các node ở lớp trên chênh lệch nhau khá nhiều. Hiện tại khi một node bị lỗi hoặc rời mạng, việc phục hồi cây multicast vẫn dựa vào giao thức đồng bộ được xây dựng trên giao thức Chord. Với việc giao thức này chỉ chạy định kỳ sẽ khiến cho quá trình khôi phục diễn ra chậm gây gián đoạn luồng video streaming trong khoảng thời gian dài. Với những kết quả đạt được và những mặt còn tồn tại của việc xây dựng ứng dụng, sau đây là một số hướng phát triền tiếp theo : ƒ Khắc phục những nhược điểm đã nêu ở trên. ƒ Xây dựng ứng dụng hôi thảo trực tuyến với nhiều nguồn phát muticast. Tài liệu tham khảo [1] [2] [3]  [4] [5] B. Zhao, K. Kubiatowicz, and A. Joseph, “Tapestry: An infrastructure for fault- resilient wide-area location and routing,” Tech. Rep. UCB//CSD-01-1141, University of California at Berkeley Technical Report, April 2001. [6] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan. “Chord: A scalable peer-to-peer lookup protocol for internet applications”. [7] Mojtaba Hosseini, Dewan Tanvir Ahmed, Shervin Shirmohammadi, and Nicolas D.Georganas. “A Survey of Application-Layer Multicast Protocols”. [8] Sameh El-Ansary, Luc Onana Alima, Per Brand, Seif Haridi Swedish Institute of Computer Science, Kista, Sweden IMIT-Royal Institute of Technology, Kista, Sweden. “Effcient Broadcast in Structured P2P Networks” [9] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker. “A Scalable Content-Addressable Network” [10] Wenwu Zhu, Member, IEEE, Dapeng Wu, Student Member, IEEE, Yiwei Thomas Hou, Member, IEEE, Ya-Qin Zhang, Fellow, IEEE, Jon M. Peha, Senior Member, IEEE. “Streaming Video over the Internet: Approaches and Directions”