Xay Dung Ung Dung Video Streaming Qua Mang p2p 9024 2

LÊ

NG

ỌC

AN

HD

09VT

2X

ÂY

DỰ

NG

ỨN

G D

ỤN

G L

UỒ

NG

VID

EO

STR

EA

MIN

GQ

UA

MẠ

NG

NG

AN

G H

ÀN

G

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNGKHOA VIỄN THÔNG 1

-------***-------

ĐỒ ÁN

TỐT NGHIỆP ĐẠI HỌC

Đề tài:

XÂY DỰNG ỨNG DỤNG LUỒNG VIDEO STREAMING QUA MẠNG NGANG

HÀNG

Ngƣời hƣớng dẫn : THS.VŨ THỊ THÚY

HÀ Sinh viên thực hiện : LÊ NGỌC ANH

Lớp : D09VT2

Khoá : 2009 - 2014

Hệ : ĐẠI HỌC CHÍNH QUY

Hà Nội, 12-2013

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA VIỄN THÔNG 1-------***-------

ĐỒ ÁN

TỐT NGHIỆP ĐẠI HỌC

Đề tài:

XÂY DỰNG ỨNG DỤNG LUỒNG VIDEO STREAMING QUA MẠNG NGANG HÀNG

Ngƣời hƣớng dẫn : THS.VŨ THỊ THÚY

HÀ Sinh viên thực hiện : LÊ NGỌC ANH

Lớp : D09VT2

Khoá : 2009 - 2014

Hệ : ĐẠI HỌC CHÍNH QUY

Hà Nội, 12-2013

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

Điểm: ........ (bằng chữ ………………..)

Ngày …. tháng 12 năm 2013

Giáo viên hướng dẫn

ThS. Vũ Thị Thúy Hà

Đồ án tốt nghiệp đại Mở

Lê Ng cọ Anh – 4

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

………………………………………………………………………

Điểm: ........ (bằng chữ ………………..)

Ngày …. tháng 12 năm 2013

Giáo viên phản biện



MỞ ĐẦU

Trong những ngày đầu phát triển của ứng dụng đa phương tiện, khoảng nửa cuối thập niên 90, việc xem một video trên mạng gần như là điều không thể. Ngày nay, cùng với sự bùng nổ của Internet, các ứng dụng đa phương tiện trong đó có video streaming đã trở thành nhu cầu không thể thiếu của nhiều cư dân mạng. Theo thống kê, riêng tại Mỹ đã có khoảng 33 tỉ video được xem trong tháng 12-2012 (nguồn comScore). Con số trên đủ cho ta thấy được sự lớn mạnh không ngừng của các ứng dụng video streaming.

Tuy nhiên, để phát triển một ứng dụng video streaming tốt gặp phải rất nhiều vấn đề. Ứng dụng video streaming đòi hỏi nhiều băng thông và yêu cầu độ trễ thấp. Chính vì vậy cần phải có một phương pháp phân phát video trên đường truyền hợp lý. IP multicast với khả năng tối ưu hóa đường truyền là một giải pháp cho vấn đề này. Tuy nhiên, việc triển khai IP multicast lại rất tốn kém bởi nó đòi hỏi toàn mạng phải có những Router đắt tiền, chuyên dụng. Điều này hoàn toàn không khả thi trong một mạng diện rộng như Internet. Triển khai multicast trên tầng ứng dụng với việc không làm thay đổi hạ tầng mạng phía dưới là một giải pháp thay thế hữu hiệu cho IP multicast.

Hiện nay, trên thế giới đã và đang phát triển rất nhiều phương pháp truyền tin multicast trên tầng ứng dụng khác nhau. Trong đó truyền tin multicast dựa mạng ngang hàng hứa hẹn có nhiều ưu điểm. Đặc thù của truyền tin multicast là phải tạo được một cây multicast tối ưu, có sự liên kết chặt chẽ giữa các node với nhau, có khả năng phục hồi lỗi nhanh. Mạng ngang hàng có cấu trúc hoàn toàn có thể đáp ứng được yêu cầu đó với việc các node được liên kết với nhau bằng một thuật toán cụ thể.

Để làm rõ hơn những lợi thế của mạng ngang hàng có cấu trúc trong việc truyền tin multicast, khóa luận này đã nghiên cứu xây dựng ứng dụng truyền video streaming multicast dựa trên nền tảng mạng ngang hàng có cấu trúc Pastry. Sau đây là tóm tắt nội dung khóa luận gồm 3 chương.

Chƣơng 1: Tổng quan về kỹ thuật Video StreamingTrong chương này giới thiệu khái quát về kỹ thuật Video Streaming. Cấu

trúc và chức năng của các thành phần trong hệ thống video streaming. Nêu ra các loại định dạng tập tin video phổ biến hiện nay. Trong chương I cũng đề cập đến vấn đề truyền tin multicast gồm truyền tin IP multicast và multicast lớp ứng dụng.

Chƣơng 2: Hệ thống luồng video qua mạng ngang hàng P2P



Trong chương này giới thiệu khái quát mạng ngang hàng P2P. Khái niệm về mạng P2P và các kiến trúc mạng của nó. Các mục tiêu, các thuận lợi, khó khăn trong mạng P2P. Trình bày các cách xây dựng lớp phủ cho truyền video streaming, nêu một số hệ thống phổ biến hiện nay đang được sử dụng trên mạng như NICE, CoopNet, HyPO…Nêu được các ưu nhược điểm của các hệ thống này.

Chƣơng 3: Xây dựng ứng dụng luồng video streaming qua mạng Pastry

Chương này chủ yếu mô tả quá trình gia nhập, rời nhóm, truyền tin multicast tới mạng và quá trình sửa cây multicast.

Phần kết luận: Tổng kết lại toàn bộ nội dung luận văn và đưa ra hướng phát triển tiếp theo.

Mặc dù đã cố gắng nhưng do kiến thức còn hạn chế, thời gian làm đồ án không nhiều, nên đồ án tốt nghiệp của em không thể tránh khỏi những thiếu sót về nội dung và hình thức. Do đó em rất mong nhận được sự góp ý của các thầy, cô giáo để bản đồ án của em được hoàn thiện hơn.

Đồ án tốt nghiệp đại Lời cảm


LỜI CẢM ƠN

Trước tiên, em muốn gửi lời cảm ơn sâu sắc nhất đến cô Vũ Thị Thúy Hà, người đã tận tình hướng dẫn em trong suốt quá trình hoàn thành khóa luận tốt nghiệp.

Em xin gửi lời cảm ơn chân thành sâu sắc nhất tới tất cả các thầy, cô giáo trường Học Viện Công Nghệ Bưu Chính Viễn Thông đã tận tình giảng dạy và giúp đỡ em trong suốt hơn 4 năm học vừa qua để em có đủ kiến thức để hoàn thành khóa luận này.

Tôi cũng xin gửi lời cảm ơn tới tất cả bạn bè D09VT2 của tôi, những người đã đồng hành cùng tôi trong suốt 4 năm học qua.

Cuối cùng, xin gửi lời tri ân đến bố mẹ và gia đình, những người thân yêu của tôi lòng biết ơn sâu sắc nhất.

Hà Nội, tháng 11 năm 2013

Sinh viên

Lê Ngọc Anh

Đồ án tốt nghiệp đại Mục


MỤC LỤC

MỞ ĐẦU........................................................................................................................1MỤC LỤC.....................................................................................................................8DANH MỤC HÌNH VẼ..............................................................................................10TÓM TẮT...................................................................................................................12CHƢƠNG I: TỔNG QUAN VỀ KỸ THUẬT VIDEO STREAMING.................13

1.1 Tổng quan video streaming.................................................................................13

1.1.1 Giới thiệu về Video Streaming.....................................................................13

1.1.2 Quá trình Video Streaming...........................................................................14

1.1.3 Kiến trúc hệ thống video streaming..............................................................14

1.2 Các loại tệp tin video...........................................................................................17

1.3 Hoạt động của hệ thống video streaming............................................................19

1.3.1 Kiến trúc hoạt động của một hệ thống Video Streaming..............................19

1.3.2 Mô hình hoạt động tổng quát của hệ thống..................................................21

1.4 Một số phương thức phân phối luồng video.......................................................22

1.4.1 IP multicast...................................................................................................23

1.4.2 Multicast lớp ứng dụng.................................................................................24

1.5 Kết luận chương 1...............................................................................................25

CHƢƠNG 2: HỆ THỐNG LUỒNG VIDEO QUA MẠNG NGANG HÀNG......262.1 Phân tích một số điểm còn tồn tại của kỹ thuật streaming truyền thống.............26

2.2 Mạng ngang hàng Peer-to-Peer...........................................................................26

2.2.1 Khái niệm......................................................................................................26

2.2.2 Ưu thế của mạng ngang hàng........................................................................27

2.2.3 Phân loại mạng ngang hàng..........................................................................27

2.2.4 Các vấn đề cần xem xét trong P2P streaming...............................................28

2.3 Các phương pháp tiếp cận xây dựng lớp phủ......................................................29

2.3.1 Phương pháp tiếp cận dạng cây....................................................................30

2.3.2 Các hệ thống luồng trực truyến dựa trên cây đơn luồng...............................31

2.3.3 Phương pháp tiếp cận dựa trên cây đa luồng................................................35

2.3.4 Các hệ thống luồng trực truyến dựa trên cây đa luồng.................................36

2.4 Phương thức tiếp cận dựa trên lưới.....................................................................37

Đồ án tốt nghiệp đại Mục


2.4.1 Các hệ thống luồng trực truyến phổ biến dựa trên lưới.................................39

2.5 Video theo yêu cầu trên P2P...............................................................................46

2.5.1 Hệ thống VoD dựa trên dạng cây................................................................47

2.5.2 Hệ thống VoD dựa trên lưới.........................................................................50

2.6 Kết luận chương 2...............................................................................................52

CHƢƠNG III: ỨNG DỤNG LUỒNG VIDEO STREAMING QUA MẠNG PASTRY.......................................................................................................................53

3.1 Giới thiệu về Pastry.............................................................................................53

3.2 Quá trình truyền tin multicast trong nhóm Scribe...............................................56

3.2.1 Chi tiết giải thuật...........................................................................................57

3.2.2 Quá trình gia nhập nhóm (join group):.........................................................58

3.2.3 Quá trình rời nhóm (leave group).................................................................59

3.2.4 Truyền tin multicast tới mạng.......................................................................59

3.2.5 Sửa cây multicast..........................................................................................60

3.3 Cải thiện Scribe bằng cấu trúc Splitstream.........................................................61

3.3.1 Giới thiệu SplitStream..................................................................................61

3.3.2 Cơ chế xây dựng luồng trong SplitStream....................................................62

3.4 Kết luận chương 3...............................................................................................64

KẾT LUẬN ĐỒ ÁN....................................................................................................65TÀI LIỆU THAM KHẢO..........................................................................................66

Đồ án tốt nghiệp đại Danh mục hình


DANH MỤC HÌNH VẼHình 1.1 Kiến trúc của hệ thống video streaming........................................................16Hình 1.2 Kiến trúc hoạt động của hệ thống..................................................................19Hình 1.3 Lược đồ hoạt động tổng quát.........................................................................21Hình 1.4 Lược đồ hoạt động trên Server ...................... Error! Bookmark not defined. Hình 1.5 Lược đồ hoạt động quản l Cache trên máy chủ Streaming ..................Error! Bookmark not defined.Hình 1.6 Các phương thức truyền tin trên mạng.........................................................23Hình 1.7 Thành phần của IP multicast..........................................................................23Hình 1.8 (a) IP multicast (b) Multicast lớp ứng dụng.................................................25Hình 2.1 Phân loại mạng ngang hàng..........................................................................27Hình 2.2 Các loại P2P Streaming.................................................................................29Hình 2.3 Mô hình cây đơn............................................................................................30Hình 2.4 Xây dựng lại cây Streaming(a)Peer 0 rời (b)Mô hình cây sau khi phục hồi 31 Hình 2.5 Giải pháp tập trung cho cấu trúc cây và duy trì cây.....................................31Hình 2.6 Sắp xếp các host trong NICE........................................................................32Hình 2.7 SpreadIt – một ứng dụng cây multicast xây dựng trên các Peer..................32Hình 2.8 SpreadIt–Kiến trúc phân lớp của một Peer...................................................33Hình 2.9 Ví dụ về ESM...............................................................................................34Hình 2.10 Tổ chức hành chính của Peer trongZigZag..................................................35Hình 2.11 Cây đa luồng trên cơ sở Streaming..............................................................35Hình 2.12 Streaming Media sử dụng nội dung CoopNet.............................................37Hình 2.13 Danh sách peer từ Tracker Server Hình 2.14 P2PliveVideo Streaming .. 37 Hình 2.15 Trao đổi dữ liệu thiết kế trong hệ thống dựa trên lưới.................................38Hình 2.16 Sơ đồ hệ thống của một nút Anysee............................................................40Hình 2.17 Kiến trúc cơ bản PPLive.............................................................................41Hình 2.18 Một sơ đồ hệ thống chung cho một nút DONet..........................................42Hình 2.19 GridMedia Kiến trúc Dựa trên MSOMP.....................................................43Hình 2.20 Hai lớp lưới/ cây che phủ trong mạng lai....................................................45Hình 2.21 Khung mTreebone (a) một lớp phủ lai (b) xử lý trạng thái nút...................46Hình 2.22 Cấu trúc trực tuyến trong CiqueStream.......................................................46Hình 2.23 Cấu trúc DirectStream..................................................................................49Hình 2.24 BASS: (a) Tổng quan hệ thống, (b)Mẫu khách hàng..................................51Hình 2.25 Phương pháp tiếp cận BiToS.......................................................................51Hình 3.1 Bảng định tuyến của nút 10233102 trong Pastry...........................................55Hình 3.2 Nút 10233102 gửi thông điệp m đến nút 33321220.....................................56Hình 3.3 Quá trình 1 nút gia nhập vào nhóm...............................................................58Hình 3.4 Truyền tin multicast trong nhóm Scribe........................................................59Hình 3.5 Quá trình tự sửa câymulticast........................................................................60Hình 3.6 Một ví dụ đơn giản minh họa cách tiếp cận của SplitStream........................62Hình 3.7 Splitstream F luồng........................................................................................62Hình 3.8 Xác định nút cha khi băng thông đi ra vượt quá giới hạn..............................63


Đ ánồ t tố nghiệp đ iạ h cọ Thu tậ ngữ vi tế t tắ

THUẬT NGỮ VIẾT TẮT

Từ viết tắt Tiếng Anh Tiếng Việt

ALM Application Layer Multicast Multicast lớp ứng dụng

BASS BitTorrent Assisted Streaming System

DHT Distributed Hash Table Bảng băm phân tán

HTTP Hypertext Transfer Protocol Giao thức chuyển tải siêu văn bản

ID Indentity Số nhận dạng

I/O Input/Ouput Đầu vào/Đầu ra

IP Internet Protocol Giao thức mạng Internet

LAN Local Area Network Mạng cục bộ

P2P Peer – to – Peer Mạng ngang hàng

QoS Quality of Service Chất lượng dịch vụ

RTSP Real Time Streaming Protocol Giao thức điều khiển phiên

TCP Transmission Control Protocol Giao thức điều khiển truyền dẫn

UDP User Datagram Protocol Giao thức lớp giao vận

VoD Video on Demand Video theo yêu cầu

Đồ án tốt nghiệp đại Tóm


TÓM TẮT

Thời gian gần đây, cùng với sự phát triển của các ứng dụng đa phương tiện trên mạng Internet, video streamig qua Internet ngày càng thu được sự quan tâm của nhiều người, đặc biệt là các ứng dụng video streaming thời gian thực. IP multicast là giải pháp hiệu quả nhất cho yêu cầu này. Tuy nhiên, việc triển khai IP multicast trên mạng diện rộng gặp nhiều vấn đề khó khăn. Do vậy, nhiều nghiên cứu đã chuyển sang hướng nghiên cứu về các ứng dụng multicast lớp ứng dụng. Nhiều giải pháp multicast lớp ứng dụng đã được đưa ra. Tuy chúng có những yêu điểm riêng, xong vẫn chưa đáp ứng được hầu hết các yêu cầu của P2P streaming thời gian thực, ví dụ như sự ra vào của các nút, độ trễ còn lớn. Hơn nữa, các giải pháp này chưa xét đến vấn đề của các nút không đóng góp.

Luận văn mô tả chi tiết giao thức mạng ngang hàng có cấu trúc Pastry và cách thức tuyền tin multicast trên nền mạng ngang hàng Pastry. Trong khóa luận, vấn đề truyền video streaming được đề cập đến. Từ đó khóa luận xây dựng nên ứng dụng truyền video streaming multicast trên nền Pastry. Việc đánh giá kết quả thu được qua quá trình xây dựng cho ta thấy được những ưu điểm của việc triển khai multicast trên mạng ngang hàng, cũng như những nhược điểm cần khắc phục.

Đồ án tốt nghiệp đại Chương I: Tổng quan về kỹ thuật video


CHƢƠNG I: TỔNG QUAN VỀ KỸ THUẬT VIDEO STREAMING

1.1 Tổng quan video streaming

1.1.1 Giới thiệu về Video StreamingVideo 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 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 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. 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 đó thông qua Internet. Video Streaming thường được sử dụng trong lĩnh vực giải trí hoặc dạy học, dùng để lưu trữ các tập tin Video hoặc các bài học, cung cấp cho người dùng các tiện ích như tìm kiếm, liệt kê và khả năng hiển thị hoặc hiển thị lại các dữ liệu Video theo yêu cầu.Với các định dạng tập tin Video truyền thống, dữ liệu chỉ có thể hiển thị khi đã được tải về (download) toàn bộ, vì vậy đối với các tập tin Video chất lượng cao có dung lượng lớn thì công việc này sẽ tiêu tốn rất nhiều thời gian.

Video Streaming tiết kiệm thời gian cho người dùng bằng cách sử dụng các công nghệ giải nén kết hợp với hiển thị dữ liệu đồng thời trong lúc vẫn tiếp tục tải video về. Quá trình này được gọi là kỹ thuật đệm (buffering):

Thay vì được gửi một lần duy nhất, dữ liệu video streaming sẽ được chia thành từng gói nhỏ, sau đó liên tục truyền những phần được chia ra.

