Tải bản đầy đủ - 0 (trang)
3 Các gói thư viện trong kurento

3 Các gói thư viện trong kurento

Tải bản đầy đủ - 0trang

Filters



Hubs



việc chưa đựng nội dung.

Là một thành phần của Media Elements.Nó được xây

dựng nhằm mục đích xữ lý dữ liệu media như Computer

Vision , AR (Augmented Reality)…Đây cũng là điểm

khác biệt của kurento so với các ưng dụng truyền thông

đa phương tiện khác. Một số Filter có thể kể tới như:

• ZbarFilter: đây là một bộ lọc với mục đích nhận

diện mã QR và bar trong video stream.Khi kết quả

được tìm thấy, bộ lọ sẽ trả về một sự kiện.Client có

thể nghe sự kiện đó và xử lý các hành động tiếp theo

• FaceOverlayFilter: bộ lọc này nhận diện khng

mặt trong một video stream.Nó cũng có thể ghi đè

khng mặt với hình được client thiết lập

• GstreamerFilter: bộ lọc này cho phép chúng ta mở

rộng các tính năng của filters.

Hubs chịu trách nghiệm quản lý nhiều luồng media

trong một đường ống (pipeline).Một Hub có thể có một

vài hub ports.Đây là tập hợp các Media Elements được

kết nối với nhau .Các loại hubs có thể tới như là:

• Composite:có chức năng trộn các luồng audio của

các endpoint dữ liệu đầu vào được kết nối.

• DispatcherOneToMany: Gửi dữ liệu tới tất cả đầu

ra của các thành phần được kết nối với nhau thơng

qua đường ống.

• Dispatcher: Là một hub cho phép định tuyến đầu

vào/ra giữa các thành phần được kết nối.



2.3.3. Media Pipeline

Một Media Pipeline là một chuỗi các media element nối tiếp nhau mà ở đó các luồng

đầu ra được tạo bởi một element (source) và đưa nó vào trong một hoặc nhiều các element

luồng đầu vào khác (sink).Dưới đây là ví dụ minh họa một Media Pipeline gồm hai thành

phần là WebRtcEndpoint, WebRtcEndpoint thứ hai nhận dữ liệu từ cái thứ nhất qua sink, sau

đó gửi trả lại theo source (src) [22].



Hình 2.10 Mơ tả một Media Pipeline với hai thành phần là WebRtcEndpoint đượ nối với nhau



24



2.3.4. Kurento Protocol

Một điểm bất lợi khi điều khiển KMS là phải sử dụng Kurento API là phải sử dụng thư

viện do Kurento cung cấp (Kurento hỗ trợ hai ngôn ngữ là java và javascript). Vì thế Kurento

cung cấp một giao thức gọi là Kurento protocol nhằm giúp lập trình viên có thể sử dụng bất

cứ ngơn ngữ nào mà mình muốn.Kurento protocol sử dụng JSON-RPC v2.0 [23] để mã hóa

các tin nhắn API của nó và sử dụng websocket để vận chuyển tin nhắn đó tới KMS,

websocket này có khả năng tương tác hai chiều giữa client và server. Một số RPC mà KMS

đưa ra có thể liệt kê như sau [24]:

• Ping: Được xây dựng với mục đích kiểm tra kết nối từ client tới KMS có còn khơng.

• Create: Mục đích là tạo một media object mới, đây có thể là pipeline hoặc media





element.

Invoke: Được xây dựng nhằm gọi một phương thức cụ thể nào đó tồn tại trong media













object (pipeline hoặc media element).

Subscribe: lắng nghe một sự kiện nào đó từ media element.

Unsubscribe: hủy lắng nghe sự kiện.

Release: xóa bỏ một media object và giải phóng nó.

OnEvent: Khi sự kiện xuất hiện, request sẽ được gửi tới client theo dõi nó.



Các yêu cầu RPC gửi tới KMS có dạng JSON như ví dụ sau:

