Đồ án Mô hình Middleware và ứng dụng vào Virtual Network Computing

thông tin của người dùng và hệ thống. Một kỹ thuật là sự dụng đối tượng phân tán. Các thao tác chính tác động đến đối tượng phân tán chính là việc đưa vào thành phần thứ ba vào mô hình tiered client/server. Trong mô hình 3 phần, thành phần đầu tiên giới thiệu tập các icons mà người dùng có thể thao tác, thành phần cuối là cơ sở hạ tầng hardware/software, và là thành phần mở rộng cung cấp trong phần trung gian thông minh cần thiết để chuyển đổi đối tượng phần trình diễn và các thao tác vào đối tượng có sự thỏa thuận theo cơ sở dữ liệu vật lý, ứng dụng thừa kế, và giao thức vận chuyển mạng. Cách hiểu này giống như sự phiên dịch giữa các yêu cầu trừu tượng và các thao tác mức thấp để hoàn thành các yêu cầu chuyển giao và đối tượng chuyển giao. Lâp trình hướng đối tượng (Object-Oriented Programming) Lập trình hướng đối tượng là tập các kỹ thuật lập trình nhằm giải quyết độ phức tạp của hệ thống phần mềm. Một vài kỹ thuật lập trình đã trở nên cũ trong việc phát triển phần mềm. Một số khác lại gần với các kỹ thuật đóng gói theo cách mà hệ thống có thể thúc đẩy, hơn là có sự tin cậy vào chính nó theo một phần của toàn đội phát triển phần mềm.Những định nghĩa cơ bản của lập trình hướng đối tượng là: Đối tượng là gói của mã nguồn và trạng thái. Đối tượng được giới thiệu theo định nghĩa thể hiện của chúng và không phải là công việc bên trong (một định nghĩa thường được sử dụng đó là đóng gói). Đối tượng riêng biệt là một thể hiện của lớp. Thông điệp (yêu cầu hoặc thao tác), là cơ chế theo bởi một client đòi hỏi một đối tượng làm một việc gì đó. Phương thức, là đoạn mã thực tế thực thi các thao tác hay hàm mà đối tượng triệu gọi (phương thức chỉ được hiểu theo việc phát triển thực thi mã nguồn). Thừa kế, nhờ đó một đối tượng có thể sử dụng giao diện thừa kế và mã thực thi của đối tượng khác. Thừa kế là một các chung nhất để xây dựng một đối tượng tập hợp mới. Trừu tượng, nhờ tính chất này mà các nhà phát triển bảo vệ người dùng khỏi các thông tin không liên quan đến công việc đang thực hiện. Đa hình, đa hình có thể nhìn như một thao tác nguyên thủy. Ví dụ, người dùng có thể yêu cầu một điều gì đó để hiển thị và phụ thuộc vào trạng thái tự nhiên của nó (nhu là bitmap, file PostScript hoặc đối tượng đồ họa metalfile). Lợi ích của Brokering và OO Programming Hai kỹ thuật trên giải quyết vấn đề truy cập từ một số ứng dụng, dịch vụ hoặc một phần thông tin trong môi trường bảo mật, phân tán, mở rộng và không đồng nhất. Kỹ thuật này cũng rất tiện dụng khi truy cập dữ liệu. Nó đưa ra một mô hình mới cho sự các ứng dụng và dịch vụ phân tán và phân phối, nó có thể thực hiện các cộng việc sau: Xử lý dữ liệu, chương trình, máy chủ, desktop, máy in và các điểm truy cập mạng như một đối tượng. Những đối tượng này có khả năng và thuộc tính khác nhau nhưng có cùng cách quản lý cơ sở hạ tầng và theo dõi sự trong suốt. Tạo cơ hội cho việc sử dụng lại các modules phần mềm trong khi cho việc thiết kế sự phức tạp. Đòi hỏi tối thiểu kinh nghiệm lập trình để tạo hoặc thiết kế ứng dụng. Các lập trình viên, người có thể hiểu các vấn đề lập trình là và tại sao một giải pháp có thể bao gồm việc khởi tạo đối tượng mà không cần một nhà khoa học máy tính phiên dịch chúng vào ứng dụng. Cho phép một ứng dụng trở thành một chuỗi liên kết giữa các đối tượng, theo đó với vai trò điều khiển luồng các đối tượng. Tự các ứng dụng trở thành các đối tượng và là cơ sở cho các ứng dụng trong tương lai. Ngăn chặn các ứng dụng khỏi các truy cập không hợp pháp trong tương lai. Các ứng dụng thừa kế có thể mang vào trong một kiến trúc hạ tầng sử dụng kỹ thuật đóng gói đối tượng giao dịch (object brokering). Cho phép cở sở hạ tầng và ứng dụng tự động thích ứng với một hệ thống mới và các tiến trình thay đổi hay tạo mới. Cho phép một ngành thương mại cùng với khả năng phát triển và phân phối các môdul phần mềm độc lập và không đồng bộ. Mô hình COM giải quyết vấn đề này. Lợi ích của COM COM cho phép các ứng dụng dựa trên đối tượng và các platform khác nhau có thể hợp tác và giao tiếp trong các hoạt động trên diện rộng và có thể triển khai quản lý các phiên một cách đồng bộ. COM là một chuẩn trên thực tế hoặc một qui định mang đến các lợi ích sau: COM là một chuẩn nhị nguyên, nó là ngôn ngữ trung gian, rất nhanh cho các hoạt động cục bộ, và cho phép phần mềm triển khai không cần đến mã nguồn của chúng. COM phân biệt rõ ràng giao diện từ các lớp, đó là một nhận định quan trọng khi sử dụng các ngôn ngữ khác nhau và các platforms khác nhau. Theo cách đó với cùng giao diện cần phải được định nghĩa theo các ngôn ngữ khác nhau ở các vị trí khác nhau, giống như là các thực thi của đối tượng, các thực thi của client, hoặc tất cả chúng. Một số mô hình đối tượng khác tạo sự dễ dàng nhưng không đúng đắn trong việc kết hợp các giao diện và lớp các đối tượng. COM có thể hoạt động cùng một số các đối tượng từ các nhà cung cấp khác nhau. Tất cả các đối tượng COM đều có một tập chuẩn của thể hiện hoặc giao diện, bao gồm giao diện “IUnknown”, nó cho phép một đối tượng có thể truy vấn đến nó từ các giao diện khác. Nhưng đúng hơn là thừa kế theo nghĩa truyền thống, COM cho phép các tập hợp các đối tượng, trong đó mỗi đối tượng theo khái niệm đều nằm trong một đối tượng khác, nó đối lập với thể hiện của thừa kế từ mã nguồn. Tập hợp chỉ giải quyết được một vài vấn đề của sự thay đổi giao diện và đưa ra một vài điểm mới. Một số các các điểm đó của thừa kế có thể được thêm vào trong mô hình COM. Một khía cạnh quan trọng của tụ hợp là cho phép bảo quản các giao diện cũ khi một đối tượng mới được cung cấp. Theo cách đó, các nhà phát triển có thể nâng cấp phần mềm đối tượng nhằm cung cấp một giao diện và chức năng mới trong khi giao diện từ phiên bản cũ vấn tiếp tục được sử dụng. CHƯƠNG III: VIRTUAL NEWORK COMPUTING 3.1. Giới thiệu chung 3.1.1. Virtual Network Computing Công nghệ VNC thúc đẩy mô hình tính toán thin-client hướng tới việc thực hiện toàn bộ ứng dụng ở phía server. Không có những thay đổi đối với một vài hệ thống cửa sổ, VNC biến nó thành các phần client/server cụ thể là VNC server, VNC client và giao thức VNC để kết nối hai phần đó. VNC server thực hiện tất cả các ứng dụng và đưa ra theo dạng “frame buffer”. VNC client hiển thị “frame buffer” và chấp nhận các đầu vào của người dùng. Còn giao thức VNC định nghĩa một cơ chế cho phép truyền những sự thay đổi của frame buffer từ server đến client, và các đầu vào của người sử dụng từ client đến server. Hình 3.1 thể hiện VNC client (có thể hiểu là VNC Viewer) chạy trên các máy khác nhau (Window, Linux, Solaris) Hình 3.1: VNC Viewer trên các máy khác nhau VNC client gửi các thông điệp sau tới server: Frame buffer update request: thông báo cho server biết client đã sẵn sàng nhận và hiển thị “frame buffer update” tiếp theo. Server trả lời thông điệp này bằng cách gửi một thông điệp “frame buffer update”. Key event chỉ ra một phím được nhấn hay thả khi client nhận các đầu vào từ người dùng. Pointer event: chỉ ra sự di chuyển của con trỏ hoặc một phím con trỏ nhấn hay nhả khi client nhận các đầu vào chuột của người dùng. VNC server gửi các thông điệp sau tới client: Frame buffer update trả lời các thông điệp frame buffer update request từ client. Nó bao gồm một chuỗi các hình chữ nhật, mỗi một frame là một vùng chữ nhật của frame buffer. Đồng thời, những hình chữ nhật này đè lên những vùng có sự thay đổi từ lần cập nhật trước. Mỗi một vùng chữ nhật được định danh duy nhất theo hệ tọa độ x, y tính từ góc trái cao nhất của màn hình và theo chiều dài và rộng của chúng. Hình chữ nhật cũng được đặc tả theo cách mã hóa các dữ liệu theo pixel. Trong trường hợp mã hóa thô (nghĩa là không dùng bất kỳ kiểu mã hóa nào) thì nó sẽ đưa ra một danh sách các giá trị của pixel theo trật tự scan-line (tính từ trái sang phải và từ trên xuống dưới). Giao thức VNC đơn giản là giao thức được sử dụng trong Citrix Systems [11] theo định nghĩa của Independent Computing Architecture (ICA), trong T.128 (có thể hiểu là T.SHARE) giao thức chia sẻ ứng dụng trong NetMeeting [7], và giao thức nguyên thủy sử dụng trong kiến trúc Sun Ray Hot Desk. Giao thức VNC đã có những thay đổi trở thành một nền độc lập, có thể chia sẻ với các ứng dụng X-Windows chạy trên nền Windows-NT, và các ứng dụng Windows chạy trên nền Unix. 3.1.2. Kiến trúc và chức năng của hệ thống Server và client VNC giao tiếp với nhau thông qua kết nối socket. Kiến trúc được mở rộng bằng việc đặt giữa hai thành phần một proxy cho phép chặn và sử lý luồng thông điệp. Proxy trộn tất cả các thông điệp từ các client và chuyển chúng tới server giống như là từ một client, trong khi đó về mặt còn lại, nó sẽ gửi multicast thông điệp từ server tới tất cả các client và cho phép các client có thể dùng chung server một cách đồng thời. Mô hình Client/Server đã đượ mở rộng trở thành kênh giao tiếp Many-to-One multi Client/Server, như vậy thì tất cả các Client đều nhận các thông điệp như nhau tại cùng một thời điểm mặc dù ở trên các phiên làm việc (Session) khác nhau. Thông điệp giữa client và server được định danh và lưu trữ và nó có thể được truyền lại với cùng một tỉ lệ giống như được ghi lại. Proxy giám sát các hoạt động của chúng. Nó cung cấp một cơ chế định vị (coordination mechanism) thông qua các dịch vụ sau: Register: dịch vụ này cho phép các client và server tự đăng ký theo Module Table sau khi kết nối với proxy. Proxy giữ lại tất cả các thông tin đó và đơn giản là gửi chúng cho tất cả các client. Nghĩa là trong một phiên làm việc của server khi mà các user ở tình trạng nghỉ ngơi, nếu có sự thay đổi thì nó sẽ thông báo cho tất cả các client. Remove: dịch vụ này cho phép các client và server tự mình xóa bỏ khỏi Module Table trước khi ngừng kết nối với proxy. Route: Dịch vụ này cho phép các client và server có thể gửi thông điệp cho nhau. Proxy duy trì một Route Table để đặc tả các nguồn và đích của thông điệp. Record: cho phép các client và server ghi lại các thông điệp gửi cho chúng. Quá trình ghi được thực hiện bởi proxy và được lưu trong các log files. Request: dịch vụ này cho phép các client yêu cầu floor. Sau khi một VNC client có được floor, proxy chỉ việc định hướng các sự kiện người dùng đến từ các client khác và cập nhật hệ thống supervision mode, ví dụ chỉ các client giám sát mới có thể thực hiện các phiên làm việc chung, trong khi phần còn lại của hệ collaborative clients chỉ có thể quan sát phiên làm việc. Release: Cho phép các client giải phóng floor. Khi VNC client giải phóng floor, hệ thống trở lại trạng thái thông thường và collaborative clients có thể dùng chung khung nhìn và điều khiển các phiên làm việc từ xa. Reconnect: dịch vụ này cho phép các client có thể chuyển tới một VNC server mới. Khi dịch vụ này được gọi, proxy sẽ đóng kết nối với VNC server hiện thời và kết nối lại tới một server mới. Collaborative clients có thể quyết định server nó muốn kết nối và tự động chuyển đến các server tương tự và không tương tự trong một phiên làm việc chung. Report: Dịch vụ này đưa ra các báo cáo của thông điệp giữa client và server. Hệ VNC Reviewer của chúng ta đọc chúng từ log file và trả lời các hoạt động captured nhờ bộ điều khiển VCR-like tương tự như việc phát lại một đoạn băng. Reviewer cũng cung cấp các trình duyệt và tìm kiếm khác nhau cho người dùng. Trong phần tiếp theo em sẽ trình bày sơ qua về công nghệ sử dụng chính trong hệ thống tính toán mạng ảo. 3.2. Thin – Client 3.2.1. Giới thiệu chung Nhiều sản phẩm tính toán mạng ngày nay đều dựa trên cái mà người ta gọi “thin-clients”. Ngoài ra trên thực tế thì “thin-client” cũng đã được sử dụng trọng cả các sản phẩn phần cứng và phần mềm. Ví dụ về các sản phẩn phần cứng là một thiết bị đầu cuối kiểu windows-based như WBT, NetPCs, NC và các máy PC để bàn truyền thống với giá rẻ được định cấu hình kiểu thin clients. Các sản phẩn phần mềm bao gồm trình duyệt Web, phần mềm mô phỏng đầu cuối và các máy hay thiết bị hiển thị. Trong các tài liệu khoa học, vấn đề “thin client” thường được đề cập tới các thiết bị thin client. Và chúng được đưa ra cùng một quan niệm không đúng khi cho rằng các ứng dụng thin client là chiến lược trung tâm hóa (device-centric). Trong thực tế phầm cứng dường như đóng vai trò thứ yếu trong thị trường thin client GartnerGroup dự đoán rằng gần 85% ứng dụng thin client desktops được triển khai trên các doanh nghiệp trong năm 2004, chúng sẽ được cấu hình theo kiểu thin clients, không quá 15% sẽ được cấu hình theo các thiết bị thin client. Theo tự điển kĩ thuật trên mạng (FOLDOC-Free Online Dictionary of Computing), thì thin client được định nghĩa như sau: “Thin clients là một chươmg trình client đơn giản hay thiết bị phần cứng được dựa trên hầu hết các chức năng của hệ thống mà bắt nguồn từ server.” Một triển vọng tiếp cận việc định nghĩa thin clients được nhìn nhận trên các ứng dụng hay các quan điểm kiến trúc ứng dụng trước khi nghiên cứu một các tỉ mỉ về các thành phần phần cứng hay phần mềm có cấu trúc kiểu thin client. Các kiến trúc client/server được mô tả bởi cách trình diễn, tầng ứng dụng và tầng dữ liệu của ứng dụng thì được thực hiện trên các lớp có sẵn. Kiến trúc client/server đa lớp bao gồm một lớp client, một hoặc nhiều lớp trung gian và một lớp phụ. Lớp client thì chịu trách nhiệm cho lôgic hiển thị của ứng dụng được cung cấp bởi người dùng với giao diện người dùng đồ họa (GUI-graphical user interface) và quản lý các thiết bị đầu vào như bàm phím, chuột. Lôgic ứng dụng bao gồm một tập các chức năng xử lý dữ liệu. Tốt hơn là nó có thể thay thế các lớp trung gian nhưng có thể thực hiện một phần trên lớp client. Các lớp phụ thường tập trung vào quản lý dữ liệu thuần túy. Định nghĩa khái niệm thin clients được đặc câu hỏi, nó là gì trong trình diễn ứng dụng, lôgic dữ liệu và ứng dụng thì được thực hiện trên lớp client. Từ quan điểm này, thin clients có thể được mô tả như các client, như phần cứng phần mềm mà chỉ dành cho các thao tác trình diễn và không phải giải quyết một vài ứng dụng hay lôgic dữ liệu. Thật là khó khăn để có thể định nghĩa chính xác về thin clients, chúng ta có thể nói định nghĩa theo khía cạnh công nghệ và trong ứng dụng: Thin clients là một chương trình client đơn giản và/hoặc thiết bị phần cứng mà tạo ra lôgic trình diễn chính và dựa trên hầu hết lôgic ứng dụng và dữ liệu trên server. 3.2.2. Kiến trúc của Thin-Client Để đưa ra tổng quan về kiến trúc này, chúng ta sẽ miêu tả ngắn gọn về các ứng dụng thin client ẩn dưới một cơ sở hạ tầng công nghệ thông tin. Lôgic trình diễn Lôgic ứng dụng Lôgic Hiển thị và trình diễn Dịch vụ Hệ điều hành Phần cứng Máy UI Hệ điều hành Phần cứng Ứng dụng Cơ sở hạ tầng IT Thin clients Fat server Mạng Hình 3.2: Kiến trúc thin client Chúng ta có thể nhìn thấy bên trái của hình 3.2 là mô hình thin client. Phần cứng của nó như một máy PC bao gồm CPU, RAM, giao diện mạng (network interface), thiết bị hiển thị và các thiết bị đầu vào như bàn phím và chuột. Các thiết bị lưu trữ của thin client có một đặc điểm chung là có dung lượng bộ nhớ không lớn, thường là được lưu trữ trên server. Trong phạm vi của phần cứng thì hệ điều hành có kích thước nhỏ và có thể bảo vệ phần mềm ứng dụng từ phần cứng mức thấp. Cuối cùng, một máy giao diện người dùng (UI) thì có nhiệm vụ quản lí giao diện người dùng đồ họa và đầu vào người dùng. Máy UI là một phần của ứng dụng chạy trên hệ điều hành. Mạng được phân loại (sóng radio, có dây, không dây,…) sự tương kết client và server. Mạng mang dữ liệu tương hợp với các giao thức đã định trước giống như trong kiến trúc khác của mô hình client/server. Chúng ta có thể thấy bên phải của hình 3.2 là fast server. Nó thay thế hầu hết các chức năng ứng dụng và dữ liệu thì được xác định trên nó. Để có thể gửi đi các dịch vụ này thì server đã được trang bị một bộ xử lí có tốc độ cao và bộ nhớ RAM lớn, có thể đủ cho việc lưu trữ dữ liệu và phần mềm chạy để có thể gửi các dịch vụ tới các thin clients của nó. Ví dụ về phần mềm web servers, các server ứng dụng hay đầu cuối. 3.3. Giao thức RFB (Remote Frame Buffer) Giao thức này là giao thức quan trọng nhất, nắm giữ toàn bộ xử lý trọng hệ thống tính toán mạng ảo (VNC). Nó xử lý tất cả các chức năng chính như về thông điệp, hình ảnh, sự kiện cũng như các chức năng phụ như nén ảnh. 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 hình 3.3 dưới đây. Hình 3.3: 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: 3.3.1. 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 dài 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 (security) 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 bộ đệm khung 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 ó 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) 3.3.2. 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. Server 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 raw nếu không được chỉ ra. 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 yêu cầu Server rằng Client quan tâm tới vùng bộ đệm khung 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 bộ đệm khung mà nó quan tâm. Và thông thường thì Server chỉ cần gửi phần thay đổi trên bộ đệm khung 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 thả. 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. 3.3.3. Thông điệp Server gửi Client FramebufferUpdate Cập nhật bộ đệm khung 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 3.3.4 Các mã hóa trong giao thức RFB-Encodings Mã hóa 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 bộ đệm khung. 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 bộ đệm khung 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 3.3.4. 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 bộ đệm khung. 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. CHƯƠNG IV: MIDDLEWARE VÀ VIRTUAL NETWORK COMPUTING Trong hai chương trước của đồ án em đã trình bày về một cách chi tiết về mô hình middleware và hệ thống VNC. Chúng đã thấy rõ vai trò quan trọng của middleware trong việc xây dựng các ứng dụng trong môi trường phân tán, cũng như vai trò của hệ VNC trong các ứng dụng giám sát và làm việc từ xa. Ở chương này em xin đi vào phân tích kĩ hơn về hệ thống VNC về các module cũng như khối kiến trúc của hệ thống. Phần cuối của chương là chương trình ứng dụng sử dụng mô hình middleware, hệ VNC mà em tham gia xây dựng. Tuy nhiên chương trình này mới hoạt động trên mạng LAN và thực sự chưa sử dụng middleware một cách hiệu quả nhất, nhưng em hi vọng trong thời gian tới em sẽ nhận được những đóng góp quí báu của quí thầy cô để tiếp tục nghiên cứu và phát triển đề tài một cách hoàn thiện và có tính ứng dụng cao. 4.1. Hệ thống VNC Như chúng ta đã biệt hệ thống VNC chia thành 2 phần rõ rệt chúng ta có thể hiểu được đó là VNC Server và VNC Viewer. Chúng ta có thể thấy mô hình chung như sau: VNC Server VNC Client VNC Client Mạng Hình 4.1: Mô hình chung của ứng dụng VNC Trong đó: VNC Server: chạy trên máy cục bộ, có thể chạy trên các hệ điều hành khác nhau và các môi trường khác nhau. Các hệ điều hành bao gồm: Windows NT, Windows XP, Macintosh, Linux… Môi trường: môi trường Windows, môi trường Linux,… VNC Client: chạy trên máy cục bộ, từ trên trình duyệt hay ở ứng dụng. Các phiên bản hỗ trợ chạy trên các hệ điều hành và các mạng khác nhau. Mạng: hệ thống cho phép sử dụng trên mạng LAN, WAN, Internet,… Một phiên làm việc của hệ thống VNC có thể được mô tả như hình 4.2. Nhìn trên mô hình ta thấy rằng phiên làm việc bắt đầu bằng việc tạo kết nối giữa client và server. Sau khi kết nối được tạo ra, chúng ta có thể thay đổi cách cấu hình cho phiên làm việc hay sử dụng cấu hình mặc định. Tiếp theo đó là vòng lặp hiển thị màn hình của server, nhận các sự kiện chuột hay bàn phím, cập nhật sự thay đổi. Cuối cùng là chấm dứt kết nối, có thể hủy kết nối từ client hay server. Hình 4.2: Biểu đồ diễn tiến của một phiên làm việc. Sau đây em xin đi vào phân tích một cách chi tiết các khối chức năng chính của hệ VNC sử dụng trong Windows để thấy rõ các dịch vụ cũng như tính chất của middleware tương ứng. Trong đồ án này em chỉ xin đi vào phân tích về các chức năng của hệ thống thông qua chương trình được cung cấp miễn phí của tổ chức. 4.1.1. VNC Server Như chúng ta đã biết công nghệ sử dụng chính trong VNC là công nghệ thin-client, công nghệ tập chung tất cả các chức năng trên server. Server nắm giữ quyền điều khiển đối với hầu hết các chức năng chính. VNC SERVER Kết nối Điều khiển Chia sẻ tài nguyên Hình 4.3: Biểu đồ chức năng của VNC Server Chúng ta có thể chia các chức năng thành ba khối chức năng chính đó là: Khối chức năng điều khiển. Khối chức năng kết nối. Khối chức năng chia sẻ tài nguyên. a. Khối chức năng kết nối bao gồm các các chức năng sau + Kết nối thông qua các kiểu kết nối khác nhau: TCP/IP, UDP, SOCKET,… + Kết nối từ các môi trường khác nhau: LAN, WAN, Internet. Ta có thể quan sát qua các mô hình sau: VNC Server chạy trên một máy Window, Linux hoặc Solaris cho phép bất kỳ một Client nào chạy trên các máy khác nhau trong mạng có thể kết nối được với nhau một cách dễ dàng. Trên mô hình này giao diện truyền thông cung cấp các dịch vụ kết nối các loại mạng khác nhau, không phụ thuộc vào phần cứng cũng như hệ điều hành chạy trên các máy VNC client. Gói Network đảm nhận công việc này. Gói này gồm các lớp sau: Connection Filter: kiểm tra các socket kết nối. Socket: quản lý toàn bộ các quá trình kết nối qua socket. SocketListener: Tạo các socket đợi. TcpFilter. TcpListener. TcpSocket: ba lớp này cài đặt việc kết nối sử dụng TCP/IP. VNC Server VNC Viewer VNC Viewer Communication Interface Hình 4.4: Mô hình giao tiếp trong hệ VNC VNC Server chạy trên một máy Window, Linux hoặc Solaris cho phép bất kỳ một Client nào chạy trên các máy khác nhau trong mạng có thể kết nối được với nhau một cách dễ dàng. Trên mô hình này giao diện truyền thông cung cấp các dịch vụ kết nối các loại mạng khác nhau, không phụ thuộc vào phần cứng cũng như hệ điều hành chạy trên các máy VNC client. Gói Network đảm nhận công việc này. Gói này gồm các lớp sau: Connection Filter: kiểm tra các socket kết nối. Socket: quản lý toàn bộ các quá trình kết nối qua socket. SocketListener: Tạo các socket đợi. TcpFilter. TcpListener. TcpSocket: ba lớp này cài đặt việc kết nối sử dụng TCP/IP. b. Khối chức năng điều khiển + Hỗ trợ đa luồng. + Xử lý thông điệp. + Xử lý phiên. + Quản lý tài nguyên. Khối chức năng điều khiển được cài đặt trong pakage Winvnc. Pakage này thừa kế từ các gói winvnc/VNCServerWin32 và rfb_win32/Service bao gồm các lớp sau: AddNewClientDialog: điều khiển các kết nối tới VNCServer. JavaViewerServer: cài đặt trình duyệt trên Server. ManagerListening: Quản trị các SOCKET đợi. QueryConnectDialog: Truy vấn các kết nối tới VNCServer. StrayIconThread: tạo các Thread cho các Server. VNCServerService: thiết lập các dịch vụ cho VNC Server. VNCServerWin32: Cài đặt các mặc định cho VNC Server trên môi trường Win32. Communication Interface VNC Viewer VNC Server User Inteface Hình 4.5: Mô hình giao tiếp người dùng trong hệ VNC Nhìn trên hình 4.5 thông qua giao diện người dùng, người sử dụng có thể thiết lập các chế độ làm việc của cả Client và Server. Ở đây các thiết lập bao gồm thiết lập về kết nối, giao tiếp, các sự kiện chuột và bàn phím. Nó được cài đặt chủ yếu trong các gói rdr, rfb_Win32, rfb. Các gói trên gồm rất nhiều các lớp ở đây em chỉ xin liệt kê một số lớp chính để thấy rõ các chức năng chính: - Rfb class: CConnection: Toàn bộ các giao tiếp của giao thức cài đặt trong lớp này, nó thừa kế các lớp trong gói Connection. HTTPServer: thừa kế các lớp của Network cho phép giao tiếp trên mạng thông qua HTTP. VNCServer: Cài đặt các mặc định cho VNCServer. c. Khối chức năng chia sẻ tài nguyên + Chia sẻ màn hình. + Chia sẻ chuột, bàn phím, clibboard. -Rfb_Win32: gói này tương tự gói rfb nhưng cung cấp các giao tiếp trên Win32. 4.1.2. VNC Viewer VNC VIEWER Kết nối Hiển thị Điều khiển Hình 4.6: Biểu đồ chức năng của VNC Viewer Chúng ta nhận thấy rất rõ các khối chức năng sau: Kết nối: Tạo các phiên làm việc với VNC server thông qua TCP/IP, SOCKET,… Hiển thị: Cập nhật các thay đổi từ phía VNC Server, thiết lập các chế độ hiển thị về màu sắc, kích thước, các thức nén,…của ảnh hiển thị. Điều khiển: sử dụng trong các sự kiện thông điệp của chuột bàn phím, clipboard. Thực sự thì các cách phân tích trên chỉ là tương đối rất khó để phân tích một cách thật sự phù hợp cho cả hai hệ trên. Ở đây em muốn đưa ra các khối chức năng để đi vào phân tích những tính chất, dịch vụ của middleware đã được xây dựng và những hướng giải quyết tiếp theo để có thể sử dụng VNC thật sự hiểu quả hơn trong các ứng dụng phân tán và quản lý. Chúng ta thấy hệ thống VNC sử dụng các giao diện sau: Giao diện người dùng, giao diện truyền thông: thực sự khi sử dụng hệ thống VNC người dụng có thể dễ dàng sử dụng hệ thống thông qua giao diện trực quan, sử dùng trên các hệ điều hành, các loại máy khác nhau. Chúng ta sẽ thấy rõ qua hình 4.7 dưới đây. Người sử dụng Giao diện người dùng VNC VIEWER Giao diện truyền thông VNC SERVER Hình 4.7: Các giao diện sử dụng trong hệ thống Giao diện lập trình hệ thống: ở đây ta coi VNC là một middleware, thông qua đó ta sẽ xây dựng ứng dụng sử dụng VNC để tạo các ứng dụng quản lý phân tán (sẽ được nói rõ trong phần ứng dụng vào BKEC tiếp theo). 4.2. Middleware trong hệ thống tính toán mạng ảo Phần trên chúng ta đã được thấy rõ các sự tương tác trong hệ thống VNC, sự giao tiếp giữa VNC Server và VNC Viewer. Nếu không có middleware thì ta có thể hình dung các giao tiếp như hình. Các VNC client sẽ kết nối trực tiếp đến VNC Server sau đó để thực hiện các giao tiếp. Như vậy thì mỗi VNC Client đều phải tự mình cài đặt tất cả các kết nối tới VNC Server, nếu có n Client thì chúng ta phải tao n kết nối. Điều này cực kỳ khó khăn nếu các VNC Client chạy trên các platform khác nhau, kết nối từ các mạng khác nhau thì chúng phải tự mình cài đặt các kết nối cần thiết để giao tiếp với VNC Server. VNC Server VNC Client VNC Client Hình 4.8: Giao tiếp trong hệ thống VNC khi không có middleware Qua phân tích trên, thay vì kết nối trực tiếp đến VNC Server, các client sẽ kết nối thông qua một middleware, middleware sẽ có vai trò tạo kết nối và giao tiếp giữa client và server. Nó giúp cho VNC Client không phải lo lắng về vấn đề phần cứng và platform khác nhau. VNC Client chỉ việc tạo kết nối tới middleware, điều này rất dễ dàng vì các middleware đã cung cấp điều này thông qua giao diện lập trình ứng dụng. Nhìn vào hình dưới chúng ta thấy rằng trong hệ thống VNC việc mở rộng kiến trúc client/server truyền thống bằng cách đặt vào giữa hai thành phần đó một proxy server (chính là một middleware) nắm vai trò quan trọng trong việc sử lý thông điệp và kết nối. Như vậy đối với mỗi VNC server, nó là một Proxy Client Module (PCM) đóng vai trò là một VNC client và ngăn chặn các thông điệp frame buffer updat. Và đối với mỗi VNC client, nó lại là Proxy Server Module (PSM) đóng vai trò là một VNC server và ngăn chặn các thông điệp user event. Những thông điệp sẽ được định hướng tới central Cooperation Manager (CM) để xử lý. 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 log files. VNC Server VNC Client VNC Client Middleware CM PSM PSM PCM Log Hình 4.9: Mô hình middleware trong VNC Như vậy toàn bộ khối bao gồm các CM, PCM và Log là một middleware có nhiệm vụ giải quyết toàn bộ các thông điệp từ server đến các client, hay các sự kiện người dùng từ client đến server. Toàn bộ các giao tiếp sẽ được thông qua một middleware, chúng ta sẽ nhìn nhận lại các dịch vụ của hệ thống đễ xem xét các tính chất của middleware được thỏa mãn. Các dịch vụ của middleware bao gồm: Register,remove và record: các dịch vụ cho phép kiểm soát các kết nối trong một bảng do CM nắm giữ, ghi lại các thông điệp gửi đi. Nó thuộc về dịch vụ thông tin. Route, request, release và reconnect: quản lý và xử lý thông điệp thuộc về dịch vụ điều khiển. Qua các dịch vụ nêu trên, chúng ta mới thấy rõ middleware giúp cho các client và server có thể kết nối được với nhau bất kể chạy từ Web, Unix, Windows,… trên mạng LAN hay trên Internet. Middleware cũng giúp cho các client loại bỏ hẳn phụ thuộc vào phần cứng của máy sử dụng. 4.3. Ứng dụng trong chương trình BKEC 4.3.1. Vấn đề và giải pháp của phần mềm hỗ trợ giảng dạy trên mạng LAN (BKEC-ECLASS) Đi vào phần ứng dụng trước hết em xin trình bày về ý tưởng và giải pháp đưa ra của phần mềm hỗ trợ giảng dạy trên mạng LAN (BKEC – Bách Khoa E - Class). Như chúng ta đã biết mô hình dạy học truyền thống ở Việt Nam hiện nay vẫn là dùng bảng và chữ viết, thầy giáo đóng vai trò quan trọng trong toàn bộ quá trình giảng dạy. Nhưng cùng với sự phát triển khoa học công nghệ thì mô hình này dần bộc lộ nhiều yếu điểm nhất là trong các phòng học ngoại ngữ, tin học… Việc một thầy nhiều trò lớp rộng đã làm giảng đáng kể chất lượng của người dạy cũng như người học. Xuất phát từ ý tưởng đó và dưới sự hướng dẫn của thầy Ts. Huỳnh Quyết Thắng, Ths. Đinh Hùng nhóm chúng em gồm 4 thành viên đã xây dựng phần mềm này hỗ trợ tối đa giảng viên và học viên trong lớp học cả về giảng dạy, học tập cũng như quản lý thông qua các giao tiếp bằng âm thanh hình ảnh cũng như đối thoại trực tiếp. Việc giáo viên từ máy chủ có thể toàn quyền quản lý giám sát máy học viên, các hướng dẫn được hiển thị trực quan là một trong những đòi hỏi không thể thiếu được trong một phần mềm hỗ trợ giảng dạy. Phần mềm gồm các chức năng chính sau: + Chức năng chia sẻ màn hình (Desktop Sharing): Chức năng này cho phép giáo viên giám sát tình hình học tập của các học viên, hoặc hiển thị màn hình giáo viên trên tất cả các máy học viên nhằm thực hiện việc giảng dạy trực tiếp ngay trên mạng LAN. + Chức năng truyền multimedia (hình ảnh, âm thanh) tới mọi thành viên trong nhóm, hoặc toàn bộ lớp học theo thời gian thực. Nguồn multimedia có thể từ file, đầu video số, card Tivi và WebCam. + Chức năng giao tiếp (voice chat, chat, Send message và file transfer) giữa giáo viên và học viên. + Chức năng điều khiển từ xa (Remote Control). Cho phép giáo viên khóa máy của học viên (khóa màn hình, khóa bàn phím, khóa chuột). Cho phép giáo viên toàn quyền điều khiển máy học viên trực tiếp trên máy giáo viên. Kiểm soát tiến trình đang chạy trên từng máy học viên. + Chức năng quản trị phòng Lab: Thực hiện phân chia nhóm học viên trong lớp giúp giáo viên dễ dàng quản lý trong quá trình giảng dạy.Các thành viên trong nhóm có thể thảo luận thông qua voice hay text thời gian thực. Giúp giáo viên quản lý được tình hình học tập của học viên từ đó đánh giá được chất lượn giảng dạy và học tập. Dưới đây là biểu đồ phân cấp chức năng của hệ thống: Hình 4.10: Mô hình phần mềm BKEC phân cấp theo chức năng Thông qua biểu đồ trên chúng ta thấy rất rõ phần mềm bao gồm một số lớn các chức năng có hầu hết trong các ứng dụng client/server thông dụng đã được rất nhiều các tổ chức xây dựng. Việc xây dựng hoàn toàn mới và từ ban đầu là điều cực kì khó khăn nếu không muốn nói là không thể đối với nhóm chúng em. Vì vậy giải pháp chọn các sản phẩm có sẵn hỗ trợ các phần mềm là một giải pháp khả quan nhất và giúp tiết kiệm thời gian tiền của cũng như mang đến hiệu quả công việc cao nhất. Trong phần mềm này chúng em sử dụng hai sản phẩm là Direct Play 9.0 của Microsoft và VNC của viện Olivetti & Oracle Research Laboratory. BKEC Client BKEC Client Direct Play 9.0 - Dịch vụ truyền thông (kết nối, quản lý kết nối, chat voice, chat text). - Dịch vụ điều khiển (sử dụng các thành phần khác trong ứng dụng,..) … MIDDLEWARE BKEC Server Hình 4.11: Mô hình middleware sử dụng Direct Play 9.0 Phần mềm sử dụng Direct Play 9.0 thông qua giao diện lập trình, giao diện lập trình hệ thống để xây dựng các chức năng giao tiếp cho client và server. Thực sự Direct Play X còn cung cấp rất nhiều dịch vụ khác, nhưng trong phần mềm BKEC giai đoạn đầu được xây dựng để sử dụng trên mạng LAN nên chưa sử dụng hết các dịch vụ cung cấp. Thông qua Direct Play 9.0, BKEC Server dễ dàng tạo kết nối tới các client thông qua giao tiếp TCP/IP hoặc UDP, quản lý các kết nối, giao tiếp bằng thông điệp, text hoặc tiếng nói. Cung cấp các dịch vụ đa luồng, dịch vụ thông tin để nhận và xử lý thông điệp, các kết nối từ nhiều client, cho phép các client có thể dễ dàng giao tiếp với nhau một cách trực tiếp hoặc gian tiếp qua server. Phần mềm bao gồm hai phần: phần ứng dụng chạy trên máy giáo viên (BKEC – Server) và phần ứng dụng chạy trên máy học viên (BKEC – Client). Trong hệ thống trên lớp quan trọng nhất là SystemServer và SystemClient, hai lớp này kiểm soát toàn bộ hoạt động của hệ thống, chịu trách nhiệm trao đổi thông tin, dữ liệu giữa Server/Client, quản trị cơ sở dữ liệu học viên, nhóm trong lớp học và điều khiển các chức năng của toàn bộ hệ thống. a. Lớp SystemServer Hình 4.12: Biểu đồ lớp quan hệ lớp System Server Hình 4.13: Lớp System Server b. Lớp SystemClient Hình 4.14: Biểu đồ quan hệ lớp SystemClient Tiếp theo hệ thống VNC được sử dụng để xây dựng chức năng chia sẻ màn hình. Chức năng này cho phép giáo viên giám sát tình hình học tập của các học viên, hoặc hiển thị màn hình giáo viên trên tất cả các máy học viên nhằm thực hiện việc giảng dạy trực tiếp ngay trên mạng LAN. Như vậy thông qua VNC chúng ta có thể dễ dàng thực hiện điều này bằng cách sử dụng các dịch vụ của VNC cung cấp (ở đây chủ yếu là dịch vụ truyền thông, thông tin sử dụng các giao diện lập trình ứng dụng, lập trình hệ thống…). Mô hình giao tiếp của VNC trong phần mềm BKEC như hình dưới đây. Trong hệ thống BKEC, 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ữ kiệu pixel. Dữ liệu này sau khi chụp còn ở dạng thô cho 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.15: Mô hình trao đổi thông tin giữa BKEC Server và BKEC Client BKEC Client BKEC Client VNC - Dịch vụ truyền thông (kết nối). - Dịch vụ điều khiển. - Dịch vụ thông tin (truyền dữ liệu, sao lưu, kiểm tra) MIDDLEWARE BKEC Server Hình 4.16: Mô hình middleware sử dụng VNC Trong BKEC chúng em sử dụng VNC vào hai chức năng chính đó là trình diễn bài giảng và kiểm soát màn hình học viên. Chúng em sử dụng VNC để có thể lấy về màn hình học viên quan sát xem các hành động đang diễn ra, chia sẻ màn hình giáo viên trong khi giảng dạy giúp học viên có thể chủ động trong việc học tập. Phần mềm cũng có thể lấy một màn hình để chia sẻ cho một nhóm hoặc cả lớp quan sát. CHƯƠNG V: KẾT LUẬN 5.1. Kết quả đạt được Đề tài với mục đích chính là nghiên cứu một cách tổng quan về mô hình middleware, tìm hiểu các ứng dụng trong thực tế và có thể đưa ra những xu hướng phát triển trong thời gian tới. Trong bản đồ án này, em đã đưa ra được những kiến thức về kiến trúc, ứng dụng và khả năng phát triển của middleware trong các phần mềm phân tán. Qua những kiến thức chung đó em cũng đưa ra về sơ bộ về hệ thống tính toán mạng ảo (giao thức chính và những ứng dụng to lớn của nó trong việc xây dựng phần mềm quản lý desktop trong môi trường phân tán) cũng như những đóng góp của middleware trong đó. Đề tài được xây dựng để đánh giá khả năng của chúng vào những ứng dụng trong thực tế ở Việt Nam khi mà xu hướng phát triển sử dụng mã nguồn mở, xây dựng phần mềm hướng thành phần ngày càng trở nên phổ biến. Giúp cho các nhà phát triển phần mềm những kiến thức chung để tiếp cận những sản phẩm trung gian nhằm lựa chọn các thành phần một cách hợp lý nhất cho các sản phẩm của mình, rút ngắn thời gian xây dựng nâng cao chất lượng sản phẩm. Đồ án còn một số hạn chế là việc ứng dụng middleware vào VNC chưa thật sự hiệu quả, việc cài đặt chương trình mới hạn chế trên mạng LAN. Chưa xây dựng được một middleware mang tính ứng dụng cao. 5.2. Hướng phát triển trong tương lai Tiếp tục nghiên cứu và phát triển ứng dụng theo hai hướng: Xây dựng và hoàn thiện phần mềm BKEC và ứng dụng có hiệu quả hơn các phần mềm trung gian có sẵn (đặc biệt là hệ thống tính toán mạng ảo). Tìm hiểu và có thể đưa ra những phần mềm trung gian với giá cả và chức năng hợp lý đối với nền công nghiệp phần mềm ở nước ta. Trên đây chỉ là những kiến thức tổng quan chúng về phần mềm trung gian, hy vọng trong thời gian tới em có thể đưa ra những nghiên cứu sâu hơn nữa, và có thể tự mình xây dựng được một phần mềm trung gian giúp xây dựng các ứng dụng phân tán trong môi trường mạng LAN nhằm quản lý desktop như họp giao ban trực tuyến, các phiên họp trực tuyến, các mô hình giảng dạy đa chức năng… TÀI LIỆU THAM KHẢO [1] The Middleware Source Book – John Colonna-Romano Patricia Srite. 1998. [2] High-Performance Client/Server - Chris Loosley and Frank Douglas. [3] A Middleware Architecture for Scalable, QoS - Aware and Self-Organizing Global Services-Franz J. Hauck, Erich Meier, Ulrich Becker, Martin Geier, Uwe Rastofer, Martin Steckermeier. 2004 [4] Middleware Architecture Report: “A Middleware Framework for Delivering Business Solutions”. 2004 [5] IRTL (Information Resource Transaction Layer) Middleware Design for P2P and Open GRID Services - Junseok Hwang, Praveen Aravamudham, Elizabeth Liddy, Jeffrey Stanton, and Ian MacInnes School of Information Studies,Syracuse University. 2003 [6] An Open Middleware Architecture for Network-Integrated Multimedia-Marco Lohse, Michael Repplinger, and Philipp Slusallek. 2004 [7] Mike Stock of Zurich, Switzerland - Technologies for Thin Client Architectures - Master Thesis in Computer Science – 2001 [8] Brian Madden - Thin Client Server Computing – 1999 [9] A Middleware Architecture for Transactional, Object-Oriented Applications - Christoph Hartwich - 14. November 2003 [10] The Gridbus Middleware 2004 - [11] IRTL (Information Resource Transaction Layer) Middleware Design for P2P and Open GRID Services, Junseok Hwang, Praveen Aravamudham, Liz Liddy, Jeff Stanton,Ian MacInnes, May 30, 2004 [12] Các tài liệu về CORBA [13] Các tài liệu về hệ tính toán lưới [14] Các trang Web về các tổ chức, công ty phát triển middleware. [15] [16]