Ban đầu bên nhận sẽ lấy về một phần chia nhỏ của dữ liệu Video và hiển thị những phần video đã nhận được, đồng thời trong lúc hiển thị các gói dữ liệu còn lại sẽ lần lượt được lấy về để kịp cho việc hiển thị tiếp theo.

Video Streaming được thể hiện dưới hai dạng:

Video theo yêu cầu (on demand): là các dữ liệu Video được lưu trữ trên máy chủ đa phương tiện và được truyền đến người dùng khi có yêu cầu, người dùng có toàn quyền để hiển thị cũng như thực hiện các thao tác (tua, dừng, quay lại…) với các đoạn dữ liệu này.

Video thời gian thực (live event): là các dữ liệu Video được biến đổi trực tiếp từ các nguồn cung cấp dữ liệu theo thời gian thực (máy camera, microphone, thiết bị phát dữ liệu Video…).



1.1.2 Qu tr nh Video Streaming

Với Video Streaming máy tính của người sử dụng không phải tải toàn bộ Video về cùng một lúc. Để thực hiện tăng tốc độ lần tải về, tại bất kỳ thời điểm nào máy tính chỉ cần tải về một phần thông tin của Video. Với kỹ thuật này, chúng ta cần một máy chủ đặc biệt kiểm soát việc cung cấp các nội dung Video, để bất kỳ phần nào của đoạn Video được lưu trữ trên máy chủ đều có thể được truy cập bất kỳ lúc nào.

Video Streaming:

True Streaming: tín hiệu Video đến theo thời gian thực và hiển thị ngay lập tức cho người xem.

Download and Play: Sau khi tải toàn bộ Video về, sau đó phát Video. Progressive Download and Play: Đây là công nghệ lai giữa hai công nghệ

trên. Trong công nghệ này, Video sẽ được chia nhỏ ra thành nhiều frame, chương trình phát Video (player) sẽ hiện thị ngay những gói vừa được tải về và lưu trữ dữ liệu đó ở bộ nhớ đệm của máy. Khi tua lại những đoạn Video mà đã tải về, Player sẽ lấy dữ liệu từ bộ nhớ đệm để tải lên.

Video Streaming sử dụng các giao thức RTSP, MMS, HTTP… để truyền dữ liệu theo dạng luồng qua mạng Internet, đồng thời sử dụng các chuẩn nén để giảm dung lượng dữ liệu, cung cấp khả năng nén dữ liệu tại nhiều mức nén, nhiều kích thước hiển thị để có thể phù hợp với độ rộng băng thông của nhiều mạng truyền dẫn để tối ưu hoá việc truyền dữ liệu qua mạng. Cũng chính vì vậy việc truyền các Video Streaming qua mạng sẽ phụ thuộc rất nhiều vào các sản phẩm phần mềm máy chủ luồng Video. Hiện nay, có rất nhiều chuẩn công nghệ Video streaming. Cũng như có nhiều định dạng dữ liệu riêng với các chuẩn cộng nghệ đó. Các định dạng Video streaming chỉ giới hạn bởi các công ty dẫn đầu trong công nghệ streaming: Các hãng này đều cung cấp các bộ công cụ trọn gói gồm máy chủ luồng video (lưu trữ, truyền phát dữ liệu theo các giao thức hỗ trợ ...), Video Playe (hiển thị dữ liệu tại phía người dùng), và công cụ kiến tạo dữ liệu với các chuẩn nén.

1.1.3 Kiến trúc hệ thống video streaming

1.1.3.1 Kiến trúc và chức năng c c thành phần

Một hệ thống video thường bao gồm 6 khối, như minh họa trong hình 1.1. Trong hình 1.1 video và âm thanh gọi là dữ liệu thô được nén bằng cách sử dụng các thuật toán nén video và âm thanh rồi sau đó được lưu trong thiết bị lưu trữ . Theo yêu cầu từ khách hàng, một máy chủ streaming sẽ lấy video và âm thanh nén dữ liệu trong các thiết bị lưu trữ và sau đó cùng với lớp ứng dụng QoS là mô-đun kiểm soát điều chỉnh các video và âm thanh thành các luồng bit theo tình trạng mạng lưới và các yêu cầu QoS. Sau đó sử dụng các giao thức truyền tải nén các chuỗi bit rồi gửi các gói tin video và âm thanh qua mạng Internet. Gói có thể bị giảm hoặc hoặc bị trễ quá mức trong mạng Internet do tắc nghẽn, các gói tin có thể bị hư hỏng do bị lỗi bit. Để nâng



cao chất lượng truyền video và âm thanh được truyền liên tục, dịch vụ phân phối được triển khai trên mạng Internet cho các gói tin được gửi đến người nhận, sử dụng giao thức RSTP đi qua các lớp vận chuyển và sau đó được xử lý bởi lớp ứng dụng trước khi được giải mã ở các bộ giải mã video và âm thanh. Để đồng bộ hóa giữa video và âm thanh , các cơ chế đồng bộ truyền thông được yêu cầu.

Từ hình 1.1 ta có thể thấy 6 khối này liên quan rất chặt chẽ với nhau và chúng là thành phần thống nhất của kiến trúc 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 để đạt được hiệu quả tốt nhất về 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 nhằm đáp ứngtheo yêu cầu của từng người sử dụng, nhiều kỹ thuật điều khiể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à kiểm soát lỗi. Điều khiển tắc nghẽn được sử dụng để ngăn ngừa mất gói dữ liệu và giảm trễ để kiểm soát lỗi, mặt khác còn nhằm để cải thiện chất lượng trình chiếu video khi không có phần dữ liệu của gói tin bị mất.

Dịch vụ phân phát video trên đƣờng truyền. Để cung cấp các dịch vụ đa phương tiện có chất lượng tốt, sự hỗ trợ của mạng là quan trọng. Điều này cho thấy do có sự hỗ trợ của mạng mà từ đó có thể giảm trễ khi truyền tải và giảm tỷ lệ mất gói tin. Được xây dựng trên nền của Internet (giao thức IP), dịch vụ phân phối video trên đường truyền cho phép đạt được QoS (chất lượng dịch vụ) và hiệu quả cao cho việc phân phát video qua mạng Internet.

M y chủ streaming. Máy chủ Streaming đóng một vai trò quan trọng trong việc cung cấp các dịch vụ trực tuyến. Để cung cấp các dịch vụ trực tuyến chất lượng, các máy chủ streaming được yêu cầu phải xử l dữ liệu video với sự ràng buộc về thời gian, hạn chế thời gian trễ và hỗ trợ hoạt động kiểm soát tương tác như tạm dừng (pause), tua (fast forword) tiếp tục, nhanh chóng chuyển tiếp và nhanh chóng quay lại. Một máy chủ streaming thường bao gồm ba hệ thống con: một hệ thống kết nối giao tiếp (ví dụ, giao thức vận chuyển), một hệ điều hành, và một 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 cho video streaming. Giao thức được thiết kế và chuẩn hóa cho truyền thông giữa khách hàng và các 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ư Use Datagram Protocol (UDP) và giao thức điều khiển phiên như Real – time Streaming Protocol (RTSP).



1.1.3.2 Cache

Hình 1.1 Kiến trúc của hệ thống video streaming

Với những hệ thống máy chủ trình chiếu Video trực truyến hoặc cung cấp cho việc tải về theo yêu cầu người dùng đang được sử dụng hiện nay, thì với mỗi yêu cầu của người dùng đến – sẽ được máy chủ xử l thông tin đảm bảo yêu cầu tải đó là hợp lệ để thiết lập kết nối. Tiếp sau đó, nó sẽ truy xuất đến ổ cứng (hoặc thiết bị lưu trữ cục bộ) để truy xuất tập tin yêu cầu đó và gửi về cho người dùng. Như chúng ta đều biết tốc độ truy xuất ổ cứng thường khá chậm. Bên cạnh đó, có những tập tin được nhiều dùng cùng quan tâm trong một thời điểm (sai khác nhỏ về thời gian), việc truy xuất ổ cứng liên tục để truy xuất cùng một tập tin như cách làm việc hiện tại là rất lãng phí và tốn kém cho máy chủ.

Để giải quyết vấn đề này, ta đưa ra giải pháp sử dụng Cache. Cache được hiểu theo nghĩa thường là nơi lưu trữ dữ liệu năm chờ phần cứng xử lý, nhằm mục đích tăng tốc độ xử lý. Cache có thể là một vùng lưu trữ của bộ nhớ chính hoặc một thiết bị lưu trữ tốc độ cao độc lập. Có rất nhiều loại Cache được biết đến hiện nay với những chức năng khác nhau như: Cache của CPU, Caching của Internet Browser, Caching của Oracle…Cụ thể ở đây ta quan tâm đến một cơ chế xử lý Video Caching ngay trên máy chủ thay thế cho Web Caching quá tải hiện nay. Việc đầu tư cho thiết bị Cache cộng với việc có một giải pháp quản lý Cache hiệu quả sẽ giảm tải rất nhiều cho máy chủ.

Cách thức hoạt động thông qua Cache:

Dữ liệu được truy xuất từ ổ cứng được đẩy lên Cache. Với mỗi yêu cầu từ người nhận gửi tới, máy chủ sẽ tìm kiếm dữ liệu đã tồn tại

trên Cache chưa, để thực hiện đẩy dữ liệu đó lên Cache, nếu tồn tại thì dữ liệu từ Cache thông qua quá trình xử l dữ liệu sẽ được truyền trực tiếp đến người



dùng thông qua quá trình xử l dữ liệu sẽ được truyền trực tiếp đến người dùng thông qua một luồng tin (bỏ qua giai đoạn truy xuất từ ổ cứng).

Cơ chế để quản l dữ liệu trên Cache, quyết định dữ liệu nào được đưa vào Cache hoặc loại bỏ ra khỏi Cache, chúng ta phải thông qua việc phân tích thông tin truy xuất dữ liệu, cùng với thử nghiệm những số liệu thực thực tế để đưa ra một giải thuật quản l Cache hợp l .

1.2 C c loại tệp tin video

Các tập tin Video thường thuộc 2 loại: codec và không codec. Một số định dạng tập tin, chỉ cần nhìn vào đuôi tập tin ta biết được loại codec mà tập tin đó sử dụng như: WMV, RM, MOV… Hoặc các loại đuôi tập tin không chỉ định chính xác loại codec nào như: MP4, AVI, MKV… Các loại tập tin trên đều là các hộp đựng (container) để chứa nội dung, chúng ta thường phải sử dụng các trình media player để mở và đọc các tập tin đó. Để biết tập tin đó sử dụng loại codec nào để mã hóa. Ta xem xét một số loại định dạng tập tin mà các website và các nhà cung cấp lớn thường hỗ trợ:

Định dạng Giới thiệu

3GP –

3GPPMultimedia

Định dạng 3GP là định dạng Video được phát triển bởi dự án 3rd Generation Partnership dựa trên chuẩn MPEG-4. Được sử dụng cho các tập tin đa phương tiện trên mạng không dây 3G tốc độ cao, sử dụng phổ biến trên điện thoại có hỗ trợ quay phim.

ASF –

Advanced Systems Format

Định dạng ASF được Microsoft phát triển. Định dạng này được dùng để truyền tải các tập tin đa phương tiện chứa văn bản, đồ họa, âm thanh, Video. Tập tin ASF chủ yếu là tập tin Windows Media Audio và Windows Media Video.Tập tin ASF chỉ đặc tả cấu trúc của tập tin video hay âm thanh được truyển tải mà không chỉ rõ phương pháp mã hóa.



AVI –

Audio Video Interleave

Định dạng AVI cũng được phát triển bởi Microsoft và chứa dữ liệu được mã hóa theo các codec khác nhau (có thể dùng các codec như DivX để mã hóa tập tin AVI). Định dạng AVI bao gồm hai loại định dạng chính DivX, Xvid. Đây là một định dạng rất phổ biển hiện nay. AVI là một sản phẩm của RIFF. Dữ liệu của tập tin được chia trong các khối, mỗi khối được xác định bởi một nhãn. Khối đầu tiên chứa dữ liệu về Video, những thông tin về chiều dài, chiều rộng, tỷ lệ khung. Khối thứ 2 chứa dữ liệu thật sự của tập tin AVI. Khối thứ 3 chứa các chỉ mục của các khối dữ liệu trong tập tin.

FLV –

Flash Video

Flash Video là một định dạng Video thường được dùng cho những website chia s như Youtube hoặc những website chiếu phim trực tuyến, được phát triển bởi Adobe System (Macromedia). Hỗ trợ 2 loại định dạng FLV và F4V.Flash Video: nội dụng nhúng trong tập tin SWF và phần mở rộng FLV chứa thông tin tập tin.Định dạng này có chất lượng chấp nhận được, trong khi kích thước tập tin nhỏ, nên rất hiệu quả trong môi trường Internet. Phù hợp với hệ thống trình chiếu Video trực tuyến nói chung và hệ thống dạy học bằng Video nói riêng.

MP4 – MPEG-

4Video

Định dạng MPEG-4 là một tiêu chuẩn được phát triển bởi Moving Picture Experts Group, được sử dụng trên rất nhiều điện thoại và các thiết bị chơi Video (còn gọi là thiết bị chơi MP4).

MOV –

Apple QuickTime Movie

QuickTime Movie là định dạng được Apple phát triển. Cũng là một định dạng thường được sử dụng trên Internet.

RM –

Real Media

Real Media là định dạng được phát triển bởi RealNetworks. Real Media chứa cả thông tin về Video (Real Video) và âm thanh (Real Audio). Thường được dùng để truyền tải các tập tin đa phương tiện thông qua internet.



VOB –

DVD Video Object

Định dạng VOB liên quan đến DVD Video Movie File. Một tập tin VOB thường chứa các luồng đa công (multiplex) gồm: Video, âm thanh và phụ đề.

WMV-

Windows Media Video

Windows Media Video là một định dạng tập tin thường gặp nhất cũng được phát triển bởi Microsoft. Tập tin Windows Media chứa Video được mã hóa theo bộ codec Windows Media Video và âm thanh được mã hóa theo codec Windows Media Audio codec.Tập tin WMV được thiết kế dùng cho ứng dụng luồng (thread) trên Internet. Dung lượng tập tin WMV khá thấp nên dễ dàng truyền tải trên mạng, tuy nhiên chấp lượng hình ảnh và âm thanh không thực sự tốt.

1.2 Hoạt động của hệ thống video streaming

1.3.1 Kiến trúc hoạt động của một hệ thống Video StreamingMột hệ thống Video treaming hoạt động chủ yếu gồm 3 thành phần: Web server,

Server và Client.

Hình 1.2 Kiến trúc hoạt động của hệ thống



Web server Web Server là máy chủ có dung lượng lớn, tốc độ cao, là nơi lưu trữ thông

tin về các website có cung cấp dịch vụ chia s video trực tuyến (những Website này nhúng mã embeded flash player do nhà cung cấp dịch vụ lưu trữ và quản l tập tin cung cấp) cùng với những thông tin liên quan khác.

Khi máy chủ Web nhận yêu cầu từ máy khách về việc xem một video có trong danh sách video mà Website cung cấp, thì nó sẽ gửi về máy khách: đoạn mã html tĩnh chứa tập tin embeded flash và tập tin xml chứa thông tin của video đó.

Server Server là một máy chủ gồm có: Ổ cứng (Hard disk) chứa dữ liệu và máy

chủ quản l dùng quản l quá trình kết nối của các máy khách (thông qua một cổng nhất định).

Hard Disk: Ổ cứng lưu trữ tập tin video của nhà cung cấp. Server Manager:o Tạo máy chủ với cổng được lựa chọn, chờ người dùng kết nối tới.o Quản l người dùng kết nối dựa trên IP.o Quản l những tập tin video đã được đưa vào cache.o Quản l việc lựa chọn gửi phần nào của tập tin video về cho người dùng.

Máy chủ Video Streaming:oKhi nhận được yêu cầu từ phía người dùng lấy một tập tin video, máy chủ

Video Streaming tìm tập tin đó dưới ổ cứng và đẩy vào thiết bị Caching.oTại thiết bị Caching, tập tin video được cắt ra thành nhiều gói nhỏ để lưu

trữ.oSau đó từng gói của tập tin video sẽ được đưa qua một cơ chế nén và mã

hóa trước khi gửi về người dùng.(3) Client

Truy cập vào web browser, chọn tập tin video cần xem và bấm play, lệnh yêu cầu play tập tin video sẽ được gửi lên máy chủ Web.(1)

Web browser sẽ nhận software player (trong đoạn mã html tĩnh chứa tập tin embeded flash) và thực hiện kết nối với server.(2)

Software player nhận những video stream và thực hiện việc giải nén, giải mã trước khi hiển thị Video lên cho người dùng.

Tóm lại:

Web Server: trả về người dùng đoạn html tĩnh, nội dung tập tin chứa embeded flash.

Server: lưu trữ tập tin video, gửi tập tin video được yêu cầu về người dùng. Client: nhận thông tin từ máy chủ Web và kết nối đến máy chủ (với thông tin

nhận được từ máy chủ Web tương ứng về tập tin video đã chọn).



1.3.2 Mô h nh hoạt động tổng qu t của hệ thống

H nh 1.3 Lƣợc đồ hoạt động tổng quát

Từ hình 1.3 ta có mô hình hoạt động chi tiết bên phía Server

H nh 1.4 Lƣợc đồ hoạt động trên Server



H nh 1.5 Lƣợc đồ hoạt động quản lý Cache trên máy chủ Streaming

1.4 Một số phƣơng thức phân phối luồng video

Trong hệ thống mạng của chúng ta hiện nay có 3 cách truyền video cở bản đó là unicast, multicast và broadcast (hình 1.6).

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, FPT…Nhưng với những ứng dụng đòi hỏi phải truyền tin từ một nguồn tới 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 một – nhiều (one – to – many), tức là dữ liệu được gửi từ một nút nguồn và một nhóm nút đích sẽ nhận được cùng dữ liệu đó. Các 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 2 người.

Broadcast: được mô tả như truyền 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ụ như 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). Giao thức lớp mạng 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 video đế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 nút trong nhóm. Tuy nhiên, với cách này thì nút nguồn sẽ phải lặp đi lặp lại việc truyền một gói video cho rất nhiều các nút khác nhau, dẫn đến việc tiêu tốn tài nguyên của nút nguồn (CPU, memory…). Đồng thời sẽ có rất nhiều gói video 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à nút đầu cuối (end – host) hoặc có thể là các router. Điều này tùy thuộc vào các công nghệ multicast khác nhau. Thay vì việc nút nguồn nhân bản gói tin và gửi đến từng nút trong nhóm thì nó chỉ truyền cho một hoặc vài nút nhất định và các nút này có nhiệm vụ sao chép và truyền gói tin theo cây multicast.

