Các chương trình quản lý phòng máy hiện nay ở Việt Nam - 6 pdf

126
3.5 Tương tác hệ thống – Điều khiển các dịch vụ có trên hệ
thống:
Trong quá trình thực hiện phần mềm, có một yêu cầu quản trị hệ thống là
người quản trị muốn biết tại thời điểm hiện tại, máy khách đang hoạt động những
dịch vụ (service) gì. Người quản trị có thể xem danh sách các dịch vụ đó, đồng thời
có thể thay đổi bằng cách thêm (mở một dịch vụ mới), bớt (tắt một dịch vụ
đang
chạy). Yêu cầu này đòi hỏi cần phải tìm hiểu cơ chế quản lý dịch vụ trong hệ điều
hành Windows.
3.5.1 Dịch vụ
3.5.1.1 Khái niệm:
Ứng dụng có khả năng hoạt động trong một khỏang thời gian dài trong một
session của hệ điều hành Windows được gọi là dịch vụ. Các dịch vụ có thể tự động
chạy lên mỗi khi máy khởi động, có thể dừng và khởi động lại, và không đưa ra
giao diện với người dùng. Dịch vụ thường được sử dụng trên server hoặc bất cứ
máy nào cần các tính năng hoạt
động lâu dài nhưng không cần can thiệp bởi người
dùng.
3.5.1.2 Loại dịch vụ:
Ta không đi quá sâu vào các dịch vụ cấp thấp. Ta chỉ quan tâm các dịch vụ
dạng ứng dụng chạy là 2 loại Win32OwnProcess và Win32ShareProcess.
3.5.1.3 Vòng đời của dịch vụ:
Một dịch vụ trải qua nhiều trạng thái trong vòng đời hoạt động của nó. Trước
hết, dịch vụ được cài đặt trong hệ thống mà nó sẽ chạy. Quá trình này thực thi bộ
cài đặt của dịch vụ và nạp dịch vụ vào trong Service Control Manager (Bộ Quản lý
Điều khiển Dịch vụ). Service Control Manager là một công cụ do hệ điều hành
Windows cung cấp để quản trị các dịch vụ.

127
Sau khi dịch vụ được nạp, nó phải được khởi động (start). Khởi động dịch vụ
cho phép nó hoạt động. Một dịch vụ đang hoạt động (running) có thể tồn tại ở trạng
thái này cho đến khi nó được ngưng lại (stop) hoặc dừng hẳn (pause) hay máy
shutdown. Dịch vụ có thể tồn tại dưới 3 trạng thái căn bản : Đang hoạt động
(Running), Ngưng (Paused), hay Dừng (Stopped). Dịch v
ụ còn báo về các trạng thái
chuyển (pending) của nó: Tiếp tục Chuyển (ContinuePending), Chuyển Ngưng
(PausePending), Chuyển Khởi động (StartPending), hay Chuyển Dừng
(StopPending). Các trạng thái chuyển cho biết lệnh nào mới vừa được kích hoạt,
nhưng chưa thực thi xong.
Ngoài ra, dịch vụ cần thêm thông tin về trạng thái khởi động của nó. Một số
dịch vụ rất cần thiết cho hệ thống (như dịch vụ DHCP), còn một số
thì không.
Người sử dụng máy có thể cần kích hoạt tự động (Automatic), kích hoạt bằng tay
(Manual), hay vô hiệu hóa (Disabled) dịch vụ. Vì vậy, dịch vụ có 3 trạng thái khởi
động (trạng thái dịch vụ khi máy vừa khởi động xong) là Tự động (Automatic),
Bằng tay (Manual), Vô hiệu (Disabled).
Việc điều khiển các dịch vụ đang hoạt động chính là xem danh sách các dịch
vụ, thay đổi 3 trạng thái hoạt động là Đang hoạt động (Running), Ngư
ng (Paused),
hay Dừng (Stopped), và 3 trạng thái khởi động là : Tự động (Automatic), Bằng tay
(Manual), Vô hiệu (Disabled). Tuy nhiên, với yêu cầu ở đầu mục, ta chỉ cần điều
khiển 2 trạng thái hoạt động là Running và Stopped, và 3 trạng thái khởi động đã
nêu là đủ.
3.5.2 Điều khiển các dịch vụ đang hoạt động trên hệ thống:
Qua kiến thức khái quát về dịch vụ ở 3.5.1, ta có thể thấy rằng để
truy xuất
đến các dịch vụ đang chạy trên hệ thống, ta phải thông qua Service Control

Manager. Đây là cách chung nhất, và có vẻ là cách khả thi duy nhất trên Visual C++
do VC++ 6.0 không hỗ trợ về truy xuất liên quan đến dịch vụ.


128
3.5.2.1 Các hàm API sử dụng :
3.5.2.1.1 OpenSCManager:
Chức năng : thiết lập kết nối đến Service Control Manager trên máy tính và
mở cơ sở dữ liệu của Service Control Manager.
SC_HANDLE OpenSCManager(
LPCTSTR lpMachineName,
LPCTSTR lpDatabaseName,
DWORD dwDesiredAccess
);
Ý nghĩa tham sô:
[in]
lpMachineName : tên máy tính. Nếu là NULL, sẽ mở chính máy tính cục
bộ này.
lpDatabaseName : tên của cơ sở dữ liệu Service Control Manager cần được
mở.
dwDesiredAccess : quyền truy cập mong muốn, xem chi tiết trong MSDN
về các quyền truy cập.
Giá trị trả về:
[out]
Nếu thành công, trả về handle của cơ sở dữ liệu Service Control Manager
được mở.
Nếu thất bại, trả về NULL. . Để bi
ết lỗi, gọi GetLastError.
3.5.2.1.2 EnumServicesStatus
Chức năng: đếm và lấy thông tin về các dịch vụ trong một cơ sở dữ liệu

Service Control Manager được mở.
BOOL EnumServicesStatus(
SC_HANDLE hSCManager,
DWORD dwServiceType,


129
DWORD dwServiceState,
LPENUM_SERVICE_STATUS lpServices,
DWORD cbBufSize,
LPDWORD pcbBytesNeeded,
LPDWORD lpServicesReturned,
LPDWORD
);
Ý nghĩa tham số:
[in]
hSCManager: handle của cơ sở dữ liệu Service Control Manager
được mở, do OpenSCManager trả về khi mở thành công.
dwServiceType : loại dịch vụ cần mở
dwServiceState : trạng thái loại dịch vụ cần liệt kê
[out]
lpServices : trỏ đến cấu trúc ENUM_SERVICE_STATUS chứa thông tin
dịch vụ:
typedef struct _ENUM_SERVICE_STATUS {
LPTSTR lpServiceName; // tên đăng ký của dịch vụ
LPTSTR lpDisplayName; //tên của dịch vụ
SERVICE_STATUS ServiceStatus;
} ENUM_SERVICE_STATUS,
*LPENUM_SERVICE_STATUS;
ServiceStatus : là cấu trúc SERVICE_STATUS

typedef struct _SERVICE_STATUS {
DWORD dwServiceType;
DWORD dwCurrentState;
DWORD dwControlsAccepted;
DWORD dwWin32ExitCode;
DWORD dwServiceSpecificExitCode;


130
DWORD dwCheckPoint;
DWORD dwWaitHint;
} SERVICE_STATUS, *LPSERVICE_STATUS;
dwServiceType : loại dịch vụ.
dwCurrentState :
Giá trị Ý nghĩa
SERVICE_CONTINUE_PENDING Tiếp tục chuyển.
SERVICE_PAUSE_PENDING Chuyển ngưng.
SERVICE_PAUSED Dịch vụ ngưng.
SERVICE_RUNNING Dịch vụ đang chạy.
SERVICE_START_PENDING Dịch vụ đang khởi động.
SERVICE_STOP_PENDING Dịch vụ đang dừng.
SERVICE_STOPPED Dịch vụ dừng hẳn.
Bảng 3-6 Tình trạng hiện tại
dwControlsAccepted
Mã điều khiển Ý nghĩa
SERVICE_ACCEPT_NETBINDCHANGE
Dịch vụ là m
ột thành phần mạng
chấp nhận thay đổi trong
binding mà không cần dừng hay

khởi động lại.
SERVICE_ACCEPT_PARAMCHANGE
Dịch vụ có thể đọc lại các tham
số khởi tạo mà không cần dừng
hay khởi động lại.
SERVICE_ACCEPT_PAUSE_CONTINUE
Dịch vụ có thể ngưng hay tiếp
tục.
SERVICE_ACCEPT_SHUTDOWN Dịch vụ được thông báo khi hệ


131
thống shutdown.
SERVICE_ACCEPT_STOP Dịch vụ có thể dừng.
Bảng 3-7 Loại điều khiển chấp nhận
dwWin32ExitCode : mã lỗi khi có một lỗi xảy ra khi đang khởi động
hay đang dừng.
dwServiceSpecificExitCode : lỗi thực thi do dịch vụ tự định nghĩa.
dwCheckPoint : giá trị tăng dần khi dịch vụ trải qua lần lược các quá
trình khởi động, dừng, ngưng, hay tiếp tục.
dwWaitHint :
thời gian dự đoán cho một thao tác khởi động, dừng,
ngưng, hay tiếp tục, tính theo mili giây.
cbBufSize : vùng đệm chứa thông tin dịch vụ từ lpServices.
[out]
pcbBytesNeeded : số byte cần thêm để lấy các mục dịch vụ còn sót (không
chứa đủ trong cbBufSize).
lpServicesReturned : số lượng các mục dịch vụ lấy được.
[in, out]
lpResumeHandle : handle bắt đầu của dữ liệu chứa các mục dịch vụ còn sót

l
ại.
Giá trị trả về:
[out]
Nếu thành công, trả về khác 0.
Nếu thất bại, trả về 0. Để biết lỗi, gọi GetLastError.
3.5.2.1.3 OpenService
Chức năng: mở một dịch vụ có sẵn.
SC_HANDLE OpenService(
SC_HANDLE hSCManager,
LPCTSTR lpServiceName,
DWORD dwDesiredAccess


132
);
Ý nghĩa tham số
[in]
hSCManager : handle của một cơ sở dữ liệu Service Control Manager được
mở. Hàm OpenSCManager trả về handle này.
lpServiceName : tên của service được mở, tên này không dài quá 256 ký tự.
Cơ sở dữ liệu Service Control Manager phân biệc chữ hoa chữ thường, nhưng so
sánh tên của các dịch vụ thì không. Các ký tự “/” và “\” đều không dùng cho tên của
dịch vụ.
dwDesiredAccess : quyền truy cập dịch vụ mong muốn.
Giá trị trả v
ề
[out]
Nếu thành công, trả về handle của dịch vụ được mở.
Nếu thất bại, trả về NULL. Để biết lỗi, gọi GetLastError.

3.5.2.1.4 StartService
Chức năng : kích hoạt một dịch vụ.
BOOL StartService(
SC_HANDLE hService,
DWORD dwNumServiceArgs,
LPCTSTR* lpServiceArgVectors
);
Ý nghĩa tham số:
hService : handle dịch vụ đã mở bằng OpenService hay CreateService, và
phải có quyền truy cập SERVICE_START.
dwNumServiceArgs : số đối số chuỗi truyền cho dịch vụ.
lpServiceArgVectors : mảng các đối số chuỗi. Dịch vụ driver không nhận
các đối số này. Nếu không cần đối số cho dịch vụ, biến đặt là NULL.
Giá trị trả về:


133
[out]
Nếu thành công, trả về khác 0.
Nếu thất bại, trả về 0. Để biết lỗi, gọi GetLastError.
3.5.2.1.5 ControlService
Chức năng : gởi mã điều khiển đến dịch vụ.
BOOL ControlService(
SC_HANDLE hService,
DWORD dwControl,
LPSERVICE_STATUS lpServiceStatus
);
Ý nghĩa tham số:
hService : handle dịch vụ đã mở bằng OpenService hay CreateService, và
phải có quyền truy cập SERVICE_START.

dwControl : mã điều khiển.
lpServiceStatus: trỏ đến cấu trúc SERVICE_STATUS nhận thông tin tình
trạng mới nhất của dịch vụ, xem thêm 3.5.2.12 EnumServicesStatus để biết thêm
về cấu trúc.
Giá trị trả về:
[out]
Nếu thành công, trả về khác 0.
Nếu thất bại, trả về
0. Để biết lỗi, gọi GetLastError.
3.5.2.1.6 ChangeServiceConfig:
Chức năng : thay đổi các tham số cấu hình của dịch vụ.
BOOL ChangeServiceConfig(
SC_HANDLE hService,
DWORD dwServiceType,
DWORD dwStartType,
DWORD dwErrorControl,


134
LPCTSTR lpBinaryPathName,
LPCTSTR lpLoadOrderGroup,
LPDWORD lpdwTagId,
LPCTSTR lpDependencies,
LPCTSTR lpServiceStartName,
LPCTSTR lpPassword,
LPCTSTR lpDisplayName
);
Ý nghĩa tham số
[in]
hService : handle dịch vụ đã mở bằng OpenService hay CreateService

dwServiceType : loại dịch vụ, xem 3.5.2.1.2 EnumServicesStatus để biết
thêm.
dwStartType : loại trạng thái khởi động.
dwErrorControl : lỗi điều khiển, để SERVICE_NO_CHANGE nếu không
muốn thay đổi điều khiển lỗi đang có.
lpBinaryPathName : tên tập tin nhị phân thực thi của dịch vụ.
lpLoadOrderGroup : tên nhóm thứ tự nạp mà dị
ch vụ là thành viên.
lpdwTagId : giá trị thẻ ghi duy nhất trong nhóm nạp.
lpDependencies : dịch vụ hay nhóm các dịch vụ trong nhóm nạp cần tải
trước khi dịch vụ có thể khởi động.
lpServiceStartName : tên tài khỏan mà dịch vụ chạy.
lpPassword : mật khẩu.
lpDisplayName : tên giao tiếp của dịch vụ với các ứng dụng.
Giá trị trả về:
[out]
Nếu thành công, trả về khác 0.
Nếu thất bại, trả về
0. Để biết lỗi, gọi GetLastError.
3.5.2.1.7 CloseServiceHandle


135
Chức năng : đóng handle được mở cho cơ sở dữ liệu Service Control
Manager hay đối tượng dịch vụ.
BOOL CloseServiceHandle(
SC_HANDLE hSCObject
);
Ý nghĩa tham số:
[in]

hSCObject : handle được mở cho cơ sở dữ liệu Service Control Manager
hay đối tượng dịch vụ cần đóng.
Giá trị trả về:
[out]
Nếu thành công, trả về khác 0.
Nếu thất bại, trả về 0. Để biết lỗi, gọi GetLastError.
3.5.2.2 Cài đặt :
Dựa vào các hàm API nêu ở 3.5.1, ta sẽ thực hiện các cài đặt
3.5.2.2.1 Xem danh sách các dịch vụ :
Các công việc cần làm:
o Mở cơ sở dữ liệu SERVICES_ACTIVE_DATABASE của Service Control
Manager.
o Lấy danh sách các dịch vụ.
o Đóng cơ sở dữ liệu lại.
Hàm cài đặt
BOOL CTaskMgr::GetServiceList(ENUM_SERVICE_STATUS* &pSrvList,
DWORD& nCount)
Có lưu ý cho hàm GetServiceBufferSizeNeeded. Hàm cài đặt này
có tác dụng trả về số byte th
ực sự cần để lưu các thông tin về các dịch vụ.


136

Hình 3-14 Xem danh sách các dịch vụ
3.5.2.2.2 Đổi trạng thái khởi động của dịch vụ :
Thực hiện các công việc sau:
o Mở cơ sở dữ liệu Service Control Manager.
o Mở dịch vụ
o Thay đổi trạng thái khởi động là SERVICE_AUTO_START hay

SERVICE_DEMAND_START hay SERVICE_DISABLED.
o Đóng các handle lại.
Hàm cài đặt ChangeWaytoStartup
int CTaskMgr::ChangeWaytoStartup(CString sServiceName, DWORD
dwStartType)


137

Hình 3-15 Đổi trạng thái khởi động
3.5.2.2.3 Khởi động dịch vụ:
Thực hiện các công việc sau:
o Mở cơ sở dữ liệu Service Control Manager.
o Mở dịch vụ
o Khởi động dịch vụ.
o Đóng các handle lại.
Hàm cài đặt StartService
int CTaskMgr::StartService(CString sServiceName)
3.5.2.2.4 Dừng dịch vụ:
Thực hiện các công việc sau:
o M
ở cơ sở dữ liệu Service Control Manager.
o Mở dịch vụ
o Dừng dịch vụ.
o Đóng các handle lại.
Hàm cài đặt StopService
int CTaskMgr::StopService(LPCTSTR sServiceName)


138

Hình 3-16 Khởi động / tắt dịch vụ
Hoàn tất yêu cầu ban đầu.
Chương 4 Các công nghệ :
Trong ba công nghệ truyền hình ảnh, âm thanh chúng em đã nghiên cứu và
trình bày trong chương này đều có những ưu và nhược điểm riêng:
RFB H323 Windows Media
Encoder (WME)
Ưu điểm Giải quyết triệt để
vấn đề quan sát màn
hình từ xa vì nghi
thức giao tiếp với
hai đầu cuối là là
vùng đệm khung cho
màn hình. Nghi thức
mã nguồn mở, hỗ trợ
đa nền.
Khả năng ứng dụng
rộng rãi trên nhiều hệ
điều hành khác nhau.
Với khả năng tích hợp
mạnh mẽ, H323 có thể
hỗ trợ nhiều công nghệ
truyền hình
ảnh âm
thanh khác nhau
(H261, H263…). Công
nghệ mã nguồn mở.
Là một bộ phát
triển phần mềm của

Windows, WME
tích hợp chặt chẽ
với hệ điều hành
Windows, đưa ra
các khả năng mã
hóa và giải mã âm
thanh hình ảnh theo
dòng rất hiệu quả.
Khuyết điểm Khả năng ứng dụng
các lĩnh vực khác
Các bản phát hành trên
Windows còn nhiều
Đòi hỏi tối đa việc
hỗ trợ về hệ điều


139
khá hạn chế, nghi
thức hầu như chỉ
dành riêng cho ứng
dụng điều khiển máy
tính từ xa.
hạn chế và lỗi, chưa
giải quyết triệt để việc
hỗ trợ trên Windows
(còn “bóng dáng” của
Linux trong việc biên
dịch).
hành trong việc
truyền gởi (phải là

hệ điều hành
Windows các phiên
bản mới thì hỗ trợ
hiệu quả cho
WME).
Bảng 4-1 So sánh các công nghệ nghiên cứu

Qua các sơ lược về ưu khuyết điểm trên, chúng em chọn nghi thức RFB để
thực hiện việc cài đặt, hai công nghệ còn lại chỉ dừng ở mức tìm hiểu và nghiên
cứu.
4.1 RFB
4.1.1 Giới thiệu:
RFB (“remote framebuffer”) là một nghi thức đơn giản để truy xuất đến giao
diện người dùng đồ họa. Vì nó làm việc ở mức vùng đệm khung, nghi thức
tương thích với mọi ứng dụng và hệ thống theo dạng “cửa sổ”, gồm cả X11,
Window.
Đầu cuối ở xa là nơi người dùng sử dụng (chẳng hạn màn hình kèm bàn
phím và có hay không chuột) được gọi là RFB client. Đầu cuối nơi những thay
đổi trên vùng đệ
m khung phát sinh (chẳng hạn các ứng dụng và hệ thống dạng
“cửa sổ”) gọi là RFB server.


140

Hình 4-1 Giới thiệu nghi thức RFB
RFB là nghi thức dành cho thin client. Điều đáng lưu ý trong thiết kế nghi
thức RFB là có rất ít yêu cầu về hệ thống cho client. Do đó, client có thể chạy
trên hầu hết các loại phần cứng khác nhau, công việc cài đặt, xây dựng client
càng đơn giản càng tốt.

Nghi thức xây dựng cho client ở dạng stateless. Nếu nghi thức ngắt kết nối từ
một server cho trước và sau đó kết nối lại vớ
i server, trạng thái của giao diện
người dùng được giữ nguyên. Hơn nữa, một đầu cuối client khác cũng có thể kết
nối vào cùng RFB server. Ở đầu cuối mới, người dùng cũng sẽ thấy chính xác
cùng một giao diện người dùng đồ họa như đầu cuối kia. Khi có kết nối mạng
thích hợp, người dùng có thể truy cập, các ứng dụng cá nhân của họ, và trạng
thái của ứng dụng đó sẽ
giữ gìn giữa các truy xuất từ các vị trí khác nhau. Điều
này cung cấp cho người dùng một cách nhìn thân thiện, chuẩn mực về kiến trúc
máy tính khi họ đi đến bất cứ đâu.
4.1.2 Nghi thức xuất ra màn hình:
Phần xuất của nghi thức dựa trên nguyên tắc đồ họa đơn nhất : “in một hình
chữ nhật dữ liệu điểm ảnh (pixel) tại một vị trí x, y cho trước”. Nhìn sơ qua,
điề
u này có vẻ không phải là cách làm hiệu quả để vẽ nhiều thành phần giao
diện người dùng. Tuy nhiên, áp dụng nhiều thuật tóan mã hóa khác nhau cho dữ
liệu điểm ảnh lại đem đến cho chúng ta sự linh động rất cao trong việc điều


141
chỉnh các thông sô như băng thông mạng, tốc độ vẽ bên client và tốc độ xử lý
của server.
Một lọat các hình chữ nhật như trên tạo nên một cập nhật vùng đệm khung
(hay đơn giản là một cập nhật). Một cập nhật đại diện cho sự thay đổi từ trạng
thái của một vùng đệm khung hiệu lực sang trạng thái khác, do vậy trong một
khía cạnh nào đ
ó nó khá giống với khung hình của video. Các hình chữ nhật
trong một cập nhật thông thường rời rạc nhưng điều này cũng không đáng lưu ý
lắm.

Nghi thức cập nhật được điều khiển bởi người dùng. Có nghĩa là, một cập
nhật chỉ gởi từ một server đến một client để đáp ứng một yêu cầu rõ ràng từ phía
người dùng. Điều này cho phép nghi thức có thay đổ
i tùy nghi về chất lượng
truyền. Client và đường mạng càng chậm, tần suất cập nhật càng thấp. Với các
ứng dụng điển hình, những thay đổi trên cùng một vùng của vùng đệm khung
thường có khynh hướng xảy ra ngay lần lượt. Với một client chậm và/hay một
đường mạng chậm, các trạng thái thay đổi nhanh có thể bỏ qua, đưa đến kết quả
là có ít lưu thông mạng hơn và có ít đường vẽ trên client hơn.
4.1.3 Nghi th
ức nhập thông tin:
Phần nhập của nghi thức dựa trên mô hình máy trạm chuẩn gồm một bàn
phím và một thiết bị trỏ đa nút (thông thường là chuột). Các sự kiện nhập chỉ
đơn giản gởi cho server từ client khi người dùng nhấn phím hoặc nút trỏ, hay bất
cứ khi nào thiết bị trỏ di chuyển. Các sự kiện đầu vào cũng có thể tổng hợp từ
các thiết bị nhập/xuất không chu
ẩn. Ví dụ, một dụng cụ nhận dạng chữ viết tay
dạng cây viết có thể phát sinh các sự kiện bàn phím.
4.1.4 Trình bày dữ liệu điểm ảnh:
Giao tiếp ban đầu của RFB client và server liên quan đến một quá trình thỏa
thuận về định dạng và mã hóa cho dữ liệu điểm ảnh sẽ gởi. Quá trình thỏa thuận
này được thiết kế nhằm mục đích cho họat động xử lý ở
client càng dễ dàng
càng tốt. Điều lưu ý là server phải luôn có thể đáp ứng mọi định dạng mà người


142
dùng mong muốn. Tuy nhiên client có thể tùy nghi với nhiều dạng và mã hóa
khác nhau, nó có thể chọn dạng mà dễ dàng cho server xử lý hơn.
Định dạng điểm ảnh là việc trình bày các màu riêng biệt của các giá trị điểm

ảnh. Định dạng điểm ảnh phổ biến nhất là 24-bit và 16-bit “màu thực”, mà trong
các trường bit giá trị điểm ảnh biên dịch trực tiếp thành các cường độ của sắc
đỏ, xanh lá cây và xanh da trời, và 8-bit “bản màu” nơ
i một quá trình ánh xạ tùy
ý có thể dùng để biên dịch các giá trị điểm ảnh sang các cường độ RGB (Red
Green Blue).
Mã hóa là việc làm thế nào một chữ nhật dữ liệu điểm ảnh sẽ gởi trên đường
truyền. Mỗi chữ nhật dữ liệu điểm ảnh được đính trước bằng một header cho
biết vị trí X, Y của hình chữ nhật trên màn hình, bề rộng và chiều cao của hình
chữ
nhật, và loại mã hóa xác định dạng mã hóa của dữ liệu điểm ảnh. Dữ liệu
theo đó sẽ dùng đúng loại mã hóa đã xác định.
4.1.5 Các mở rộng cho nghi thức:
Nghi thức có thể mở rộng bằng việc thêm các loại mã hóa mới. Các loại mã
hóa được định nghĩa hịên tại là Raw, CopyRect, RRE, CoRRE, Hextile và ZRLE.
Trong thực tế, chúng ta chỉ dùng ZRLE, Hextile và CopyRect vì chúng cung cấp
khả năng nén tốt nhấ
t cho một máy tính điển hình.
Thêm vào các mã hóa thật, client có thể yêu cầu một “mã hóa giả” để khai
báo với server rằng nó có hỗ trợ một mở rộng của nghi thức. Một server không
hỗ trợ phần mở rộng sẽ bỏ qua mã hóa giả trên. Chú ý rằng điều này có nghĩa là
client phải ngầm hiểu là server không hỗ trợ phần mở rộng cho đến khi nó nhận
được xác nhận về mở rộng đó của server.
Điều quan trọng là loại mã hóa và mã hóa giả khác không gây xung đột. Để
tránh điều đó, phiển bản nghi thức RFB và các loại mã hóa được RealVNC Ltd
chứng thực và duy trì.


143
4.1.6 Các thông điệp nghi thức:

Nghi thức RFB có thể họat động trên mọi tầng vận chuyển tin cậy, dựa trên
luồng byte hay thông điệp. Có hai phần trong nghi thức, một pha bắt tay khởi
tạo theo sau một giao tiếp nghi thức thông thường.
Bắt tay khởi tạo bao gồm các thông điệp về Phiên bản Nghi thức, Bảo mật,
Khởi tạo bên Client và Khởi tạo bên Server, sẽ được mô tả sau. Chú ý c
ả server
và client đều gởi thông điệp Phiên bản Nghi thức.
Nghi thức tiến hành trong phần giao tiếp thông thường sau thông điệp Khởi
tạo bên Server. Ở phần này, client có thể gởi bất cứ thông điệp nào mà nó muốn,
và có thể nhận được những thông điệp kết quả từ server. Mọi thông điệp đó đều
bắt đầu bằng một byte loại thông điệ
p, theo sau là dữ liệu.
Bảng mô tả thông điệp sau đây sử dụng các dạng dữ liệu cơ bản U8, U16,
U32, S8, S16, S32. Chúng đại diện lần lượt cho dữ liệu số nguyên không dấu 8,
16 và 32 bit và số nguyên có dấu 8, 16, 32 bit. Mọi số nguyên dạng nhiều byte
(không tính giá trị điểm ảnh) đều theo thứ tự lớn trước nhỏ sau (bit càng ở đầu
càng có giá trị).
Kiểu dữ liệu PIXEL được xây dự
ng hiển thị gía trị điểm ảnh của các byte
dạng byte cho mỗi điểm ảnh (bytePerPixel), trong đó 8x bytePerPixel là số bit
mỗi điểm ảnh (bits-per-pixel) thỏa thuận bởi client và server hoặc trong thông
điệp Khởi tạo bên Server hay thông điệp Đặt Định dạng Điểm ảnh
4.1.6.1 Các thông điệp bắt tay khởi tạo
4.1.6.1.1 ProtocolVersion
Quá trình bắt tay bắt đầu khi server gởi cho client thông điệp
ProtocolVersion. Thông điệp này báo cho client biết số phiên bản nghi thức RFB
cao nhất mà server hỗ trợ. Client sau đó sẽ hồi đáp với một thông điệp tương tự cho
biết số phiên bản nghi thức sẽ dùng (có thể khác với số server đưa). Client không
bao giờ yêu cầu phiên bản nghi thức cao hơn số server nêu. Cả server và client đều
có thể hỗ trợ tương thích ng

ược bằng cơ chế này.


144
Chỉ những phiên bản nghi thức được phát hành lúc này là 3.3, 3.7 và 3.8
(phiên bản 3.5 thường được hồi trả sai bởi một số client, nhưng thường được server
hiểu là 3.3). Việc thêm các dạng mã hóa và mã hóa giả mới thường không có đòi
hỏi thay đổi trong phiên bản nghi thức, vì server chỉ cần đơn giản bỏ qua dạng mã
hóa nếu nó không hiểu.
Thông điệp ProtocolVersion bao gồm 12 byte là một chuỗi ASCII trong định
dạng “RFB xxx.yyy\n” với xxx và yyy là số phiên bản nghi thứ
c chính và phụ, độn
thêm các số 0.
Số byte Giá trị
12
"RFB 003.003\n" (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)
hay
Số byte Giá trị
12
"RFB 003.007\n" (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)
hay
Số byte Giá trị
12
"RFB 003.008\n" (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)
4.1.6.1.2 Bảo mật
Một khi phiên bản nghi thức thỏa thuận xong, server và client phải thỏa
thuận tiếp dạng bảo mật dùng trong kết nối.
Phiên bản 3.7 tiếp Server lập danh sách các dạng bảo mật nó hỗ trợ:
Số byte Type [Giá
trị]

Mô tả
1
số các dạng bảo mật
U8
Mảng U8
Số các dạng bảo mật
Các dạng bảo mật
Nếu server đưa danh sách có ít nhất một dạng được client hỗ trợ, client gởi
trả một byte đơn cho biết dạng bảo mật nào được dùng khi kết nối :
Số byte Type [Giá
trị]
Mô tả


145
1 U8 Dạng bảo mật
Nếu số dạng bảo mật bằng 0, sau đó vì một lý do nào đó kết nối thất bại (e.g
server không thể hỗ trợ phiên bản được yêu cầu). Việc này sẽ tạo ra một chuỗi mô
tả lý do (với số độ dài cho biết chuỗi kèm sau dài bao nhiêu).
Số byte Type [Giá
trị]
Mô tả
4
Độ dài chuỗi
U32
Mảng U8
Độ dài chuỗi lý do
Chuỗi lý do
Server đóng kết nối sau khi gởi chuỗi lý do.
Phiên bản 3.3 tíếp Server quyết định dạng bảo mật và gởi một word đơn:

Số byte Type [Giá
trị]
Mô tả
4 U32 Dạng bảo mật
Dạng bảo mật chỉ có các giá trị 0, 1 và 2.Giá trị 0 cho biết kết nối thất bại và
gởi kèm theo chuỗi lý do đã được mô tả ở trên.
Dạng bảo mật định nghĩa trong tài liệu này là
Số Tên
0 Thất bại
1 Không có gì
2 Chứng thực VNC
Những dạng bảo mật khác là:
Số Tên
5
RA 2
6
RA 2ne
16 Tight
17 Ultra
18 TLS


146
Một khi dạng bảo mật được quyết định, dữ liệu phù hợp với dạng đó sẽ gởi
kèm (xem 4.3.6.2 để biết thêm chi tiết). Vào cuối pha bắt tay bảo mật, nghi thức
thường được tiếp tục với thông điệp SecurityResult.
Chú ý rằng sau pha bắt tay bảo mật, dữ liệu nghi thức tiếp sẽ được gởi trên
một kênh mã hóa hay đã được thay đổi.
4.1.6.1.3 SecurityResult
Server g

ởi một word ể thông báo client quá trình bắt tay bảo mật ã thành
công hay chưa.
Số byte Type [Giá
trị]
Mô tả
4 U32
0
1
Trạng thái:
OK
thất bại
Nếu thành công, nghi thức tiếp tục với thông điệp ClientInitialisation.
Phiên bản 3.8 tiếp Nếu không thành công, server gởi chuỗi mô tả lý do thất bại, và
sau đó đóng kết nối:
Số byte Type [Giá
trị]
Mô tả
4
Độ dài chuỗi
U32
Mảng U8
Độ dài chuỗi lý do
Chuỗi lý do
Phiên bản 3.3 và 3.7 Nếu không thành công, server đóng kết nối.
4.1.6.1.4 ClientInitialisation
Khi client và server đã vui vẻ sẵn sàng nói chuyện với nhau theo dạng bảo
mật đã thỏa thuận, client gởi một thông điệp khởi tạo:
Số byte Type [Giá
trị]
Mô tả

1 U8 cờ chia sẻ


147
Cờ chia sẻ khác 0 nếu server thử cho chia sẻ desktop cho các client khác kết
nối, 0 nếu nó thiết lập một kết nối loại trừ cho client này bằng cách ngắt kết nối
những client khác.
4.1.6.1.5 ServerInitialisation
Sau khi nhận thông điệp ClientInitialisation, server gởi thông điệp
ServerInitialisation. Thông điệp này cho client biết bề dài và bề rộng của vùng đệm
khung, định dạng điểm ảnh và tên của desktop:
Số byte Type [Giá trị] Mô tả

2
2
16
4
chiều dài tên
U16
U16
PIXEL_FORMAT
U32
mảng U8
chiều rộng của khung
chiều dài của khung
định dạng điểm ảnh
chiều dài tên
chuỗi tên
với PIXEL_FORMAT là
Số byte Type [Giá

trị]
Mô tả
1
1
1
1
2
2
2
1
1
1
3
U8
U8
U8
U8
U16
U16
U16
U8
U8
U8
số bit mỗi điểm ảnh
độ sâu màu
cờ big-endian
cờ true-color
red-max
green-max
blue-max

red-shift
green-shift
blue-shift
độn



148
Định dạng điểm ảnh bên server là số bit dùng cho mỗi giá trị điểm ảnh trên
đường truyền. Giá trị này phải lớn hơn hay bằng độ sâu màu, là số bit dùng thực
trong giá trị điểm ảnh. Hiện tại số bit điểm ảnh phải là 8, 16 hay 32 – ít hơn 8 bit
màu chưa được hỗ trợ. Cờ big-endian là khác 0 (đúng) nếu những điểm ảnh đa byte
đượ
c hiểu theo một big-endian (tức là một số có byte chứa giá trị càng lớn thì càng
ở cuối các byte). Hiển nhiên cờ này vô nghĩa với điểm ảnh 8 bit màu.
Nếu cờ true-color là khác 0 (đúng) nếu sáu thành phần cuối xác định làm thế
nào tách cường độ đỏ, xanh và xanh dương từ giá trị điểm ảnh. Red-max là giá trị
đỏ tối đa (=2
n
– 1 với n là số bit dùng cho màu đỏ). Chú ý giá trị này luôn theo thứ
tự big-endian. Red-shift là số lần cần dời bit để lấy giá trị đỏ trong điểm ảnh cho
đến bit quan trọng nhất. Green-max, green-shift và blue-max, blue-shift tương tự
cho màu xanh lá và xanh dương. Chẳng hạn, để tìm giá trị đỏ (từ 0 đến red-max) từ
một điểm ảnh cho trước, làm như sau:
• Tráo đổi giá trị điểm ảnh d
ựa theo cờ big-endian (e.g nếu cờ big-endian
là 0 (sai) và thứ tự byte của máy chủ là big endian, tráo đổi).
• Dời bit sang phải theo red-shift.
• AND với red-max (theo thứ tự byte của máy chủ).
Nếu cờ true-color là 0 (sai) thì server sẽ dùng giá trị điểm ảnh mà không trực

tiếp lấy từ cường độ đỏ, xanh lá và xanh dương, nhưng được biểu thị chỉ rõ trong
bản đồ màu. Các mục trong bản đồ màu
được server thiết lập dùng thông điệp
SetColourMapEntries (phần 4.3.6.4.2).
4.1.6.2 Các dạng bảo mật
4.1.6.2.1 None
Không cần chứng thực và dữ liệu nghi thức gởi không mã hóa.
Phiên bản 3.8 tiếp Nghi thức tiếp tục với thông điệp SecurityResult.
Phiên bản 3.3 và 3.7 Nghi thức tiếp tục với thông điệp ClientInitialisation.
4.1.6.2.2 Chứng thực VNC


149
Chứng thực VNC được dùng và dữ liệu nghi thức gởi không mã hóa. Server
gởi một giá trị thử 16 byte ngẫu nhiên:

Số byte Type [Giá
trị]
Mô tả
16 U16 thử
Client mã hóa giá trị thử với DES, dùng mật mã được người dùng cung cấp
là khóa, và gởi trả hồi đáp 16 byte:
Số byte Type [Giá
trị]
Mô tả
16 U16 hồi đáp
Nghi thức tiếp tục với thông điệp SecurityResult.
4.1.6.3 Các thông điệp gởi từ client tới server
4.1.6.3.1 SetPixelFormat
Thiết lập định dạng mà giá trị điểm ảnh sẽ gởi trong những thông điệp

FramebufferUpdate. Nếu client không gởi một thông điệp thì server gởi những giá
trị điểm ảnh trong định dạng mặc nhiên ghi rõ trong thông điệp ServerInitialisation.
(phần 4.3.6.1.5).
Nếu cờ true-color là 0 (sai) thì nó cho bíêt một “bản đồ màu” sẽ được dùng.
Server có thể thiết lập bất cứ mục nào trong bả
n đồ màu dùng thông điệp
SetColourMapEntries (phần 4.3.6.4.2). Ngay tức khắc sau khi client gởi thông điệp
này (SetPixelFormat) bản đồ màu sẽ bỏ trống, thậm chí nếu đã có những mục được
thiết lập bởi server.
Số byte Type [Giá trị] Mô tả
1
3
16
U8 0

PIXEL_FORMAT
dạng thông điệp
độn
định dạng điểm ảnh
với PIXEL_FORMAT được mô tả trong 4.3.6.15:


150
Số byte Type [Giá
trị]
Mô tả
1
1
1
1

2
2
2
1
1
1
3
U8
U8
U8
U8
U16
U16
U16
U8
U8
U8
số bit mỗi điểm ảnh
độ sâu màu
cờ big-endian
cờ true-color
red-max
green-max
blue-max
red-shift
green-shift
blue-shift
độn
4.1.6.3.2 FixColourMapEntries
Thông điệp này không còn được dùng. Trước đây nó là một dạng thông điệp.

4.1.6.3.3 SetEncodings
Thiết lập dạng mã hóa mà dữ liệu điểm ảnh dùng được server gởi. Thứ tự
của các dạng mã hóa được ghi trong thông điệp là chỉ dẫn của client cho biết ý
muốn của nó( mã hóa được ghi trước nhất là dạng mà nó thích hơn cả). Server có
thể hoặc không nghe theo chỉ dẫn này. Dữ liệu đi
ểm ảnh có thể luôn luôn gởi dưới
dạng mã hóa thô (raw) thậm chí khi không có khai báo tường minh.
Thêm vào các mã hóa thật, client có thể yêu cầu các “mã hóa giả’ để khai
báo với server rằng nó hỗ trợ các mở rộng nào đó cho nghi thức. Server mà không
hỗ trợ phần mở rộng sẽ đơn giản bỏ qua mã hóa giả. Chú ý rằng client phải ngầm
định server không hỗ trợ phần mở rộng cho đến khi nó nhận thông tin xác nhận rõ
phần mở rộng từ
server.
Xem phần 4.3.6.5 cho định dạng dữ liệu cho mỗi mã hóa và phần 4.3.6.6 cho
định nghĩa các mã hóa giả.