danh gia hieu nang hoat dong cua dimdim web meeting

BỘ CÔNG THƢƠNG

TRƢỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM

KHOA CÔNG NGHỆ THÔNG TIN

ĐỒ ÁN CHUYÊN NGÀNH

ĐÁNH GIÁ HIỆU NĂNG HOẠT ĐỘNG

CỦA PHẦN MỀM DIMDIM WEB MEETING

Nhóm sinh viên thực hiện :

Mã số SV Họ và tên Lớp

10369231 Phạm Khắc Minh ĐHTH6CLT

10305221 Vương Văn Dũng ĐHTH6CLT

Giảng viên hƣớng dẫn : Ths.Mai Xuân Phú

HUI – Tháng 6/2012

Đồ án chuyên ngành 06 - 2012 GVHD : Mai Xuân Phú

HUI - ĐHTH6CLT Phạm Khắc Minh – Vương Văn Dũng 2

LỜI CẢM ƠN

Trong quá trình thực hiện đề tài : “ Xây Dựng Kịch Bản Đánh Giá

Hiệu Năng Hoạt Động Của Phần Mền DimDim Web Meeting”. Nhóm em

xin chân thành gửi lời cảm ơn sâu sắc nhất đến thầy giáo Mai Xuân Phú

đã chỉ bảo và hướng dẫn nhóm tận tình trong suốt quá trình nhóm thực

hiện đồ án, để nhóm chúng em có thể hoàn thành tốt Đồ Án Chuyên

Ngành này.

Nhóm xin chân thành cảm ơn các Thầy, Cô giáo bộ môn đã giảng

dạy, cung cấp cho chúng em nhiều kiến thức trong suốt quá trình học tập

tại trường Đại Học Công Nghiệp TP.Hồ Chí Minh.

Một lần nữa nhóm chúng em xin chân thành cảm ơn tới Khoa Công

Nghệ Thông Tin đã tạo điều kiện cho chúng em học tập và phát triển kỹ

năng cũng như chuyên môn ngành nghề mà mình đã chọn.

TP.HCM, Ngày 15 Tháng 06 Năm 2012

Nhóm Sinh Viên

Phạm Khắc Minh

Vƣơng Văn Dũng



NHẬN XÉT CỦA GIẢNG VIÊN HƢỚNG DẪN

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................



NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................

.........................................................................................................................



MỤC LỤC

I. GIỚI THIỆU CHUNG ---------------------------------------------------------------------------- 9

1. Tóm Lƣợc Giao Thức RTP Và RTCP ------------------------------------------------------------------------------ 9

2. Kết Quả Của Đồ Án 2 ----------------------------------------------------------------------------------------------------------- 9

Giới Thiệu Về DimDim -------------------------------------------------------------------------- 9

Tính Năng Nổi Bật Của DimDim So Với Các Phần Mềm Khác ------------------------- 10

Hiện Trạng Của Đồ Án Trước Khi Thực Hiện Đồ Án 3 ----------------------------------- 10

Mục Tiêu Của Đồ Án 3 ------------------------------------------------------------------------- 11

II. XÂY DỰNG CÁC MÔ HÌNH TEST ĐỂ ĐÁNH GIÁ HIỆU NĂNG CỦA

DIMDIM WEBMEETING ------------------------------------------------------------------------- 12

1. Giao Thức Real Time Messaging Protocol - RTMP ---------------------------------------------------- 12

Giới Thiệu ---------------------------------------------------------------------------------------- 12

Các Cơ Chế Hoạt Động Của RTMP ---------------------------------------------------------- 13

Quy Trình Bắt Tay ------------------------------------------------------------------------------ 13

Tiêu Đề RTMP ----------------------------------------------------------------------------------- 14

Một Số Giá Trị Trong Trường Content Type ------------------------------------------------ 15

Chuẩn Mã Hoá Dữ Liệu AMF - Action Message Format --------------------------------- 15

Truyền Tải Nhiều Đối Tượng AMF Trên Cùng Một Kết Nối----------------------------- 15

2. Giả Lập Các Trƣờng Hợp Mạng Trong Hệ Thống ----------------------------------------------------- 17

3. Sử Dụng NetLimieter Để Thiết Lập Bang Thông Mạng Trong Hệ Thống ------------ 18

4. Sử Dụng Phần Mềm Wireshark Để Bắt Các Gói Tin ------------------------------------------------- 19

5. Xây Dựng Kịch Bản Test --------------------------------------------------------------------------------------------------- 22

Mẫu Gói Tin Mặc Định ------------------------------------------------------------------ 23

Mẫu Gói Tin Bị Trễ ---------------------------------------------------------------------- 24

Mẫu Gói Tin Trùng Lặp ----------------------------------------------------------------- 28

Mẫu Mất Gói Tin ------------------------------------------------------------------------- 31

Mẫu Hƣ Gói Tin --------------------------------------------------------------------------- 36

III. KẾT LUẬN ---------------------------------------------------------------------------------------- 38

IV. TÀI LIỆU THAM KHẢO --------------------------------------------------------------------- 39



MỤC LỤC HÌNH

Hình 1.1 : Mô Hình Hệ Thống DimDim Web Meeting

Hình 1.2 : Hình Minh Họa Lúc Diễn Ra Phiên Họp Của Hệ Thống

Hình 2.1.1 : Cơ Chế Hoạt Động Của Giao Thức RTMP

