Hệ Điều Hành Phân Tán Chorus (Phần 4)

Phần 4: Truyền thông trong Chorus

Mô hình truyền thông cơ bản trong Chorus là các thông điệp được truyền qua. Trong phần này chúng ta sẽ thảo luận về các thông điệp, các cổng, các hoạt động truyền thông, và bao gồm các cuộc gọi từ hạt nhân.

4.1 Thông điệp (Messages)

Mỗi thông điệp (message) có chứa một tiêu đề (header), một phần cố định (fixed part) và phần thân tùy chọn (body). Phần đầu xác định nguồn và đích, có định danh bảo vệ khác nhau và cờ báo hiệu. Các phần cố định, nếu có, luôn luôn 64 byte dài và hoàn toàn dưới sự kiểm soát của người dùng. Phần thân có thể thay đổi kích thước, với tối đa là 64K byte, và cũng hoàn toàn dưới sự kiểm soát của người dùng. Từ quan điểm của hạt nhân xem xét, thì cả phần cố định và phần thân là không định kiểu mảng byte, nghĩa là các hạt nhân không quan tâm những gì có trong đó.

Khi một message được gửi đến một thread trên một máy khác, nó luôn luôn là bản sao chép. Tuy nhiên, khi nó được gửi đến một thread trên cùng một máy, có một sự lựa chọn giữa sao chép nó hay ánh xạ nó vào không gian địa chỉ của người nhận. Trong trường hợp này, nếu người nhận viết lên một trang được ánh xạ tới, một bản sao chính được làm tại chỗ. Khi một thông điệp không phải là một số nguyên các trang nhưng thông điệp đã được ánh xạ, một số dữ liệu chỉ cần vượt ra ngoài bộ đệm sẽ bị mất khi các trang cuối cùng (hoặc đầu tiên) mà ánh xạ tới.

Một dạng khác của thông điệp là minimessage, mà chỉ được sử dụng giữa các tiến trình hạt nhân cho đồng bộ hóa các thông điệp ngắn, thường là để báo hiệu sự xuất hiện của một ngắt. Các minimessages được gửi đến miniports đặc biệt.

4.2 Cổng (Port)

Message được gửi đến cổng (port), mỗi cổng trong số đó có thể lưu trữ  một số lượng nhất định các thông điệp. Nếu một thông báo được gửi tới một cổng đã đầy, người gửi bị đình chỉ cho đến khi có đủ không gian. Khi cổng được tạo ra, cả định danh duy nhất và một định danh cục bộ được trả lại cho người gọi. Sau đó là được sử dụng trong tiến trình xem xét các cổng trực tiếp. Chỉ Thread trong tiến trình hiện tại đang nắm giữ cổng có thể được đọc từ cổng.

Khi một tiến trình được tạo ra, nó sẽ tự động được gán một cổng mặc định mà hạt nhân sử dụng để gửi thông điệp ngoại lệ. Nó cũng có thể được tạo thêm nhiều cổng phụ (additional ports) nếu cần. Các cổng phụ (nhưng không phải là cổng mặc định) có thể được chuyển đến các tiến trình khác, ngay cả trên các máy khác. Khi một cổng bị chuyển, tất cả các message hiện tại nó chứa có thể di chuyển cùng với nó. Sự di động của cổng rất hữu ích, ví dụ, khi một máy chủ trên một máy tính muốn một máy chủ trên một máy khác nhau đảm nhận công việc của mình. Bằng cách này, các dịch vụ có thể được duy trì trong một cách tường minh.

Chorus cung cấp một cách để gộp một số cổng với nhau thành một nhóm các cổng (port group). Để làm như vậy, tiến trình đầu tiên tạo ra với một nhóm cổng trống và được trở lại một khả năng cho nó. Sử dụng khả năng này, nó có thể thêm các cổng vào nhóm, và sau đó nó có thể sử dụng khả năng xóa cổng khỏi nhóm. Một cổng có thể có mặt trong nhiều nhóm, như minh họa trong hình. 4.1.

Hình 4.1. Một cổng có thể là thành viên của nhiều nhóm cổng

Các nhóm cổng thường được sử dụng để cung cấp các dịch vụ cấu hình lại. Ban đầu thiế lập một số máy chủ thuộc về nhóm, cung cấp một số dịch vụ. Khách hàng có thể gửi message cho nhóm mà không cần phải biết được máy chủ có đang hoạt động. Sau đó, các máy chủ mới có thể tham gia vào nhóm và những máy chủ trước có thể mang đi mà không làm gián đoạn các dịch vụ và không ảnh hưởng tới các máy khách.

4.3. Hoạt động truyền thông

Hai loại hoạt động truyền thông được cung cấp bởi Chorus: gửi không đồng bộ (Asynchronous send) và RPC. Gửi Không đồng bộ cho phép một thread chỉ đơn giản để gửi thông điệp đến cổng. Không có gì đảm bảo rằng thông điệp đến và không có thông báo nếu gặp sự cố. Đây là dạng chuẩn nhất của gói dữ liệu và cho phép người dùng xây dựng các mô hình truyền thông tùy ý trên nó.

Các hoạt động truyền thông khác là RPC. Khi một tiến trình thực hiện một hoạt động RPC, nó sẽ bị khóa tự động cho đến khi nào có thông báo trả lời đến, hoặc bộ hẹn giờ RPC hết hạn, vào thời điểm đó người gửi là hết bị khóa. Thông điệp đó không cấm người gửi phải bắt buộc là sẽ có thông điệp phản hồi. Bất kỳ thông điệp nào không qua giao dịch nhận dạng của RPC sẽ được lưu trữ tại cổng để sử dụng trong tương lai, nhưng sẽ không phản hồi lại người gửi.

RPCs sử dụng ít nhất một lần nghĩa, có nghĩa là trong trường hợp một giao tiếp không thể khôi phục hoặc không chế biến, hệ thống phải bảo đảm sẽ có một RPC trả về một mã lỗi hơn là thay đổi, hoạt động được thực thi nhiều hơn một lần.

Nó cũng có thể gửi tin nhắn cho một nhóm cổng. Tùy chọn khác nhau được kích hoạt, như hình. 4.2. Các tùy chọn này xác định nhiều thông điệp được gửi và đến các cổng.

Hình 4.2. Tùy chọn cho việc gửi đến các nhóm cổng.

(a) Gửi đến tất cả cổng

(b) Gửi tới một cổng và được chọn

(c) Gửi tới cùng một cổng ở một trạng thái chỉ định

(d) Gửi tới cổng đang không ở trạng thái được chỉ định

Lựa chọn (a) trong hình. 4.2 sẽ gửi thông điệp tới tất cả các cổng trong nhóm. Để lưu trữ có độ tin cậy, một tiến trình có thể có tất cả các tập tin dữ liệu lưu trữ máy chủ nào đó. Option (b) gửi nó đến chỉ một cổng, nhưng cho phép hệ thống chọn một. Khi một tiến trình chỉ muốn một số dịch vụ, chẳng hạn như ngày tháng hiện hành, nhưng không quan tâm nó đến từ đâu, tùy chọn này là sự lựa chọn tốt nhất, như hệ thống sau đó có thể chọn cách hiệu quả nhất để cung cấp các dịch vụ.

Hai tùy chọn khác cũng được gửi tới chỉ một cổng, nhưng giới hạn sự lựa chọn hệ thống có thể thực hiện. Trong (c), người gọi có thể xác định rằng các cổng phải được trên một trạng thái cụ thể, ví dụ, để cân bằng tải hệ thống. Lựa chọn (d) cho rằng bất kỳ cổng nào không có trong trạng thái chỉ định có thể được sử dụng.

Để nhận được một thông điệp, một thread nói với hạt nhân gọi cổng nó muốn nhận. Nếu một thông điệp kích hoạt, phần cố định của tin nhắn được sao chép vào không gian địa chỉ của người gọi, và cơ thể, nếu có, là hoặc sao chép hoặc ánh xạ vào, tùy thuộc vào các tùy chọn. Nếu thông điệp không được kích hoạt, các thread bị treo cho đến khi một thông điệp đến hoặc bộ đếm thời gian người sử dụng quy định hết hạn.

Hơn nữa, một tiến trình có thể xác định rằng nó muốn nhận được từ một trong những cổng nó sở hữu, nhưng nó không quan tâm đến chúng. Tùy chọn này có thể được cải thiện bằng cách vô hiệu hóa một số các cổng, trong trường hợp này chỉ kích hoạt các cổng đủ điều kiện đáp ứng yêu cầu. Cuối cùng, các cổng có thể được gán ưu tiên, có nghĩa là nếu có nhiều hơn một cổng được nhận một thông điệp, các cổng với các ưu tiên cao nhất sẽ được chọn. Các cổng có thể được kích hoạt và vô hiệu hoá tự động, và các ưu tiên của chúng có thể được thay đổi.

4.4 Truyền thông semantics (Communication semantics)

Các cơ chế truyền thông đa tiến trình Chorus (IPC) cho phép các thread liên lạc bằng cách gửi thông điệp không đồng bộ hoặc bằng cách đặt các cuộc gọi thủ tục từ xa (RPC). Khi gửi một thông điệp không đồng bộ, phần dẫn (emmiter) sẽ bị khóa chỉ trong nội bộ của thông điệp.
Hệ thống không đảm bảo rằng thông điệp sẽ được nhận bởi các cổng đích.
Khi các cổng đích là không hợp lệ, người gửi không được thông báo và thông điệp sẽ bị loại.
Ngược lại, giao thức RPC cho phép xây dựng các dịch vụ sử dụng mô hình “máy chủ/khách”. RPC đảm bảo rằng các câu trả lời nhận được bởi máy khách là của các máy chủ tương ứng với yêu cầu của máy khách. RPC cũng cho phép một máy khách cho biết nếu yêu cầu của nó đã được nhận được bởi máy chủ, nếu máy chủ đã vô hiệu trước khi phát ra một phản hồi, hay nếu các đường dẫn liên lạc đã bị phá vỡ.
Không đồng bộ IPC và đồng bộ RPC là dịch vụ thông tin chỉ cung cấp bởi Chorus Nucleus. Các IPC không đồng bộ dịch vụ cơ bản là đủ để cho phép xây dựng các giao thức phức tạp hơn trong các hệ thống con. Nó làm giảm lưu lượng mạng trong trường hợp thành công, đạt hiệu suất cao hơn và rộng hơn vào các mạng lớn hay bận.
RPC là một khái niệm đơn giản, dễ hiểu, trong ngôn ngữ cấu trúc hiện nay, và dễ dàng xử lý trong trường hợp lỗi hoặc treo máy. Các Nucleus không cung cấp “kiểm soát lưu lượng”  khi yêu cầu ứng dụng rất khác nhau.

4.5. Lời gọi hạt nhân (Kernel Calls for Communication)

Các cuộc gọi quản lý cổng được thể hiện trong hình. 4.3. Việc đầu tiên cho phép các cổng được tạo ra, phá hủy, kích hoạt, và vô hiệu hóa. Việc cuối cùng là xác định một cổng và một tiến trình. Sau khi cuộc gọi hoàn thành, cổng không còn thuộc về chủ sở hữu ban đầu của nó (không cần phải là người gọi) mà thay vào đó thuộc về tiến trình đích. Nó bây giờ có thể đọc được các tin nhắn từ cổng.

Call Description
portCreate Tạo cổng và khả năng của nó
portDelete Hủy cổng
portEnable Kích hoạt cổng và đếm các thông điệp nhận được từ các cổng
portDisable Vô hiệu hóa cổng
portMigrate Dời cổng đến tiến trình khác

Hình 4.3. Chọn lời gọi quản lý cổng.

Ba lời gọi để quản lý các nhóm cổng. Chúng được liệt kê trong hình. 4.4. Đầu tiên, grpAllocate, tạo ra một nhóm cổng mới và trả về một khả năng cho nó để gọi. Sử dụng khả năng này, người gọi hoặc tiến trình khác sau đó sử dụng các khả năng có thể thêm hoặc xóa cổng khỏi nhóm.

Call Description
grpAllocate Tạo nhóm cổng
grpPortInsert Thêm cổng mới cho nhóm
grpPortRemove Xóa cổng từ nhóm

Hình 4.4. Lời gọi cho nhóm cổng

Lời gọi từ hạt nhân cho việc gửi và nhận tin nhắn. IpcSend gửi một thông điệp không đồng bộ với một cổng cụ thể hoặc một nhóm cổng. IpcReceive khóa trừ khi một thông điệp đến từ một cổng đặc biêt. Thông điệp này có thể đã được gửi trực tiếp đến cổng, cho một nhóm cổng trong đó cổng quy định là một thành viên, hoặc tất cả các cổng kích hoạt (giả sử rằng các cổng quy định được kích hoạt). Phần cố định trong địa chỉ nào đó được sao chép phải được cung cấp, nhưng một địa chỉ cho phần thân là tùy chọn, bởi vì kích thước không phải luôn luôn được biết. Nếu bộ đệm không được cung cấp cho phần than thì lời gọi ipcGetData có thể được thực hiện để thu được phần thân (kích thước được biết đến khi nó được trả về bởi các IpcReceive gọi). Một thông điệp trả lời có thể được gửi bằng cách sử dụng ipcReply. Cuối cùng, ipcCall thực hiện một cuộc gọi thủ tục từ xa.

Call Description
ipcSend Gửi thông điệp không đồng bộ
ipcReceive Khóa cho đến khi thông điệp đến
ipcGetData Nhận phần thân của thông điệp hiện tại
ipcReply Gửi phản hồi tới thông điệp hiện tại
ipcCall Gọi một thù tục từ xa

Hình 4.5. Chọn lời gọi truyền thông.

Phần 5: Định danh (Name Entities)

5.1 Định danh duy nhất (Unique Identifier)

Tất cả đối tượng của Chorus như tác nhân, cổng, và các phân đoạn (segments) được tham chiếu một cách tổng thể bằng cách sử dụng định danh duy nhất (UIs).

Chorus là một hệ thống phân tán, điều quan trọng là có một cách đặt tên các đối tượng trong một tập của các trạng thái đại diện cho một miền Chorus (Chorus domain). Các cấu trúc tiêu chuẩn sử dụng cho một định danh duy nhất cho phép các đơn vị quản lý riêng biệt được dễ dàng kết nối với nhau

Chorus Nucleus thực hiện một dịch vụ định vị định danh duy nhất (UILS) cho phép thực thể hệ thống sử dụng định danh duy nhất tham chiếu các đối tượng Chorus mà không có nhận dạng của mình tại vị trí hiện thời.

Chorus Nucleus đảm bảo rằng UI sẽ tồn tại ít nhất một trạng thái và sẽ không bao giờ sử dụng lại. UI là một cấu trúc 128 bit, có tính duy nhất được xây dựng bằng phương pháp cổ điển. Các dịch vụ định vị sử dụng một vài gợi ý cho việc tìm kiếm các đối tượng đại diện bởi UIs.

Các Nucleus không kiểm soát sự lan truyền của định danh duy nhất, đó là trách nhiệm của các hệ thống con cá nhân.

Hình 5.1  Tiến trình, luồng, vùng, thông điệp và cổng được định danh bởi UIs

5.2 Định danh cục bộ (Local Identifiers)

 

Định danh cục bộ (LIS) được sử dụng trong bối cảnh của một máy chủ để xác định các nguồn tài nguyên liên quan với máy chủ. Những định danh này được đại diện bởi số nguyên và được tạo ra bởi các máy chủ cục bộ. Chúng có thể truyền giữa các thực thể bên trong Chorus miền, nhưng chỉ có nghĩa khi tài nguyên tham chiếu của máy chủ đã tạo ra chúng. Đặc biệt, các định danh có thể đại diện một thứ tự trong bảng máy chủ hay một con trỏ đến một cấu trúc dữ liệu máy chủ.

5.3 Xác thực (Authentication)

