Phát triển phần mềm lấy tin nhanh RSS trên điện thoại di động có khả năng tương tác với PC

Phát triển phần mềm lấy tin nhanh RSS trên điện thoại di động có khả năng tương tác với PC Phát triển phần mềm lấy tin nhanh RSS trên điện thoại di động có khả năng tương tác với PC Phát triển phần mềm lấy tin nhanh RSS trên điện thoại di động có khả năng tương tác với PC luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

-

H Ồ VIỆT THẮNG

TRÊN ĐIỆN THOẠI DI ĐỘNG CÓ KHẢ

NĂNG TƯƠNG TÁC VỚI PC

Chuyên ngành: Điện Tử Tin Học

LUẬN VĂN THẠC SĨ KHOA HỌC

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Phạm Văn Tiến

L ỜI CAM ĐOAN Tôi là Hồ Việt Thắng, tôi xin cam đoan luận văn thạc sĩ điện tử tin học này do chính tôi nghiên cứu và thực hiện dựa trên kiến thức bản thân và các tài liệu tham khảo đã trích

dẫn Các thông tin, số liệu được sử dụng trong luận văn là trung thực và chính xác và chưa từng được công bố trong bất kỳ công trình nào khác

Hà Nội, ngày 12 tháng 09 năm 2011

Hồ Việt Thắng

3

Hình 1: RSSU 123

Hình 2: BluetoothU 193

Hình 3: Cấu trúc bộ giao thức BluetoothU 203

Hình 4: Các dạng mạng BluetoothU 253

Hình 5: Định dạng gói tin BluetoothU 263

Hình 6: Cấu trúc của L2CAPU 313

Hình 7 : Sơ đồ use caseU 373

Hình 8: Các đối tượng cần quản lýU 383

Hình 9: Sơ đồ kiến trúc hệ thốngU 403

Hình 10: Cấu trúc module ManagerU 413

Hình 11: Cơ chế đồng bộ giữa hai thiết bịU 423

Hình 12 Trường hợp timeStamp của B mới hơn AU 463

Hình 13: timeStamp của B cũ hơn của AU 473

Hình 14: Di động trước khi thêm mới RSSU 553

Hình 15: Máy tính trước khi thêm mới RSSU 553

Hình 16: Máy tính sau khi thêm RSS thành côngU 563

Hình 17: Di động sau khi thêm mới RSS thành côngU 563

Hình 18: Máy tính trước khi lưu RSSU 573

Hình 19: Di động trước khi lưu tin RSSU 583

Hình 20: Quá trình thực hiện lưu RSS trên di độngU 583

Hình 21: Ảnh máy tính sau khi thực hiện lưu RSS trên di độngU 593

Hình 22: Ảnh di động sau khi lưu RSS thành côngU 593

Hình 23: Giao diện phần mềm chạy trên máy tínhU 643

Hình 24: Cửa sổ thêm một catalog mớiU 65

DANH SÁCH CÁC B ẢNG

3

Bảng 1 Vấn đề tốc độ của thiết bịU 353

Bảng 2 : Vấn đề kích thước của màn hìnhU 353

Bảng 3: Vấn đề tốc độ mạngU 353

Bảng 4: Thuộc tính của các đối tượng Catalog, RSS, NewsU 493

Bảng 5: Các trường cần phải có của gói tin dùng để đồng bộU 493

Bảng 6: Các trường của gói tinU 513

Bảng 7: Cấu trúc gói tin:U 513

Bảng 8: Các trường trong gói tin backupU 513

Bảng 9: Các trường hợp thử nghiệm hệ thốngU 54

CÁC T Ừ VIẾT TẮT SỬ DỤNG TRONG

L2CAP Logical Link Control and Adaption protocol

Chương 1 MỞ ĐẦU

1.1 Lý do chọn đề tài và mục đích của luận văn

Hầu hết chúng ta thường có một danh sách các website ưa thích, có thể khoảng 10-15 điểm dừng chân mỗi ngày Tuy nhiên, thường chỉ có một vài điểm trong số đó có tin

mới đáng đọc ngay lập tức, do vậy thói quen nạp và duyệt qua từng site mỗi ngày làm lãng phí rất nhiều thời gian của người dùng Nhờ một chuẩn web tên RSS việc đọc tin này sẽ trở nên nhẹ nhàng hơn Chuẩn này cho phép các site cung cấp một danh sách đơn giản chỉ gồm tựa đề và nội dung tóm tắt Dùng một chương trình gọi là RSS reader (trình đọc RSS), mọi người có thể đăng ký với các nguồn cung cấp tin khác nhau và nhanh chóng duyệt qua những tin tức dày dặc Tuy nhiên khi nhu cầu đọc tin tức lên cao, người ta không chỉ bó buộc đọc trên máy tính hay di động mà còn có nhu cầu lưu

lại các mẩu tin tức, chuyển chúng qua lại giữa máy tính và các thiết bị khác nhằm tiện hơn cho việc đọc của mình

Luận văn trình bày về một hệ thống đọc tin RSS bao gồm hai chương trình hoạt động độc lập, riêng rẽ trên máy tính và di động, đồng thời cho phép đồng bộ dữ liệu giữa hai thiết bị cũng như tổ chức lưu trữ các mục RSS theo mong muốn nhằm đáp ứng nhu cầu đọc tin tức ngày càng cao của người sử dụng

1.2 Tổ chức luận văn

Luận văn được chia thành năm phần chính và một phần phụ lục

Phần 1 tác giả trình bày mục đích nghiên cứu, phương pháp luận cũng như tổ chức của

luận văn