Hình 2.1.2 : Quy Trình Bắt Tay Giữa Client Và Server Trong Giao Thức RTMP

Hình 2.1.3 : Tiêu Đề RTMP 12 Bytes

Hình 2.1.4 :Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03

Hình 2.1.5 :Truyền các khối dữ liệu xen kẽ nhau

Hình 2.2.1 : Giao Diện Đồ Họa Của WANem

Hình 2.3.1 : Giao Diện Của Phần Mềm NetLimiter

Hình 2.4.1 : Giao Diệu Của Phần Mêm WireShark

Hình 2.4.2 : Các gói tin RTMP

Hình 2.4.3 : Thông số gói tin Audio data 120 bytes



Hình 5.1 : Mô Hình Test Hệ Thống “DimDim Web Meeting”

Hình 5.1.1 : Mô Hình Test Mặc Định

Hình 5.1.2 : Lược Đồ Gói Tin Mẫu Khi Bắt Ở Phía Client

Hình 5.2.1 : Lược đồ gói tin Audio và Video bắt ở phía Client với độ trễ 10ms



Hình 5.3.1 : Lược đồ gói tin Audio và Video bắt ở phía Client với trùng lặp 3%





Hình 5.4.1 : Lược đồ gói tin Audio và Video bắt ở phía Client với độ mất gói tin 1%




Hình 5.5.1 : Lược đồ gói tin Audio và Video bắt ở phía Client với độ hư gói tin 1%



CÁC THUẬT NGỮ VIẾT TẮT

Thuật Ngữ Đầy Đủ Ý Nghĩa

RTP Real-time Transport Protocol

Giao thức chuyền tải thời gian

thực

RTCP Real-time Transport Control

Protocol

Giao thức điều khiển chuyền tải

thời gian thực

AMF Action Message Format Định dạng khích hoạt thông báo

RTMP Real Time Messaging

Protocol

Giao thức thông báo thời gian thực

RTMPT Real Time Messaging

Protocol Tunneled


ẩn

RTMPS Real Time Messaging

Protocol Secure


có bảo mật

RTMPET Encrypted Real Time Messaging

Protocol

Tunneled

Giao thức thông báo thời gian

thực ẩn có m. hóa

HTTP Hypertext Transfer protocol Giao thức truyền siêu văn bản

FLV Flash Video Là tên gọi của một định dạng file

được truyền tải qua mạng internet

sử dụng Adobe Flash Player

F4V Flash 4 Video Một định dạng file của Flash

SWF Một định dạng file của Flash



I. GIỚI THIỆU CHUNG

Đồ án này thực hiện dựa trên cơ sở kết quả của đồ án 2 “Tìm Hiểu Về Hội

Thảo Truyền Hình”. Từ đó xây dựng các kịch bản test để đánh giá hiệu năng

hoạt động của phần mềm “DimDim Web Meeting”. Để đưa ra những thông số

như độ trễ, trùng lắp, mất và hư gói tin sao cho phù hợp với hệ thống, để đảm

bảo hệ thống hoạt động trong môi trường đường truyền mạng tốt nhất.

1. Tóm Lƣợc Giao Thức RTP Real-time Transport Protocol Và

RTCP Real-time Transport Control Protocol

RTP – Real-time Transport Protocol : được thiết kế cho các dịch vụ, ứng

dụng thời gian thực end-to-end, như các ứng dụng interactive Audio và Video,

sử dụng các dịch vụ mạng unicast hoặc multicast. Các ứng dụng sử dụng RTP

chạy trên nền của giao thức UDP ( hoặc TCP cũng có thể được sử dụng nhưng

rất ít ), nhằm sử dụng các dịch vụ multiplexing và checksum của UDP. RTP được sử dụng để truyền tải thông tin dữ liệu thời gian thực qua mạng

Internet. Trong khi đó RTCP được sử dụng để giám sát chất lượng dịch vụ như

truyền tải thông tin điều khiển và xác nhận của các phiên làm việc.

Mỗi giao thức sử dụng một port riêng biệt, thông thường port chẵn sử dụng

cho RTP và port lẻ kế tiếp còn trống sử dụng cho RTCP.

Vì truyền tải trong môi trường IP và UDP Protocol nên việc mất gói tin (

packet loss ), không đúng thứ tự gói tin (out of order), trễ (delay and jitter) là

không thể tránh khỏi. Để hạn chế tác động của các vấn đề này RTP và RTCP sử

dụng các trường thời gian (Timestamp) và Sequence number trong phần header

để đo đạt các thông số loss rate, delay, jitter, RTT…,

2. Kết Quả Của Đồ Án 2

Giới Thiệu Về DimDim

DimDim là hệ thống mã nguồn mở cho phép người dùng cài đặt và sử dụng

miễn phí, tạo một Webmeeting trực tuyến, chia sẻ tài liệu, thông tin, Video…

một sản phẩm nổi trội của DimDim. Cũng như tất cả các sản phẩm truyền thông

miễn phí khác, như Skype và Hotmail hay Yahoo để giữ liên lạc với nhau, khi

người dùng muốn chia sẻ tài liệu của họ trên máy tính cho người khác mà họ

thấy rằng việc trả giá cho một trang web hội nghị có giá quá đắt và phức tạp.

Chính vì thế DimDim một open sources miễn phí đã được tạo ra.