Các Chorus Nucleus cung cấp khả năng bảo vệ các đối tượng được quản lý bởi các máy chủ hệ thống con. Vì tất cả các dịch vụ được gọi thông qua cơ chế Chorus IPC, sự hỗ trợ cung cấp không thể thiếu cơ chế này.
Nucleus hỗ trợ một định danh bảo vệ (protection identifier) cho mỗi tác nhân và cổng. Cấu trúc của các định danh là cố định, nhưng Nucleus không liên kết bất kỳ giá trị ngữ nghĩa nào với chúng. Định danh bảo vệ có thể được thay đổi bởi thread đáng tin cậy. Ngoài ra, tác nhân hoặc cổng có thể kế thừa định danh bảo vệ của các tác nhân đã tạo ra nó.
Mỗi thông điệp được gửi bởi một tác nhân có kiểm soát của Nucleus với các định danh bảo vệ của nó từ nguồn tác nhân và cổng. Những giá trị này có thể được đọc nhưng không được sửa đổi bởi người nhận của thông điệp và có thể được sử dụng để xác định danh tính của người yêu cầu của dịch vụ.

(Hết phần 4-5)

Hệ Điều Hành Phân Tán Chorus (Phần 3)

Phần 3: Quản lý tiến trình trong Chorus

3.1. Tiến trình (Processes)

Một tiến trình trong Chorus là tập hợp các yếu tố chủ động và thụ động làm việc với nhau để thực hiện một số tính toán. Các yếu tố hoạt động là các luồng (thread). Các yếu tố thụ động là một không gian địa chỉ (address space) như một số khu vực (region) và một tập các cổng (cho việc gửi và nhận thông điệp). Một tiến trình với một luồng như một tiến trình UNIX truyền thống. Một tiến trình không có luồng không thể làm bất cứ điều gì hữu ích, và thường chỉ tồn tại trong một khoảng rất ngắn trong khi một tiến trình đang được tạo ra.

Ba loại tiến trình tồn tại, khác nhau ở số lượng đặc quyền và sự tin cậy, như được liệt kê trong hình. 3-1. Đặc quyền (Privilege) là khả năng để thực hiện I / O và các hướng dẫn khác, Tin cậy (Trust) có nghĩa là tiến trình được phép gọi trực tiếp hạt nhân.

Type Trust Privilege Mode Space
User Untrusted Unprivileged User User
System Trusted Unprivileged User User
Kernel Trusted Privileged Kernel Kernel

Hình 3-1. 3 loại tiến trình trong Chorus.

Chorus có cấu trúc nhiều lớp, như minh họa trong hình. 3-2. Ở phía dưới là microkernel hay gọi là hạt nhân (nucleus). Nó cung cấp quản lý tối thiểu tên, tiến trình, luồng, bộ nhớ và truyền thông. Những dịch vụ này được truy cập bởi các cuộc gọi đến microkernel này. Hơn 100 cuộc gọi tồn tại. Các tiến trình trong các lớp cao hơn cung cấp cho phần còn lại của hệ điều hành. Mỗi máy trong hệ thống phân tán dựa trên Chorus chạy một bản sao giống hệt của Chorus microkernel.

Hình 3.2. Chorus có cấu trúc nhiều lớp, với một microkernel, các hệ thống con, và các quy trình người sử dụng

Phía trên  microkernel, là các tiến trình hạt nhân (kernel processes). Những tiến trình này có thể được tự động nạp và loại bỏ trong quá trình thực hiện hệ thống và cung cấp một cách để mở rộng chức năng của microkernel mà không cần tăng kích thước và độ phức tạp của nó. Từ đó các tiến trình này chia sẻ không gian hạt nhân với microkernel và với các tiến trình khác, sau đó phải di dời sau khi được nạp. Các tiến trình có thể gọi microkernel để có được dịch vụ, và có thể gọi nhau.

Ví dụ, xử lý ngắt được viết như các tiến trình hạt nhân. Trên một máy với một ổ đĩa, vào thời gian khởi động hệ thống, các tiến trình xử lý ngắt đĩa sẽ được nạp. Khi ngắt đĩa xảy ra, chúng sẽ được xử lý bởi tiến trình này. Trên các máy trạm không đĩa, các bộ xử lý đĩa gián đoạn là không cần thiết và sẽ không được nạp. Khả năng tự động tải và dỡ bỏ các quy trình hạt nhân làm cho nó có thể cấu hình hệ thống phần mềm để phù hợp với phần cứng, mà không cần phải biên dịch lại các microkernel

Các lớp tiếp theo bao gồm các tiến trình hệ thống (system processes). Những tiến trình này chạy trong chế độ người dùng, nhưng có thể gửi các thông điệp đến tiến trình hạt nhân (các tiến trình khác) và có thể thực hiện cuộc gọi đến các microkernel, thể hiện bởi các mũi tên trên hình 3.2. Một tập các tiến trình hạt nhân và hệ thống có thể làm việc cùng nhau để tạo thành một hệ thống con. Trong hình 3.2, các tiến trình S2, S1, và K1 hình thành một hệ thống con và tiến trình K2, S3 hình thành một hệ thống con thứ hai. Hệ thống con A trình bày một giao diện rõ ràng cho người sử dụng của nó, chẳng hạn như hệ thống UNIX gọi là giao diện. Một tiến trình trong mỗi hệ thống con là người quản lý và kiểm soát hoạt động của hệ thống con.

Trên các hệ thống con là tiến trình người dùng (user processes). Ví dụ, hệ thống các cuộc gọi được thực hiện bởi một tiến trình người dùng U1 có thể bị chặn bởi K1 và truyền lại cho S1 hoặc S2 để xử lý. Những tiến trình này, lần lượt, có thể sử dụng dịch vụ microkernel, khi thích hợp. Các hệ thống con làm cho nó có thể xây dựng hệ điều hành mới (hoặc cũ) trên microkernel như một mô-đun, và cho phép nhiều giao diện điều hành hệ thống để tồn tại trên một máy cùng lúc.

Tiến trình người sử dụng là không tin cậy và không có đặc quyền. Các tiến trình này không thể thực hiện I /O trực tiếp, và không thể gọi cho hạt nhân, trừ các cuộc gọi mà hệ thống con đã làm. Mỗi tiến trình người dùng có hai phần: phần người sử dụng thường xuyên và một phần hệ thống được gọi sau khi gặp sự cố. Sự sắp xếp này cũng tương tự như cách UNIX làm.

Mỗi tiếntrình (và cổng) có một định danh bảo vệ (protection identifier) liên kết với nó. Nếu tiến trình nhánh, các cá thể của nó được thừa hưởng cùng một bảo vệ nhận dạng. Định danh này chỉ là một chuỗi bit, và không có bất kỳ ngữ nghĩa liên kết nào cho biết rằng hạt nhân biết về nó. Bảo vệ định danh cung cấp một cơ chế có thể được sử dụng để xác thực. Ví dụ, các hệ thống con UNIX có thể chỉ định một UID (người sử dụng nhận dạng) với mỗi quá trình và sử dụng các bảo vệ định danh để thực hiện các UID.

3.2 Luồng (Threads)

Mỗi tiến trình hoạt động trong Chorus có một hoặc nhiều luồng (thread) để thực thi các mã. Mỗi thread có bối cảnh riêng của nó (như stack, chương trình truy cập, và đăng ký), và sẽ được lưu khi các khối thread đang chờ đợi sự kiện nào đó và được phục hồi khi thread này được kết nối lại. Thread gắn liền với tiến trình mà nó được tạo ra, và không thể chuyển tới tiến trình khác.

Thread trong Chorus được quản lí bởi hạt nhân và dự kiến ​​bởi hạt nhân, do đó, để tạo ra và phá hủy chúng cần thực hiện liên lạc với hạt nhân. Một lợi thế là khi một khối thread chờ đợi đối với một số sự kiện (ví dụ, khi một thông điệp đến), hạt nhân có thể sắp xếp cho một thread khác. Một lợi thế khác là khả năng chạy các thread khác nhau trên các CPU khác nhau khi bộ đa xử lý đang hoạt động. Những bất lợi của thread hạt nhân là cần thêm chi phí cần thiết để quản lý chúng. Tất nhiên, người dùng vẫn còn miễn phí để thực hiện một gói các thread cấp người dùng bên trong một thread hạt nhân duy nhất.

Thread liên lạc với nhau bằng cách gửi và nhận thông điệp. Nó không quan trọng nếu người gửi và người nhận đang trong tiến trình tương tự hoặc là trên các máy khác nhau. Nếu có từ hai thread cùng trong tiến trình, chúng có thể giao tiếp bằng cách sử dụng bộ nhớ chia sẻ, nhưng sau đó hệ thống có thể không cấu hình lại được để chạy với các thread trong các tiến trình khác.

Các trạng thái dưới đây được phân biệt, nhưng không loại trừ lẫn nhau:
1. KÍCH HOẠT (ACTIVE) – Thread có thể chạy.
2. TREO (SUSPENDED)- Thread này đã bị hoãn.
3. DỪNG (STOPPED) – Tiến trình của thread này đã bị hoãn.
4. CHỜ (WAITING) – Các thread đang chờ một số sự kiện xảy ra.

Một thread trong trạng thái ACTIVE hoặc là đang chạy hoặc chờ đến lượt của mình cho một CPU rảnh. Trong cả hai trường hợp, nó đều có thể chạy. Một thread ở trạng SUSPENDED đã bị treo bằng một thread khác (hoặc tự bản thân nó) mà một hạt nhân ban hành. Tương tự, khi hạt nhân ngăn chặn một tiến trình, tất cả các thread trong trạng thái ACTIVE được đặt ở trạng thái dừng lại (STOPPED) cho đến khi tiến trình này được tiếp tục. Cuối cùng, khi một thread thực hiện một hoạt động ngăn chặn mà không thể được kết thúc ngay lập tức, thread được đặt trong tình trạng WAITING cho đến khi sự kiện xảy ra.

Một thread có thể được ở nhiều hơn một trạng thái cùng lúc. Ví dụ, một thread trong tình trạng bị treo sau đó cũng có thể nhập trạng thái dừng lại và nếu tiến trình của nó bị treo. Khái niệm, mỗi thread có ba bit độc lập liên kết với nó, mỗi bit cho trạng thái TREO, DỪNG, và CHỜ. Chỉ khi cả ba bit bằng 0 thì  có thể chạy thread.

Các thread chạy trong chế độ và không gian địa chỉ tương ứng với tiến trình của chúng. Nói cách khác, các thread của một tiến trình hạt nhân chạy ở chế độ hạt nhân, và các chủ đề của tiến trình người sử dụng chạy trong chế độ người dùng.

(Hết phẩn 3)

Hệ Điều Hành Phân Tán Chorus (Phần 2)

Phần 2: Kiến trúc HĐH Chorus

2.1 Khái quát chung:

Một hệ thống Chorus bao gồm một Nucleus nhỏ và một bộ hệ thống máy chủ, mà hợp tác trong bối cảnh các hệ thống con (Hình 2.1).

Hình 2.1: Kiến trúc Chorus

Điều này cung cấp cơ sở cho một hệ điều hành mở. Ở cấp độ này, sự phân tán là ẩn. Sự lựa chọn này được thực hiện để xây dựng một cơ cấu hợp lý cấp hai, với một Nucleus chung ở mức thấp nhất và gần như tự trị, các hệ thống con cung cấp các ứng dụng với hệ điều hành truyền thống.

Vì vậy, các Chorus hạt nhân không phải là cốt lõi của một hệ điều hành cụ thể, thay vì nó cung cấp công cụ chung được thiết kế để hỗ trợ một loạt các hệ thống con chủ, mà có thể cùng tồn tại bên trên của hạt nhân.

Cấu trúc này hỗ trợ các chương trình ứng dụng, mà đã được chạy trên một hệ điều hành hiện tại, theo cách tái tạo hoạt động của hệ thống giao diện bên trong một hệ thống con.

Một ví dụ cho phương pháp này được đưa ra sử dụng trong môi trường thực thi UNIX (UNIX emulation) được gọi là Chorus / MiX .

Ý tưởng kinh điển của tách các chức năng của một hệ điều hành vào các nhóm dịch vụ cung cấp bởi các máy chủ tự trị là trung tâm của Chorus. Trong các hệ thống nguyên khối, các chức năng này thường là một phần của”hạt nhân”. Tác dụng việc phân tách này làm tăng Modul, và do đó  làm linh hoạt các thành phần trong hệ thống tổng thể.

2.1.1 Các hạt nhân Chorus (Chorus Nucleus)

Hạt nhân Chorus ở cấp độ thấp nhất, quản lý các nguồn tài nguyên vật lý của một vùng. Ở mức cao nhất, nó cung cấp cơ chế cho quá trình giao tiếp giữa các vị trí (IPC). Các Nucleus gồm có bốn thành phần chính cung cấp dịch vụ cục bộ (local) và toàn hệ thống (global)

(Hình 2.2):

Chorus giám sát: sự cố treo, ngắt, có lỗi, và trường hợp ngoại lệ được chuyển đi bằng phần cứng;

Chorus quản lý thời gian thực:  kiểm soát việc phân bổ các bộ xử lý và cung cấp thành phần đồng bộ và  kế hoạch ưu tiên;

Chorus quản lý bộ nhớ ảo: có trách nhiệm điều khiển bộ nhớ ảo phần cứng và tài nguyên bộ nhớ cục bộ;

Chorus quản lý đa tiến trình giao tiếp: cung cấp thông tin không đồng bộ trao đổi và thủ tục gọi từ xa (RPC) cơ sở tại một vị trí độc lập.

Hình 2.2: Chorus Nucleus

Không có sự phụ thuộc giữa bốn thành phần hạt nhân của Chorus. Kết quả tất yếu là, việc phân phối các dịch vụ cung cấp bởi nhà Nucleus gần như ẩn. Dịch vụ tại đâu thì giải quyết với các tài nguyên tại đó và có thể được chủ yếu là quản lý chỉ sử dụng thông tin của nơi đó. Dịch vụ toàn hệ thống phải kết hợp với các hạt nhân để cung cấp phân phối.

Trong Chorus – V3 nó đã được quyết định, dựa trên hiệu quả kinh nghiệm với Chorus -V2, bao gồm trong các Nucleus một số chức năng mà có thể đã được cung cấp bởi các máy chủ hệ thống: tác nhân, cổng quản lý, quản lý tên, và quản lý RPC.

Các tiêu chuẩn cho cơ chế Chorus IPC là chính các phương tiện sử dụng để giao tiếp với quản lý trong hệ thống. Ví dụ, người quản lý bộ nhớ ảo sử dụng Chorus IPC gửi dữ liệu yêu cầu đến dịch vụ sửa lỗi.

Các Nucleus cũng được thiết kế để dễ di động, trong đó, trong một số trường hợp, có thể ngăn cản việc sử dụng một số tính năng phần cứng nằm bên dưới. Kinh nghiệm có được từ porting các Nucleus đến các Đơn vị quản lý bộ nhớ (MMU) của ba bộ chip và có xác nhận hợp lệ sự lựa chọn này.

2.1.2 Các hệ thống con (Subsystems)

Hệ thống máy chủ làm việc hợp tác để cung cấp một giao diện hệ điều hành chặt chẽ, được gọi như là một hệ thống con.

2.1.3 Hệ thống giao diện (System Interfaces)

Một hệ thống Chorus cung cấp cấp độ khác nhau của giao diện (hình 1).

Giao diện Nucleus cung cấp truy cập trực tiếp đến dịch vụ cấp thấp của Chorus hạt nhân.

Một giao diện hệ thống con được thực hiện bởi một tập các máy chủ cùng hợp tác, và thông thường đại diện cho hệ thống điều hành trừu tượng phức tạp. Một số hệ thống con khác nhau có thể được cư trú trên một hệ thống Chorus đồng thời, cung cấp một loạt các hệ điều hành hoặc cấp cao giao diện để làm thủ tục ứng dụng khác nhau. thư viện người dùng, chẳng hạn như “C”thư viện, tăng cường hơn nữa giao diện Chorus bằng cách cung cấp cơ sở lập trình thường được sử dụng.

2.1.4 Các hệ thống con hướng đối tượng

Là một thí nghiệm nghiên cứu, một hệ thống con thứ hai đã được thực hiện bởi lập trình hướng đối tượng. Nó bao gồm ba lớp. Các lớp dưới cùng làm quản lý đối tượng theo một cách chung và có một microkernel hiệu quả cho các hệ thống hướng đối tượng. Lớp giữa cung cấp một hệ thống thời gian chạy chung. Lớp trên cùng là hệ thống thời gian chạy ngôn ngữ. Hệ thống con này, được gọi là COOL.