Phần 2 giới thiệu chung về các công nghệ được sử dụng trong hệ thống, đó là RSS và bluetooth Chương này giới thiệu về RSS cũng như cấu trúc dữ liệu và các thành phần

của định dạng gốc của RSS là XML Ngoài ra tác giả cũng nói về các đặc điểm của bộ giao thức Bluetooth và cấu trúc phân tầng của nó

Phần 3 nói về mô hình của hệ thống đọc tin RSS sẽ được xây dựng dựa trên một bài toán cụ thể Qua quá trình phân tích bài toán tác giả thu được các yêu cầu về chức năng

và phi chức năng của hệ thống phải có, từ đó thiết kế các phần của hệ thống trên cả máy tính và di động

Phần 4 đưa ra giao thức đồng bộ được sử dụng cho hệ thống đọc tin Giao thức này cho phép đồng bộ dữ liệu cũng như cách thức tổ chức thư mục mà người dùng thực hiện trên máy và di động

Phần 5 đánh giá hệ thống đọc tin RSS đã được thiết kế, các ưu nhược điểm cũng như hướng phát triển trong tương lai

Các hướng dẫn cài đặt hệ thống cùng các ảnh minh họa giao diện chương trình, các tài

liệu tham khảo được trình bày trong phần phụ lục

1.3 Phương pháp nghiên cứu

Tác giả nghiên cứu lý thuyết về cấu trúc bộ giao thức Bluetooth và chuẩn dữ liệu RSS

từ đó thiết kế một giao thức đồng bộ các thông tin về RSS giữa máy tính và thiết bị di động (cụ thể là di động sử dụng hệ điều hành symbian của Nokia) rồi kiểm nghiệm trên các thiết bị thật theo nhiều kịch bản đồng bộ khác nhau

Từ mô tả bài toán đặt ra, qua quá trình phân tích thu được các yêu cầu chức năng và phi chức năng mà hệ thống cần có, đồng thời cũng rút ra được các mặt thuận lợi và khó khăn khi xây dựng hệ thống

Dựa trên các yêu cầu thu được từ quá trình phân tích, thiết kế nên cấu trúc của hệ thống trên cả máy tính và di động, các biểu đồ tuần tự, sơ đồ tương tác giữa các thực thể…Từ

các yêu cầu về khả năng đồng bộ thiết kế các loại gói tin cũng như các trường cần phải

có để đáp ứng yêu cầu đó

Phần này sẽ giới thiệu các khái niệm cơ bản nhất về bộ giao thức Bluetooth và định

dạng tập tin RSS được sử dụng để xây dựng nên hệ thống Vì RSS thực chất là định

dạng XML mở rộng nên luận văn sẽ đề cập chủ yếu đến biểu diễn dữ liệu và những thành phần của một tài liệu XML

2.1 Gi ới thiệu chung về RSS

RSS (Really Simple Syndication) là một định dạng tập tin thuộc họ XML dùng trong

việc chia sẻ tin tức Web được dùng bởi nhiều website tin tức và weblog

RSS được dùng phổ biến bởi cộng đồng weblog để chia sẻ những tiêu đề tin tức mới

nhất hay toàn bộ nội dung của nó, và ngay cả các tập tin đa phương tiện đính kèm (xem podcasting, vodcasting, broadcasting, screencasting, Vloging, và MP3 blogs.) Vào giữa năm 2000, việc sử dụng RSS trở nên phổ dụng đối với hãng tin tức lớn, bao

gồm Reuters, CNN, và BBC Những nhà cung cấp tin này cho phép các website khác

tổng hợp những tiêu đề tin tức "được chia sẻ" hay cung cấp các tóm tắt ngắn gọn của các bản tin chính dưới nhiều hình thức thỏa hiệp khác nhau RSS ngày nay được dùng cho nhiều mục đích, bao gồm tiếp thị, báo cáo lỗi (bug-reports), hay các hoạt động

khác bao gồm cập nhật hay xuất bản định kì

Một chương trình gọi là một feed reader hay aggregator có thể kiểm tra xem một

website có hỗ trợ RSS cho người dùng không và, nếu có, hiển thị những bài viết cập

nhật nhất mà nó tìm thấy từ website đó Ngày nay có thể tìm thấy RSS feeds trên rất

nhiều Web sites lớn, cũng như nhiều những site nhỏ

Các công cụ đọc tin phía trình khách và công cụ aggregator thường được xây dựng

thành một chương trình độc lập hoặc là một phần mở rộng của các chương trình có sẵn như trình duyệt web Những chương trình như vậy có mặt trên nhiều hệ điều hành khác nhau

Trên các trang web, RSS feeds thường được liên kết bằng một hình chữ nhật màu cam , có thể kèm theo các kí tự XML hay RSS Vì RSS thực chất là sự mở

rộng của XML nên trong phần tiếp theo luận văn sẽ trình bày về cấu trúc và mô tả của định dạng XML

2.1.1 Giới thiệu chung về XML

XML (Extensible Markup Language) ra đời vào tháng 2/1998, là ngôn ngữ có kiến trúc gần giống với HTML nhưng XML nhanh chóng trở thành một chuẩn phổ

HTTP Trong khi HTML là ngôn ngữ chủ yếu về hiển thị dữ liệu thì XML lại đang phát triển mạnh về việc chuyển tải, trao đổi và thao tác dữ liệu XML đưa ra một định

dạng chuẩn cho cấu trúc của dữ liệu hoặc thông tin bằng việc tự định nghĩa định dạng

của tài liệu Bằng cách này, dữ liệu được lưu trữ bằng XML sẽ độc lập với việc xử lý

Vì vậy XML ra đời sẽ đáp ứng được yêu cầu ngày càng cao của các nhà lập trình trong

