Dựa theo cách tổ chức phân cụm như trên, giả sử rằng Tracker tự động cập nhật dữ liệu thông tin về các bảng định tuyến BGP một cách định kỳ. Trong peerlist mà tracker gửi cho các receiver đều có chứa địa chỉ IP cùng với tiền tố mạng của các peer tương ứng. Vì vậy khi nhận được peerlist mỗi receiver đều có thể tự xác định được nó thuộc về nhóm mạng nào. Sau đó receiver sắp xếp lại các peer trong danh sách theo các nhóm từ cluster nhỏ nhất trước rồi đến cluster lớn hơn và sau cùng là các peer bên ngoài. Quá trình tìm kiếm các phân mảnh video của receiver cũng thực hiện theo đúng trình tự như vậy. Ưu điểm của việc ưu tiên download từ các peer trong cùng cluster ngoài việc dữ liệu phải truyền qua ít chặng, thời gian truyền tải ngắn, giảm biến thiên độ trễ (jitter), thì còn hạn chế được khả năng bị tường lửa ngăn chặn khi phải truy cập sang các mạng khác.
Lấy ví dụ, nếu chúng ta có các peer P1, P2, P3, P4 và P5 như mô tả ở phần trên. Khi P1 nhận được peerlist thì nó sẽ tự sắp xếp lại như sau: P2 (thuộc cũng nhóm
P5 P4 P3 P2 P1 128.2.10.11 128.2.11.43 128.10.3.60 128.10.3.100 128.10.7.22 Network cluster 128.10.3.0/24 128.10.0.0/16 128.2.0.0/16 Cluster ID
128.10.3.0/24 với P1); P3 (cùng nhóm 128.10.0.0/16 với P1, P2); P4, P5 (thuộc các nhóm bên ngoài). Dựa theo danh sách đã được sắp xếp như trên, client gửi yêu cầu lần lượt cho P2, rồi đến P3, nếu không nhận được trả lời nó gửi cho P4, rồi đến P5; sau cùng mới phải truy cập vào Video server.
2.2.2. Cập nhật chỉ mục
Đối với những peer mới đăng nhập vào hệ thống (receiver) thì trước hết cần phải xác định được một danh sách các peer đang lưu giữ các phân mảnh của video yêu cầu (gọi là các sender), sau đó receiver mới có thể kết nối đến sender để download. Danh sách sender được xác định thông qua chỉ mục (index) lấy từ Tracker. Dựa vào chỉ mục có thể biết được những peer nào đang lưu giữ các phân mảnh của file video liên quan. Bởi vì ban đầu các peer đều phải liên lạc với Tracker để nhận peerlist và đều phải gửi thông báo cho Tracker sau mỗi lần download được một phân mảnh video. Tuy nhiên, do tính chất biến động của môi trường mạng ngang hàng cho nên danh sách trả về cho receiver không phải lúc nào cũng được cập nhật nghĩa là vẫn có những peer không còn kết nối với hệ thống (offline). Việc hạn chế các peer offline trong danh sách trả về là cần thiết, bởi vì qua đó làm giảm thời gian tìm kiếm cho receiver và đồng thời cũng giảm được các thông báo dư thừa. Đối với hệ thống mà chúng ta đang xây dựng việc cập nhật cho các chỉ mục được dồn toàn bộ về cho máy chủ. Mặc dù đã có một số kỹ thuật duy trì tính cập nhật của chỉ mục, tuy nhiên server không phải lúc nào cũng biết được chắc chắn trạng thái của một peer cụ thể. Trường hợp nếu như peer ngắt kết nối một cách đúng đắn thì chương trình phần mềm chạy trên client phải gửi thông báo logoff cho server. Thực tế có nhiều nguyên nhân khiến cho peer mất kết nối và không thể gửi thông báo (phần mềm hoặc phần cứng của peer bị sự cố, đường truyền bị tắc ngẽn hoặc bị lỗi, các thông báo đến trễ hoặc thất lạc…). Việc kiểm tra trạng thái kết nối của các peer trên toàn mạng trong thời gian thực là điều rất khó có thể thực hiện được. Thay vào đó chúng ta có thể tiến hành kiểm tra và cập nhật cho cho peerlist của Tracker theo thời điểm hoặc theo sự kiện. Theo sự kiện là khi nhận được thông báo logoff từ phía client, peer tương ứng trong danh sách coi như là offline. Còn theo thời điểm là kiểm tra danh sách mỗi khi nhận được yêu cầu gửi peerlist từ phía client. Dựa vào đặc điểm của mô hình đang xây dựng trong đó các peer phải thường xuyên gửi thông báo cho tracker mỗi khi download xong một phân mảnh video. Do các phân mảnh đều có độ dài bằng nhau (giả sử là SegDur phút video) nên với chất lượng phát hình bình thường thì định kỳ sau SegDur phút mỗi peer phải download được một phân mảnh và gửi thông báo lại cho Tracker được biết. Về phía Tracker, mỗi khi nhận được một thông báo báo cáo, nó sẽ ghi lại thời gian nhận được thông báo tương ứng của mỗi peer. Cho rằng những peer mà không thể nhận được thông báo trong khoảng thời gian 2*SegDur là đã offline (trừ trường hợp peer đã gửi thông báo download xong phân mảnh cuối). Trước mỗi lần gửi peerlist, Tracker đều kiểm tra và lọc bỏ các peer offline và chỉ nhập trở lại danh sách khi nào nhận được thông báo report từ những peer này.
Điều này giúp cho peerlist mà Tracker gửi tới receiver luôn được cập nhật và chỉ bao gồm các peer đang online.
Về vấn đề tải thông báo của Tracker, chúng ta có thể đánh giá như sau. Các thông báo thống kê là những thông báo ngắn (sử dụng giao thức TCP), được các peer gửi trong chu kỳ khoảng một vài phút (tùy theo độ dài của video segment). Giả sử rằng trong hệ thống đang có 1000 peer truy cập đồng thời và video được chia thành các phân mảnh có độ dài SegDur = 2 phút. Thông báo COMPLETE_SEG được gửi định kỳ từ phía client có kích thước 48byte (20 byte IP header + 20 byte TCP header + 2 byte mã thông báo + 4 byte mã videoID + 2 byte số thứ tự segment). Do đó lưu lượng thông báo mà tracker phải nhận là: (1000 x 48 x 8)/(2 x 60) = 3.12Kb/s. Tracker cũng phải gửi các thông báo xác nhận cho mỗi peer, mỗi thông báo có kích thước 40 byte (không chứa dữ liệu, chỉ đặt giá trị bit ACK trong phần TCP header). Như vậy lưu lượng thông báo gửi đi của tracker là: (1000 x 40 x 8)/(2 x 60) = 2.6Kb/s. Thông qua một tính toán đơn giản như vậy cũng có thể thấy là tải thông báo cập nhật đối với tracker cũng chỉ khá nhỏ. Do đó chúng ta có thể áp dụng kỹ thuật cập nhật chỉ mục này cho tracker mà không phải lo ngại nhiều về vấn đề quá tải.
2.3. Phân phối và lƣu đệm dữ liệu
Trong hệ thống PPVoD, để đạt được hiệu quả phân phối dữ liệu, ban đầu server chia nhỏ file video thành các phân mảnh (segment) có kích thước bằng nhau và phân phối cho các peer khác nhau trong hệ thống. Việc phân phối các phân mảnh như vậy có những ưu điểm là:
- Sau khi các phân mảnh được phân phối cho các peer thì file video sẽ được lưu giữ trên mạng chứ không chỉ trên một server riêng rẽ. Như vậy nếu như có một vài peer lưu trữ các phân đoạn video rời hệ thống hoặc bị lỗi mất kết nối thì phần còn lại của các phân đoạn vẫn có thể được truy cập, do đó tính sẵn sàng phục vụ của hệ thống được tăng lên.
- Việc phân tán các file video trên toàn mạng không chỉ giúp giảm tải mà còn giảm yêu cầu về bộ nhớ lưu trữ đối với server. Khi cần thiết có thể xóa file video khỏi server mà khả năng phục vụ của hệ thống vẫn được duy trì. Kết quả là chi phí đầu tư cho bộ nhớ lưu trữ của hệ thống cũng được giảm bớt.
- Khi các phân mảnh của một video được lưu giữ bởi nhiều peer thì một yêu cầu streaming đối với một video cụ thể sẽ được đáp ứng bởi những peer ở các vị trí khác nhau, điều này giúp làm giảm bớt gánh nặng sreaming ra khỏi một vài peer đơn lẻ.
Về phía client, mỗi khi download được một segment thì client (receiver) đều phải lưu lại vào bộ nhớ chia sẻ. Việc lưu đệm như vậy đem lại hai lợi ích:
- Thứ nhất vì xác suất được xem lại của segment vừa xem xong là cao hơn so với những segment khác.
- Thứ hai là các peer truy cập vào sau để xem video có thể download lại segment từ peer này và qua đó giúp giảm tải cho server.
Tuy nhiên, vì phần bộ nhớ chia sẻ của mỗi peer đều có hạn nên để lưu lại segment trước hết receiver sẽ phải kiểm tra xem còn đủ bộ nhớ sẵn sàng (StAvail ≥ seg_size, trong đó seg_size là kích thước của segment). Nếu có đủ, nó sẽ lưu lại segment nhận được và giảm giá trị của StAvail như sau: StAvail = StAvail – seg_size. Ngược lại thì chiến lược LRU (Least Recently Used) sẽ được áp dụng, tức là trong trường hợp không còn bộ nhớ trống thì peer sẽ xóa đi các phân mảnh cũ nhất để dành chỗ cho những phân mảnh mới nhất. Những phân mảnh cũ nhất ở đây được hiểu là được tải về từ các peer khác sớm nhất.
2.4. Tạo dòng truyền tải video streaming
Trong hệ thống, khi một receiver (bên nhận) có nhu cầu truy cập video, trước hết receiver sẽ phải tìm kiếm segment đầu tiên của video sau đó kết hợp băng thông từ các peer đã được lựa chọn để tạo dòng truyền tải (streaming). Việc kết hợp băng thông từ nhiều peer cung cấp như vậy có những thuận lợi bao gồm:
(1) Vì các peer vốn không đồng nhất, nên một peer riêng rẽ có thể không cung cấp đủ băng thông cho phiên streaming, trong trường hợp này cần phải kết hợp băng thông từ nhiều peer khác nhau.
(2) Sự kết hợp băng thông từ nhiều peer cung cấp làm tăng tính ổn định cho phiên streaming, bởi trong phiên nếu có một vài peer rời hệ thống hoặc bị lỗi thì các peer khác vẫn có khả năng cung cấp đủ cho phần băng thông còn thiếu.
Trong các phần dưới đây sẽ mô tả phương thức lựa chọn các peer cung cấp từ peerlist và sau đó sẽ giới thiệu giải thuật lập lịch streaming.
2.4.1. Lựa chọn các peer cung cấp
Sau khi receiver nhận được peerlist từ Tracker server, do kích thước của danh sách có thể khá lớn và receiver không thể kết nối đồng thời với tất cả các peer trong danh sách nên cần phải chọn ra một số peer cung cấp thích hợp. Cách thức lựa chọn như sau, ban đầu receiver gửi một thông báo truy vấn cho các peer trong danh sách (thông báo chứa mã videoID và số thứ tự của Segment). Mỗi peer nhận được thông báo này sẽ gửi thông báo trả lời cho receiver kèm theo các thông số Bwavail và EstimatedRTT. Trong
Phân mảnh mới nhất Phân mảnh cũ nhất Bộ nhớ chia sẻ StAvail seg_size
đó BwAvail là băng thông mà peer có khả năng upload và EstimatedRTT (Estimated Round Trip Time) là ước lượng thời gian truyền tải giữa receiver và peer. Receiver sẽ đợi cho đến khi hết thời gian chờ Tcollect để nhận các thông báo trả lời và thu thập thông tin. Sau khoảng thời gian Tcollect, receiver chọn ra một tập con của các peer cung cấp dựa trên giá trị Pot của chúng (Pot – Potentiality là khả năng của một peer trở thành một supplier). Giả sử rằng có m peer thành viên bao gồm {P1, P2, …, Pm}, giá trị Poti của peer Pi được tính theo công thức:
} { max } { max 1 1 i m i i i m i i i TT EstimatedR TT EstimatedR BwAvail BwAvail Pot
trong đó α, β là các hệ số trọng lượng cho các giá trị BwAvaili, EstimatedRTTi (α + β =1). Thiết đặt giá trị lớn hơn cho α nghĩa là thiên về các peer có băng thông sẵn sàng lớn hơn còn nếu đặt giá trị lớn hơn cho β nghĩa là thiên về chọn các peer ở gần hơn. Thông thường thì lựa chọn các peer ở gần là tốt hơn, bởi vì khi đó dữ liệu phải truyền qua ít chặng hơn giúp tiết kiệm được băng thông cho đường backbone và giảm được sự suy hao do nghẽn mạng. Do đó khi triển khai hệ thống thực tế cũng nên đặt cho giá trị của β lớn hơn so với α. Cũng theo như công thức nêu trên thì các peer ở gần receiver, có băng thông sẵn sàng cao hơn sẽ có giá trị Pot lớn hơn.
Sau khi xác định được tập tối ưu, receiver sẽ chọn ra M phần tử trong tập có giá trị Pot lớn nhất làm peer cung cấp (supplier). Số lượng các peer được chọn phải thỏa mãn điều kiện băng thông kết hợp từ các peer phải lớn hơn hoặc bằng so với tốc độ phát hình CBR (video playback bit rate). Các phần tử còn lại của tập không được chọn sẽ được đặt trong tập dự phòng (standby), dùng để thay thế trong trường hợp peer cung cấp rời hệ thống hoặc lỗi mất kết nối. Nếu như băng thông kết hợp từ tất cả các peer thành viên vẫn nhỏ hơn playback bit rate thì peer sẽ tạo kết nối đến video server để download về các block còn thiếu. Trường hợp băng thông phục vụ của server không còn đủ thì yêu cầu download của receiver sẽ bị từ chối, tiến trình video playback trên client bị tạm dừng. Receiver phải thực hiện lại việc truy vấn các peer trong peerlist như trên sau một khoảng thời gian TRetry tiếp đó.
Khi đã xác định được các peer cung cấp, receiver sẽ dành phần băng thông ưu tiên của mình để download. Giả sử có M peer cung cấp (P1, P2, …, PM) được chọn và tốc độ phát hình của video là Br. Receiver sẽ dành băng thông Bwri (băng thông dành riêng nên được đặt là bội số của băng thông đơn vị BwrU, giá trị của BwrU trong phần mô phỏng được đặt là 64Kbps) cho peer cung cấp Pi, thỏa mãn điều kiện:
Br Bwr M i i 1
Sau đó, receiver gửi thông báo Reserver_Bandthwidth<Bwri> (dành riêng băng thông) cho mỗi supplier. Nhận được thông báo này, supplier Pi sẽ giảm giá trị BwAvaili của mình một khoảng Bwri (BwAvaili = BwAvaili – Bwri) và tăng trở lại khi kết thúc phiên streaming.
Chú ý là ở đây việc "dành riêng băng thông" không có nghĩa là băng thông Bwri
của peer Pi thực sự được dành riêng và không thể sử dụng bởi các ứng dụng khác. Mạng Internet hiện nay không cung cấp dịch vụ dành riêng tài nguyên, như vậy băng thông đóng góp bởi peer cung cấp Pi có thể dao động lên xuống trong phiên streaming. Trong mô hình hiện tại, một receiver dành băng thông Bwri đối với peer Pi, chỉ có nghĩa là peer Pi giảm giá trị BwAvaili đi một khoảng Bwri. Theo một nghĩa khác, tiến trình dành riêng băng thông trong mô hình này chỉ có ý nghĩa điều khiển việc lựa chọn và xác định một peer đóng góp bao nhiêu cho phiên streaming chứ không đảm bảo chắc chắn là băng thông được thật sự dành riêng.
2.4.2. Giải thuật lập lịch
Để có thể kết hợp đầy đủ băng thông từ nhiều peer cung cấp, thì các supplier cần phải gửi đồng thời từng phần khác nhau của cùng segment cho receiver. Như vậy cần phải chia nhỏ tiếp mỗi segment thành các khối (block) có kích thước bằng nhau, trong đó mỗi block có độ dài là TBlk giây video. Nhờ đó receiver có thể download song song đồng thời các block khác nhau từ các peer cung cấp khác nhau. Giá trị của TBlk phụ thuộc vào tốc độ bit của video được mã hóa. Ví dụ, đối với một video được mã hóa ở bit rate 512Kbps thì đặt giá trị TBlk=1 là vừa phải, bởi vì với một giây video kích thước khoảng 64 Kb thì có thể gửi đi thông qua một vài gói tin UDP.
Tại thời điểm bất kỳ trong toàn bộ phiên streaming, một vài peer có thể rời hệ thống hoặc bị lỗi, tốc độ của dòng streaming đến từ các supplier có thể bị suy giảm do nghẽn mạng. Trong những trường hợp này, receiver sẽ chọn ra các peer từ tập dự phòng để thay thế. Chúng ta gọi đây là giai đoạn chuyển đổi peer cung cấp (supplier switching). Trong giai đoạn chuyển đổi, tốc độ của băng thông nhận được sẽ nhỏ hơn tốc độ phát hình yêu cầu dẫn đến sự thiếu hụt bộ đệm tại receiver. Để tránh khỏi vấn đề này thì giải pháp là bắt buộc receiver phải lưu đệm tối thiểu SInitBuff Block trước khi bắt đầu phát hình. Đây được gọi là giai đoạn khởi tạo bộ đệm (initial buffer time).
Việc giảm thời gian chờ của bộ đệm là một vấn đề quan trọng, bởi vì thời gian khởi tạo bộ đệm lâu đồng nghĩa với việc người dùng sẽ phải chờ lâu trước khi có thể bắt đầu xem.
Vấn đề đặt ra có thể được phát biểu thành bài toán lập lịch như sau: Giả sử rằng video segment được chia thành N block {blk0, blk1, …, blkN-1} và receiver đã chọn ra