{

"jsonrpc": "2.0",

"id": 1,

"method": "create",

"params": {

"type": "PlayerEndpoint",

"constructorParams": {

"pipeline": "6829986",

"uri": "http://host/app/video.mp4"

},

"sessionId": "c93e5bf0-4fd0-4888-9411-765ff5d89b93"

}

}

• “jsonrpc” : Là một kiểu string dùng để xác định phiên bản của giao thức JSON-RPC. Ở





đây là “2.0” vì KMS sử dụng phiên bản này.

“id” : Một giá trị định danh duy nhất được được thiết lập bởi client. KMS sẽ hồi đáp lại id









có cùng giá trị với yêu cầu từ client.

“method” : Là một string chứa tên của yêu cầu được gọi.

“params” : Mang các giá trị điều kiện mà KMS cần để thực hiện một method bất kì.



25



Ngồi hai cái kể trên kurento còn cung cấp một thư viện gọi là Kurento Utils. Đây là một

đối tượng của RTCPeerConnection.Gói thư viện này nhằm đơn giản hóa việc phát triển các

ứng dụng WebRTC.



2.4. Các kiến trúc phân tải của ứng dụng web

2.4.1. Tất cả trong một

Ở kiến trúc này [25] tồn bộ mơ trường đều nằm trong một server duy nhất. Đối với ứng dụng

web thông thường, sẽ bao gồm webserver, application server, database server. Một ví dụ của

cách thiết lập này là LAMP stack, viết tắt của Linux, Apache, Mysql, PHP đều nằm trong một

server duy nhất

Trường hợp sử dụng: Tốt cho thiết lập ứng dụng nhanh chóng, bởi vì đây là thiết lập đơn

giản nhât



Hình 2.11 Mơ tả kiến trúc phân tải tất cả trong một

Ưu điểm: Đơn giản

Nhược điểm:

• Ứng dụng và database sử dụng tranh chấp tài nguyên server (CPU,RAM, I/O…).Do







đó bên cạnh việc gây ra giảm hiệu năng của hệ thống, nó còn gây khó khăn trong việc

xác định thành phần nào gây ra điều đó.

Khơng dễ dàng cho việc mở rộng ứng dụng.



2.4.2. Tách biệt riêng database server

Cách thiết lập này [25] sẽ tách riêng hệ thống database với những phần còn lại để loại bỏ việc

tranh chấp tài nguyên giữa các ứng dụng và database. Đồng thời tăng tính bảo mật bằng cách

giấu database khỏi internet công cộng.

Trường hợp sử dụng: Tốt cho việc thiết lập một ứng dụng nhanh chóng, tuy nhiên có thể

loại bỏ được việc tranh chấp tài nguyên hệ thống giữa các ứng dụng với database.



26



Hình 2.12 Mơ tả kiến trúc phân tải tách riêng database server

Ưu điểm:

• Các tầng ứng dụng và cơ sở dữ liệu khơng còn trang tranh chấp ngun hệ thống nữa







(CPU, bộ nhớ, I/O…).

Có thể mở rộng bằng cách thêm tài nguyên cho server nào cần (CPU, bộ nhớ).

Tùy thuộc vào thiết lập, có thể tăng tính bảo mật bằng cách che giấu cơ sở dữ liệu.



Nhược điểm:

• Thiết lập phức tạp hơn chút so với cách sử dụng một server duy nhất.

• Có thể phát sinh các vấn đề về hiệu năng nếu kết nối mạng giữa 2 server có độ trễ cao

( do khoảng cách địa lý giữa các server) hoặc bằng thông quá thấp cho việc truyền tải

dữ liệu.



2.4.3. Load Balancer ( Reverse Proxy)

Load Balancer [25] được thêm vào hệ thống để tăng hiệu suất của hệ thống bằng cách phân tải

ra nhiều server. Nếu một server bị lỗi, các server còn lại sẽ phân chia nhau chịu tải cho đến