vấn đề trao đổi và xử lý thông tin

Ưu điểm của XML là có thể mô tả được các loại dữ liệu có cấu trúc, dễ đọc dễ hiểu, được lưu trữ trên máy dưới dạng tập tin văn bản nên không cần cài đặt thêm bất cứ

phần mềm nào để sử dụng Tuy nhiên cũng có thể thấy nhược điểm của XML là không

hỗ trợ bảo mật, không có cơ chế đảm bảo tính toàn vẹn dữ liêu, không hỗ trợ người dùng đa truy nhập và không cho phép truy vấn qua nhiều tài liệu

2.1.2 T ừ HTML đến XML

Trong một trang Web, ngôn ngữ đánh dấu HTML dùng các cặp Tags để đánh dấu vị trí

đầu và cuối của các mảnh dữ liệu để giúp chương trình trình duyệt (browser) parse (ngắt khúc để phân tích) trang Web và hiển thị các phần theo ý người thiết kế trang Web Thí dụ như một câu HTML dưới đây:

<P align="center">Chào mừng bạn đến thăm

<STRONG>Bách Khoa</STRONG>

</P>

Câu code HTML trên có chứa hai markup Tags, <P> và <STRONG> Mỗi cặp Tags

gói dữ liệu nó đánh dấu giữa opening Tag và closing Tag Hai closing Tags ở đây là

</P> và </STRONG> Tất cả những gì nằm bên trong một cặp Tags được gọi là

Element Để nói thêm đặc tính của một Element, ta có thể nhét Attribute như align

trong opening Tag của Element ấy dưới dạng AttributeName="value", thí dụ như align="center"

Vì Tags trong HTML được dùng để format (trình bày) tài liệu nên browser cần biết ý

nghĩa của mỗi Tag Một browser hay HTML parser sẽ thu thập các chỉ thị sau từ câu HTML trên:

- Bắt đầu một Paragraph mới và đặt Text ở giữa trang (<P align="center">)

- Hiển thị câu Chào mừng bạn đến thăm

- Hiển thị chữ Bách Khoa cách mạnh mẽ (<STRONG>Vovisoft</STRONG>)

- Gặp điểm cuối của Paragraph (</P>)

Để xử lý đoạn code HTML trên, chẳng những browser cần phải xác định vị trí các Tags

mà còn phải hiểu ý nghĩa của mỗi Tag Vì mỗi Tag có ý ngĩa riêng của nó, thí dụ P cho Paragraph, STRONG để nhấn mạnh, thí dụ như dùng chữ đậm (Bold)

Giống như HTML, XML đến từ SGML Nó cũng dùng Tags để encode data Điểm khác biệt chính giữa HTML và XML là trong khi các Tags của HTML chứa ý nghĩa về formatting (cách trình bày) các dữ liệu, thì các Tags của XML chứa ý nghĩa về cấu trúc

của các dữ liệu Thí dụ như một tài liệu đặt hàng (order) XML dưới đây:

Tài liệu này chỉ chứa dữ liệu, không nhắc nhở gì đến cách trình bày Điều này có nghĩa

là một XML parser (chương trình ngắt khúc và phân tích) không cần phải hiểu ý nghĩa cũa các Tags Nó chỉ cần tìm các Tags và xác định rằng đây là một tài liệu XML hợp

lệ Vì browser không cần phải hiểu ý nghĩa của các Tags, nên ta có thể dùng Tag nào cũng được Đó là lý do người ta dùng chữ eXtensible (mở rộng thêm được) trong định nghĩa của XML

2.1.3 Nh ững thành phần của một tài liệu XML

Chúng ta có thể sử dụng trình soạn thảo đơn giản nhất là Notepad để soạn thảo tài liệu XML, nhưng phải tuân thủ theo qui tắc sau:

Theo định dạng trên, chúng ta thấy tuy tài liệu XML rất đơn giản nhưng qui định cũng

rất nghiêm ngặt, có nghĩa là các tài liệu XML đều xuất phát từ nút gốc (root), và mỗi

phần tử phải có thẻ đóng và thẻ mở “< …/>”

- Khai báo: Mỗi một tài liệu XML có một chỉ thị khai báo

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

Đây là chỉ thị xử lý, chỉ thị xử lý được đặt trong cặp Tag <? và ?> Nó cho biết phiên

bản đặc tả XML mà bộ phân tích cần làm theo, ngoài ra nó cho phép người lập trình cho biết dữ liệu trong XML dùng encoding nào, còn thuộc tính standalone sẽ cho biết

tài liệu XML có cần đến một tài liệu khác không (có hai giá trị cho thuộc tính này đó là

“yes” nếu không cần đến một tài liệu khác và “no” nếu cần)

- Chú thích: được khai báo như sau:

<! chú thích >

- Ph ần tử (Elements): Một tài liệu XML được cấu thành từ những phần tử Một

phần tử có thẻ mở và thẻ đóng Giữa thẻ mở và thẻ đóng là nội dung của phần tử

đó Phần tử có thể chứa dữ liệu hoặc có thể lồng vào một phần tử khác

- Ph ần tử gốc (root): Trong tài liệu XML, chỉ có một phần tử gốc, và phần tử

này sẽ chứa tất cả những phần tử của tài liệu XML do chúng ta tạo ra

Theo ví dụ trên, ta thấy phần tử gốc là “Catalog”

- Thu ộc tính (Attributes): Như đã trình bày ở trên, một phần tử có thể chứa dữ

liệu hoặc chứa phần tử khác hoặc cả hai Bên cạnh đó, phần tử có thể rỗng, khi