H nh 1.6 C c phƣơng thức truyền tin trên mạng

1.4.1 IP multicast

Ip multicast là chuẩn mở của IETF (Internet Engineering Task Force) 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à nút 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 nút ứng dụng. Ở đây, các nút này sẽ đóng vai trò là ngọn của cây.

Hình 1.7 Thành phần của IP multicast



Trong IP multicast, mỗi nút sẽ gửi yêu cầu một router gắn với nó khi muốn gia 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.

IP multicast là giải pháp hiệu quả nhất cho các kỹ thuật video streaming qua Internet và các ứng dụng video streaming thời gian thực. Với kiến trúc IP Multicast đang sử dụng hiện này để triển khai trên hệ thống mạng Internet đang thực sự gặp các vấn đề khó khăn:

Khi triển khai trên hệ thống lớn như Internet, các router phải lưu trữ rất nhiều trạng thái của các nhóm. Đây thực sự là một vấn đề lớn khi số nhóm tăng lên cao.

Tạo và duy trì một cây multicast mất rất nhiều tài nguyên và thời gian. Khi có quá nhiều kết nối hoặc một nút mạng không hoạt động sẽ gây ra rới

mạng và phải sửa chữa lại nhiều phần của cây. Việc cân bằng tải và định tuyến lại cây chưa được xử l thật tốt.

Vấn đề lớn nhất của việc triển khai IP Multicast là chi phí để thay thế lại hạ tầng mạng đã được xây dựng là cực kỳ lớn. Do vậy, nhiều nghiên cứu đã chuyển sang hướng nghiên cứu về các ứng dụng multicast lớp ứng dụng, nhằm khắc phục những nhược điểm trên.

1.4.2 Multicast lớp ứng dụng

Do nhu cầu sử dụng truyền thông multicast đang ngày càng lớn, trong khi giao thức IP multicast ở tầng mạng chưa đủ để đáp ứng, do vậy xu hướng multicast ngày càng được mở rộng sang multicast lớp ứng dụng. Multicast lớp ứng dụng không thay đổi và phá vỡ hệ thống mạng. Thay vào đó, nó chỉ thực hiên chức năng truyền multicast trên các máy cuối ở lớp ứng dụng. Từ lớp ứng dụnga sẽ truyền xuống các lớp mạng và lớp giao vận. Ở các lớp thấp hơn, cơ chế hoàn toàn không thay đổi.

Khái niệm multicast lớp ứng dụng chỉ đơn giản là việc thi hành multicasting như một dịch vụ lớp ứng dụng chứ không phải như một dịch vụ lớp mạng. Hình 1.8 mô tả việc truyền tin multicast cho cùng một nhóm người nhận và người gửi của multicast lớp ứng dụng và IP multicast. Ở đây, cây multicast được hình thành ở lớp ứng dụng. Với việc chỉ sử dụng phương thức truyền tin unicast của lớp mạng, nút 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 1.8 (a) IP multicast (b) Multicast lớp ứng dụng

Khi truyền multicast ở lớp ứng dụng, các gói tin không được nhân bản tại các bộ định tuyến giống như mô hình multicast nguyên thủy (IP multicast) mà việc nhân bản gói tin sẽ được thực hiện tại các máy đầu cuối. Về mặt logic, các máy đầu cuối tạo nên một mạng phủ và giao thức truyền thông multicast phải xây dựng và duy trì việc truyền multicast trên mạng phủ này. Trong multicast lớp ứng dụng, các công việc điều khiển như gia nhập nhóm, rời khỏ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). Do đó, nó không đòi hỏi sự hỗ trợ của các nút trung gian như bộ định tuyến hoặc máy chủ chuyên dùng.

1.5 Kết luận chƣơng I

Trong chương này giới thiệu tổng quan kỹ thuật luồng video từ khái niệm, quá trình hoạt động cũng như cấu trúc và chức năng của các thành phần trong hệ thống video streaming. Nêu ra các loại định dạng tập tin video phổ biến hiện nay. Trong chương 1 cũng đề cập đến vấn đề truyền tin multicast gồm truyền tin IP multicast và multicast lớp ứng dụng. Qua nghiên cứu, tôi nhận thấy: Tầm quan trọng của giao thức multicast lớp ứng dụng trong việc truyền video streaming. Cũng như công nghệ streaming video phát triển rất nhanh, các nhà nguyên cứu và phát triển dường như rất hứng thú trong lĩnh vực này. Chúng ta có thể hoàn toàn hy vọng chất lượng của video streaming đạt được mức chất lượng TV truyền thống, thậm chí bằng cả chất lượng DVD.

Đồ án tốt nghiệp đại Chương II: Hệ thống luồng video qua mạng ngang hàng


CHƢƠNG II: HỆ THỐNG LUỒNG VIDEO QUA MẠNG NGANG HÀNG P2P

2.1 Phân tích một số điểm còn tồn tại của kỹ thuật streaming truyền thống

Kỹ thuật streaming truyền thống dựa trên hệ thống Client - Server cung cấp hiệu suất tốt và tỷ lệ sẵn sàng cao nếu số lượng khách hàng được giới hạn. Tuy nhiên, việc triển khai và chi phí bảo trì của các hệ thống này thường rất cao. Ước tính hiện tại cho chi phí của YouTube là 1 triệu USD mỗi ngày và các chi phí có thể tăng lên nhanh nếu nhiều video tiếp tục được chuyển sang chất lượng cao hơn. Trong thực tế, nhiều dịch vụ luồng trực tuyến hiện nay đều có độ phân giải tương đối thấp để tiết kiệm băng thông. Chất lượng của các dịch vụ luồng trực tuyến thường không thể so sánh được với mạng lưới truyền hình truyền thống. Do đó quản lý tài nguyên là một vấn đề quan trọng trong việc triển khai kỹ thuật streaming trên Internet.

Mặt khác, khả năng xử lý, dung lượng lưu trữ, lưu lượng của máy chủ I/O có thể tạo thành nút thắt cổ chai. Mặt khác, số lượng lớn các kết nối mạng đường dài cũng có thể dẫn đến tắc nghẽn lưu thông. Do đó, hệ thống không thể đáp ứng yêu cầu thực hiện của các ứng dụng luồng đa phương tiện quy mô lớn, thời gian thực. Tuy nhiên, kỹ thuật IP multicast được cung cấp để giải quyết những vấn đề này cần sự hỗ trợ từ phần cứng đặc biệt và các chi phí thiết lập cơ sở hạ tầng và quản lý là rất tốn kém. Về bản chất, các kỹ thuật truyền thống không thể giải quyết hiệu quả những vấn đề của video streaming. Do đó, mô hình phân phối luồng video quy mô lớn qua mạng Internet đang nổi lên. Mạng P2P đã được chấp nhận rộng rãi như là một cách để giải quyết các vấn đề tài nguyên với các ứng dụng luồng Internet như VoD , live streaming và cung cấp một sự thay thế cho hệ thống client - server.

2.2 Mạng ngang hàng Peer-to-Peer

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 nút 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 (clien) và chủ (server), mà chỉ có những nút ngang hàng 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 nút khác trong mạng. Mô hình mạng này khác với mô hình mạng khách – chủ (server –client) 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 và 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ố máy khách tăng lên thì 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 2.1)

Hình 2.1 Phân loại mạng ngang hàng

2.2.3.1 Mạng ngang hàng thuần túy

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 quy luật nào). Những mạng như thế này dễ dàng được xây dựng vì các máy mới khi muốn tham gia mạng có thể lấy các liên kết sẵn có có 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 nút trong mạng không cấu trúc là rất ít, mỗi nút chỉ nắm bắt thông tin về những nút



liên kết trực tiếp và một số ít các nút khác, thông tin về những nút còn lại hoàn toà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 nút 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 (Distributed Hash Table – Bảng băm phân tán). 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 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 tạo 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 nút đề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.

2.2.3.2 Mạng ngang hàng lai ghép

Trong mô hình mạng ngang hàng lai 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 trữ các chỉ mục bao gồm thông tin về các nút mà nó quản lý và vị trí các cặp key – value trên mạng. Các nút trong mạng phải tạo liên kết với server này. Một nút muốn trao đổi thông tin với một nút 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ỉ nút đích. Quá trình trao đổi thông tin sau đó được diễn ra trực tiếp giữa 2 nút. 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.4 C c vấn đề cần xem xét trong P2P streaming

Trong vài năm qua, mạng P2P đã xuất hiện như là một phương pháp thuận lợi cho việc cung cấp các nội dung đa phương tiện trên nền một mạng phủ lớn. Các đặc tính bên trong mạng P2P làm cho các mô hình P2P trở thành một ứng cử viên tiềm năng để giải quyết các vấn đề khác nhau trong truyền thông đa phương tiện trên mạng Internet. P2P Streaming là giải pháp tốt hơn vì hai l do. Đầu tiên, mạng P2P không cần sự hỗ trợ từ các bộ định tuyến Internet và do đó chi phí hiệu quả và đơn giản để triển khai. Thứ hai, một peer đồng thời hoạt động như một client cũng như server, do đó có thể tải xuống một luồng video và cùng một lúc tải lên luồng video đó để các peer khác xem chương trình đó. Do đó, truyền tải P2P làm giảm đáng kể nhu cầu băng thông của nút nguồn. Mục tiêu của cơ chế P2P streaming là tối đa hóa chất lượng phân phối nội dung cho các điểm peer riêng l . Tổng hợp nguồn tài nguyên có sẵn của các peer và có khả năng mở rộng đến số lượng bất kỳ các điểm tham gia. Mỗi peer có thể tiếp tục cung cấp nội dung phù hợp với các peer đã kết nối với nó trong lớp phủ bằng cách sử dụng băng thông của các điểm peer đang tham gia. Tuy nhiên, việc cung cấp các dịch



vụ P2P streaming video cho một số lượng lớn người xem tạo ra những thách thức công nghệ rất khó khăn trên cả hệ thống và tài nguyên mạng.

Trong khi các ứng dụng phân phối file P2P truyền thống nhằm mục tiêu truyền dữ liệu linh hoạt, P2P streaming tập trung vào việc phân phối hiệu quả các nội dung audio và video theo yêu cầu thời gian ràng buộc. Luồng dữ liệu được nhận, phát ngay lập tức và truyền cho các điểm peer liên quan khác. Ví dụ: ứng dụng chia s file P2P, BitTorrent cho phép các điểm peer trao đổi đoạn bất kỳ của các nội dung được phân phối mà nó là không quan trọng thứ tự. Ngược lại, các kỹ thuật như vậy là không khả thi trong ứng dụng streaming. Các tập tin video được phát trực tiếp trong lúc nó đang được tải xuống. Ngoài ra, các peer đã hạn chế khả năng tải lên, mà xuất phát từ thực tế là Internet được thiết kế cho các mô hình client – server và các ứng dụng. Hơn nữa, hệ thống streaming chịu việc rớt gói tin hoặc chậm trễ do tắc nghẽn mạng.

Trong P2P streaming, trễ end-to-end từ nguồn đến nơi nhận lớn bởi vì nội dung có thể phải đi qua một số nơi nhận trung gian. Hành vi của người nhận là không thể đoán trước, họ được tự do tham gia và rời bỏ bất cứ lúc nào, do đó loại bỏ các peer kế tiếp của họ. Người nhận có thể phải lưu một số cấu trúc dữ liệu cục bộ và trao đổi thông tin trạng thái với nhau để bảo vệ các kết nối. Các chi phí kiểm soát ở mỗi điểm nhận đáp ứng mục đích như vậy sẽ nhỏ để giữ cho không sử dụng quá nhiều tài nguyên mạng và để khắc phục hạn chế tài nguyên ở mỗi điểm nhận. Điều này là quan trọng đối với khả năng mở rộng của hệ thống với một số lượng lớn các điểm nhận.

Việc cấu trúc các nút thành lập một mạng phủ cung cấp video đảm bảo QoS. Mặt khác, hệ thống có quy mô mở rộng nên có thể chứa hàng chục ngàn người nhận tại cùng một thời điểm. Đồng thời, các chi phí quản lý liên quan hợp lý ngay cả ở quy mô lớn.

2.3 C c phƣơng ph p tiếp cận xây dựng lớp phủKỹ thuật streaming trong cách tiếp cận P2P được phân loại thành truyền video thời

gian thực (P2P live video streaming) và truyền video theo yêu cầu (P2P on demand video streaming). Một số hệ thống P2P streaming đã được triển khai để cung cấp xem video theo yêu cầu hoặc các dịch vụ truyền video trực tuyến qua Internet.

Hình 2.2 Các loại P2P Streaming

Dựa trên cấu trúc mạng che phủ, hệ thống P2P streaming được sắp xếp thành ba loại: tree-based (phương thức tiếp cận dạng cây), mesh-based (phương thức tiếp cận



dạng lưới) and hybrid schemes (phương thức tiếp cận dạng ẩn). Phương pháp tiếp cận tree-based sử dụng phương pháp đẩy dữ liệu để phân phối nội dung. Tuy nhiên, phương pháp tiếp cận mesh-based sử dụng tràn lụt dữ liệu để phân phối nội dung.

2.3.1 Phƣơng ph p tiếp cận dạng cây

Tương tự như một cây IP multicast được hình thành bởi các bộ định tuyến ở lớp mạng, các người dùng tham gia vào một phiên video streaming có thể tạo thành một cây ở lớp ứng dụng có gốc được bắt nguồn từ máy chủ video nguồn như hình 2.3. Về nguyên tắc, mỗi nút nhận dữ liệu từ một nút cha, có thể là nút nguồn hoặc một peer. Các hệ thống dựa trên cây thường phân phối video bằng cách chủ động đẩy dữ liệu từ một peer tới các nút con của nó.

Một cách tiếp cận chung của P2P streaming là sắp xếp các peer tham gia vào một lớp phủ có cấu trúc cây đơn luồng mà nội dung được đẩy đi từ nguồn tới tất cả các peer. Nội dung được lan truyền như một dòng chảy liên tục của thông tin từ nguồn xuống. Mỗi người dùng tham gia vào cây ở vị trí nhất định. Các hệ thống loại này chủ yếu là khác nhau trong các thuật toán được sử dụng để tạo ra, duy trì cấu trúc cây. Cho một tập hợp của các điểm peer, có rất nhiều cách để kết nối các peer. Mục tiêu của thuật toán xây dựng cây là tối đa hóa băng thông tới gốc của tất cả các nút. Vì các hệ thống này rất gần với IP multicast, cố gắng để mô phỏng cấu trúc cây của nó, nó có thể để đạt được độ dài đường truyền dữ liệu tương ứng mà không chênh lệch quá nhiều từ các đường dẫn IP multicast.

H nh 2.3 Mô h nh cây đơn

Xây dựng và duy trì cây có thể được thực hiện tập trung hoặc một cách phân tán trong hệ thống cây đơn luồng. Trong hình 2.4 & 2.5, một máy chủ trung tâm quản lý xây dựng cây và phục hồi cây. Khi một peer tham gia hệ thống nó giao tiếp với máy chủ trung tâm. Dựa trên các kết nối hiện có và đặc tính của các peer mới được tham gia vào như vị trí và điểm truy cập mạng, máy chủ quyết định vị trí của peer mới trong cây và thông báo nút cha để peer mới được kết nối vào. Các máy chủ trung tâm có thể phát hiện một peer tách ra thông qua tín hiệu mất hoặc phán đoán dựa trên chỉ số thời gian đầu ra. Trong cả hai trường hợp máy chủ sẽ tính toán lại cấu trúc liên kết cây cho



số peer còn lại và chỉ dẫn chúng tạo thành cấu trúc liên kết mới. Đối với một hệ thống streaming lớn, máy chủ trung tâm có thể trở thành điểm nút thắt cổ chai. Để giải quyết vấn đề này, các thuật toán phân phối ví dụ ZigZag được phát triển để xây dựng và duy trì cây streaming phân phối nội dung. Nếu các peer không thay đổi một cách thường xuyên, hệ thống dựa trên mô hình cây đòi hỏi ít chi phí như các gói tin được chuyển tiếp từ peer tới peer mà không cần phải thêm bản tin thông báo. Tuy nhiên trong môi trường tỷ lệ biến động cao, cây sẽ thường xuyên thay đổi và phải xây dựng lại. Do đó, các peer cần phải đệm dữ liệu (buffer data) ít nhất là bằng thời gian cần thiết cho sửa chữa cây để tránh khỏi mất gói.

Hình 2.4 : Xây dựng lại cây Streaming(a) Peer 0 rời (b) Mô hình cây sau khi phục hồi

Hình 2.5 Giải pháp tập trung cho cấu trúc cây và duy trì cây

2.3.2 C c hệ thống luồng trực truyến dựa trên cây đơn luồng

2.3.2.1 Giao thức NICE

Hệ thống phổ biến nhất sử dụng cách tiếp cận cây đơn luồng là NICE. NICE (The Internet Cooperative Environment) được thiết kế ban đầu cho băng thông thấp và các ứng dụng truyền dữ liệu với một số lượng lớn người dùng. Giao thức sắp xếp các trạm cuối (host) vào trong một hệ thống phân cấp dựa trên thời gian thông tin chuyền đi vòng quanh giữa các host hình 2.6. Các hoạt động cơ bản của giao thức là tạo ra và duy trì các tuyến đường trong hệ thống. Mỗi thành viên giữ chi tiết trạng thái về các thành viên khác gần nó trong hệ thống phân cấp. Và chỉ có kiến thức hạn chế về các



thành viên khác trong nhóm. Cấu trúc phân cấp cũng rất quan trọng cho xác định vị trí của các thành viên thất bại.

Hình 2.6 Sắp xếp các host trong NICE.

2.3.2.2 Giao thức SpreadIt

SpreadIt xây dựng ứng dụng cây multicast trên các thiết lập của khách hàng. Các nút được tổ chức thành các cấp khác nhau (hình 2.7 và hình 2.8). Đối với mỗi nút n ở mức 1+l; l = 0 , 1 , 2 …, có một nút p được gọi là cha của nó, ở mức l, n được gọi là con của p. Tất cả các nút trong cây con có gốc là p được gọi là con cháu của nó. Mỗi peer trong cây chịu trách nhiệm việc gửi các dữ liệu cho nút con của mình. Mỗi nút khách hàng cần phải được kích hoạt với một lớp peering(lớp nằm giữa lớp ứng dụng và lớp vận chuyển). Các lớp peering tại các nút khác nhau phối hợp với nhau để thiết lập và duy trì một cây multicast. Các ứng dụng (RealPlayer, Windows Media Player, etc) có được luồng từ các lớp peering trên các máy tính cục bộ. SpreadIt sử dụng một cây đơn phân bố và như vậy rất dễ bị tổn thương do gián đoạn một nút tách ra.