khi server kia hoạt động trở lại. Nó có thể được sử dụng để cung cấp nhiều ứng dụng thông

qua cùng một tên miền và cổng.Có một số phần mềm cung cấp khả năng phân tải như là

HAProxy, Nginx và Varnish…

Trường hợp sử dụng: Kiến trúc này hữu dụng trong mơi trường đòi hỏi khả năng mở rộng

bằng cách thêm nhiều server.



27



Hình 2.13 Mơ tả kiến trúc phân tải load balancer

Ưu điểm:

• Cho phép mở rộng hệ thống bằng cách thêm nhiều server.

• Có thể bảo vệ chống lại những tấn công DDOS bằng cách giới hạn kết nối client với

một số lượng và tần số hợp lý.

Nhược điểm:

• Load balancer có thể gây ra tình trạng “nghẽn cổ chai” nếu server chạy load balancer





khơng được cung cấp đủ tài ngun hoặc khơng được cấu hình tốt.

Nếu load balancer sập, tồn bộ dịch vụ của ta sập theo.



2.4.4. HTTP Accelerator (Caching Reverse Proxy)

Một HTTP Accelerator [25], hay caching HTTP reverse proxy, có thể được sử dụng để

giảm thời phục vụ của hệ thống đối với người dùng sử dụng một vài kĩ thuật khác nhau. Kĩ

thuật chính của phương pháp này là cache lại hồi đáp từ một web server hoặc application

server vào trong bộ nhớ và những yêu cầu trong tương lai cùng với nội dung sẽ được cung cấp

một cách nhanh chóng mà không cần tương tác với web server hoặc application server.

Môt số phần mềm cung cấp HTTP acceleration: Vernish, Squid, Nginx.

Trường hợp sự dụng: Kiến trúc này hữu dụng trong nhưng hệ thống web động năng về nội

dung hoặc với nhiều tệp được truy cập thường xun.



28



Hình 2.14 Mơ tả kiến trúc phân tải Accelerator

Ưu điểm:

• Tăng hiệu suất bằng cách giảm CPU tải trên web server, thơng qua caching.

• Có thể đóng vai trò như reverse proxy load balancer.

• Một vài phần mềm caching có thể bảo vệ chống lại các cuộc tấn cơng DDOS.

Nhược điểm:

• Cần phải tinh chỉnh để có hiệu suất tốt nhất.

• Nếu tốc độ truy cập vào cache chậm, nó sẽ làm giảm hiệu năng.



2.4.5. Master-Slave nhân rộng database

Một cách để tăng hiệu suất của hệ thống database thực hiện nhiều thao tác đọc ghi, ví

dụ như các hệ thống CMS, đó là sử dụng các kiến trúc Master-Slave Replication [25]. MasterSlave replication yêu cầu một master và nhiều slave. Master đóng vai trò ghi dữ liệu còn các

Slave đóng vai trò đọc dữ liệu ra. Khi có dữ liệu được ghi trên master, những dữ liệu này sau

đó sẽ được đồng bộ dần lên các Slave. Kiến trúc này giúp chia tải (các thao tác đọc dữ liệu) ra

nhiều server.

Trường hợp sử dụng: Hữu dụng cho các hệ thống mà cần tăng tốc độ đọc ghi.



Hình 2.15 Mơ tả kiến trúc phân tải Master-Slave nhân rộng database

Ưu điểm:



29







Tăng hiệu năng đọc dữ liệu từ database bằng cách phân tải nhiều yêu cầu ra nhiều







server slave.

Có thể tăng khả năng đọc ghi dữ liệu chỉ bằng cách sử dụng server master cho việc ghi



(master khơng cần phải thực hiện thao tác đọc).

Nhược điểm:

• Cài đặt kiến trúc khá phức tạp,

• Cập nhập lên các server slave diễn ra bất đồng bộ, do vậy nội dung trên đó có thể chưa