đó nó có thể chứa thuộc tính Một thuộc tính chỉ là một sự lựa chọn để gắn dữ

liệu đến phần tử Một thuộc tính đặt trong thẻ mở của phần tử và chỉ ra giá trị

một mạng Bluetooth có thể cho phép tối đa lên đến 8 thiết bị kết nối với nhau và được

gọi là một Piconet Các Piconet có thể liên kết được với nhau để hình thành nên một Scatternet Cấu trúc của mạng Bluetooth yêu cầu phải có một thiết bị đóng vai trò quản

lý (master) và các thiết bị còn lại hoạt động phụ thuộc vào master (slave device) Vai trò của các thiết bị trong mạng có thể thay đổi nếu cần thiết

dải tần nhỏ hơn không làm thay đổi tốc độ truyền dữ liệu, tuy nhiên các thiết bị này sẽ

nhạy cảm với nhiễu hơn và các nhiễu này có thể làm gây ra việc giảm tốc độ truyền dữ

liệu của toàn hệ thống

2.2.2 C ấu trúc của bộ giao thức

Hình 3: Cấu trúc bộ giao thức Bluetooth

Hệ thống Bluetooth bao gồm bốn tầng thấp nhất và các giao thức liên quan được định nghĩa trong đặc tả bluetooth cũng như các giao thức chung lớp dịch vụ, giao thức phát

hiện dịch vụ SDP (service discovery protocol) và các profile Một ứng dụng Bluetooth hoàn chỉnh có thể sẽ yêu cầu thêm một vài dịch vụ hay giao thức ở tầng trên mà được định nghĩa trong các đặc tả của bluetooth

H ệ thống điều khiển Bluetooth - Bluetooth controller

Ba lớp thấp nhất trong tầng giao thức đôi khi được nhóm thành một hệ thống con với tên gọi Bluetooth Controller Đây là cách triển khai hệ thống thông dụng nhất đóng vai trò như là một giao diện (interface) truyền thông giữa phần điều khiển bluetooth và phần còn lại của hệ thống bluetooth bao gồm L2CAP và các lớp cao hơn (được biết đến như là Bluetooth host) Đặc tả của Bluetooth cho phép trao đổi thông tin

giữa các hệ thống bluetooth khác nhau bằng cách định nghĩa các bản tin giao thức được trao đổi giữa các tầng tương ứng cũng như giữa các hệ thống con bằng các định nghĩa

một giao diện chung giữa bluetooth controller và bluetooth host

Các giao th ức và báo hiệu của hệ thống lõi

Để tương tác giữa các thiết bị có thể thực hiện thì các tiêu chuẩn tương tác được định nghĩa ra dựa trên các giao thức báo hiệu theo đặc tả của Bluetooth Các giao thức lõi Bluetooth là giao thức sóng vô tuyến RF (Radio Protocol), giao thức kiểm soát kết nối LC( Link Controll), quản lý kết nối LM( Link Manager) và giao thức kiểm soát thích ứng kết nối logic L2CAP( Logical Link Control and Adaption protocol) Ngoài ra thì giao thức phát hiện dịch vụ SDP( Service Discovery Protocol) là một giao thức tầng

dịch vụ mà tất cả các ứng dụng Bluetooth đều phải sử dụng

Hệ thống lõi Bluetooth cung cấp các dịch vụ thông qua một số điểm truy cập dịch vụ, các điểm này trên hình được biểu diễn bằng hình elip Các dịch vụ này chứa các thành

phần cơ bản để điều khiển hệ thống lõi Bluetooth CÁc dịch vụ này có thể chia làm 3

loại Đó là dịch vụ điều khiển thiết bị có nhiệm vụ thay đổi hành vi và chế độ hoạt động của thiết bị Bluetooth, dịch vụ điều khiển truyền tải có nhiệm vụ tạo, thay đổi và

giải phóng các phương tiện truyền tải (kênh truyền và kết nối), và dịch vụ dữ liệu được

sử dụng để kiểm soát dữ liệu cho việc truyền qua các phương tiện truyền tải

Giao di ện giữa phần Host và Controller- Host to Controller Interface (HCI)

Một giao diện dịch vụ tới hệ thống Bluetooth Controller được tạo ra nhằm coi Bluetooth Controller như là một thành phần chuẩn Với cấu hình này thì Bluetooth Controller sẽ vận hành ba tầng thấp nhất và L2CAP được chứa trong phần còn lại của ứng dụng Bluetooth trong host system Giao diện chuẩn này được HCI (host to controller interface) HCI 3cung cấp một3 3giao3 3diện3 3lệnh để3 3điều khiển3 3baseband3 3và3 3quản

lý3 3liên kết3, 3và truy cập3 3đến tình trạng3 3phần3 3cứng3 3và thanh ghi điều khiển3 3Về cơ bản3, 3

giao diện này3 3cung3 3cấp3 3một phương pháp3 3thống3 3nhất3 3truy3 3cập3 3vào3 3HCI3 3Bluetooth3 3

baseband3 3capabilities HCI3 3tồn tại3 3qua3 33 phần3, 3Host -3 3Transport Layer3 3–3 3Host Controller3 3Mỗi3 3bộ phận3 3có một3 3vai trò3 3khác nhau3 3trong hệ thống3 3HCI và v3iệc sử dụng giao diện dịch vụ này là tùy chọn đối với người phát triển

Kh ả năng phát hiện lỗi của lớp L2CAP

Lớp 3baseband3 3cung3 3cấp3 3các3 3giao thức3 3ARQ3 3cơ bản trong3 3công nghệ3 3Bluetooth3 3Các3 3lớp3 3