2.2 Cấu trúc hạt nhân (Kernel Structure)

Hạt nhân bao gồm bốn phần, như được minh họa trong hình 2.3. Ở phía dưới là các tác nhân giám sát, trong đó quản lý phần cứng và bắt bẫy, trường hợp ngoại lệ, làm gián đoạn, và chi tiết phần cứng khác, và xử lý chuyển ngữ cảnh. Nó được viết một phần trong assembler và phải được làm lại khi Chorus được chuyển đến phần cứng mới.

Hình 2.3. Cấu trúc hạt nhân

Tiếp đến bộ phận quản lý bộ nhớ ảo (virtual memory manager), xử lý một phần ở mức thấp của hệ thống phân trang. Phần lớn nhất của nó liên hệ với quản lý lưu trữ trạng thái và các khái niệm hợp lý khác, là các máy tính độc lập.

Hai bộ phận của VMM không làm tất cả công việc quản lý hệ thống phân trang với nhau. Một phần thứ ba, các ánh xạ (mapper), là bên ngoài hạt nhân và là phần cấp cao. Các giao thức giao tiếp giữa VMM và mapper cũng được xác định, do đó người dùng có thể cung cấp mappers riêng của mình.

Phần thứ ba của hạt nhân là điều hành thời gian thực (real-time executive). Nó có trách nhiệm quản lý các tiến trình, đề tài, và lập kế hoạch. Nó cũng sắp xếp để đồng bộ hóa giữa các thread cho việc loại trừ lẫn nhau và mục đích khác.

Cuối cùng, chúng ta có quản lý truyền thông liên tiến trình (interprocess communication manager), xử lý UIs, cổng, và việc gửi thông điệp trong một cách minh bạch. Nó sử dụng dịch vụ của các hoạt động thời gian thực và quản lý bộ nhớ ảo để làm công việc của mình. Bốn phần của hạt nhân được xây dựng thành các mô-đun, vì thế thay đổi phần này thì không ảnh hưởng đến các phần khác.

(Hết Phần 2)

Hệ Điều Hành Phân Tán Chorus (Phần 1)

Cùng với sự phát triển của mạng máy tính, việc tính toán, quản lý ngày nay không chỉ đơn giản tập trung  trong máy tính đơn như trước nữa.

Nó đòi hỏi các hệ thống tính toán phải được kết hợp từ một số lượng lớn các máy tính kết nối với nhau qua 1 mạng tốc độ cao. Chúng thường được gọi là các mạng máy tính hay còn có tên khác là các Hệ phân tán. Hệ phân tán ra đời đã giúp chúng ta giản thiểu được rất nhiều chi phí về vật chất, tiền của, con người, bằng việc sử dụng một cách hợp lý tài nguyên chung. Chỉ với một con vi xử lý mà nó làm được nhiều việc trong một khoảng thời gian, chỉ với một đường truyền nhiều người có thể sử dụng.
Một mục tiêu quan trọng của việc nghiên cứu và phát triển hệ phân tán là phát triển hệ điều hành phân tán. Chúng ta có thể định nghĩa những mục tiêu hệ điều hành phân tán bằng cách so sánh với những hệ điều hành quy ước như UNIX, một hệ điều hành chuẩn. Không giống như các hệ điều hành quy ước, hệ điều hành phân tán có thể điều chỉnh và mở rộng. Các thành phần mới có thể được bổ sung vào hệ điều hành phân tán để đáp ứng những yêu cầu mới của các chương trình ứng dụng. Mô đun trong hệ điều hành phân tán dựa trên sự hỗ trợ của truyền thông giữa các mô đun.

Bài tiểu luận này chúng ta sẽ nghiên cứu về hệ điều hành Chorus, một hệ điều hành phân tán thông qua các nguyên lý của hệ phân tán. Bài viết đề cập đến các vấn đề kiến trúc hệ điều hành Chorus, vấn đề quản lý tiến trình, quản lý truyền thông, định danh, và các vấn đề về xử lý ngoại lệ, phần cuối là sự so sánh giữa 3 hệ điều hành phân tán Amoeba, Mach với Chorus.

Phần 1: Giới thiệu về HĐH phân tán Chorus

Ngày nay với sự phát triển của các ứng dụng máy tính, việc thiết kế một hệ thống phân tán mà các yêu cầu về vấn đề hiệu quả và khả thi đã tăng lên, nhằm phục vụ nhu cầu sử dụng trong xây dựng, hoạt động, và hành chính.
Sự tiến hóa này đã kéo theo các yêu cầu về một cấu trúc hệ thống mới mà khó có thể thực hiện chỉ bằng cách lắp ráp các hệ thống mạng lưới hợp tác. Trong phần 1 này chúng ta sẽ nghiên cứu về tổng quan về hệ điều hành Chorus gồm lịch sử ra đời và các phiên bản.

  • Hệ điều hành phân tán

Một hệ điều hành phân tán là một tập hợp của các thành phần phần mềm, mà nó đơn giản hoá các tác vụ của chương trình và hỗ trợ trên phạm vi lớn nhất có thể của các chương trình ứng dụng. Hệ điều hành phân tán thực thi các tác vụ bằng cách thực thi các chương trình ứng dụng trên diện rộng, định hướng trừu tượng tài nguyên trong hệ thống phân tán.

Trong một hệ phân tán mở, hệ điều hành phân tán được thực thi bởi một tập hợp của các nhân, và các máy chủ (các tiến trình máy chủ). Không có sự phân chia rõ rệt giữa hệ điều hành phân tán (hoặc đúng hơn là các dịch vụ mở của nó) và các trình ứng dụng chạy trên nền của hệ phân tán mở đó.

Một hệ điều hành phân tán phải cung cấp những điều kiện thuận lợi gói gọn trong một mô đun, và bảo vệ cấu thành đó, trong khi các máy khách truy cập tài nguyên trên mạng diện rộng. Các nhân và các máy chủ đều quản trị các nguồn tài nguyên:

– Sự đóng gói: Cả nhân và máy chủ đều cung cấp giao diện dịch vụ có lợi cho tài nguyên của chúng, đó là thiết lập những thao tác đáp ứng yêu cầu của các máy khách. Chi tiết của việc quản lý bộ nhớ và các thiết bị để thực thi các nguồn tài nguyên, nên được ẩn đi từ các máy khách, thậm chí ngay cả khi chúng cùng nằm trong một phạm vi.

– Xử lý đồng thời: Các máy khách có thể chia sẻ các nguồn tài nguyên và truy cập vào chúng một cách đồng thời. Quản trị tài nguyên chịu trách nhiệm về tính tương tranh trong suốt.

– Bảo vệ: Các nguồn tài nguyên yêu cầu phải được bảo vệ bởi những truy cập bất hợp pháp.

– Để thực hiện cùng lúc các lời gọi tác vụ liên quan sau:

+ Sự phân giải tên: Máy chủ (hoặc nhân) quản trị một nguồn tài nguyên phải được định vị từ các định danh của nguồn tài nguyên.

+ Truyền thông: Các đối số của thao tác và kết qủa phải được truyền đi từ các nguồn tài nguyên được quản trị đến một mạng hoặc một máy tính cá nhân.

+ Lập biểu: Vấn đề này liên quan đến vấn đề tương tranh, khi một lệnh được thực thi, tiến trình của nó phải được lập biểu trong phạm vi của nhân hoặc máy chủ.

Trong hệ điều hành, nhân có vai trò quan trọng, nó cung cấp những kỹ thuật cơ bản nhất nhưng vẫn mang tính tổng quát, nó có nhiệm vụ quản lý tài nguyên. Máy chủ có thể thích nghi với sự tự động nạp vào, thực thi đòi hỏi  những chính sách quản lý tài nguyên. Chỉ có một vài cơ sở nghiên cứu trong hệ thống phân tán, có thể nói rằng điều khiển bởi một trình đơn thuần nhất trong hệ điều hành phân tán mà mọi máy tính thi hành tương tự như nhân. Một hệ điều hành phân tán phải hiện hành trên mạng với những quy ước: Các nhân của hệ điều hành như là UNIX, mà hầu hết các trạm làm việc thi hành và nhiều ứng dụng được tồn tại.

Công nghệ Chorus đã được thiết kế để xây dựng thế hệ mới mở, phân tán, một hệ điều hành có thể mở rộng. Chorus có các đăc điểm chính sau đây:

+ một kiến trúc trên nền tảng truyền thống, dựa trên một hạt nhân (Nucleus) tối thiểu có tích hợp xử lý phân tán và truyền thông ở mức thấp nhất, và đó thực hiện các dịch vụ chung được sử dụng bởi một tập các máy chủ hệ thống con.
+ một thời gian thực Nucleus cung cấp dịch vụ thời gian thực sử dụng để lập trình hệ thống;
+ một kiến trúc mô-đun cung cấp khả năng mở rộng, và cho phép cấu hình cụ thể của hệ thống và ứng dụng của nó trên một loạt các phần cứng và cấu hình mạng, bao gồm cả hệ thống song song và đa hệ thống.

Các kiến ​​trúc Chorus đã được thiết kế để đáp ứng các yêu cầu này, nền tảng của nó là một Nucleus chung chạy trên mỗi máy. Truyền thông và phân phối được quản lý ở cấp thấp nhất của Nucleus này. Hệ điều hành truyền thống được xây dựng như các hệ thống con trên của Nucleus chung và sử dụng các dịch vụ cơ bản của nó.

  • Lịch sử hệ điều hành Chorus

Chorus  là một dự án nghiên cứu trên các hệ phân tán tại INRIA1 tại Pháp 1979-1986. Ba phiên bản được phát triển, gọi tắt là CHORUS-V0, CHORUS-V1, và CHORUS-V2, dựa trên một hạt nhân theo định hướng truyền thông. Các khái niệm cơ bản để xử lý tính toán phân tán trong Chorus, cho cả hệ thống và dịch vụ ứng dụng, đó là một hạt nhân (Nucleus) quản lý việc trao đổi tin nhắn giữa các cổng thuộc các tác nhân.

Trong khi phiên bản đầu của CHORUS đã có giao diện tùy chỉnh, CHORUS-V2  tương thích với hệ thống UNIX V, và đã được sử dụng làm cơ sở để hỗ trợ các ứng dụng thử nghiệm phân tán. CHORUS-V3 là phiên bản hiện hành được  xây dựng dựa trên kinh nghiệm các CHORUS trước và tích hợp nhiều khái niệm từ các dự án nghiên cứu phát triển hệ thống phân tán.

  • Các phiên bản Chorus:

 

  • CHORUS 2V0 (1980-1982)

CHORUS-V0 thử nghiệm với ba khái niệm chính:
+ Các hoạt động của một tác nhân, đó là một chuỗi luân phiên các giai đoạn thực hiện liên tục và các giai đoạn giao tiếp.

+ Một ứng dụng phân tán, mà là một tập các tác nhân độc lập truyền thông độc quyền bằng cách trao đổi các thông điệp thông qua các cổng, hoặc một nhóm các cổng. Các cổng quản lý và đặt tên được thiết kế để cho phép chuyển đổi và cấu hình lại các cổng động của ứng dụng.
+ Hệ điều hành được xây dựng như một Nucleus nhỏ, đơn giản và đáng tin cậy, nhân rộng trên mỗi trang web, và bổ sung bởi các tác nhân của hệ thống phân tán phụ trách các cổng, tác nhân, files, thiết bị đầu cuối, quản lý mạng

  • CHORUS-V1 (1982-1984)

Đây là phiên bản chuyển CHORUS từ nguyên mẫu thành  một hệ thống thực. Trang web này là  SM90 đa vi máy tính – dựa trên Motorola 68000 và sau đó là 68.020 – kết nối với nhau bởi một 10Mb / s Ethernet. Trong một cấu hình đa xử lý, một bộ xử lý chạy UNIX là một hệ thống phát triển và quản lý đĩa, và lên đến bảy bộ vi xử lý khác chạy CHORUS với một hệ thống CHORUS điều khiển mạng. Các mã Pascal đã được biên dịch.
Trọng tâm chính của phiên bản này là thử nghiệm việc thực thi CHORUS trên nền kiến ​​trúc đa xử lý.
Việc thiết kế đã có một số thay đổi từ CHORUS-V0, cụ thể là:
+ Các thông điệp cấu trúc đã được xây dựng để cho phép gắn vào các giao thức và chuyển ngữ cảnh của chúng.
+ Khái niệm về thông báo hoạt động, nó biểu hiện dữ liệu, bối cảnh cho các tính toán nhúng, và đồ thị của các tính toán trong tương lai, đã được thử nghiệm với các ứng dụng chịu lỗi.

CHORUS-V1 đã được chạy vào giữa năm 1984. Nó đã được phân phối đến một vài nơi thử nghiệm, và một trong số đó vẫn còn sử dụng hệ thống.

  • CHORUS-V2 (1984-1986)

Thông qua UNIX  buộc các giao diện CHORUS phải viết lại và hệ thống các tác nhân phải thay đổi.
Tuy vậy các Nucleus, thay đổi rất ít. Các hệ thống con UNIX được phát triển một phần từ kết quả của dự án Sol (File Manager), và một phần từ đầu (Process Manager). Những khái niệm như cổng, thông điệp, các bước xử lý, và các cuộc gọi thủ tục từ xa đã được xem xét lại. Thay đổi được thực hiện cho phù hợp chặt chẽ hơn về UNIX ngữ nghĩa. Giao diện UNIX được mở rộng để hỗ trợ các ứng dụng phân phối bởi các phương tiện chức năng mới như tín hiệu phân tán, và các tập tin phân tán.

CHORUS-V2 cung cấp một cơ hội để xem xét lại toàn bộ kiến ​​trúc UNIX hạt nhân đối với hai khái niệm sau đây:
+Mô đun (Modularity): tất cả các dịch vụ UNIX được chia thành một số tác nhân độc lập. Sự phân chia này yêu cầu thiết kế của giao diện cụ thể giữa các dịch vụ UNIX mà trước đây phụ thuộc vào chia sẻ cấu trúc dữ liệu hạt nhân.
+Phân bố (Distribution): đối tượng như các tập tin và các tiến trình, quản lý bởi các tác nhân hệ thống, có thể được phân phối trong Chorus, như các dịch vụ fork  hoặc exec.

Điều này đòi hỏi sự phát triển của giao thức mới cho các dịch vụ phân tác, chẳng hạn như việc đặt tên và vị trí của đối tượng.
Công việc này cung cấp những kinh nghiệm vô giá khi nó đến sự phát triển của CHORUS-V3; CHORUS-V2 có thể được coi như là một dự thảo của các phiên bản hiện hành. CHORUS-V2 đã được chạy vào cuối năm 1986. Nó đã được ghi nhận và được sử dụng bởi nhóm nghiên cứu bên ngoài các dự án Chorus.

  • CHORUS-V3 (1987-nay)

Mục tiêu của phiên bản này là cung cấp một sản phẩm công nghiệp tích hợp tất cả các khía cạnh tích cực của các phiên bản trước của CHORUS cũng như các hệ thống khác. CHORUS cũng cung cấp một số tính năng mới đáng kể. Các phần về sau em trình bày là mô tả của phiên bản này.

(Hết phần 1)

Thuật toán kết hợp đa sinh trắc theo mô hình đa thể hiện trong hệ thống BIOPKI

Trong phạm vi đề tài nghiên cứu KHCN cấp nhà nước KC.01.11/06-10 về “Nghiên cứu xây dựng hệ thống kiểm soát truy cập mạng và an ninh thông tin dựa trên sinh trắc học sử dụng công nghệ nhúng, BioPKI”, công trình này tập trung nghiên cứu và thiết kế thuật toán xác thực đa sinh trắc và thử nghiệm ứng dụng trên nền tảng hệ thống BioPKI.

Hiện nay, phần lớn các hệ xác thực sinh trắc hiện nay chỉ sử dụng một dấu hiệu sinh trắc để xác minh định danh. Các hệ đơn sinh trắc này có một số nhược điểm đáng lưu ý nhất là tỷ lệ chấp nhận sai (False Acceptance Rate) sẽ tăng nhanh khi số lượng người dùng lớn và chịu ảnh hưởng lớn của nhiễu khi dữ liệu sinh trắc thu nhận trong điều kiện thực tê. Chính vì lý do này, người ta tiến hành kết hợp nhiều dấu hiệu sinh trắc nhằm giải quyết các nhược điểm nói trên.