Tính Năng Nổi Bật Của DimDim So Với Các Phần Mềm Khác

- Chất lượng hình ảnh, âm thanh tốt, không bị trễ

- Hỗ trợ multipoint (có thể tạo ra nhiều meeting room đồng thời cùng một

lúc).

- Hỗ trợ trình chiếu Power Point (có hỗ trợ các công cụ rất hoàn thiện như vẽ,

in và viết…).

- Cho phép chia sẻ cả màn hình máy của người đang trình bày.

- Có một whiteboard cho phép giảng bài trực tuyến bằng bảng (có thể cho

phép các Client ghi lên bảng nếu có thắc mắc hay không hiểu).

- Có tính năng cho các Client join có thể xem các trang web mà người tạo ra

meeting muốn.

- Có thể hoán chuyển cho bất cứ một ai muốn trình bày.

- Có thể cho phép hoặc không cho phép một ai nghe hay thấy cuộc họp.

- Có tính năng nghi lại cuộc họp và sau đó gửi đi cho các Client tham gia vào

cuộc họp để họ có thể xem lại qua layer.

- Có tính năng chat public hoặc chat private.

- Có tính năng hoán chuyển và tích hợp moodle và suger.

Hiện Trạng Của Đồ Án Trƣớc Khi Thực Hiện Đồ Án 3

Tạo ra được một phiên hội thảo giữa Master room với các Client với nhau,

hay nói cách khác là giữa người tạo ra phiên hội thảo với các người dùng từ xa

có thể trao đổi, nói chuyện trực tiếp với nhau, dựa vào phần mềm “DimDim Web

Meeting”.

Mô hình hệ thống nhóm đã xây dựng được ở đồ án 2 :

Hình 1.1 : Mô Hình Hệ Thống DimDim Web Meeting



Đây là kết quả hình ảnh giao diện chụp được trong lúc diễn ra phiên họp :

Hình 1.2 : Hình Minh Họa Lúc Diễn Ra Phiên Họp Của Hệ Thống

Bên cạch đó thì hệ thống “DimDim Web Meeting” còn một số hạn chế, như về

bảo mật, hạn chế về giới hạn camera (chỉ cho phép một Room được mở tối đa

hai camera ), khung hình Video có độ phân giải thấp 220pixels - 240pixels, nên

chất lượng hình ảnh truyền đi chưa được sắc nét.

Mục Tiêu Của Đồ Án 3

Xây dựng các kịch bản test để đánh giá hiệu năng hoạt động của hệ thống

“DimDim Web Meeting” dựa trên hệ thống mạng được xây dựng gần với mạng

thực tế với các trường hợp như :

3. Mất gói tin

4. Trễ gói tin

5. Trùng lặp gói tin

6. Hư gói tin

Từ đó đưa ra một hệ thống “DimDim Web Meeting” có hiệu năng hoạt

động tốt nhất và định hướng cho người dùng biết được những thông số như độ

trễ, mất, hư, và trùng lặp gói tin như thế nào thì phù hợp để đảm bảo cho hệ

thống có hiệu năng hoạt động tốt nhất.



II. XÂY DỰNG CÁC MÔ HÌNH TEST ĐỂ ĐÁNH GIÁ HIỆU

NĂNG CỦA DIMDIM WEBMEETING

Hệ thống “DimDim Web Meeting” được đặt nền móng dựa trên giao thức

RTMP, ngoài những giao thức như RTP và RTCP nhóm đã tìm hiểu từ việc kế thừa

của đồ án trước, thì nhóm em sẽ giới thiệu và trình bày thêm phần giao thức RTMP.

Mục đích của đồ án này nhóm em sẽ phân tích những gói tin hình ảnh và âm

thanh dựa trên giao thức RTMP vào việc đánh giá mức ảnh hưởng của hệ thống đối

với những trường hợp thực tế như : mất gói tin, hư gói tin, trùng lặp và trễ. Để đưa

ra hiệu năng hoạt động khi sử dụng “DimDim Web Meeting”.

1. Giao Thức Real Time Messaging Protocol RTMP

Giới Thiệu

RTMP ban đầu là một giao thức độc quyền được phát triển bởi Macromedia cho

việc truyền tải âm thanh, hình ảnh và dữ liệu qua internet, giữa một Flash player với

một Server. Hiện đang thuộc sở hữu của Adobe, đã phát hành.

RTMP được thiết kế cho hiệu suất truyền tải âm thanh, hình ảnh và dữ liệu cao

giữa các nền công nghệ Adoble Flash, bao gồm Adoble Flash Player và Adobe AIR.

RTMP hiện như là một đặc điểm kỹ thuật mở để tạo ra những sản phẩm và công

nghệ cho phép cung cấp hình ảnh, âm thanh và dữ liệu trong AMF mở, SWF, FLV,

và F4V định dạng tương thích với Adoble Flash Player.

Giao thức RTMP có nhiều biến thể :

1. Đơn giản là giao thức hoạt động trên đỉnh của TCP và sử dụng cổng mặc

định 1935.

2. RTMPS đó là RTMP trên một kết nối an toàn SSL bằng cách sử dụng

HTTPS.

3. RTMPE đó là RTMP mã hóa bằng cách sử dụng cơ chế bảo mật của Adobe.

Trong khi các chi tiết của việc thực hiện là độc quyền, cơ chế sử dụng

nguyên thủy mã hóa ngành công nghiệp chuẩn.

