Đã có nhiều hệ thống P2P cho VoD được phát triển. Phần dưới đây giới thiệu một vài hệ thống chính và các kỹ thuật đã được áp dụng.
1.3.4.a. GnuStream
GnuStream [28, 29] là một ứng dụng VoD được xây dựng dựa trên Gnucleus - một phần mềm client mã nguồn mở dành cho mạng Gnutella (mạng P2P thuần nhất). GnuStream sử dụng mạng của Gnutella. Khi người dùng muốn xem một video cụ thể, GnuStream sẽ tìm kiếm trên mạng của Gnutella thông qua Gnucleus client và trả về một số kết quả tìm kiếm. Video sẽ được download từ nhiều peer đồng thời và được phát lại từ bộ đệm (buffer). Những kỹ thuật đã được áp dụng trong Gnustream bao gồm:
- Tạo bộ đệm (buffering) để đối phó với những vấn đề biến thiên độ trễ mạng, các dữ liệu đến sai trình tự và mất kết nối với các peer cung cấp.
- Sử dụng các peer dự phòng (backup peers) để đề phòng trường hợp các peer rời hệ thống hoặc có sự suy giảm băng thông.
- Tăng kích thước bộ đệm hiển thị (display buffer) lên gấp đôi để làm giảm thời gian chờ giải mã và hiển thị.
- Truy xuất dữ liệu đa nguồn (multi-resource retrieving) với phân bổ đều hoặc theo mức độ đóng góp. Phân bổ theo mức độ đóng góp dựa trên năng lực của seeding peer, bao gồm cả băng thông download.
GnuStream dựa nhiều vào mạng Gnutella, làm cho việc tìm kiếm các peer chia sẻ dữ liệu trở nên khó khăn. Một hạn chế khác của kiến trúc mạng Gnutella là đã sử dụng kỹ thuật truy vấn phát tràn (flooding) để tìm kiếm nội dung.
1.3.4.b. P2Cast
P2Cast [13]là một ý tưởng kết hợp giữa multicast tầng ứng dụng và mạng ngang hàng. Hệ thống P2Cast tự tạo ra một mạng phủ riêng; một cây multicast tầng ứng dụng ALMT (xem phần 1.2.1.b) và đồng thời cả ứng dụng P2P streaming. Tuy nhiên vì có sự khác biệt giữa live streaming và on demand streaming nên P2Cast không thể đơn giản kết nạp các client tham gia muộn vào cây ALMT. Bởi vậy P2Cast phải áp dụng kỹ thuật patching cho các client này.
Khi có một client mới N muốn xem một video, nó cần trở thành một phần của cây ALMT đang phát video đó. Để tham gia vào ALMT nó phải liên lạc với server (seeder gốc của video). Server sau đó sẽ thực hiện một giải thuật tiếp nhận client (client admission algorithm) như sau:
Giải thuật tiếp nhận Client của P2Cast
1: Cho rằng ước lượng băng thông của I tới N là B(I,N) và đợi cho tất cả các nút con của nó trên cây cơ sở C(I) thông báo thông báo băng thông của chúng tới N và trở lại
cho I là B(Cj,N)
2: Cmax = argmaxC∈C(I){B(C,N)}
3: if B(I,N) > Cmax ^ I có thể hỗ trợ ít nhất một stream then
4: if N chỉ cần stream cơ sở then
5: N tham gia vào cây cơ sở và nhận I làm nút cha 6: else
7: I trở thành patch server cho N
8: if I có đủ băng thông còn lại cho stream cơ sở then
9: N tham gia cây cơ sở và nhận I làm nút cha 10: else
11: N tham chiếu tới Cmax thực hiện giải thuật này 12: end if
13: end if
14: else
15: N tham chiếu tới Cmax thực hiện giải thuật này 16: end if
Hình 1.3.4.b-1: Giải thuật tiếp nhận Client của P2Cast
Khi một client muốn xem một video nó cần trở thành bộ phận của cây ALMT. Để trở thành bộ phận của cây multicast thì client mới phải tham gia tiến trình tiếp nhận client bằng cách liên lạc với một server thông qua phiên batching gần đây nhất. Nút có băng thông sẵn sàng cao nhất dành cho client mới sẽ trở thành nút cha của client này. Ngược lại client sẽ được chỉ định tới một client khác của server và thực hiến tiến trình lựa chọn tương tự (theo kiểu đệ quy). Nếu client không phải là client đầu tiên của phiên này nó cần đến phần còn thiếu (patch) được lấy từ một patch server. Tiến trình lựa chọn patch server cũng giống như tiến trình tiếp nhận client. Để giảm thời gian chờ của client thì tiến trình tiếp nhận client và tiến trình lựa chọn patch server được thực hiện đồng thời.
Câu hỏi đặt ra là tại sao P2Cast lại phải sử dụng các kỹ thuật batching và patching? Trái với kỹ thuật multicast tầng mạng thì multicast tầng ứng dụng có thể gửi stream từ thời điểm bắt đầu cho mọi nút mới tham gia. Tuy nhiên điều này làm tăng thêm đòi hỏi đối với các nút trên cây là phải có đủ bộ đệm trống để giữ một bản sao của toàn bộ stream. Lý do khác để sử dụng kỹ thuật patching là P2Cast không nối theo dây truyền patch stream, điều này giúp hạn chế khả năng patch stream bị gián đoạn.
Các thử nghiệm đã cho thấy rằng:
1. Việc đưa thêm thông tin về độ trễ mạng để tính toán trong quá trình xây dựng cây là tốt hơn dưới góc độ xác suất từ chối kết nối client (client rejection) và hiệu quả sử dụng mạng (network usage). Tuy nhiên điều này lại làm tăng thêm gánh nặng cho server.
2. Việc tăng ngưỡng bộ đệm cho batching làm giảm xác suất từ chối kết nối client nhưng lại làm tăng thêm yêu cầu về không gian lưu trữ của client. Xác suất từ chối client giảm nhanh khi ngưỡng thấp hơn 20% của độ dài video.
3. Thời gian trễ ban đầu phụ thuộc nhiều vào số lượng client thành viên mà client mới phải liên lạc trước khi được tiếp nhận. Điều này dẫn tới phải có bước ước lượng băng thông trong giải thuật tiếp nhận client. Có một cách để hạn chế số client thành viên là giảm ngưỡng batching.
4. Bởi vì patch-stream và base-stream được download đồng thời, patch stream có thể đóng vai trò là bộ đệm cho base-stream.
5. Vì độ dài của patch-stream thường ngắn nên khả năng patch-strean bị gián đoạn là nhỏ. Hơn nữa khi patch-stream không được phát multicast hoặc theo dây truyền thì khả năng để client nhận được patch-stream là lớn hơn nhiều. Điều này dẫn tới thực tế là patch stream chỉ dựa trên sự sẵn sàng của client yêu cầu và gửi yêu cầu, các liên kết giữa các client và không dựa trên gì khác.
1.3.4.c. BiToS
Hình 1.3.4.c-1: Cơ chế hoạt động của BiTos.
Trước những thành công rất ấn tượng của BitTorrent (một trong các phần mềm chia sẻ file phổ biến nhất hiện nay), đã có nhiều ý tưởng về việc xây dựng hệ thống VoD dựa trên mô hình của BitTorrent được đề xuất. BiToS [17] là một trong những đề xuất đầu tiên cho ý tưởng này. Các tác giả khẳng định rằng chỉ cần một thay đổi nhỏ cho giao thức BitTorrent thì có thể chuyển thành dịch vụ truyền video theo yêu cầu. Theo đề xuất của họ thì thay đổi cơ chế lựa chọn phân mảnh là thứ duy nhất cần thay đổi so với giao thức ban đầu.
Dưới đây là cơ chế lựa chọn phân mảnh của BitTorrent [4]:
1. Các phân mảnh được chia thành các mảnh con để phục vụ cho download, ngay khi có một mảnh con nào đó nhận được yêu cầu download thì các mảnh con thuộc cùng phân mảnh này cũng sẽ nhận được yêu cầu download trước các phân mảnh khác. Điều này để đảm bảo rằng sẽ sớm có các mảnh đầy đủ sẵn sàng, bởi vì chỉ có các mảnh đầy đủ mới có thể đem ra để trao đổi (bargain).
2. Chừng nào mà chưa download được đầy đủ các mảnh (và như vậy chưa có gì để đem ra trao đổi) thì các mảnh được chọn ngẫu nhiên. Cần phải làm như vậy bởi nếu các mảnh hiếm được nhiều peer truy cập download đồng thời thì có thể tốc độ download của các peer nhận được sẽ giảm. Nếu có một peer nào đó chọn download các mảnh hiếm này trước, thì khoảng thời gian trước khi nó có thể đem ra trao đổi phân mảnh (đầy đủ) có thể tăng lên và như vậy làm giảm thời gian download tổng thể.
3. Ngay khi toàn bộ mảnh đầu tiên được download, chính sách áp dụng được thay đổi thành mảnh hiếm nhất trước (rarest first). Chính sách này lựa chọn các mảnh mà có trên các peer láng giềng là ít nhất. Điều này có lợi ở chỗ các mảnh hiếm nhất có thể đem ra trao đổi với nhiều user khác.
Cơ chế chọn mảnh này không phù hợp với mô hình truyền video theo yêu cầu, bởi vì trong VoD sẽ có sự giới hạn về thời gian (deadline) cho các phân mảnh. Các phân mảnh thuộc về phần đầu của stream rõ ràng là có deadline sớm hơn các phân mảnh thuộc về phần cuối của stream. Cơ chế lựa chọn phân mảnh của BitTorrent không tính đến điều này. Cũng có ý kiến cho rằng chỉ cần đơn giản chọn các mảnh một cách tuần tự là xong. Tuy nhiên có vấn đề khác cần phải xét đến, các client tham gia muộn sẽ không có gì để đem ra trao đổi với các client tham gia trước nó. Điều này sẽ gây ảnh hưởng làm hỏng kỹ thuật trao đổi Tit-For-Tat (ăn miếng trả miếng) của BitTorrent.
BiTos đưa ra một cơ chế chọn phân mảnh trong đó có tính đến deadline của các mảnh. Để làm việc này nó chia các phân mảnh còn chưa được download thành hai tập. Một tập có mức ưu tiên cao bao gồm các mảnh sắp được phát bởi chương trình media player. Một tập khác, gọi là tập các mảnh còn lại, bao gồm các mảnh vẫn chưa được download. Một tham số hệ thống, xác suất p, xác định khả năng một phân mảnh thuộc tập có mức ưu tiên cao được lựa chọn là 1-p. Xác suất của p có thể được điều chỉnh động thích ứng với các điều kiện khác nhau. Một khi đã biết được phải chọn một phân mảnh từ một tập cụ thể nào, ta có thể áp dụng cơ chế lựa chọn phân mảnh của BitTorrent, cơ chế chọn mảnh hiếm nhất trước (rarest first). Như vậy chỉ cần một thay đổi nhỏ cho cơ chế mảnh hiếm nhất trước, đó là nếu có hai hoặc nhiều hơn các mảnh có cùng mức độ hiếm thì mảnh nào gần với deadline hơn sẽ được chọn.
Hình 1.3.4.c-2: Cơ chế chọn mảnh của BiTos.
Tuy nhiên có một vấn đề là giá trị của tham số p có thể tác động lớn đến hiệu năng của giải thuật. Nếu như p được đặt là một giá trị lớn, chỉ có một số ít của các phân mảnh thuộc tập có mức ưu tiên thấp được download và client sẽ chỉ có ít mảnh để trao
đổi. Tuy nhiên nếu p được đặt giá trị nhỏ thì chỉ có một số ít các mảnh thuộc tập có độ ưu tiên cao được download và client không thể theo kịp được tốc độ phát hình. Như vậy khó khăn chủ yếu của BiTos là việc xác định tham số xác suất p tối ưu là điều không dễ dàng.
Một hạn chế nữa của BiTos là không có video server hỗ trợ download để đảm bảo việc phân phối phân mảnh được kịp thời. Nhiều kết quả đánh giá khác nhau đã chỉ ra rằng có ít nhất 5% của các phân mảnh không nhận được đúng lúc, điều này đã khiến cho chất lượng dịch vụ bị suy giảm.