Hình 2.7 SpreadIt – một ứng dụng cây multicast xây dựng trên các Peer



Hình 2.8 SpreadIt–Kiến trúc phân lớp của một Peer

2.3.2.3 Giao thức ESM

ESM (End System Multicasst) là một cơ sở hạ tầng cho phát thanh truyền hình, thực hiện bởi đại học Carnegie Mellon. ESM cho phép truyền dữ liệu âm thanh hình ảnh tới một lượng lớn người sử dụng. Hệ thống ESM sử dụng một cấu trúc lớp phủ dựa trên đó xây dựng một cây. Các thông tin được phân phối một cách truyền thống dựa trên cây đơn luồng, trong đó bất kỳ peer nào cũng chỉ nhận được luồng tin từ duy nhất một nguồn. Mỗi nút duy trì thông tin về một nhóm nhỏ ngẫu nhiên của các thành viên khác, cũng như các thông tin về đường đi từ nguồn đến nó. Một nút mới tham gia phát sóng bằng cách liên hệ với nguồn và lấy danh sách ngẫu nhiên của các thành viên hiện đang trong nhóm. Sau đó chọn một trong các thành viên làm nút cha của nó bằng cách sử dụng thuật toán lựa chọn nút cha. Để tìm hiểu về các thành viên khác, một bản tin thăm dò được sử dụng. Khi một nút tham gia vào phát sóng hoặc cần thực hiện thay đổi nút cha, nó dò một tập hợp ngẫu nhiên của các nút nó biết. Các bản tin thăm dò được ưu tiên tới các thành viên đã không được khảo sát hoặc có sự trễ thấp.

Hình 2.9 cho thấy một vi dụ về nhiệm vụ của ESM. Người nhận cuối cùng có thể đóng vai trò của nút cha hoặc nút con. Các nút cha đóng vai trò là các thành viên và thực hiện sao chép. Các nút con là người nhận trực tiếp dữ liệu từ nút cha. Có một máy chủ điều khiển và một máy chủ dữ liệu cư trú trong cùng một gốc nguồn. Bất kỳ một người nhận có thể đóng vai trò của nút cha chuyển tiếp dữ liệu cho nút con của nó. Mỗi khách hàng sẽ có hai kết nối: một kết nối quản l và một kết nối dữ liệu.



Hình 2.9 Ví dụ về ESM

Một lợi thế của ESM là nó giải quyết các vấn đề triển khai của IP multicast. Tuy nhiên, multicasting thực hiện tại máy trạm cuối hiệu năng thấp. Nói chung các trạm cuối không xử l được thông tin giống như các router. Ngoài ra, giới hạn băng thông và nhu cầu của việc chuyển tiếp bản tin từ host to host sử dụng kết nối unicast và do đó tăng trễ end-to-end của quá trình truyền tin, góp phần tăng chi phí phải trả cho cách tiếp cận này. Đó là những l do làm cho ESM kém hơn so với IP multicast.

2.3.2.4 Giao thức ZigZag

ZigZag đã được đề xuất bởi trường đại học Central Florida và để cải thiện giao thức NICE. Các thuật toán để xây dựng cấu trúc và bảo dưỡng khá giống với NICE và tất cả các thuộc tính của giao thức NICE vẫn còn. ZigZag nhận vào một hệ thống các nhóm và xây dựng cây munlticast trên hệ thống phân cấp này theo một bộ quy tắc được gọi là quy tắc C (hình 2.10). Một nhóm có một nút cha đứng đầu và một nút liên kết. Nút cha chịu trách nhiệm giám sát các thành viên của nhóm và nút liên kết chịu trách nhiệm truyền tải những nội dung cho các thành viên trong nhóm. Vì vậy nút cha gặp vấn đề không ảnh hưởng đến tính liên tục dịch vụ của các thành viên khác hoặc trong trường hợp nút liên kết tách ra, nút cha vẫn còn hoạt động và có thể chị định một nút liên kết mới nhanh chóng. Trong khi ở NICE tất cả mọi dữ liệu được chuyển tiếp bởi các nút cha, ở NICE chịu trách nhiệm chuyển tiếp dữ liệu là bởi nút liên kết. Các giao thức điều khiển trên ZigZag có chi phí thấp. Một máy thu cần trao đổi thông tin điều khiển tới O(LogN) máy thu khác trong trường hợp tệ nhất. ZigZag được áp dụng tốt nhất cho các ứng dụng luồng chẳng hạn như máy chủ truyền thông một sự kiện thể thao dài hạn trực tuyến cho nhiều khách hàng. Nó không phù hợp cho các ứng dụng truyền thông trực tuyến nơi nhiều nguồn có mặt. Hạn chế chính của ZigZag là nó không xem xét dung lượng băng thông tải lên của peer tham gia vào giao thức. Ngoài ra, ZigZag tạo ra cây đơn luồng kết nối giữa các peer, nó cũng có những vấn đề chung của cây đơn luồng như không sử dụng băng thông tải lên của lá, các nút bên trong cây dễ bị tổn thương.



Hình 2.10 Tổ chức hành chính của Peer trong ZigZag

2.3.3 Phƣơng ph p tiếp cận dựa trên cây đa luồng

Các giải pháp cây đơn luồng có lẽ là cách tiếp cận tự nhiên nhất và nó không yêu cầu phức tạp thuật toán mã hóa video. Tuy nhiên, một trong những mối quan tâm với cách tiếp cận dựa trên cây đơn luồng đó là sự thất bại của các nút, đặc biệt là những nút có vị trí cao trong cây có thể làm gián đoạn việc cung cấp dữ liệu cho một lượng lớn người dùng dẫn đến kết quả thu được kém. Nếu một nút bên trong tài nguyên băng thông không đáp ứng phục vụ các nút con của nó, các peer trong cây sẽ bị ảnh hưởng trễ cao trong tiếp nhận dữ liệu hoặc sẽ không bao giờ nhận được gói tin. Các hệ thống này không khai thác tốt tất cả các tài nguyên peer có sẵn và đặc biệt băng thông. Ví dụ, các nút lá chiếm một phần lớn các peer trong hệ thống và họ không đóng góp băng thông vào hệ thống, điều đó làm các peer sử dụng băng thông không hiệu quả. Để đáp ứng mối quan tâm, các nhà nghiên cứu đã nghiên cứu cấu trúc tốt hơn cho việc phân phối dữ liệu. Đặc biệt, một trong những cách tiếp cận đã trở nên phổ biến là phương thức tiếp cận trên cây đa luồng.

Hình 2.11 Cây đa luồng trên cơ sở Streaming

Trong cách tiếp cận cây đa luồng (hình 2.11), một cơ cấu xây dựng cấu trúc các peer tham gia trong cây đa luồng. Mỗi peer xác định một cây để tham gia dựa trên liên kết băng thông truy cập. Mỗi peer được đặt như một nút nội bộ trong một cây đơn luồng và nút lá trong cây khác mà nó tham gia. Khi một peer tham gia hệ thống, nó



tiếp xúc với nút khởi động (bootstrapping) để xác định một nút cha trong cây. Trong cây đa luồng dựa trên hệ thống P2P luồng trực tuyến, đoạn video được mã hóa thành nhiều luồng và mỗi luồng được truyền qua một cây. Chất lượng video nhận được tại các peer phụ thuộc vào số lượng luồng tin mà nó nhận được. Khi một nút bên trong của một cây tách ra, các nút con của nó cũng như các cây có gốc là nút tách ra được phân chia lại và chúng tham gia lại các cây. Việc cung cấp nội dung là một cơ chế đơn giản, các nút nội bộ trong mỗi cây chỉ đơn giản là chuyển tiếp bất kỳ gói tin nhận được cho tất cả các nút con tương ứng của nó. Do đó, thành phần chính của các luồng P2P dựa trên phương pháp tiếp cận cây là các thuật toán xây dựng cây.

Có hai lợi thế quan trọng cho các giải pháp cây đa luồng. Đầu tiên, nếu một mạng ngang hàng bị phá hoặc bỏ đi, tất cả các nút con của nó mất đi luồng gửi từ các peer, nhưng nó vẫn nhận được các luồng phân phối dữ liệu qua các cây khác. Do đó, tất cả các nút con của nó sẽ nhận được luồng video trong trường hợp mất đi luồng gửi từ một luồng. Thứ hai, một peer đóng vai trò khác nhau như nút nội bộ cũng như các nút lá trong cây khác nhau.

Nếu các peer không thay đổi quá thường xuyên, hệ thống cây đa luồng trực tuyến đòi hỏi ít chi phí, vì các gói tin được chuyển tiếp từ nút tới nút mà không cần thông báo thêm. Tuy nhiên, trong môi trường biến động cao, cây liên tục bị thay đổi và xây dựng lại. Quá trình này đòi hỏi đáng kể bản tin quản l quá trình trên. Do đó, các nút phải đệm dữ liệu ít nhất là thời gian cần thiết để cây sửa chữa, để tránh mất gói tin.

2.3.4 C c hệ thống luồng trực truyến dựa trên cây đa luồng

Vài ứng dụng được xây dựng trên khái niệm cây đa luồng phổ biến ngày nay. Ví dụ như SplitStream and Coopnet. Ở đây ta chỉ xem xét tới hệ thống CoopNet

2.3.4.1 CoopNet

CoopNet (Cooperative Networking) kết hợp các khía cạnh của cơ sở hạ tầng dựa trên hạ tầng mạng P2P. Nó sử dụng nhiều mã hóa để thực hiện truyền nội dung trên lớp xử l , sau đó truyền nội dung trong các lớp khác nhau theo những con đường khác nhau. Một máy chủ giàu tài nguyên đóng vai trò trung tâm trong việc xây dựng và quản l các cây phân phối nội dung, tuy nhiên băng thông cho việc gửi các luồng dữ liệu nội dung được đóng góp bởi tập hợp các peer (hình 2.12). Hệ thống xây dựng nhiều cây phân phối mở rộng nguồn và tất cả người thu. Khi một nút muốn tham gia, nó liên lạc với máy chủ trung tâm nếu đáp ứng yêu cầu thì một nút cha trong cây được chỉ định cho nó. CoopNet hỗ trợ cả luồng trực tuyến cũng như các dịch vụ theo yêu cầu. Cách tiếp cận CoopNet là tốt, ở đây các peer thu được nội dung chất lượng thấp được ưu tiên hơn. Tuy nhiên, các máy chủ trung tâm cần phải duy trì kiến thức đầy đủ của tất cả các cây phân phối, nó sẽ tạo ra chi phí kiểm soát nặng trên máy chủ. Vì vậy khả năng mở rộng của CoopNet không tốt. Một vấn đề khác là các máy chủ trung tâm trở thành một điểm thất bại trên hệ thống.



Hình 2.12 Streaming Media sử dụng nội dung CoopNet

2.4 Phƣơng thức tiếp cận dựa trên lƣới

Để chống lại các động thái từ các peer, nhiều hệ thống P2P streaming sử dụng phương pháp tiếp cận dựa trên lưới. Trong phương pháp tiếp cận dựa trên lưới, peer tham gia tạo thành một lớp phủ kết nối ngẫu nhiên. Trong lớp phủ các nội dung gốc từ nguồn ban đầu được phân phối giữa các peer khác nhau. Mỗi nút có thông tin về tất cả các nút khác nhau trong hệ thống. Kết quả là, mỗi nút duy trì kết nối với một vài nút khác trong mạng. Mỗi peer trao đổi dữ liệu với một tập các peer hàng xóm. Nếu một peer hàng xóm rời đi, các peer vẫn có thể tải về các video từ những peer hàng xóm còn lại. Trong khi đó, các peer sẽ bổ sung thêm các máy khác vào tập hợp peer hàng xóm của nó. Không giống như các hệ thống cây đơn luồng trong hệ thống lưới trên, mỗi peer có thể nhận được dữ liệu từ nhiều peer hàng xóm cung cấp. Vì vậy, các hệ thống truyền dựa trên lưới khỏe mạnh chống lại các trạng thái từ các peer hàng xóm. Những thách thức lớn trong hệ thống luồng trực truyến P2P dựa trên lưới là hình thành thông tin láng giềng và lập danh mục dữ liệu.

Khi một peer tham gia vào mạng. Một peer trong các địa chỉ mạng (một nút bootstrapping) theo dõi peer mới và cung cấp một danh sách có chứa các thông tin của một nhóm ngẫu nhiên các peer đang hoạt động. Sử dụng danh sách này, các peer cố gắng để bắt đầu kết nối và nếu thành công nó bắt đầu trao đổi nội dung video với các peer (hàng xóm). Để xử l những peer rời khỏi mạng không báo trước, các peer trong mạng thường xuyên trao đổi với nhau. Đồng thời, tùy thuộc vào cấu trúc hệ thống của các peer, một peer không kết nối duy nhất tới một peer láng giềng, để đáp ứng việc các peer tách ra.

Hình 2.13 Danh sách peer từ Tracker Server Hình 2.14 P2PliveVideo Streaming



Trong hệ thống dựa trên lưới, các khái niệm về luồng video trở nên không có tác dụng do cấu trúc liên kết lưới. Các khối đơn vị dữ liệu trong hệ thống lưới là một đoạn video. Các máy chủ đa phương tiện phân chia nội dung truyền vào các khối truyền thông nhỏ, mỗi khối có một số thứ tự nhất địn. Sau đó, mỗi khối được truyền đến tất cả các peer qua lưới (hình 2.14). Mỗi khối dữ liệu có các con đường khác nhau để tới các peer, chúng có thể đến đích theo một thứ tự không liên tục. Để đối phó với vấn đề này khối dữ liệu thường được thêm các bộ đệm (buffered) vào bộ nhớ và tự sắp xếp lại trước khi cung cấp cho máy thu, đảm báo phát liên tục.

Chủ yếu có ba vấn đề chính của thiết kế trao đổi dữ liệu trong hệ thống lưới: đẩy (push), kéo (pull) và lai đẩy-kéo (Hybrid Push - Pull) hình 2.15. Trong một hệ thống lưới đẩy, một peer tích cực đẩy các khối nội dung nhận được cho các peer hàng xóm của nó (peer mà chưa nhận được các khối nội dung đó). Không có quy định rõ ràng mối quan hệ cha-con trong hệ thống lưới. Một peer có thể đẩy mò mẫm một khối nội dung tới peer vừa có khối đó. Nó cũng có thể xảy ra hai peer cùng đẩy các khối như nhau, sẽ làm lãng phí băng thông. Để giải quyết vấn đề đó, lịch trình đẩy khối nội dung cần phải được lên kế hoạch một cách cẩn thận giữa các peer. Và lịch trình cần phải được tái tạo khi các peer đến và đi trong hệ thống.

Hình 2.15 Trao đổi dữ liệu thiết kế trong hệ thống dựa trên lƣới

Một phương pháp cho việc truyền dữ liệu là phương pháp kéo. Ý tưởng chính của phương pháp kéo là mỗi peer yêu cầu các đoạn thiếu từ các peer khác. Mỗi peer có một nhóm hàng xóm và định kỳ trao đổi thông tin dữ liệu sẵn có (buffer maps) với các peer hàng xóm. Một bộ nhớ đệm chứa số thứ tự của các khối hiện có trong bộ đệm của peer. Bất cứ khi nào một peer nhận được thông tin từ các peer khác, nó học về các khối nó đã không được biết. Sau đó nó yêu cầu các khối còn thiếu từ các peer trong nhóm. Hơn nữa, bất kì khối đều có sẵn tại nhiều đối tác, do đó mạng lưới mạnh để tránh thất bại khi một nút tách ra. Tức là các peer sẽ sử dụng các peer hàng xóm khác để nhận được khối dữ liệu. Một bất lợi của kỹ thuật kéo là thường xuyên trao đổi bản đồ đệm và kéo các sản phẩm yêu cầu nhiều hơn tín hiệu phía trên và tăng trễ khi lấy một khối nội dung.

Phương pháp kéo (pull) trong lớp phủ không có cấu trúc mạnh mẽ có thể làm việc tốt với tốc độ cao nhất trong môi trường P2P trong khi chế độ đẩy (Push) có thể làm giảm hiệu quả độ trễ được thấy ở các nút người sử dụng. Phương pháp kéo thuần túy không thể đáp ứng nhu cầu của các ứng dụng vì trễ vì độ trễ tích lũy lớn . Lai push-



pull



streaming có thể làm giảm độ trễ và kế thừa các tính năng tốt nhất như đơn giản và mạnh mẽ của phương pháp kéo thuần túy. Mỗi nút sẽ sử dụng phương pháp kéo và sau đó khi nhận được khối dữ liệu mỗi nút sẽ chuyển tiếp khối đó đến peer hàng xóm mà không có yêu cầu rõ ràng từ những hàng xóm. Các luồng dữ liệu được phân loại như các gói đươc kéo và đẩy như các gói tin. Một gói của nút bị kéo chỉ khi các gói dữ liệu được yêu cầu, trong khi một gói bị đẩy ngay sau khi nút nhận được gói đó. Mỗi nút hoạt động theo chế độ kéo thuần túy trong khoảng thời gian đầu tham gia. Trong khi đó, các gói tin bị mất gây ra bởi sự không đáng tin cậy của liên kết mạng hay những peer thất bại sẽ được kéo cũng từ những peer khác. Vì vậy, hầu hết các gói tin nhận được sẽ được đẩy đi.

2.4.1 C c hệ thống luồng trực truyến phổ biến dựa trên lƣới

Nhiều ứng dụng được phát triển bởi các nhà nghiên cứu cho các mục đích khác nhau của P2P streaming dựa trên lưới. Anysee là một ứng dụng dựa trên phương pháp đẩy nhưng trái lại CoolStreaming, Chainsaw, PPLive, PPStream, and SopCast là một ví dụ về ứng dụng dựa trên phương pháp kéo. GridMedia and PRIME là những ứng dụng được phát triển dựa trên cách tiếp cận sơ đồ lai push-pull.

2.4.1.1 Hệ thống AnySee

