cool3by_110y
New Member
Download miễn phí Tổng quan giao thức thời gian thực rtp (real time protocol)
MUC LỤC
Lời nói đầu
CHƯƠNG 0:TRUYỀN DÒNG DỮ LIỆU THỜI GIAN THỰC
0.1. Khái niệm truyền dòng
0.2. Quá trình truyền dòng
CHƯƠNG I: LỰA CHỌN CÁC GIAO THỨC PHÙ HỢP VỚI CÁC ỨNG DỤNG THỜI GIAN THỰC
1.1. Giao thức TCP: ( Transmision Control Protocol)
1.2. Giao thức UDP: (User Datagram Protocol)
1.3. Định tuyến multicast
1.4. Giao thức nào có thể đáp ứng được yêu cầu thời gian thực?
CHƯƠNG II: TỔNG QUAN GIAO THỨC THỜI GIAN THỰC RTP
(REAL TIME PROTOCOL).
3.1. Những khái niệm ban đầu
3.2. Ứng dụng của RTP trong hội thảo đa phương tiện
CHƯƠNG III: GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC
(REAL TIME TRANSPORT PROTOCOL).
3.1. Một số khái niệm liên quan đến RTP
3.2. Cấu trúc phần tiêu đề gói RTP
3.3. Ghép các phiên truyền RTP
3.4. Sự thay đổi phần tiêu đề trong một số trường hợp
CHƯƠNG IV: GIAO THỨC ĐIỀU KHIỂN RTP
(RTCP: RTP CONTROL PROTOCOL).
4.1. Chức năng và hoạt động của RTCP
4.2. Các loại gói tin RTCP
4.3. Khoảng thời gian truyền các gói RTCP
4.4. Cập nhật số thành viên tham gia phiên truyền
4.5. Qui định đối với việc gởi và nhận các gói RTCP
4.6. Các bản tin thông báo của người gởi và người nhận
4.7 Gói tin mô tả các thông tin của nguồn
4.8. Gói BYE
4.9. Gói APP
CHƯƠNG V: CÁC BỘ RTP TRANSLATORS VÀ RTP MIXERS .
5.1. Khái niệm chung
5.2. Hoạt động của bộ Translators
5.3. Hoạt động của Mixers.
78
5.4. Các “mixer” mắc phân tầng.
80
PHẦN VI: MỘT SỐ THUẬT TOÁN CẦN CHÚ Ý.
6.1. Phân phối các định danh SSRC.
82
6.2 Vấn đề bảo mật trong RTP.
86
6.3. Điều khiển tắc nghẽn.
87
6.4. RTP với các giao thức lớp mạng và lớp giao vận.
88
CHƯƠNG VII: ỨNG DỤNG LÝ THUYẾT VÀO THỰC TẾ.
7.1 Phân tích yêu cầu đặt ra.
90
7.2. thực hiện.
92
7.3. Kết quả.
93
Phụ lục.
96
Kết luận.
99
Tài liệu tham khảo.
100
5.3. Hoạt động của Mixers
5.4. Các “mixer” mắc phân tầng
PHẦN VI: MỘT SỐ THUẬT TOÁN CẦN CHÚ Ý
6.1. Phân phối các định danh SSRC
6.2. Vấn đề bảo mật trong RTP
6.3. Điều khiển tắc nghẽn
6.4. RTP với các giao thức lớp mạng và lớp giao vận
CHƯƠNG VII: ỨNG DỤNG LÝ THUYẾT VÀO THỰC TẾ
7.1 Phân tích yêu cầu đặt ra
7.2. thực hiện
7.3. Kết quả
Phụ lục
Kết luận
Tài liệu tham khảo
Để tải tài liệu này, vui lòng Trả lời bài viết, Mods sẽ gửi Link download cho bạn ngay qua hòm tin nhắn.
Ketnooi -
Ai cần tài liệu gì mà không tìm thấy ở Ketnooi, đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
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 toá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 giới hạn, gọi là băng thông của phiên truyền (session bandwidth). Băng thông có 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 hay 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ã hoá 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 toá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 đó 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 soát lỗi như đã nêu ở phần đầu. Tuy nhiên nó rất phù hợp cho những kết nối 1 chiều, hay cho những phiên 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 toá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 toá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 toá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 gia đồng thời là lớn thì việc này khá quan trọng. Để giải quyết vấn đề này, người ta sử dụng thuật toá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.
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 toá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 hay tạo ra thời gian timeout, số lượng thành viên trong nhóm sẽ giảm. thuật toá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 toán back-off.
4.4 CẬP NHẬT SỐ THÀNH VIÊN THAM GIA PHIÊN TRUYỀN:
( MAINTAINING THE NUMBER OF SESSION MEMBERS)
Việc tính toán chu kỳ gởi các gói RTCP dựa trên sự ước lượng số thành viên tham gia trong phiên truyền. Một thành viên mới sẽ được thêm vào biến đếm khi họ được nghe thấy. Khi đó mỗi thành viên sẽ được thêm vào bảng được đánh số bởi định danh SSRC hay CSRC để dùng cho việc theo dõi. Một thành viên mới sẽ chưa chính thức được thừa nhận trước khi gói tin có chứa giá trị SSRC mới hay gói SDES RTCP có chứa CNAME chư...