Chia sẻ luận văn, tiểu luận ngành kinh tế miễn phí
Nội quy chuyên mục: - Hiện nay có khá nhiều trang chia sẻ Tài liệu nhưng mất phí, đó là lý do ket-noi mở ra chuyên mục Tài liệu miễn phí.

- Ai có tài liệu gì hay, hãy đăng lên đây để chia sẻ với mọi người nhé! Bạn chia sẻ hôm nay, ngày mai mọi người sẽ chia sẻ với bạn!
Cách chia sẻ, Upload tài liệu trên ket-noi

- Những bạn nào tích cực chia sẻ tài liệu, sẽ được ưu tiên cung cấp tài liệu khi có yêu cầu.
Nhận download tài liệu miễn phí


Để Giúp ket-noi mở rộng kho tài liệu miễn phí, các bạn hảo tâm hãy Ủng hộ ket-noi
ket-noi sẽ dùng số tiền được ủng hộ để mua tài liệu chia sẻ với các bạn
By cool3by_110y
#1027242

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

 





Để DOWNLOAD tài liệu, xin trả lời bài viết này, mình sẽ upload tài liệu cho bạn ngay.

Ketnooi - Kho tài liệu miễn phí lớn nhất của bạn


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:


yề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 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ư...

Lưu ý khi sử dụng

- Gặp Link download hỏng, hãy đăng trả lời (yêu cầu link download mới), Các MOD sẽ cập nhật link sớm nhất
- Tìm kiếm trước khi đăng bài mới

Chủ đề liên quan:
Kết nối đề xuất:
xe máy Vision cũ tại Hà Nội
Advertisement
Advertisement