L2CAP3 3tùy chọ3n có thể cung cấp thêm một phát hiện lỗi và truyền lại các PDU của L2CAP Tính năng này được3 khuyến khích cho3 3các ứng dụng với3 3yêu cầu giảm thiểu

tối đa3 3của các lỗi3 không 3bị phát hiện3 3trong các dữ liệu3 3người dùng3 3Một tính năng3 3tùy3 3

chọn3 3thêm3 3của3 3L2CAP3 3là3 3điều khiển luồng (theo cách thay đổi kích thước cửa sổ bộ đệm)3 3có thể3 3được sử dụng để3 3quản3 3lý3 3cấp3 3phát3 3bộ đệm trong3 3các3 3thiết bị nhận3 3Cả3 3hai3 3

của3 3các tính năng3 3tùy3 3chọn3 3làm3 3tăng3 3thêm3 3việc thực hiện3 3QoS3 3trong các tình huống3 3nhất3 3

định3

Các kh ối chức năng chức năng của hệ thống:

- Channel Manager (qu ản lý kênh truyền): Chức năng quản lý kênh truyền chịu

trách nhiệm cho việc tạo, quản lý và hủy bỏ các kênh L2CAP dùng để vận chuyển các luồng dữ liệu của ứng dụng hay dữ liệu của các dịch vụ Nó sử dụng giao thức L2CAP để tương tác với khối quản lý kênh truyền trên một thiết bị

với các đối tượng thích hợp Khối quản lý kênh truyền tương tác với khối quản

lý kết nối nội bộ (local Link Manager) để tạo ra các liên kết logic và 3cấu hình các3 3liên3 3kết3 này 3để cung cấp3 3QoS3 3cần thiết cho3 3các3 3loại3 3dữ liệu đang được3 3vận chuyển3

- L2CAP Resource Manager( khối quản lý tài nguyên): Khối quản lý tài nguyên L2CAP chịu trách nhiệm cho việc quản lý trình tự việc chuyển các phân mảnh PDU tới băng cơ sở và phân lịch giữa các kênh truyền để đảm bảo kênh truyền L2CAP không từ truyền truy cập tới kênh truyền vật lý vì lý do cạn kiệt tài nguyên của Bluetooth controller L2CAP 3Resource Manager 3 3cũng có thể3 3thực

hiện3 3chính sách3 3lưu lượng3 3phù hợp3 3để đảm bảo3 3rằng các ứng dụng3 3xử lý3 3SDU3 3

trong3 3giới hạn của3 3thiết lập3 3QoS3đã cam kết 3Bluetooth3 3truyền tải dữ liệu3 3chung3 3

mô hình3 3giả định3 3ứng dụng3 3cách cư xử3 3tốt3, 3và không3 3xác định cách3 3thực hiện3 3

một3 3dự kiến sẽ3 3đối3 3phó3 3với3 3vấn đề này

- Device Manager (Khối quản lý thiết bị).4Quản lý thiết bị là các khối chức năng trong baseband kiểm soát hành vi chung của các thiết bị kích hoạt Bluetooth Nó

có trách nhiệm cho tất cả các hoạt động của hệ thống Bluetooth mà không trực

tiếp liên quan đến vận chuyển dữ liệu, chẳng hạn như quá trình dò hỏi sự hiện

diện của các thiết bị đã kích hoạt Bluetooth gần đó, kết nối với các thiết bị Bluetooth khác được kích hoạt hoặc cho phép thiết bị Bluetooth có thể được phát hiện hay kết nối bởi khác thiết bị Khối quản lý thiết bị có thể yêu cầu truy

nhập vào các hạ tầng vận chuyển từ bộ điều khiển tài nguyên baseband để thực

hiện các chức năng của mình, đồng thời nó cũng có thể điều khiển hành vị của các thiết bị cục bộ bằng các lệnh HCI, chẳng hạn như quản lý tên thiết bị địa phương, bất kỳ phím liên kết được lưu trữ, và chức năng khác

- Link Manager: Chức năng quản lý kết nối chịu trách nhiệm cho việc tạo, thay đổi và giải phóng các kết nối logic cũng như cập nhật các thông số liên quan đến

kết nối vật lý giữa các thiết bị Nó 3đạt được điều này3 3bằng3 3cách3 3giao3 3tiếp3 3với

khối quản lý liên kết trong các thiết bị3 3Bluetooth3 3khác sử dụng3 3giao thức3 3quản3 3lý3 3

liên kết3 3(3LMP) LMP 3cho phép3 3tạo ra3 3các liên kết3 logic 3mới3 và các đường 3vận chuyển3 logic4 4 3giữa các thiết bị3 3khi3 3có3 3yêu3 3cầu3, 3cũng như kiểm soát3 3các thuộc tính3 3

liên kết và3 3vận tải nói chung, như3 3sự3 3cho phép3 3mã3 3hóa3 3trên kết nối vận chuyển3logic, khả năng 3thích ứng với3 3công suất truyền3 của3 kết3 nối 3vật lý hay3 3điều chỉnh3 3

các thiết lập QoS3 3cho một3 3liên kết logic

- Baseband Resource Manager (khối quản lý tài nguyên tầng baseband): 4Chức năng quản lý tài nguyên tầng baseband 3chịu trách nhiệm về3 3tất cả các truy cập3 3

vào phương tiện3 3truyền3 3Nó có hai3 3chức năng chính3 T3rung tâm của nó3 3là3 3một bộ