Đề tài này đề xuất một thuật toán nhằm kết hợp đa sinh trắc theo mô hình đa thể hiện dùng sinh trắc nhiều ngón tay trên cơ sở tối thiểu hóa tỷ lệ chấp nhận sai và tỷ lệ từ chối sai. Thuật toán cài đặt trong môi trường C++ và đã thử nghiệm thành công trong trường hợp kết hợp đa sinh trắc vân tay hai ngón với kết quả khả quan.

 

TÀI LIỆU THAM KHẢO

 

  • A Wiley Tech Brief, Samir Nanavati, Michael Thieme ,Raj Nanavati, “Biometrics Identity Verification in a Networked World
  • Anil Jail, Ruud Bolle, Sharath Pankanti, “Biometrics – Personal Identification in Networked Society
  • Paul Reid “Biometrics for Network Security“.

[4] Suranjan Choudhury, Kartik Bhatnagar and Wasim Haque, “Public Key Infrastructure Implementation and Design”. M&T Books, 2002.

[5]. C.Adam, S.Lloyd, “Understanding PKI: Concept, Standard and Develoyment Consideration”, 2nd ed. , Addition Wesley 2002.

[6]. FX3 SDK User Guide.

Thiết kế tích hợp thẩm dịnh sinh trắc học trong hệ thống BK-BIOPKI

Hạ tầng cơ sở khoá công khai (Public Key Infrastructure – PKI) đang được nghiên cứu phát triển và triển khai là cơ sở cho các giao dịch điện tử trên mạng.

Tuy nhiên nguy cơ mất an toàn trong hệ PKI thường gặp ở vấn đề quản lý và bảo vệ khoá cá nhân (Private Key). Xây dựng hệ thống an ninh thông tin dựa trên kết hợp sinh trắc học với cơ sở hạ tầng khóa công khai PKI là hướng tiếp cận  BioPKI đang được quan tâm nghiên cứu.

Đề tài nghiên cứu này thuộc Đề tài nghiên cứu cấp nhà nước theo nghị định thư hợp tác với Malaysia về “Hệ thống an ninh sinh trắc học BK-BioPKI” của khoa CNTT. Báo cáo này trình bày chủ yếu về thiết kế và cài đặt hệ thống BioPKI phân hệ RA-User tích hợp một giải pháp sử dụng đặc trưng vân tay để bảo vệ khoá cá nhân trong hệ thống BK-BioPKI. Đề tài này đã đề xuất giải pháp sử dụng đặc trưng vân tay sinh tập khóa sinh trắc học (BEK- biometric encryption key) và sử dụng tập khóa này để bảo vệ khóa cá nhân. Trong quá trình tạo cặp khóa RSA, người dùng được yêu cầu quét vân tay. Tập khóa BEK được sinh ra từ mẫu vân tay của người dùng. Để tập khóa BEK có độ ổn định cao, người dùng được yêu cầu quét vân tay nhắc lạ một số lần và tập khóa BEK được dùng để mã hóa bảo vệ khóa cá nhân. Khi muốn truy xuất khoá cá nhân, vân tay người dùng phải được thẩm định xác thực bởi quá trình thẩm định vân tay lấy trực tuyến. Chương trình thiết kế và cài đặt trong môi trường Visual C++ 7.1 trên nền Windows.

Tài liệu tham khảo chính

  1. Alex Stoianow and Ann Cavoukian, Biometric Encryption: A Posotive-Sum Technology that Achieves strong Authentication, Security AND Privacy, 2007.
  2. Ing. Martin Drahanský, Biometric Security System Fingerprint Recognition Technology, luận văn tiến sỹ đại học kỹ thuật BRNO, Sec, 3/2005.

3 F. Hao, R. Anderson, J. Daugman, Combining cryptography with biometrics effectively, Computer Laboratory – University of Cambridge, No. 640, 7-2005.

Hệ thống tính toán tình nguyện BOINC

Tính toán tình nguyện là một mô hình tính toán phân tán dựa trên việc tận dụng thời gian nhàn rỗi của các máy tính kết nối vào mạng Internet.

Bắt đầu từ cuối những năm 1990, tính toán tình nguyện đã từng bước phát triển và khẳng định chỗ đứng của mình trong khoa học máy tính bằng những dự án tiêu biểu như : SETI@Home [2], ClimatePrediction[6], Einstein@Home[5] … Tính toán tình nguyện cho phép các cá nhân, tổ chức có thể dễ dàng tham gia và đóng góp công sức vào các hoạt động khoa học mang tính cộng đồng. Đó cũng là một cách để các tổ chức quảng bá, phổ biến các hoạt động khoa học ra cộng đồng. Để bắt kịp với xu thế chung của thế giới, từ năm 2008, Trung tâm Tính toán hiệu năng cao, Trường Đại học Bách Khoa Hà Nội đã triển khai nghiên cứu, tìm hiểu, làm chủ công nghệ tính toán tình nguyện với nền tảng là gói phần mềm BOINC, từ đó từng bước ứng dụng vào thực tiễn.

Với mong muốn áp dụng công nghệ tính toán tình nguyện để giải quyết các bài toán thực tế của Việt Nam với hiệu năng tốt nhất. Đề tài nghiên cứu này đã đi sâu nghiên cứu và tìm hiểu các công nghệ mới nhất về tính toán tình nguyện, từ đó khai thác những ưu điểm sẵn có, tìm ra những nhược điểm cần cải tiến và khắc phục, nhằm thiết lập nên một hệ thống lưới tính toán tình nguyện đáp ứng được các nhu cầu tính toán hiện có, cụ thể như sau:

  • Công nghệ nền tảng để xây dựng hệ thống dựa trên gói phần mềm mã nguồn mở BOINC [5], đây là chính gói phần mềm được sử dụng rộng rãi và thành công nhất cho các dự án tình toán tình nguyện hiện nay trên thế giới.
  • Xây dựng thành công lưới tính toán tình nguyện với máy chủ đặt tại địa chỉ 202.191.56.60, sử dụng gói phần mềm BOINC, trong đó phần mềm BOINC server đã được cải tiến, sử dụng giải thuật lập lịch mới tiên tiến : “Giản đồ lập lịch chịu lỗi Round Robin dựa trên độ tin cậy” của TS. Luis.F.G. Sarmenta, Viện công nghệ Massachusetts – MIT, nhằm tăng hiệu năng thực thi của hệ thống trong khi vẫn đảm bảo yêu cầu về độ chính xác của các kết quả tính toán.
  • Triển khai thành công ứng dụng mô phỏng khuếch tán nguyên tử của bộ môn Vật lý Tin học – Đại học Bách Khoa Hà Nội, lên lưới tính toán tình nguyện, chạy thử nghiệm và thu được kết quả chính xác với hiệu năng được cải thiện rõ rệt.

Hệ thống tính toán tình nguyện xây dựng trong đề tài nghiên cứu hiện đã chạy thử nghiệm thành công và có thể kết nối từ bên ngoài vào qua địa chỉ URL: 202.191.56.60/VCP bằng phần mềm client trong gói phần mềm BOINC. Mọi thông tin liên quan đến đề tài có thể tham khảo trang chủ của đề tài tại địa chỉ : http://hpcc.hut.edu.vn/vcp/

TÀI LIỆU THAM KHẢO

  • Nông Thị A, Giàng A Sử, “Một số vấn đề chọn lọc của tin học”, kỷ yếu hội thảo FAIR 2007, 2007.
  • Nguyễn Dũng, “Một số vấn đề nâng cao của tin học”,
  • Eason, B. Noble, and I. N. Sneddon, “On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,” Phil. Trans. Roy. Soc. London, vol. A247, pp. 529-551, Apr. 1955.
  • Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp. 68-73.
  • S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds.  New York: Academic, 1963, pp. 271-350.
  • Elissa, “Title of paper,” unpublished.
  • Nicole, “Title of paper with only first word capitalized,” J. Name Stand. Abbrev., submitted for publication.
  • J. Kaufman, Rocky Mountain Research Laboratories, Boulder, CO, personal communication, 1992.
  • Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy studies on magneto-optical media and plastic substrate interface,” IEEE Transl. J. Magn. Jpn., vol. 2, pp. 740-741, August 1987 [Dig. 9th Annual Conf. Magn. Jpn., p. 301, 1982].

Thiết kế hệ thống giám sát BK-supervisorLAN

Hệ thống BK-supervisorLAN được xây dựng dựa trên yêu cầu thực tế của Trung tâm Máy tính – trường Đại học Bách Khoa Hà Nội, có kế thừa và phát triển hệ thống BkvideoLAN. Hệ thống gồm hai khối chức năng chính: giám sát quang cảnh bằng camera trên mạng IP và hỗ trợ giám sát quản lý phòng thực hành máy tính.

Hệ thống triển khai trong môi trường mạng máy tính cục bộ, bao gồm các thành phần sau: server, trung tâm giám sát, các máy client và các webcam,IP camera. Webcam được gắn với máy client và kết nối mạng với server, trung tâm giám sát và IP camera.

  • Server đóng vai trò Web server cung cấp trang web động (jsp) cho trung tâm giám sát, mail server cho phép học viên tương tác với giáo viên qua email, SQL server cơ sở dữ liệu và server lưu trữ lưu ảnh, video được chụp lại trong quá trình hoạt động.
  • Máy client có gắn webcam bắt hình ảnh từ webcam và truyền dòng liên tục về trung tâm giám sát, chụp và ghi lại hình ảnh tự động hoặc khi có yêu cầu và truyền về server lưu trữ. Máy client bắt tiến trình, kết thúc tiến trình và chụp màn hình cục bộ khi có yêu cầu từ trung tâm giám sát. Cung cấp giao diện cho phép học viên tương tác với giáo viên theo hai hình thức: gửi mail hoặc chat.
  • Trung tâm giám sát có là máy dành giáo viên thực hiện chức năng giám sát. Trong môi trường mạng, vai trò Trung tâm giám sát có thể là bất cứ máy nào có kết nối mạng. Các tác vụ tại trung tâm giám sát là:
    • Quan sát quang cảnh phòng học trực tuyến thời gian thực qua 4 dòng video truyền đồng thời từ Ip camera hoặc webcam.Có thể lựa chọn nhiều cách bố trí hiển thị các dòng video này.
    • Cấu hình webcam.Yêu cầu chụp, ghi tự động hoặc tức thời.
    • Theo dõi màn hình của máy client. Bắt các tiến trình tại máy client và kết thúc các tiến trình không được phép.
    • Tương tác với học viên theo 2 hình thức: email và chat.
    • Quản trị thành viên có phân quyền, quản trị thiết bị, quản trị lớp học, quản trị ảnh và video được lưu trữ.

TÀI LIỆU THAM KHẢO

[1].Nguyễn Thị Hoàng Lan, “Truyền thông đa phương tiện, Đại học Bách Khoa Hà Nội.

[2].Sun Microsystems,Inc “JMF API Documentation” , Sun Microsystems.

[3].S.J.Gibbs & D.C.Tsichritzis, Multimedia programming,Addison – Wesley.

[4].L.L.Ball, Multimedia Network Intergration and Management”, McGraw-Hill.

Làm việc với JMF

Time-Based Media:

Mọi dữ liệu có ý nghĩa thay đổi theo thời gian đều có thể được mô tả như là media data theo thời gian: Các đoạn âm thanh, hình ảnh, trình tự MIDI, hình ảnh động và các phương thức truyền thông đa phương tiện phổ biến hiện nay. Các loại dữ liệu truyền thong đa phương tiện nhu vậy có thể có được từ nhiều nguồn khác nhau, chẳng hạn như: có thể có sẵn trong máy của bạn, hay trên Internet, thu được từ camera, microphone, từ các chương trình phát song trên TV hay radio.

ở phần này, mô tả các đặc điểm chính của media data dựa trên thời gian và việc mô tả này có thể được khái quát qua sơ đồ sau:

·         Thu từ thiết bị ngoại vi.

·         Đọc từ file.

·         Nhận từ mạng(net).

 

 

·         Tạo bộ lọc.

·         Nén và giải nén.

·         Chuyển đổi định dạng.

 

 

·         Mô tả.

·         Lưu trữ.

·         Gửi vào mạng.

 

 

Mô hình xử lý truyền thông.

Streaming Media(media data theo luồng):

Một đặc tính quan trọng của truyền thông đa phương tiện dựa trên thời gian đó là đòi hỏi phải được cung cấp và xử lý. Khi một luồng media data bắt đầu, nó đòi hỏi một sự quản lý nghiêm ngặt về thời gian, và điều này phải được đáp ứng. Vì lý do này, media data dựa trên thời gian thường được gọi media data theo luồng(streaming media), điều này có nghĩa là nó được chuyển giao trên một luồng cụ thể và phải được tiếp nhận, xử lý trong một khung thời gian cụ thể và kết quả có thể chấp nhận được.

Ví dụ: khi một bộ phim được phát, nếu media data không được gửi một các nhanh chóng và đầy đủ thì sẻ xảy ra hiện tượng đứng và giật hình, thậm chí có thể bị phát lại. Mặt khác, nếu dữ liệu không được nhận và xử lý đủ nhanh, bộ phim có thể xuất hiện những đoạn hay khung hình bị bỏ mất, trong khi tốc độ trình chiếu vẫn bình thường.

Content type(kiểu nội dung):

Các media data được lưu thành các loại định dạng khác nhau, gọi là kiểu nội dung. Ví dụ: QuickTime, MPEG, WAV…. Về cơ bản, kiểu nội dung là kiểu của tập tin. Kiểu nội dung được định nghĩa bởi vì, các media data thường được thu thập từ nhiều nguồn khác nhau, hơn là thu được từ các tập tin địa phương(trên máy của bạn).

Media Streams(luồng media data):

Một luồng media data là các media data thu được từ các tập tin địa phương, qua mạng, hay có được từ các thiết bị ngoại vi như microphone, máy ảnh… Luồng media data thường các chứa nhiều kênh khác nhau của dữ liệu mà người ta gọi là các track. Ví du: một tập tin QuickTime có thể chứa cùng lúc cả kênh hình ảnh(video track) và kênh âm thanh(audio track).

Ghép kênh(multiplexing) là ghép nhiều kênh khác nhau(các kênh này có thể ở nhiều luồng khác nhau), thành một luồng duy nhất có chứa các kênh đó.

Phân rã kênh(demultiplexing) là quá trình phân rã một luồng có chứa kênh khác nhau thành các kênh riêng rẻ.

Một loại kênh có thể được nhận diện bằng loại dữ liệu mà nó chứa. Định dạng của một kênh định nghĩa cấu trúc mà kênh đó có.

Một luồng media data có thể được xác định vị trí và giao thức sử dụng để truy cập nó. Ví dụ: một URL, có thể được sử dụng để mô tả vị trí của một tập tin QuickTime trên một hệ thống địa phương hay một hệ thống từ xa. Nếu là tập tin địa phương, nó có thể được truy cập qua giao thức FILE(FILE protocol). Mặt khác, nếu là tập tin trên một máy chủ Web, tập tin có thể được truy cập qua giao thức HTTP. Một định vị địa phương cho media data(media locator) có thể cung cấp một cách khác để xác định vị trí của một luồng media data, khi URL không được sử dụng.

Các luồng media data có thể được phân loại dựa trên phương thức phân phối như sau:

Pull(kéo)- việc truyền dữ liệu được kiểm soát từ phía Client. Ví dụ: Hypertext Transfer Protocol(HTTP) và FILE là các giao thức pull.

Push(đẩy)- máy chủ bắt đầu việc truyề dữ liệu và kiểm soát các luồng dữ liệu. Ví dụ: giao thức truyền tải thời gian thực(RTP) là một giao thức dạng push, được sử dụng cho các luồng media data. Tương tự như vậy, giao thức SGI MediaBase cũng là giao thức dạng push, được sử dụng để truyền tải video theo yêu cầu.

Các định dạng media data phổ biến:

Các bảng sau đây cung cấp một số định dạng cho media data phổ biến hiện nay. Khi lựa chọn một định dạng, điều quan trọng là phải dựa vào các đặc điểm của nhận dạng của định dạng, môi trường mục tiêu và kết quả mong đợi thu được trên từng đối tượng cụ thể. Ví dụ: nếu bạn cần cung cấp các media data cho một trang Web, bạn cần cân nhắc đến các đặc điểm về băng thông.