AnySee là một ứng dụng dựa trên phương pháp đẩy trong hệ thống lưới trong đó các nguồn được phân chia dựa trên trễ của nó. Các công việc cơ bản của anysee là như sau. Ban đầu, một lớp phủ được xây dựng dựa trên lưới. Tất cả các peer, với một định danh duy nhất, đầu tiên kết nối với các nút bootstrapping và lựa chọn một hoặc một số peer để xây dựng liên kết. Mỗi peer do đó duy trì một nhóm các peer hàng xóm. Phát hiện một vị trí dựa trên thuật toán được sử dụng để phù hợp với lớp phủ và mô hình vật l phía dưới lớp phủ. Ban đầu, tất cả các đường streaming được quản l bởi các lớp phủ hợp đơn duy nhất để dễ quản l việc tham gia, rời khỏi của các peer. Người quản l tối ưu hóa giữa các lớp phủ và khám phá con đường thích hợp, xây dựng các liên kết sao lưu và cắt đứt con đường có Q0S thấp. Người quản l duy trì hai đường truyền hoạt động, gồm đường dẫn streaming hiện tại và các đường dẫn sao lưu được tính toán trước của tất cả các peer trong mạng. Vì vậy, khi các peer chết hoặc rời khỏi mạng, một con đường mới được chọn từ bộ dự phòng để thay thế các liên kết bị hỏng do đó khôi phục lại kết nối của mạng. Sơ đồ hệ thống của một nút AnySee được thể hiện trong hình 2.16. Cơ chế AnySee thuận lợi bởi vì các peer hàng xóm không tụ họp đòi yêu cầu khi có một peer ra đi, thay vào đó người quản l lớp phủ thay thế một liên kết bị mất bằng cách đề cập đến các thiết lập sao lưu thay thế một peer hiệu quả. Do đó, Anysee khôi phục các kết nối của mạng rất nhanh. Mục tiêu của quản l nút quan trọng là xác định số lượng yêu cầu mà một peer cần phải có. Video được phân chia thành nhiều khối, mỗi khối có thời gian cố định 1s. Các peer lấy các khối từ các nguồn hoặc peer hàng xóm khác và bộ nhớ cache của chúng trong bộ nhớ địa phương. Điểm yếu của Anysee là chất lượng truyền nội dung không được đảm bảo, việc lựa chọn một



nhóm các peer ngẫu nhiên có thể không có đủ nguồn lực để cung cấp chất lượng truyền thông mong muốn.

Hình 2.16 Sơ đồ hệ thống của một nút Anysee

2.4.1.2 Hệ thống Chainsaw

Chainsaw là một hệ thống lưới dựa trên phương pháp đẩy mà không dựa trên một cấu trúc mạng cứng nhắc. Trong sơ đồ này, các peer được thông báo về các gói dữ liệu mới của các peer hàng xóm. Bằng cách này, dữ liệu trùng lặp có thể được loại bỏ và một peer có thể đảm bảo nhận được tất cả các gói dữ liệu. Đối với mỗi peer hàng xóm, một peer tạo ra một danh sách các gói mong muốn, tức là một danh sách các gói tin dữ liệu peer muốn mà trong peer hàng xóm có sẵn. Sau đó nó sẽ được áp dụng một số chiến lược để chọn một hoặc nhiều gói dữ liệu từ danh sách và yêu cầu tới peer hàng xóm thông qua một bản tin yêu cầu. Một peer theo dõi các gói dữ liệu đã yêu cầu từ mỗi peer hàng xóm và đảm bảo rằng nó không yêu cầu gói tin đó từ nhiều peer. Nó cũng hạn chế số lượng yêu cầu tới một peer nào đó, để đảm bảo rằng yêu cầu được trải rộng trên tất cả các peer hàng xóm. Các nút theo dõi các yêu cầu từ các peer hàng xóm của họ và gửi các gói tin tương ứng trong điều kiện băng thông cho phép. Hệ thống không cung cấp một cơ chế nào để thực thi việc đóng góp nguồn tài nguyên công bằng của các nút nhưng Chainsaw cho phép peer tự xác định rõ băng thông tải lên tối đa của. Chainsaw có khả năng đem lại hiệu năng mạng cao và các chi phí CPU do mỗi thông báo gói.

2.4.1.3 Hệ thống PPLive

PPLive là một ứng dụng P2P TV thương mại, nó sử dụng mạng lưới như một giao diện mạng phủ dựa trên phương thức kéo, phân phối luồng nội dung trực tuyến và nội dung đã ghi sẵn. Sự khác biệt lớn PPLive với BitTorrent là trong gói PPLive phải đáp ứng các thời hạn phát lại. Vào tháng Giêng năm 2008, ứng dụng PPLive cung cấp gần 500 kênh với 1.000.000 người sử dụng trung bình. Số lượng các kênh truyền hình



trong tháng 12 năm 2008 được báo cáo là tương đương năm 1775. Nền tảng PPLive bao gồm nhiều lớp phủ. Một lớp phủ tương ứng với một kênh PPLive. Mỗi peer trong một lớp phủ được xác định bằng cặp (địa chỉ, số port). Hình 2.17 cho thấy các hoạt động cơ bản của một peer PPLive. Lúc đầu, peer PPlive tải danh sách các kênh từ danh sách các kênh của máy chủ thông qua giao thức http. Sau đó các kênh được lựa chọn, peer thu thập một tập hợp nhỏ của các peer hàng xóm tham gia trong cùng một lớp phủ bằng cách truy vấn tới các máy chủ thành viên thông qua giao thức UDP. Một peer giao tiếp với các peer hàng xóm trong danh sách để có được danh sách bổ sung, tập hợp với danh sách bạn bè hiện tại của mình thông qua UDP. Theo cách này, peer giữ một danh sách của các peer khác xem cùng một kênh. Để có đủ thời gian để phản ứng với các nút rời đi và để giải quyết những khó khăn, gói tin cho phép có hai bộ đệm: một được quản l bởi PPLive và thứ hai của máy thu của người dùng. Một nhược điểm của kiến trúc P2PLive là khởi động chậm có trễ lớn. Các hoạt động của PPStream là rất giống như PPLive.

Hình 2.17 Kiến trúc cơ bản PPLive

2.4.1.4 Hệ thống DONet

DONet (hoặc CoolStreaing) là hệ thống P2P streaming lưới dựa trên phương thức kéo được đưa ra bởi trường đại học Hong Kong và Vancouver. Trong DONet tất cả các nút định kỳ trao đổi dữ liệu thông tin sẵn có với một nhóm đối tác, và lấy dữ liệu có sẵn từ một hoặc nhiều đối tác, hoặc cung cấp dữ liệu có sẵn cho các đối tác. Một nút bao gồm ba phần chính (hình 2.18). Một người quản l thành viên (Membership manager) giúp quản l các nút, một người quản l quan hệ đối tác (Partnership manager) trong đó thiết lập và duy trì quan hệ đối tác với các nút khác, một lịch trình (A Scheduler) lên lịch trình việc truyền tải dữ liệu video và xác định khối cần được lấy từ đối tác và tải khối đó của các đối tác. CoolStreaming yêu cầu nút mới tham gia liên lạc với máy chủ gốc để có được một kết nối ban đầu. Mỗi nút cũng duy trì một nhóm con của các peer khác trong nhóm. CoolStreaming sử dụng khả năng mở rộng peer, qua giao thức (SGAM) để phát tán thông báo tới các peer. Một nút



CoolSreaming có thể ra đi. Sự ra đi của peer có thể dễ dàng phát hiện sau một thời gian nó không làm gì và một nút bị ảnh hưởng có thể nhanh chóng phản ứng thông qua tái lập lịch trình bằng cách sử dụng thông tin bản đồ bộ đệm của các đối tác còn lại. CoolStreaming cũng cho phép mỗi nút định kỳ thiết lập quan hệ đối tác mới với các nút lựa chọn ngẫu nhiên từ danh sách nhóm của mình. Hoạt động này sẽ giúp mỗi nút duy trì một sự ổn định với các đối tác trong điều kiện có nút tách ra và khám phá các đối tác có chất lượng tốt hơn, ví dụ như những người liên tục có băng thông tải lên cao hơn và nhiều phân đoạn có sẵn. CoolStreaming hỗ trợ các loại phần mềm khác nhau của các máy thu đa phương tiện, chẳng hạn như Windows Media Player, Real Player... Sử dụng các thuật toán lập lịch và một hệ thống đệm (buffering) mạnh mẽ, CoolStreaming đạt được việc phát video mượt mà và khả năng mở rộng hệ thống rất tốt cũng như hiệu suất. Tổng thể tốc độ streaming và phát lại liên tục của hệ thống CoolStreaming là tỷ lệ thuận với số lượng các peer trực tuyến tại bất kỳ thời điểm nào. Một trong những nhược điểm của DONet đó là thông báo cho các peer và sau đó có thể yêu cầu chia khối dữ liệu trước trao đổi dẫn đến kết quả trễ lớn. Tương tự như vậy, do các thuật toán lựa chọn ngẫu nhiên, chất lượng dịch vụ có thể không được đảm bảo. Hơn nữa, DONet giả định rằng tất cả các peer có thể hợp tác trong sự lặp lại của các luồng, nó có thể có các peer ích kỷ trong các hệ thống không muốn chia s băng thông tải lên của peer đó.

Hình 2.18 Một sơ đồ hệ thống chung cho một nút DONet

2.4.1.5 SopCast

SopCast là một ứng dụng miễn phí BitTorrent- like P2PTV, sinh ra từ một dự án sinh viên tại Đại học Fundan ở Trung Quốc. SOP là viết tắt cho Streaming trên P2P. Trong Sopcast các kênh có thể được mã hóa trong Windows Media Video (WMV), Video tập tin cho Realplayer (RMVB), Real Media (RM), Advanced Streaming Format (ASF), và MPEG Audio Stream Layer III (MP3). Một khách hàng có nhiều sự



lựa chọn kênh truyền hình, mỗi kênh thành lập lớp phủ riêng của mình. Mỗi luồng kênh bao gồm nguồn cấp dữ liệu âm thanh và video trực tuyến hoặc vòng lặp hiển thị theo một lịch trình định sẵn. Người xem điều chỉnh vào một kênh lựa chọn của họ và Sopcast bắt đầu hoạt động của mình để lấy luồng. Nó cũng cho phép người sử dụng phát sóng kênh riêng của mình. Sopcast cung cấp tỷ lệ tổn thất khung thấp. Tuy nhiên, Sopcast bị trễ peer, tức là các peer xem cùng một kênh có thể không được đồng bộ. Hơn nữa, thời gian chuyển kênh là rất cao.

Hình 2.19 GridMedia Kiến trúc Dựa trên MSOMP

2.4.1.6 GridMedia

GridMedia thông qua một cơ chế truyền tải đẩy - kéo để lấy dữ liệu từ các nút đối tác. Chế độ kéo trong lớp phủ không có cấu trúc có thể làm việc tốt với tốc độ cao trong môi trường P2P trong khi chế độ đẩy có thể làm giảm độ trễ tích lũy ở phía người dùng. Một máy chủ theo dõi được triển khai để hỗ trợ việc xây dựng các lớp phủ. Khi khởi động, một nút tham gia liên lạc đầu tiên tới RP để có được một danh sách các phần của các nút đã có trong lớp phủ, được gọi là quá trình đăng nhập. Sau đó các nút tham gia ngẫu nhiên sẽ lựa chọn một số nút trong danh sách này như các peer hàng xóm. GridMedia chủ yếu bao gồm nhiều người gửi dựa trên giao thức multicast lớp phủ (MSOMP) và nhiều người gửi dự phòng dựa trên thuật toán phát lại (MSRRA). MSOMP bắt nguồn từ máy chủ streaming đó là một nút ở gốc. Các MSOMP triển khai lưới dựa trên cấu trúc hai lớp và nhóm tất cả các peer vào cụm với nhiều con đường đi khác nhau từ gốc đế mỗi peer. Sau đó, với một hoặc một số các nhà chỉ huy trong mỗi nhóm, tất cả các nút chỉ huy xây dựng xương sống của lớp phủ. MSOMP sử dụng các dịch vụ multicast IP hiện có sẵn trong mạng LAN. IP Multicast miền (IMD) là một mạng lưới địa phương của bất kỳ kích thước mạng nào hỗ trợ IP multicast. IMD có thể là một máy chủ duy nhất, một mạng LAN. Trong mỗi IMD, một peer tiêu đề có trách nhiệm phổ biến các nội dung streaming với các peer đồng nghiệp khác trong cùng IMD. Ngay sau khi nút phần đầu rời khỏi, một nút tiêu đề mới sẽ được bầu để thay thế vai trò. MSOMP kết nối với các IMD bằng đường hầm unicast. MSOMP dựa trên GridMedia kiến trúc được thể hiện ở hình 2.19.



Đề giải quyết vấn đề mất gói tin, MSRRA được đề xuất tại các peer gửi để vá gói tin bị mất bằng cách sử dụng peer nhận để dự đoán mẫu mất. Trong MSRRA, mỗi peer nhận được gói tin truyền tải đồng thời từ nhiều người gửi. Ngay sau khi có tắc nghẽn xảy ra trên một liên kết, peer nhận sẽ có thông báo về tình trạng tắc nghẽn này và sau đó nó sẽ thông báo cho người gửi khác, những người sẽ tiếp tục vá các gói tin bị mất. Các thuật toán MSRRA hiệu quả làm giảm tác động của các nút thất bại, tắc nghẽn mạng và các hoạt động chuyển đổi liên kết.

2.4.1.7 PRIME

PRIME là một khả năng mở rộng kỹ thuật P2P streaming của nội dung trực tuyến dựa trên hệ thống lưới đẩy - kéo lưới. Mục tiêu thiết kế quan trọng nhất của PRIME là để giảm tắc nghẽn băng thông và tránh bị hiện tượng thắt nút cổ chai. PRIME sử dụng tràn ngập nội dung kết hợp việc đẩy nội dung bởi nút cha với kéo nội dung yêu cầu của nút con. Mỗi peer đồng thời nhận được nội dung từ tất cả các nút cha của mình và cung cấp nội dụng cho tất cả các nút con của nó. Cho các gói dữ liệu có sẵn tại nút cha, một chương trình lập lịch trình gói tin tại mỗi peer định kỳ xác định một danh sách lệnh của các gói dữ liệu cần được yêu cầu từ cha.Nút cha chỉ đơn giản là cung cấp các gói tin yêu cầu của mỗi con trong trình tự quy định và theo tỷ giá được xác định bởi các cơ chế kiểm soát tắc nghẽn. Mỗi phân đoạn của các nội dung được gửi đến các peer cá nhân tham gia trong hai giai đoạn: giai đoạn khuếch tán và tràn ngập giai đoạn. Trong giai đoạn khuếch tán, mỗi peer nhận được bất kỳ của một phân đoạn mới từ nút cha của nó ở mức cao hơn. Vì vậy, các mảnh của một phân đoạn mới được tạo ra đang dần dần kéo theo các đồng nghiệp ở các cấp độ khác nhau. Trong giai đoạn lụt, mỗi peer nhận được thấp hơn. Các cha được gọi là tràn ngập các nút cha. Mỗi phần của bất kỳ phân đoạn mới được lan tỏa thông qua một khuếch tán đặc biệt cây con trong giai đoạn khuếch tán của phân khúc đó. Sau đó, các phần có sẵn được trao đổi giữa các đồng nghiệp trong cây tổng, khuếch tán khác nhau thông qua các lưới tràn ngập trong giai đoạn tràn ngập của phân khúc này. Các ứng dụng của hai giai đoạn khác nhau cho phân phối nội dung dẫn đến hiệu quả sử dụng nguồn lực sẵn có để chứa khả năng mở rộng và cũng giảm thiểu nội dung nút cổ chai. Những bất lợi của PRIME là nếu nội dung nút cổ chai xảy ra, các nút phải chờ đợi lâu để tìm ra đơn vị dữ liệu cần thiết của họ sau khi một vài giai đoạn lụt, khi dữ liệu có sẵn trong khu vực của mình. Do đó, không có sự đảm bảo cho một mức độ hợp l của luồng trực tuyến chất lượng. Hơn nữa, các thuật toán không xem xét hành vi của các hệ thống P2P trong sự hiện diện của một thùng đựng.



2.4.1.8 HyPO

Hình 2.20 Hai lớp lƣới/ cây che phủ trong mạng lai

HyPo là một lớp phủ lai P2P cho truyền thông đa phương tiện trực truyến. Tối ưu hóa các lớp phủ bằng cách tổ chức peer với các phạm vi có băng thông tương tự trong bất kì khu vực địa lý nào trong một lớp phủ lưới và tạo thành một lớp phủ cây bằng cách chọn các peer được ổn định. Hình 2.20 minh họa một lưới / cây che phủ hai lớp trong HyPO. Tùy thuộc vào cơ chế tối ưu hóa cây, trong đó các peer có một băng thông lớn sẽ được ở gần với nút nguồn trong các lớp phủ cây, và phân bố đều trong các cây với các nhánh với một chiều sâu tương tự. Do đó, việc tối ưu hóa cây làm giảm độ sâu trung bình của cây, do đó nâng cao khả năng mở rộng. Lưới trong HyPO không phải là một kết nối bổ trợ từ các peer trong lưới, thành viên luôn luôn cung cấp dữ liệu cho lưới cho đến khi nó trở thành một thành viên cây. Tuy nhiên, tất cả các thủ tục của HyPO rất ít dựa trên một máy chủ theo dõi, một khoảng thời gian liên tục có thể xảy ra nếu máy chủ bị lỗi. Hơn nữa, HyPO không đề cập đến cách làm sao dữ liệu được phân bố trong lớp phủ lưới của nó.

2.4.1.9 mTreebone