lập lịch trình3 3cấp3 3thời gian3 3trên3 3các kênh3 3vật3 3lý3 3cho tất cả3 3các3 3đối3 3tượng3 muốn truy cập kênh truyền 3Chức năng chính3 3khác3 3là đàm phán3 3hợp3 3các thỏa thuận truy nhập với các đối tượng này3 Một thỏa thuận là cam kết đưa ra một chất lượng dịch vụ QoS nhằm cung cấp cho các ứng dụng người dùng một hiệu năng như dự kiến

- Link Controller (bộ điều khiển kết nối) chịu trách nhiệm cho việc mã hóa và

giải mã các gói tin Bluetooth phần data payload và các tham số liên quan đến kênh truyền vật lý, logic và các kết nối logic Link controller chịu trách nhiệm báo hiệu các giao thức quản lý kết nối (hoạt động chặt chẽ với chức năng lập lập

biểu của bộ phận quản lý tài nguyên), được sử dụng trong việc nhận, gửi các tín

hiệ điều khiển luồng, báo nhận và tín cầu gửi lại

- RF: khối RF chịu trách nhiệm cho việc truyền và nhận các gói thông tin từ đường truyền vật lý Một đường điều khiển giữa khối baseband và RF cho phép baseband điều khiển các tham số thời gian và tần số sóng mang của RF Khối

RF biến đổi luồng dữ liệu đến (từ) kênh truyền vật lý cũng như baseband thành các định dạng theo yêu cầu

2.2.3 Baseband

Baseband là một phần của hệ thống Bluetooth làm nhiệm vụ thực hiện các truy cập và các thủ tục của lớp vật lý giữa các thiết bị sử dụng Bluetooth Hai hoặc nhiều hơn các thiết bị chia sẻ chung một kênh truyền vật lý hình thành nên piconet Một thiết bị

Bluetooth đóng vai trò chính trong việc quản lý mạng (sau đây gọi là master) và các

thiết bị còn lại gọi là slave Có thể có tối đa 7 slave trong một piconet,

Hình 4: Các dạng mạng Bluetooth

Baseband cung cấp hai loại kết nối là: SCO và ACL

- Synchronous Connection Oriented (SCO)

o SCO là một kết nối point-to-point giữa một master và một slave trong piconet

o Một Master hỗ trợ tối đa 3 kết nối SCO đồng thời trong khi các slave có

thể hỗ trợ 2 hoặc 3 kết nối

o Các gói tin SCO không bao giờ được truyền lại và thường được sử dụng trong các ứng dụng hạn chế về mặt thời gian như voice, audio

o Được sử dụng trong truyền tiếng nói 64Kbps

o Kết nối SCO có thể được xem như một kết nối chuyển mạch

- Asynchronous Connectionless (ACL):

o Là một kết nối Point-to-multipoint giữa master và các slave trong piconet

o Trên các slot mà không dành để cho SCO truyền, master vẫn có thể thiết

lập kết nối ACL với bất kỳ slave nào, bao gồm cả các slave đang trong giao tiếp SCO

o Không giống như SCO có thể thiết lập được nhiều kết nối SCO, chỉ có

một kết nối Acl duy nhất được thiết lập giữa hai node

o Các gói tin ACL luôn luôn được truyền lại khi bị mất

2.2.3.1 Định dạng gói tin

Mỗi gói tin bao gồm 3 phần là Access code (72 bits) , header (54 bits) và payload

(0-2745 bits)

Hình 5: Định dạng gói tin Bluetooth

- Access code: Dùng để đồng bộ hóa, dùng trong quá trình tìm kiếm thiết bị và yêu cầu kết nối Có 3 loại khác nhau của Access code: Channel Access Code (CAC), Device Access Code (DAC) and Inquiry Access Code (IAC) CAC dùng để xác định một piconet duy nhất, DAC dùng để thực hiện yêu cầu kết nối, IAC dùng để thực hiện tìm kiếm thiết bị

- Header: Chứa một số thông tin về packet như thứ tự của packet, địa chỉ đích,

kiểm lỗi, v.v…

2.2.3.2 Các lo ại địa chỉ trong hệ thống Bluetooth

Có 4 loại địa chỉ khác nhau có thể gán cho một thiết bị Bluetooth, đó là BD_ADDR, AM_ADDR, PM_ADDR, AR_ADDR

- BD_ADDR: Bluetooth Device Address Là 48 bit địa chỉ MAC theo tiêu chuẩn IEEE quy định (Giống như địa chỉ MAC trên mỗi card mạng), xác định duy

nhất 1 thiết bị Bluetooth trên toàn cầu, trong đó 3 byte cho nhà sản xuất thiết bị

và 3 byte cho sản phẩm

- AM_ADDR: Active Member Address: Nó là một con số 3 bit dùng để phân

biệt giữa các active slave tham gia trong 1 piconet 2 3 = 8 nên có tối đa 7 Slave active trong 1 piconet, còn 000 là địa chỉ Broadcast (truyền đến tất cả các thành viên trong piconet) Địa chỉ này chỉ tồn tại khi Slave ở trạng thái active

- PM_ADDR: Parked Member Address Là một con số 8 bit, phân biệt các parked Slave Do đó có tối đa 255 thiết bị ở trạng thái parked Địa chỉ này chỉ

tồn tại khi Slave ở trạng thái parked

- AR_ADDR: Access Request Address Địa chỉ này được dùng bởi parked Slave để xác định nơi mà nó được phép gửi thông điệp yêu cầu truy cập tới

Với trạng thái Connection, master và slave thực hiện việc trao đổi thông tin, sử dụng

mã truy nhập kênh truyền CAC và đồng hồ của master

Thông thường một kết nối giữa hai thiết bị sẽ xảy ra theo các trường hợp sau: nếu một thiết bị không có thông tin nào về thiết bị kia thì cả hai quá trình inquiry và page đều