Cột CPU là yêu cầu đặc trưng cho sức mạnh xử lý cần thiết để kết xuất một các tốt ưu nhất cho một định dạng. Cột băng thông là yêu cầu đặc trưng cho tốc độ đường truyền dẫn cần thiết để gửi hoặc nhận một cách nhanh chóng để kết xuất tối ưu.

Định dạng Kiểu nội dung Chất lượng CPU yêu cầu Băng thông yêu cầu
Cinepak AVI

QuickTime

Trung bình Thấp Cao
MPEG-1 MPEG Cao Cao Cao
H.261 AVI

RTP

Thấp Trung bình Trung bình
H.263 QuickTime

AVI

RTP

Trung bình Trung bình Thấp
JPEG QuickTime

AVI

RTP

Cao Cao Cao
Indeo QuickTime Trung bình Trung bình Trung bình

Một số định dạng video phổ biến.

Định dạng Kiểu nội dung Chất lượng CPU yêu cầu Băng thông yêu cầu
PCM AVI

QuickTime

WAV

Cao Thấp Cao
Mu-Law AVI

QuickTime

WAV

RTP

Thấp Thấp Cao
ADPCM(DVI,IMA4) AVI

QuickTime

WAV

RTP

Trung bình Trung bình Trung bình
MPEG-1 MPEG Cao Cao Cao
MPEGLayer3 MPEG Cao Cao Trung bình
GSM WAV

RTP

Thấp Thấp Thấp
G.732.1 WAV

RTP

Trung bình Trung bình Thấp

Một số định dạng âm thanh phổ biến.

Trình diễn media data (Media presentation):

Hầu hết media data là dữ liệu âm thanh hay hình ảnh, chúng có thể được trình diễn thông qua các thiết đầu ra như loa và màn hình. Những thiết bị như vậy là điểm đến của hầu hết các media data. Các luồng dữ liệu có thể được gửi tới được bất cứ đâu, ví dụ: được lưu thành các tập tin hay được truyền đi trên mạng. Một đầu ra cho media data đôi khi còn được gọi là “bể dữ liệu”(data sink).

Kiểm soát trình diễn(Presentation Controls)

Trong khi một luồng media data đang được trình diễn, VCR- một cách kiểm soát kiểm soát trình diễn có thể được cung cấp cho người dung để có thể kiểm soát các thao tác này. Ví dụ: một bảng điều khiển có thể được cung cấp trong các chương trình chơi nhạc hay xem phim, chúng cho phép người dùng dừng, bắt đầu hay phát lại, chuyển tiếp hay tua các đoạn media data đa được trình diễn.

Độ trễ(Latency)

Trong nhiều trường hợp, đặc biệt là khi luồng media data đang cư trú trên mạng, việc trình diễn các luồng dữ liệu này không thể được bắt đầu ngay lập tức. Thời gian trước khi dữ liệu được trình diễn gọi là độ trễ bắt đầu(the start latency). Người dùng có thể cảm nhận được điều này, đó là sự chậm trễ từ khi họ ra lệnh bắt đầu cho tới khi dữ liệu thực sự được trình diễn.

Trình diễn media data thường kết hợp media data vào một số phép đồng bộ. Ví dụ: nhạc nền có thể được phát trong khi chạy một ứng dụng trình chiếu ảnh, một đoạn âm thanh có thể được lồng ghép trong một đoạn video. Khi trình diễn một luồng media data đã được đồng bộ, điều quan trọng là quản lý được độ trễ bắt đầu của các luồng con bên trong, nếu không sự bắt đầu của các dòng các nhau sẽ được bắt đầu tại các thời điểm khac nhau.

Chất lượng trình diễn(Presentation quality)

Chất lượng trình diễn một luồng media data phụ thuộc vào nhiều yếu tố, bao gồm

Mô hình nén được sử dụng.

Khả năng xử lý của hệ thống phát.

Băng thông sẵn có(cho các luồng media data qua mạng).

Thông thường, tập tin có chất lượng cao hơn và kích thước lớn hơn thường có quyền lớn hơn trong việc yêu cầu và chiếm giữ băng thông phục vụ cho việc xử lý. Băng thông thường được biểu diễn như là số bit truyền được trong một khoảng thời gian nhất định, còn được gọi là bit rate.

Để đạt được sự trình diễn video chất lượng cao, đòi hỏi số khung hình trong từng đơn vị thời gian(frame rate) càng cao càng tốt. Thông thường, một bộ phim đạt được 30khung hình trên mỗi giây được coi là khó phân biệt(giữa các khung hình): chương trình TV hay băng hình.

Xử lý media data:

Trong hầu hết các trường hợp, dữ liệu của một luồng media data sẽ được xử lý trước khi chúng được trình diễn cho người dùng. Một số hoạt động xử lý có thể liệt kê như sau:

Nếu là luồng ghép, các kênh đơn sẽ được tách ra.

Nếu là một kênh đơn được nén, nó sẽ được giải mã.

Nếu cần thiết, các kênh có thể được chuyển đổi thành những định dạng khác nhau.

Bộ lọc hiệu ứng có thể được áp dụng để giải mã các kênh(nếu cần).

Sau đó, các kênh này sẽ được chuyển giao cho các thiết bị đầu ra thích hợp. Nếu các luồng media data phải được lưu trữ thay vì được đưa đến các thiết bị đầu ra, các giai đoạn này có thể bị thay đổi một chút. Ví dụ: nếu bạn muốn thu lấy hình ảnh và âm thanh từ máy quay, xử lý chúng và lưu trữ vào một tập tin, thì các giai đoạn có thể như sau:

Các kênh hình ảnh và kênh âm thanh sẽ được thu lấy.

Bộ lọc hiệu ứng có thể được áp dụng nếu bạn muốn thu được các kênh nguyên chất.

Các kênh riêng biệt sẽ được mã hóa.

Các kênh sẽ được ghép và nén vào một luồng media data duy nhất.

Luồng media data sẽ được lưu thành một tập tin

Tách kênh(demultipexers) và ghép kênh(multiplexers):

Tách kênh là chiết xuất để thu được các kênh riêng biệt từ một luồng media data ghép. Ghép kênh là thực hiện chức năng ngược lại, lấy các kênh riêng biệt và thực hiện ghép chúng vào một luồng media data duy nhất, luồng này gọi là luồng media data ghép.

Các bộ codec:

Một codec thực hiện nén và giải nén media data. Khi một kênh được mã hóa, nó được chuyển đổi sang một định dạng thích hợp cho việc lưu trữ hay truyền tải, khi nó được giả mã, nó được chuyển đổi thành một định dạng(thô) không nén phù hợp.

Mỗi codec đều có định dạng đầu vào, và chắc chắn rằng nó có thể xử lý được và đảm bảo rằng định dạng đầu ra là khả thi. Trong một số trường hợp, một loạt các codec có thể được sử dụng việc chuyển đổi định dạng.

Bộ lọc hiệu ứng:

Một bộ tạo hiệu ứng có thể thay đổi kênh dữ liệu theo một kiểu nào đó, chúng thường xuyên được sử dụng để tạo ra các hiệu ứng đặc biệt.

Bộ lọc hiệu ứng có thể được phân loại được dựa trên loại hình chúng được áp dụng: tiền xử lý hay kết quả kết xuất có được. Thông thường, bộ lọc tín hiệu được áp dụng cho các dữ liệu đang còn ở dạng thô.

Bộ kết xuất(renderers):

Một kết xuất là một khái niệm trừu tượng đại diện chi một thiết bị trình diễn. Đối với âm thanh, thông thường, thiết bị âm thanh là card âm thanh của máy tính mà kết quả sẽ được xuất ở đầu ra là loa. Đối với video, thiết bị trình diễn là màn hình máy tính.

Ghép(composting):

Hiện nay, có một số thiết bị chuyên dụng hỗ trỡ việc ghép. Việc ghép trên một media data là quá trình kết hợp nhiều kênh của dữ liệu vào một phương tiện trình diễn duy nhất. Ví dụ: phủ một bản lên một đoan video là một hình thức phổ biến. Ghép  có thể thực hiện trên phần cứng hay phần mềm. Một thiết bị thực hiện ghéo có thể được như bộ kết xuất nhiều kênh đầu vào.

Thu (Media capture):

Media data theo thời gian có thể được “chụp” lại từ một nguồn thực, sau đó được xử lý và trình diễn lại. Ví dụ: âm thanh có thể được thu từ một microphone hoặc một đoạn video có thể thu được từ một máy ảnh. Chúng có thể được coi là đầu vào của một mô hình xử lý xử lý truyền thông tiêu chuẩn.

Một thiết bị thu có thể cung cấp nhiều luồng media data. Ví dụ: một máy quay video có thể cung cấp cả hình ảnh và âm thanh. Những luồng này có thể được thu lấy một cách riêng biệt hoặc kết hợp thành một luồng duy nhất có chứa cả kênh âm thanh và kênh hình ảnh.

Thiết bị thu(Capture devices):

Để “bắt” được các media data theo thời gian, chúng ta cần có phần cứng chuyên dụng, ví dụ: để thu được âm thanh bạn cần một microphone và một card âm thanh. Tương tự như vậy, để thu một chương trình truyền hình bạn cần một TV và một card đồ họa. Hầu hết các hệ thống cung cấp một cơ chế truy vấn để tìm ra được những thiết bị có sẵn trong máy tính của bạn.

Các thiết bị thu có thể được mô tả như một trong hai loại nguồn pull hay nguồn plus. Ví dụ: máy ảnh là một nguồn pull, nguồn sử dụng có thể kiểm soát khi chụp hình ảnh. Trong khi đó, microphone là nguồn plus, chúng lien tục cung cấp dữ liệu âm thanh từ các môi trường xung quanh mà người dùng không thể kiểm soát việc thu này.

Các định dạng của một luồng media data thu được từ một thiết bị bị thuộc vào khả năng xử lý của thiết bị đó. Một số thiết bị xử lý được rất ít các định dạng. Bên cạnh đó, cũng có thiết bị xử lý được rất nhiểu định dạng khác nhau.

Kiểm soát thu(capture controls):

Đôi khi, bộ kiểm soát có thể cung cấp cho người dùng nhiều chức năng quản lý quá trình thu. Ví dụ: một bảng điều khiển có thể cho phép người dùng xác định tốc  độ thu, loại mã hóa cho dữ liệu, cũng như các chức năng cho phép bắt đầu và ngừng việc thu dữ liệu.

JMF

Java Media Framework(JMF) cung cấp một kiến trúc thống nhất và giao thức truyền tin để quản lý việc thu nhận, cung cấp và xử lý media data theo thời gian. JMF được thiết kế để hỗ trợ nhiều tiêu chuẩn định dạng như: AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime,RMF, và WAV.

Bằng cách khai thác các lợi thế của nền tảng Java, JMF mang đến một khẩu hiệu “Write once, run anywhere” – (viết chỉ một lần, và chạy được bất cứ đâu) để phát triển những ứng dụng truyền thông đa phương tiện như âm thanh và video. JMF cung cấp các hàm Java API cơ bản, từ đó, cho phép người lập trình can thiệp sâu hơn vào các media framework. JMF có khả năng thúc đẩy việc triển khai cho những hệ thống căn bản nhất, bên cạnh đó, người lập trình có thể dễ dàng tạo ra những chương trình ứng dụng có tính năng động cao với JMF API.

Với JMF, bạn có thể dễ dàng tạo ra các chương trình ứng dụng hay các applet như trình diễn, thu thập và lưu trữ media data. Framework này cho phép các nhà phát triển và các nhà cung cấp ứng dụng thực hiện các chương trình truyền thông đa phương tiện với dữ liệu thô và có thể mở rộng hay bổ sung thêm có định dạng mới, kiểu nội dụng mới, và tạo ra có cơ chế trình diễn mới.

Kiến trúc

Các thiết bị như băng từ và VCR cung cấp một mô hình quen thuộc để thu thập , lưu trữ, xử lý và trình diễn media data dựa trên thời gian. Khi bạn xem phim bằng VCR, khi bạn cho vào một cuộn băng từ, đồng nghĩa với việc bạn bạn đã cung cấp một nguồn madia data. VCR đọc và giải mã dữ liệu, gửi các tín hiệu thích hợp tới màn hình và loa.

Mô hình xử lý bằng VCR.

JMF sử dụng cùng một mô hình tương tự như trên. Một nguồn dữ liệu(data source) được đóng gói đóng vai trò như một cuộn băng từ và một bộ phát(player) để xử lý và kiểm soát tương tự như một VCR. Để JMF có thể thực hiện tốt vai trò này, nó yêu cầu dữ liệu đầu vào và đầu ra thích hợp.

Nguồn dữ liệu và bộ phát là hai bộ phận không thể thiếu trong mô hình của kiến trúc của JMF API, điều này chắc rằng việc thu nạp, trình diễn, và xử lý media sẽ được sẽ lý. Bên cạnh đó, JMF cũng hỗ trợ những hàm API cấp thấp hơn, thích hợp cho việc tùy chỉnh các chức năng xử lý và mở rộng chúng. Chúng cung cấp cho nhà phát triển trên nền tảng Java những hàm API đơn giản và dễ sử dụng  để có thể tích hợp các chức năng xử lý media data vào ứng dụng mà minh xây dựng, duy trì cho các ứng dụng sự năng động và khả năng tương thích tốt, cho chúng khả năng có thể được mở rộng khi cần thiết, là nền tảng để xây dựng các ứng dụng truyền thông đa phương tiện tiên tiến, sở hữu những công nghệ tương lai.

Mộ hình kến trúc của JMF

Mộ hình thời gian(Time model):

Các ứng dụng viết bằng JMF có độ chính xác tính bằng đến từng nano giây. Các đặc điểm về thời gian sẽ được mô tả trong JMF, đại diện cho điều này là đối tượng Time, đã được xây dựng sẵn trong JMF. Đặc điểm kỹ thuật vượt trội của class này là có khả năng hỗ trợ độ chính xác đển nano giây.

Một class khác trong JMF đóng vai trò đồng bộ, đó là Clock. Clock thực hiện nhiệm vụ như một cái đồng hồ, dùng để theo dõi thời gian cho một luồng media data thực. Clock cung cấp một giao diện linh hoạt và cơ bản để thực hiện việc đồng bộ và kiểm soát quá trình của một luồng media data.

Mô hình thời gian trong JMF

Một Clock “sở hữu” một TimeBase để theo thời gian  của một luồng media data đang được xử lý. Một Time-Base cung cấp các mốc thời gian liên tục đến từng tic-tắc. Một điều quan trọng là, TimeBase chỉ cung cấp thời gian hiện tại mà nó đang nắm giữa, gọi là thời gian cơ sở(time-base). Thời gian cơ sở này không thể bị dừng lại cũng như cũng không được phép thiết lập từ người dùng. Thời gian cơ sở là thời gian được dựa trên thời gian hiện tại của đồng hồ hệ thống.

Đối tượng Clock trong JMF đại diện cho vị trí hiện tại bên trong một luồng media data- bắt đầu của một luồng media data là mốc 0, và mốc kết thúc là thời gian tối đa để xử lý luồng đó. Duration (khoảng thời gian) của một luồng media data được tính từ lúc bắt đầu cho tới khi kết thúc-là thời gian cần thiết để trình diễn xong luồng media data đó(các đối tượng có thể cung cấp thông tin Duration khi chúng có thể nhận biết được Duration của mình).

Để theo dõi một kênh media data , một Clock sử dụng:

Time-Base Start-Time: mốc thời gian mà Time-Base nhận được yêu cầu trình diễn.

Media Start-Time: mốc thời gian mà luồng media data thực sự được trình diễn.

Playback rate: tốc độ trình diễn, nó cho thấy Clock chạy nhanh ra sao, được thể hiện trong mối tương quan quan vói Time-Base. Ví dụ: ta có tốc độ phát rate=1.0, cho thấy tốc độ trình diễn bình thường, với rate=2.0, chỉ ra rằng luồng media data đang được trình diễn với tốc độ gấp đôi tốc độ bình thường. Một rate<0 cho thấy rằng Clock đang chạy ngược lại với Time-Base của chính nó. Điển hình cho điều này là khi ta phát ngược lại một luồng media data.

