Tìm hiểu công nghệ thin client & hệ Virtual NeTrung ươngork Computing

ô hình ứng dụng và đặt biệt là giá thành. Ngày nay kiến trúc client/server càng ngày càng phát triển rất mạnh mẽ trong rất nhiều các ứng dụng, bên cạnh đó sự ra đời của công nghệ thin-client đã đánh dấu một bước ngoặc quan trọng trọng việc kiểm soát tài nguyên mạng hay triển khai các ứng dụng xuất phát từ sự không đồng đều của cơ sở hạ tầng công nghệ thông tin như trong kinh doanh, thương mại hay trong giáo dục. Đồ án tập trung nghiên cứu, tìm hiểu công nghệ thin client và đặc biệt là hệ thống Virtual Network Computing cũng như các giải pháp, kĩ thuật sử dụng, các chuẩn mã hóa và nén dữ liệu. Từ đó xây dựng nên phần mềm hỗ trợ giảng dạy BKeC. Là một phần mềm cài đặt trên mạng LAN, mang tính ứng dụng cao, giá thành thấp hỗ trợ môi trường giảng dạy và học tập ngày càng phát triển ở nước ta. Về bố cục, đồ án được chia làm bốn chương và phần đánh giá, cũng như hướng phát triển của đề tài: Chương I–Các vấn đề thực tiễn, mục tiêu nghiên cứu và ý nghĩa thực tiễn của đồ án. Chương II–Cơ sở lí thuyết về sự tiến hóa của mô hình client/server, khái niệm thin client và cơ chế bắt thông điệp của API windows hook. Chương III–Giới thiệu công nghệ thin client và hệ virtual network computing. Chương IV–Mô hình triển khai ứng dụng hệ virtual network computing trong phần mềm BKeC. Đánh giá và hướng phát triển của đề tài. Em xin gửi lời cám ơn chân thành nhất của mình tới Thày giáo thạc sĩ Lương Mạnh Bá đã hướng dẫn tận tình để em có thể hoàn thành đồ án này. Đồng thời em cũng xin được cám ơn Thày giáo tiến sĩ Huỳnh Quyết Thắng cùng các Thày, Cô 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 vô cùng quý báu. Hà Nội, tháng 05 năm 2005 Sinh viên Trần Xuân Thịnh Lớp Tin pháp k45 MỤC LỤC Trang DANH MỤC CÁC HÌNH VẼ TRONG ĐỒ ÁN Hình 2.1 Minh họa mạng máy tính 11 Hình 2.2 Mô hình TCP/IP 12 Hình 2.3 Khuôn dạng IP 13 Hình 2.4 Khuôn dạng TCP 14 Hình 2.5 Mô hình khái niệm client/server 17 Hình 2.6 Mô hình kiến trúc hai lớp cơ bản 19 Hình 2.7 Mô hình client/server 3 lớp 20 Hình 2.8 Các phạm trù chi phí TCO theo GartnerGroup 22 Hình 2.9 Kiến trúc thin client 24 Hình 2.10 Đăng kí và nhúng hook trong windows 29 Hình 2.12 Layout của một chương trình chạy định dạng PE 32 Hình 2.13 Một chương trình minh họa về snapshot PE 33 Hình 3.1 Mô hình ba thành phần của thin client 37 Hình 3.2 Kiến trúc trình diễn phân tán 38 Hình 3.3 Thông tin giữa ICA client và server 39 Hình 3.4 Giao thức ICA và tầng giao vận 39 Hình 3.5 Sơ đồ kiến trúc X Window 41 Hình 3.6 Kiến trúc TCF 45 Hình 3.7 Mô hình kết nối trên đa hệ điều hành 50 Hình 3.8 Giao thức RFB 50 Hình 3.9 Mô hình giao tiếp Client/proxy/Server 63 Hình 4.1 Mô hình ứng dụng và dịch vụ trong VNC 67 Hình 4.2 Mô hình kết nối trên giao thức RFB và HTTP 68 Hình 4.3 Mô hình kết nối lớp VNCServerST 70 Hình 4.4 Mô hình kết nối và hiển thị trên VNCclient 71 Hình 4.5 Biểu đồ tuần tự phiên kết nối trong hệ thống BKeC-VNC 74 Hình 4.6 Truyền dữ liệu giữa BKeC Server và BKeC Client 75 Hình 4.7 Mô hình chia sẽ màn hình cho nhóm 76 Hình 4.8 Mô hình chia sẽ màn hình cho lớp học 77 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 77 Hình 4.10 Mô hình giao tiếp giữa BKeC Server và BKeC Client 78 Hình 4.11 Giao diện và chức năng chia sẻ màn hình trong phần mềm BKeC 79 Hình 4.12 Minh họa kết quả chia sẻ màn hình trong BKeC 80 Hình 4.13 Kiểm soát màn hình học viên trong BKeC 80 Hình 4.14 Các tham số lựa chọn trên BkeC-VncServer 81 Hình 4.15 Các tham số lựa chọn trên BkeC-VncClient 81 DANH MỤC CÁC BẢNG TRONG ĐỒ ÁN Bảng 2.1 Danh sách các request primitive của TCP 15 Bảng 2.2 Danh sách các response primitive của TCP 16 Bảng 2.3 Sự phân chia phạm trù chi phí TCO Model v4 23 Bảng 2.4 Các phạm trù ứng dụng 25 Bảng 2.5 Các cấu hình phần cứng 26 Bảng 2.6 Operating System Footprint 26 Bảng 2.7 Tài nguyên phần cứng cho hai loại kịch bản 27 Bảng 3.1 Tổng kết công nghệ trình diễn phân tán 43 Bảng 3.2 Browser clients footprints 44 Bảng 3.3 Tổng kết công nghệ trình diễn từ xa 46 DANH MỤC CÁC TỪ VIẾT TẮT TRONG ĐỒ ÁN API application program interface atm Asynchronous Transfer Mode CAD computer aided design CM Cooperation manager COFF Common Object File Format COM Common Object Model DART Digital Asset Retrieval Technology DES Data Encryption Standard DHTML DYNAMIC Hypertext Transfer Protocol DTP desktop publishing FOLDOC Free Online Dictionary of Computing GUI graphical user interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol HTTPS HTTP tunneling secured through SSL ICA Independent Computing Architecture IDE Integrated Drive Electronics IEEE Institute of Electrical and Electronic Engineers IP INTERNET PROTCOL MoCA Movie Content Analysis NLB NETWORK LOAD BALANCING OCR Optical Character Recognition OSI Open Systems Interconnection PCM Proxy Client Module PDA personal digital assistant PE Portable Executable PSM Proxy SERVER Module rdp Remote Desktop Protocol RFB REMOTE FRAME BUFFER RRE Rise and Run Length Encoding SSL Secure Sockets Layer TCF Thin Client Framework TCO total cost of ownership TCP Transmission Control Protocol VNC VIRTUAL NETWORK COMPUTING WWW World WIDE WEB ChƯƠng I MỞ ĐẦU Đặt vấn đề Sự phát triển của mạng máy tính, cũng như sự ra đời của Inernet World Wide Web đã thay đổi rất nhiều cách nghĩ của chúng ta, thay đổi và có ảnh hưởng to lớn đến tất cả các lĩnh vực trong đời sống, kinh tế và xã hội. Hiện nay, vấn đề về truyền thông, ứng dụng mô hình client/server và sự tiến hóa của nó và các dịch vụ mạng rất phát triển, song cũng có một số khó khăn. E-learning (học trên mạng), E-comercial (thương mại điện tử), E-government (chính phủ điện tử) là một môi trường điện tử được hỗ trợ bởi công nghệ máy tính và công nghệ Internet cũng như các ứng dụng Web được xây dựng dựa trên các dịch vụ và cơ sở hạ tầng có sẵn. Các khái niệm này bắt đầu phổ biến vào cuối những năm 90 của thế kỉ trước. Sự không đồng đều của hệ thống cơ sở hạ tầng đã gây ra nhiều hạn chế, nhất là trên các máy trạm hay PC đầu cuối (phía người dùng). Làm việc theo nhóm là một trong những yếu tố hàng đầu mang lại thành công cho các công ty hay tổ chức, đặc biệt là trong ngành Công nghệ thông tin. Nhưng những khó khăn mà họ gặp phải đó là thời gian, bạn thử tưởng tượng xem trong một nhóm mà không sự đồng đều về năng lực giữa các thành viên. Tất cả những kiến thức mà họ học tập trao đổi nhau qua những lời nói, bản ghi chép báo cáo dường như chưa đem lại hiệu quả cao trong công việc. Hãy hình dung, nếu như trên màn hình của bạn xuất hiện vấn đề mà bạn gặp phải và nó đang được giải quyết trực quan bởi người khác nhưng ho ở xa, rõ ràng là hiệu quả hơn tất nhiều so với những gì mà bạn từng nghe hay được đọc. Họ như những người thầy của bạn ở xa vậy. Các vấn đề về truyền thông multimedia, hay hội thảo trực tuyến (video conferencing) luôn là những vấn đề nóng bỏng và có rất nhiều vấn đề rất cần được giải quyết. Trọng tâm của đề tài Khi mà sự gia tăng ứng dụng của máy tính trong các lĩnh vực như đào tạo, kinh doanh hay thương mại…thì những ứng dụng dựa trên mô hình client/server là không thể thiếu được, đặc biệt là những ứng dụng multi client/server. Trọng tâm của đề tài nhằm nghiên cứu sự tiến hóa của kiến trúc client/server, các mô hình ứng dụng, kiến trúc của công nghệ thin client/server và cuối cùng nghiên cứu một trong những ứng dụng tiêu biểu của công nghệ thin client/server là hệ VNC (Virtual Network Computing). Đây là một kết quả nghiên cứu to lớn của viện Olivetti & Oracle Research Laboratory. Hệ thống có thể chia sẽ tài nguyên hệ thống đặc biệt là Desktop (màn hình) và các input (các đầu vào). Và hơn nữa là nghiên cứu này đã giúp chúng tôi xây dựng nên phần mềm hỗ trợ giảng dạy BKeC. Ý nghĩa thực tế của đề tài và những hạn chế Ý nghĩa Vấn đề chia sẽ tài nguyên hệ thống mà đặc biệt là Desktop (màn hình) và các input (các đầu vào) có ý nghĩa quan trọng trong việc phát triển ứng dụng đặc biệt là các ứng dụng triển khai trên mô hình client/server thông qua mạng LAN, INTRANET cũng như INTERNET. Đó cũng là mong muốn đầu tiên khi chúng tôi nghiên cứu trong đề tài này. Những hạn chế Tuy nhiên những hạn chế của đề tài mà tôi cảm thấy nếu khắc phục được thì có thể phát triển ứng dụng rất rộng rãi và có tầm quan trọng trong thực tế. Trên thực tế, hệ thống VNC chưa hỗ trợ nhiều cho multimedia, ví dụ chưa có sự tham gia của âm thanh hay các các thiết bị mở rộng. Trong tương lai chúng tôi rất mong muốn nghiên cứu tiếp và có thể giải quyết một trong những hạn chế này. Phương pháp luận Toàn bộ những nghiên cứu của đồ án này đều tham khảo từ các cuốn sách trong nước cũng như ngoài nước và phần lớn là từ các trang web, các bài báo khoa học được công bố rộng rãi trên mạng và các đồ án khoa học. Điển hình là các nghiên cứu của viện AT&T Laboratories Cambridge, công ty RealVnc và viện kỹ thuật điện và điện tử IEEE (Institute of Electrical and Electronic Engineers) là một tổ chức của nước Mỹ chuyên phát triển nhiều loại tiêu chuẩn, trong đó có các tiêu chuẩn về truyền dữ liệu. Những nghiên cứu này không chỉ là hướng theo lý thuyết đơn thuần mà quan trọng hơn là được dùng để phát triển ứng dụng. CHƯƠNG II CƠ SỞ LÝ THUYẾT Lý thuyết chung về mạng Internet và Intranet Máy tính điện tử đã không còn là một thứ phương tiện quá quý hiếm mà ngày càng trở thành một công cụ làm việc thông dụng của con người. Các cơ quan, doanh nghiệp... ngày nay hầu hết đã trang bị máy tính đặc biệt là các máy PC. Và trong đó đã trang bị máy tính để bàn cho số đông các nhân viên của mình, cho dù chỉ là để soạn thảo văn bản. Mặc dầu khái niệm “văn phòng không giấy” vẫn còn là một thứ “ảo ảnh” (không phải vì trở ngại kỹ thuật), nhưng phải thừa nhận là thông tin được số hoá và lưu trữ trong máy tính ngày càng nhiều hơn, đa dạng hơn. Không những thế, thông tin đó còn được trao đổi qua lại nhờ các mạng máy tính đủ loại được cài đặt ngày càng nhiều hơn, hiện đại hơn. Do nhận thức được vai trò của thông tin trong hoạt động kinh tế thị trường cạnh tranh gay gắt, các tổ chức và doanh nghiệp đều tìm mọi cơ hội và biện pháp để xây dựng và hoàn thiện các hệ thống thông tin nội bộ của mình. Hệ thống này bao gồm một cơ sở hạ tầng truyền thông máy tính và một tập hợp các chương trình ứng dụng nhằm tin học hoá các hoạt động tác nghiệp của đơn vị. Hệ thống thông tin nội bộ đó phải luôn chính xác, tin cậy, hiệu quả, thông suốt và đảm bào an toàn, an ninh trong mọi tình huống. Và đặc biệt là hệ thống phải có khả năng truyền thông với thế giới bên ngoài thông qua mạng toàn cầu Internet khi cần thiết. Hình 2.1 Minh họa mạng máy tính Để đạt được cùng một lúc nhiều mục tiêu như vậy rõ ràng là không thể tùy tiện mua một mạng cục bộ nào đó và cài đặt một cách tùy tiện, cập nhật phần mềm ứng dụng một cách thiếu đồng bộ. Cần phải có sự thiết kế tổng thể mạng thông tin dựa trên các yêu cầu nhiều mặt của đơn vị. Từ đó khái niệm mạng nội bộ (Intranet) xuất hiện một cách chính thức bên cạnh khái niệm liên mạng (Internet) và càng ngày càng thu hút sự quan tâm của cả những người sử dụng lẫn các nhà cung cấp. Song song với việc phát triển các công cụ tiện ích và các dịch vụ thông tin cho Internet, người ta cũng bắt đầu tập trung vào việc lựa chọn các giải pháp cho Intranet. Các sản phẩm “phần mềm tập thể” (Groupware) như Lotus notes, novell Group Wise, Microsoft Exchange, Apple Open Transport,... đều hướng đến mục tiêu Internet nhưng không tương hợp với nhau vì đều dựa trên các chuẩn riêng của hãng cung cấp. Sự hội tụ về một chuẩn chung là một thực tế không thể trốn tránh, đặc biệt là về ngôn ngữ đặc tả các tài liệu điện tử. HTML – với khả năng đặc tả chất lượng cao mà đơn giản nhờ phương tiện “siêu văn bản” - đang trở thành một cái đích hấp dẫn và có tính khả thi. Cùng với nó là giao thức truyền HTTP và ngôn ngữ lập trình trên mạng Java (Sun), và các công cụ phát triển cho Web. Có nghĩa là người ta đang tiến hành một sự “chuyển giao công nghệ” từ Internet sang Intranet. Chính vì vậy có những tài liệu đã không ngần ngại khi định nghĩa Intranet là một mạng dùng riêng cho các yêu cầu hoạt động nội bộ của một đơn vị xã hội, có thể là mạng cục bộ hay mạng diện rộng, trong đó có sử dụng các phần mềm tập thể và các công nghệ cốt lõi của Internet. Họ giao thức TCP/IP TCP/IP thực chất là một họ giao thức cùng làm việc với nhau để cung cấp phương tiện truyền thông liên mạng. Hình 2.2 Mô hình TCP/IP Giao thức liên mạng IP. Mục đích của IP chính là cung cấp khả năng kết nối các mạng con thành liên mạng để truyền dữ liệu. Vai trò của nó tương tự như vai trò của giao thức tầng mạng trong mô hình OSI. Để kết nối các mạng con sử dụng TCP và IP thì tất cả các hệ thống thành viên của liên mạng đòi hỏi đều phải cài đặt IP ở tầng mạng. IP là một giao thức kiều không liên kết, đơn vị dữ liệu của nó được gọi là datagram có khuôn dạng như sau: 0 3 4 7 8 15 16 31 VER THL Type of Service Total Length Identification flags Fragment offset Time to live Protocol Header checksum Source Address Destination Address Options + Padding Data (max: 65.535 bytes) Hình 2.3 Khuôn dạng IP VER (4 bit): chỉ version hiện hành của IP được cài đặt. IHL (4 bit): chỉ độ dài phần header của datagram tính theo đơn vị từ (word=32 bits) với độ dài tối thiểu là 5 từ (20 bytes). Type of service (8 bits): đặc tả các tham số về dịch vụ. Total Length (16 bits): chỉ độ dài toàn bộ datagram (tính theo byte), kể cả phần header. Indentification (16 bits): dùng để định danh duy nhất cho một datagram trong khoảng thời gian nó vẫn còn trên liên mạng. Flag (3 bits): liên quan đến sự phân đoạn (fragment) các datagram. Fragment Offset (13 bits): chỉ vị trí của đoạn ở trong datagram. Time to Live (8 bits): quy định thời gian tồn tại (theo giây) của datagram trong liên mạng. Protocol (8 bits): chỉ giao thức tầng trên kế tiếp sẽ nhận vùng dữ liệu ở trạm đích (thường là TCP hoặc UDP). Header Checksum (16 bits): mã kiểm soát lỗi 16 bits theo phương pháp CRC, chỉ cho vùng header. Source Address (32 bits): địa chỉ của trạm nguồn. Destination Address (32 bits): địa chỉ của trạm đích. Options: khai báo các options do người gửi yêu cầu. Padding: vùng đệm, được dùng để đảm bảo cho phần header luôn kết thúc ở một mốc 32 bits. Data: vùng dữ liệu. Các bước thực hiện bởi một thực thể IP như sau: Đối với thực thể IP ở trạm nguồn, khi nhận được một primitive SEND từ tầng trên, nó thực hiện các bước sau đây: Tạo một IP datagram dựa trên các tham số của primitive SEND. Tính checksum và ghép vào header của datagram. Ra quyết định chọn đường: hoặc là trạm đích nằm trên cùng mạng hoặc là một gateway sẽ được chọn cho chặng tiếp theo. Chuyển datagram xuống tầng dưới để truyền qua mạng. Đối với gateway, khi nhận được một datagram quá cánh, nó sẽ thực hiện các công việc sau: Tính checksum, nếu sai lệch thì loại bỏ datagram. Giảm giá trị của tham số Time-to-Live. Nếu thời gian đã hết thì loại bỏ datagram. Ra quyết định chọn đường. Phân loại datagram nếu cần. Kiến tạo lại IP header, bao gồm giá trị mới của các vùng Time-to-Live, Fragmentation và Checksum. Chuyển datagram xuống tầng dưới để truyền qua mạng. Cuối cùng, khi một datagram được nhận bởi thực thể IP ở trạm đích, nó sẽ thực hiện các công việc sau: Tính checksum, nếu bất cập thì loại bỏ datagram. Tập hợp các đoạn của datagram nếu có phân đoạn. Chuyển dữ liệu và các tham số điều khiển lên tầng trên bằng cách dùng primitive DELIVER. Giao thức điều khiển truyền TCP. TCP là một giao thức kiểu “có liên kết”. Đơn vị dữ liệu sử dụng được gọi là segment (đoạn dữ liệu) có khuôn dạng như sau: 0 15 16 3 1 Source Port Destination Port Sequence Number Acknowledgment Number Data offset Reserved URG ACK PSH RST SYN FIN Windows Checksum Urgent Pointer Options Padding TCP data Hình 2.4 Khuôn dạng TCP Source Port (16 bits): số hiệu cổng của trạm nguồn. Destination Port (16 bits): số hiệu cổng của trạm đích. Sequence Number (32 bits): số hiệu của byte đầu tiên của segment. AckKhôngwledgment Number (32 bits): số hiệu của segment tiếp theo mà trạm nguồn đang chờ để nhận (ngầm ý báo nhận tốt). Data Offset (4 bits): số lượng từ-32 bits (32 bits words) trong TCP header. Resered (6 bits): dùng trong tương lai. Control bits (các bít điều khiển): URG: vùng con trỏ khẩn (Urgent Pointer) có hiệu lực. ACK: vùng báo nhận (ACK number) có hiệu lực.ư PSH: chức năng PUSH RTS: khởi động lại (Reset) liên kết. SYN: đồng bộ hoá các số hiệu tuần tự (sequence number). FIN: không còn dữ liệu từ trạm nguồn. Window (16 bits): cấp phát credit để kiểm soát luồng dữ liệu (theo cơ chế cửa sổ). Checksum (16 bits): mã kiểm soát lỗi cho toàn bộ segment (header + data). Urgent Pointer (16 bits): con trỏ này trỏ tới số hiệu tuần tự của byte đi theo dữ liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn. Options : khai báo các option của TCP, trong đó có độ dài tối đa của vùng TCP data trong một segment. Padding : phần chèn thêm vào header để đảm bảo phần header luôn kết thúc ở một mốc 32 bits (có giá trị toàn là 0). TCP data: chứa dữ liệu của tầng trên, có độ dài tối đa ngầm định là 536 bytes. Cũng giống như ở các giao thức khác, các thực thể ở tầng trên sử dụng TCP thông qua các hàm dịch vụ nguyên thuỷ (service primitive). Request primitives Tên primitive Chức năng Unspecified Passive Open Đón yêu cầu liên kết từ một trạm xa bất kỳ Fully Specified Passive Open Đón yêu cầu liên kết từ trạm đích đã chỉ ra. Active Open Yêu cầu mở liên kết với trạm đích đã chỉ ra. Active Open with Data Yêu cầu mở liên kết với trạm đích đã chỉ ra và truyền dữ liệu kèm theo yêu cầu. Send Truyền dữ liệu qua liên kết có tên được chỉ ra Allocate Tăng thêm độ dài dữ liệu nhận. Close Yêu cầu đóng liên kết một cách bình thường. Abort Yêu cầu đóng liên kết một cách bất bình thường. Status Hỏi trạng thái liên kết. Bảng 2.1 Danh sách các request primitive của TCP Response primitives Tên primitive Chức năng Open ID Báo cho người sử dụng biết tên liên kết được thực hiện cho liên kết được yêu cầu trong một Open primitive. Open Failure Thông báo thiết lập liên kết bị thất bại Open Success Thông báo thiết lập liên kết thành công Deliver Thông báo dữ liệu đến. Closing Thông báo rằng người sử dụng TCP ở xa đã yêu cầu đóng liên kết và tất cả dữ liệu được gửi từ người sử dụng ở xa đó đã được tiếp nhận. Terminate Thông báo rằng liên kết đã kết thúc không còn tồn tại nữa, kèm theo mô tả nguyên nhân của sự kết thúc đó. Status Response Thông báo trạng thái hiện hành của liên kết. Error Thông báo về yêu cầu dịch vụ hoặc lỗi bên trong. Bảng 2.2 Danh sách các response primitive của TCP Sự tiến hóa của kiến trúc client/server Căn bản về mô hình khái niệm client/server Thuật ngữ client/server đã được sử dụng lần đầu tiên vào những năm 1980 cùng với sự phát triển của máy tính và hệ thống mạng. Kiến trúc các phần mềm client/server được đưa vào sử dụng cuối những năm 1980 và tỏ ra rất linh hoạt. Trên Internet, một trình duyệt Web như là một chương trình client gửi những yêu cầu dịch vụ đến Web server thông qua giao thức HTTP từ một máy tính bất kì nơi nào trên thế giới có kết nối Internet. Kiến trúc client/server là một dạng chung trong hệ thống tính toán phân tán gồm rất nhiều máy tính. Khía cạnh phân tán không có vai trò gì đối với người sử dụng bởi vì hệ thống phân tán chỉ xuất hiện trên các máy trạm hay các máy cục bộ mà ở đó người dùng không hình dung được. Trong khi đó, đối với các chuyên gia hay nhà chuyên môn trong lĩnh vực công nghệ thông tin, họ là những người sử dụng có những hiểu biết nhất định thì các khái niệm hệ thống máy tính, sao lưu dữ liệu, cân bằng tải và các chức năng khác không còn tính trong suốt nữa. Một hệ thống phân tán thì luôn gắn với các khái niệm cơ bản sau đây: (1) Một hệ thống tính toán phân tán là một tập hợp ít nhất hai máy tự trị (không cần sự điều khiển của con người). (2) Các máy đều có sự liên hệ với nhau thông qua mạng. (3) Thông tin trao đổi giữa các máy (các thông điệp) thì được chia sẽ. Kiến trúc client/server dựa trên những khái niệm được đề cập trên đây. Nó mô tả giao tiếp giữa các tiến trình tính toán được phân loại theo dịch vụ người dùng hay người cung cấp dịch vụ. Client và server được xây dựng nên từ các mô dun phần mềm hay phần cứng đôi khi là sự tổ hợp của cả hai. Và chúng có thể chạy trên các máy chuyên dụng nếu cần thiết. Mỗi một quan hệ client/server là một thiết lập giữ hai mô đun chức năng khi một mô đun của clien khởi động một yêu cầu dịch vụ và server sẽ chọn lựa để trả lời hay đáp ứng yêu cầu dịch vụ. Ví dụ một yêu cầu dịch vụ là "retrieve customer name", "calculate last year’s net income", v.v... Với các yêu cầu dịch vụ thì vai trò của client/server không đảo ngược. Tuy nhiên, một server có yêu cầu dịch vụ R1 thì có thể trở thành một client cho yêu cầu dịch vụ R2 tới một server khác (xem hình 2.5). Ví dụ, một client có thể gửi yêu cầu dịch mà yêu cầu này có thể tạo ra một yêu cầu dịch vụ khác. Thông tin trao đổi giữa client và server hoàn toàn là các thông điệp. Yêu cầu và bổ sung thông tin dịch vụ thì được chuyển qua server. Các đáp ứng của server nó tương tự như thông điệp khác gửi trở lại client. Đó là một đặc điểm chủ yếu của mô hình client/server. Trao đổi thông điệp là một tương tác cơ bản. Hay nó cách khác mô hình client/server không hỗ trợ một tiến trình yêu cầu ngoại tuyến (off-line). Ở đây có một vài trường hợp ngoại lệ. Ví dụ, hệ thống hàng đợi thông điệp cho phép client lưu trữ thông điệp trên một hàng đợi không đồng bộ hóa với server. Và tất nhiên client và server có thể chạy cùng trên một máy. M1 Client M2 Server Client M3 Server Yêu cầu Đáp ứng Yêu cầu Đáp ứng Yêu cầu dịch vụ R1 Yêu cầu dịch vụ R2 Hình 2.5 Mô hình khái niệm client/server Các ứng dụng sử dụng mô hình client/server chủ yếu dành cho các chức năng hay các hoạt động kinh doanh, giáo dục, …. Mục tiêu của ứng dụng client/server là cung cấp các cơ chế linh hoạt để các tổ chức thiết kế ứng dụng cần thiết. Sự tiến hóa của mô hình kiến trúc client/server Lớp của kiến trúc client/server Các ứng dụng truyền thống được dựa trên chức năng. Một số vấn đề gặp phải trong kinh doanh là các kiến trúc ứng dụng có thể phản ánh một cách đầy đủ phạm vi, các yêu cầu kinh doanh. Để đạt được nó, người ta thường chia thành ba lớp khái niệm sau: (1) Tầng trình diễn (Presentation layer): Tầng này thì chịu trách nhiệm về giao diện người dùng của mỗi ứng dụng. Nó thực thi mô hình chức năng cụ thể của mỗi tổ chức hay công ty nào đó. (2) Tầng ứng dụng (Application layer): Tầng này chịu trách nhiệm về các chức năng kinh doanh của ứng dụng. Nó thực thi các mô hình tiến trình của mỗi tổ chức hay công ty. (3) Tầng dữ liệu (Data layer): Tầng này quản lí dữ liệu kinh doanh. Nó thực thi các mô hình thông tin trong mỗi tổ chức hay công ty. Mỗi một tầng thực thi ứng dụng cụ thể nào đó dựa trên lớp kiến trúc trên máy tính hay máy chuyên dụng. Sự phụ thuộc này là dựa trên số thành phần lớp của mỗi một tiến trình nhiệm vụ. Để phân biệt khái niệm lớp trong kiến trúc client/server người ta đã phát triển từ kiến trúc client/server từ 2, 3 cho đến đa lớp. Kiến trúc client/server hai lớp (two-tiers) Kiến trúc client/server hai lớp dựa trên hình thức bản của hệ tính toán client/server với một lớp là client và lớp kia là server. Bởi vậy, tầng ứng dụng có thể thực hiện trên client hay server, một trong hai kết quả đó đều bắt nguồn từ các kiến trúc này. Hơn nữa các tầng ứng dụng có thể phân tán giữa các lớp chứ không hẳn là các tầng ứng dụng cùng nằm một chỗ, có một vài sự khác nhau giữa năm kiến trúc cơ sở: • Trình diễn phân tán (Distributed Presentation): Mỗi tầng trình diễn của một ứng dụng hầu như được thực hiện trên lớp client. Trong khi đó hầu hết các xử lí là được thực hiện trên lớp server. Client chỉ đơn thuần là thực hiện việc hiển thị ảnh của giao diện người dùng đồ họa (GUI) của ứng dụng và chuyển các tương tác người dùng với giao diện người dùng đồ họa như ấn phím và click chuột tới server. Kiến trúc trình diễn phân tán này cho phép client tham gia một xử lí nhỏ khi client không hiển thị dữ liệu pixel raw. Sự trao đổi lần lượt giữa client và server là rất lớn tùy theo tài nguyên mạng. Một ví dụ về kiến trúc trình diễn phân tán là các thiết bị đầu cuối sử dụng hệ điều hành windows kết nối tới server hay X Window được quản lí trình diễn phân tán của hệ thống UNIX. • Trình diễn từ xa (Remote presentation): Tầng trình diễn được thực hiện trên lớp client. Trong khi đó thì tất cả tầng ứng dụng và tầng dữ liệu thì được thực hiện cho lớp server. Phía client có khả năng quản lí toàn bộ giao diện người dùng. Tương tác người dùng như là sự di chuyển chuột, kéo thả thanh cuộn, v.v..hay việc kiểm tra cú pháp việc nhập dữ liệu thì có thể được xử lí ngay trên client và không cần phải gửi lên server. Hơn nữa, client nắm rõ các thành phần trong giao diện người dùng đồ họa. Nó được cung cấp thông tin bởi server để miêu tả một nút bấm hay một cửa sổ nào đó. Với tài nguyên của mạng nhỏ thì các kết quả này là rất cần thiết. Ví dụ về kiến trúc trình diễn từ xa là một trình duyệt web hiển thị một trang HTML được nạp từ web servers. • Lôgic phân tán (Distributed Logic): Cả client và server đều thực thi một phần của tầng ứng dụng. Tầng trình diễn và tầng dữ liệu thì được thực hiện trên client và server theo thứ tự nhất định. Khi mà lõi của một ứng dụng (chức năng giao dịch kinh doanh) được phân tán giữa client và server, các thành phần của tầng ứng dụng giao tiếp với nhau thông qua các thông điệp. Kiến trúc lôgic phân tán thì rất phức tạp trong khi thực thi và duy trì nó. Hệ thống cơ sở dữ liệu tích cực có thể nắm giữ một phần của lôgic ứng dụng trên các thủ tục lưu trữ và thủ tục hoạt động trong khi lõi của lôgic ứng dụng ở trên client. • Quản lý dữ liệu từ xa (Remote Data Management): Client có thể thực thi cả trên tầng ứng dụng và tầng trình diễn và liên hệ với server để quản lý dữ liệu ứng dụng. Quản lý dữ liệu trung tâm thì không cần quản lý dữ liệu phân tán. Hiện nay các tầng trình diễn và ứng dụng trên tài nguyên client và server trở nên sẵn có. Các máy tính cá nhân ngày nay thì có đủ tài nguyên để có thể điều khiển xử lí các hai tầng trên. • Quản lý dữ liệu phân tán (Distributed Data Management): Quản lý dữ liệu thì được thực hiện trên client và server. Các yêu cầu này để bảo đảm tính nhất quán dữ liệu giữa client và server, tính nhất quán này thường phức tạp trong khi thực thi. Quản lý dữ liệu trung tâm thì có chút ưu tiên nhưng đôi khi sự không tương xứng này làm giảm hiệu năng hoạt động. Sau đây là sơ đồ mô tả năm kiến trúc cơ bản trong mô hình client/server hai lớp: Dữ liệu Dữ liệu Dữ liệu Dữ liệu Dữ liệu Ứng dụng Ứng dụng Ứng dụng Ứng dụng Ứng dụng Ứng dụng Trình diễn Trình diễn Trình diễn Trình diễn Trình diễn Trình diễn Trình diễn Phân tán Trình diễn Từ xa Lôgic Phân tán Quản lý dữ liệu phân tán Quản lý dữ liệu từ xa Dữ liệu Hình 2.6 Mô hình kiến trúc hai lớp cơ bản Ứng dụng client/server được xây dựng dựa theo một vài kiến trúc ở trên, hiện nay, kiến trúc dữ liệu từ xa và kiến trúc trình diễn từ xa/phân tán trở nên phổ biến. Kiến trúc dữ liệu từ xa thì rất phổ biến trong trong các ứng dụng giao dịch kinh doanh và hỗ trợ đắc lực bởi số lượng lớn các nhà cung cấp cơ sở dữ liệu. Bởi vì hầu hết các ứng dụng thì được thực hiện trên lớp client, đôi khi kiến trúc này cũng có liên quan như kiến trúc fat client. Trong khi đó, các kiến trúc trình diễn từ xa trở nên phổ biến cùng với sự phát triển của World Wide Web (WWW). Bởi hầu hết các ứng dụng là thực hiện trên lớp server, đôi khi các kiến trúc này như là kiến trúc thin client (kiến trúc này sẽ nói rõ hơn trong phần tiếp theo). Kiến trúc client/server ba lớp và đa lớp Trong kiến trúc hai lớp, client kết nối trực tiếp tới server mà không qua một server chuyển tiếp (trung gian) nào. Kiến trúc này được sử dụng rất phổ biến trong môi trường công nghệ thông tin nhỏ với một số lượng nhỏ client tham gia. Tuy nhiên, khi số lượng các client tăng lên, server sẽ nhanh chóng trở nên quá tải với các yêu cầu client. Đồng thời, vì nhiều xử lý logic đã được gắn vào các bộ ứng dụng cố định, do đó các thay đổi trong các quy tắc giao dịch sẽ dẫn tới những thay đổi mã nguồn rất đắt đỏ và tốn nhiều thời gian. Bất chấp sự đơn giản và dễ dàng trong việc phát triển các sản phẩm, Mô hình hai lớp (two tier) vẫn tiếp tục quyến rũ các dự án phần mềm thương mại quy mô nhỏ, nhưng nhu cầu đối với việc truy cập dữ liệu nhanh hơn và việc tối thiểu thời gian phát triển ứng dụng và đặc biệt là khả năng cập nhật công nghệ, bổ sung chức năng mới của một ứng dụng đã thuyết phục các chuyên viên thiết kế tìm ra một cách mới trong việc tạo ra các ứng dụng phân tán. Kiến trúc ba lớp đã xuất hhiện vào những năm 1990 vượt lên sự hạn chế của kiến trúc hai lớp. Lớp thứ ba (lớp server trung gian) là giao diện kết nối giữa giao diện người dùng (client) và thành phần quản trị cơ sở dữ liệu (server). Lớp trung gian (middle-tier) có thể thực hiện được một số các chức năng khác nhau như các thông điệp truy vấn, thực hiện ứng dụng, v.v… Và nó còn cho phép số lượng client kết nối lên tới hàng trăm. Kiến trúc được thiết kết cho mô hình client/server phân tán bởi tính linh hoạt, dễ bảo trì và dễ mở rộng. Các ứng dụng client/server ngày nay khác rất nhiều so với tổ tiên của chúng, chúng có một cái tên mới: ứng dụng đa lớp (multitier application) và được biết tới như kiến trúc n lớp (n-tier). Trong mô hình này, việc xử lý được phân tán giữa client và server và các giao dịch lôgic thì được đặt tại một lớp giữa. Phần lớn các hệ thống thực hiện ba công việc chính tương ứng với ba lớp của mô hình n lớp. Database ASP IIS Server Components Client Tier 1 Tier 3 Tier 2 Hình 2.7 Mô hình client/server 3 lớp Giao diện và điều hướng USER: Tier 1-Tầng này bao gồm toàn bộ tương tác với người sử dụng. Nó cung cấp một giao diện đồ họa, qua đó người sử dụng có thể tư._.ơng tác với ứng dụng, nhập dữ liệu, xem kết quả của yêu cầu, đồng thời nó cũng quản lý việc thao tác và định dạng dữ liệu mà client tiếp nhận. Trong các ứng dụng Web, trình duyệt thi hành các tác vụ của tầng này. Giao dịch logic: Tier 2 nằm giữa tầng giao diện và tầng các dịch vụ dữ liệu, đây chính là khu vực làm việc của các chuyên viên thiết kế ứng dụng phân tán. Giao dịch logic nắm giữ các quy tắc quản trị việc xử lý ứng dụng, liên kết với người sử dụng tại một đầu và với dữ liệu ở đầu kia. Các dịch vụ dữ liệu: Tier 3: các dịch vụ dữ liệu được cung cấp bởi kho dữ liệu có cấu trúc (SQL, Oracle database) hoặc phi cấu trúc (Microsoft Exchange, Microsoft Message Quering), chúng quản lý và cung cấp các dịch vụ truy cập tới dữ liệu ứng dụng. Một ứng dụng đơn có thể dung nạp các dịch vụ của một hoặc nhiều kho dữ liệu. Kiến trúc ba lớp phân tách mỗi mảng chức năng lớn để việc trình bày được độc lập với các quy tắc xử lý và giao dịch logic, tóm lại là độc lập với dữ liệu. Mô hình này đòi hỏi việc phân tích và thiết kế nhiều hơn nhưng đổi lại nó làm giảm chi phí bảo trì và tăng tính linh hoạt trong một thời gian dài. Giới thiệu về thin clients Khái niệm thin clients Nhiều sản phẩm tính toán mạng ngày nay đều dựa trên công nghệ mà người ta gọi “thin-clients”. Ngoài ra, trên thực tế thì “thin-client” đã được sử dụng rộng rãi trong 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ẩm 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 như là 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à trung tâm hóa về thiết bị (device-centric). Trong thực tế phần 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ương 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ách 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 đượ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. Thật là khó khăn để có thể định nghĩa chính xác về thin clients, chúng ta chỉ có thể đị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. Thin clients và TCO (Total Cost of Ownership) Việc phân tích tổng chi phí sở hữu để triển khai dự án (Total Cost of Ownership) đã được giới thiệu vào năm 1987 bởi GartnerGroup và kể từ khi nó được chấp nhận và phát triển sang nhiều phương pháp luận khác nhau bởi các công ty tư vấn tin học. GartnerGroup phân tích tổng hợp trong hầu hết các trường hợp về sự liên kết chi phí với cơ sở hạ tầng công nghệ thông tin của các công ty chỉ là chi phí tài chính của các đăng kí cấp phép phần cứng và phần mềm. Việc ra đời của khái niệm thin client cùng với TCO đã giúp cho cách doanh nghiệp các công ty trong ngành công nghệ thông tin tối ưu hóa về mặt chi phí trong triển khai ứng dụng, đặc biệt là các ứng dụng lớn trên mạng mà có nhiều người dùng, có cơ sở hạ tầng không đồng đều. Để hỗ trợ các tổ chức, công ty xác nhận tất cả những thay đổi liên quan tới chi phí của hệ thống công nghệ thông tin, chi phí trực tiếp và gián tiếp được chia thành các phạm trù cơ bản về chi phí. GartnerGroup xác định có năm phạm trù cơ bản về chi phí: Vốn, quản lý và hoạt động (chi phí trực tiếp), thời gian thực hiện và hoạt động của người sử dụng (chi phí gián tiếp). Hoạt động người dùng Vốn Thời gian thực hiện Quản lý 35% 25% 11% 19% 10% Các hoạt động Các hoạt động Hình 2.8 Các phạm trù chi phí TCO theo GartnerGroup Khái niệm về chi phí trực tiếp và gián tiếp chúng ta có thể thấy rõ hơn trong bảng phân loại sau đây: Chí phí trực tiếp Vốn • Phần cứng • Phần mềm 19% Các thao táchoạt động • Hỗ trợ công nghệ • Kế hoạch và quản lý tiến trình • Quản lý cơ sở dữ liệu • Các dịch vụ 25% Quản trị • Quản trị tài chính • Đào tạo đội ngũ công nghệ thông tin • Đào tạo người dùng 10% Chi phí gián tiếp Hoạt động người dùng • Đào tạo chính qui • Đào tạo không chính qui • Hỗ trợ một phần và trực tiếp • Quản lý dữ liệu • Phát triển phần mềm • v.v… 35% Thời gian thực hiện • Có kế hoạch • Không có kế hoạch 11% Bảng 2.3 Sự phân chia phạm trù chi phí TCO Model v4 Tiêu chuẩn cho các kiến trúc đa lớp thin client Với sự ra đời của máy tính cá nhân PC, sự chuyển từ các kiến trúc máy tính lớn (mainframe) sang kiến trúc phân tán (chia sẻ file) và sau đó là sự phát triển của các kiến trúc client/server. Trong quá trình đó, thì các máy trạm (host) đã sớm sử dụng thin clients, dần dần thay thế các máy tính cá nhân để bàn chạy trên nền Windows của Microsoft, MacOS và một số hệ điều hành giao diện người dùng đồ họa (GUI) khác. Tổng quan về kiến trúc 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 2.9 Kiến trúc thin client Chúng ta có thể nhìn thấy bên trái của hình 2.9 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. Phương tiện giao diện người dùng (UI engine) 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 2.9 là fat server. Nó thay thế hầu hết các chức năng ứng dụng và dữ liệu xác định. Để 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. Để có thể nắm rõ hơn về các thành phần chi tiết của kiến trúc thin client chúng ta sẽ nghiên cứu kĩ trong các phần sau. Ứng dụng kiến trúc thin client Trong kiến trúc thin client, client kết nối vào hầu hết các chức năng trên hệ thống trên server. Chức năng của client là có nhiệm vụ hiển thị với sự tối thiểu về lôgic ứng dụng trên nó với hiệu năng chấp nhận được và xác định sự cần thiết của ứng dụng thin client đáp ứng các nhiệm vụ trình diễn. Trong vấn đề giao dịch kinh doanh ngày ngay có nhiều loại ứng dụng khác nhau. Không phải tất cả các ứng dụng đều thích hợp trong môi trường thin client. Phạm vi các ứng dụng từ dữ liệu đơn giản đầu vào trên hệ thống đầu cuối cho tới việc thiết kế các máy tính trợ giúp phức tạp (CAD-computer aided design) trên các máy trạm hiệu năng cao. Thậm chí với một giao dịch kinh doanh đã có một số ứng dụng khác nhau. Ví dụ trong ngành kinh doanh ngân hàng các máy xử lý văn bản, thư điện tử và trình duyệt web là những công cụ được sử dụng rộng rãi. Ngoài ra trong ngành kế toán và quản lý tài chính chủ yếu thao tác với dữ liệu đơn giản. Sự đối lập trong ngành phần mềm sử dụng các máy trạm lớn dùng làm môi trường phát triển phần mềm. Cho dù các ứng dụng có thích hợp với môi trường thin client hay không, thì lôgic trình diễn của ứng dụng vẫn có thể được phân tách từ các lôgic ứng dụng nói chung. Lôgic trình diễn ứng dụng có nhiệm vụ hiển thị dữ liệu tới người dùng và cho phép họ điều khiển thao tác dữ liệu. Sự phức tạp của hiển thị dữ liệu tới người dùng và sự phức tạp của tính sẵn có giao diện người dùng đồ họa (GUI) tới ứng dụng để cho phép chỉnh sửa dữ liệu trở nên chuẩn hóa. Chúng ta sẽ xem các phạm trù ứng dụng trên môi trường client, sự phức tạp về dữ liệu và GUI: Kiểu ứng dụng Ví dụ Phức tạp về dữ liệu Phức tạp về GUI PIM (quản lý thông tin cá nhân) Thư điện tử, lịch làm việc Thấp Trung bình Truy cập Web Trình duyệt Trung bình Trung bình Các sản phẩm văn phòng Word, power point Trung bình Cao Phát triển phần mềm Môi trường IDE, biên dịch, gỡ rối, kiểm thử. Cao Cao Các giao dịch Các ứng dụng dựa trên các thiết bị đầu cuối Trung bình Thấp Các ứng dụng ngân hàng các ứng dụng kế toán và thương mại Trung bình Trung bình Các ứng dụng Desktop Các ứng dụng DTP và thao tác với hình ảnh Cao Cao Bảng 2.4 Các phạm trù ứng dụng Thin client Một thin client bao gồm phần cứng, hệ điều hành, và máy giao diện người dùng (UI engine). Chúng ta sẽ so sánh giữa fat client và thin client. Phần cứng Hầu hết các xử lý ứng dụng là trên server, các yêu cầu phần cứng, tốc độ và bộ nhớ ít hơn so với fat client. Bảng dưới đây so sánh cấu hình phần cứng của một cấu hình phổ biến WBT và hai chuẩn máy tính Credit Suisse Financial Services. WBT Q3/2001 Standard PC CSFS Q2/19982 Standard PC CSFS Q3/2001 Vi xử lý PII / 166 MHz PII / 266 MHz PIII / 1 GHz Bộ nhớ trong 32 MB RAM 64 MB RAM 256 MB RAM Bộ nhớ ngoài 16 MB Flash 3.5 GB HD 20 GB HD CD-ROM / Floppy Không /không 24x/có 48x/có Màn hình 1024x786 @16bit 1280x1024 @16bit 1280x1024 @16bit Cạc mạng 10/100 Mbit Ether 10/100 Mbit Ether 10/100 Mbit Ether Công suất tiêu thụ 45 Watt 283 Watt 100 Watt Bảng 2.5 Các cấu hình phần cứng Hệ điều hành Khách quan mà nói hệ điều hành của thin client thì khác nhiều so với fat client. Ngoài việc hỗ trợ các thiết bị đầu vào và hiển thị, thì phần lớn mục đích của nó là cung cấp các kết nối mạng và chạy trên phương tiện giao diện người dùng (UI engine) dành cho các thao tác hiển thị và trình diển. Hệ điều hành có thể hỗ trợ các thay đổi của giao thức trình diễn/hiển thị của mạng để có thể kết nối và thực hiện theo các ứng dụng trên các server. Sau đây là một số yêu cầu về phần cứng giữa hệ điều hành thin client và hệ điều hành fat cliene truyền thống. Bảng 2.6 Operating System Footprint Phương tiện giao diện người dùng (UI engine) Phương tiện giao diện người dùng là một thành phần trung tâm của thin client. Nó được thiết kế cả trên server hiển thị và trình diễn. Server hiển thị thì đơn thuần là hiển thị đồ họa đầu ra của ứng dụng (tức là vẽ dữ liệu pixel) và cho người dùng để vẽ lại đầu vào của ứng dụng. Server trình diễn trong quản lí đối lập và hiển thị điều khiển giao diện người dùng như là sự nắm giữ các đầu vào trên thin client. Công nghệ server hiển thị thì dựa trên trình diễn phân tán, trong khi đó server trình diễn thì dựa trên trình diễn từ xa. Fat server Phần cứng và hệ điều hành Hệ điều hành và phần cứng server thì không chỉ khác với server mà còn khác với cả fat client. Tính toán thin client chiếm hầu hết các lôgic ứng dụng. Ngoài ra các tài nguyên trên server thì rất cần thiết để thực thi ứng dụng và toàn bộ tài nguyên phần cứng là cần thiết có các tính toán thin client trên server. Bảng 2.7 Tài nguyên phần cứng cho hai loại kịch bản Kiến trúc thin client có rất ít các yêu cầu về bộ nhớ. Cùng với sự dịch chuyển các lôgic ứng dụng sang server trung tâm, một phần lôgic ứng dụng có thể chia sẻ cho nhiều nguời dùng. Các dịch vụ Điều khiển phiên và đồng bộ hóa Ứng dụng chạy trên fat server phải hỗ trợ đa người dùng (multi-user). Ứng dụng Fat client chạy trên môi trường độc lập. Chúng được truy cập bởi người dùng đơn lẻ tại các thời điểm. Trong khi đó các ứng dụng thin client được truy nhập đồng thời bởi một số người dùng. Trong kiến trúc thin client, một người dùng kết nối tới ứng dụng trên server từ xa. Miêu tả một phiên kết nối giữa client và ứng dụng trên server là trong vòng một khung thời gian. Một ứng dụng thin client có thể gửi dịch vụ của nó tới một số người dùng khác. Một người dùng truy cập ứng dụng phải được phép của đối tượng truy cập. Cơ chế thực thi các chức năng này được đề cập đến như là việc điều khiển phiên. Đồng bộ hóa cũng là một mối quan tâm lớn trong ứng dụng thin client. Một ví dụ minh họa là một số ứng dụng fat client cho phép cấu hình bởi người dùng. Các cấu hình này thường được lưu trữ trong một file hay Windows registry. Có những cách tiếp cận về vấn đề điều khiển phiên và đông bộ hóa: • Hệ điều hành bảo vệ mỗi người dùng một cách tốt nhất. Nó sẽ cung cấp một mẫu riêng cho mỗi một ứng dụng hay yêu cầu dịch vụ. Cách tiếp cận này sẽ làm bớt đi sự khó khăn trong triển khai và phát triển ứng dụng. Người lập trình ứng dụng không quan tâm tới điều khiển phiên và đồng bộ hóa bởi vì hệ điều hành vận dụng tối đa các vấn đề này. • Khung làm việc trên ứng dụng client được dựa trên điều khiển phiên và đồng bộ hóa. Đây là những cách tiếp cận rất thuận lợi từ quan điểm phát triển như quan tâm tới xử lý tài nguyên hệ điều hành như file hay Windows registry. Tính sẵn sàng cao So sánh với kiến trúc truyền thống fat client/server, thì kiến trúc thin client/server phụ thuộc hoàn toàn vào server. Các fat client thì hoạt động độc lập với server. Thậm chí ngay cả khi server bị hỏng, mà ứng dụng fat vẫn có thể chạy trên máy người dùng mặc dù bị hạn chế về chức năng. Ngược lại thì thin client không thể thực hiện ứng dụng nếu như server không tồn tại hay hỏng bởi vì thin clients phụ thuộc vào server. Để đảm bảo về tình sẵn sàng cao, chúng ta cần hiểu rõ hơn về các khái niệm như sự dư thừa (redundancy) và tính chịu lỗi (failover). Thu nhận các thông điệp hoạt động trên máy tính Cơ chế bắt thông điệp trên Window API –Hooking Giới thiệu Thuật ngữ Hooking nói đến một kỹ thuật cơ bản của việc điều khiển những phần mã lệnh thích hợp để thực hiện các chức năng nào đó của người lập trình. Nó cung cấp cho ta một cơ cấu không phức tạp mà giúp ta dễ dàng thay đổi cách thao tác của hệ điều hành như các sản phẩm của các công ty thứ ba, mà không cần thiết phải có mã nguồn trong tay. Nhiều hệ thống hiện đại gây sự chú ý vào năng lực của họ để lợi dụng những ứng dụng Windows có sẵn bằng cách dùng kỹ thuật theo dõi. Một động lực cho việc hooking không chỉ góp phần nâng cao tính năng của chương trình mà còn trợ giúp trong chương trình gỡ rối nữa. Không giống các hệ điều hành như DOS và Windows 3.xx, hệ điều hành Windows hiện nay như NT/2K và 9x cung cấp cơ cấu xuyên qua (sophisticated) để chia các không gian địa chỉ cho mỗi tiến trình. Kiến trúc này đưa ra một cách bảo vệ bộ nhớ thực, vì thế sẽ không có ứng dụng nào có thể chen vào không gian địa chỉ của các tiến trình khác hay trong trường hợp tệ hơn là làm treo luôn hệ điều hành. Điều này gây ra nhiều khó khăn cho các nhà phát triển hệ thống như hook. Sau đây là các giải pháp làm thế nào để tạo ra một tập các hàm hooking Win32 API trên NT/2K cũng như là trên 98/Me của dòng hệ điều hành Windows. Việc giám sát của ứng dụng cung cấp cho ta một số lợi ích: a/Theo dõi chức năng của các hàm API Khả năng điểu khiển các hàm API là một cách có ích lớn nhất và giúp cho ta theo dõi những hoạt động “ẩn” mà xuất hiện trong suốt quá trình gọi API. Nó góp phần tìm ra các tham số hợp lệ cũng như thông báo các vấn đề phía sau. b/Sự gỡ rối và và kĩ thuật đảo ngược Bên cạnh các phương pháp chuẩn cho việc gỡ rối, API Hooking trở thành một cơ chế gỡ rối thông dụng nhất. Nhiều nhà phát triển dùng kỹ thuật API Hooking để nhận dạng các thành phần được cài đặt và các mối quan hệ giữa chúng. Chặn API là một cách mạnh mẽ của việc lấy thông tin cần thiết. c/Sự ngang hàng bên trong hệ điều hành Nhiều nhà phát triển thích tìm hiểu sâu hơn về hệ điều hành và thích thú trong vai trò là một “chương trình gỡ rối”. Hooking cũng cung cấp một kỹ thuật cho việc khám phá ra những việc không được công bố hay biết thêm nhiều hơn về các hàm API. d/Sự mở rộng chức năng Bằng cách nhúng mô đun của mình vào bên trong các ứng dụng mở rộng của Windows, rồi gửi đi các mã lệnh thực hiện thông thường bằng cách chèn thông điệp hook có thể cung cấp một cách dễ dàng để thay đổi và mở rộng các chức năng môdun đã có. Hệ thống mở rộng Windows Hooks Việc nhúng thư viện liên kết động (dynamic link library) vào tiến trình đích dựa trên Windows Hooks. Đó là bẫy trong cơ chế điều khiển thông điệp hệ thống. Một ứng dụng có thể cài đặt các chức năng để theo dõi sự trao đổi thông điệp trong hệ thống và tiến trình trước khi các thông điệp được xử lý bởi các thủ thục window. Thông thường hook được thực thi trong một trật tự cơ bản của hệ thống mở rộng hooks. Mỗi một hook sau khi cài đặt có một không gian địa chỉ được gọi khi cần thiết. Việc cài đặt hook thông qua việc gọi SetWindowsHookEx() với những tham số thích hợp khi đó hệ điều hành sẽ ánh xạ không gian địa chỉ trong mỗi tiến trình. Sơ đồ dưới đây thể hiện sự đăng kí hook bởi Hook Server nhúng sang không gian địa chỉ với tên là "Application one" và "Application two". Hình 2.10 Đăng kí và nhúng hook trong windows Hệ thống mở rộng hook được đăng kí một lần khi gọi hàm SetWindowsHookEx(). Nếu không lỗi sẽ trả về một thẻ hook có giá trị. Giá trị trả về này là yêu cầu cuối cùng của chức năng hook của người lập trình khi gọi CallNextHookEx(). Sau khi thành công trong việc gọi SetWindowsHookEx(), hệ điều hành sẽ tự động nhúng thư viện liên kết động (dynamic link library) vào trong tất cả các tiến trình cần thiết . Hệ thống mở rộng hook được nạp bởi đa tiến trình không chia sẽ cùng không gian địa chỉ. Ví dụ một thẻ điều khiển hook sg_hGetMsgHook, bao gồm SetWindowsHookEx() và được sử dụng như tham số trong CallNextHookEx() thì cần phải sử dụng địa chỉ ảo trong tất cả không gian địa chỉ. Mỗi một hook thư viện liên kết động (dynamic link library) được nạp vào trong không gian địa chỉ của tiến trình đích, không giống như cách gỡ hook thư viện liên kết động (dynamic link library) trừ khi Hook Server gọi hàm UnhookWindowsHookEx() hay thoát khỏi ứng dụng. Khi Hook Server gọi UnhookWindowsHookEx() thì hệ điều hành sẽ kiểm tra tất cả các tiển trình đã nạp hook DLL. Hệ điều hành sẽ giảm số đếm chốt (lock) của thư viện liên kết động (dynamic link library) trở về 0, thư viện liên kết động (dynamic link library) thì tự động bỏ ánh xạ từ không gian địa chỉ của tiến trình. Cơ chế chặn thông điệp Việc nhúng thư viện liên kết động (dynamic link library) vào không gian địa chỉ của một tiến trình mở rộng là một yếu tố chính của hệ thống giám sát. Nó cung cấp một thời điểm thích hợp để điều khiển các hoạt động trên đoạn tiến trình. Tuy nhiên, muốn chặn các hàm API được gọi trong tiến trình, việc nhúng thư viện liên kết động (dynamic link library) là chưa đủ. Về mức độ mà hook được áp dụng, có hai cơ chế để giám sát các hàm API, giám sát mức nhân hệ điều hành (Kernel level) và mức người lập trình (User level). Để hiểu rõ hơn về hai mức này cần phải nắm rõ mối quan hệ giữa Win32 subsystem API và Native API. Sau đây là hình minh họa các hook khác nhau trong các quan hệ môđun và sự phụ thuộc của chúng trong Windows 2K . Hình 2.11 Mối quan hệ của hook và sự phụ thuộc trong Win2k Phần lớn các thi hành này khác nhau là do cách thức chặn thông điệp. Đối với mức nhân thì hooking ràng buộc với kernel-mode driver, trong khi đó thì mức người lập trình thì hooking thường xuyên sử dụng user-mode DLL. a/Hooking mức nhân hệ điều hành NT Những phương pháp để có thể hooking trên dịch vụ hệ thống WinNT là ở trong mô hình mức nhân hệ thống. Đó là cơ chế chặn thông điệp phổ biến nhất theo chứng minh của Mark Russinovich và Bryce Cogswell. Ý tưởng cơ bản của họ là nhúng một cơ chế chặn để theo dõi hệ thống NT mà được gọi từ những người lập trình. Công nghệ này rất mạnh mẽ và cung cấp một cách vô cùng linh hoạt cho việc hooking điểm mà tất cả user-mode có thể thâm nhập trước khi phục vụ cho nhân hệ điều hành. b/Hooking mức người lập trình trong Win32 Sự phân lớp Window (Windowssubclassing.) Đây là phương pháp thíc hợp cho những tình huống mà việc chạy ứng dụng có thể bị thay đổi bởi các thực thi mới trong thủ tục window. Để hoàn thành một nhiệm vụ đơn giản là gọi SetWindowLongPtr() với tham số là GWLP_WNDPROC. Một khi một thủ tục mới của chúng ta được khởi tạo, thì mỗi khi Windows phát đi những thông điệp cụ thể, nó sẽ kiểm tra địa chỉ của thủ tục window liên kết với một window cụ thể và gọi thủ tục của chúng ta thay vì gọi lại. Trở ngại của cơ chế này là với mỗi việc phân lớp thì tồn tại trong vòng ranh giới của tiến trình cụ thể. Hay nói cách khác môt ứng dụng có thể không phân lớp một lớp window được tạo ra bởi một tiến trình khác. Thông thường thì cách tiếp cận này có thể sử dụng được khi chúng ta cần sử dụng hook trong một ứng dụng thông qua add-in (tức là thêm các thư viện thành phần In-Proc COM) Proxy DLL (Trojan DLL) Một cách dễ dàng cho việc tận dụng hiệu quả hàm API là thay thế thư viện liên kết động (dynamic link library) bởi một thư viện cùng tên và sử dụng các hàm như là trong thư viện gốc. Công nghệ này có thể dễ dàng thực thi sử dụng các function forwarder. Function forwarder đơn giản là đầu vào trong các thư viện liên kết động ủy quyển cho các hàm của thư viện liên kết động khác được thay thế. Ghi chồng mã lệnh (Code overwriting) Có nhiều phương pháp ghi chồng mã lệnh. Một trong số đó là địa chỉ của hàm thì sử dụng bởi lệnh CALL. Cách này thì có vẻ khó và hay bị lỗi. Ý tưởng cơ bản thu được là theo dõi các lệnh được gọi trong bộ nhớ và thay thế địa chỉ của hàm ban đầu bằng một hàm bổ sung của người lập trình. Một phương thức khác cũng khá phức tạp. Trong cách tiếp cận tới địa chỉ cục bộ của hàm API ban đầu và thay đổi một vài byte đầu tiên của hàm đó với cách dùng lệnh JMP rồi trực tiếp gọi hàm bổ sung của người lập trình. Cách này thì rất “gian” và gọi trình tự phục hồi và hoạt động hooking cho mỗi gọi hàm riêng. Giám sát bởi chương trình gỡ rối (debugger) Một sự thay thế để hooking các hàm API là đặt một điểm ngắt gỡ rối sang hàm đích. Tuy nhiên có vài trở ngại, là phần lớn các tiếp cận này là những trường hợp gỡ rối này làm treo tất cả các tuyến ứng dụng. Nó đòi hỏi một người lập trình gỡ rối phải xử lý các trường hợp ngoại lệ. Một vấn đề khác nữa là trong thực tế chương trình gỡ rối kết thúc, sẽ tự động ngừng hoạt động bởi Windows. Sự giám sát bởi sự thay đổi của bảng địa chỉ đầu vào (Import Address Table) Công nghệ này đã được công bố đầu tiên bởi Matt Pietrek và nghiên cứu công phu của Jeffrey Ritcher (trong cuốn "API Hooking by Manipulating a Module's Import Section") và John Robbins (trong cuốn "Hooking Imported Functions"). Nó rất mạnh mẽ, đơn giản và hoàn toàn dễ thực thi. Và hầu hết các yêu cầu về hooking là dành cho hệ điều hành Windows NT/2K/9x. Khái niệm về công nghệ này dựa trên cấu trúc đơn giản của định dạng file của Portable Executable (PE) Windows. Để có thể hiểu hơn nữa về cách thực hiện của phương pháp này, chúng ta nên biết rõ những khái niệm cơ bản đằng sau định dạng file trong PE, là sự mở rộng của định dạng file của đối tượng phổ biến (COFF-Common Object File Format). Nói chung file nhị phân PE thì được tổ chức gồm tất cả cả mã lệnh và phân khu dữ liệu trong một layout phù hợp sự hiển thị của bộ nhớ ảo của chương trình chạy (executable). Định dạng PE được tạo ra từ một số phần lôgic. Mỗi phần nắm giữ một kiểu xác định của dữ liệu và địa chỉ cần thiết để hệ điều hành nạp phù hợp với định dạng PE được mô tả sau đây. Hình 2.12 Layout của một chương trình chạy định dạng PE Chương trình nạp sẽ thực hiện việc nạp một ứng dụng cùng với tất cả các thư viện liên kết động sang bộ nhớ. Khi địa chỉ của mỗi thư viện liên kết động (dynamic link library) được nạp vào trong bộ nhớ, thì không thể biết trước được, không thể xác định được địa chỉ thực sự của mỗi hàm. Việc nạp này cần phải thực hiện một số công việc mở rộng để chắc rằng chương trình sẽ gọi thành công các hàm. Nhưng hãy nhìn rõ các chương trình chạy trong bộ nhớ và cố định địa chỉ của tất cả các hàm được nạp, chúng được nạp lần lượt mà không hợp lý về thời gian xử lý và vì sự giảm thực thi. Sau đây là một ví dụ về cấu trúc file snapshot PE của ứng dụng Win32 đơn giản trong chương trình TestApp.exe. Hình 2.13 Một chương trình minh họa về snapshot PE Các yêu cầu của hệ thống công cụ Hook Nhằm cung cấp cho người dùng hệ thống hooking để giám sát các hàm Win32 API theo tên. Cung cấp khả năng nhúng hook driver vào trong tất cả tiến trình chạy bởi Windows hooks như gọi hàm API-CreateRemoteThread() API. Và khung làm việc này thiết lập trong file.INI Cơ chế chặn thông điệp dựa trên bảng địa chỉ đầu vào đưa ra một kết quả sử dụng lại kiểu hướng đối tượng và sự mở rộng của kiến trúc tầng đưa ra một sự hiệu quả và cơ chế mở rộng cho các hàm hooking API functions. Sự thu nhận và chỉ số hóa các hoạt động trên máy tính Giới thiệu chung Trong đồ án này tôi xin được giới thiệu một công nghệ mới cho việc thu nhận và đánh chỉ số hoạt động trên máy tính. Công nghệ mới này không làm cản trở tương tác tự nhiên người-máy và nó được dựa trên công nghệ tính tính toán mạng ảo VNC. Nó cũng là mô hình tính toán ultra-thin-client/server mà được phân tách thành giao diện hiển thị từ những hệ thống cửa sổ ứng dụng logic. Server thực hiện tất cả các ứng dụng trong khi đó client đơn giản là hiển thị cập nhật từ framebuffer và chấp nhận các đầu vào (bàn phím, chuột, bút điện tử..). Việc tìm ra công nghệ này là một quá trình nghiên cứu lâu dài và còn là sự đúc kết từ những kinh nghiệm trước đó của các nhà nghiên cứu viện AT&T Laboratories Cambridge. Sự thu nhận (capturing) các hoạt động cung cấp các mẫu nguồn (source of record) được xem là các tài nguyên cần thiết rất nhiều cho nghiên cứu này. Trong khi đó việc đánh chỉ số (indexing) các mẫu nguồn này cho phép các thông tin truy cập ngẫu nhiên và nhanh hơn nhiều. Một số công cụ tính toán phân tích và tập hợp âm thanh, hình ảnh và ghi nhận tương tác người máy để hỗ trợ việc thu nhận theo thời gian thực của hàng chuỗi truy cập hoạt động của người dùng. Mặc dù những tương tác người máy có thể cung cấp rất nhiều các tập chỉ số mà chúng ta có thể lấy ra từ các ghi nhận của nó. Thí dụ, mỗi người dùng tạo một sự kiện như là bấm phím trên một phiên làm việc của một máy trạm nào đó, sự kiện được ghi nhận trên mỗi phiên làm việc đó. Hoạt động trên máy tính (COMPUTER-BASED ACTIVITIES) Hoạt động tính toán là một trong những hoạt động quan trọng trong hệ thống VNC. Mô hình client/server mà chúng ta rất quen thuộc được chuyển sang mô hình client/proxy/server, việc đặt giữa client và server một proxy chính là để ngăn chặn và xử lí luồng thông điệp trong phiên kết nối của client-server. Mô hình này sẽ được trình bày kĩ hơn trong phần sau. Proxy server sẽ nhận thông điệp trước và lưu giữ chúng thường xuyên. Đồng thời nó cũng đồng bộ hóa các điểm giữa các thông điệp liên tiếp. Các thông điệp cập nhật framebuffer được lưu trữ trên một file log. Chỉ cần file log này thôi là có đủ khả năng quay trở lại các hoạt động trước đó trong các phiên làm việc của VNC. Sự bất đồng bộ hóa của VNC client (tức là VNC reviewer) thì có thể đọc và hiển thị các thông điệp cập nhật từ file log và cũng một cách tương tự như việc đồng bộ hóa của VNC client đọc và hiển thị các thông điệp cập nhật từ VNC server. Kết quả đạt được với các đoạn video cho phép người dùng theo dõi các chuyển động này tương tự như việc xem và điều khiển trên bàn điều khiển của đầu máy video (VCR). Tuy nhiên các kết quả thu được khi xem các đoạn phim hay movie thường là xuất hiện hiện tượng đen hay bị mờ.Việc cung cấp các khả năng duyệt và tìm kiếm, các thông điệp này hay còn gọi là các sự kiện chính được tổ hợp từ các điểm (check point) được đánh chỉ số. Các thông điệp này được lưu trữ và có thể được ánh xạ đồng bộ hóa với các điểm cập nhật khung trong file log để có thể truy cập ngẫu nhiên. Một thông điệp framebuffer thường có tầm ảnh hưởng tới một vùng nhỏ của toàn bộ framebuffer, và nó có thể truy cập những thông điệp được thu nhận một cách rất tuần tự. Để có thể truy cập một cách ngẫu nhiên, ngoài việc lưu trữ các thông điệp framebuffer, thì cần phải tạo ra các điểm checkpoint vào trong file log. Mỗi một điểm checkpoint là một thông điệp cập nhật các dữ liệu pixel framebuffer ở những thời điểm xác định. Trong khi tìm kiếm các chỉ số của mỗi một thông điệp cập nhật, VNC sẽ đọc điểm checkpoint được đánh dấu gần nhất và hiển thị ảnh lên màn hình. Nếu sau đó nó phát hiện một số điểm checkpoint chưa được hiển thị, nó sẽ truy cập vào file log để tìm các điểm checkpoint trước đó. a/Các sự kiện và các chỉ số (Events to Indices) Người ta đã nghiên cứu thấy sự đa dạng của việc tăng các chỉ số trong việc ghi nhận dữ liệu đa phương tiện. Việc xác định thông điệp các sự kiện cũng như việc đánh chỉ số các điểm từ thông điệp framebuffer và để làm rõ làm thế nào chuyển đổi các sự kiện này vào trong việc đánh chỉ số sử d._.oxy 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. ._.