mTreebone là một thiết kế cây lưới phối hợp thúc đẩy cả lưới và cấu trúc cây. Ý tưởng chính của mTreebone là xác định một nhóm các nút ổn định để xây dựng một cây dựa trên xương sống, các nút này được gọi là treebone với hầu hết các dữ liệu bị đẩy trên xương sống này. Các nút bền vững cùng với những nút khác, được tổ chức thành một lớp phủ lưới bổ trợ, tạo điều kiện cho treebone để phù hợp động lực của một nút và khai thác hoàn toàn băng thông giữa các nút lớp phủ. Các nút không ổn định khác được gắn vào xương sống như vùng bên ngoài. Hình 2.21 cho thấy một mô hình mTreebone. Trong sơ đồ này, kết nối lưới được gọi chỉ khi có một nút riêng biệt bị ảnh hưởng bởi sự ra đi của nút cha hay nút cha thất bại. Việc duy trì treebone và tối ưu hóa chỉ xảy ra tại các nút treebone và không có thêm chi phí cho các peer vùng ngoài xương sống. Thông thường, chất lượng truyền là tốt nhất cho các nút treebone do sự ổn định tốt của các con đường cung cấp dữ liệu của nó từ nguồn. Thách thức chính là chúng ta cần phải xác định tập hợp các nút lớp phủ ổn định và vị trí của nút tại các địa điểm thích hợp trong cây. Một yêu cầu như vậy có thể gây xung đột với băng thông và chậm trễ trong xây dựng cây. Một phát sinh khác khi xem xét về sự ổn



định của mTreebone là phụ thuộc vào các nút treebone, đó là các nút sẽ ở lại trong treebone trong khoảng thời gian bao lâu. Mặt khác, CliqueStream là một lớp phủ lai tương tự như mTreebone khai thác các thuốc tính của một nhóm lớp phủ P2P (hình 2.22). ClipueStream tìm ra một hay nhiều nút bền vững có băng thông cao nhất trong mỗi nhóm và giao cho các nút đó vai trò chuyển tiếp nội dung đặc biệt. Để duy trì hiệu quả truyền tải, một cây phân phối nội dung được xây dựng trên các nút bền vững sử dụng cấu trúc trong nền định tuyến cơ bản và nội dung sẽ được đẩy qua chúng. Các nút ít ổn định trong một nhóm sau đó tham gia vào việc phổ biến nội dung và kéo nội dung tạo ra một lưới xung quanh các nút bền vững.

Hình 2.21 Khung mTreebone (a) một lớp phủ lai (b) xử lý trạng thái nút

Hình 2.22 Cấu trúc trực tuyến trong CiqueStream

Lai kéo – đẩy P2P treaming lớp phủ nổi lên như một giải pháp thay thế cho các phương pháp truyền thống như là cây và lưới. Kể từ khi thiết kế hệ thống lai làm đơn giản hóa việc xây dựng lớp phủ và các quy trình bảo dưỡng và đồng thời vẫn giữ được hiệu quả của mạng và đạt được kiểm soát tốt các nút quá tải.

2.5 Video theo yêu cầu trên P2P

VoD (Video on Demand) hiện có đặt ra một số vấn đề như tính khả thi của giao thức multicast, máy chủ hỏng và chi phí triển khai bảo đưỡng các thiết bị định tuyến



lớp phủ cao. Tuy nhiên, video streaming dựa trên P2P cung cấp một kiến trúc thay thế cho các dịch vụ video theo yêu cầu. Trong một hệ thống VoD P2P, tất cả các peer là host có kết nối Internet, trong đó peer lưu trữ và các luồng video do khách hàng đề nghị. Chi phí của các peer truy cập Internet sẽ được chịu bởi khách hàng chứ không phải bởi các nhà cung cấp dịch vụ VoD. Bởi vì có một nguồn cung cấp phong phú của các peer cung cấp nguồn tài nguyên chưa được sử dụng như băng thông và lưu trữ, dựa trên kiến trúc P2P nên có chi phí ít hơn so với các giải pháp truyền thống client- server và giải pháp CDN.

Áp dụng kỹ thuật luồng trực tuyến P2P vào luồng VoD không phải là một công việc dễ vì nhiều l do. Như hệ thống luồng trực truyến P2P, hệ thống P2P - VoD cũng cung cấp nội dung bằng luồng. Tuy nhiên, các peer có thể xem các gói khác nhau của một đoạn video cùng một lúc, do đó làm yếu đi khả năng giúp đỡ lẫn nhau. Hệ thống VoD có khả năng cho phép người dùng bắt đầu xem một đoạn video sau khi chờ đợi một thời gian, trong khi vẫn tiếp tục tải video về. Mặc dù, trễ end-to-end của luồng trực truyến ngắn nhưng vẫn gây khó khăn cho người sử dụng. Do đó, một cây ngắn bắt nguồn tại máy chủ video và kéo dài trên peer không phải là điều mong muốn trong truyền tải VoD. Người sử dụng sẽ có thể xem video tại một thời gian tùy , không giống như trong truyền hình trực tiếp họ cần phải đồng bộ hóa thời gian xem. Người sử dụng cũng sẽ có thể thực hiện các hoạt động kiểm soát như tua lại, lùi về phía trước..vv trên video. Ví dụ, một peer có thể chặn xem một luồng VoD khi đó QoS của hệ thống giảm, nhưng các peer khác có thể không làm điều tương tự cho một luồng vì nó không có tùy chọn xem lại. Nếu QoS của các luồng video giảm, sẽ có nhiều các peer rời hệ. Điều này cho thấy tầm quan trọng của một giao thức phục hồi trong một hệ thống luồng VoD. Các giao thức kết nối lại các peer bị bỏ rơi, do đó không có mất mát nội dung và không trễ lâu.

Một yêu cầu quan trọng của một dịch vụ VoD là khả năng mở rộng. Một hệ thống VoD cho phép một peer mới tham gia hệ thống nhanh. Thời gian tham gia ngắn, yêu cầu tham gia của các peer đến hệ thống ở các thời điểm khác nhau. Dự kiến hệ thống phải truyền tải các video cho tất cả các peer mà không làm cho máy chủ trở thành một nút cổ chai. Hệ thống VOD P2P thường yêu cầu người dùng đóng góp dung lượng lưu trữ vì các hệ thống này cần kích thước bộ đệm rất lớn để đáp ứng các yêu cầu đa dạng từ các peer khác nhau. Không gian lưu trữ này thường là 1 GB trong PPLive. Có hiệu lực sau khi người dùng cài đặt PPLive và chạy hệ thống lần đầu tiên, người dùng có thể nhìn thấy một loại file chưa biết 1 GB tồn tại trong bộ nhớ máy.

Như hệ thống video streaming, hệ thống VoD P2P thường được phân loại dựa trên cây và hệ thống dựa trên lưới.

2.5.1 Hệ thống VoD dựa trên dạng cây

Nhiều người dùng sử dụng mạng che phủ dạng cây được đồng bộ và nhận nội dung theo thứ tự các máy chủ sẽ gửi đi. Vấn đề chính trong hệ thống VoD dựa trên



cây là việc thiết kế cây và các thủ tục cho người dùng tham gia vào hệ thống. P2Cast và P2VoD là những ví dụ của hệ thống VoD dựa trên cây.

P2Cast là một mô hình vá lỗi (patching) ban đầu cho hệ thống VoD. chương trình đề xuất để hỗ trợ sử dụng dịch vụ VoD có nguồn gốc IP multicast. P2Cast giải quyết hai vấn đề kỹ thuật quan trọng như xây dựng một lớp phủ thích hợp cho các tuyến và cung cấp một luồng tin liên tục phát lại khi một khách hàng ra khỏi hệ thống. Số lượng khách hàng đến một ngưỡng nhất định tạo thành một phiên. Đối với mỗi phiên máy chủ cùng với các khách hàng P2Cast tạo thành một cây đa luồng ở lớp ứng dụng trên mạng unicast. Các khách hàng trong P2Cast có thể chuyển tiếp các luồng video cho các khách hàng. Mỗi khách hàng tích cực góp phần băng thông và không gian lưu trữ cho hệ thống đồng thời tận dụng các nguồn tài nguyên tại các khách hàng khác. Toàn bộ video được truyền trực tiếp trên cây đa luồng ở lớp ứng dụng, để nó có thể được chia s giữa các khách hàng. Đối với khách hàng tham gia muộn hơn các khách hàng đầu tiên trong phiên giao dịch và do đó bỏ lỡ một đoạn ban đầu của video, đoạn thiếu này có thể được lấy từ máy chủ hoặc máy khách hàng khác có lưu trữ đoạn ban đầu. P2Cast có thể phục vụ nhiều khách hàng so với dịch vụ unicast client-server truyền thống. Các chương trình phục hồi trong P2Cast cho phép các đồng nghiệp nhận dữ liệu từ máy chủ trực tiếp khi các nút cha tách ra. Tuy nhiên, điều này làm tăng khối lượng công việc của máy chủ.

P2VoD là một mô hình video theo yêu cầu dạng cây mà nó cố gắng để giải quyết các vấn đề của việc kết nối nhanh, cung cấp nhanh chóng và phục hồi thất bại cục bộ, xử l hiệu quả các yêu cầu không đồng bộ của khách hàng và cung cấp chi phí quản l nhỏ so với P2Cast. Mỗi khách hàng trong P2VoD có một bộ đệm FIFO kích thước thay đổi để lưu trữ các nội dung gần đây nhất của luồng video nhận được. Tồn tại những khách hàng trong P2VoD có thể chuyển tiếp các luồng video tới một khách hàng mới miễn là họ đủ băng thông đầu ra và vẫn giữ khối đầu tiên của tập tin video trong bộ đệm. Mô hình bộ nhớ đệm cho phép một nhóm các khách hàng, đến với hệ thống tại thời điểm khác nhau, để lưu trữ các nội dung video giống nhau trong tiền tố của các bộ đệm của nó. Nhóm như vậy hình thành một phiên. Khi một thành viên của một phiên rời hệ thống, bất kỳ thành viên còn lại của phiên có thể cung cấp video mà không có biến động tới các peer con bị bỏ rơi của các thành viên rời đi với điều kiện băng thông đầu ra quy định là đủ. Trong P2VoD, một kết nối luồng được giả định là tốc độ bit không đổi, bằng với tốc độ phát lại của video. Quá trình phục hồi trong VoD là phức tạp hơn. Ngoài ra, P2VoD không xem xét các băng thông không đồng nhất của các peer.

Bộ nhớ đệm và chuyển tiếp là một cách tiếp cận dựa trên cây, là nơi mà một khách hàng VoD thường dựa trên nội dung được lưu trong bộ đệm của các peer cha của nó. Trong mô hình này, các bộ định tuyến không thực hiện chức năng multicast. Do đó, các host cuối chịu trách nhiệm cho việc lưu trữ và phân bố của luồng tin đa phương tiện. Các host cuối có thể là các máy khách hàng hoặc các proxy của nó và các hệ



thống này duy trì các đối tượng truyền thông trong bộ nhớ cục bộ tạm thời của họ. Nếu một khách hàng yêu cầu các đối tượng truyền thồng về sau, máy chủ gốc có thể chuyển tiếp các yêu cầu tới các host cuối.

Ostream tận dụng khả năng đệm của host cuối bằng cách sử dụng bộ nhớ cache và phương pháp lưu trữ và chuyển tiếp. Mô hình sử dụng một thuật toán cây mở rộng cho các peer để xây dựng một lớp phủ cho truyền thông trực tuyến. ostream làm giảm sự thiểu sự thiếu hiệu quả của topo như trễ liên kết và kéo dài được giới thiệu bằng cách sử dụng multicast lớp ứng dụng.

Hình 2.23 Cấu trúc DirectStream

Một khung làm việc được gọi là DirectStream cho phép khách hàng tận dụng những lợi ích của khoảng thời gian bộ nhớ đệm và dịch vụ video theo yêu cầu với sự hỗ trợ hoạt động VCR . DirectStream bao gồm một máy chủ chỉ dẫn, máy chủ nội dung và khách hàng. Máy chủ chỉ dẫn hoạt động như một điểm trung tâm hành chính. Nó duy trì một cơ sở dữ liệu theo dõi của tất cả các máy chủ và khách hàng tham gia trong DirectStream và giúp khách hàng mới xác định các dịch vụ cần thiết. Các máy chủ nội dung cung cấp các chức năng tương tự như trong mô hình client – server truyền thống lưu trữ nội dung trong kho lưu trữ của nó và phục vụ yêu cầu của khách hàng, miễn là đủ băng thông có sẵn. Do đó khách hàng trong DirectStream có chức năng như nút P2P. Một peer lưu trữ một cửa sổ chuyển động của một nội dung được nhận được mới nhất và phục vụ những peer đến muộn bằng cách liên tục chuyển tiếp các nội dung được lưu trữ. Một tập hợp các khách hàng hoạt động trong một lớp phủ P2P streaming được thành lập được gọi là một nhóm. Các nhóm trong DirectStream phát triển theo thời gian và mỗi khách hàng trong một nhóm chia s luồng giống nhau. Quá trình tìm kiếm dịch vụ cho một yêu cầu mới bao gồm bốn bước như được chỉ ra trong hình 2.23. Đầu tiên các khách hàng mới sẽ gửi một yêu cầu đến máy chủ chỉ dẫn để yêu cầu video bắt đầu từ vị trí. Các máy chủ chỉ dẫn sau đó nhìn vào cơ sở dữ liệu của mình và trả về một danh sách các nút ứng cử viên, bao gồm cả máy chủ dữ liệu và khách hàng có nội dung để phục vụ yêu cầu này. Khách hàng mới xác định từ các nút để lấy các luồng sử dụng cho thuật toán lựa chọn cha QoS. Sử dụng thuật toán



này, một khách hàng lựa chọn một nút cha có đủ băng thông. Các khách hàng mới liên hệ với nút ứng viên được chọn và yêu cầu chuyển tiếp luồng. Sau khi kết nối được thiết lập, khách hàng mới gửi tín hiệu trở lại máy chủ chỉ dẫn và đăng ký chính nó vào cơ sở dữ liệu. DirectStream giảm đáng kể khối lượng công việc đặt ra trên máy chủ. Một lợi thế là quy mô của nó cũng như sự phổ biến của video tăng ngay cả khi khách hàng tham gia không hợp tác chia sẽ. DirectStream có hai nhược điểm, quản l tập trung đưa ra một điểm đơn của sự thất bại. Khi nhiều nhóm cao cấp khác nhau thất bại, một peer có thể nhanh thiếu bộ đệm của nó.

Trong hệ thống VoD dựa trên cây, các peer trên lớp trên luôn luôn đóng một vai trò quan trọng trong mạng che phủ toàn bộ. Sự ra đi của nó sẽ dẫn đến sự biến động lớp mạng thấp hơn. Hơn nữa, mỗi peer chỉ có một nhà cung cấp dữ liệu, điều đó sẽ gây ra không hiệu quả sử dụng băng thông có sẵn trong một mạng không đồng nhất và mạng cómôi trường năng động. Đồng thời, trong bộ nhớ cache và dựa trên hệ thống chuyển tiếp, nếu cha nhảy đến một điểm nào đó trong đoạn video, nó bắt đầu nhận dữ liệu và không quan tâm tới nút con và những nút cần phải tìm kiếm cha mới.

2.5.2 Hệ thống VoD dựa trên lƣới

Trong hệ thống VoD dựa trên lưới, không có cấu trúc liên kết cụ thể được tạo ra. Các peer trong mạng kết nối với một số peer cha để nhận các gói tin video. Hệ thống VoD dựa trên lưới có giao thức ở trên lớp phủ, dễ dàng để thiết kế và linh hoạt hơn cho tốc độ các khối nội dung và do đó nó được phổ biến hơn. Hiện P2P dựa trên hệ thống lưới đã được chứng minh là rất tốt cho phân phối nội dung video quy mô lớn với ít tài nguyên máy chủ. Tuy nhiên, trong hệ thống VoD khó khăn trong thực tế là người dùng muốn nhận được các khối tuần tự để xem video trong khi tải về. Ngoài ra, trong dịch vụ VoD người sử dụng có thể quan tâm tới các phần khác nhau của đoạn video và có thể cạnh tranh tài nguyên của người dùng khác. Qua đó, thách thức chính của hệ thống là đảm bảo rằng người dùng có thể bắt đầu xem video tại bất kỳ thời điểm nào, với thời gian chờ nhỏ và tốc độ phát lại cao.

BitTorrent (BT) là một trong những kỹ thuật dựa trên lưới để phân phối khối lượng lớn các nội dung trên Internet. Nó là một giao thức chia s tập tin mở rộng mà còn kết hợp với cơ chế truyền dữ liệu tràn lụt. Có một số hạn chế của kỹ thuật BT ban đầu trong việc cung cấp video streaming. Trong BT, các tập tin được phân đoạn trên khoảng trống (space). Mặc dù cơ chế lựa chọn đoạn mặc định của BitTorrent là rất hiệu quả trong việc giảm thiểu xác suất cho các đoạn miếng hiếm và cung cấp các đoạn hiếm cho các peer, nó không thất vọng trong thời gian lưu lượng tắc nghẽn. L do là với thời gian dữ liệu nhạy cảm thì mỗi đoạn sẽ phải nhận trong một khoảng thời gian nhất định. Yếu tố này không được xem xét trong cơ chế lựa chọn đoạn ban đầu của BT và do vậy nó không thể cung cấp dịch vụ phân phối nhạy cảm thời gian, bởi vì các đoạn được yêu cầu dựa trên sự hiếm có và không theo thời hạn của nó. Do đó, cơ



chế lựa chọn đoạn hiện tại cần sửa đổi để hỗ trợ dịch vụ thời gian nhạy cảm như VoD. BASS và BiToS là các ví dụ của BitTorrent dựa trên hệ thống P2P VoD dạng lưới.

Hình 2.24 BASS: (a) Tổng quan hệ thống, (b)Mẫu khách hàng

BitTorrent hỗ trợ hệ thống streaming (BASS) mở rộng hệ thống BitTorrent hiện tại để cung cấp một dịch vụ gần Video-on-Demand. Bởi vì BASS sử dụng sự hỗ trợ của BT cho các luồng, nó sử dụng các dịch vụ của một máy chủ bên ngoài mà có thể lưu được toàn bộ video của các nhà sản xuấ và đảm bảo rằng người sử dụng có thể phát lại video mà không gặp sự thay đổi chất lượng. Sự thay đổi duy nhất của BitTorrent cho thấy là nó không nên tải về bất cứ dữ liệu nào trước thời điểm playback. Nó được phép sử dụng đoạn hiếm nhất đầu tiên và chính sách ăn miếng trả miếng (tit – for - tat). Trong chính đoạn hiếm đầu tiên, khách hàng yêu cầu một phần dựa trên số lượng bản sao nó thấy có sẵn và chọn một cái là phổ biến nhất. Từ máy chủ truyền thông, BASS tải các phần trong trật tự, bỏ qua các phần mà đã được tải bởi BitTorrent, hoặc đang trong quá trình được tải về và dự kiến sẽ hoàn thành trước thời hạn phát. Tổng quan về hệ thống của BASS được đưa ra trong hình 2.24. Dù BASS làm giảm tải tại các máy chủ, thiết kế của hệ thống vẫn là máy chủ theo định hướng và do đó các yêu cầu băng thông tại các máy chủ tăng tuyến tính với số lượng người dụng.