phải được thực hiện Và nếu như một thiết bị biết một số thông tin về thiết bị kia thì chỉ

1.3: Thiết bị nhận được gói tin inquiry sẽ chuyển sang trạng thái inquiry response

và gửi gói tin phản hồi lại nguồn phát inquiry

Sau khi quá trình inquiry đã hoàn thành, thủ tục paging được sử dụng để thiết lập kết

nối

Bước 2:

Với quá trình paging, một kết nối thực sự sẽ được thiết lập Quá trình paging

thường diễn ra sau quá trình inquiry và đòi hỏi duy nhất địa chỉ Bluetooth của thiết bị để thực hiện tạo kết nối Thông tin về đồng hộ sẽ giúp đẩy nhanh quá

trình tạo kết nối Thiết bị khởi tạo kết nối sẽ thực hiện quá trình paging và tự động trở thành master của kết nối Quá trình thực hiện như sau:

2.1: Thiết bị nguồn gửi gói tin page một thiết bị

khác

3Page stateU

2.2: Thiết bị đích nhận được gói tin page 3Page Scan state3

2.3: Thiết bị gửi lại gói tin phản hồi 3Slave Response state3:

2.4: Thiết bị nguồn nhận được gói phản hồi, gửi lại

gói tin FHS

3Master Response state3

2.5: Thiết bị đích gửi lại phản hồi 3Slave Response state3

2.6: Thiết bị đích và nguồn chuyển sang các thông

số kênh truyền của thiết bị nguồn

3Master Response state3:

& 3Slave Response state3

Trạng thái Connection được bắt đầu với một gói tin POLL được gửi bởi master nhằm xác định slave đã chuyển qua các tham số thời gian, tần số của master chưa Slave có

thể phản hồi với bất kỳ gói tin nào

2.2.4 Link Management Protocol (LMP)

Giao thức LMP chịu trách nhiệm cho việc khởi tạo và kiểm soát các kết nối giữa các thiết bị bluetooth, bao gồm việc điều khiển và điều chỉnh kích thước của các gói tin baseband Nó cũng được sử dụng cho bảo mật, xác thực và mã hóa; khởi tạo, trao đổi,

kiểm tra các kết nối và key dùng để mã hóa LMP cũng điều khiển các chế độ công

suất và vài trò của các thiết bị bluetooth cũng như trạng thái kết nối của các thiết bị trong một piconet

Do các bản tin LMP được lọc và trích xuất thông tin bởi LMP bên phía nhận nên chúng không bao giờ được chuyển lên các layer cao hơn Các bản tin LMP có mức ưu tiên cao hơn các dữ liệu của người dùng Nếu một LMP cần gửi một bản tin, nó sẽ không bị các dữ liệu của L2CAP làm chậm lại Thêm vào đó, các bản tin LMP đều không được báo nhận (ACK) do đường truyền logic đã cung cấp đủ độ tin cậy nên việc báo nhận là không cần thiết

2.2.5 Logical Link Control and Adaptation Protocol (L2CAP)

Mô t ả

Tầng L2CAP hỗ trợ các giao thức lớp trên trong việc dồn kênh(multiplexing), phân đoạn gói tin (segmentation), tái tổ hợp gói (re-assembly) và chuyên chở các thông tin

về QoS L2CAP cho phép các giao thức và ứng dụng lớp trên truyền và nhận các gói

dữ liệu L2CAP SDU có kích thước tối đa lên đến 64kB L2CAP đồng thời cũng cho phép điều khiển luồng trên từng kênh riêng rẽ cũng như chức năng gửi lại các gói tin

đã mất.L2CAP cung cấp các kênh truyền logic (L2CAP channel) đã được ánh xạ vào các liên kết được hỗ trợ bởi một ACL

Lớp L2CAP được dựa trên khái niệm về các kênh truyền Mỗi một điểm cuối (end point) của một kênh truyền L2CAP được tham chiếu đến bởi một CID (channel identifier)

từng thiết bị và một thiết bị có thể gán các CID độc lập với các thiết bị khác (ngoại trừ

một số CID dành riêng, ví dụ như kênh báo hiệu)

Hình 6: Cấu trúc của L2CAP

Phân kênh giao th ức:

L2CAP phải hỗ trợ việc phân kênh giao thức vì tầng Baseband không hỗ trợ trường

“type” để xác định các giao thức lớp trên nào đang hoạt động trên nó L2CAP phải có

khả năng phân biệt các giao thức lớp trên như là SDP, RFCOMM và Telephony Control

Segmentation & Reassembly

So sánh với các phương tiện truyền dẫn vật lý khách, các gói dữ liệu được định nghĩa

bởi giao thức tầng Baseband bị hạn chế về kích thước Việc gửi các gói tin có MTU tương ứng với payload lớn nhất của tầng baseband (341 byte) sẽ làm hạn chế khả năng tận dụng băng thông của các giao thức lớp cao hơn vốn được thiết kế để sử dụng

các gói tin kích thước lớn Các gói L2CAP phải được phân mảnh thành các gói tin nhỏ hơn cho tầng baseband truyền đi Tương tự, các gói tin của tầng Baseband có thể được tái tổ hợp thành một gói tin L2CAP kèm theo việc kiểm tra tính toàn vẹn của nó Chức năng phân đoạn và tái tổ hợp thật sự cần thiết để hỗ trợ các giao thức sử dụng các gói tin có kích thước lớn hơn là sự hỗ trợ từ Baseband

Quality of Service