4. RTMPT được đóng gói dưới dạng HTTP để đi qua firewall. RTMPT thường

sử dụng dạng Cleartext (1 định dạng password) thông qua cổng giao tiếp

mặc định là 80 và 443. Các phiên được đóng gói RTMPT có thể thực hiện

bằng dạng RTMP đơn giản, RTMPS hoặc trong các gói RTMPE.



Các Cơ Chế Hoạt Động Của RTMP

RTMP ở chế độ tiêu chuẩn chạy trên TCP với cổng mặc định là 1935. Ngoài ra

RTMP còn chạy trong chế độ đường hầm trên một kết nối HTTP sử dụng cổng 80.

Hình 2.1.1 : Cơ Chế Hoạt Động Của Giao Thức RTMP

Quy Trình Bắt Tay

Hoạt động cơ bản của RTMP như sau : Tất cả các quá trình truyền thông được

thực hiện bởi Client. Client khởi tạo một kết nối RTMP bằng cách gửi một byte có

giá trị 0x03, byte này kèm theo sau một khối dữ liệu 1536 bytes. Định dạng của khối

dữ liệu này cho đến nay vẫn chưa biết, nhưng dường như nó không thực sự được sử

dụng bởi giao thức ngoại trừ thao tác bắt tay.

Server nhân được gói dữ liệu và lưu gói dữ liệu 1536 bytes và cũng gửi 1 byte

giá trị 0x03 theo sau bởi 2 khối dữ liệu 1536 bytes. Khối thứ 2 chính là nội dung đã

được gửi lên bởi Client trước đó.

Client nhận 2 khối dữ liệu 1536 bytes từ Server, so sánh với khối dữ liệu ban

đầu nó gửi lên Server, nếu phù hợp thì kết nối được thiết lập, nó cũng gửi trả khối

dữ liệu này về lại cho Server.

IP Header TCP Header RTMP Message

IP Header TCP Header HTTP Header RTMP Message

RTMP ở chế độ chuẩn

RTMP ở chế độ đƣờng hầm



Hình 2.1.2 : Quy Trình Bắt Tay Giữa Client Và Server Trong Giao Thức RTMP

Tiêu Đề RTMP

RTMP có 4 loại tiêu đề đó là tiêu đề 12, 8, 4 hoặc 1 byte. Byte đầu tiên của tiêu

đề rất quan trọng, 2 bits đầu tiên của nó xác định kích thước tiêu đề.

0x00 : tiêu đề 12 bytes (header full)

0x01 : tiêu đề 8 bytes

0x02 : tiêu đề 4 bytes (bao gồm Basic Header và 3 bytes Timestamp)

0x03 : tiêu đề 1 byte (chỉ bao gồm Basic Header)

6 bits còn lại biểu diễn chỉ số của đối tượng AMF. Một khi đối tượng AMF đã được

nhận đầy đủ bởi Client thì chỉ số này có thể được tái sử dụng

Hình 2.1.3 : Tiêu Đề RTMP 12 Bytes

Client Server

0x03 + 1536 Byte

Khởi Động Kết Nối

0x03 + 1536 Byte + 1536

Byte

1536 Byte



Đối với tiêu đề 12 bytes thì 3 bytes tiếp theo là trường Timestamp (little - endian), 3

bytes tiếp theo (Length) là chiều dài của đối tượng AMF (big-endian), byte kế tiếp

quy định nội dung của đối tượng AMF (Action Message Format), 4 bytes cuối xác

định Source ID

Đối với tiêu đề 8 bytes thì bỏ trường Source ID trong tiêu đề 12 bytes.

Đối với tiêu đề 4 bytes thì bỏ trường Length, Content Type trong tiêu đề 8 bytes.

Đối với tiêu đề 1 byte thì bỏ trường Timestamp trong tiêu đề 4 bytes nghĩa là nó chỉ

bao gồm byte đầu tiên chứa kiểu tiêu đề và chỉ số đối tượng AMF.

0x01 Set Packet Size Message (Chunk Size)

0x02 Unknown (AbortMessage)

0x03 Bytes Read

0x04 Ping Message

0x05 Server Bandwidth

0x06 Client Bandwidth

0x07 Unknown

0x08 Audio Packet

0x09 Video Packet

0x0A – 0x0E Unknown

0x0F Flex Stream

0x10 Flex Shared Object

0x11 Flex Message

0x12 Notify

0x13 Shared Object

0x14 Invoke

Một Số Giá Trị Trong Trường Content Type

Chuẩn Mã Hoá Dữ Liệu AMF - Action Message Format

AMF là một định dạng dùng ghép nối tiếp các dữ liệu được dùng để giao tiếp

thông qua môi trường mạng. AMF giúp mã hoá và định nghĩa các kiểu dữ liệu cần

tương tác giữa hai hệ thống. Thông qua AMF, các hệ thống đầu cuối sẽ hiểu được

dữ liệu được chuyền từ hệ thống khác là kiểu dữ liệu gì. AMF được giới thiệu đầu

tiên 2001 trong Flash Player 6 là AMF0. Sau này được phát triển thêm thành AMF 3

trong Flash Player 9.

Truyền Tải Nhiều Đối Tƣợng AMF Trên Cùng Một Kết Nối

Mỗi đối tượng AMF được chia thành các khối dữ liệu có kích thước 128 bytes