Hình 2.25 Phƣơng ph p tiếp cận BiToS



Hệ thống BiToS cũng dựa trên BitTorrent. Ý tưởng chính là để phân chia các khối đang thiếu thành hai tập hợp: “tập hợp ưu tiên cao” và “tập hợp còn lại” và yêu cầu với các khối xác suất cao hơn từ tập hợp ưu tiên cao hơn (hình 2.25). Tập hợp ưu tiên cao hơn, có chứa tất cả các phần khá gần để được tái tạo. Vì vậy, peer mong muốn tải về những phần sớm hơn. Trái ngược với tập hợp còn lại, trong đó có chứa các phần mà sẽ không cần đến trong tương lai gần. Sau khi người dùng bắt đầu, bộ đệm của người dùng yêu cầu những phần cần thiết từ các phần đệm các peer nhận. Trong BiToS, trọng tâm chính được đưa ra cho việc lập lịch cẩn thận của các khối video. Các phần mà bỏ lỡ thời hạn phát lại của nó được giảm xuống đơn giản. Do vậy, điều này có thể dẫn đến suy giảm chất lượng phát lại video. Ngoài ra do tính chất bất đối xứng của các kết nối Internet và không đồng nhất của các peer, hệ thống không thể đảm bảo rằng các đoạn video được yêu cầu luôn luôn có sẵn để phát lại đúng thời gian yêu cầu.

2.6 Kết luận chƣơng II

Chương 2 đã trình bày khái quát về khái niệm mạng ngang hàng P2P, ưu nhược điểm của mạng ngang hàng. Bên cạnh đó còn đề cập đến việc phân loại mạng ngang hàng. Qua đó thấy mạng ngang hàng rất ổn định và dễ mở rộng; tận dụng tối đa tài nguyên đóng góp của các nút tham gia mạng; mạng ngang hàng dễ cài đặt; chi phí thiết bị thấp, triển khai một hệ thống mạng khá dễ dàng.

Nội dung chính chương 2 trình bày các hệ thống P2P streaming, có thể phân chia thành hệ thống P2P live Streaming và P2P VoD. Tùy theo cách tiếp cận, hệ thống P2P live streaming có thể được chia thành dạng cây hoặc dạng lưới. Hệ thống P2P VoD cũng có thể chia thành dạng cây và dạng lưới.

Tuy nhiên, hệ thống P2P streaming cũng bộc lộ nhiều nhược điểm cần phải xem xét, trong đó quan trọng nhất là trễ luồng video.

Đồ án tốt nghiệp đại Chương III: Ứng dụng luồng video streaming qua mạng


CHƢƠNG III: ỨNG DỤNG LUỒNG VIDEO STREAMING QUA MẠNG PASTRY

3.1 Gi iớ thi uệ về Pastry

Gần đây các ứng dụng Internet trong mạng ngang hàng đã được phổ biến một cách rộng rãi thông qua các ứng dụng chia sẽ file như Napster, Gnutella và FreeNet. Trong khi khá nhiều sự chú đều tập trung vào các vấn đề bản quyền được đưa ra bởi các ứng dụng cụ thể thì các hệ thống P2P lại đưa nhiều khía cạnh về vấn đề kỹ thuật như kiểm soát phân cấp, tự tổ chức và khả năng mở rộng. Các hệ thống P2P được mô tả như một hệ thống phân phối, trong đó tất cả các nút đều có nhiệm vụ và năng lực giống nhau, đồng thời tất cả các thông tin truyền thông là đối xứng.

Hiện nay có khá nhiều dự án nhằm xây dựng các ứng dụng P2P. Một trog những vấn đề quan trọng trong việc xây dựng này là nhằm cung cấp các thuật toán hiệu quả cho vị trí đối tượng và quá trình định tuyến trong mạng. Pastry là một trong những giải pháp được đưa ra. Pastry có khả năng chống chịu lỗi, khả năng mở rộng và đáng tin cậy. Hơn nữa, Pastry còn có đặc tính định tuyến cục bộ khá tốt.

Pastry được thiết kế như một chất nền chung cho việc xây dựng một loạt các ứng dụng mạng ngang hàng trên Internet như chia s file toàn cầu, lưu trữ file, truyền thông nhóm và các hệ thống đặt tên. Một số ứng dụng được xây dựng trên đinh của Pastry cho đến nay bao gồm một tiện ích lưu trữ liên tục chung, được gọi là PAST và một hệ thống có khả năng mở rộng, đó là Scribe. Còn lại các ứng dụng khác đang được phát triển.

Pastry cung cấp các khả năng sau đây: đầu tiên mỗi nút trong mạng pastry sẽ có một định danh duy nhất (NodeId) trong một không gian định danh 128 bit vòng tròn. Khi có một thông điệp và một khóa 128 bit dạng số, một nút pastry sẽ hiệu quả trong

việc định tuyến thông điệp đó tới một nút với nodeid có số gần nhất với khóa, trong số tất cả các nút pastry hiện đang sống. Số lượng chuyển tiếp các bước trong mạng bao phủ pastry là O(logN), trong khi kích thước của bảng định tuyến được duy trì trong mỗi nút Pastry chỉ là O(logN) (trong đó N là số nút Pastry sống trong mạng bao phủ). Tại mỗi nút Pastry dọc theo đường định tuyến mà một tin nhấn có, ứng dụng sẽ được thông báo và có thể thực hiện các tính toán ứng dụng cụ thể có liên quan đến tin nhắn.

Thứ hai, môi nút Pastry sẽ tiến hành theo dõi L hàng xóm trực tiếp của nó trong không gian nodeid (được gọi là tập lá) và thông báo cho các ứng dụng của các nút mới đến, nút ra và nút phục hồi trong tập lá. Thứ ba, pastry đưa vào tài khoản cục bộ trong Internet cơ bản, nó tìm cách giảm thiểu khoảng cách truyền đi thông điệp, theo một hệ mét xấp xỉ vô hướng giống như độ trễ lệnh ping. Pastry hoàn toàn là phi tập trung, có khả năng mở rộng và tự tổ chức. Bởi vậy nó sẽ tự động thích nghi với sự ra đi, đến và sự thất bại của các nút. ứng dụng P2P xây dựng trên pastry có thể sử dụng khả năng của mình bằng nhiều cách, bao gồm:



Ánh xạ đối tượng ứng dụng tới các nút Pastry: Các đối tượng ứng dụng cụ thể được phân công thành các định danh ngẫu nhiên đồng đều, duy nhất ( các ObjId) và được ánh xạ tới k (k ≥ 1), các nút với nodeId có số gần nhất với objId. Đại lượng k phản ánh mức độ mong muốn nhân rộng các ứng dụng cho các đối tượng.

Cách chèn them các đối tượng: Các đối tượng ứng dụng cụ thể có thể được them vào bằng cách đinh tuyến một thong điệp Pastry sử dụng ObjId như là khóa (key).

Quá trình truy cập các đối tượng: Các đối tượng ứng dụng cụ thể có thể được tra cứu, liên lạc hoặc thu hồi bằng cách định tuyến một thông điệp Pastry có sử dụng ObjId như là khóa. Theo định nghĩa, thong điệp này được đảm bảo đến một nút có khả năng duy trì một bản sao của đối tượng được yêu cầu, trừ khi tất cả k nút với các nodeId gần nhất với ObjId đều thất bại

Tính đa dạng: Việc phân công các nodeId là ngẫu nhiên và không thể bị hỏng bởi một sự tấn công nào đó. Như vậy, với xác suất cao, các nút với các nodeId liền kề có tính đa dạng cả về vị trí địa l , thẩm quyền, quyền sở hữu và việc đính kèm các tập tin trong mạng…Điều này giảm thiểu xác suất thất bại đồng thời của tất cả k nút trong việc duy trì một bản sao đối tượng.

Khả năng cân bằng tải: Cả nodeId và ObjId đều được phân bố ngẫu nhiên và đồng đều trong không gian định danh Pastry 128bit. Kết quả này tạo nên một sự cân bằng tốt đầu tiên nhằm lưu trữ các yêu cầu và truy vấn tải trọng giữa các nút Pastry cũng như trong mạng Internet cơ bản.

Hiệu quả và khả năng mở rộng việc phổ biến thông tin: Các ứng dụng có thể thực hiện multicast một cách hiệu quả bằng cách sử dụng chuyển tiếp đường dẫn ngược dọc theo cây được hình thành bởi các định tuyến từ các client tới nút có nodeId gần với ObjId nhất. Tính chất cục bộ của mạng Pastry đảm bảo rằng các kết quả multicast trên cây là khá hiệu quả, tức là dữ liệu có hiệu quả trong việc cung cấp và sử dụng nguồn tài nguyên Internet cơ bản.

Pastry là một giao thức phân phối dữ liệu và định tuyến ở lớp ứng dụng trong các ứng dụng mạng ngang hang có cấu trúc. Đúng như định nghĩa của nó, Pastry có 2 nhiệm vụ chính là phân phối dữ liệu trong một mạng ngang hang và tìm kiếm dữ liệu trong mạng dựa vào khóa tìm kiếm. Hệ thống Pastry là một hệ thống phân tán có khả năng tự cấu hình và có tính ổn định cao, khả năng chống chịu lỗi tốt, đồng thời nó cũng có khả năng mở rộng và ứng dụng cho những dịch vụ lớn.

Pastry sử dụng giao thức DHT để lấy định danh các nút tham gia vào hệ thống mạng. Với dải địa chỉ lớn thì giao thức DHT quả thực rất phù hợp với hệ thống mạng ngang hang, không ngoại trừ đối với Pastry. Tuy nhiên điều thú vị của Pastry nằm ở bảng định tuyến sẽ được mô tả dưới đây.



Hình 3.1 Bảng định tuyến của nút 10233102 trong Pastry

Nút và dữ liệu trong mạng Pastry được định danh bởi một giá trị 128bit (nodeId và ObjId). Mỗi dữ liệu lưu trữ trong mạng được băm bởi một hàm băm, từ đó thu được một giá trị gọi là khóa và dữ liệu này được lưu trữ tại nút quả lý dãy các khóa có chứa giá trị khóa này ( giá trị khóa thu được khi băm dữ liệu).

Mỗi nút trong mạng sẽ lưu trữ một bảng định tuyến (routing table) một tập các hàng xóm (neighborhood – set) và một tập namespace. Pastry dùng các dữ liệu này để quản lý và duy trì sự ổn định của mạng, đồng thời phục vụ cho việc tìm kiếm dữ liệu.

Ở hình 3.1 là bảng định tuyến của nodeId 10233102. Dựa vào bảng định tuyến này, nút 10233102 có thể gửi dữ liệu đến cho nút khác. Ví dụ 10233102 muốn gửi thông điệp m tới cho nút 33321220. Đầu tiên nó sẽ tìm trong các nút hàng xóm trong bảng định tuyến, nếu có sẽ gửi đến luôn. Nếu không tìm thấy nó sẽ tìm trong Routing Table và so sánh các ký tự ban đầu của nút cần gửi đến 33321220 với các cột trong Routing Table. Cụ thể là nút 33321220 có ký tự đầu là 3: nó sẽ tìm trong Routing Table tại hàng 1 cột 3 và tìm được nút 31203203. Do ngay từ ký tự đầu của nút cần gửi đã khác nút gửi nên quá trình tìm kiếm dừng lại. Nút 1023312 sẽ gửi đến nút 31203203 với yêu cầu sẽ gửi thông điệp m đến nút 33321220. Quá trình này tiếp tục xảy ra cho đến khi đến được nút cần gửi.



Hình 3.2 Nút 10233102 gửi thông điệp m đến nút 33321220

Các nút định kỳ gửi các gói tin keep-alive cho các nút bằng hàng xóm của nó và nếu như một nút nào đó không nhận được gói keep-alive của một nút bằng xóm trong tập hàng xóm của nó trong một thời gian nhất định thì nó sẽ xem như nút hàng xóm đã rời khỏi mạng và tự động update thông tin.

3.2 Qu tr nh truyền tin multicast trong nhóm Scribe

Scribe là cơ sở hạ tầng cho việc truyền tin multicast ở lớp ứng dụng dựa trên giao thức Pastry. Cũng chính vì thế mà nó thừa hưởng được những đặc tính của một giao thức mạng ngang hàng có cấu trúc và đồng thời mang những đặc điểm này vào trong việc truyền thông điệp multicast ở lớp ứng dụng. Giống như Pastry, Scribe là mô hình phân quyền hoàn toàn và nó có khả năng xây dựng, duy trì mạng, phát tán thông báo một cách có tổ chức và tin cậy. Đồng thời có tính tương thích cao với số lượng nhóm, số thành viên trong nhóm lớn cũng như khi có nhiều tài nguyên trên mạng.

Scribe sẽ xây dựng một cây multicast bằng cách gọi thủ tục join giao thức Pastry mỗi khi một nút có yêu cầu đăng nhập vào nhóm truyền tin multicast. Và nhờ khả năng tự cấu hình của Pastry mà vấn đề quản lý nút, nút lỗi cũng như ra vào của nút trở nên dễ dàng. Đồng thời, Scribe sử dụng giao thức Pastry để phát tán thông báo multicast. Scribe tổ chức theo nhóm, tức là hợp những nút có cùng nhu cầu nhận dữ liệu multicast vào một nhóm. Về mặt logic thì các nút trong nhóm sẽ có quan hệ với nhau theo hình cây (sẽ giải thích kỹ ở phần sau). Bất kỳ một nút nào trong mạng cũng có thể thực hiện được 3 thao tác: Một là tạo ra 1 nhóm (group), hai là join vào một



nhóm đã có từ trước (trở thành 1 nút trong cây multicast) và ba là truyền tin multicast tới tất cả các nút có trong nhóm. Scribe là một mô hình cung cấp một cách „nỗ lực tối đa” trong việc truyền tin multicast, nó có thể quản l và duy trì được nhiều nhóm cùng một lúc, các nhóm có số lượng thành viên lớn cũng như có nhiều tài nguyên trong mạng.

3.2.1 Chi tiết giải thuật

Mô hình

Mô hình thực thi Scribe là một mạng Pastry trong đó các máy có cài đặt chương trình ứng dụng của Scribe. Chương trình ứng dụng này sẽ cung cấp cho các máy này hai phương thức là forward (được gọi khi một thông điệp định tuyến qua một nút) và deliver (được gọi khi thông điệp đến một nút mà có nodeId gần với key nhất hoặc nội dung thông điệp chính là địa chỉ của nút đó). Các thông điệp trong Scribe có 4 kiểu là: JOIN (xin tham gia vào một nhóm), CREATE (tạo một nhóm mới), LEAVE (rời khỏi nhóm), MULTICAST (truyền thông điệp multicast).

- Quản lý nhóm:

Mỗi nhóm truyền multicast có một định danh groupId duy nhất.

Scribe node (tức là nút trong mạng có cài chương trình ứng dụng Scribe) có Id gần với Id của nhóm (groupId) nhất được gọi là “điểm gặp” và nó cũng chính là gốc của cây multicast tương ứng với groupId này luôn).

- Tạo nhóm: Một nút Scribe nào đó muốn khởi tạo một nhóm thì các bước thực hiện sẽ là:

B1: Nút Scribe dùng Pastry định tuyến thông điệp router (CREATE , groupId).

B2: Giao thức Pastry sẽ gửi thông điệp này tới điểm cuối là một nút có nodeId gần với groupId nhất. Và nút này sẽ được xem như là gốc của nhóm mới tạo ra.

B3: Hệ thống sẽ kiểm tra độ an toàn, các thông tin về chứng thực. Nếu không có vấn đề gì thì sẽ thêm nhóm mới vào danh sách nhóm đã biết trong mạng.

Trong việc tạo nhóm, bước quan trọng nhất chính là bước kiểm tra độ an toàn và chứng thực thông tin, vì điều này có ảnh hưởng rất lớn tới sự an toàn của toàn mạng nói chung chứ không chỉ riêng sự an toàn của nhóm multicast.

- Quản lý thành viên:

Một nhóm về phương diện logic là một cây multicast có gốc là “điểm gặp”, mỗi khi có một nút mới được join vào nhóm thì nó sẽ trở thành một thành viên của nhóm cũng như trở thành một thành phần của cây multicast, vì thế phải có cơ chế hợp l để tổ chức, quản lý các thành viên của nhóm. Nếu một nút Scribe là một phần của nhóm thì về phương diện cây multicast thì nó là một forwarder. Mỗi một forwarder duy trì một bảng gọi là children table mà mỗi mục của bảng này sẽ gồm 2 trường : địa chỉ IP của một nút con nào đó của nó (IP Adds) và nodeId tương ứng của nút con đó.



3.2.2 Qu tr nh gia nhập nhóm (join group):

Khi một nút muốn join vào một nhóm nào đó, nó sẽ thực hiện các bước sau:

Gửi thông điệp JOIN với groupId của nhóm cần tham gia làm key: route (JOIN, groupId).

Giao thức Pastry sẽ định tuyến nó tới “điểm gặp”.

- Nếu nút trung gian trong quá trình truyền thông điệp là một forwarder (một thành phần của nhóm đang định tham gia vào) thì đơn giản chỉ là thêm nút cần tham gia vào làm một nút con của nút forwarder này.

- Nếu nút trung gian không phải là một forwarder của nhóm cần tham gia vào thì thực hiện các bước:

+ Tạo một children table cho nút trung gian và thêm thông tin của nút cần tham gia vào bảng này.

+ Gửi thông điệp JOIN của nút trung gian tới “điểm gặp” ( lúc này thay cho việc thực hiện tham gia nút ban đầu, ta đi tham gia nút trung gian vào nhóm). Và cứ thực hiện đệ quy như thế này ta sẽ có được một danh sách các nút mới tham gia vào nhóm thay vì chỉ một nút như ban đầu.

Để dễ hiểu, ta xét ví dụ sau: Một nhóm có “điểm gặp” là A có nodeId = 1100 (như ở hình vẽ dưới).

Hình 3.3 Quá trình 1 nút gia nhập vào nhóm