Khi bắt đầu một luồng media data được bắt đầu trình diễn, Media-Time  sẽ được ánh xạ thành một Time-Base, và sự thay đổi(tiếp tục) của Time-Base này sẽ được dùng để tính toán thời gian đã thực hiện trình diễn. Trong suốt quá trình trình diễn của luồng media data, Media-Time hiện tại sẽ được tính theo công thức:

MediaTime=MediaStartTime+rate*(TimeBaseTime-TimeBaseStartTime)

Khi quá trình dừng, Media-Time dừng, nhưng Time-Base vẫn tiếp tục được tính. Nếu quá trình trình diễn được khởi động lại, Media-Time sẽ được tính lại như khi một luồng media data được trình diễn.

Quản lý(Manager)

JMF API chủ yếu chứa các hàm định nghĩa hành vi và sự tương tác của các đối tượng thu nhận, xử lý, và xử lý theo Time-Base. Các hàm này đã được cung cấp sẵn trong framework này. Bằng cách sử dụng một class trung gian được gọi là managers, JMF làm cho việc triển khai các nó trở nên dễ dàng hơn.

JMF cung cấp bốn loại managers:

Manager: quản lý các hàm khởi tạo cho cái đối tượng Player(bộ trình diễn), Processcer(bộ xử lý), DataSource(nguồn dữ liệu), DataSick(“bể” chứa dữ liệu). Đây là cấp độ trung gian để có thể giao tiếp với JMF. Nhìn chung, các đối tượng này có cùng một cách khởi tạo dù cho mỗi loại có thể yêu cầu một vài tùy chỉnh riêng biệt.

PackageManager: đóng vai trò như một “sổ đăng ký” cho cái đối tượng Player, Processer, DataSource, DataSick.

CaptureDiviceManager: thực hiện đăng ký cho các thiết bị thu có sẵn.

PlugInManager: thực hiện việc đang ký cho các thành phần như: Multiplexer, Demultiplexer, Codec, Effect, Renderer.

Để xây dựng một ứng dụng dựa trên JMF, điều trước tiên là bạn phải tạo ra một Manager để quản lý các phương thức khởi tạo cho Player, Processcer, DataSource, và DataSink.  Nếu muốn có được dữ liệu từ các thiết bị thu ngoại vi, bạn có thể sử dụng phương thức CaptureDeviceManager để tìm ra xem những thiết bị ban cần đang có thật sự kết nối và phương thức này cũng giúp cho phép truy cập vào những thiết bị này. Nếu bạn quan tấm đến việc sử lý dữ liệu từ các plug-in, JMF cung cấp cho ban phương thức PlugInManager để kiểm soát được dữ liệu từ các plug-in này.

Nếu bạn muốn tạo riêng cho mình một plug-in mới, bạn có thể kết thừa các chức năng được xây dựng sẵn của JMF thông qua PlugInManager để có được một Processer hỗ trợ các hàm API đã được xây dựng sẵn. Để có thể tùy chỉnh các chức năng của Player, Processer, DataSource, DataSink với JMF, bạn có thể kết thừa lớp PackageManager.

Mô hình sự kiện (Event Model):

JMF sử dụng một cơ chế quản lý sự kiện(Event) có cấu trúc, điều này giúp cho các ưng dụng được xây dựng bằng JMF có thể quản lý được hiện trạng của hệ thống truyền thông cũng như quản lý được các lỗi điều khiển như: lỗi dữ liệu, lỗi thiết bị đầu vào… Bất cứ khi nào, một đối tượng được xây dựng trên JMF muốn thông báo một sự kiện, nó sẽ gửi đi một MediaEvent. Để nhận được MediaEvent này, bạn cần đăng ký một “người tiếp nhận” thích hợp với đối tượng mà bạn muốn thu được MediaEvent của nó, bằng cách gọi phương thức Listener.

Các đối tượng điều kiển(chẳng hạn như Player hay Processcer) và một số đối tượng chứa các đối tượng điều khiển như GainControl là các đối tượng có thể gửi MediaEvent.

Mô hình quản lý sự kiện trong JMF.

RTPSessionManager cũng là đối tượng cung cấp các MediaEvent, sẽ tìm hiểu kỹ thêm ở những phần sau.

Mô hình dữ liệu (Data Model):

Các bộ trình diễn được xây dựng bằng JMF sử dụng sử dụng các DataSource để quản lý việc chuyển giao dữ liệu của các luồng media data. Một DataSource xác định cả vị trí nguồn, phương thức và phần mềm dùng để truyền luồng media data. Sau khi được sử dụng, một DataSource không thể được tái sử dụng để cung cấp cho một nguồn dữ liệu đa phương tiện khác.

Trong JMF, một DataSource được xác định bởi một MediaLocator hoặc bởi một URL(universal resource locator) được dùng để tham chiếu đến tài nguyên trên Internet. Một MediaLocator tương tự như một URL, và có thể được định nghĩa thông qua một URL, nhưng nó có thể được định nghĩa ngay cả khi các giao thức xử lý tương ứng không được cài đặt trên hệ thống(trong Java, một URL có thể được xử lý nếu giao thức xử lý tương ứng đã được cài đặt trên hệ thống).

Một DataSource quản lý một tập các đối tượng SourceStream. Một DataSource tiêu chuẩn được xây dựng như một mảng các byte(đơn vị truyền dữ liệu). Để truyể dữ liệu từ DataSource, bạn sử dụng mốt đối tượng khác là Buffer, Buffer thực hiện dữ liệu theo từng byte. Một số DataSource thông dụng trong JMF là:

Mô hình dữ liệu trong JMF.

Các nguồn dữ liệu Pull(Pull Data-Source) và nguồn dữ liệu Push(Push Data-Source):

Pull Data-Source: việc khởi tạo truyền dữ liệu và kiểm soát luồng media data được thực hiện từ phía client. Các giao thức truyền dữ liệu thuộc dạng này như: Hypertext Transfer Protocol(HTTP) và FILE. JMF định nghĩa hai loại nguồn dữ liệu Pull: PullDataSourcePullBufferData, trong đó PullBufferData sử dụng bộ đệm để thực hiện việc truyền dữ liệu.

Push Data-Source: việc khởi tạo truyền dữ liệu và kiểm soát luồng media data được hiện từ phía server. Các nguồn dữ liệu Push có thể được biết đến như: dữ liệu quảng bá qua vô tuyến, các dạng dữ liệu quảng bá trong các mạng, dịch vụ video theo yêu cầu(VOD –video on demand). Đối với các dữ liệu được phát qua vô tuyến, được áp dụng một giao thức truyền tải thời gian thực là RTP(Real-time Transport Protocol), được phát triển bởi IETF(Internet Engineering Task Force). Đối với các dịch vụ VOD, chúng được áp dụng một giao thức khác là MediaBase, được phát triển bởi SGI. JMF định nghĩa hai dạng nguồn dữ liệu Push: PushDataSourcePushBufferDataSource, trong đó PushBufferDataSource sử dụng một bộ đệm để thực hiện truyền dữ liệu.

Mức độ kiểm soát được hiểu là các chức năng kiểm soát mà các trình khách có thể cung cấp cho người dùng, việc này thùy thuộc vào từng loại nguồn dữ liệu được trình diễn. Ví dụ: một tập tin MPEG có thể được thay đổi vị trí lưu trữ, một trình khách có thể cho phép người dùng kiểm soát việc trình diễn một đoạn video. Ngược lại, các dữ liệu quảng bá được kiểm soát máy chủ và các trình khách không thể tác động vào các tập tin này. Một vài giao thức VOD có thể hỗ trợ người dùng một cách hạn chế: một trình khác có thể cho phép người dùng chọn vị trí trình diễn mới tùy thích , như lại xử lý không nhanh khi người dùng thực hiện tao tác tua(về trước hay về sau).

Các nguồn dữ liệu đặc biệt

JMF định nghĩa hai nguồn dữ liệu đặc biệt: nguồn dữ liệu khả nhân bản(cloneable data) và nguồn dữ liệu hợp nhất(merging data).

Nguồn dữ liệu nhân bản được sử dụng khi bạn muốn tạo một bản sao cho một nguồn dữ liệu Pull hay Push. Để tạo một bản sao: bạn cần gọi phương thức createCloneableDataSource từ một đối tượng dạng Manager, sau đó tham chiếu tới một DataSource mà bạn muốn nhân bản. Khi một nguồn dữ liệu được nhân bản bằng phương thức createCloneableDataSource, bạn chỉ nên tao thác với nguồn dữ liệu nhân bản và không nên thao tác trực tiếp lên nguồn dữ liệu chính.

Nguồn dữ liệu khả nhân bản là thể hiện(implements) của lớp đại diện SourceCloneable, trong đó, định nghĩa một phương thức duy nhất là createClone. Số lượng bản sao mà bạn có thể tạo được là tùy ý, tuy nhiên nguồn dữ liệu mà bạn muốn tạo bản sao phải là nguồn có khả năng nhân bản(cloneable datasource). Các bản sao cũng có các phương thức hoạt động tương tự như bản gốc: các phương thức kiểm soát connect(kết nối), disconnect(ngắt kết nối), start(bắt dầu), stop(dừng), và các phương thức truyền, phù hợp với từng loại dữ liệu.

Các bản sao không nhất thiết phải có các thuộc tính giống với bản gốc dùng để tạo ra chúng hay các bản sao khác. Ví dụ: một nguồn dữ liệu khả nhân bản được tạo ra cho một thiết bị thu(máy quay, máy ảnh…) có thể được xem như một nguồn “cha” cho tất cả các bản sao của nó, trong trường hợp này, các bản sao sẽ không được tạo ra, trừ khi bản gốc được sử dụng. Nếu bạn sử dụng một hay nhiều bản gốc và một hay nhiều bản sao tại cùng một thời điểm, thì các bản sao khác sẽ được tạo ra với số bản gốc được sử dụng.

Với nguồn dữ liệu kết hợp, bạn có thể kết hợp các SourceStream từ nhiều nguồn dữ liệu thành một nguồn dữ liệu duy nhất. Điều này cho phép một tập hợp các nguồn dữ liệu được kiểm soát từ một điểm duy nhất. Một khi các phương thức kiểm soát như connect, disconnect, start, stop  được gọi trong nguồn dữ liệu kết hợp, chúng sẽ được gửi đến từ nguồn dữ liệu thành phần.

Để xây dựng một nguồn dữ liệu kết hợp, bạn cần gọi tới phương thưc createMergingDataSource trong một đối tượng Manager, phương thức này sẽ tham chiếu tới một mảng bao gồm các DataSource. Để việc xác nhập được thực hiện, các nguồn dữ liệu phải có cùng kiểu nội dung, ví dụ: một nguồn dữ liệu dạng PullDataSource không thể kết hợp với một nguồn dữ liệu dạng PushDataSource. Độ lớn của nguồn dữ liệu kết hợp là tổng độ lớn tối đa của các nguồn dữ liệu thành phần.

Dịnh dạng dữ liệu

Định dạng của một dữ liệu đa phương tiện được định nghĩa thông qua một đối tượng định dạng là Format. Một định dạng mang trong mình các tham số mã hóa đặc trưng hay các thông tin định thời, tên của định dạng, và loại dữ liệu phù hợp.

JMF cung cấp các loại định dạng cụ thể như sau:

Các định dạng dữ liệu đa phương tiện trong JMF.

AudioFormat la định dạng âm thanh, nó bao gồm các mô tả như: tốc độ phát, số kênh và số bit/mẫu. VideoFormat là một gói định dạng cho video bao gồm:

IndexdColorFormat.

RGBFormat.

YUVFormat.

JPEGFormat.

H261Format.

H263Format.

Để nhận được cảnh báo khi định dạng bị thay đổi, bạn sử dụng một ControllerListener và “lắng nghe” sự kiện FormatChangeEvents(để biết thêm thông tin, bạn có thể tham khảo tại phần Phản ứng với các sự kiện truyền thông).

Điều kiển(Control):

JMF cung cấp một cơ chế điều kiển thông quan việc thiết lập và truy vấn các thuộc tính của đối tượng. Một đối tượng điều kiển thường cung cấp cho người dùng khả năng truy cập vào phần thông tin giao tiếp người dùng , từ đó cho phép người dùng kiểm soát đối tượng thông qua các thuộc tính của nó. JMF cung cấp nhiều loại đối tượng điều kiển như: Controller, các DataSource, các DataSink, và các plug-in.

Bất kỳ một lớp nào muốn cung cấp khả điều kiển đều phải là một thể hiện(implements) của lớp Controls và các lớp điều kiển khác tương ứng mà bạn muốn sử dụng. Các lớp điều kiển này cung cấp nhiều phương thức để bạn có thể truy cập và kiểm soát các đối tượng chứa chúng. Các DataSourcePlugIn sử dụng các lớp thể hiện điều kiển để hiện thực khả năng truy cập vào các thành phần điều kiển của chúng.

CachingControl cho phép theo dõi và hiển thị các trình tải về. Nếu có một nhu cầu tải về từ Player hay Processer, nó sẽ hiện thực quá trình tải này qua một thanh tiến trình(process bar) cho phép người dùng theo dõi một cách trực quan toàn bộ tiến trình tải.

GainControl cho phép điều chỉnh mức độ của các kênh âm thanh như thiết lập cũng như tắt âm lượng đầu ra của các đối tượng như Player hay Processer, nó cũng hỗ trợ cơ chế nhận biết những thay đổi về âm lượng.

GianControl

 

Control

Các đối tượng DataSink hoặc Multiplexer đọc luồng media data từ một DataSource và ghi nó đến đích cuối cùng bằng một lớp thể hiện của StreamWriterControl. Lớp điều kiển này cho phép người dùng giới hạn kích thuốc đầu ra của luồng media data.

FramePositioningControlFrameGrabbingControl: thực hiện việc chiết xuất khung hình(frame) tùy thuộc vào khả năng của PlayerProcesser. FramePositioningControl cho phép xác định chính xác một frame trong một luồng media data đang “chảy ” qua một Player hay một Processer. FrameGrabbingControl cung cấp khả năng lấy ra một frame từ một luồng media data hiện hành. FrameGrabbingControl cũng hỗ trợ các kết xuất(Renderer) ở các mức độ khác nhau.

Các đối tượng có chứa thuộc tính dạng Format có hiện thực lớp FormatControl để cho phép truy cập đến thuộc tính này. FormatControl cũng cung cấp các chắc năng truy vấn và thiết lập cho các Format.

TrackControl cũng là một dạng của FormatControl, tuy nhiên nó cung cấp các chức năng kiểm soát hiệu suất của một Processer đang thực hiện xử lý một luồng media data. Với TrackControl, bạn cũng có thể thực hiện chuyển đổi các định dạng được thực hiện trên từng kênh đơn và tùy chọn Effect(hiệu ứng), Codec, hoặc Renderer được xử dụng trong Processer. (có thể tham khảm thêm tại phần Tùy biến xử lý với JMF).

Hai đối tượng điều kiển khác là PortControlMonitorControl cung cấp cho người dùng khả năng kiểm soát quá trình thu dữ liệu. PortControl xác định phương thức đầu ra của các thiết bị thu. MonitorControl cung cấp khả năng duyệt trước nguồn dữ liệu từ các thiết bị thu hay khi chúng được mã hóa.

BufferControl cho phép người dùng kiểm soát các vùng đệm khi thực thi một đối tượng cụ thể.

JMF cũng cung cấp một vài đối tượng điều kiển để kiểm soát quá trình mã hóa và giải mã bằng phần cứng hay phần mềm:

BitRateControl: cung cấp khả năng kiểm soát tốc độ dữ liệu đầu vào hoặc kiểm soát tốc độ mã hóa. Cho phép kiểm soát tới mức bit/s.

FrameProcessingControl: cung cấp các thông số kỹ thuật đặc trưng của một frame, cho phép thao tác cùng với bộ Codec ở mức tối thiểu nhất.

FrameRateControl:cho phép thay đổi tốc độ duyệt frame.

H261Control: cho phép kiểm soát các thông số mã hóa cho luồng video H.261 ở chế truyển tải hình ảnh.