( ngoại trừ Audio có kích thước 64 bytes ). Khối đầu tiên thường được gắn tiêu đề

12 bytes, các khối tiếp theo thường được gắn tiêu đề 1 byte, trong bất kỳ loại tiêu đề

nào cũng có chứa chỉ số của đối tượng AMF tương ứng.



Hình 2.1.4 :Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03

Để có thể truyền nhiều đối tượng AMF trên một kết nối đơn người ta không truyền

các khối dữ liệu của một đối tượng AMF liên tiếp nhau mà truyền xen kẽ các khối

dữ liệu của nhiều đối tượng AMF.

Hình 2.1.5 :Truyền các khối dữ liệu xen kẽ nhau



2. Giả Lập Các Trƣờng Hợp Mạng Trong Hệ Thống

Phần mêm WANem được viết tắt của từ Wide Area Network Emulator tạm

dịch phần mềm giả lập mạng diện rộng với kết nối LAN to LAN. WANem là

một phần mềm mã nguồn mở sử dụng miễn phí được cài đặt trong hệ điều hành

Linux, trong đề tài này nhóm em cài đặt sử dụng hệ điều hành Linux trên máy

ảo Vmware Workstastion. WANem được sử dụng cấu hình bằng cách truy cập

dưới dạng web với giao diện khá thân thiện và dễ sử dụng, đáp ứng thỏa mãn

các nhu cầu của nhóm trong đề tài.

Hình 2.2.1 : Giao Diện Đồ Họa Của WANem

Mục đích sử dụng phần mền WANem để thực hiện giả lập hệ thống mạng

với các trường hợp thực tiễn như gói tin bị trể, bị lỗi, bị trùng lặp hoặc mất gói

tin thì với những trường hợp đó sẽ ảnh hưởng đến chất lượng hình ảnh và âm

thanh của “DimDim Web Meeting” như thế nào. Với việc sử dụng phần mền

WANem nhằm lấy kết quả tương đối như một hệ thống mạng thực tiễn để nhóm

tổng hợp các kết quả đưa ra nhận định và đánh giá cho các trường hợp hình ảnh

và âm thanh từ các Master room đến Client có đảm bảo hiệu năng hoạt động

cho hệ thống mạng dành cho “DimDim Web Meeting” hay không.



3. Sử Dụng NetLimieter Để Thiết Lập Bang Thông Và Tốc Độ Mạng

Trong Hệ Thống

NetLimiter là một công cụ kiểm soát internet và giám sát thiết kế cài đặt

trên hệ điều hành Windows. NetLimiter có chức năng thiết lập giới hạn tốc độ

download và upload của đường truyền dữ liệu cho các ứng dụng hoặc kết nối

mạng LAN và theo dõi lưu lượng truy cập ứng dụng Webrower của các máy

Client khi sử dụng “DimDim Web Meeting”.

Mục đích nhóm sử dụng NetLimiter để hạn chế băng thông download và

upload của máy Client. Giả lập hệ thống mạng ADSL hiện tại với các Client

nằm ở các vị trí địa lý khác nhau kết nối đến Master room với đường truyền có

giới hạn, để đưa ra việc đảm bảo băng thông như thế nào thì máy Client nhận

được hình ảnh và âm thanh sử dụng tốt nhất.

Giao diện NetLimiter khá đơn giản với nhiều phiên bản khác nhau và kèm

theo các tính năngnhư giới hạn, giám sát mạng, chặn kết nối, lọc, thống kê...

Hiện tại nhóm sử dụng phiên bản miễn phí với giao diện như bên dưới.

Hình 2.3.1 : Giao Diện Của Phần Mềm NetLimiter



4. Sử Dụng Phần Mềm Wireshark Để Bắt Các Gói Tin

Wireshark là một phần mền sử dụng để phân tích gói tin. Với rất nhiều

phần mền phân tích gói tin như hiên nay. Thì Wireshark được xem là vượt trội

hơn hẳn các phần mềm khác về khả năng hỗ trợ rất nhiều các giao thức (khoảng

850 loại), từ những loại phổ biến như TCP, IP đến những loại đặc biệt như là

AppleTalk và Bit Torrent. Và cũng bởi Wireshark được phát triển trên mô hình

mã nguồn mở, những giao thức mới sẽ được thêm vào.

Wireshark có thể cài đặt được trên hầu hết các hệ điều hành Linux,

Windows và sử dụng miễn phí, nhóm sử dụng wireshark để bắt các gói tin

Video và Audio để thiết lập bảng tính cho các trường hợp sử dụng trong hệ

thống mạng “DimDim Web Meeting”. Với giao diện ứng dụng đồ họa thân

thiện rõ ràng và được bố trí dễ hiểu giúp người sử dụng dễ dàng phân tích các

gói tin.

Hình 2.4.1 : Giao Diệu Của Phần Mêm WireShark

Dùng Wireshark để bắt gói tin và phân tích các gói tin

Các gói tin bắt được khi dùng Wireshark, gồm các gói Video data và Audio data



Hình 2.4.2 : Các gói tin RTMP

TH1 : Audio length 120 bytes




5. Xây Dựng Kịch Bản Test

Mô hình test : hệ thống gồm :

Máy 1 : Server Centos DimDim

May 2 : Server Wanem

Máy 3 : Master Room

Máy 4 : Client

Hình 5.1 : Mô Hình Test Hệ Thống “DimDim Web Meeting”

