Giao thức XMPP và khai thác dữ liệu bản đồ phân tán

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ - ĐHQGHN KHOA CÔNG NGHỆ THÔNG TIN CÔNG TRÌNH DỰ THI GIẢI THƯỞNG “SINH VIÊN NGHIÊN CỨU KHOA HỌC” NĂM 2014 Tên công trình: Giao thức XMPP và khai thác dữ liệu bản đồ phân tán Họ và tên sinh viên: Nam, Nữ: Lớp: QH-2011-I/CQ-C-CLC Khoa: Công nghệ thông tin Giáo viên hướng dẫn: PGS TS. Nguyễn Việt Hà Giáo viên đồng hướng dẫn: ThS. Vũ Quang Dũng 1 Tóm tắt/Lời nói đầu Sự phát triển của công nghệ thông tin dẫn đến nhu cầu sử dụng và hiển thị dữ liệu bản đồ trực tuyến ngày càng tăng cao. Hiện có nhiều hệ thống bản đồ nhưng còn có hạn chế: đều sử dụng mô hình máy chủ - khách, điều này khiến cho dữ liệu trao đổi có thể bị mất mát hoặc không được đáp ứng trong thời gian yêu cầu và gây quá tải lên máy chủ. Trước thực trạng đó, nhóm sinh viên chúng tôi đề xuất đề tài: “ Giao thức XMPP và khai thác dữ liệu bản đồ phân tán” nhằm xây dựng hệ thống trao đổi dữ liệu bản đồ sử dụng phương thức XMPP. Từ đó giảm tải cho máy chủ và giảm thời gian trao đổi dữ liệu đảm bảo tính ổn định và đáp ứng thời gian yêu cầu cho hệ thống. Bên cạnh đó chúng tôi áp dụng phương pháp hiển thị theo lớp(layer) giúp hiển thị dữ liệu bất kỳ và tối ưu cho việc tách biệt các dữ liệu. Quá trình nghiên cứu và phát triển đề tài này là tiền đề để chúng tôi tiếp tục áp dụng cho nghiên cứu trực quan liên quan tới chiều không/thời gian trong tương lai. Từ khóa: XMPP, GIS, OpenLayers, lớp, dữ liệu bản đồ, phân tán 2 Mục lục Tóm tắt/Lời nói đầu Mục lục Danh sách hình vẽ Đặt vấn đề Giải quyết vấn đề Trao đổi dữ liệu giữa các Client Phát biểu bài toán XMPP và Websocket Xây dựng máy chủ hỗ trợ XMPP/Websocket Hiển thị dữ liệu bản đồ Phát biểu bài toán Công nghệ sử dụng Công nghệ Web OpenLayers Open Street Map GeoServer Hiển thị Thực nghiệm Môi trường thực nghiệm Môi trường máy chủ Máy khách Kết quả Kết luận Kết quả thu được Hạn chế Hướng đi tương lai: Nâng cấp hệ thống Bản đồ trục thời gian (TimeMap) Khai thác tri thức bản đồ phân tán Tài liệu tham khảo 3 Danh sách hình vẽ 4 1. Đặt vấn đề Với sự phát triển của hệ thống hạ tầng mạng, nhu cầu sử dụng các ứng dụng bản đồ trực tuyến đang tăng cao. Các ứng dụng này yêu cầu dữ liệu phải liên tục được cập nhật mới. Bên cạnh đó sự bùng nổ của thiết bị di động như máy tính bảng, điện thoại thông minh dẫn đến việc dữ liệu trao đổi tăng về lượng và cần linh hoạt và gọn nhẹ hơn. Nhu cầu kết nối, tương tác giữa người dùng cũng ngày càng nhiều: người dùng cần có các phương thức kết nối, trao đổi, tương tác với bạn bè, đối tác dễ dàng và nhanh chóng. Hiện có nhiều ứng dụng bản đồ, như Google Maps, Here Maps, iOS Maps, etc. Nhưng các ứng dụng này đều có 2 hạn chế: ● Hầu hết sử dụng mô hình máy chủ - máy khách thuần túy. Dữ liệu ở máy khách khi cần thiết đều phải lấy từ máy chủ. Khi số lượng người dùng là lớn, nhiều yêu cầu dữ liệu được gửi đến, máy chủ sẽ quá tải, khiến dữ liệu có thể mất mát hoặc đáp ứng với thời gian chậm. ● Không có các phương thức cho phép các máy khách tương tác, trao đổi dữ liệu trực tiếp, nhanh chóng và đơn giản. Từ đó chúng tôi đề xuất một hệ thống hiển thị dữ liệu bản đồ, trong đó việc trao đổi dữ liệu không chỉ được thực hiện giữa máy chủ và máy khách mà còn giữa các máy khách, thông qua một máy chủ thứ 2. Mô hình hoạt động của hệ thống tổng quát được thể hiện ở sơ đồ sau: 5 Cụ thể, khi có yêu cầu về dữ liệu, clients sẽ thực hiện các bước: 1. Gửi yêu cầu đến các clients còn lại thông qua XMPP server 2. Nếu nhận được dữ liệu yêu cầu(từ clients khác), đến bước 4. Nếu không nhận được đến bước 3 3. Nếu không có, gửi yêu cầu đến Web Server 4. Nhận yêu cầu 5. Kết thúc Bài toán cụ thể chúng tôi cài đặt để minh họa cho hệ thống ở đây là: Tài liệu được chia làm 4 phần: 1. Đặt vấn đề 2. Giải quyết vấn đề 3. Thực nghiệm 4. Kết luận: Đạt được, hạn chế và phương hướng tương lai 6 2. Giải quyết vấn đề 2.1. Trao đổi dữ liệu giữa các Client 2.1.1. Phát biểu bài toán Trong các ứng dụng truyền thống: Khi máy khách có nhu cầu cần phải lấy dữ liệu mới hoặc cập nhật dữ liệu, máy khách sẽ gửi yêu cầu đến máy chủ. Máy chủ sẽ xử lý yêu cầu, sau đó gửi lại cho máy khách theo mô hình sau. Hệ thống của chúng tôi đề xuất sử dụng mô hình trao đổi dữ liệu như trong mô hình sau: Trong đó, cốt lõi của hệ thống là giao thức XMPP với công nghệ Websocket, một công nghệ mới có trong HTML5. 2.1.2. XMPP và Websocket XMPP là viết tắt của eXtensible Messaging and Presence Protocol, là một công nghệ XML mở cho phép giao tiếp thời gian thực, nó có thể đáp ứng một số lượng lớn các ứng dụng bao gồm tin nhắn nhanh (instant messaging), trạng thái trực tuyến (presence), đàm phán đa phương tiện (media negotiation), bảng tương tác (whiteboarding), sự công tác (collaboration), máy kết nối đơn giản (lightweight middleware), thống nhất nội dung (content syndication), và định tuyến XML tổng quát (generalized XML routing) - theo xmpp.org XMPP sử dụng các luồng XML để truyền tải thông tin. XML là một phần của chuỗi tiến hóa của các ngôn ngữ đánh dấu (markup language) (ngôn ngữ với các cặp dấu ngoặc). Chữ X trong XML viết tắt của eXtensible nghĩa là khả mở và XMPP tận dụng tính khả mở đó, nó sử dụng XML để tạo ra các không gian tên (namespace) để thuận tiện trao đổi các loại thông điệp khác nhau. Truyền thông trên XMPP thực chất là trao đổi các khổ XML (stanza), chúng tôi sử dụng triệt để khả năng mở rộng này của XMPP để truyền dữ liệu và các thông điệp điều khiển giữa các client. Websocket [1] là công nghệ được phát triển như một phần của HTML5, được cung cấp dưới dạng một interface (Websocket Javascript interface), nó cho phép định nghĩa một kết nối socket đơn, song công mà thông qua đó thông điệp có thể được truyền giữa máy chủ và máy khách. Chuẩn Websocket cho phép đơn giản hóa tối đa những rườm rà của giao tiếp bán song công của web và sự quản lý kết nối. - theo websocket.org 7 2.1.2. Xây dựng máy chủ hỗ trợ XMPP/Websocket a. Chiến lược kết nối Có một khó khăn nảy sinh khi chúng tôi thực hiện nghiên cứu này liên quan đến chuẩn sử dụng XMPP thông qua websocket (XMPP/WS). Cho đến thời điểm này, vẫn chưa có một chuẩn chính thức nào về XMPP/WS được công nhận vì vậy việc tìm ra một mô hình mẫu để học tập, cải biên cho đúng với mục đích sử dụng là một vấn đề lớn. Do đó, một thực tế rõ ràng là chiến lược kết nối và xây dựng máy chủ XMPP/WS trong phần nghiên cứu của chúng tôi không phải chiến lược kết nối chuẩn, nhưng nó là một trong các chiến lược đã được khuyến nghị trong cuốn The Definitive Guide to HTML5 WebSocket của Vanessa Wang, Frank Salim, and Peter Moskovits. (http://www.websocket.org/book.html) Chiến lược kết nối của chúng tôi là sử dụng một gateway hỗ trợ websocket làm trung gian giữa máy khách và máy chủ XMPP. Mô hình của chiến lược kết nối này như sau: - Client: Sử dụng strophe.js [7] là một module phát triển trên nền javascript, hỗ trợ các phương thức xmpp từ phía client. - XMPP Server: Sử dụng ejabberd, phần mềm cung cấp dịch vụ xmpp. - Gateway: Sử dụng module node-xmpp-bosh[4] do dhruvbird phát triển, là module của notejs[6], tương thích với strophe.js từ phía client. b. Tiến hành cài đặt (thực hiện trên HĐH ubuntu server) - Cài đặt ejabberd (sử dụng apt-get của ubuntu), sau đó config cổng admin từ 5820 thành một cổng khác (sửa trong file ejabberd.cfg). Việc này sẽ giúp tránh được xung đột do module node-xmpp-bosh (gateway) cũng giao tiếp trên cổng 5820. 8 - Cài phiên bản mới nhất của nodejs sudo apt-get install python-software-properties sudo add-apt-repository ppa:chris-lea/node.js sudo apt-get update sudo apt-get install nodejs - Cài module node-xmpp-bosh theo hướng dẫn chi tiết từ nhà phát triển module này https://github.com/dhruvbird/node-xmpp-bosh 2.2. Hiển thị dữ liệu bản đồ 2.2.1. Phát biểu bài toán Dữ liệu nhận được từ server và từ clients khác cần được hiển thị đến người dùng dưới dạng hình ảnh trực quan. Ở đây ta có 2 dạng dữ liệu: 1. Dữ liệu bản đồ từ server: Dữ liệu này sẽ được lấy về ngay từ khi tải trang web, và sẽ được update trong qua trình sử dụng thông qua request HTTP 2. Dữ liệu về vị trí từ người dùng từ clients: Dữ liệu này sẽ được gửi đến các clients còn lại khi có sự thay đổi về trang thái của client. Các dữ liệu này sẽ được xử lý hiển thị về phía người dùng 2.2.2. Công nghệ sử dụng 2.2.2.1. Công nghệ Web HTML5 là phiên bản thứ 5, mới nhất của chuẩn HTML, ngôn ngữ cấu trúc và trình bày nội dung cho World Wide Web. HTML5 có nhiều tính năng mới hỗ trợ viêêc đưa vào và quản lý các nôêi dung đa phương tiêên và đồ họa, không còn phụ thuôêc vào các plugin và API. Cùng với HTML5 là thế hệ tiếp theo của CSS (Cascading Style Sheets) – CSS3. CSS là những đăêc tả hiển thị hỗ trợ cho trình duyệt Web trong việc trình bày một trang HTML. CSS3 là phiên bản mới nhất của CSS. 2.2.2.2. OpenLayers Openlayers[2] là một thư viện thuần JavaScript hỗ trợ cho việc hiển thị dữ liệu bản đồ trên hầu hết các trình duyệt web mà không phụ thuộc vào phía server. OpenLayers cài đặt một tập các hàm API JavaScript hỗ trợ việc xây dựng các ứng dụng bản đồ trên nền web, cũng tương tự như các hàm API của Google Maps và MSN MSN Virtual Earth, nhưng với sự khác biệt quan trọng – OpenLayers là phần mềm mã nguồn mở, được phát triển bởi cộng đồng phần mềm mã nguồn mở. Có hai khái niệm quan trong cần được hiểu rõ khi làm việc với OpenLayers để hiện xây dựng bản đồ: 1. Map: Map là nơi để lưu giữ các thông tin về hệ quy chiếu, đơn vị,… của bản đồ. 2. Layers: Bên trong bản đồ, dữ liệu được hiển thị thông qua Layer. Một Layer là một nguồn dữ liệu, nó cho biết OpenLayers nên yêu cầu và hiển thị dữ liệu như thế nào. 9 Trong một Map có thể chứa một hoặc nhiều ‘Layer’ chồng lên nhau. Dữ liệu được hiện thị trong một Layer có thể là dạng raster hoặc vector. OpenLayers cung cấp một tập các điều khiển (controls) cho lập trình viên có các thao tác linh hoạt trên bản đồ. Các điều khiển là các lớp trong OpenLayers, chúng cho phép định nghĩa các trạng thái, hành vi của bản đồ. Hoặc hiển thị các thông tin bổ sung cho người dùng. Các điều khiển là giao diện chính cho phép tương tác với bản đồ. 2.2.2.3. Open Street Map Open Street Map[3] là môêt dự án bản đồ mở, cho phép tất cả mọi người cùng đóng góp, tùy chỉnh, để xây dựng dữ liêêu bản đồ thế giới chi tiết tới mọi vùng miền. Khác với Google Map, Open Street Map cung cấp trực tiếp dữ liêêu bản đồ dưới nhiều định dạng, và cho phép người dùng sử dụng mà không đòi hỏi thông qua API hay ràng buôêc hạn chế. Môêt trong số những định dạng bản đồ mà Open Street Map cung cấp là ảnh bản đồ tĩnh (Static Map Tile). Định dạng này phù hợp để vẽ đồ thị lên trên vì bản đồ khi đó là môêt phần của không gian đồ họa. 2.2.2.4. GeoServer Geoserver [5] là một dự án mã nguồn mở, phát triển trên ngôn ngữ Java. Geoserver cho phép người dùng chia sẻ, sửa đổi các dữ liệu bản đồ. Geoserver cho phép lấy nguồn dữ liệu từ nhiều nguồn, và cho phép các ứng dụng khác truy cập thông qua giao thức HTTP. Geoserver hỗ trợ nhiều định dạng dữ liệu bản đồ chuẩn như: Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS), Web Map Service (WMS) 2.2.3. Hiển thị Dữ liệu bản đồ được lấy trực tiếp từ Open Street Map. OpenStreetMap cung cấp nhiều định dạng dữ liệu bản đồ. Ở hệ thống, ảnh được cung cấp dưới định dạng “.png”, kích thước 256x256px, các ô ảnh bản đồ nhỏ được xếp cạnh nhau để tạo thành một bản đồ có kích thước lớn. Open Street Map cung cấp ảnh bản đồ thông qua các đường dẫn (URL), cụ thể: http://b.tile.openstreetmap.org/15/26019/14425.png sẽ cho hình ảnh sau: - URL ảnh bản đồ Open Street Map cung cấp có cấu trúc như sau: http://[abc].tile.openstreetmap.org/zoom/x/y.png o [abc] : subdomain ( a.tile , b.tile , c.tile ) o zoom : mức zoom ( 0-18) o x, y : toạ độ của ô ảnh trong mảng. Cụ thể : 10 Ở mức zoom=0, toàn bộ bản đồ trái đất chỉ gồm 1 ô ảnh. Ở mức zoom=1, mỗi chiều ô ảnh được chia làm 2, cho 4 ô ảnh bản đồ. Với x,y là toạ độ ô ảnh, có 4 ô xác định bởi bộ 3 số zoom,x,y : [1,0,0] , [1,1,0] , [1,0,1] , [1,1,1]. Tương tự với các mức zoom tiếp theo. Việc hiển thị dữ liệu được xử lý thông qua thư viện Openlayers. Openlayers sử dụng các layer để hiển thị dữ liệu Thế mạnh của việc hiển thị sử dụng layer là khả năng tách biệt hóa. Mỗi layers có một nhiệm vụ riêng, hiển thị dữ liệu riêng. Từ đó việc quản lý, thay đổi các layer để hiển thị đến người dùng là linh hoạt và không ảnh hưởng đến layer khác. Mô hình hiển thị đến người dùng được mô tả như sau: Ở đó: 11 ● ● ● Layer OSM hiện thị nền bản đồ, lấy nguồn từ Open Street Maps hoặc Geoserver Vector layer hiển thị dữ liệu vector Marker layer hiển thị các marker Kết quả cho ta giao diện của hệ thống với người dùng: Trong đó, ở view bản đồ người dùng, có các thao tác: ● Di chuyển: Bằng chuột ● Zoom: Bằng cuộn chuột, controller ● Đánh dấu(mark): click chuột Sau khi đã kết nối, bản đồ của người dùng sẽ hiển thị và liên tục được cập nhật thông qua xmpp và hiển thị ở view bản đồ của client khác trên client còn lại. 3. Thực nghiệm 3.1. Môi trường thực nghiệm 3.1.1. Môi trường máy chủ Trong phần nghiên cứu của mình, chúng tôi sử dụng một máy chủ vật lý làm nơi lưu trữ và chạy các máy chủ web, XMPP server, Geoserver Chúng tôi cần máy chủ cung cấp được 2 dịch vụ là dịch vụ web và dịch vụ XMPP. Bởi vì hai dịch vụ này chạy trên 2 cổng khác nhau và không xung đột nên trong phạm vi nghiên cứu, chúng chạy trên cùng một máy chủ. Khi ứng dụng nghiên cứu này vào thực tế thì tùy vào điều kiện cụ thể mà ta có thể thay đổi số lượng máy chủ. HP 12 CPU Intel Core 2 Duo E4400 @2.0GHz Memory 2x512MB DDR2 OS Ubuntu 12.0.4 LTS 3.1.2. Máy khách Sự lựa chọn môi trường máy khách có tính linh động cao, miễn là máy khách có cung cấp trình duyệt web cho người sử dụng. Trong quá trình kiểm thử, hệ thống của chúng tôi chạy tốt với các trình duyệt phổ thông như Internet Explorer của Microsoft, Chrome của Google và Firefox của Mozilla. CPU Intel Core i3 2350 @2.35 GHz x2 Memory 4x1GB DDR3 OS Windows 8.1 Browser Chrome v33 Firefox v27 CPU Intel Core 2 Duo E7400 @2.80GHz x2 Memory 1+2GB DDR2 OS Windows 8.1 Browser Chrome v33 Firefox v27 3.2. Kết quả Hệ thống chạy ổn định và không gặp vấn đề gì trong việc trao đổi dữ liệu. Khi có sự thay đổi từ client, client còn lại nhận được dữ liệu và cập nhật tức thời. Điều này thể hiện qua việc cập nhật liên tục vị trí client ở cửa sổ “partner” và tính toán khoảng cách giữa 2 điểm đánh dấu 13 4. Kết luận 4.1. Kết quả thu được Qua thực nghiệm, hệ thống đã thành công trong việc trao đỗi dữ liệu giữa 2 clients thông qua giao thức XMPP và máy chủ XMPP. Dữ liệu được trao đổi không thông qua server thuần túy, giảm tải cho server. 4.2. Hạn chế Hiện tại hệ thống còn 2 hạn chế: 1. Chỉ hỗ trợ 2 clients 2. Dữ liệu trao đổi chưa phong phú: Mới chỉ là địa điểm hiện tại và địa điểm được đánh dấu 4.3. Hướng đi tương lai: 4.3.1. Nâng cấp hệ thống Chúng tôi sẽ nâng cấp hệ thống để khắc phục các hạn chế hiện tại: 1. Hỗ trợ hệ thống gồm n - clients, sử dụng cơ chế xác thực của XMPP: XMPP ID để xác thực người dùng 2. Trao đổi thông tin phong phú hơn, bao gồm: Dữ liệu ảnh bản đồ(không phải yêu cầu đến OSM hay geoserver nếu clients khác có) 4.3.2. Bản đồ trục thời gian (TimeMap) Trong tương lai, chúng tôi đề xuất một hệ thống lưu trữ dữ liệu theo 3 chiều: 1. 02 Chiều không gian 2. Chiều thời gian cho phép người dùng hiển thị dữ liệu theo dạng bản đồ 2 chiều thông thường. Nhưng bên cạnh đó là khả năng hiển thị trục thời gian của tọa độ/vị trí/đối tượng. Theo trục thời gian này, người dùng có thể xem được đối tượng/tọa độ/vị trí đó đã có những biến cố gì, sự kiện gì xảy ra trong lịch sử. Với hệ thống này, chúng tôi mong muốn người dùng sẽ có trải nghiệm thú vị hơn, là một cách trực quan, hứng thú để quan sát lịch sử. Nhất là với lớp trẻ Việt Nam, ngày càng thiếu kiến thức và quan tâm đến lịch sử của nước nhà. 4.3.3. Khai thác tri thức bản đồ phân tán Một hướng đi nữa của nghiên cứu này là ứng dụng vào việc khai thác tri thức bản đồ phân tán. Nói một cách dễ hiểu là với nghiên cứu này, những thông tin trên đường của mạng lưới người dùng sẽ được chia sẻ cho nhau và từ đó có được thông tin chính xác nhất về tình trạng giao thông hiện tại. Ý tưởng của hướng đi này dựa trên ý tưởng của thuật toán distancevector trong định tuyến mạng của các router. Nếu như hướng đi này được hiện thực hóa, nó sẽ trở thành một giải pháp đắc lực cho việc giải quyết các vấn đề của giao thông đô thị Việt Nam, vốn đang là bài toán khó đối với toàn xã hội. Để trực quan hóa hướng đi này, chúng tôi đưa ra một tình huống trong giải quyết tắc đường. Giả sử như mọi người dân Hà Nội đều sử dụng smartphone và trên đó có ứng dụng để khai thác bản đồ phân tán, khi đó, với tri thức có được từ mạng lưới người dùng, ứng dụng có 14 thể biết được tình trạng thực tế của các tuyến đường và từ đó gợi ý cho người dùng tuyến đường hợp lý nhất (mật độ thấp nhất, hiện đang không sửa chữa, chất lượng đường chấp nhận được..). Khi đó, nếu nhìn toàn cục giao thông ở Hà Nội, ta sẽ thấy một sự “tự điều chỉnh” vô cùng hợp lý và hiệu suất của các tuyến đường được khai thác một cách tối đa. Tài liệu tham khảo [1] The Definitive Guide to HTML5 WebSocket by Vanessa Wang, Frank Salim, and Peter Moskovits [2] “Openlayers” [Online]. Available: http://openlayers.org/ [3] “Open Street Maps” [Online]. Available: http://www.openstreetmap.org/ [4] “node-xmpp-bosh” [Online]. Available: https://github.com/dhruvbird/node-xmpp-bosh/ [5] “Geoserver” [Online]. Available: http://geoserver.org [6] “note.js” [Online]. Available: http://nodejs.org/ [7] “strophe.js” [Online]. Available: http://strophe.im/ 15 [...]... Nam, ngày càng thiếu kiến thức và quan tâm đến lịch sử của nước nhà 4.3.3 Khai thác tri thức bản đồ phân tán Một hướng đi nữa của nghiên cứu này là ứng dụng vào việc khai thác tri thức bản đồ phân tán Nói một cách dễ hiểu là với nghiên cứu này, những thông tin trên đường của mạng lưới người dùng sẽ được chia sẻ cho nhau và từ đó có được thông tin chính xác nhất về tình trạng giao thông hiện tại Ý tưởng... cửa sổ “partner” và tính toán khoảng cách giữa 2 điểm đánh dấu 13 4 Kết luận 4.1 Kết quả thu được Qua thực nghiệm, hệ thống đã thành công trong việc trao đỗi dữ liệu giữa 2 clients thông qua giao thức XMPP và máy chủ XMPP Dữ liệu được trao đổi không thông qua server thuần túy, giảm tải cho server 4.2 Hạn chế Hiện tại hệ thống còn 2 hạn chế: 1 Chỉ hỗ trợ 2 clients 2 Dữ liệu trao đổi chưa... của giao thông đô thị Việt Nam, vốn đang là bài toán khó đối với toàn xã hội Để trực quan hóa hướng đi này, chúng tôi đưa ra một tình huống trong giải quyết tắc đường Giả sử như mọi người dân Hà Nội đều sử dụng smartphone và trên đó có ứng dụng để khai thác bản đồ phân tán, khi đó, với tri thức có được từ mạng lưới người dùng, ứng dụng có 14 thể biết được tình trạng thực tế của các tuyến đường và từ... marker Kết quả cho ta giao diện của hệ thống với người dùng: Trong đó, ở view bản đồ người dùng, có các thao tác: ● Di chuyển: Bằng chuột ● Zoom: Bằng cuộn chuột, controller ● Đánh dấu(mark): click chuột Sau khi đã kết nối, bản đồ của người dùng sẽ hiển thị và liên tục được cập nhật thông qua xmpp và hiển thị ở view bản đồ của client khác trên client còn lại 3 Thực nghiệm 3.1 Môi trường thực nghiệm... điểm hiện tại và địa điểm được đánh dấu 4.3 Hướng đi tương lai: 4.3.1 Nâng cấp hệ thống Chúng tôi sẽ nâng cấp hệ thống để khắc phục các hạn chế hiện tại: 1 Hỗ trợ hệ thống gồm n - clients, sử dụng cơ chế xác thực của XMPP: XMPP ID để xác thực người dùng 2 Trao đổi thông tin phong phú hơn, bao gồm: Dữ liệu ảnh bản đồ( không phải yêu cầu đến OSM hay geoserver nếu clients khác có) 4.3.2 Bản đồ trục thời... nhiệm vụ riêng, hiển thị dữ liệu riêng Từ đó việc quản lý, thay đổi các layer để hiển thị đến người dùng là linh hoạt và không ảnh hưởng đến layer khác Mô hình hiển thị đến người dùng được mô tả như sau: Ở đó: 11 ● ● ● Layer OSM hiện thị nền bản đồ, lấy nguồn từ Open Street Maps hoặc Geoserver Vector layer hiển thị dữ liệu vector Marker layer hiển thị các marker Kết quả cho ta giao diện của hệ thống...Ở mức zoom=0, toàn bộ bản đồ trái đất chỉ gồm 1 ô ảnh Ở mức zoom=1, mỗi chiều ô ảnh được chia làm 2, cho 4 ô ảnh bản đồ Với x,y là toạ độ ô ảnh, có 4 ô xác định bởi bộ 3 số zoom,x,y : [1,0,0] , [1,1,0] , [1,0,1] , [1,1,1] Tương tự với các mức zoom tiếp theo Việc hiển thị dữ liệu được xử lý thông qua thư viện Openlayers Openlayers sử dụng các layer để hiển thị dữ liệu Thế mạnh của việc hiển thị... chúng tôi sử dụng một máy chủ vật lý làm nơi lưu trữ và chạy các máy chủ web, XMPP server, Geoserver Chúng tôi cần máy chủ cung cấp được 2 dịch vụ là dịch vụ web và dịch vụ XMPP Bởi vì hai dịch vụ này chạy trên 2 cổng khác nhau và không xung đột nên trong phạm vi nghiên cứu, chúng chạy trên cùng một máy chủ Khi ứng dụng nghiên cứu này vào thực tế thì tùy vào điều kiện cụ thể mà ta có thể thay đổi số lượng... Chrome của Google và Firefox của Mozilla CPU Intel Core i3 2350 @2.35 GHz x2 Memory 4x1GB DDR3 OS Windows 8.1 Browser Chrome v33 Firefox v27 CPU Intel Core 2 Duo E7400 @2.80GHz x2 Memory 1+2GB DDR2 OS Windows 8.1 Browser Chrome v33 Firefox v27 3.2 Kết quả Hệ thống chạy ổn định và không gặp vấn đề gì trong việc trao đổi dữ liệu Khi có sự thay đổi từ client, client còn lại nhận được dữ liệu và cập nhật tức... yêu cầu đến OSM hay geoserver nếu clients khác có) 4.3.2 Bản đồ trục thời gian (TimeMap) Trong tương lai, chúng tôi đề xuất một hệ thống lưu trữ dữ liệu theo 3 chiều: 1 02 Chiều không gian 2 Chiều thời gian cho phép người dùng hiển thị dữ liệu theo dạng bản đồ 2 chiều thông thường Nhưng bên cạnh đó là khả năng hiển thị trục thời gian của tọa độ/vị trí/đối tượng Theo trục thời gian này, người dùng có ... đề xuất đề tài: “ Giao thức XMPP khai thác liệu đồ phân tán nhằm xây dựng hệ thống trao đổi liệu đồ sử dụng phương thức XMPP Từ giảm tải cho máy chủ giảm thời gian trao đổi liệu đảm bảo tính... Việt Nam, ngày thiếu kiến thức quan tâm đến lịch sử nước nhà 4.3.3 Khai thác tri thức đồ phân tán Một hướng nghiên cứu ứng dụng vào việc khai thác tri thức đồ phân tán Nói cách dễ hiểu với nghiên... trực quan Ở ta có dạng liệu: Dữ liệu đồ từ server: Dữ liệu lấy từ tải trang web, update qua trình sử dụng thông qua request HTTP Dữ liệu vị trí từ người dùng từ clients: Dữ liệu gửi đến clients