H263Control: cho phép kiểm soát luồng video mã hóa theo chuẩn H.263, bao gồm: vector vô hướng, mã hóa số học có cú pháp(arithmetic coding– chũ yếu sử dụng cho việc nén dữ liệu chất lượng cao), cơ chế dự đoán nâng cao khi thực hiện tua về trước hay về sau gọi là P-Bframe, và phần quản lý các lỗi mỡ rộng.

KeyFrameControl: cho phép quản lý các đặc trưng của các frame chính. Các bộ mã hóa có thể thực hiện ghi đè lên frame chinh nếu cần thiết.

MpegAudioCotrol: cung cấp khả năng chiết xuất một tập tin MPEG và kiểm soát các tham số mã hóa của tập tin này.

QualityControl: cung cấp các mô tả chất lượng đi kèm với từng định dạng và khả năng kiểm soát CPU khi sử dụng bộ mã hóa. Điều này cho thấy, có thể đạt được những mức chất lượng khác tùy thuộc vào các hiệu ứng và loại hình nén được sử dụng. Việc thiết lập chất lượng đầu ra cao hơn có thể thu được kết quả có chất lượng tốt hơn, ví dụ: chất lượng hình ảnh tốt hơn cho các đoạn video.

SilenceSuppressionControl: cho phép kiểm soát các đặc điểm của các tham số chủ yếu của ức chế sự tĩnh lặng(Silence suppresion) của một Codec. Khi chế độ ức sự chế tĩnh lặng được bật, bộ giả mã sẽ không kết xuất ra bất cứ dữ liệu nào nếu nó nhận được cảnh báo bắt đầu một đoạn ức chế sự tĩnh lặng.

Các công cụ giao tiếp với người dùng:

Một Control có thể cung cấp khả năng giao tiếp với người dùng đầu cuối và khả năng kiểm soát hành vi của họ. Để có được một thể hiện Component mặc định của Control hiện tại, bạn gọi tới phương thức getControlComponent. Phương thức này trả về một đối tượng AWT mà bạn có thể thêm vào ứng dụng của mình.

Một Controller cũng có thể cho phép truy cập đến các thuộc tính dạng Component được định nghĩa bên trong chúng. Ví dụ: một đối tượng Player cung cấp khả năng truy cập đến cung cụ giao tiếp bên trong thông qua phương thức getVisualComponentgetControlPanelComponent.

Nếu bạn không muốn sử dụng các Component đã được định nghĩa sẵn, bạn cũng có thể hiện thực riêng cho mình một công cụ riêng để thực hiện những tác vụ tương tác với người dùng tùy thích. Ví dụ: bạn có thể hiện thực một công cụ giao tiếp với người dùng cho một Player. Các hoạt động giao tiếp trên giao diện sẽ được các thành thích hợp khác chuyển giao cho Player bên dưới, chẳng hạn như các phương thức start hoặc stop. Bằng cách đăng ký các đối tượng kiểm soát có vai trò “lắng nghe” như các đối tượng ControllerListener cho một Player, bạn có thể cung cấp khả năng phản ứng thích hợp với người dùng(thông qua giao diện) đến với Player.

Khả năng mở rộng:

Chúng ta có thể mở rộng JMF bằng 2 cách:

Bẳng cách hiện thực các công cụ(plug-in) tùy ý, chúng ta có thể kế thừa những thành phần tiêu chuẩn đã được xây dựng sẵn để tạo ra một công cụ cho riêng mình.

Hiện thực một cách trực tiếp các đối tượng như Controller, Player, Processer, DataSource, hoặc DataSink.

Khi hiện thực một plug-in, ban có thể tùy chỉnh hay mở rộng thêm các tính năng của một Processer mà không phải bắt tay xây dựng từ đầu. Sau khi một plug-in được đăng ký với JMF, nó có thể được lựa chọn như một quá trình xử lý tùy chọn, miễn là nó được xây dựng bằng API trong Java. Trong Java, plug-in có thể được sử dụng:

Bạn có thể thay thế hay mở rộng một Processer hoạt động độc lập bằng plug-in của mình.

Truy cập vào luồng media data “đang chảy” tại các điểm cụ thể. Ví dụ: bạn có thể sử dụng các plug-in hiệu ứng tại đầu vào và đầu ra của một Processer để tạo hiệu ứng cho luồng media data hiện hành.

Xử lý dữ liệu bên ngoài ProcesserPlayer. Ví dụ: bạn có thể dùng một plug-in tách kênh để xử lý cho một luồng media data ghép, do đó bạn có thể chơi các bản nhạc thông qua Sound(âm thanh) trong Java.

Trong tình huống, người lập trình muốn có được sự linh động và xử lý tốt hơn cho các đối tượng Controller, Player, Processer, DataSource, DataSink, thể hiện của các đối tượng này có thể được thay đổi hay mở rộng để đáp ứng với từng nhu cầu. Ví dụ: nếu bạn muốn có một bộ giải mã MPEG trên phần cứng, bạn có thể hiện thực một Player, có dữ liệu đầu vào từ một DataSource, và sử dụng bộ giải mã để phân tích, giải mã, kết xuất trong từng giai đoạn của quá trình. Các PlayerProcesser cũng có thể được hiện thực và kế thừa từ các công cụ truyền thông đa phương tiện như MediaPlayer(Microsoft), RealPlayer(Real NetWork), HotMedia(IBM).

Lưu ý: trong JMF, ProcesserPlayer không cần thiết hỗ trợ plug-in. Plug-in không hoạt động trong môi trường của JMF1.0.

Trình diễn(Presentation):

Trong JMF, quá trình trình diễn là một mô hình được hiện thực từ các Controller. Controller định nghĩa cơ chế kiểm soát trạng thái và điều kiển cơ bản cho các đối tượng điều kiển, trình diễn và thu nhận dữ liệu truyền thông đa phương tiện dựa trên thời.Nó định nghĩa các giai đoạn mà bộ điều kiển hoạt động và cung cấp một cơ chế kiểm soát các giai đoạn chuyển đổi giữa các quá trình. Một hoạt động cần phải được thực hiện trước khi dữ liệu đa phương tiện theo thời gian có thể được trình diễn, vì vậy JMF cho phép kiểm soát các quá trình trên khi chúng xảy ra.

Một Controller có thể kiểm soát nhiều MediaEvent, và có thể cập nhật trong thái của nó. Để nhận được sự kiện từ một Controller, chẳng hạn như một Player, bạn cần hiện thực lớp ControllerListener.

Trong JMF, có hai dạng Controller: PlayerProcesser. PlayerProcesser được xây dựng cho một nguồn dữ liệu cụ thể và không thể tái sử dụng để trình diễn các luồng dữ liệu khác.

Các Controller trong JMF.

Player:

Một Player xử lý tại đầu vào của một luồng media data và kết xuất ra kết quả theo một thời gian chính xác. Một DataSource được sử dụng để cung cấp dữ liệu cho Player. Điểm kết xuất phụ thuộc vào từng loại dữ liệu truyền thông đang phương tiện được xử lý.

 

Mô hình xử lý của một Player trong JMF.

Player hỗ trợ nhiều phương thức kiểm soát từ người dùng và điều kiển bởi ClockController.

Mô hình kiểm soát của ControllerClock đối với Player.

Trạng thái của Player:

Một Player có thể có 1 trong 6 trạng thái. Clock xác định 2 trạng thái cơ bản: dừng(Stopped) và bắt đầu(Started). Để tạo điều kiện thuận lợi để quản lý tài nguyên, Controller xác định 5 trạng thái: Unrealized(chưa thực thi), Realizing(đang thực thi), Realized(đã thực thi), Prefetching(đang nạp), Prefetched(đã nạp).

Các trạng thái của Player.

Trong một quá trình tiêu chuẩn, một Player phải trải qua tất cả các trang thái trước khi đạt được trạng thái Started:

Một Player ở trạng thái Unrealized sẽ được khởi tạo, nhưng nó sẽ không được cấp phát bất cư tài nguyên nào. Và khi một Player được khởi tạo, nó luôn phải ở trạng thái Unrealizied.

khi phương thức reali được gọi, một Player sẽ thực hiện chuyển trạng thái từ Unrealizing sang trạng thái Realizing. Trong trạng thái Realizing, Player sẽ quyết định yêu cầu những loại tài nguyên nào. Trong quá trình này, Player chỉ được phép yêu cầu tài nguyên cần thiết và chỉ yêu cầu 1 lần. Tài nguyên yêu cầu có thể bao gồm tài nguyên dùng để kết xuất, chứ không nhất thiết là tài nguyên nội tại của hệ thống. (Độc quyền sử dụng tài nguyên có hạn chế, chẳng hạn như các thiết vị phần cứng chỉ có thể được cấp phát cho một Player tại một thời điểm, những tài nguyên như vậy sẽ được Player yêu cầu trong trạng thái Prefething). Một Player ở trạng thái Realizing thường thực hiện tải tài nguyên qua mạng.

Khi một Player kết thúc trạng thái Realizing, nó sẽ chuyển sang trạng thái Realized. Khi một Player đạt được trạng thái Realized, tức là nó đã biết được những loại tài nguyên cần thiết và biết được thông tin về loại dữ liệu sẽ trình diễn. Bởi vì Player ở trạng thái Realized, nó sẽ biết được là sao để kết xuất được dữ liệu, từ đó cung cấp các công cụ và phương thức điều kiển phù hợp. Nó sẽ thực hiện kết nối đến các đối tượng khác của hệ thống, tuy nhiên nó không gây cản trở việc khởi tạo của bất cứ Player nào khác.

Khi phương thức prefetch được gọi, Player sẽ chuyển từ trạng thái Realized sang trạng thái Prefetching. Một Player đang ở trạng thái Prefetching, tức là nó đang ở trạng thái chuẩn bị để trình diễn một luồng madia data.Trong giai đoạn này, Player sẽ chuẩn bị luồng media data, nhận nguồn tài nguyền danh riêng, và tất cả những gì cần thiết để chuẩn bị trình diễn. Trạng thái Prefetching phải được lặp lại, nếu Player nhận được yêu cầu thay đổi vị trí trình diễn hoặc tốc độ trình diễn luồng media data, nó có thể thực hiện bổ sung thêm bộ đệm hay các cơ chế xử lý cần thiết.

Khi phương thức start được gọi, Player sẽ bước vào trạng thái Started. Khi Player ở trạng thái Started, Clock của nó sẽ hoạt động, Time-Base và Media-Time được tính toán. Trên thực tế, Player phải trải qua một thời gian đợi nào đó, trước khi bắt đầu trình diễn.

Một Player gởi một TransitionEvent, khi nó chuyển từ trạng thái này sang trạng thái khác. Một thể hiện của ControllerListener cung cấp cho chương trình của bạn khả năng xác định trạng thái hiện tại của Player và để có thao tác phù hợp. Ví dụ: khi chương trình của bạn gọi một phương thức bất đồng bộ trong một Player hay một Processer, bạn cần xác định sự kiện nào xảy ra khi một quá trình xử lý kết thúc.

Sử dụng cơ chế quản lý theo sự kiện, bạn có thể quản lý độ trễ của một Player, bằng cách kiểm soát thời gian bắt đầu của trạng thái Realizing và Prefetching. Nó cũng cho phép bạn phương thức phù hợp ứng với trạng thái hiện tại của Player.

Các phương thức trong từng trạng thái của Player:

Không phải tất cả các phương thức đều được gọi ở bất cứ trạnh thái nào của Player. JMF hạn chế các phương thức tùy thuộc vào từng trạng thái của Player. Nếu bạn gọi một phương thức không phù hợp với trạng thái hiện tại của Player, nó sẽ “ném” ra biệt lệ tương ứng:

           Trạng thái

Phương

thức

Unrealized Realized Prefetched Started
addController NotRealizedError legal legal ClockStartedError
deallocate legal legal legal ClockStartedError
getControlPanelComponent NotRealizedError legal legal legal
getGainControl NotRealizedError legal legal legal
getStartLatency NotRealizedError legal legal legal
getTimeBase NotRealizedError legal legal legal
getVisualComponent NotRealizedError legal legal legal
mapToTimeBase ClockStoppedException ClockStoppedException ClockStoppedException legal
removeController NotRealizedError legal legal ClockStartedError
setMediaTime NotRealizedError legal legal legal
setRate NotRealizedError legal legal legal
setStopTime NotRealizedError legal legal StopTimeSetError

(nếu được thiết lập trước đó)

setTimeBase NotRealizedError legal legal ClockStartedError
syncStart NotRealizedError NotPrefetchedError legal ClockStartedError

 

Processer:

Một Processer cũng được dùng để trình diễn một luồng media data. Processer là một dạng đặc biệt của Player, nó cung cấp khả năng kiểm soát tất cả quá trình xử lý đầu vào của một luồng media data. Một Processer hỗ trợ tất cả các kiểu điều kiển trình diễn như của một Player.

Mô hình của một Processer.

Ngoài khả năng kết xuất dữ liệu đến các thiết bị đầu ra, một Processer còn có thể kết xuất dữ liệu đến một DataSource, để từ đó, dữ liệu có thể được xử lý tiếp bằng một Player hay một Processer khác, hoặc có thể đi đến những điểm đầu cuối khác, ví dụ: có thể dùng để lưu vào một tập tin.

Điều kiển trình diễn:

Ngoài khả năng cung cấp điều kiển trình diễn bằng Controller, một Player hoặc một Processer còn có thể cung cấp khả năng điều kiển trĩnh diễn lại. Nếu muốn làm như vậy, trước hết, bạn còn có một từ Player hoặc một Porcesser một GainControll bằng cách gọi phương thức getGainControll. Một đối tượng GainControll sẽ cung cấp một GainChangeEvent bất cứ khi nào nó bị thay đổi. Bằng cách hiện thức lớp GainChangeListener, bạn có thể bắt được các thay đổi này. Ví dụ: bạn cập nhật thông tin từ từ một Component.

Trong Player hoặc Processer, tùy thuộc vào từng loại Control, chúng có thể cung cấp cho bạn các hành vi điều kiển của người dùng, cũng như khả năng tùy chỉnh các công cụ giao tiếp với họ. Bạn có thể truy cập các bộ điều kiển này qua phương thức getControls.

Ví dụ: lớp thể hiện CachingControl là một kế thừa của lớp Control, nó cung cấp một cơ chế hiển quá trình tải về trên một thanh tiền trình. Nếu một Player có thể thông báo về tiến độ tải về của nó, nó sẽ sử dụng phương thức này. Để xem một Player có hỗ trợ phương thức CachingControl hay không, bạn có thể gọi phương thức getControl(CachingControl) hoặc sử dụng getControls để xem danh sách bộ điều kiển.

Các cộng cụ giao tiếp người dùng

Một Player hay Processer thường cung cấp 2 công cụ giao tiếp người dùng tiêu chuẩn: công cụ bằng hình ảnh hoặc một bảng điều kiển. Bạn có thể truy cập trực tiếp thông qua phương thức getVisualComponentgetControlComponent.

Bạn cũng có thể tùy chỉnh các công cụ này và sử dụng cơ chế “lắng nghe” để xác định khi nào chúng có thay đổi.

Các sự kiện điều kiển:

Các sự kiện ControllerEvent sẽ được gửi bởi một Controller như Player hay Processer khi chúng rơi vào một trong ba trường hợp sau: chúng có sự thay đổi nội tại, TransitionEvents và ControllerClosedEvent:

Các sự kiện khi xảy ra sự thay đổi gồm: RateChangeEvent, DurationUpdateEvent, và FormatChangeEvent…. Các sự kiện này sẽ được thông báo khi các thuộc tính của một Controller bị thay đổi. Ví dụ: một Player sẽ thông báo một sự kiện RateChangeEvent khi chỉ số tốc độ trình diễn của nó bị thay đổi, thông qua phương thức setRate.

Các sự kiện TransitionEvent cho phép chương trình của bạn theo dõi và đáp ứng những thay đổi trạng thái của một Controller. Ví dụ: một Player sẽ thông báo các sự kiện TransitionEvent khi nó chuyển từ trạng thái này sang trạng thái khac.

Các sự kiện ControllerClosedEvent sẽ được Controller thông báo trước khi nó đóng. Một khi Controller thông báo sự kiện ControllerClosedEvent thì nó không thể còn được sử dụng. Một sự kiện ControllerClosedError là một trường hợp đặc biệt của ControllerClosedEvent. Khi bạn nhận được một ControllerClosedError, bạn có thể có được những phản ứng phù hợp để kiểm soát những trục trặc và giảm thiểu những tác động từ phía người dùng.