Quá trình thiết lập liên kết L2CAP cho phép trao đổi thông tin về chất lượng dịch vụ (QoS) mong muốn giữa các thiết bị Bluetooth Các triển khai L2CAP phải theo dõi các tài nguyên được sử dụng bởi giao thức và đảm bảo rằng các cam kết về QoS được thực

hiện

2.2.6 Các ch ế độ làm việc trong hệ thống Bluetooth

Một thiết bị Bluetooth trong trạng thái Connection có thể ở một trong bốn chế độ sau: Active, Hold, Sniff và Park

- Active Mode If an active slave is not addressed, it may sleep until the next new

master transmission Trong chế độ Active, thiết bị bluetooth tham gia vào các

hoạt động trên kênh truyền Master lập lịch trình việc truyền phát dựa trên các yêu cầu lưu lượng tới và đến các slave khác nhau Thêm vào đó, nó hỗ trợ các thông tin liên lạc cơ bản để giữ slave đồng bộ với kênh truyền Các active slave

lắng nghe trên các khe thời gian master-to-slave để nhận các gói tin

- Sniff Mode: Thiết bị 3đồng bộ3 3để3 3piconet3 3có thể nhập vào3 3chế độ tiết kiệm3 3điện3, trong đó 3hoạt động3 3của3 3thiết3 3bị3 3được hạ xuống3 T3rong3 3chế độ3 3SNiFF3, 3một thiết

bị3 3slave3 3lắng nghe3 3các3 3piconet3 3với tốc độ3 3giảm3, 3do3 3đó3 3làm giảm3 3chu kỳ nhiệm vụ3 3

của nó3 3Khoảng thời gian3 3SNiFF3 3có thể lập trình3 3và phụ thuộc3 3vào ứng dụng3 3Nó3 3

có3 3chu kỳ nhiệm vụ3 3cao nhất (ít tiết kiệm năng lượng nhất) trong ba chế độ tiết

- Hold mode: Thiết bị 3đồng bộ3 3để3 3piconet3 3có thể nhập vào3 3chế độ tiết kiệm3 3điện3, trong đó 3hoạt động3 3của3 3thiết3 3bị3 3được hạ xuống Thiết bị Master có thể đưa các slave vào chế độ HOLD, chế độ chỉ có bộ đếm thời gian nội bộ hoạt động Thiết

bị slave cũng có thể yêu cầu để đưa về chế độ HOLD Việc truyền dữ liệu được

khởi động lại ngay lập tức khi các thiết bị thoát khỏi chế độ HOLD Chế độ này

có chu kỳ nhiệm vụ trung bình trong ba chế độ tiết kiệm năng lượng (sniff, hold

và park)3

- Park Mode: Trong chế độ PARK, một thiết bị vẫn đồng bộ với piconet nhưng không tham gia vào truyền nhận dữ liệu Thiết bị trong chế độ PARK bỏ địa chỉ AM_ADDR của nó và không thường xuyên lắng nghe các thông tin từ master

để tái đồng bộ và kiểm tra các gói tin broadcast Chế độ này có chu kỳ nhiệm vụ

thấp nhất (tiết kiệm năng lượng nhất) trong ba chế độ tiết kiệm (sniff, hold và park)

K ết luận: Trong chương này luận văn đã giới thiệu về các cách biểu diễn dữ liệu cũng

như những thành phần cơ bản của một tài liệu XML - định dạng làm nên RSS, và các đặc điểm, cấu trúc của bộ giao thức Bluetooth Trong chương tiếp theo, luận văn sẽ trình bày về thiết kế của hệ thống sẽ được xây dựng từ bài toán đồng bộ dữ liệu đặt ra ban đầu

Chương 3 XÂY DỰNG HỆ THỐNG

Hiện nay các phần mềm đọc RSS trên điện thoại cũng như trên máy tính có rất nhiều

và cũng làm rất tốt việc tổ chức, quản lý các bookmark Tuy nhiên trong hoàn cành người dùng sử dụng di động để đọc tin tức và di chuyển nhiều thì chưa có một phần

mềm nào đưa ra giải pháp cho phép đồng bộ dữ liệu giữa hai hệ thống chạy trên máy tính và di động để người sử dụng có thể truyền tải nội dung từ PC sang di động với

mục đích đọc trong khi đi lại và ngược lại, truyền tải nội dung từ di động sang PC để đọc do PC có màn hình to hơn, độ phân giải tốt hơn…

Vì vậy bài toán đặt ra là xây dựng một hệ thống bao gồm hai thành phần: một phần

chạy trên máy tính và một chạy trên thiết bị di động Hai phần này vừa có khả năng

hoạt động độc lập như một phần mềm đọc tin RSS độc lập, vừa có khả năng đồng bộ

dữ liệu với nhau dựa trên một giao thức đồng bộ được thiết kế riêng

Chương này sẽ đề cập đến vấn đề thiết kế hệ thống để giải quyết bài toán nêu trên và

phần giao thức đồng bộ sẽ được trình bày trong chương tiếp theo

3.1 Các v ấn đề cần giải quyết

Theo yêu cầu của bài toán đặt ra, hệ thống gồm hai thành phần hoạt động độc lập như

những phần mềm đọc tin RSS bình thường do đó ngôn ngữ được chọn để xây dựng hệ

thống là java do khả năng sử dụng lại mã nguồn cao cũng như khả năng chạy đa nền

của nó Khi sử dụng java để xây dựng hệ thống này sẽ gặp nhiều các khó khăn như sau

3.1.1 Các v ấn đề chung khi viết phần mềm cho thiết bị di động:

Khi xây dựng một ứng dụng cho điện thoại di động thường hay gặp phải các khó khăn sau:

Vấn đề - Tốc độ của các thiết bị di động