Đảm bảo chất lượng dịch vụ (QoS) mạng là một trong những đặc tính quan trọng. Những thành phần của một kiến trúc tổng quát nhằm đảm bảo QoS đã được đề xuất theo cơ chế “ứng dụng yêu cầu, mạng thực hiện” hay “mạng phải thực hiện
theo yêu cầu của ứng dụng” [8]. Trong đó, mạng phải cung cấp cơ chế tương thích
theo biến động về QoS, sự hỗn tạp của các kiến trúc mạng khác nhau và ứng dụng
trao đổi thông tin QoS với mạng về mức chất lượng dịch vụ và chính sách quản lý QoS, gồm cả cơ chế duy trì tài nguyên và tái đàm phán từ đầu cuối đến đầu cuối [78].
Trong mạng Internet hiện nay, có rất ít cơ chế hỗ trợ duy trì tài nguyên, kể cả
những thành phần mạng không có khả năng lập trình để tương thích trong mạng do
sự phát triển không đồng đều và sự đa dạng về chủng loại thiết bị. Vì vậy, áp dụng
phương pháp tương thích động nhằm đảm bảo QoS cho các dịch vụ từ đầu cuối đến
đầu cuối trong mạng đang được quan tâm nghiên cứu. Trong đó, có nhiều nghiên cứu tập trung vào cơ chế tương thích với cấu trúc, tốc độ của luồng bằng việc áp dụng các kỹ thuật vào việc lọc, mã hóa, biến đổi bộ đệm, quyết định, v.v… kể cả tự động chọn trạng thái luồng phù hợp với QoS sẵn có của mạng khi chạy ứng dụng.
Để cung cấp QoS từ đầu cuối đến đầu cuối, ứng dụng thông báo cho mạng các yêu cầu, mạng phải tương thích hoặc tự cấu hình qua tất cả các lớp kiến trúc phù hợp (tương thích tĩnh) và thường xuyên nhận thông tin về QoS của mạng để thay đổi trạng thái luồng để phù hợp với khả năng của mạng (tương thích động).
Nguyên tắc tích hợp yêu cầu QoS phải có được cấu hình, dự báo và duy trì qua tất cả các lớp kiến trúc [8]. Và, cần một giao diện phù hợp giữa ứng dụng và mạng
để quan sát khả năng mạng theo định hướng ứng dụng (tổng hợp khả năng tương
thích giữa QoS hiện tại) của mạng và các trạng thái luồng tiềm năng cho một ứng
dụng. Đây là yêu cầu kết nối lỏng giữa các thành phần của những kiến trúc khác nhau để đơn giản hóa trong quá trình thiết kế hệ thốngđối với các ứng dụng Internet
do IP không thiên về công nghệ mạng cụ thể nào. Thêm vào đó, chi phí dịch vụ (hệ
số tính cước phí cũng thể hiện như một tham số QoS) đối với người sử dụng, nên ứng dụng phải có khả năng tương thích linh hoạt hơn về sự lựa chọn mức dịch vụ.
Mô hình tương thích động được đề xuất trong [86], sử dụng cơ chế QoSSpace
đánh giá các tham số QoS để tạo ra QoSReport về các khả năng giữa QoS của mạng và giá trị trạng thái luồng của ứng dụng qua “giá trị trạng thái tương ứng” (SCV) của mỗi luồng. SCV có các giá trị trong khoảng [0, 1] để chỉ thị việc đánh giá tức thời khả năng giữa trạng thái luồng và mạng (trị 0 hoặc 1, ứng với trường hợp khi
QoSSpace không hoặc có thông tin khẳng định trạng thái luồng được mạng hỗ trợ).
Quyết định phân bố lưu lượng hay trạng thái luồng nào được sử dụng phụ
thuộc vào QoS của mạng, khả năng của ứng dụng và những tham chiếu của người
sử dụng do cơ chế tương thích ứng dụng (Application Adaptation Function - AAF)
cung cấp thông tin tham chiếu (người sử dụng, trạng thái luồng của ứng dụng và
QoSReport) và chọn tự động trạng thái luồng phù hợp nhất khi người sử dụng yêu
cầu “sử dụng dịch vụ giá thấp nhất” ở thời điểm khởi động. Sử dụng mô hình hệ thống điều khiển truyền thống trong hình 3-1 để diễn giải về các khối của mô hình QoSSpace và những khác biệt về mục đích và chức năng liên quan.
Hình 3-1. Hệ thống điều khiển truyền thống
Trong mô hình QoSSpace có:
Chức năng truyền đạt Bộ điều khiển Hệ thống Phản hồi Đánh giá Hành động điều khiển
- Hệ thống là ứng dụng, đầu vào là luồng khi nó truyền qua mạng.
- Các phép đo tại đầu ra là một tập các phép đo tham số QoS đối với luồng. - Chức năng truyền đạt tương tự với QoSSpace tạo ra QoSReport như chức năng phản hồi của bộ xử lý hệ thống.
- Bộ điều khiển tương tự với AAF và hành động điều khiển sẽ lựa chọn trạng
thái luồng phù hợp ảnh hưởng đến hệ thống (ứng dụng) và đầu ra (luồng).
Tuy nhiên, quá trình tương thích động của QoSSpace khác với hệ thống điều
khiển truyền thống ở ba điểm quan trọng về mục đích và chức năng như sau:
- QoSSpace không mô hình hóa đầu vào/đầu ra của hệ thống mà đánh giá sự
tương thích giữa QoS của mạng đối với luồng và trạng thái luồng.
- Các nội dung của QoSReport từ QoSSpace có thể thay đổi bởi ứng dụng và
bởi tham chiếu của người sử dụng.
- Bộ xử lý của AAF có thể thay đổi bởi tham chiếu của người sử dụng hoặc
các đầu vào hoặc đầu ra từ các tài nguyên của ứng dụng cụ thể khác.
So với hệ thống điều khiển truyền thống, trong quá trình điều khiển phản hồi
ở đây các phép đo được xử lý theo cách khác vì việc phản hồi mang bản chất khác. Mục đích của mô hình QoSSpace ở đây là lựa chọn một trạng thái luồng phù hợp cho ứng dụng.
Các ứng dụng Internet trong tương lai phải được tương thích để giải quyết các yêu cầu về sự hỗn tạp của mạng, sự khác biệt về QoS với nhà cung cấp dịch vụ, biến đổi QoS trong khi chạy và khác biệt với tham chiếu của người sử dụng. Có thể, các cơ chế đảm bảo tương thích QoS đã sẵn sàng trên mạng, nhưng chưa được triển khai đồng bộ từ đầu cuối đến đầu cuối. Điều đó đòi hỏi các ứng dụng phải tương
thích bộ xử lý của chúng và khả năng ứng dụng các cơ chế đảm bảo QoS sẵn có trên
trong mạng. Một khung tương quan QoS về trạng thái luồng của ứng dụng, của
mạng và tham chiếu của người sử dụng từ đó xuất hiện nhằm vào tính tương thích
3.3. ĐIỀU KIỆN TƯƠNG THÍCH QoS ĐỐI VỚI MIDDLEWARE
Công nghệ Middleware được áp dụng trong những năm gần đây để hỗ trợ đảm
bảo QoS cho các ứng dụng đa phương tiện phân bố trong môi trường hỗn tạp, nhất
là các ứng dụng nhạy cảm với chất lượng dịch vụ (ứng dụng đa phương tiện, ứng
dụng điều khiển từ xa)... Mục này trình bày một kiến trúc Middleware có khả năng
đảm bảo chất lượng dịch vụ trong môi trường hỗn tạp và các cơ chế tương thích áp
dụng trong giai đoạn triển khai, chạy ứng dụng, gồm xác định đặc điểm QoS của ứng dụng, biên dịch QoS, thiết lập QoS và tương thích QoS.
3.3.1. Kiến trúc middleware đảm bảo QoS
Kiến trúc Middleware tổng quát cho phép thực hiện tương thích QoS theo các
ứng dụng trong các hệ thống đa phương tiện phân tán được đề xuất trong [97] gồm hai lớp, như mô tả trong hình 3-2.
Lớp thứ nhất (lớp ứng dụng chung) có bộ điều khiển tương thích ứng dụng
chung và bộ đánh giá tài nguyên hỗ trợ tương thích tài nguyên lớp thấp bằng cách
phản ứng với những thay đổi về độ sẵn sàng của tài nguyên.
Hình 3-2. Kiến trúc middleware tương thích QoS theo ứng dụng
Lớp thứ hai (lớp ứng dụng cụ thể) có bộ thao tác ứng dụng, các profiler của ứng dụng và bộ đàm phán chịu trách nhiệm thực hiện tương thích chức năng ở mức cao đối với mỗi ứng dụng, kể cả ra quyết định (khi nào và chức năng ứng dụng nào
Ứng dụng (VideoStream, …)
Bộ thao tác (ứng dụng cụ thể) Cơ chế điều khiển
Profiler Bộ đàm phán Lớp ứng dụng Hệ thống đầu cuối khác Lớpứng dụng cụ thể Lớp ứng dụng chung
Tài nguyên mạng/hệ thống đầu cuối
Bộ điều khiển tương thích Bộ đánh giá
tài nguyên
Thông tin tài nguyên hệ thống
Lớp phân bố/Lớp cơ sở hạ tầng
(CORBA, COM) Kernel/OS
Lớp Middleware tương thích nhận biết ứng dụng
được tham gia vào cung cấp dịch vụ) dựa trên các yêu cầu của ứng dụng cụ thể
đang chạy được lưu giữ trong profiler của ứng dụng đó. Tương tác giữa các thành
phần của middleware và ứng dụng được thực hiện thông qua một platform cho phép
thực hiện các dịch vụ truyền thông, ví dụ như CORBA.
Với kiến trúc hai lớp như trên (điều khiển tương thích chung và thao tác ứng dụng cụ thể), các hoạt động do các thành phần này tạo ra sẽ thực hiện điều khiển tương thích chất lượng dịch vụ đối với tất cả các ứng dụng chia sẻ cùng một nguồn
tài nguyên ở hệ thống đầu cuối, đồng thời điều khiển tương thích chất lượng dịch vụ
đối với từng dịch vụ cụ thể dựa trên những tham số cấu hình được thiết lập trong
file cấu hình. Các thành phần của kiến trúc Middleware như trên phù hợp với các
thành phần trong mô hình chung cho tương thích QoS đã được đề xuất [97]. Một ứng dụng triển khai trên hệ thống middleware đảm bảo chất lượng được phát triển theo hai giai đoạn. Đó là giai đoạn xây dựng và giai đoạn chạy ứng dụng.
a.) Giai đoạn xây dựng ứng dụng
Người phát triển ứng dụng chỉ ra các tham số QoS, các cấu hình và môi trường có khả năng áp dụng ứng dụng. Các đặc điểm này được biên dịch bởi bộ biên dịch QoS (một công cụ đã phát triển kèm theo middleware), thành các biểu diễn bên
trong để chèn vào middleware và được sử dụng khi chạy ứng dụng.
b.) Giai đoạn chạy ứng dụng
QoS Middleware thực hiện thiết lập QoS và tương thích cho ứng dụng. Thiết
lập QoS thực hiện trước khi thực hiện ứng dụng, trong khi tương thích QoS được
kích hoạt do sự thay đổi tài nguyên, di chuyển của người sử dụng hay thay đổi đặc
điểm của người sử dụng trong quá trình chạy ứng dụng.
3.3.2. Các cơ chế điều kiện tương thích trong hệ thống QoS Middleware
a). Xác định các đặc điểm QoS của ứng dụng
Trong giai đoạn phát triển ứng dụng, đặc điểm QoS của ứng dụng được cung
cấp. Định dạng đặc điểm QoS thay đổi trong các hệ thống QoS Middleware khác
[77]; trong Agilos, QoS được định nghĩa qua các quy tắc và các chức năng tương
ứng [22]; trong khi ở trong Q-RAM, QoS được trình bày bởi các chức năng sử dụng
tài nguyên [83]. Tuy nhiên các đặc điểm QoS của ứng dụng có chung các đặc tính
về đặc điểm QoS của một ứng dụng cụ thể, định dạng QoS của ứng dụng thì được
thay đổi theo từng nhóm ứng dụng và đặc điểm QoS mức ứng dụng được biên dịch
thành tham số QoS mức hệ thống.
Đối với các ứng dụng chạy trong môi trường có kích thước lớn, đặc điểm QoS của chúng được biểu diễn bao gồm Mô tả ứng dụng (chi tiết hóa một tập thành phần hệ thống tham gia, các tham số QoS chuyển đổi từ mức QoS người sử dụng cảm nhận được), Các chính sách tương thích ứng dụng (chỉ ra điều kiện ứng dụng phải tương thích) và Mẫu trạng thái của ứng dụng (các thông tin trạng thái cần thiết khi ứng dụng có thể tạm dừng hoặc khôi phục).
Hệ thống Middleware hỗ trợ môi trường lập trình QoS, giúp người phát triển
ứng dụng xác định định dạng đặc điểm QoS của ứng dụng.
b.) Biên dịch QoS
Sau khi nhận các đặc tính QoS của ứng dụng, bộ biên dịch QoS chuyển các đặc tính này thành một cơ sở dữ liệu QoS. Cơ sở dữ liệu QoS bao gồm các cấu hình ứng dụng có thể, ấn định tài nguyên, chính sách tương thích ứng dụng, mẫu trạng
thái ứng dụng và được thực hiện bởi hệ thống middleware (giống biên dịch chương
trình, mã nguồn) để thiết lập, phân phối và tương thích ứng dụng QoS. Với đặc tính
QoS như mã nguồn, bộ biên dịch QoS tiếp tục các bước sau:
+ Bước 1: Dịch các đặc tính QoS thành một tập các biểu đồ chức năng của ứng dụng.
+ Bước 2: Kết hợp biểu đồ chức năng ứng dụng với các thành phần dịch vụ thích hợp của hệ thống bao gồm các thành phần thực hiện chức năng đặc điểm theo miền, nhưng độc lập với ứng dụng (các bộ giám sát CPU, buffer hay thu phát RTP).
+ Bước 3: Ấn định tài nguyên “đầu cuối-đầu cuối” cho các thành phần ứng dụng trong mỗi biểu đồ chức năng ứng dụng với cấu hình ứng dụng (tính tài nguyên
hay thăm dò tài nguyên). Bộ biên dịch QoS chỉ xác định việc ấn định các tài nguyên “đầu cuối-đầu cuối” tối thiểu cho mỗi cấu hình của ứng dụng.
c.) Thiết lập QoS
Sau khi biên dịch QoS, các thành phần của ứng dụng được cài đặt trên server
hoặc client của ứng dụng. Middleware sẽ chạy trên các host, cơ sở dữ liệu QoS ban đầu được lưu trữ trong QoSProxy của Server ứng dụng. Khi chạy ứng dụng, các phần của cấu hình QoS được tải về QoSProxy của mỗi client. Quá trình thiết lập
QoS bắt đầu khi người sử dụng bắt đầu một ứng dụng có yêu cầu QoS và kết thúc
khi ứng dụng bắt đầu chạy. Các thực thể tham gia vào quá trình này được chỉ ra trong hình 3-3. Trong giai đoạn thiết lập QoS, Middleware lựa chọn một trong số các cấu hình đã xác định từ trước, phụ thuộc vào yêu cầu QoS của người sử dụng và điều kiện tài nguyên hiện có.
Hình 3-3. Các thành phần mạng tham gia quá trình thiết lập QoS
Các bước chính trong giai đoạn thiết lập QoS gồm: Phát hiện dịch vụ; Lựa chọn cấu hình ứng dụng và ấn định tài nguyên.Mô tả cụ thể các bước như sau:
+ Bước 1 (phát hiện dịch vụ): Khi người sử dụng có yêu cầu cung cấp dịch vụ kèm theo yêu cầu về chất lượng, yêu cầu dịch vụ này được gửi tới hệ thống phát
Middleware Middleware Middleware Middleware Server ứng dụng phụ Server ứng dụng Dữ liệu ứng dụng Dữ liệu ứng dụng đã tương thích
Điều khiển dịch vụ Kết quả/hàng đợi DA hoặc mạng các DA Điều khiển dịch vụ Kết quả/hàng đợi
Dữ liệu ứng dụng
Client ứng dụng
Client ứng dụng
C: Thành phần ứng dụng RB: Tương thích tài nguyên
Hệ thống phát hiện dịch vụ:
SA: tác tử dịch vụ
UA: Tác tử người sử dụng
DA: Tác tử thư viện
QoSProxy
QoSProxy
QoSProxy
hiện dịch vụ. Hệ thống phát hiện dịch vụ sẽ nhận yêu cầu dịch vụ và gửi lại tập các server điều khiển dịch vụ. Hệ thống phát hiện dịch vụ bao gồm ba thành phần chính: tác tử người sử dụng (UA), tác tử thư viện (DA) và tác tử dịch vụ (SA). Tác tử UA
và SA là một phần của QoSProxy chạy tương ứng trên client và trên server.
+ Bước 2 (lựa chọn cấu hình ứng dụng): Sau khi Server ứng dụng được phát hiện, middleware tại client thực hiện cấu hình ứng dụng theo yêu cầu của khách
hàng dựa trên trên các yêu cầu QoS của người sử dụng và cơ sở dữ liệu QoS. Một
cấu hình được lựa chọn có thể gồm các thành phần ứng dụng chạy trên server phụ
để thực hiện yêu cầu QoS của khách hàng theo điều kiện tài nguyên mà cấu hình này hướng tới, kể cả việc xác định vị trí của server ứng dụng phụ.
+ Bước 3 (ấn định tài nguyên): Sau khi lựa chọn cấu hình ứng dụng và xác định các thành phần dịch vụ, Middleware thực hiện ấn định tài nguyên gồm việc tạo lập kế hoạch ấn định tài nguyên “đầu cuối-đầu cuối” theo chiến lược ấn định xác định trong cơ sở dữ liệu QoS rồi gửi kế hoạch ấn định tài nguyên “đầu cuối-đầu cuối” tới server, client và các server phụ khác, được QoSProxy đang chạy trên host gửi đến RB tại chỗ và RB thực hiện việc ấn định thực sự.
+ Bước 4 (tải cơ sở dữ liệu QoS): QoSProxy phía Client tải hai phần sau của
cơ sở dữ liệu QoS từ QoSProxy phía Server về chính sách tương thích dịch vụ và
mẫu trạng thái ứng dụng. Chính sách tương thích dịch vụ dùng để tương thích QoS,
trong khi mẫu trạng thái ứng dụng để hỗ trợ di chuyển ở mức ứng dụng.
Khi bốn bước trên được thực hiện xong, QoSProxy trên mỗi host bắt đầu khởi
động các thành phần quy định trong cấu hình đã chọn. Ứng dụng bắt đầu chạy.
d.) Các cơ chế điều kiện tương thích QoS
Sau khi thiết lập dịch vụ, Middleware có thể thực hiện tương thích QoS trong