Mô hình quản lý sự kiện trong JMF.

Tiến trình:

Một Processer là một Player có một DataSource ở đầu vào, thực hiện một số tiến trình xử lý được định nghĩa bởi người dùng và đầu ra là một luồng media data đã được xử lý:

Mô hình tiến trình xử lý trong JMF.

Một Processer có thể gửi dữ liệu đầu ra đến một thiết bị trình diễn hay một DataSource. Nếu dữ liệu được gửi tới một DataSource, thì DataSource này có thể được sử dụng cho một Player hay một Porcesser khác như một nguồn dữ liệu đầu vào, hoặc có thể dùng làm dữ liệu cho một DataSink.

Trong khi một tiến trình được xử lý bởi một Player được định nghĩa bởi một thể hiện, thì một Porcesser cho phép người lập trình định nghĩa loại tiến trình được áp dụng với luồng media data. Điều này cho phép phối hợp các hiệu ứng, ghép và bố cục lại luồng dữ liệu.

Một tiến trình xử lý luồng media data được thực hiện qua nhiều gia đoạn:

Tiến trình bên trong một Processer.

Tách kênh(Demultiplexing) là một quá trình phân tích luồng dữ liệu đầu vào. Nếu một luồng có chứa nhiều kênh, các kênh này sẽ được chiết xuất và xử lý một cách riêng biệt. Ví dụ: Một tập tin QuickTime có thể được tách kênh thành kênh âm thanh và kênh hình ảnh. Quá trình tách kênh sẽ được tữ động thực hiện, bất cứ khi nào, luồng dữ liệu đầu vào là một luồng media data ghép.

Tiền xử lý(Pre-processing) là quá trình áp dụng các thuật toán hữu ích tương ứng với từng kênh dữ liệu đầu vào.

Chuyển mã(Transcoding) là quá trình chuyển đổi từ kênh media data từ một định dạng đầu vào thành một định dạng khác. Một quá trình giải nén một luồng media data cũng được coi là một quá trình giải mã(deconding). Và ngược lại, quá trình nén một luồng media data cũng được coi là một quá trình mã hóa(encoding).

Hậu xử lý(Post-processing) là quá trình áp dụng các thuật toán cần thiết để giải mã các kênh.

Ghép kênh(Multiplexing) là một quá trình ghép các kênh media data vào một luồng media data duy nhất. Ví dụ: các kênh hình ảnh và âm thanh riêng biệt có thể được ghép vào một luồng dữ liệu dạng MPEG-1. Bạn chỉ định dạng dữ liệu kết xuất bằng phương thức setOutputContentDescriptor.

Kết xuất(Rendering) là quá trình trình bày các kênh media data ra cho người dùng.

Việc xử lý ở từng giai đoạn được thực hiện bởi những thành phần riêng biệt. Những thành phần đó là những plug-in được cung cấp sẵn trong JMF. Nếu Processer hỗ trợ các phương thức TrackControl, bạn có thể chọn plug-in phù hợp cho từng kênh dữ liệu:

Demultiplexer: thực hiện phân tích các luồng media data như WAV, MPEG, QuickTime. Nếu luồng media data là luồng ghép, nó sẽ thực hiện tách luồng này thành những kênh riêng biệt.

Effect:  thực hiện xử lý các hiệu ứng đặc biệt trên từng kênh dữ liệu.

Codex: thực hiện mã hóa và giải mã.

Mutiplexer: thực hiện kết hợp nhiều kênh riêng biệt vào một luồng media data duy nhất.

Renderer: xử lý từng kênh media data, kết xuất dữ liệu đến các điểm đầu cuối như loa và màn hình.

Các trạng thái của Processer:

Một Processer có hai trạng thái chuẩn bị cơ bản, Configuring(đang cấu hình) và Configured(đã cấu hình), xảy ra trước khi Processer vào trạng thái Realizing

Trạng thái của Processer.

Processer sẽ vào trạng thái Configuring khi nó gọi phương thức configure. Khi một Processer ở trạng thái Configuring, nó sẽ kết nối tới một DataSource, thực hiện tách kênh trên luồng dữ liệu đầu vào và xác định định dạng của dữ liệu đầu vào.

Processer sẽ ở trạng thái Configured khi náo đã hoàn thành kết nối đến một DataSource và xác định xong định dạng của dữ liệu. Khi Processer đạt được trạng thái nó sẽ thông báo một sự kiện ConfigureCompleteEvent.

Khi phương thức realize được gọi, Processer sẽ chuyển sang trạng thái Realized.

Khi Processer ở trạng thái Configured, để gọi có được đối tượng TrackControl của các kênh trong luồng media data hiện hành, bạn có thể gọi tới phương thức getTrackControls. Những đối tượng TrackControl này cho phép bạn xác định những hoạt động xử lý mà bạn mong muốn bên trong Processer.

Khi phương thức realize được gọi bên trong một Processer đang ở trạng thái Unrealized, nó cho phép Processer nay chuyển từ trạng thái Configuring hay Configured sang trạng thái Realized.

Không thể truy cập đến các TrackControl của một luồng media data bên trong một Processer đang ở trạng thái Realized.

Các phương thức trong từng trạng thái của Processer:

Processer là một dạng đặc biệt của Player, nên một số phương thức bên trong của một Player cũng có thể được gọi cho một Processer. Ngoài ra, một Processer còn sở hữu một số phương thức đặc biệt. Bảng sau cho ta thấy các phương thức có thể được gọi trong từng trạng thái của một Processer, nếu phương thức được gọi không phù hợp với trạng thái hiện tại hoặc xảy ra lỗi, nó sẽ trả về một biệt lệ tương ứng.

           Trạng thái

Phương

thức

Unrealized Configuring Configured Realized
addController NotRealizedError NotRealizedError NotRealizedError legal
deallocate legal legal legal legal
getControlPanelComponent NotRealizedError NotRealizedError NotRealizedError legal
getControls legal legal legal legal
getDataOutput NotRealizedError NotRealizedError NotRealizedError legal
getGainControl NotRealizedError NotRealizedError NotRealizedError legal
getOutputContentDescriptor NotConfiguredError NotConfiguredError legal legal
getStartLatency NotRealizedError NotRealizedError NotRealizedError legal
getSupportedContentDescriptors legal legal legal legal
getTimeBase NotRealizedError NotRealizedError NotRealizedError legal
getTrackControls NotConfiguredError NotConfiguredError legal FormatChangeException
getVisualComponent NotRealizedError NotRealizedError NotRealizedError legal
mapToTimeBase ClockStoppedException ClockStoppedException ClockStoppedException ClockStopedException
realize legal legal legal legal
removeController NotRealizedError NotRealizedError NotRealizedError legal
setOutputContentDescriptor NotConfiguredError NotConfiguredError legal FormatcChangeException
setMediaTime NotRealizedError NotRealizedError NotRealizedError legal
setRate NotRealizedError NotRealizedError NotRealizedError legal
setStopTime NotRealizedError NotRealizedError NotRealizedError legal
setTimeBase NotRealizedError NotRealizedError NotRealizedError legal
syncStart NotPrefetchedError NotPrefetchedError NotPrefetchedError NotPrefetchedError

Các phương thức bên trong Processer.

Kiển soát tiến trình

Bạn có thể kiểm soát những hoạt động cần thiết của Processer thông qua TrackControl đối với từng kênh cụ thể. Bạn gọi tới phương thức getTrackControls để có được danh sách các TrackControl hiện hành bên trong Processer.

Thông qua một đối tượng TrackControl, bạn có thể chọn bộ hiệu ứng, bộ mã hóa hay bộ kết suất tùy ý với kênh mà bạn chọn. Để tìm ra được những công cụ này, bạn có thể truy vấn đối tượng PlugInManager.

Để kiểm soát quá trình chuyển mã được thực hiện trên một kênh được thực hiện bởi Codec, bạn có thể có được đối tượng điều kiển cho từng kênh bằng cách gọi phương thức getControls cho từng đối tượng TrackControl.  Phương thức này trả về các đối tượng điều kiển cho từng kênh như BitRateControlQualityControl.

Nếu bạn muốn xác định định dạng cho dữ liệu đầu ra, bạn có thể gõi tới phương thức setFormat để xác định định dang mang muốn và cho phép Processer xác định bộ mã hóa và kết xuất thích hợp. Ngoài ra, bạn có thể chỉ định kiểu dữ liệu đầu ra bằng cách: bạn có thể khởi tạo một Processer bằng cách sử dụng một ProcesserModel. Một ProcesserModel xác định các kiểu dữ liệu đầu vào và đầu ra cho một Processer. Khi một ProcesserModel thông qua một Manager để tạo một Processer, bạn có thể quản lý tốt hơn dữ liệu đầu vào và đầu ra.

Dữ liệu đầu ra:

Phương thức getDataOutput trả về một DataSource đầu ra của một Processer. DataSource này có thể được sử dụng cho một Player hay một Processer khác hoặc là nguồn dữ liệu cho một DataSink.

Một DataSource đầu ra của Processer có thể ở bất dạng nào sau đây: PushDataSource, PushBufferDataSource, PullDataSource, PullBufferDataSource.

Về bản chất, Processer là một Player.

Thu

Một thiết bị thu dữ liệu truyền thông đa phương tuện có thể được coi như một nguồn cung cấp dữ liệu. Ví dụ: một microphone có thể nắm bắt âm thanh đầu vào hay một máy quay video kỹ thuât số có thể cung cấp các kỹ thuật thu hình khác nhau. Các thiết bị này có thể gọi tắt là nguồn dữ liệu(DataSource). Ví dụ: một thiết bị có thể cung cấp dữ liệu có thể coi là một PushDataSource. Bất kỳ DataSource có thể được sử dụng như  một trong các loại nguồn dữ liệu sau: PushDataSource, PushBufferDataSource, PullDataSource, PullBufferDataSource.

Một số thiết bị cho phép cung cấp những luồng media data kép. Ví dụ: một luồng dữ liệu thu từ buổi truyền hình trực tiếp có thể cung cấp cả kênh hình và kênh âm thanh. DataSource tương ứng nhiều SourceStream được cung cấp thiết bị thu.

Lưu trữ và truyền tải luồng media data

Một DataSink được sử dụng để đọc dữ liệu lên từ một DataSource hoặc là điểm đến của một luồng media data(không phải đến các thiết bị kết xuất). Một DataSink có thể được lưu thành một tập tin trên hệ thông, có thể được gửi vào mạng(Internet) hoặc có thể được truyền tải trực tuyến thời gian thực bằng phương thức RTP.

Giống như Player, DataSink được xây dựng để quản lý thông qua Manager bằng một DataSource. Một DataSink có thể sử dụng một StreamWriterControl để ghi thành tập tin.

Kiểm soát lưu trữ:

Một DataSink có thể thông báo tình trạng của nó thông qua sự kiện DataSinkEvent. Có các loại DataSinkEvent như sau:

DataSinkErrorEvent: chỉ ra rằng có lỗi khi tiến hành ghi dữ liệu từ DataSink.

EndOfStreamEvent: chỉ ra rằng luồng dữ liệu đã được ghi thành công.

Đế có thể bắt được các sự kiện này, bạn cần có một thể hiện của lớp DataSinkListener.

Ứng Dụng Chia Sẻ Video Trong Mạng Lan

Ứng dụng được xây dựng nhằm mục đích chia sẻ video giữa 1 máy (tạm gọi là server) và các máy còn lại trong 1 nhóm nhất định(các máy client).

  • Giới thiệu sơ về ứng dụng,ý tưởng thực hiện:
  • Client:

Khi các máy client kết nối vào server thì các client sẽ nhận được các đoạn video đang chiếu tại server và hiển thị trên màn hình ở phía client

Client kết nối vào server tại 1 thời điểm sẽ xem được trực tiếp nội dung video đang chiếu tại server(giống với xem truyền hình).

Client có quyền không xem đoạn phim,và gửi yêu cầu về server .

  • Server:

Server phát các đoạn video tại server và bắt đầu gửi video(dưới dạng Stream) lên mạng .

Server sẽ biết được danh sách các client đang kết nối tới mình(mỗi client kết nối sẽ được hiển thị lên bảng tại server).Server sẽ biết được thông tin chi tiết của từng Client.

Server có quyền đóng kết nối và cấm không cho bất cứ 1 client nào xem video.

 

  • Cách thực hiện:
    • Giao thức RTP và dịch vụ Multicast IP Address:
      • Giao thức RTP(REAL TIME PROTOCOL):giao thức vận chuyển thời gian thực.Giao thức này được ra đời để cải tiến về mặt thời gian thực của việc truyền dữ liệu qua mạng,nhất là ở lĩnh vực truyền thông đa phương tiện(video/audio) mà các giao thức trước đó không làm được(TCP/IP).

Giao thức RTP có thể sử dụng với các mục đích:hội thảo trực tuyến,học từ xa qua mạng,chia sẻ video trong 1 nhóm máy tính,…

  • Multicast service:là dịch vụ để gửi các gói tin,tập tin,video/audio từ 1 máy tính tới 1 nhóm máy tính nhất định(mạng Lan).

Địa chỉ IP được multicast sử dụng là địa chỉ IP thuộc lớp D:224.0.0.0  è 239.255.255.255

  • Xây dựng ứng dụng:như vậy ý tưởng chính của chúng em là sẽ sử dụng giao thức RTP và Multicast service để gửi(server) và nhận(các client) video/audio thông qua mạng Lan.
    • Server:
      • Truyền Video/Audio lên mạng(lớp MediaSender):khi bắt đầu chiếu 1 video ,thì tại server sẽ bắt đầu gửi video này lên mạng theo địa chỉ multicast và port multicast nhất định(Ip này phải đảm bảo thuộc lớp D).ví dụ:110.111.112/6366
      • Mở Socket (lớp Server,SocketServerListener): mở Socket tại 1 port để bắt đầu lắng nghe kết nối từ client
      • Giao tiếp với Client(lớp ClientHandler): sau khi tạo socket để lắng nghe kết nối từ các client,server sẽ nắm được thông tin chi tiết của từng Client và bắt đầu giao tiếp với Client:có thể đóng kết nối client,hoặc nhận yêu cầu đóng kết nối từ phía Client
    • Client:
      • Mở kết nối tới Server(lớp Client):tạo socket client và bắt đầu kết nối tới server,nếu được server đồng ý thì client sẽ kết nối thành công tới server,và bắt đầu xem video từ server.
      • Nhận video (Lớp MediaReceive):sau khi kết nối tới server,client sẽ nhận được thông tin về các thông tin của Multicast Address:IP/Port.ví dụ: 110.111.112/6366(video) – 230.110.111.112/6368(audio)

Kết nối tới các địa chỉ tại các port trên,Client sẽ xem được video đang phát trực tuyến tại server.

  • Tiếp tục:Client có thể giao tiếp với server,có thể yêu cầu server đóng kết nối tới mình.
  • Hướng dẫn sử dụng:
    • Hướng dẫn chạy ứng dụng:
      • Server:

Chép các file video(mpg,avi) vào thư mục

 ../server/Release/MediaFiles

Chạy file:

../server/Release/jar/server.jar

Khi chương trình chạy,bấm nút Play để chạy file video và gửi video lên mạng.Sau đó Clients có thể kết nối và xem video.

Khi chọn video khác trong danh sách để play thì sẽ đóng player trước đó.

Hạn Chế: chưa làm được chức năng gửi nhiều video cùng lúc .

  • Client:

Chạy file:

 ..\client\Release\Client.jar

  • Hướng dẫn Build ứng dụng:đã cài đặt ant và set biến môi trường.Chép các file video vào thư mục …/Release/Build/MediaFiles
    • Build Server:mở command(CMD) ,di chuyển thư mục hiện hành tới thư mục xml:gõ ant
  • Build Client: mở command(CMD) ,di chuyển thư mục hiện hành tới thư mục xml:gõ ant

 

  • Chạy mã nguồn bằng netbean,2 project đượ đặt tại 2 thư mục Client và Server.LƯU Ý,PHẢI COPY CÁC FILE VIDEO VÀO THƯ MỤC :

Server/Source(Netbean)/MediaFiles

Tài liệu tham khảo: