Đồ án Tốt nghiệp Tìm hiểu công nghệ thin client và hệ Virtual Network Computing

g trình chạy trên server. Đây là những chương trình rất nặng và chiếm rất nhiều tài nguyên. Cho nên nó không thể chạy được trên các máy Network Computer hay trên các máy trợ giúp kĩ thuật số cá nhân (PDA). ■ Kiểu bảo mật của hệ thống X được kế thừa không được an toàn, khi cho phép các máy tính từ xa hiển thị màn hình của bạn. ■ Khởi động ứng dụng thì vô cùng chậm bởi vì số kết nối ngầm càng ra tăng nhất là với đường truyền có băng thông thấp. Xây dựng hệ videotile dựa trên công nghệ Ultra-Thin Client Vào năm 1994 viện nghiên cứu ORL đã xây dựng hệ videotile để thử nghiệm cho công nghệ ultra-thin-client. Hệ videotile là một thiết bị hiển thị như màn ảnh LCD, một cây bút điện tử và được kết nối qua mạng ATM . Nó được thiết kế để hiển thị video với chất lượng tốt, nhưng cái mà người ta mong muốn khi xây dựng hệ này là nó có thể tương tác với nhiều ứng dụng khác. Từ thí nghiệm đầu tiên cho đến cuối cùng, người ta mong muốn hiển thị màn hình của máy tính từ xa, và phải có ý nghĩa trên mạng có băng thông thấp. Một điều có thể nói là rất thông minh về mặt ứng dụng đó là hình ảnh truyền đi của giao diện người dùng như là hình ảnh của video nhưng chỉ những phần hình ảnh thay đổi thì mới được tryền đi đó là ý tưởng để phát triển giao thức VNC. Truy cập qua một trình duyệt Web hỗ trợ JavaApplet. Từ khi công ty Sun Microsystems tung ra phiên bản alpha của ngôn ngữ java và trình duyệt HotJava vào năm 1995. Các nhà nghiên cứu ORL đã mong muốn có thể cài đặt hay thực thi Videotile trên trình duyệt web có hỗ trợ JavaApplet. Và thế là mô hình thin-client được thiết kế sao cho có thể tương thích với môi trường Java. Giao thức VNC, VNC server và VNC viewer (client) Công nghệ ẩn trong hệ thống VNC là một giao thức đơn giản cho phép truy cập giao diện người dùng từ xa. Làm việc trên framebuffer và tương thích với tất cả các hệ điều hành, các hệ thống có kiểu ứng dụng cửa sổ và các ứng dụng liên kết trên mạng. Giao thức này thực hiện việc kết nối dựa trên bộ giao thức TCP/IP. VNC là một hệ thống “thin-client”. Các thiết kế của nó là tạo ra các chuỗi hình ảnh. Các hình ảnh này được mã hóa trên dữ liệu pixel thật hiệu quả, đồng thời việc ánh xạ các kí tự văn bản đã giúp cho các máy đầu cuối chạy trên phần cứng với những yêu cầu tối thiểu. Các nguyên thủy đồ họa đơn -Single Graphics Primitive Sự hiển thị của giao thức này dựa trên các nguyên thủy hình đồ họa đơn. Khởi tạo giá trị dữ liệu pixel của hình chữ nhật tại tọa độ (x,y) với các kiểu mã hóa cho dữ liệu pixel đã trở nên linh hoạt hơn, cân bằng được các tham số băng thông của mạng, tốc độ hiển thị của client và tốc độ xử lý của server. Một đặc điểm chung mà kiểu mã hóa cho kết quả không cao khi kiểu mã hóa ở trạng thái mặc định-mã hóa thô (raw), tức là không có sự thỏa thuận giữa client và server. Khi đó dữ liệu pixel của mỗi hình chữ nhật sẽ được gửi đi theo thứ tự từ trái qua phải. Và đương nhiên tất cả client phải hỗ trợ kiểu mã hóa này. Tuy nhiên thông thường giữa client và server có thể thỏa thuận để thống nhất một kiểu mã hóa tốt nhất giữa chúng. Ví dụ, kiểu mã hóa copy-rectangle thì rất đơn giản và hiệu quả, và được sử dụng khi client cũng có một dữ liệu pixel tương tự trong framebuffer của nó. Kiểu mã hóa này dùng hệ tọa độ (x,y). Tọa độ này sẽ chỉ ra vị trí của mỗi hình chữ nhật trong framebuffer sao cho client có thể sao chép được dữ liệu đó. Kiểu mã hóa này thể hiện rõ nhất khi trên màn hình có sự di chuyển ảnh hay cuộn trang hình ảnh trên một cửa sổ ứng dụng mà chúng ta hay sử dụng các thanh cuộn. Hầu hết tất cả client đều hỗ trợ kiểu mã hóa này, hơn nữa nó rất dễ cài đặt. Một vấn đề nảy sinh là làm sao nâng cao hiệu quả khi phải truyền đi hình ảnh chứa quá nhiều ảnh nền, hay có nhiều hình chữ nhật với nhiều màu sắc khác nhau. Việc sử dụng mã hóa JPEG giải quyết vấn đề hiệu quả truyền của ảnh tĩnh, mã hóa MPEG cho ảnh động. Cập nhật tương thích-Adaptive Update Việc thiết lập giá trị dữ liệu pixel của mỗi hình chữ nhật cũng là một sự cập nhật trên framebuffer. Việc cập nhật này là một sự hiển thị sự thay đổi trạng thái từ framebuffer này tới framebuffer khác một cách hợp lệ và tương tự như việc cập nhật các frame trong video. Tuy nhiên, không hẳn như vậy, việc cập nhật này thông thường chỉ là các hình chữ nhật khác nhau, có kích thước khác nhau và tất nhiên là ít khi có cùng tọa độ. Vì thế mà phải chọn một kiểu mã hóa thích hợp sao cho có thể truyền đi nội dung hình ảnh một cách tốt nhất, phù hợp với băng thông của mạng hiện có. Giao thức cập nhật được yêu cầu bởi client và server sẽ phải đáp ứng các yêu cầu đó. Chúng ta biết rằng về phía client có các yêu cầu cập nhật khác nhau và các yêu cầu này có tốc độ cũng rất khác nhau. Vì vậy giao thức này phải thỏa mãn chất lượng cho cả client có yêu cầu chậm và kết nối qua mạng có tốc độ chậm. Trên mạng có tốc độ nhanh thì các hình ảnh được cập nhật sẽ mịn hơn nhiều. Chính vì thế việc hiệu chỉnh tần suất yêu cầu của client cũng phải phù hợp với băng thông của mạng cho phép. VNC Viewers Việc thiết kế VNC client rất đơn giản dựa trên công nghệ thin client. Thường được kết nối theo giao thức TCP/IP và hiển thị dữ liệu pixel trực tiếp từ framebuffer nhận được từ server lên một hệ thống các cửa sổ.VNC viewer có thể sử dụng từ rất nhiều các thiết bị và hệ điều hành khác nhau. Đó là sự tổng hợp của hệ thống Videotile (nguồn gốc ra đời của VNC), hệ thống giao diện cửa sổ X-based (ví dụ: Solaris, Linux, and Digital Unix workstations), trên hệ thống Win32 của Windows NT/95, và trên trình duyệt web có hỗ trợ Java applet (của Sun’s JavaStation). Hình 3.7 Mô hình kết nối trên đa hệ điều hành VNC Servers Việc thiết kế VNC server có vẻ khó hơn so với việc thiết kế VNC viewer. Bởi vì giao thức được thiết kế ở đây để client có thể dễ dàng trao đổi với server, server có nhiệm vụ phải thực thi các trao đổi cần thiết (cung cấp định dạng dữ liệu pixel nếu client có yêu cầu). Đầu tiên, khi đi vào thiết kế và xây dựng server, các nhà nghiên cứu đã xây dựng nó trên hai hệ thống một là trên hệ thống X và trên Windows NT/95. Server được phát triển trước tiên trên một máy Unix, và nó có thể đáp ứng một số lượng client kết nối khác nhau, với mỗi hiển thị trên các client khác nhau như là hiển thị các cửa sổ kiểu hệ thống X chúng được coi là các cửa sổ ảo. Việc chuyển mô hình ứng dụng trên hệ điều hành thành các ứng dụng kiểu của sổ của VNC gặp phải một số khó khăn, việc nắm bắt các cửa sổ ứng dụng phải dùng các thư viện của hệ điều hành (trong window chúng ta đã từng biết đến thư viện HOOK). Các thư viện này sẽ thực hiện việc nắm bắt sự thay đổi của màn hình hay các cửa sổ ứng dụng để có thể cập nhật chúng một cách liên tục. Mô hình ứng dụng cho nhiều người dụng cũng đã sớm được đưa vào. Giao thức Remote frameBuffer-RFB Chúng ta có thể thấy được cơ chế chụp màn hình và truyền đi được mô tả bằng hinh dưới đây. Hình 3.8 Giao thức RFB Giao thức RFB thực hiện trên các luồng thông điệp trao đổi giữa Client và Server. Sau đây là các thông điệp cơ bản của giao thức Thông điệp bắt tay-Handshaking Message ProtcolVersion Khi client và server có tín hiệu bắt tay để kết nối thì server sẽ gửi một thông điệp ProtcolVersion. Thông điệp này để client biết rằng phiên bản của giao thức cao nhất mà server hỗ trợ. client cũng gửi lại thông điệp tương tự để cho server biết được phiên bản client đang sử dụng. Thông điệp này gồm 12 byte biên dịch theo mã ASCII theo định dạng sau: Security Khi đã thỏa thuận một phiên bản giao thức thì cả server và client đều phải đồng ý kiểu mã hóa bảo mật khi client kết nối Trong đó: Security –types định nghĩa như sau: SecurityResult server gửi cho client kết quả của kết nối: Nếu kết quả OK thì Client sẽ tiếp tục khởi tạo bằng thông điệp ClientInitialisation ClientInitialisation Client gửi thông điệp khởi tạo: Shared-flag 1 : Nếu server có thể chia sẽ màn hình mà phải rời các kết nối từ các Client khác. 0 : Nếu như server có trao thực hiện kết nối bởi Client này khi hủy kết nối tất cả các kết nối hiện tại. ServerInitialisation Sau khi nhận thông điệp ClientInitialisation, server sẽ gửi thông điệp này để cho client biết kích thước của framebuffer trên server cũng như định dạng pixel của màn hình server như sau: Với PIXEL_FORMAT Server-pixel-format chỉ định dạng pixel tự nhiên trên server, nó được sử dụng trừ khi client có yêu cầu thay đổi định dạng. Bits-per-pixel là số bít sử dụng trên mỗi giá trị pixel(8,16,32) Thông điệp Client gửi Server SetPixelFormat Việc gửi thông điệp này có thể được gửi trong thông điệp FramebufferUpdate. Nếu như client không gửi thông điệp này thì server sẽ gửi giá trị pixel với định dạng tự nhiên khi nó khởi tạo ServerInitialisation. Với PIXEL_FORMAT Nếu true-color-flag là 0 thì ánh xạ màu(colour map) sẽ sử dụng. FixColourMapEntries SetEncoding Việc thiết lập kiểu mã hóa với dữ liệu pixel có thể được gửi bởi server. Thứ tự các kiểu mã hóa thì được gợi ý bởi client như là một tham chiếu. cerver có thể hay không chọn gợi ý đó. Dữ liệu pixel thường được gửi là mã hóa mặc định mã hoá thô (raw) nếu không được xác định. Trong khi thêm các mã hóa xác thực, client có thể yêu cầu mã giả”pseudo-encoding” để khai báo với Server rằng nó hỗ trợ các giao thức mở rộng. Một server cố thể không hỗ trợ giao thức mở rộng này và như thế thì nó sẽ bỏ qua mã giả này. Cấu trúc thông điệp như sau: Với number-of-encodings : FramebuferUpdateRequest Thông điệp này báo cho server rằng client quan tâm tới vùng framebuffer có tọa độ (x,y) và kích thước width và height. Lúc này server sẽ gửi lại thông điệp FramebufferUpdate. Server giả thiết rằng client giữ một bản sao của tất cả các phần framebuffer mà nó quan tâm. Và thông thường thì server chỉ cần gửi phần thay đổi trên framebuffer tới client mà không quan tâm tới những gì đã gửi trước đó. Tuy nhiên trong một vài phiên làm việc nào đó giữa client và server, client bị mất nội dung hay phần ảnh trên màn hình mà nó cần. Khi đó client cần phải gửi lại thông điệp FramebufferUpdateRequest nhưng với biến incremental=0, nếu như yêu cầu này được gửi sớm thì server có thể gửi lại cho client kịp thời và nếu như chúng ta sử dụng kiểu mã hóa CopyRect thì không nhận được kết quả. Nếu như client không bị mất một vài nội dụng của phần hình ảnh mà nó quan tâm, Khi nó gửi thông điệp FramebufferUpdateRequest với biến incremental 0, Lúc này server sẽ gửi lại thông điệp FramebufferUpdate. Cấu trúc của thông điệp như sau: KeyEvents Sử dụng cờ Down-flag để xác định trạng thái của phím ấn hay thả Down-flag=0, nếu như phím được ấn Down-flag=1, nếu như phím được nhả. Giá trị của phím được định nghĩa trong hệ thống X Window. Hầu hết các phím thông thường thì tương ứng với giá trị mã ASCII ví dụ: Khi sử dụng sự kiện phím chúng ta gặp một số vấn đề đó là sự khác nhau giữa hệ thống phím trên Server và trên Client ví dụ kiểu bàn phím Mỹ(US) và kiểu Anh(UK) ... Khi Server sử dụng kiểu phím US nhận được một kí tự ‘#’ từ Client sử dụng kiểu phím UK, vì kiểu phím UK không sử dụng trạng thái lật phím Shift cho nên Server sẽ không thể hiển thị kí tự ‘#’. Trong trường hợp này thì bản thân Server sẽ phải làm một động tác giả (fake) để lật trạng thái phím Shift để nó có thể nhận kí tự ‘#’ thay vì kí tự ‘3’. Không giống như Shift , trạng thái của phím chuyển đổi như Ctrl hay Alt có thể được chuyển đổi bằng hệ thống phím khác. Ví dụ chúng ta sử dụng tổ hợp phím Ctrl-a thì sẽ gửi mã của phím Ctrl sau đó gửi mã của phím ‘a’ trong mã ASCII không tồn tại mã cho tổ hợp phím này. PointerEvents Chỉ ra sự di chuyển và trạng thái khi chuột ấn hay nhả. Cấu trúc thông điệp bao gồm: tọa độ con trỏ chuột(x-position, y-postion), trạng thái phím(button-mask:0-7), giá trị 0 tương ứng phím nhả, 1 tương ứng phím ấn. ClientCutText Thông điệp này có vai trò gửi nội dung một văn bản khi client gõ từ bàn phím hay từ clipboard từ bộ đệm đến server. Thông điệp Server gửi Client FramebufferUpdate Cập nhật framebuffer chứa chuỗi tuần tự các hình chữ nhật dữ liệu pixel để client có thể hiện thị chúng. Thông điệp này được gửi khi client yêu cầu thông điệp FramebufferUpdateRequest Dữ liệu pixel của hình chữ nhật có cấu trúc: SetColourMapEntries Khi định dạng pixel sử dụng là ánh xạ màu, thông điệp này cho client biết giá trị pixel có thể được ánh xạ tới màu RGB. number-of-colours định nghĩa như sau: Bell Báo chuông cho Client khi có kết nối. ServerCutText Cấu trúc Các mã hóa trong giao thức RFB-Encodings Mã hóa thô (Raw) Là kiểu mã hóa dơn giản nhất trên dữ liệu pixel. Kiểu mã hóa này quan tâm tới giá trị pixel width x height phần hình chữ nhật. Các giá trị này theo thứ tự từ trái qua phải trên mỗi dòng. Tất cả client phải chấp nhận mã hóa raw trừ khi nó yêu cầu server thay đổi kiểu mã hóa khác. Mã hóa CopyRect Còn gọi là mã hóa khung chữ nhật, kiểu mã hóa này rất đơn giản và hiệu quả, nó có thể được sử dụng khi client sẵn sàng cùng một dữ liệu pixel bất kể khi nào trong framebuffer. Kiểu mã hóa này quan tâm đến hệ tọa độ X,Y và nó đưa vị trí này vào trong framebuffer sao cho client có thể sao chép dữ liệu pixel của khung chữ nhật mà nó quan tâm. Kiểu mã hóa này có thể sử dụng trong các tình huống(trạng thái) màn hình thay đổi nhiều. Rõ nhất là trong trường hợp di chuyển các cửa sổ hay việc cuộn màn hình. Kiểu mã hóa này không hiệu quả trong việc tối ưu hóa vẽ dạng văn bản hay các mẫu có sự trùng lặp nhiều. Nhưng một sự thông minh là server chỉ gửi các mẫu giống nhau một lần. Mã hóa RRE – Rise and Run Length Encoding Là một kiểu mã hóa tương tự như mã RLE, kiểu mã hóa này cho phép mã hóa các khung chữ nhật đồ họa đơn giản ngay lập tức và hiệu quả, và không thích hợp với khung chữ nhật chứa toàn bộ màn hình. Một ý tưởng cơ bản đằng sau kiểu mã hóa này là phân chia các khung chữ nhật dữ liệu pixel thành các vùng chữ nhật nhỏ hơn tương ứng với dữ liệu pixel gần cùng một tập hợp giá trị điều này làm tăng tốc độ tính toán một cách dễ dàng hơn. Trong mỗi một khung chữ nhật con chứa giá trị . v là gia trị pixel nền chữ nhật đó,(x,y) là tọa độ đầu của khung chữ nhật con và (w,h) là kích thước của khung chữ nhật con đó. client có thể chuyển đổi các giá trị tượng ứng của các khung chữ nhật con thành khung chữ nhật ban đầu.. Cấu trúc mã hóa như sau: number-of-subrectangles có cấu trúc: Mã hóa CoRRE-Compact RRE Là sự biến đổi của mã RRE, mã này không hỗ trợ khung chữ nhật có kích thước quá 255x255 pixels. Khi server muốn gửi một khung chữ nhật có kích thước lớn hơn thì nó phải chia thành các hình chữ nhật nhỏ hơn và sẽ được nén theo kiểu RRE. Tốt nhất kích thước của mỗi khung chữ nhật con là 48x48, nếu kích thước này quá nhỏ sẽ cho kết quả tồi. Cấu trúc mã hóa như sau: number-of-subrectangles có cấu trúc: Mã hóa Hextile Kiểu mã hóa này xuất phát từ ý tưởng của mã hóa CoRRE. Khung chữ nhật được chia thành các tile lớn hơn 16x16, cho phép mỗi chiều của khung chữ nhật con là 4 bit như vậy mỗi khung chữ nhật con sẽ chứa 16 bit. Không giống như mã CoRRE, Tile của khung chữ nhật con không ở mức cao nhất. Trong khi phân chia khung chữ nhật ban đầu tới các cỡ theo một con đường nhận biết sớm. Có nghĩa là vị trí và kích thước của mỗi tile không được chỉ ra cụ thể, việc mã hóa nội dung của các tile theo một trật tự đã nhận biết trước. Nếu kích thước của tile không là bội của 16 thì tile sau sẽ nhỏ hơn. Mỗi tile là hai kiểu mã hóa raw dữ liệu pixel hay một sự thay đổi trên mã RRE. Mỗi tile có một giá trị pixel của background. Tuy nhiên giá trị pixel của bạckground không cần phải chỉ ra nếu nó có cùng giá trị với background của tile trước đó. Và nếu như tất cả các background của tile đều giống nhau thì chi cần chỉ ra một lần. Điều này cũng có ý nghĩa tương tự cho foreground của tile. Như vậy dữ liệu mã hóa của mỗi tile nằm trong một trật tự. Mỗi tile với một kiểu mã hóa riêng: Nếu bit Raw được thiết lập thì các bít còn lại không thích hợp với kích thước và giá trị pixel của khung chữ nhật ( tile). Ngược lại các bít còn lại sẽ bị che ( mask) bởi: BackgroundSpecified - nếu đượcc thiết lập với giá trị mầu nền của tile: Nếu bit Raw đầu tiên của tile chưa được thiết lập thì phải thiết lập bit này. Nếu nó chưa được thiết lập thì background sẽ không thay đổi cho tới tile cuối cùng. ForegroundSpecified - Nếu được thiết lập một giá trị pixel thì nó sẽ xác định mầu foreground cho tất cả các khung chữ nhật con trong mỗi tile. AnySubrects - Nếu được thiết lập, một byte sẽ trả về số khung chữ nhật con sau đây: Nếu không được thiết lập , không trả về khung chữ nhật con nào. SubrectsColoured – Nếu được thiết lập thì mỗi hình chữ nhật con sẽ được gán một mầu của nó. Nếu không được thiết lập thì tất cả các khung chữ nhật con sẽ cùng một mầu cũng như mầu foreground. Nếu như ForegrounđSpecifie bit đã không được thiết lập thì Foreground sẽ giữ nguyên cho đến tile cuối cùng. Khung chữ nhật con có cấu trúc như sau: Sử dụng hai byte để xác định vị trí và kích thước khung chữ nhật con.Bốn bit đầu tiên sẽ xác định vị trí X, bốn bit sau sẽ xác định vị trí Y cũng như vậy đối với width và heigth. Mã hoá ZRLE Mã hóa này dựa trên mã hoá Zlib Run-Length và tổ hợp kiểu nén zlib, kết hợp với mã hoá Run- Length. Khung chữ nhật bắt đầu với chiều dài 4 bytes và theo sau là các byte về dữ liệu nén kiểu zlib. Một luồng dữ liệu zlib được sử dụng trong giao thức kết nối RFB, bởi vậy khung hình chữ nhật được mã hoá và giải mã theo ZRLE theo một trật tự chặt chẽ. Dữ liệu zlib khi giải nén thì được hiển thị trên tile 64x64 pixel theo thứ tự từ trái qua phải, từ trên xuống dưới, tương tự như mã hextile. Nếu như chiều rộng của khung chữ nhật không phải là bội số của 64 thì chiều rộng của tile cuối cùng trong mỗi một dòng là nhỏ hơn. Đối với chiều cao cũng như vậy. Kiểu mã hoá ZRLE sử dụng kiểu nén CPIXEL (Compressed pixel) . Nó giống như PIXEL cho định dạng pixel tương ứng trừ khi bit true-colour-flag khác không, bits-per-pixel là 32, độ sâu màu là 24 hoặc nhỏ hơn thì tất cả bit màu RGB sẽ được xác định bằng 3 byte. Trong trường hợp CPIXEL chỉ sử dụng 3 byte dài và phải chứa nhiều hơn 3 byte thì nó sử dụng thêm bytes PerCPixel. Với mỗi tile sẽ bắt đầu bởi một kiểu subencoding. Bit đầu tiên của byte này được thiết lập nếu như byte này được mã hoá theo kiểu Run-Length, và thiết lập 0 cho các bit còn lại. Các giá trị của subenconding: 0- Dữ liệu pixel Raw: 1- Dữ liệu màu bao gồm các màu đơn lẻ: 2-16: Kiểu bảng màu được đóng gói bao gồm giá trị pixel của paleteSize(=subencoding). 17-127: không sử dụng. 128: Mã hoá RLE, bao gồm số cửa sổ được mã hoá cho tới tile cuối cùng. 129 : không sử dụng. 130-255: bảng mầu RLE, bao gồm các giá trị pixel của paletteSize Mã hóa giả (pseudo-encodings) Cursor pseudo-encoding Một client yêu cầu yêu cầu Cursor pseudo-encoding được khai báo nó có khả năng vẽ con trỏ chuột trên máy hiện tại. Điều này cải tiến hiệu năng trên kết nối mạng chậm. Server thiết lập kiểu chuột bằng các gửi pseudo-rectangle với Cursor pseudo-encoding được cập nhật liên tục. Cập nhật về vị trí, toạ độ cũng như kích thước của pseudo-rectangle. DesktopSize pseudo-encoding Client yêu cầu DesktopSize pseudo-encoding được chỉ ra rằng nó có khả năng sao chép phần thay đổi trên framebuffer. Server sẽ thay đổi cở màn hình bằng các gửi pesedo-rectangle với DesktopSize pseudo-encoding như là khung chữ nhật cuối cùng trong việc cập nhật. Một số nghiên cứu mới về kiến trúc và chức năng của hệ thống VNC VNC client và server giao tiếp với nhau thông qua liên kết socket. Hơn nữa kiến trúc client/server được mở rộng bằng cách đặt vào giữa hai thành phần đó một proxy để ngăn chặn và thao tác các luồng thông điệp. Proxy là cách mà chúng ta cung cấp một cơ chế định tọa độ cho client nhằm hỗ trợ làm việc tương hỗ (cooperative work). Server Cliebts PCM CM PSM RFB server RFB client PSM PSM Log Hình 3.9 Mô hình giao tiếp Client/proxy/Server Hình 3.9 mô tả FrameWork-proxy bao gồm gồm Proxy Client Module (PCM) giao tiếp với RFB Server và Cooperation manager(CM). Proxy Server Module (PSM) qua Cooperation manager(CM) và RFB Client. Proxy Client Module (PCM) PCM đóng vai trò như một proxy client tới RFB Server thông qua kết nối socket. SA sẽ đọc tất cả các thông điệp từ Server và chuyển(forward) chúng tới CM để tìm đường(routing) và phân phối tới PSM. Thông điệp giữa PCM và RFB Server thông qua giao thức RFB. Proxy Server Module (PSM) PSM đóng vai trò như một proxy server tới RFB Client thông qua kết nối socket. Các CA sẽ đọc tất cả các thông điệp từ các Client và gửi(forward) chúng tới CM để tìm đường(routing) và phân phối tới PCM. Thông điệp giữa PSM và RFB Client thông qua giao thức RFB. Cooperation manager(CM) CM thực hiện hai chức năng chính đó là tìm đường và ghi lại các thông điệp. Nó định tuyến cho các thông điệp từ SA tới CA và ngược trở lại. Và ghi lại các thông điệp mà có sự thay đổi trạng thái từ các bộ đệm khung từ xa(Remote FrameBufer). CM gửi multicast thông điệp từ VNC server tới các collaborative VNC client theo các PCM tương ứng và trộn các thông điệp từ VNC client tới VNC server theo các PCM tương ứng. Tại cùng thời gian, nó cũng lưu trữ các thông điệp vào các file log. Để mà đạt được mục đích này thì người ta sử dụng ba công nghệ. Thứ nhất tách rời các ứng dụng giao diện từ các ứng dụng logic sang kiểu hiển thị thay đổi sử dụng giao thức RFB. Thứ hai là đặt một proxy ở giữa kiến trúc Client/Server để chặn, ghi nhận, kết nối lại, trộn và phát multicast các luồng thông điệp giữa các Client và Server trên FrameWork mà chúng ta đã trình bày ở trên. Và công nghệ thứ ba đó là sự mở rộng các tích hợp của công nghệ trong Java và World Wide Web. Trong giao thức TCP (Transmission Control Protocol) thì chỉ cung cấp kiểu dịch vụ truyền unicast. Nếu như chúng ta muốn truyền cùng một thông tin đến nhiều client mà vẫn sử dụng phương thức unicast thì phải đóng gói hay tạo ra các bản sao dữ liệu rồi truyền đến mỗi client trong một chu kì thực hiện (in turn). Cũng như hội thảo trực tuyến (Audio and Video Conferencing) thì số client của VNC kết nối vào proxy thì bị giới hạn bởi băng thông đường truyền của mạng. Con đường tốt nhất để truyền từ một nguồn nào đó đến nhiều client khác nhau là sử dụng dịch vụ truyền multicast dựa trên IP multicast. Kiểu truyền này cung cấp một cách tối ưu hóa hiệu năng truyền dựa trên kiểu truyền unicast với thời gian thực. Sự phối hợp (Coordination) CM giám sát và phối hợp các hoạt động của các môdun xung quanh nó. Nó cung cấp cơ chế phối hợp nhờ các dịch vụ truy cập hoặc các phương thức triệu gọi dưới đây: Register: Đây là phương thức cho phép các modules tự mình đăng ký vào Module Table của CM sau khi bắt đầu được thực hiện. CM giữ lại tất cả các modules hiện thời đang kết nối với chúng. Remove: Phương thức này cho phép các modules tự xóa bỏ sự đăng ký ở bảng Module Table trước khi thoát khỏi hệ thống. Route: Phương thức này cho phép các modules gửi các thông điệp tới các modules khác trong một hệ thống. CM duy trì một bảng định hướng(Route Table) để miêu tả các modules đích cho các thông điệp gửi bởi các modules nguồn. Record: Phương thức này cho phép các module ghi lại các thông điệp chúng bởi đi. Việc ghi lại được thực hiện bởi CM và lưu trữ lại trong các file log. Request: Phương thức này cho phép Proxy Server Modules yêu cầu các quyền (floor) từ các VNC client tương ứng. Sau khi một VNC client chiếm được quyền, CM chỉ dẫn đường cho các sự kiện của người dùng tới từ các client riêng lẻ và hệ thống được đặt vào chế độ supervision mode, có nghĩa là chỉ client quản lý có thể thực hiện việc dùng chung trong phiên làm việc trong khi các client còn lại chỉ có thể quan sát phiên làm việc. Release: Phương thức này cho phép Proxy Server Modules giải phóng floor cho các VNC client tương ứng. Khi VNC client giải phóng floor, hệ thống của chúng ta trở về chế độ bình thường và các client có thể chia sẻ và điều khiển từ xa cùng một phiên làm việc. Reconnect: Phương thức này cho phép các Proxy Client Module chuyển kết nối đến tới một VNC server mới. Khi phương thức được gọi, thì PCM đóng kết nối đối với VNC server hiện thời và kết nối lại tới một server mới. Hệ client cộng tác có thể quyết định server nó muốn kết nối và tự động chuyển kết nối đến những server tương tự cũng như là không tượng tự nhau trong một phiên làm việc. Riêng về phía phương thức được gọi bởi module kết nối, CM đơn giản bằng cách tạo một dịch vụ thông báo đơn giản cho các client. Nó đóng vai trò là một server phiên khi người dùng ở trạng thái nghỉ ngơi giống như số lượng các thành viên được tập trung lại. Khi có sự thay đổi về trạng thái chia sẻ, nó sẽ thông báo cho tất cả các thành viên theo Proxy Server Modules tương ứng. Xem xét các log file, được chia làm hai kiểu: một bản ghi của các thông điệp frame buffer update và một bản ghi khác của các thông điệp user event. Cả hai thông điệp đều được dán nhãn thời gian khi chúng được ghi lại. Việc dán nhãn thời gian phục vụ cho việc đồng bộ trong một chuỗi các thông điệp. Hình 3 biểu diễn sự bố trí của hai log files. Log file của các thông điệp frame buffer update hiệu quả cho việc phát lại các phiên làm việc đã được sao lưu. Một VNC client không đồng bộ có thể đọc các thông điệp từ file theo cùng một cách như các VNC client đồng bộ đọc từ socket. Log file của user event đòi hỏi cho việc xây dựng một cách tự động các bảng chỉ mục nhằm ánh xạ các các sự kiện hoặc nhóm các sự kiện tới một điểm đồng bộ trong log file của thông điệp frame buffer update. Theo cách này chúng ta có thể tạo một chỉ mục của phiên làm việc được ghi lại nhờ các sự kiện giống như các từ chìa khóa. Để tăng tốc độ tìm kiếm cho từ chìa khóa cho khi phát lại, chúng ta cũng chèn vào một điểm checkpoint tùy chọn của log file. Checkpoint chính là một thông điệp frame buffer update lưu trữ các dữ liệu pixel cho toàn thể các frame buffer. Trong khi tìm kiếm từ chìa khóa, các VNC client không đồng bộ đọc điểm checkpoint gần nhất và lấy ra toàn bộ hình ảnh màn hình, nó thưc hiện một phiên làm việc lưu trữ từ một số lần cập nhật màn hình cho tới khi yêu cầu được tìm thấy. Sự cộng tác (Cooperation) Chúng ta hỗ trợ sự cộng tác trong cả hai chế độ đồng bộ và bất đồng bộ. Ở chế độ đồng bộ, các proxy cho phép chia sẻ các vùng làm việc chung và chia sẻ ứng dụng bằng cách multicasting thông điệp frame buffer update tới nhiều collaborative users và trộn các thông điệp user event tới các phiên làm việc dùng chung. Kết quả là mọi người dùng chia sẻ đồng thời một khung nhìn tại một thời điểm và điều khiển ứng dụng cũng như vùng làm việc đó. Proxy cũng cung cấp các dịch vụ hỗ trợ những người dùng có hiểu biết cao và các điều khiển sàn. Ở chế độ làm việc không đồng bộ, log files cung cấp cho người dùng kiểu ghi media. Người dùng có thể lấy lại hoặc phát lại phiên làm việc trước đó nhằm chia sẻ kiến thức cũng như kinh nghiệm. Hệ VNC client của chúng ta, chạy ở chế độ bất đồng bộ VCR-like điều khiển và cho phép người dùng sử dụng các điều khiển như play, stop, fast forward và rewind một phiên làm việc sao lưu giống như phát lại một đoạn băng. Nó làm dễ dàng việc tìm kiếm trước và sau cho các sự kiện người dùng giống như một từ khóa. CHƯƠNG IV ÁP DỤNG VÀ TRIỂN KHAI ỨNG DỤNG VNC TRÊN PHẦN MỀM BKEC 4.1 Tính ứng dụng của hệ VNC trong thực tế Hệ thống VNC là một hệ thống thin client, rất thích hợp trong phát triển ứng client/server. Đặc biệt là các ứng dụng client/server triển khai trên mạng không đồng đều về cấu hình phần cứng và có băng thông mạng thấp. Bởi vậy giảm được chi phí khi triển khai ứng dụng. Trong những phân tích ở các chương trước chúng ta thấy rằng hệ VNC là một hệ thống chia sẻ tài nguyên màn hình và các thiết bị đầu vào như chuột, bàn phím, v.v…Đó là những tài nguyên rất cần thiết khi chúng ta triển khai các ứng dụng. Đầu tiên, là những ứng dụng kiểm soát người dùng sử dụng máy tính từ xa. Ví dụ chương trình kiểm soát hoạt động của nhân viên trong công ty, nhà máy, siêu thị hay một cơ quan tổ chức có sử dụng máy tính cài đặt mạng LAN, INTRANET hay INTERNET. Việc giám sát này giúp cho các nhà điều hành nắm rõ hơn về hoạt động trong tổ chức, công ty mình để có những hình thức điều chỉnh thích hợp. Thứ hai, là những ứng dụng hỗ trợ trong giảng dạy, học tập. Chúng ta đã biết về mô hình học trực tuyến trên mạng (E-learning), đây là mô hình đòi hỏi học viên phải tự tìm bài học, tất cả bài giảng và tài liệu đều ở trên web server. Ở đây tôi muốn nói tới những ứng dụng mà giáo viên có vai trò chủ đạo. Thay vì hình thức giảng dạy truyền thống, giáo viên không nhất thiết phải đến lớp để giảng mà có thể giảng tại bất kì nơi nào thông qua mạng máy tính có cài đặt phần mềm hỗ trợ giảng dạy. Hình thức giảng dạy này không làm thay đổi nhiều so với kiểu truyền thống mà thông qua sự trợ giúp của multimedia giáo viên có thể trao đổi với sinh viên thông qua hệ thống voice cùng với các bài giảng được hiển thị trực tiếp ngay trên màn hình học viên. Do vậy đã tạo nên những giờ học rất hiệu quả và tạo niềm đam mê cho học viên. Cuối cùng, hệ thống VNC là mã nguồn mở theo chuẩn của GNU cho phép chạy trên nhiều hệ điều hành. Được nghiên cứu bởi viện nghiên cứu Cambridge và đang tiếp tục được phát triển bởi công ty RealVnc. Có thể cho chất lượng tốt trên nhiều máy, với ưu thể là không bị mất màu khi chạy trên nhiều máy đó là ưu điểm hơn hẳn so với NetMeeting là một bộ công cụ phát triển SDK của Microsoft. Khi so sánh với NetOp và NetSupport là hai phần mềm dạy học khá nổi tiếng, thì VNC cho chất lượng gần bằng. Hơn nữa VNC không phụ thuộc nhiều vào cấu hình phần cứng kể cả Client hay Server. Đây chính là lý do chính mà chúng tôi sử dụng mã nguồn mở của VNC để xây dựng thành công phần mềm hỗ trợ giảng dạy BKeC. Mô hình lớp kết nối và lớp dịch vụ trong hệ thống VNC VNC là một hệ thống phức tạp, hệ thống này cung cấp nhiều kết nối khác nhau từ các hệ điều hành khác nhau. Hệ thống này có thể chạy trên ứng dụng độc lập hay thông qua dịch vụ của hệ điều hành. Trong khuôn khổ của đồ án, tôi chỉ giới thiệu mô hình VNC trên hệ điều hành Windows. Chúng ta sẽ đưa ra mô hình các lớp kết nối chính và các lớp dịch vụ trên client và server. Phân tích mô hình trên VNCServer Lớp dịch vụ Hệ thống VNC có thể chạy trên ứng dụng độc lập hay chạy trên các dịch vụ của hệ điều hành windows. Sau đây là mô hình của hệ thống VNC-server: VNC-Server VNCWin32 VNCService VNCWin32 Service Hình 4.1 Mô hình ứng dụng và dịch vụ trong VNC Khi chạy trên một dịch vụ của hệ điều hành Windows thì hệ thống phải nhúng ứng dụng VNCWin32 và trong tiến trình dịch vụ. Việc đăng kí dịch vụ được cài đặt trong lớp service. Sau khi đăng kí dịch vụ chúng ta sẽ khởi tạo tiến trình bằng lệnh service.start(). DWORD VNCServerService::serviceMain(int argc, TCHAR* argv[]) { setStatus(SERVICE_RUNNING); //Khởi tạo một service int result = server.run(); //Ứng dụng VNCWin32 được nhúng //Trong một tiến trình service setStatus(SERVICE_STOP_PENDING); //Kết thúc một service return result; } void VNCServerService::stop() { server.stop(); //Dừng tiến trình ứng dụng } Mô hình các lớp kết nối Hệ thống VNC hỗ trợ hai phương thức kết nối, kết nối theo giao thức RFB và giao thức HTTP. Trong hệ thống VNC, thì VNCServer là lớp đóng vai trò quan trọng thực thi tất cả việc điều khiển kết nối với tất cả client. VNCWin32 (Application) VNCServerST (RFP protocol) JavaViewerServer HTTPServer (http protocol) VNCServerST (RFP protocol) Hình 4.2 Mô hình kết nối trên giao thức RFB và HTTP Thông thường kết nối giữa client và server thông qua giao thức RFB (tức là từ ứng dụng đến ứng dụng). Nhưng đôi khi lại có các yêu cầu kết nối thông qua một trình duyệt web có hỗ trợ máy ảo java (tức là từ ứng dụng Web đến ứng dụng thông thường). VNC cài đặt một lớp JavaViewerServer, lớp này là một thành phần trung gian, giúp cho việc kết nối theo giao thức HTTP chuyển sang giao thức RFB. Việc cài đặt linh hoạt này giúp cho client có thể truy cập ở bất kì nơi nào trên thế giới thông qua mạng INTERNET. Hơn nữa, với một trình duyệt hỗ trợ máy ảo java người dùng có thể truy cập tới server, thông tin hiển thị trên JavaApplet. Chúng ta có thể thấy hai kiểu kết nối được trích dẫn sau đây: int VNCServerWin32::run() { { Lock l(runLock); hostThread = Thread::self(); runServer = true; } DWORD result = 0; try { //Khởi tạo socket chờ kết nối ManagedListener rfb(&sockMgr, &vncServer); //RFB protcol ManagedListener http(&sockMgr, httpServer); //HTTP protcol // Thao tác cho đến khi tiến trình kết thúc MSG msg; do { // Khởi tạo cổng trên cả hai giao thức kêt nối. rfb.setPort(port_number, localHost); http.setPort(http_port, localHost); //Cập nhật trang web Java viewer's . httpServer->setRFBport(rfb.sock ? port_number : 0); // Chạy server cho đến khi thông tin trong registry //thay đổi hay tiến trình ứng dụng kết thúc while (sockMgr.getMessage(&msg, NULL, 0, 0)) { if (msg.hwnd == 0) { if (msg.message == VNCM_REG_CHANGED) break; if (msg.message == VNCM_COMMAND) doCommand(); } TranslateMessage(&msg); DispatchMessage(&msg); } } while ((msg.message != WM_QUIT) || runServer); } catch (…) { } { Lock l(runLock); runServer = false; hostThread = 0; } return result; } Bây giờ chúng ta sẽ phân tích các liên kết chính, cài đặt của một số lớp kết nối với lớp VNCServerST, đọc và ghi thông tin từ luồng, bảo mật hay mã hóa dữ liệu. Trong mô hình kết nối có rất nhiều các lớp là các interface, chúng được cài đặt nhiều phương thức ảo. Hầu hết các phương thức ảo được cài đặt trên lớp VNCServerST. Chúng ta có thể xem kĩ hơn về các phương thức cài đặt trong phần phụ lục. Mô hình kết nối giữa các lớp được mô tả bằng hình 4.232. Việc tổ chức kết nối từ lớp VNCServerST và SConnection thông qua lớp VNCSConnection. Lớp này có nhiệm vụ cài đặt một số phương thức tham số của cấu hình server. Lớp SConnection thực hiện việc kết nối, bảo mật với mỗi client. Lớp SMsgReaderV3 đọc các thông tin gửi đến server trên luồng rồi xử lí và trả lời client thông qua lớp SMsgWriterV3. Lớp SDesktop là một lớp interface, thu nhận các sự kiện thay đổi của màn hình, chuột, bàn phím,.v.v… Lớp này được cài đặt trên lớp SDisplay. // -=- SDesktop interface virtual void start(VNCServer* vs); virtual void stop(); virtual void pointerEvent(const Point& pos, rdr::U8 buttonmask); virtual void keyEvent(rdr::U32 key, bool down); virtual void clientCutText(const char* str, int len); virtual void framebufferUpdateRequest(); virtual Point getFbSize(); Hình 4.3 Mô hình kết nối lớp VNCServerST Chúng ta sẽ nắm một cách rõ ràng hơn khi xem đoạn code khởi tạo một ứng dụng VNCServerWin32 sau đây: // VNCServerWin32 Server-Khai báo các biến rfb::win32::SDisplay desktop; rfb::VNCServerST vncServer; rfb::Mutex runLock; rfb::Thread* hostThread; bool runServer; bool isDesktopStarted; JavaViewerServer* httpServer; rfb::win32::RegistryReader config; rfb::win32::SocketManager sockMgr; QueryConnectDialog* queryConnectDialog; //Khởi tạo một ứng dụng VNCServerWin32 VNCServerWin32::VNCServerWin32() : vncServer(CStr(ComputerName().buf), &desktop), httpServer(0), runServer(false), isDesktopStarted(false), command(NoCommand), commandSig(commandLock), queryConnectDialog(0) { // Khới tạo Java-viewer HTTP server httpServer = new JavaViewerServer(&vncServer); // Khởi tạo màn hình desktop.setStatusLocation(&isDesktopStarted); // Khởi tạo VNC server vncServer.setQueryConnectionHandler(this); // Đăng kí các sự kiện màn hình để điều khiển sockMgr.addEvent(desktop.getUpdateEvent(),&desktop); } Phân tích mô hình trên VNCClient Kết nối thông qua trình duyệt Web Chúng không quan tâm nhiều tới kiều kết nối này, giao thức liên lạc là giao thức HTTP. Chỉ cẩn trình duyệt web có hỗ trợ JavaApplet là hoàn toàn người dùng có thể truy cập vào server. Kết nối thông qua ứng dụng dựa trên giao thức RFB Nhìn chung mô hình kết nối trên client đơn giản hơn nhiều so với trên server. Trên server chạy trên nhiều tiến trình đơn tương ứng với các phiên kết nối từ server tới các client khác nhau. Hình 4.4 Mô hình kết nối và hiển thị trên VNCclient Trong mô hình kết nối trên, việc gửi hay nhận thông điệp cũng giống như server đều thông qua hai lớp CmsgReaderV3 và lớp CmsgWriterV3. Mỗi khi nhận được dữ liệu lớp Cview sẽ hiển thị hình ảnh lên một cửa sổ theo chuẩn PixelBuffer cài đặt trên lớp DIBsectionBuffer. Trong một phiên kết nối thì cả client và server đều phải thống nhất kiểu bảo mật, định dạng dữ liệu pixel và kiểu mã hóa. Lớp CView thực thi trong một tiến trình đơn CViewThread, tiến trình này được khởi tạo từ lớp CviewManager như sau. bool CViewManager::addClient(const char* hostinfo, bool isConfigFile) { CViewThread* thread = new CViewThread(hostinfo, *this, isConfigFile); addThread(thread); thread->start(); return true; } void CViewThread::run() { try { CView view; view.setManager(&manager); const char* hostname; // Tách host name và port CharArray host; int port; getHostAndPort(hostname.buf, &host.buf, &port); // Chuẩn bị thử kết nối // các sự kiện tổ hợp phím bấn dùng phím shift keybd_event(VK_SHIFT, MapVirtualKey(VK_SHIFT, 0), 0, 0); keybd_event(VK_SHIFT, MapVirtualKey(VK_SHIFT, 0), KEYEVENTF_KEYUP, 0); sock = new network::TcpSocket(host.buf, port); } catch(…) {} //Khởi tạo kết nối cho lớp CView view.initialise(sock); try { view.postQuitOnDestroy(true); //Kiểm tra dữ liệu trên luồng sau khi giải mã rồi hiển thị lên //của sổ CView. Và sẽ thực hiện liên tục cho đến khi kết nối bị //hủy bỏ while (true) { view.getInStream()->check(1,1); view.processMsg(); } } catch (…) {} } //end Run() method Biểu đồ tuần tự phiên kết nối trong hệ thống BKeC-VNC + Các thông điệp bắt tay giữa client và server: Server và client phải thỏa thuận một phiên bản làm việc chung. Sau đó server sẽ xác định quyền truy nhập của client. Cả client và server đều phải gửi thông điệp khởi tạo để xác định kiểu mã hóa dữ liệu, ánh xạ màu và định dạng dữ liệu pixel. + Các thông điệp trong một phiên kết nối: Client có yêu cầu cập nhật dữ liệu framebuffer cùng với các sự kiện bàn phím và chuột. Server sẽ cập nhật dữ liệu framebuffer. + Thông điệp hủy kết nối: Cả client và server đều có thể hủy kết nối mà không làm ảnh hưởng tới phiên làm việc khác. Sau đây là trình tự kết nối trong một phiên giao dịch giữa BKecVncServer và BKecVncClient: Hình 4.5 Biểu đồ tuần tự phiên kết nối trong hệ thống BKeC-VNC Các khối chức năng truyền dữ liệu trong BKeC-VNC Trong hệ thống BKeC-VNC, chúng ta quan tâm nhất tới việc truyền dữ liệu ảnh màn hình. Chỉ khi màn hình có sự thay đổi ở vùng nào đó trên màn hình thì chức năng Windows API Hooking sẽ thu nhận sự thay đổi đó (theo tọa độ, kích thước của hình ảnh). Sau đó hình ảnh được chuyển thành dữ liệu pixel. Dữ liệu này sau khi chụp còn ở dạng thô nên nó sẽ được mã hóa nhờ chức năng Desktop Data Encoding. Chức năng Compression tiếp tục nén dữ liệu rồi chuyển vào luồng. Chức năng Stream và Network sẽ có nhiệm vụ là truyền thông tin tới các máy client dưới dạng những khung dữ liệu framebuffer. Network + Socket + TCPSocket Decompression Stream + In Stream + OutStream FrameBuffer Input + Mouse + Keyboard Desktop Bitmap image Window API Hooking + Input + Desktop Desktop Data Encoding + Raw + ZRLE + Hextile + RRED Compression Stream + In Stream + OutStream Network + Socket + TCPSocket ................. Desktop Display Desktop Data Decoding + Raw + ZRLE + Hextile + RRED Current Token User(1) . . . . Current Token User(n) Server Client Hình 4.6 Truyền dữ liệu giữa BKeC Server và BKeC Client Khi có nhiều client tham gia kết nối tới server, thì việc đồng bộ hóa việc truyền dữ liệu là rất quan trọng. VNC cung cấp cơ chế điều khiển phiên bằng cách cấp cho mỗi một client một thẻ TokenUser. Khi đó dữ liệu sẽ được sao chép thành nhiều bản như nhau và truyền đồng bộ cho các client. Cơ chế này được hỗ trợ bởi hệ điều hành. Mỗi client nhận được dữ liệu phải giải nén nhờ chức năng Decompression. Sau đó dữ liệu được giả mã và hiển thị lên màn hình của client. 4.3 Phân tích yêu cầu triển khai phần mềm BKeC Trong phần mềm BKeC thì hệ thống chia sẻ màn hình và thiết bị (chuột, bàn phím, v.v..) là những chức năng quan trọng nhất. Bởi vì trình diễn bài giảng, điều khiển máy tính từ xa là những chức năng không thể thiếu được trong tất cả các phần mềm hỗ trợ giảng dạy và cũng như phần mềm BKeC. Sau đây là các tương tác chính của hệ thống chia sẻ màn hình và thiết bị. Mô hình trình diễn bài giảng Trong mô hình này máy giáo viên đóng vai trò là một máy server, còn khi đó các máy học viên đóng vai trò là các máy thin client kết nối trực tiếp vào server để nhận được những hình ảnh trên màn hình của máy giáo viên. Ví dụ một bài giảng Power point, hay kĩ năng sử dụng máy tính, v.v…Và quan trọng hơn giáo viên có thể truyền đạt những gì không thể nói bằng lời. Hình 4.7 Mô hình chia sẽ màn hình cho nhóm Trong mô hình trên ta thấy giáo viên có thể chia sẻ màn hình của mình cho một nhóm sinh viên. Như vậy giáo viên có thể giảng bài, trình diễn hay thảo luận một vấn đề nào đó cho một nhóm sinh viên mà không ảnh hưởng tới thành viên khác trong lớp. Tương tự với việc chia sẻ màn hình cho một học viên bất kì trong lớp. Hình 4.8 Mô hình chia sẽ màn hình cho lớp học Mô hình kiểm soát màn hình máy học viên Việc kiểm soát màn hình máy học viên đóng vai trò quan trọng. Qua đó giáo viên có thể biết được học viên đang làm gì và có gặp khó khăn gì. Trong mô hình này thì máy học viên đóng vai trò là một server, còn máy giáo viên là client kết nối tới máy học viên để nhận dược hình ảnh trên màn hình máy học viên. Tương tự như vậy khi giáo viên muốn chọn một máy học viên bất kì để trình diễn hình ảnh cho cả lớp xem. Hình 4.9 Mô hình kiểm soát màn hình học viên và chia sẽ màn hình cho lớp học 4.4 Mô hình thiết kệ hệ VNC trong phần mềm BKeC Từ việc phân tích yêu cầu chúng ta thấy rằng cần phải cài đặt VncServer và VncClient trên cả máy giáo viên và máy học viên. Hệ thống VNC được viết trên nền Win32 nên dễ dàng đóng gói thành thư viện kiểu COM để lập trình. Chúng tôi đã đóng gói thành hai thư viện sử dụng trong phần mềm BKeC: + BkVncServer.dll bao gồm hai hàm chính: DSStartServer() : thực hiện khởi tạo VNC Server. DSStopServer() : dừng VNC Server. + BkVncClient.dll bao gồm hai hàm chính: DSStartClient (string host, int port) : thực hiện kết nối với VNC Server. DSDisconnectServer() : thực hiện ngừng kết nối với VNC Server. BKeC Server VncServer VncClient BKeC Client VncServer VncClient Yêu cầu Yêu cầu Đáp ứng Đáp ứng Hình 4.10 Mô hình giao tiếp giữa BKeC Server và BKeC Client Công nghệ COM+ là công nghệ truyền thông trong mạng rất hay. Thứ nhất nó là viết được bởi một ngôn ngữ bầt kỳ nào trong nền Windows, sau đó có thể dung lại với thậm chí các ngôn ngữ khác không trực tiếp viết ra nó. Tức là độc lập về ngôn ngữ. Thứ hai nó viết theo tư tưởng hướng đối tượng nên dễ dùng. Thứ ba, đặc biệt quan trọng, nó được viết trên lớp application, là lớp mà lập trình viên thao tác trực tiếp trong các lớp mạng nên dễ dùng để phát triển các ứng dụng Điểm yếu về công nghệ là việc dùng các tính năng bảo mật rất phức tạp. Hệ thống Vnc đã khắc phục những khó khăn (các cấu hình về bảo mật) khi chuyển ứng dụng từ Windows 2000 sang WinXP .Để chi tiết hơn xin xem các tài liệu về COM+ do Microsoft cung cấp. Trong phần mềm BKeC chúng tôi không sử dụng dịch vụ service hay kết nối qua giao thức HTTP mà sử dụng kết nối thông qua giao thức RFB. Việc đồng bộ hóa giữa các tiến trình của nhiều client là do hệ điều hành đảm nhận. Mỗi một phiên kết nối giữa VncServer và VncClient được chạy trên một tiến trình, chính vì thế mà phần mềm BKec chạy tương đối ổn định với số lượng kết nối dưới 40 máy. Sau đây là một số kết quả mà chúng tôi đã cài đặt: Trong phần mềm BKeC chức năng chia sẽ màn hình là một trong những chức năng chính của phần mềm. Trong hình 4.11 chúng ta có thể thấy được được giao diện chính của BKeC-Server và chức năng chia sẻ màn hình. Giáo viên có thể chia sẽ màn hình của mình cho cả lớp, nhóm hay một học viên nào đó trong lớp, tùy theo lựa chọn thông qua chức năng Show. Đồng thời giáo viên có thể theo dõi và điều khiển máy học viên thông qua chức năng View Student’screen. Và giáo viên sử dụng chức năng Select Student’screen khi muốn chọn một màn hình của học viên để trình diễn cho cả lớp. Hình 4.11 Giao diện và chức năng chia sẻ màn hình trong phần mềm BKeC Bên phía BKeC-Client chúng tôi không cài đặt các giao diện điều khiển như BKeC-Server, mà thực hiện gọi hàm trong thư viện BkVncClient.dll. Chúng ta có thể thấy được kết quả chia sẻ màn hình trong hình 4.12 sau đây: Hình 4.12 Minh họa kết quả chia sẻ màn hình trong BKeC Việc truyền phần dữ liệu màn hình thay đổi đã mang lại kết quả đáng kể. Chúng ta có thể nhận ra trên hình 4.12 một bên là màn hình ban đầu và một bên là màn hình sau khi truyền đi và hiển thị. Hình 4.13 Kiểm soát màn hình học viên trong BKeC Một điểm khác biệt giữa hệ thống Vnc với các hệ thống sử dụng công nghệ thin-client khác là hệ thống Vnc không phải là hệ thống hỗ trợ đa người dùng. Như đã nói ở trên thì Vnc không có cơ chế điều khiển phiên mà phụ thuộc vào hệ điều hành. Để hệ thống chạy tốt hơn, trong quá trình xây dựng phần mềm BKeC chúng tôi đã phải cài đặt các tham số tùy theo cấu hình của mạng và số lượng máy kết nối. Chúng ta có thể thấy các tham số mà chúng tôi sử dụng trên BkeC-VncServer và BkeC-VncClient trong hai hình 4.14 và 4.15 sau đây: Hình 4.14 Các tham số lựa chọn trên BkeC-VncServer Các tham số lựa chọn trên BkeC-VncClient là các kiểu mã hóa (ZRLE, Hextile và Raw), các tham số độ sâu của màu (8, 16, hight, true colour) và các tham số về màn hình và các đầu vào khác. Hình 4.15 Các tham số lựa chọn trên BkeC-VncClient ĐÁNH GIÁ VÀ HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI Nhận xét chung Trong suốt quá trình nghiên cứu đề tài, tôi đã thu được rất nhiều kiến thức bổ ích cho mình, từ sự tiến hóa của mô hình client/server, khái niệm thin client cho đến các công nghệ thin client và cơ chế bắt thông điệp Windows API Hooking, cơ chế này giúp chúng ta hiểu sâu hơn nữa về hệ điều hành windows lâu nay chúng ta đang sử dụng, tính bảo mật trong windows NT và xây dựng nên những chương trình thú vị. Và đặc biệt là nghiên cứu về hệ thống VNC, ngoài việc tìm hiểu công nghệ, nghiên cứu này còn là một trong những yếy tố quan trọng để xây dựng nên phần mềm hỗ trợ giảng dạy BKeC. Tuy nhiên trong quá trình nghiên cứu và sử dụng chúng tôi chưa có cải tiến quan trọng nào từ mã nguồn mở của Vnc. Hướng phát triển của đề tài và phần mềm BKeC Với chiến lược là giảm giá thành triển khai công nghệ thin client tỏ ra rất linh hoạt và có khả năng phát triển rất nhanh. Trong xu thế đó, với tính dụng mạnh mẽ của hệ Vnc mà chúng ta đã phân tích trong chương 4, thì chúng ta hoàn toàn có thể xây dựng nhhiều ứng dụng không chỉ trong học tập, kinh doanh và còn hơn thế nữa. Nếu như trong hệ thống Vnc có thể tích hợp về âm thanh, dữ liệu multimedia và tích hợp thêm nhiều thiết bị khác thì chúng ta có thể xây dựng nên nhiều ứng dụng trên phạm vi rộng lớn của đời sống xã hội và tận dụng tối đa tài nguyên mạng. Hơn nữa, từ phân tích trong chương ba chúng ta hoàn toàn có thể cải tiến mô hình kết nối VncServer/VncClient sang mô hình VncServer/Proxy/VncClient. Việc cài đặt một proxy sẽ giúp cho việc đồng bộ hóa tốt hơn, có thể hỗ trợ đa người dùng. Trong tương lai, chúng ta có thể cải tiến phần mềm BKeC không chỉ giới hạn trong mạng LAN, INTRANET mà chúng ta hoàn toàn có thể triển khai ứng dụng trên mạng INTERNET. Khi đó giáo viên không nhất thiết là phải đến lớp mà có thể giảng bài tại bất kì nơi nào có cài đặt mạng INTERNET. Từ mô hình tất cả học viên phải kết nối vào máy giáo viên chuyển sang mô hình cả học viên và giáo viên đều kết nối với một máy server với giao diện dành cho giáo viên và học viên khác nhau. Mô hình này không những tạo điều kiện thuận lợi cho giáo viên mà cùng một lúc có thể tổ chức nhiều lớp học. Khi đó server không những đóng vai trò là cầu nối giữa thầy và trò mà còn là nơi lưu trữ cơ sở sữ liệu cần thiết cho môi trường học tập hiện đại. Trong quá trình nghiên cứu do kiến thức có hạn và thời gian hạn hẹp chắc chắn không thể không thể tránh khỏi những sai sót. Rất mong có được sự đóng góp ý kiến của các Thày, Cô và các bạn cùng những người quan tâm đến vấn đề này để đề tài có thể được hoàn thiện hơn và có ích cho thực tiễn. Cuối cùng thay cho lời kết luận, một lần nữa em xin trân thành cảm ơn Thày giáo Ths.Lương Mạnh Bá cùng các Thày, Cô trong trong bộ môn công nghệ phần mềm khoa Công nghệ thông tin trường Đại học Bách Khoa Hà Nội đã cho em những ý kiến, bài học vô cùng quý báu, hơn nữa là những kinh nghiệm trên con đường sự nghiệp của mình. TÀI LIỆU THAM KHẢO [1] Nguyễn Thúc Hải - Mạng máy tính và các hệ thống mở - 1999 [2] Đặng Văn Đức - Phân tích thiết kế hướng đối tượng bằng UML - 2002 [3] Mike Stock of Zurich, Switzerland - Technologies for Thin Client Architectures - Master Thesis in Computer Science – 2001 [4] Brian Madden - Thin Client Server Computing – 1999 [5] Sheng Feng Li, Mark Spiteri, John Bates, Andy Hopper - Capturing and ndexing Computer-based Activities With Virtual Network Computing. [6] Tristan Richardson (RealVNC Ltd) - The RFB Protocol – 2004 [7] Tristan Richardson, Quentin Stafford-Fraser, Kenneth R.Wood and Andy Hopper - Virtual Network Computing IEEE Internet Computing, Vol. 2 No. 1, Jan./Feb. 1998 [8] Sheng Feng Li - Integrating Synchronous and Asynchronous Collaboration With Virtual Network Computing. [9] Sheng Feng Li - Application of stateless client system in collaborative enterprise. [10] Bài báoHuỳnh Quyết Thắng-Vũ Thanh Hùng- Xây dựng phần mềm quản lý phòng thí nghiệm V-Class. [11] Minneman, S., et. al., “A Confederation of Tools for Capturing and Accessing Collaborative Activity”, ACM Multimedia’95, Page 523-534, November 1995. [12]. Kyle Marsh – MSDN - Win32 Hooks & Application [13]. Andrew S.Tanenbaum – Prentice Hall - Computer Networks [14] - CodeGuru API Hooking Revealed.htm [15]. [16]. [17] Nhóm CKTT-BKeC, tài liệu phần mềm hỗ trợ giảng dạy BKeC.