8. Timestamp: 32 bits
4.3KHOẢNG THỜI GIAN TRUYỀN CÁC GĨI RTCP:
(RTCP TRANSMISSION INTERVAL)
RTP được thiết kế để cho phép một ứng dụng cĩ thể tự co giãn kích cỡ phiên truyền từ vài thành viên đến hàng nghìn thành viên.
Ví dụ, trong cuộc hội thảo thoại, lưu lượng dữ liệu vốn đã tự giới hạn. Bởi vì trong cùng một thời điểm, chỉ cĩ 1 hoặc 2 người cùng phát biểu. Do vậy đối với việc
truyền multicast, tốc độ dữ liệu để duy trì một liên kết là tươngđối ổn định, độc lập so
với số thành viên tham gia.
Tuy vậy, lưu lượng dùng cho việc điều khiển thì khơng được hạn chế như vậy.
Nếu các bản báo nhận cửa mỗi thành viên được duy trì ở một tốc độ phát khơng đổi,
thì lưu lượng của luồng điều khiển sẽ tăng tỉ lệ với số thành viên tham gia. Do đĩ, tốc độ phát phải được thay đổi động dựa trên tính tốn khoảng thời gian phát các gĩi
RTCP liên tiếp.
Với mỗi phiên truyền giả sử rằng lưu lượng dữ liệu chịu ảnh hưởng của một tập các
39
thể được cung cấp và bị giới hạn bởi nhà cung cấp dịch vụ. Nếu khơng cĩ sự giới
hạn của nhà cung cấp thì sẽ cĩ một số ràng buộc, phụ thuộc vào mơi trường mạng. Điều này sẽ giới hạn số phiên truyền tối đa cĩ thể chấp nhận. Giá trị này cĩ thể được hiểu như là session bandwidth.
Việc chọn băng thơng này cĩ thể dựa trên yếu tố giá thành hoặc kinh nghiệm của
nhà thiết kế. Thơng thường giá trị của nĩ sẽ phụ thuộc vào kiểu định dạng của dữ
liệu.
Các thơng số của session bandwidth là cố định, được quyết định bởi sự quản lý
phiên của ứng dụng. Tuy nhiên, các ứng dụng cĩ thể thiết lập một giá trị mặc định, tương ứng với dải thơng dữ liệu (data bandwidth ) của từng người gởi, tương ứng
với từng cách mã hố dữ liệu. Tất cả các thành viên đều phải sử dụng cùng một giá
trị session bandwidth, do đĩ khoảng thời gian phát gĩi RTCP sẽ được tính giống
nhau.
Việc tính tốn băng thơng cho lưu lượng dữ liệu và lưu lượng thơng tin điều khiển, được thực hiện ở lớp mạng và lớp giao vận.
Lưu lượng điều khiển nên giới hạn chỉ là một phần nhỏ của session bandwidth,
để việc truyền tải dữ liệu khơng bị ảnh hưởng. Theo khuyến nghị, luồng RTCP nên chiếm 5% session bandwidth. Trong đĩ 1/4 giải thơng của RTCP dùng cho những
thành viên hiện đang gởi dữ liệu. Do đĩ, trong phiên truyền với số lượng người gởi ít, người nhận nhiều, thì một thành viên mới kết nối cĩ thể nhanh chĩng nhận được giá trị
CNAME của thành viên đang gởi dữ liệu.
Băng thơng dành cho lưu lượng điều khiển cĩ thể chia làm 2 loại, một cho cac thành viên đang ở trạng thái gởi dữ liệu, một dành cho các thành viên cịn lại. Chúng ta
2 tham số này là S và R. Theo khuyến nghị, 1/4 RTCP bandwidth dành cho người
gởi dữ liệu, do vậy tỷ lệ sử dụng băng thơng của các thành viên sẽ là 1,25% và 3,75%. Khi tỷ lệ người gởi lớn hơn 1/4 số thành viên, thì những người gởi sẽ sử dụng cả
5% Session bandwidth. Việc phân chia thành hai loại thành viên R, S cho phép ta cĩ thể giảm băng thơng RTCP của những thành viên (R) khơng gởi dữ liệu vể 0. Khi đĩ (adsbygoogle = window.adsbygoogle || []).push({});
các thành viên này sẽ khơng gởi đi các bản tin RTCP, mà chỉ nhận các bản tin RTCP để phục vụ cho việc khơi phục và đồng bộ dữ liệu. Thơng thường, điều này khơng
được khuyến khích vì nĩ sẽ làm mất một số chức năng kiểm sốt lỗi như đã nêu ở
40
truyền khơng cần sự hồi đáp về chất lượng dữ liệu nhận được, cũng như khơng cần quan tâm đến sự cĩ mặt của các thành viên chỉ nghe. Nếu sử dụng cơ chế này ta cĩ thể
giảm được phần nào sự tắc nghẽn trên mạng do băng thơng khơng đủ.
Việc tính tốn chu kỳ phát các gĩi tin ghép RTCP cũng nên đặt ra giới hạn tránh trường hợp quá nhiều gĩi tin vượt quá mức băng thơng cho phép, khi số lượng
thành viên tham gia ít và khơng cịn theo qui luật số lớn nữa. Điều này địi hỏi chu
kỳ phát các bản thơng báo phải đủ lớn. Mỗi khi khởi động ứng dụng, thời gian trễ được áp đặt trước cho gĩi RTCP ghép đầu tiên. Sau đĩ các thành viên khác gởi các
bản tin thơng báo gởi lại sẽ điều chỉnh lại khoảng thời gian phát của các bản tin
RTCP ngắn hơn cho phù hợp, cĩ thể sẽ bằng 1/2 giá trị ban đầu. Giá trị tối thiểu
khuyến cáo là 5s.
Các khoảng thời gian phát giữa các gĩi RTCP liên tiếp, cĩ thể được giảm xuống
phụ thuộc vào các tham số băng thơng phiên truyền, tuân theo những yêu cầu sau:
- Với phiên truyền Multicast, chỉ cĩ bên chủ động gởi số liệu mới được quyền
rút gắn khoảng thời gian gởi các gĩi RTCP ghép.
- Với phiên truyền unicast việc giảm giá trị cĩ thể được thực hiện bởi bên nhận
lẫn bên gởi. Trong trường hợp này, thời gian trễ được khởi tạo ban đầu là 0 (tốc độ gởi nhanh nhất).
- Cho tất cả các phiên truyền nĩi chung, khoản thời gian nhỏ nhất được cố định, dựa trên sự tính tốn dựa trên khoảng thời gian timeout của thành viên. Với cách này, sẽ khơng xảy ra hiện tượng timeout cho các gĩi tin RTCP, khi một thành viên nào đĩ thiết lập thời gian timeout quá bé.
- Theo khuyến nghị, giá trị tối thiểu cĩ thể được giảm xuống bằng:
360/bw (kilobits/second).
Nếu băng thơng của phiên truyền lớn hơn 72kb/s khi đĩ khoảng thời gian tối
thiểu sẽ nhỏ hơn 5s.
- Khoảng thời gian tính tốn giữa các gĩi RTCP tỷ lệ tuyến tính với số lượng
các thành viên tham gia. Việc này cĩ thể gây rắc rối khi cĩ một nhĩm thành viên mới đồng thời tham gia vào một phiên truyền thiết lập sẵn. Khi đĩ các
thành viên sẽ cĩ sự ước lượng sai về khoảng thời gian truyền, họ sẽ thiết lập
khoảng thời gian này nhỏ hơn so với yêu cầu. Với số lượng thành viên tham
41
người ta sử dụng thuật tốn "timer reconsideration", trong đĩ cĩ cơ chế Back-off. Theo đĩ, các thành viên sẽ tự động dữ lại gĩi RTCP của mình khi lắng nghe thấy số lượng thành viên đang tăng lên. (adsbygoogle = window.adsbygoogle || []).push({});
Khoản thời gian thực tế giữa các gĩi RTCP được biến đổi ngẫu nhiên trong khoảng
[0.5,1.5] lần giá trị tính tốn, để tránh sự đồng bộ khơng lường trước được của các thành viên. Gĩi RTCP đầu tiên được gởi sau khi thành viên tham gia phiên truyền
cũng bị làm trễ đi một khoảng thời gian ngẫu nhiên trong khoảng 1/2 khoảng thời gian
RTCP tối thiểu.
Ta liên tục ước lượng động giá trị trung bình của các gĩi tin RTCP ghép, bao gồm
cả các gĩi phía nhận và các gĩi phía gởi. Giá trị này được dùng để tự động thay đổi lượng thơng tin điều khiển được mang đi.
Khi các thành viên rời bỏ phiên, họ sẽ gởi tín hiệu BYE hoặc tạo ra thời gian
timeout, số lượng thành viên trong nhĩm sẽ giảm. thuật tốn "reverse reconsideration" sẽ được sử dụng để các thành viên khác tăng tốc độ truyền gĩi
RTCP. Mặt khác, khi một người rời khỏi phiên truyền, gĩi BYTE được chuyển đi luơn, khơng đợi đến lượt. Do đĩ, để tránh tình trạng tràn số liệu, gây ra khi cĩ nhiều
thành viên cùng rời đi, người ta sử dụng thuật tốn back-off.