- Dùng Wireshark để bắt và phân tích gói tin.

- Dùng NetLimiter để thiết lập giới hạn mạng 512Kb up và down ở phía

Client.

- Dùng Server WANem để thiết lập độ trễ, mất, trùng lặp và hư gói tin.

- Mỗi trường hợp test lấy mẫu gói tin trong 60s và lấy 10 lần.

- Thiết lập bảng đường đi trong hệ thống

- Client01 : route add 192.168.1.123 mask 255.255.255.255 192.168.1.124 và

route add 192.168.1.100 mask 255.255.255.255 192.168.1.124

- DimDim Server : route add –host 192.168.1.101 netmask 0.0.0.0 gw

192.168.1.124



Mẫu Gói Tin Mặc Định

TH1 : Mẫu các gói tin Video và Audio cả nhận và gửi mặc định bắt trên cả

hai phía Master room và Client trong 60s và lấy 10 lần .

Hình 5.1.1 : Mô Hình Test Mặc Định

Mẫu các gói Video và Audio chỉ bắt ở phía Client và chỉ lấy các gói tin mà

Client nhận được trong 60s.

CLIENT

Giây AUDIO VIDEO

10 84 23

20 84 23

30 82 21

40 84 22

50 81 23

60 85 22

TB 83.7 22.3



Hình 5.1.2 : Lược Đồ Gói Tin Mẫu Khi Bắt Ở Phía Client

Tại phía Client thi trung bình gói tin Audio bắt được là khoảng 84 gói và

Video là khoảng 23 gói. Hinh ảnh và âm thanh truyền tốt, không bị lắc hình,

âm thanh nghe rõ.

Mẫu Gói Tin Bị Trễ

Mức giới hạn của độ trễ gói tin trong hệ thống từ 20ms trở xuống để đảm

bảo hệ thống hoạt động có hiệu năng tốt

Bảng thống kê các gói tin Audio và Video khi bắt ở Client với độ trễ 10ms so

với gói tin ban đầu :

Giây Audio

Default

Video

Default

Audio Video

10 84 23 83 23

20 84 23 82 23

30 83 22 83 22

40 84 23 80 22

50 85 23 84 22

60 84 22 84 21

84 84 82 8481

85

23 23 21 22 23 22

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio

Video

Gói tin

Giây



Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trễ là 10ms

so với gói tin ban đầu :


Các gói tin Audio và Video giảm không đáng kể so với vói tin mặc định, âm

thanh và hình ảnh của hệ thống không bị ảnh hưởng với độ trễ 10ms



Giây Audio

Default

Video

Default

Audio Video

10 84 23 83 22

20 84 23 84 22

30 83 22 84 22

40 84 23 84 22

50 85 23 83 22

60 84 22 83 21

Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trễ gói tin

là 15ms so với gói tin ban đầu :

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây




Với độ trễ 15ms thì hình ảnh và âm thanh bên phía Client nhận vẫn ổn định

âm thanh và hình ảnh hơi bị giật nhưng vẫn có thể chấp nhận được



Giây Audio

Default

Video

Default

Audio Video

10 84 23 78 18

20 84 23 79 4

30 83 22 77 0

40 84 23 76 0

50 85 23 78 0

60 84 22 77 0

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây



Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trễ gói tin

là 20ms so với gói tin ban đầu :


Với độ trễ 20ms thấy gói tin Video và Audio bắt được giảm hẳn đi so với

gói tin ban đầu, thậm chí mất cả gói Video, dựa vào Wireshark để bắt gói tin

trong trường hợp này, phía lúc đầu nhận được cả Video và Audio nhưng do

bị mất gói tin Control (Video và Audio). Dẫn đến phía Client bị giật hình và

đứng hình.

Với độ trễ 20ms trở lên thì phía Client nhận được các gói tin Audio và

Video giảm hẳn và đôi khi không bắt được gói Video nên làm cho chất

lượng âm thanh và hình ảnh mà Client nhận được rất chậm, hệ thống hay bị

đứng hình và được khoảng 20 - 30 phút thì mất kết nối với Master room.

Nhận Xét : Để hệ thống “DimDim Web Meeting” hoạt động với chất lượng

âm thanh và hình ảnh tốt thì đòi hỏi phải có một môi trường mạng ổn định có

độ trễ phải dưới 20ms.

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây



Mẫu Gói Tin Trùng Lặp

Mức giới hạn độ trung lặp gói tin trong hệ thống từ 10% trở xuống để

đảm bảo hệ thống hoạt động có hiệu năng tốt

Bảng thống kê các gói tin Audio và Video khi bắt ở Client với độ trùng lặp 3%


Giây Audio

Default

Video

Default

Audio Video

10 84 23 77 22

20 84 23 84 21

30 83 22 77 21

40 84 23 75 22

50 85 23 76 21

60 84 22 77 21

Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trùng lặp

gói tin là 3% so với gói tin ban đầu :


Với độ trùng lặp gói tin 3% thì hệ thống không bị ảnh hường gì. Chất lượng

âm thanh và hình ảnh hoạt động tốt.

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây





Giây Audio

Default

Video

Default

Audio Video

10 84 23 77 21

20 84 23 76 20

30 83 22 77 17

40 84 23 78 8

50 85 23 76 0

60 84 22 77 0

Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trùng lặp

gói tin là 5% so với gói tin ban đầu :


Với độ trùng lặp gói tin 5% thì chất lượng âm thanh và hình ảnh bên phía

Client nhận được bị chậm và hình nhòe, và chạy khoảng 20-30 phút thì hệ

thống bị treo, Client bị mất kết nối với Master room. Do phía Client bị mất

gói tin Control (Video và Audio).

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây





Giây Audio

Default

Video

Default

Audio Video

10 84 23 78 8

20 84 23 76 0

30 83 22 77 0

40 84 23 78 0

50 85 23 76 0

60 84 22 77 0

Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ trùng lặp gói

tin là 8% so với gói tin ban đầu :


Với độ trùng lặp gói tin từ 8% trở lên thì hệ thống hoặt động chập chờn âm

thanh hình ảnh Client nhận được lúc có lúc không và hầu như là bị đứng

hình.

Ghi chú : để đảm bảo hệ thống “DimDim Web Meeting” hoạt động với hiệu

năng tốt nhất thì đòi hỏi hệ thống không có gói tin trùng lặp quá 3%.

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Giây

Gói tin



Mẫu Mất Gói Tin

Mức giới hạn của mất gói tin trong hệ thống từ 10% trở xuống để đảm

bảo hệ thống hoạt động có hiệu năng tốt

Bảng thống kê các gói tin Audio và Video khi bắt ở Client với độ mất gói tin

1% so với gói tin ban đầu :

Giây Audio

Default

Video

Default

Audio Video

10 84 23 83 22

20 84 23 82 21

30 83 22 82 22

40 84 23 83 23

50 85 23 84 22

60 84 22 82 22

Lược đồ các gói tin Audio và Video bắt được ở phía Client với độ mất gói tin

là 1% so với gói tin ban đầu :


Với độ mất gói tin 1% thì hệ thống vẫn đảm bảo chất lượng âm thanh và

hình ảnh không bị thay đổi

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây





Giây Audio

Default

Video

Default

Audio Video

10 84 23 77 20

20 84 23 78 21

30 83 22 75 19

40 84 23 76 17

50 85 23 70 15

60 84 22 74 14




Với độ mất gói tin 3% thì hệ thống bị ảnh hưởng chất lượng âm thanh và

hình ảnh bị chậm lại, hay bị giật hình, âm thanh bị vọng

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây





Giây Audio

Default

Video

Default

Audio Video

10 84 23 77 17

20 84 23 78 17

30 83 22 77 18

40 84 23 76 16

50 85 23 75 15

60 84 22 74 14




Với độ mất gói tin 5% chất lượng âm thanh và hình ảnh của hệ thộng bị

chậm và nhiều lúc bị giật và đứng lúc lâu.

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây





Giây Audio

Default

Video

Default

Audio Video

10 84 23 78 15

20 84 23 78 12

30 83 22 75 6

40 84 23 75 0

50 85 23 70 0

60 84 22 68 0




Với độ mất gói tin 10% thì chất lượng âm thanh và hình ảnh của hệ thộng

mà bên phía Client nhận được rất chậm và nhiều lúc bị giật và đứng hình

Do hệ thống chạy trên nền TCP có độ tin cậy cao nên khi xảy ra trường hợp

bị mất gói tin thì sẽ xảy ra hai trường hợp sau :

2. Phía Client không nhận được gói tin từ Server : do Client gửi các gói

tin video và audio cho Server nhưng Client không nhận được gói tin

phản hồi của Server (à tôi đã nhận được gói tin Video và Audio này

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây



rồi), nên phía Client vẫn gửi đi gửi lại gói tin đó cho đến khi Server

trả lời là nó đã nhận được, Client không gửi những gói tin đó nữa vẫn

tiếp tục kết nối.

3. Phía Server không nhận được gói tin từ Client : trong quá trình gửi

nhận giữa Client và Server đang bình thường, nhưng có một số gói

tin bị mất thì ngay lập tức Server sẽ gửi yêu cầu cho Client gửi lại

những gói tin đó. Do đó khi dùng Wireshark để bắt các gói tin phía

Client thấy xuất hiện nhiều gói (unknown) và không có gói tin

Control hoặc bị Bad.

Nhận Xét : Khi thiết lập hệ thống bị mất gói tin ở phía Client sẽ bị ảnh hưởng

như sau :

- Hệ thống bị mất gói tin 10% trở lên thì hệ thống sẽ hoạt động không ổn

định, nhiều lúc làm treo toàn bộ hệ thống, do mất gói tin Control.

- Với độ mất gói tin từ 3-5% thì chất lượng âm thanh và hình ảnh hay bị

đứng hình và hệ thống chạy khoảng 10-20 phút thì bị mất kết nối, dẫn

đến bị treo hệ thống.

Để hệ thống hoạt động được đảm bảo thì đòi hỏi hệ thống có độ mất gói tin

không quá 1%, vì chỉ cần mất gói tin control thì cũng dẫn đến hệ thống bị

mất kết nối, và bị treo toàn bộ.



Mẫu Hƣ Gói Tin

Bảng thống kê các gói tin Audio và Video khi bắt ở Client với độ hư gói tin


Giây Audio

Default

Video

Default

Audio Video

10 84 23 84 23

20 84 23 75 13

30 83 22 70 10

40 84 23 68 3

50 85 23 65 3

60 84 22 65 0



Hình 5.5.1 : Lược đồ gói tin Audio và Video bắt ở phía Client với độ hư gói tin 1%

Hình ảnh và âm thanh phía Client nhận không ổn định và hay bị đứng hình

so với trường hợp ban đầu. Trong khoảng thời gian 10 phút thì hình ảnh và

âm thanh không còn nhận được nữa, và bị mất kết nối với Server, dẫn đến

tình trạng bị mất kết nối với hệ thống Master Room.

0

10

20

30

40

50

60

70

80

90

10 20 30 40 50 60

Audio Default

Video Default

Audio

Video

Gói tin

Giây



Sau thời gian khoảng 10 phút khi sử dụng Wireshark để bắt gói tin từ phía

Client thì bắt được nhiều gói tin Request từ phía Server gửi tới, mà Server

không thấy được gói ACK Replay trả lời từ Client, cho nên sẽ tự động

ngắt kết nối với Client sau nhiều gói tin yêu cầu không thấy trả lời.

Trong quá trình gửi gói tin từ phía Client đến Server thì bị ảnh hưởng bởi

việc áp đặt WANem với thông số hư gói tin 1%, để Server xác nhận và

chuyền tải đến Master room nhưng bị hư gói tin control (audio và video)

nên Server yêu cầu Client gửi lại gói tin mà phía Client yêu cầu, sau một

khoảng thời gian nhất định mà khía Server vẫn không thấy Client gửi lại

thì tự đông Server sẽ ngắt kết nối với Client, đồng thời gửi thông báo tới

Master room là đã mất kết nối phía Client.

Nhận Xét : Với thông số hư gói tin 1% trong vòng 10 phút, thì số gói tin bắt

được từ phía Client bị giảm dần và xuất hiện nhiều gói tin bị lỗi trong quá

trình gửi nhận từ Client và Master room

Với đường truyền mạng ADSL như hiện nay, và mô hình nhóm đưa ra để đảm

bảo cho việc sử dụng “Dimdim Web Meeting” có âm thanh và hình ảnh tốt thì

với mức độ hư gói tin phải đảm bảo dưới 1%.



III. KẾT LUẬN

Qua quá trình xây dựng các kịch bản test với những tình huống có thể xảy ra

trong thực tế đối với hệ thống “DimDim Web Meeting” như độ trễ, mất, hư và trùng

lặp gói tin ở phía Client. Với mô hình hệ thống có băng thông thấp (512Kb cho up

và down). Từ đó đưa ra những biện pháp tốt nhất để sử dụng hệ thống “DimDim

Web Meeting” có chất lượng hình ảnh và âm thanh ổn định nhất.

Để đảm bảo hệ thống “DimDim Web Meeting” hoạt động với chất lượng âm

thanh và hình ảnh truyền đi không bị ảnh hưởng, thì buộc phải đảm bảo những tiêu

chí sau :

- Băng thông của hệ thống luôn ổn định, hệ thống truyền dữ liệu đi có độ

trễ không quá 15ms, nếu quá 15ms trở lên thì chất lượng âm thanh và

hình ảnh truyền đi bị ảnh hưởng, phía bên nhận âm thanh sẽ bị vọng lại

và phát chậm hơn, hình ảnh thì bị giật.

- Đảm bảo dữ liệu truyền đi không bị mất gói tin quá 1%, vì nếu mất phải

gói Control (Video hay Audio) sẽ dẫn đến hệ thống bị đứng hình, và dẫn

đến tình trạng mất kết nối tới Server.

- Đảm bảo dữ liệu truyền đi có độ hư gói tin không quá 1% , nếu quá 1%

thì hệ thống hoạt động khoảng 10 – 20 phút thì âm thanh và hình ảnh bị

đứng hình dẫn đến tình trạng treo cả hệ thống.

- Và hệ thống phải đảm bảo các gói dữ liệu truyền đi có độ trùng lặp gói

tin phải nhỏ 5%. Thì mới đảm bảo được chất lượng âm thanh và hình ảnh

của hệ thống truyền đi ổn định.



IV. TÀI LIỆU THAM KHẢO

1. DimDim, Inc., (2009) “DimDim Open Source Community edition (4.5)”,

Online,

http://www.dimdim.com.

2. Dsa a Adobe,Inc., (2009) “Real Time Messaging Protocol (RTMP)”, Online,

http://www.adobe.com/devnet/rtmp/

3. WANem 1.2.1 (Wide Area Network Emulator) Performance Engineering

Research Centre 27th

May 2008

4. G. Combs, (2010) “Wireshark”, Online, http://www.wireshark.org

5. http://www.ispringsolutions.com/help/index.jsp?topic=/kinetics.6/desktop/bitrate

s.html

6. C. Allen & D. Accattato, (2010) “Red5: Open Source Flash Server”, Online,

http://red5.org

7. Red5, http://osflash.org/red5

8. http://www.adobe.com/support/documentation/en/flashmediaServer/

http://www.dimdim.com/

http://www.wireshark.org/

http://www.ispringsolutions.com/help/index.jsp?topic=/kinetics.6/desktop/bitrates.html

http://www.ispringsolutions.com/help/index.jsp?topic=/kinetics.6/desktop/bitrates.html

http://red5.org/

http://osflash.org/red5

http://www.adobe.com/support/documentation/en/flashmediaserver/

danh gia hieu nang hoat dong cua dimdim web meeting

Documents