Để 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 được M peer cung cấp {P1, P2, …, PM} với băng thông đóng góp tương ứng là {Bw1, Bw2,…, BwM}, receiver có băng thông download tối thiểu bằng tốc độ phát hình CBR, làm thế nào để gán các block cho các supplier để đạt được thời gian khởi tạo bộ đệm nhỏ nhất cũng như thời gian hoàn thành lịch biểu sớm nhất có thể.
Bài toán được nêu ra ở đây không phải là vấn đề mới mẻ. Đã có rất nhiều hệ thống vận dụng ý tưởng này nhằm đối phó với đặc tính biến động và hỗn tạp của môi trường mạng ngang hàng [8, 14, 18]. Tuy nhiên cách thức giải quyết vấn đề của mỗi hệ thống cũng rất khác nhau. Bài toán lập lịch media streaming đã trở thành một bài toán cơ bản
trong hầu hết các hệ thống truyền dữ liệu đa phương tiện dựa trên mạng ngang hàng (Distributed Multimedia Streaming over Peer-to-Peer Networks). Đây thực chất là một biến thể của bài toán Lập lịch các máy xử lý song song, một bài toán thuộc lớp NP- Hard. Không dễ dàng tìm ra lời giải tối ưu cho bài toán lập lịch thuộc lớp này, cụ thể là với bài toán đặt ra thì yêu cầu giải thuật phải thích ứng được với những thay đổi nhanh chóng của các điều kiện môi trường mạng. Tuy nhiên chúng ta cũng có thể sử dụng các giải thuật tìm nghiệm gần tối ưu.
Đã có một số phương án giải quyết bài toán này. Đơn giản nhất là giải thuật Round Robin (RR), được áp dụng trong hệ thống của DONet [27], thực hiện việc gán block cho các supplier lần lượt theo vòng, ưu tiên gán cho các supplier có băng thông lớn hơn trước. Hạn chế của giải thuật này là không quan tâm đến tỉ lệ băng thông đóng góp của mỗi supplier cho phiên streaming. Như vậy băng thông đóng góp của các peer mạnh có thể bị lãng phí, trong khi các peer yếu có thể phải đảm nhận gửi quá nhiều block. Một phương án khác được tác giả Mohamed M.Hfeeda đề cập đến trong bài báo
"A hybrid architechture for cost-effective ondemain media streaming" (2004) [18] là giải thuật Bandwidth Proportion (BP), dựa trên việc gán các block cho các supplier theo tỉ lệ băng thông đóng góp. Đây cũng là phương án đã được áp dụng trong hệ thống của GnuStream (xem phần 1.3.4.a). Trong phương án này, mỗi supplier Pi sẽ gửi liên tiếp (Bwi/Br)*N block cho receiver bắt đầu từ block kế tiếp sau block kết thúc của Pi-1 (các supplier đã được sắp xếp theo thứ tự giảm dần của băng thông). Cách tiếp cận này mặc dù đã tận dụng được băng thông đóng góp của mỗi supplier tuy nhiên đối với những block đầu tiên của segment thì chỉ có supplier P1 gửi block dẫn đến việc kéo dài thời gian khởi tạo bộ đệm. Dưới đây là mã giả của các giải thuật RR và BP:
Giải thuật Round Robin
Input:
num_suppliers : số supplier;
supplier[i] : các peer cung cấp được sắp xếp theo thứ tự giảm của Bw[i];
Bw[i] : băng thông đóng góp của supplier[i];
num_blks : số block;
block[i] : chỉ số của block;
blk_size : kích thước định trước của block;
Scheduling:
cur_supplier :=0;
for cur_blk :=0 to num_blk-1 do if (cur_supplier < num_supplier)
cur_supplier :=cur_supplier + 1;
else
cur_supplier :=1;
Gán block[curr_blk] cho supplier[cur_supplier];
Giải thuật Bandwidth Proportion Input:
num_suppliers : số supplier;
supplier[i] : các peer cung cấp được sắp xếp theo thứ tự giảm của Bw[i];
Bw[i] : băng thông đóng góp của supplier[i];
num_blks : số block;
block[i] : chỉ số của block;
blk_size : kích thước định trước của block;
Scheduling: Br := 0; for i := 1 to num_supplier do Br := Br + Bw[i]; curr_blk : = 0; for i := 1 to num_supplier do for j : = 1 to num_blk*Bw[i]/Br do
Gán block[curr_blk] cho supplier[i]; curr_blk++;
end for j
end for i
Hình 2.4.2-1: Các giải thuật Round Robin và Bandwidth Proportion
Trên cơ sở phân tích các giải thuật nêu trên, tác giả đã xây dựng giải thuật cho hệ thống với mục tiêu tận dụng băng thông đóng góp của tất cả các peer cung cấp và đạt được thời gian khởi tạo bộ đệm nhỏ nhất, tạm gọi là giải thuật Estimate Time (ET). Giải thuật được thực hiện tại receiver để sinh ra lịch biểu gửi cho các supplier đã được lựa chọn. Ý tưởng chính của giải thuật là gán block cho các supplier theo nguyên tắc supplier nào có ước lượng thời gian nhỏ nhất sẽ được gán cho block hiện tại, lần lượt từ block đầu tiên cho đến block cuối. Giải thuật được thực hiện như sau:
Tương ứng với supplier[i] thì estimatedTime[i] là ước lượng thời gian để hoàn thành việc gửi block kế tiếp. Khởi tạo ban đầu estimatedTime[i] được gán giá trị
blk_size/Bw[i] là thời gian để mỗi supplier hoàn thành việc gửi block đầu tiên. Bước vào vòng lặp, ta duyệt qua tất cả các supplier để tìm ra giá trị estimatedTime[i] nhỏ nhất. Giả sử supplier[k] có estimatedTime nhỏ nhất thì block hiện tại block[curr_blk]
được gán cho supplier[k]. Sau đó tăng giá trị của estimatedTime[k] lên thêm
theo của supplier[k]. Còn ước lượng thời gian gửi block kế tiếp của những supplier còn lại đều không thay đổi. Thủ tục này được tiếp tục lặp lại cho các block
block[curr_blk+1], block[curr_blk+2], … cho đến khi kết thúc việc gán block cuối cùng. Dưới đây mã giả của giải thuật:
Giải thuật đề xuất – Estimate Time Input:
num_suppliers : số supplier;
supplier[i] : các peer cung cấp;
Bw[i] : băng thông đóng góp của supplier[i];
num_blks : số block;
block[i] : chỉ số của block;
blk_size : kích thước định trước của block;
Scheduling:
1: for i := 1 to num_suppliers do
2: estimatedTime[i] : = blk_size / Bw[i];
3: for curr_blk := 0 to num_blks-1 do
4: Chọn k sao cho estimatedTime[k] = Min {estimatedTime[i]};
5: Gán block[curr_blk] cho supplier[k];
6: estimatedTime[k] := estimatedTime[k] + blk_size / Bw[k];
7: end for cur_blk
Hình 2.4.2-2: Giải thuật đề xuất
Hình 2.4.2-2 là một ví dụ minh họa của việc gán 8 block cho supplier sử dụng các giải thuật RR, BP và giải thuật đề xuất. Giả sử tốc độ bit phát hình là 512Kbps và một block chứa 1 giây nội dung video (block_size = 512Kb). Có 3 supplier đóng góp băng thông, trong đó của P1 là 320Kbps (chiếm 5/8 tổng băng thông Br), P2 là 128Kbps (1/4*Br) và P3 là 64Kbps (1/8*Br). Như hình minh họa, để download được tất cả 8 block, giải thuật RR phải mất đến 16 giây, trong khi BP và giải thuật ET chỉ mất có 8 giây. Nếu như giá trị SInitbuff (số block khởi tạo bộ đệm) được đặt là 4 thì RR mất 8 giây để download 4 block khởi tạo, BP mất 6.4 giây trong khi ET chỉ mất 4.8 giây (thời gian khởi tạo được tính là thời gian để download xong cả 4 block đầu tiên). Ví dụ này cho thấy so với các giải thuật RR và BP thì giải thuật đề xuất có thời gian download tất cả các block cũng như thời gian khởi tạo bộ đệm nhỏ hơn.
Hình 2.4.2-2: Minh họa việc gán 8 block cho 3 supplier sử dụng các giải thuật Round Robin, Bandwidth Proportion và Estimate Time
Time (second) 8s Bandwidth (kbps) 0s 16s 320 0 3 6 128 1 4 7 64 2 5
(a) Lịch biểu của giải thuật Round Robin
P3 P1 P2 6.4s Time (second) 128 8s Bandwidth (kbps) 0s 5 6 64 64 7
(b) Lịch biểu của giải thuật Bandwidth Proportion
320 3 4 0 1 2 P3 P1 P2 4.8s Time (second) 320 128 64 P1 8s Bandwidth (kbps) 0s 2 6 7
(c) Lịch biểu của giải thuật Estimate Time
4 5 0 1 3 P3 P1 P2