Nút B có nodeId là 0111 muốn tham gia vào nhóm có A là gốc, nó sẽ gửi gói tin route (JOIN,x) với x là groupId của nhóm này, giao thức Pastry sẽ định tuyến gói tin tới nút D có nodeId là 1001. Nhưng nút D không phải là một thành phần của nhóm này cho nên D sẽ tạo ra một children table của nó và thêm vào đó mục (122.45.1.23 ; 0111). Tiế theo D sẽ gửi gói tin yêu cầu tham gia vào nhóm có gốc A : route (JOIN,x). Tiếp tục giao thức Pastry lại định tuyến nó tới nút E và E cũng không phải thành viên của nhóm này. Vì thế E cũng tạo ra một children table của nó và thêm mục (172.16.2.13; 1001). Và sau đó E gửi gói tin route (JOIN,x). Gói tin này tiếp tục được định tuyến và tới A vì A là một thành phần của nhóm cho nên ở đây A sẽ thêm mục



(10.10.1.123;1101) vào children table của nó. Kết quả là ta sẽ có thêm 3 thành phần mới của nhóm là B, D và E.

3.2.3 Quá tr nh rời nhóm (leave group)

Khi một nút nào đó muốn rời khỏi nhóm thì nó sẽ ghi một cách cục bộ rằng nó đã rời khỏi nhóm (tức là chỉ một mình nó biết là nó đã rời khỏi mạng). Sau đó nếu bảng children table của nút này là rỗng (tức là nó không có con trong cây multicast) thì nó sẽ gửi thông điệp LEAVE tới cha của nó trong cây multicast. Thông điệp này sẽ được đệ quy trong cây multicast cho tới khi nó tới một nút mà nút có con đã rời khỏi như trong trường hợp nó không có con nào cả. Sau đó các con của nó sẽ xem như nó bị lỗi và thực thi theo cơ chế sửa lỗi (sẽ trình bày ở dưới).

Với cách gia nhập và rời khỏi nhóm như thế này và với đặc tính phân phối ngẫu nhiên của Pastry thì cây multicast sẽ được xây dựng một cách đồng đều theo nghĩa là không một nút nào trong cây mutlicast, ngay cả nút gốc phải chịu quá nhiều kết nối tới các nút khác. Việc này giúp cho Scribe có khả năng mở rộng về kích thước cũng mhư về khả năng, tức là cả khi tăng số lượng nút trong nhóm hay tăng các gói tin multicast gửi đến mạng thì Scribe vẫn có thể đảm đương được.

3.2.4 Truyền tin multicast tới mạng

Khi một nút nào đó muốn truyền multicast tới các điểm trong một nhóm nào đó thì nó sẽ gửi thông điệp multicast tới “điểm gặp” (route (MULTICAST,rootId). Sau khi điểm gặp nhận được thông điệp này nó sẽ gửi trả lại nút kia IP của nó (rootIP), sau đó nút này sẽ truyền thông tin muốn gửi tới điểm gặp. Điểm gặp này sẽ sao chép gói tin multicast này và gửi cho các con của nó trong cây multicast ( nếu có ). Các điểm con này khi nhận được dữ liệu cũng lại tiếp tục sao chép dữ liệu đó và gửi tới các con của nó trong cây ( nếu có ). Cứ lặp đi lặp lại như vậy và chỉ dừng lại việc này khi dữ liệu tới các nút là nút lá của cây.

Hình 3.4 Truyền tin multicast trong nhóm Scribe

Giả sử như hình vẽ ở trên, Sender là nút cần gửi dữ liệu cho cây multicast có gốc là 1100. Nó sẽ gửi gói tin route (MULTICAST, 1100). Nút 1100 nhận được gói tin và



trả lại cho sender địa chỉ IP của nó. Từ lúc này sender giao tiếp với nút gốc này thông qua IP (bây giờ là quan hệ trong giao thức TCP/IP chứ không liên quan tới Pastry hay P2P). Sender gửi dữ liệu cho nút gốc 1100. Nút này sẽ tạo ra một bản sao dữ liệu và gửi cho con của nó là 1101. Nút 1101 nhận được dữ liệu từ root, nó cũng sẽ tạo ra một bản sao và gửi cho 1001 là con của nó. Nút 1001 lại sao chép dữ liệu và gửi cho 0111 và 0100 là thành viên trong children table của nó. Khi các nút 0100 và 0111 nhận được dữ liệu, do nó là lá của cây multicast nên nó không làm gì nữa.

Trong vấn đề truyền dữ liệu multicast này có một điểm thú vị là khi sender muốn gửi dữ liệu multicast tới nhóm của nó lại phải xin và nhận IP của nút gốc rồi để sau đó giao tiếp với nút này dựa vào IP mà không sử dụng giao thức Pastry để gửi dữ liệu. Đơn giản là việc định tuyến cũng như việc gửi thông tin qua Pastry là một việc làm rất tốn thời gian và tai nguyên mạng, mà bình thường một sender không chỉ gửi một gói tin multicast tới mạng mà nó gửi một số hoặc nhiều gói tin. Do đó việc sender lưu IP của nút root và gửi gói tin trực tiếp sẽ tiết kiệm được thời gian cũng như tài nguyên mạng. Tuy nhiên nếu nút gốc bị lỗi hoặc bị rời khỏi mạng thì sender phải tìm lại IP của nút root mới và tiếp tục truyền thông tin.

3.2.5 Sửa cây multicast

Vì Scribe làm việc trong môi trường mạng, do đó muốn duy trì được sự ổn định của nhóm thì cần phải có các cơ chế hợp l để giải quyết các vấn đề thường gặp phải trong mạng ngang hàng. Phần này sẽ đi sâu vào việc làm sao để sửa chữa một cây multicast khi một nút bị rời khỏi mạng.

Trong Scribe, nút cha sẽ định kỳ gửi các gói tin heartbeat tới nút con của nó nhằm thông báo sự tồn tại của mình trong cây. Nếu nút con không nhận được gói tin heartbeat do cha nó gửi tới trong một thời gian nào đó, nó sẽ xem như nút cha của nó bị lỗi. Và nó sẽ tự động tìm một nút cha khác thay thế, bằng cách gửi thông điệp JOIN với key là groupId của nhóm hiện tại (quá trình này giống như quá trình gia nhập vào nhóm).

Hình 3.5 Quá trình tự sửa câymulticast



Giả sử như hình vẽ trên, ban đầu ta có cây multicast với gốc là nút 1100, trong cây nút 1001 có cha là nút 1101. Khi nút 1001 không nhận được heartbeat của 1101 trong một khoảng thời gian nào đó, nó sẽ xem như 1101 bị lỗi và nó sẽ tự động gửi gói tin route (JOIN,groupId). Tiếp theo giống như trong quá trình gia nhập nhóm. Cây multicast sẽ được xây dựng lại và bây giờ thì nút 1001 nhận một nút mới là 1111 là cha mới của nó (như hình vẽ).

Trong trường hợp nút gốc bị lỗi thì các con của nó cũng chạy giải thuật như trên. Khi đó giải thuật Pastry sẽ tự chọn ra một nút gốc mới có nodetId gần nhất (tính theo hiện thời) với groupId và nhóm sẽ lại được duy trì như bình thường.

Vì khả năng chống lỗi cao như thế này, Scribe luôn có tính sẵn sàng cao và chống chịu lỗi tốt, cho dù có nhiều nút lỗi cùng một lúc thì sau một thời gian ngắn cây multicast lại được xây dựng lại và ổn định như trước.

3.3 Cải thiện Scribe bằng cấu trúc Splitstream

Hiện nay, đã có những nghiên cứu xây dựng cây multicast dành cho truyền video streaming trên mạng ngang hàng có cấu trúc như Splitstream. Splitstream được xây dựng dựa trên nền tảng Pastry, Scribe và thêm vào đó một số giải pháp để hạn chế tình trạng quá tải tại một số nút tham gia mạng

3.3.1 Giới thiệu SplitStream

SplitStream là một hệ thống cây đa luồng đề xuất trong năm 2003 của trung tâm nghiên cứu của Microsoft. SplitStream được thiết kế để khắc phục tải trọng (load) chuyển tiếp không ổn định trong hệ thống multicast thông thường dựa trên đa cây. Ý tưởng chính của SplitStream là phân chia các luồng vào các khối độc lập không giống nhau và mỗi khối được truyền multicast sử dụng một cây riêng biệt. Để đảm bảo rằng các tải trọng được chuyển tiếp có thể được lan truyền trên tất cả các peer tham gia, một mạng lưới cây được xây dựng trong đó một nút là một nút nội bộ trong nhiều nhất là một cây và là một nút lá trong tất cả các cây khác. Một tập hợp các cây như vậy được gọi là interior – node - disjoint. Hình 3.6 minh họa cách SplitStream cân bằng tải được chia thành hai đường và gói tin được multicast trong hai cây riêng biệt. Mỗi peer, xa so với nguồn, nhận được cả hai luồng tin. Mỗi peer là một nút bên trong chỉ có một cây và là chuyển tiếp các khối nội dung đến hai nút con. Khi một nút bị quá tải nhận được yêu cầu từ nút con, nó hoặc là từ chối hoặc chấp nhận nút con và từ chối một nút con hiện tại của mình, nút con bị từ chối là kém hấp dẫn hơn so với nút con mới. Một nút sẽ được mong muốn nhiều hơn nếu nodeId của nó gần hơn với nút cha của nó.

SplitStream xây dựng các cây multicast cho các luồng trong khi vẫn quan tâm những hạn chế băng thông trong và băng thông bên ngoài của các peer. Nó cung cấp khả năng phục hồi thất bại các liên kết nút ra đi không báo trước và cây multicast được sửa chữa. Một trong những vấn đề chính với SplitStream là tác động của các nút



với băng thông không đồng nhất về hiệu quả của nó. Một vấn đề khác là trong một interior – node - disjoint, các nút nhận gói tin riêng biệt với độ trễ khác nhau ví dụ như các nút được đặt trong khoảng cách khác nhau từ gốc của cây. Điều này là không mong muốn cho một ứng dụng luồng truyền thông trực tuyến, trong đó việc đòi hỏi thời gian thực chính xác. Thêm vấn đề khác là tăng cường quy mô hệ thống để cây có độ sâu lớn hơn và các nút được đặt trong khoảng cách đa dạng từ nguồn.

Hình 3.6 Một ví dụ đơn giản minh họa cách tiếp cận của SplitStream

3.3.2 Cơ chế xây dựng luồng trong SplitStream

Splitstream có thể được xem như là việc chọn lựa các cây Scribe để tạo nên cây multicast đa luồng. Việc lựa chọn các cấy Scribe sẽ dễ dàng tạo nên cây mulitcast đa luồng với tính chất: 1 nút là nút trong của 1 luồng sẽ là nút lá trong các luồng còn lại.

Hình 3.7 Splitstream F luồng

Việc xây dựng các luồng khá đơn giản. Như ở trên hình 3.7, với không gian Pastry được đánh địa chỉ các nút gồm F ký tự. Splitstream sẽ chọn ra các luồng có tên là 0x, 1x, …, Fx để các nút sau khi gia nhập vào cây multicast đa luồng có thể đảm bảo. Nút có Id bắt đầu là 0x sẽ là nút trong của cây multicast stripeId 0x và là nút lá của tất cả



các luồng còn lại. Tương tự nút có Id bắt đầu là 1x sẽ là nút trong của cây multicast stripeId 1x và là lá của tất cả các luồng còn lại.

Tuy nhiên, Splitstream sẽ gặp các vấn đề tại các máy (peer) tham gia nếu chỉ đơn thuần lựa chọn các cây Scribe để truyền các luồng vào thì là chưa đủ đáp ứng tính chất multicast.

- Không giới hạn được băng thông đi ra của 1 peer do như cầu join của các peer khác: khi 1 peer đã vượt quá băng thông giới hạn đi ra thì các peer khác vẫn muốn gia nhập vào luồng của các peer này. Nếu vẫn duy trì cơ chế như cây Scribe thì sẽ có một số peer thật sự không nhận được dữ liệu từ 1 vài luồng do nút cha của nó không gửi dữ liệu thực sự đến cho nó.

Splitstream sử dụng cơ chế mới để giải quyết vấn đề tại các nút mà băng thông đi ra đã bị vượt quá giới hạn. Cơ chế này bao gồm:

-B1 : Xác định nút cha:

H nh 3.8 X c định nút cha khi băng thông đi ra vƣợt quá giới hạn

Trong ví dụ trên nút với Id là 080* đã bị limit outdegree (băng thông đi ra vượt quá giới hạn) thì nhận được yêu cầu join vào của nút với Id 001* ở luồng 0800. Nút 080* sẽ xem xét tất cả các nút con của nó để loại đi 1 nút con. Hình 3.8 (1) – (2) là trường hợp có nút con 9* nhận được nút 080* làm cha trong luồng 1800 khác với luồng 0800. Nút 080* sẽ nhận được nút 001* làm con và loại bỏ nút 9*. Sau đó nút 085* lại yêu cầu join vào nút 080*. Hình 3.8 (3) – (4) là trường hợp các nút con đều nhận 080* là cha trong luồng 0800, xét đến Id của các nút con. Nút 001* là nút có Id với số ký tự tính từ trái sang phải khác với luồng 0800 nhất. Nút 001* sẽ trở thành nút orphan và nút 085* được nhận làm nút con.



- B2: Nếu sau bước 1 vẫn có nút orphan (tức là nút chưa tìm được nút cha) sẽ tiến hành bước này. Nút orphan sẽ gửi unicast đến SCG (Spare Capacity Group) để tìm được nút cha. SCG là tập hợp tất cả các nút mà băng thông đi ra chưa vượt quá giới hạn. Với cơ chế truyền tin unicast, nút orphan sẽ gửi thông điệp tìm nút có luồng mà băng thông đi ra chưa vượt quá giới hạn để nhận nó làm nút cha.

Ƣu điể m : Xây dựng cây multicast đa luồng khá đơn giản dựa vào kết cấu sẵn có của Pastry và Scribe. Khi mạng ổn định và việc phân chia định danh là khá đều thì các nút trong hệ thống chịu quá tải tương đương nhau. Thêm vào đó là các cơ chế tìm nút cha nhằm đảm bảo các nút trong mạng không bị quá tải.

Nhƣợc điể m : Không đảm bảo được độ chênh lệch độ trễ các luồng nhận được tại các nút là nhỏ, do việc tạo cây Scribe mang tính ngẫu nhiên dựa chủ yếu vào kết cấu bên dưới của Pastry.

3.4 Kết luận chƣơng IIIChương này nhằm giới thiệu về Pastry, nền tảng xây dựng của giao thức Scribe.

Đồng thời mô tả quá trình gia nhập, rời nhóm, truyền tin multicast tới mạng và quá trình sửa cây multicast trong Scribe. Từ đó đưa ra được các ưu nhược điểm của giao thức Scribe trong việc truyền tin multicast lớp ứng dụng so với IP multicast. Giới thiệu kỹ thuật SplitStream qua đó áp dụng vào giao thức Scribe nhằm khắc phục những nhược điểm của giao thức Scribe, tạo một hệ thống cây multicast đa luồng.

Đồ án tốt nghiệp đại kết luận đồ


KẾT LUẬN ĐỒ Á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 này đã trình bày một cách ngắn gọn về nghiên cứu multicast lớp ứng dụng cho truyền video thời gian thực trong mạng ngang hàng P2P, cụ thể là cải thiện giao thức Scribe. Tuy nhiên việc triển khai multicast lớp ứng dụng vẫn chưa thực sự đáp ứng được các yêu cầu của P2P video streaming thời gian thực, ví dụ như sự ra vào của các nút, độ trễ lớn. Hơn nữa các giải pháp này còn chưa xét đến vấn đề các nút không đóng góp.

Với những kết quả đạt được và những mặt còn tồn tại, sau đây là một vài hướng phát triển tiếp theo:

Khắc phục những nhược điểm nêu trên. Sử dụng phần mềm OverSim so sánh đánh giá hiệu năng giữa Scribe và

SplitStream. Nghiên cứu cải thiện QoS khi truyền video streaming qua mạng P2P.

Một lần nữa em xin chân thành cảm ơn cô giáo Vũ Thị Thúy Hà đã hướng dẫn em, cùng các thầy cô bộ môn đã tận tình giúp đỡ em trong thời gian học tập tại trường để em có đủ kiến thức để có thể hoàn thành đồ án này.

Đồ án tốt nghiệp đại Tài liệu tham


Tài li ệ u ti ế ng Vi ệ t:

TÀI LIỆU THAM KHẢO

1. Bùi thị Lan Hương: Luận văn thạc sĩ “Phương pháp multicast tầng ứng dụng dựa trên cơ chế kéo đẩy cho truyền video thời gian thực trên mạng P2P”.

2. Nguyễn Văn Minh: Luận văn tốt nghiệp “Truyền tin multicast đa luồng thời gian thực trên mạng ngang hàng có cấu trúc”.

3. Nguyễn Ngọc Anh, “Topology Optimization for DTH-based Application Layer Multicast”, Trường đại học Công Nghệ, 2012.

4. ThS. Vũ Thị Thúy Hà, TS. Lê Nhật Thăng, bài báo”Định tuyến trong mạng ngang hàng thế hệ mới”.

Tài li ệ u ti ế ng Anh:

1. Antony Rowstron and Peter Druschel: “Pastry: Scalable, deccentralized object location and routing for lagre – scale peer – to – peer systems”.

2. Bin Rong, “Video Streaming over the Internet using Application Layer Multicast”, RMIT University, 2008.

3. Chung-Yan Chen, Yu-Wei Chen, “Design and Analysis of Streaming for P2P”, Graduate Institute of Information and Logistics Management, National Taipei University of Technology, 2013.

4. Luca Abeni, Csaba Kiraly, Renato Lo Cigno, “Scheduling P2P Multimedia Streams: Can we achieve performance and robustness?”, 2009 IEEE.

5. L. Abeni, C. Kiraly, R. Lo Cigno, “Achiving performance and robustness in P2P streaming systems”, University of Trento, Italy, Tech. Rep. TR-DISI-09- 041, 2009.

6. Indrani Gupta, Ken Binman, Prakash Linga, Al Demers, Robbert van Renesse:” Peer – to – Peer Networks: Kelips”.

7. Xuemin Shen, Heather Yu, John Buford, Mursalin Akon, “Handbook of Peer- to-Peer”, Springer 2009.

Xay Dung Ung Dung Video Streaming Qua Mang p2p 9024 2

Documents

Transcript of Xay Dung Ung Dung Video Streaming Qua Mang p2p 9024 2