được cập nhập mới nhất trong những thời điểm nhất định.

Nếu master lỗi, không thể ghi được dữ liệu lên.



30



CHƯƠNG 3. GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER

Ở chương này ta đi trình bầy giải pháp nhằm tăng tính mở rộng cho các ứng dụng

WebRTC sử dụng kurento trước đó.Trước tiên, ta bắt đầu phân tích các quy trình thực hiện

một ứng dụng multimedia với kurento, các thành phần tham gia vào trong ứng dụng và quá

trình trao đổi tương tác với nhau.



3.1. Các quá trình thực hiện cuộc gọi video với kurento media server

Với các ứng dụng WebRTC thông thường, việc thực hiện các ứng dụng media sử dụng

API WebRTC cung cấp thông thường hầu như khá phức tạp, rất khó để cho lập trình viên.

Như đã đề cập đến ở chương 2, kurento cung cấp một số API nhằm mục đích đơn giản hóa

việc xây dựng các ứng dụng đa phương tiện, một phần trong các API này dựa vào WebRTC

API có sẵn. Một điều nữa là mặc dù các ứng dụng WebRTC chưa hẳn là peer-to-peer, nó vẫn

cần một server đứng giữa để thực hiện việc trao đổi các thông tin cần thiết giữa các peer, có

thể cần một media server cho việc nâng cao hiệu suất của ứng dụng WebRTC. Dưới đây là

một số thành phần tham gia vào khi thực hiện cuộc gọi.



Hình 3.1 Mơ tả kiến trúc các thành phần tham gia vào thực hiện cuộc gọi video

Tóm lượt lại hình trên ta có thể thấy có 4 thành phần chính tham gia vào q trình thực hiện.

Dưới đây là mơ tả tóm gọn các thành phần:

• Peer : Chính là đối tượng kết nối ( ở đây có thể là trình duyệt web,mobile…).

• Signaling Server: Như đã giới thiệu ở các phần trên, ở đây nó đứng giữa thực hiện trao





đổi với các peer và KMS.

ICE (Interactive Connectivity Establishment): Q trình hỗ trợ vượt NAT, nó sẽ nhận

đăng kí từ các peer và trả về candidate (là các cách để kết nối với peer đó).ICE ở đây



31



có thể là tập hợp bao gồm STUN, TURN server được đặt ở các đối tượng là peer và

KMS. Phần này đã được giới thiệu ở phần 2.1.4

Các đối tượng này sẽ tham gia vào trong quá trình thực hiện cuộc gọi video.Về cơ bản ta có

thể chia q trình này thành 3 q trình con là đăng kí,thực hiện cuộc gọi,kết thúc cuộc

goi.Chi tiết về quá trình thực hiện sẽ được mơ tả bên dưới.



3.1.1 Đăng kí người dùng

Bước này thực hiện khá đơn giản với việc có 3 tác nhân là người dùng A, người dùng

B và signaling server.Server này sẽ là trung gian xử lý các yêu cầu đăng kí của hai bên (ví dụ

có thể lưu vào database).Nó cũng đưa ra các quyết định liệu có thể cho người dùng đăng kí

hay khơng.Có hai trạng thái mà nó gửi về cho người dùng ở bước này là đăng kí thành cơng

và đăng kí thất bại. Hình dưới mơ tả pha đăng kí người dùng.



Hình 3.2 Mơ tả q trình đăng kí



3.1.2. Thực hiện cuộc gọi

Bước chủ yếu được giới thiệu ở đây là thực hiện cuộc gọi.Ở bước này các peer sẽ phải

thực hiện một số trao đổi nhất định để có thể đạt được kết nối với KMS. Các trao đổi này

được trung gian qua Signaling Server và lấy được candidate thông qua các ICE đứng bên cạnh

các đối tượng.Dưới đây là mô tả chi tiết các quy trình để thực hiện một cuộc gọi video.



32



Quy trình lấy được SDP



Hình 3.3 Mơ tả q trình bắt đầu lấy SDP

Khi thực hiện việc đăng kí thành cơng,để bắt đầu thiết lập cuộc gọi, mỗi bên cần biết một

thông số nhất định.Đầu tiên, bắt đầu khởi tạo một đối tượng là WebRtcPeer ( đã nhắc qua ở

chương 2).Sau đó ta bắt đầu thiết lập một callback để lắng nghe SDP offer được gửi về. Khi

nhận được SDP thành công, Peer A bắt đầu gửi yêu cầu cấp quyền truy cập một số tài nguyên

thiết bị tới người dùng.Nếu người dùng đồng ý, chúng ta bắt đầu thực hiện q trình tiếp theo

là gửi các thơng tin ban đầu từ Peer A ( như là SDP, đến từ đâu, muốn kết nối tới đâu…) đến

signaling.Signaling có nhiệm vụ lưu lại các thông tin này và bắt đầu thông báo tới trình duyệt

B là có ai đó muốn kết nối.Khi Peer B nhận được thông báo bên A muốn kết nối, nó sẽ thiết

lập tương tự như Peer A khi lấy SDP offer và truy cập thiết bị. Khi đó Signaling sẽ có thơng

tin của hai Peer và bắt đầu vào quá trình thiết lập cuộc gọi với KMS.

Trao đổi ứng viên (candidate)



Hình 3.4 Quá trình thu thập candidate từ trình duyệt và trao đổi với KMS



33



Quá trình này song song với q trình đạt được SDP, mục đích của quá trình này nhằm

mở ra các cách khác nhau mà cách peer khác có thể kết nối với A.Đầu tiên ta cần làm là đăng

kí lắng nghe candidate tới ICE peer A bằng cách ta sẽ thiết lập một callback là

OnIceCandidate ( đây là một option khi tạo đối tượng WebRtcPeer).Khi đó,ICE cho trình

duyệt A sẽ thực hiện chức năng của nó là tìm các cách để có thể kết nối với A. Khi tìm được,

nó sẽ gửi lại cho trình duyệt A thơng qua hàm callback OnIceCandidate.Bước tiếp theo trình

duyệt A gửi lại cho signaling server, server này đơn giản là ủy quyền lại cho Kurento Media

Sever (KMS) bằng cách gọi addCandidate để yêu cầu thêm vào các cách để kết nối với A

(candidate).Vì vậy KMS sẽ biết cách để kết nối với peer A.Việc này tương tự với Peer B.



Hình 3.5 Quá trình KMS trao đổi candidate với các peer

Quá trình này được thực hiện khi mà WebRtcEndpoint đã được tạo ra bên trong KMS.

Khi đó ta cần biết cách để biết làm sao để kết nối với WebRtcEndpoint tương ứng. Bằng cách

thêm vào một máy chủ ICE bên cạnh KMS ( có thể là STUN hoặc TURN). Nó sẽ nói cho

KMS biết làm cách nào để kết nối với WebRtcEndpoint trong đó.Từ đó KMS sẽ gửi các cách

kết nối với WebRtcEndpoint này (candidate) trở lại chỗ mà nó đã đăng kí mỗi khi mà máy chủ

ICE gửi trả về một candidate tương ứng.Các candidate này được gửi trở lại các peer qua

Signaling làm trung gian.Các peer sẽ thực hiện công việc cuối cùng là thêm cái candidate đó

vào (bằng cách thực hiện addCandidate ở đối tượng WebRtcPeer) và q trình này có thể sẽ

phải lặp lại nhiều lần. Nếu q trình trao đổi thành cơng, Peer sẽ biết cách để kết nối với

WebRtcEndpoint trong KMS vừa tạo.Kết quả từ hai quá trình kể trên là các Peer và KMS đã

hiểu cách kết nối với nhau.



34



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

3 Các gói thư viện trong kurento

Tải bản đầy đủ ngay(0 tr)

×