Multicast và giải pháp triển khai dịch vụ IPTV trong mạng của VNPT

Trái với điều này là khả năng tìm kiếm metadata đối với các định dạng âm thanh và hình ảnh trong các hệ thống chia sẻ dữ liệu gần đây như Kazaa [Kazza03] và Limewire [Limewire03].. 1.2.3

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

i

MỤC LỤC MỤC LỤC I

DANH MỤC CÁC TỪ VIẾT TẮT VI

DANH MỤC CÁC HÌNH VẼ VII

DANH MỤC CÁC BẢNG XI

MỞ ĐẦU XII

CHƯƠNG 1 GIỚI THIỆU 1

1.1 Các hệ thống chia sẻ file giải quyết các vấn đề gì? 1

1.2 Các nhược điểm của các hệ thống chia sẻ file 2

1.2.1 Tìm kiếm không đầy đủ 3

1.2.2 Giói hạn các định dạng phổ biến 3

1.2.3 Các cộng đồng bị phân chia 4

1.3 Mục đích 4

1.4 Phương pháp 5

1.4.1 Cải thiện việc tìm kiếm 5

1.4.2 Đơn giản việc tạo và dò tìm cộng đồng 7

1.5 Những đóng góp 9

1.5.1 Cải thiện tìm kiếm 9

1.5.2 Đơn giản hóa việc tạo và dò tìm cộng đồng 10

1.6 Tổng quan luận văn 12

CHƯƠNG 2 MÔ TẢ Ý TƯỞNG 14

2.1 Giới thiệu 14

2.2 Tìm kiếm 15

2.2.1 Metadata 15

2.2.2 Định tuyến truy vấn 20

2.2.3 Các cộng đồng 25

2.2.4 Tìm kiếm các hệ thống trung tâm cục bộ 29

2.3 Tạo và dò tìm các cộng đồng 36

2.3.1 Cộng đồng không trong suốt 37

2.3.2 Cộng đồng có giới hạn 38

2.3.3 Cộng đồng ẩn 40

2.3.4 Cộng đồng không chia sẻ 40

2.3.5 Cộng đồng cục bộ 41

2.4 Các tham số khác của các hệ thống chia sẻ file 43

2.4.1 Các phân loại khác đối với hệ thống mạng ngang hàng 44

2.4.2 Kiến trúc mạng 46

2.4.3 Các hệ thống có cấu trúc 48

2.4.4 Nặc danh và việc kiểm soát 50

2.5 Kết luận 52

2.5.1 Các yếu điểm của các phương thức tìm kiếm đã có 53

2.5.2 Khó khăn trong việc tạo và dò tìm các cộng đồng 54

2.5.3 Lý do tìm kiếm và vấn đề các cộng đồng 56

CHƯƠNG 3 KHÁI NIỆM VỀ CỘNG ĐỒNG CHIA SẺ FILE 58

3.1 Như thế nào là cộng đồng: Thiết kế lược đồ cộng đồng 58

3.2 Các thuộc tính của các cộng đồng chia sẻ file 59

3.2.1 Tên 59

3.2.2 Định dạng 59

3.2.3 Giao thức 60

3.2.4 Hiển thị 60

3.2.5 Các tham số khác 61

3.3 Cộng đồng như lớp/Cộng đồng như đối tượng 63

3.4 Kết luận 66

CHƯƠNG 4 THIẾT KẾ SNS-P2P 68

4.1 Giới thiệu 68

4.2 Tổng quan 69

4.3 Các lược đồ và việc lựa chọn lược đồ XML 70

4.4 Metadata được cải tiến 71

4.5 Thiết kế bộ tương thích Web: tìm kiếm cải tiến 74

4.6 Việc dò tìm và tạo cộng đồng được đơn giản hóa 82

4.7 Thiết kế nơi lưu trữ 87

4.7.1 Các tương tác 90

4.7.2 Cơ sở dữ liệu XML 93

4.8 Thiết kế bộ tương thích mạng 95

4.8.1 Các Tương Tác 97

4.8.2 Giao thức 100

4.9 Kết luận 104

CHƯƠNG 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 106

5.1 Các đóng góp 106

5.2 Hướng phát triển 109

THAM KHẢO 113

A PHỤ LỤC: SƠ LƯỢC VỀ LƯỢC ĐỒ XML 129

A.1 Các phần tử 130

A.2 Các thuộc tính 131

A.3 Các loại đơn giản 131

A.4 Các loại phức 133

A.5 Các loại kéo theo 135

CMIP

Common Management Information Protocol Giao thức thông tin quản lý chung DHT Distributed Hash Tables Các bảng băm phân tán

DTD Document Type Definition Lược đồ định loại văn bản

XML Extensible Markup Language Ngôn ngữ đánh dấu mở rộng

URL Uniform Resource Locator Địa chỉ định vị tài nguyên

XSLT

Extensible Stylesheet Language Transformations Chuyển đổi ngôn ngữ mẫu mở rộng

DANH MỤC CÁC HÌNH VẼ

Hình 1: Bố trí bên trong của File được đính thẻ ID3v1[Nilson00] 17

Hình 2: Mô hình JxtaSearch 18

Hình 3 Ví dụ không gian truy vấn text đối với các tài liệu về “SNS-P2P” 19

Hình 4: Mô hình mạng ngang hàng lai 21

Hình 5: Mô hình Gnutella (Không tập trung) 22

Hình 6: Hai phương pháp định tuyến truy vấn 24

Hình 7: Mô hình Alpine 26

Hình 8: Mô hình Peer-to-peer liên kết 28

Hình 9: Tìm kiến vs Cục bộ 30

Hình 10: Đinh tuyến truy vấn FASD 35

Hình 11: Loại file hỗ trợ trong Kazaa và Limewire 39

Hình 12: Mô hình Superpeer 47

Hình 13: Tìm kiếm theo khóa Chord 49

Hình 14: Cấu trúc chung của mô hình đối model [Cointe87] 64

Hình 15: Mối quan hệ giữa các cộng đồng và các file 65

Hình 16: Lược đồ đơn giản cho các cộng đồng 67

Hình 17: Truyền thông giữa các client SNS-P2P 69

Hình 18: A schema for the "mp3-nap" community 72

Hình 19: An XML file described by the "mp3-nap" schema 72

Hình 20: So sánh SNS-P2P với mô hình tương tác người dùng hiện có 76

Hình 21: Một lược đồ đơn giản 77

Hình 22: Một Form đơn giản 78

Hình 23: Vai trò của XSL trong SNS-P2P 79

Hình 24: Việc tạo ra giao diện tạo mới từ một lược đồ XML 80

Hình 25: Việc tạo ra giao diện hiển thị từ một trường hợp XML 81

Hình 26: Một lược đồ cho các cộng đồng (community.xsd) 83

Hình 27: Cộng đồng gốc (community.xml) 84

Hình 28: File cộng đồng cho cộng đồng “mp3-nap” 86

Hình 29: Cấu ttrúc nơi lưu trữ 88

Hình 30: Các ID nguồn trong SNS-P2P 89

Hình 31: Các tương tác với nơi lưu trữ 92

Hình 32: Các tương tác với bộ tương thích mạng 100

Hình 33: Trình tự bản tin công bố 102

Hình 34: Trình tự bản tin tìm kiếm 103

Hình 35: Stamps.xsd – Lược đồ cho cộng đồng Stamp Error! Bookmark not defined Figure 36: default-resource-create.xsl: Stylesheet mặc định cho việc tạo form Error!

Bookmark not defined

Hình 37: Đầu ra HTML của create.jsp được trả lại trình duyệt Error! Bookmark not

defined

Hình 38: Lược đồ lớp cho WebAdapter và việc thực thi [Arthorne02d] Error! Bookmark

not defined

Hình 39: Vai trò của Servlets và JSPs trong SNS-P2P [Arthorne02d] Error! Bookmark

not defined

Hình 40: Cấu trúc dữ liệu bên trong đối với việc giải quyết các IDs tài nguyên Error!

Bookmark not defined

Hình 41: Cấu trúc dữ liệu bên trong cho các file cục bộ trong server trung tâm Error!

Bookmark not defined

Hình 42: Vai trò của DownloadServlet và các thành phần DatabaseViewer Error!

Bookmark not defined

Hình 43: Lược đồ lớp cho nơi lưu trữ việc và việc thực thi [Arthorne02d] Error!

Bookmark not defined

Hình 44: Sơ đồ lớp cho PeerNetworkAdapter và thực thi [Arthorne02d] Error!

Bookmark not defined

Hình 45: Ví dụ về bản tin SearchRequest Error! Bookmark not defined Hình 46: Ví dụ bản tin SearchResponse với các kết quả Error! Bookmark not defined Hình 47: Ví dụ bản tin SearchResponse không có kết quảError! Bookmark not defined Hình 48: Ví dụ bản tin RegisterRequest (đăng kí khởi tạo) Error! Bookmark not

Hình 52: Ví dụ bản tin RegisterResponse (tài nguyên xác định) Error! Bookmark not

defined

Hình 53: Ví dụ bản tin RegisterResponse (các tài nguyên loại bỏ/tái đăng kí) Error!

Bookmark not defined

Hình 54: Thời gian công bố một phải nghịch đảo với số file Error! Bookmark not

Hình 58: Thời gian để lưu trữ tài nguyên vào cơ sở dữ liệu client nghịch đảo với số file

Error! Bookmark not defined Hình 59: Thời gian để công khai từ Client tới Server tỉ lệ nghịch với số file Error!

Bookmark not defined

Hình 60: Trình tự bản tin công khai Error! Bookmark not defined Hình 61: Thời gian để tìm kiếm tài nguyên Server tỉ lệ nghich với số file Error!

Bookmark not defined

Hình 62: Thời gian để lưu trữ vào cơ sở dữ liệu Server tỉ lệ nghich với số file Error!

Bookmark not defined

Hình 63: So sánh tổng thời gian công khai và thời gian cho các hoạt động server Error!

Bookmark not defined

Hình 64: Thời gian tìm kiếm với số file cố định Error! Bookmark not defined Hình 65: Thời gian tìm kiếm tỉ lệ nghịch với số file Error! Bookmark not defined Hình 66: Các hoạt động liên đến việc tìm kiếm một file Error! Bookmark not defined Hình 67: Thời gian tìm kiếm DB của server so với với tổng thời tìm kiếm Error!

Bookmark not defined

Hình 68: Thời gian công khai với sự hiện diện cộng đồngError! Bookmark not defined Hình 69: Tác động của các cộng đồng khác đến thời gian thêm fileError! Bookmark not

defined

DANH MỤC CÁC BẢNG

Bảng 1: Tóm lược các phương pháp đã có đối với các cộng đồng 42

Bảng 2: Các đặc tính máy chủ Error! Bookmark not defined

CHƯƠNG 1 GIỚI THIỆU

1.1 Các hệ thống chia sẻ file giải quyết các vấn đề gì?

Có thể nói các hệ thống chia sẻ dữ liệu phải xử lý rất nhiều vấn đề mà chúng ta không nhận thấy Ví dụ, làm thế nào để có thể truy nhập dữ liệu suốt 24 giờ hay làm sao tìm ra không gian lưu trữ hàng triệu file hoặc giảm tải trên các máy chủ Giải pháp cho tất cả các vấn đề trên sẽ mang lại thuận lợi cho hàng ngàn máy tính

PC đang được xem ở “tình trạng cấp bách của Internet”

Lượng thông tin có nhiệm vụ chuyển từ các máy chủ - máy tính có cấu hình mạnh với ổ cứng dung lượng lớn và các bộ vi xử lý cao đến các PC client cấu hình kém hơn Tuy nhiên các máy tính ở biên Internet cũng có các ổ cứng dung lượng lớn,

bộ vi xử lý mạnh, và việc truy nhập internet băng rộng của nhiều máy tính đó phổ biến là có băng thông rộng Sự kết hợp này đồng nghĩa với việc các máy tính ở biên phải được trang bị tốt để tự chúng trở thành các máy chủ

Napster [Napster02] được xem như khởi đầu vấn đề bằng việc chuyển mỗi máy tính cấu hình mạnh thành các máy chủ Napster kết nối tất cả các máy chủ này thành một siêu máy chủ khổng lồ với băng thông và không gian lưu trữ rộng Tính phổ biến của chúng không thể tách rời tính phổ biến của định dạng âm thanh MP3 MP3 đánh dấu một điểm nhấn mang tính quy mô và chất lượng: người sử dụng có thể tải một bài hát có chất lượng CD trong khoảng vài phút đến vài giây tuỳ thuộc vào chất lượng kết nối của chúng

Napster cho phép người dùng kết nối với nhau để mang lại hiệu quả cao hơn Sự phong phú của các host hiện có đồng nghĩa với việc các mô hình sử dụng không liên tục bởi các host riêng lẻ không ảnh hưởng đến sự tồn tại phổ biến của các file: thông thường có một vài người truy nhập trực tuyến các file mà bạn muốn Ngoài

ra, tải của mạng giảm vì tốc độ tải tốt nhất từ người sử dụng ở gần bạn trên mạng Vượt trên hàng ngàn người sử dụng mang một máy chủ đơn đến điểm nối, yêu cầu được cân bằng trên các nút lưu giữ bản sao của các file Và mỗi lần tải thành công

sẽ thêm các host khác vào danh sách

Việc hợp nhất môi trường chia sẻ dữ liệu Napster phân nhỏ thành vô số các ứng dụng khác nhau Những ứng dụng phát sinh này sẽ là câu trả lời cho một vài điểm yếu của Napster, quan trọng nhất là điểm lỗi trung tâm được miêu tả nhờ có một máy chủ trung tâm lưu giữ cơ sở dữ liệu của các file và vị trí của chúng Các hệ thống cũng mở rộng các file vốn có thành hình ảnh, tài liệu, … Ngày nay, thế giới chia sẻ dữ liệu là sinh động mặc dù có thuê Napster Nó sẽ di chuyển xa khỏi các vấn đề ban đầu về sự không tinh vi, cân bằng tải và không gian lưu trữ thành một loạt các vấn đề mới nảy sinh từ thành công to lớn của nó

1.2 Các nhược điểm của các hệ thống chia sẻ file

Napster bộc lộ rất nhiều nhược điểm với phương pháp tập trung Gnutella [Kan01]

là một đáp ứng bản năng mang lại phương pháp đối lập với việc loại bỏ hoàn toàn bất cứ sự kiểm soát tập trung nào Các ứng dụng chia sẻ dữ liệu khác chiếm giữ vị trí giữa mà ở đó các máy tính có cấu hình cực mạnh có thể trở nên cân bằng hơn các máy khác hình thành kiểu phân cấp các nút Freenet[Clarke00] thực hiện phương pháp phi tập trung cũng như chú trọng vào việc chống lại sự kiểm duyệt

và nặc danh mà là một phần yếu điểm của các hệ thống khác Ở đây, chúng ta thảo luận vài điểm yếu của các hệ thống chia sẻ dữ liệu liên quan đến đồ án này

1.2.1 Tìm kiếm không đầy đủ

Napster dựa vào hai trường đơn giản, “artist” và “title”, như là thẻ xác định về nội dung của dữ liệu Các trường này thường được so sánh với các tên file để tìm ra sự phù hợp [Donfest01] Tên file, mặc dù được tạo và hiểu một cách đơn giản nhưng không phải là nguồn metadata hiệu quả nhất Vài vấn đề cơ bản đối với tên file là không gian bị giới hạn và thiếu cấu trúc

Trái với điều này là khả năng tìm kiếm metadata đối với các định dạng âm thanh

và hình ảnh trong các hệ thống chia sẻ dữ liệu gần đây như Kazaa [Kazza03] và Limewire [Limewire03] Các hệ thống này cho phép người sử dụng xác định rõ từ then chốt cho các thuộc tính riêng biệt của các file như là “artist” và “title” Không may là đối với các định dạng ít được biết đến thì việc tìm kiếm tên file vẫn là mặc định Thậm chí đối với các loại phổ biến như MP3 thì không thể tìm được thông tin quan trọng

1.2.2 Giói hạn các định dạng phổ biến

Napster xác định yêu cầu của một cộng đồng đặc trưng: mọi người cùng chia sẻ các file âm thanh MP3 Kể từ đó, việc hỗ trợ các định dạng khác được thêm vào trong các ứng dụng liên tiếp: hình ảnh, ứng dụng, tranh , … Thiếu may mắn là các nhà thiết kế ứng dụng kiểm soát danh sách các định dạng được hỗ trợ Ngày nay không thể tạo ra cộng đồng một cách nhanh chóng nhằm chia sẻ các định dạng ngoài danh sách nhỏ bé này

Các ứng dụng như Napster và Kazaa rõ ràng hỗ trợ một vài định dạng khác nhau nhưng không thể dễ dàng được mở rộng để hỗ trợ các định dạng mới Sự hiểu biết

1.2.3 Các cộng đồng bị phân chia

Một điểm không thuận lợi khác để thực hiện ý tưởng là việc phân mảnh của các cộng đồng chia sẻ dữ liệu, mỗi ứng dụng như một ốc đảo Không có phương pháp nào để khẳng định liệu một cộng đồng người dùng với các mối quan tâm chung hiện có khác hơn so với hay các phương thức tìm kiếm đặc thù, không theo thể thức Vấn đề này có thể dẫn đến người sử dụng tạo lại hệ thống hơn là việc tận dụng ưu điểm của các cộng đồng đã có Không có cơ chế chuẩn cho việc tìm kiếm cộng đồng Điều này cho phép người sử dụng nhận thấy cộng đồng nhờ chỉ rõ ngữ nghĩa kiểu cộng đồng mà họ tìm kiếm

1.3 Mục đích

Đố án này đưa ra một khung ứng dụng mới lạ gọi là Ngang hàng phổ Searching and Sharing Peer-to-Peer (SNS-P2P) tập trung vào những nhược điểm trong các hệ thống chia sẻ dữ liệu đã được trình bày ở trên Có hai mục tiêu chính:

biến-1 Cải thiện khả năng tìm kiếm trong các hệ thống chia sẻ dữ liệu ngang hàng

2 Việc tạo và tìm kiếm các cộng đồng chia sẻ dữ liệu mới sẽ dễ dàng hơn

Sử dụng metadata có cấu trúc chính là nền tảng chính cho cả hai mục tiêu trên

SNS-P2P chỉ rõ một lớp metadata có thể được thực hiện đầu tiên của cơ sở hạ tầng mạng ngang hàng Nó làm cho việc tạo metadata dễ dàng và đảm bảo rằng metadata tuân theo một cấu trúc mong muốn là một phần quan trọng trong việc tìm kiến metadata SNS-P2P cải thiện việc tìm kiếm nhờ đưa ra metadata và xử lý một loạt các truy vấn metadata Mục tiêu đầu tiên của vấn đề cải thiện việc tìm kiếm metadata là điều kiện tiên quyết cho mục tiêu thứ hai, đơn giản hóa việc tạo

và chia sẻ cộng đồng Việc cải thiện năng lực tìm kiếm theo cách không phụ thuộc vào định dạng làm giảm rào cản cho việc tạo cộng đồng

sẻ dữ liệu Trong SNS-P2P, metadata dành cho các file có định dạng bất kỳ có thể được đọc bằng cách sử dụng các kỹ thuật chuẩn hóa Không có yêu cầu nhằm thực hiện phần mềm theo yêu cầu khách hàng để trích metadata từ mỗi một định dạng mới Kết quả này có thể tăng khả năng tìm kiếm metadata với một loạt các định dạng file

Điều này thu được nhờ sử dụng các file XML Thay vì việc tận dụng các file nhị phân, tất cả các file được “đóng gói” dưới dạng XML Các file nhị phân được đưa vào như là các đường kết nối Metadata XML được lưu trữ trong cơ sở dữ liệu và được so sánh để cung cấp khả năng tìm kiếm nâng cao cho tất cả các file trong cộng đồng Từ các ứng dụng đã tồn tại, SNS-P2P chỉ có thể đổi thành dạng

“.xml” Nhưng một định dạng này là không đủ để thể hiện bất cứ định dạng nào

Sử dụng các lược đồ

Lược đồ xác định cấu trúc của tất cả các file XML được chia sẻ trong SNS-P2P Lược đồ được định rõ là sử dụng ngôn ngữ lược đồ XML chuẩn hóa[W3C01] Mỗi lược đồ chỉ rõ tất cả các trường được đưa ra dưới dạng file XML và các kiểu

dữ liệu của chúng Thông tin này là cơ bản để cải thiện chất lượng tìm kiếm

Trước tiên, có thể sử dụng lược đồ nhằm tự động tạo một giao diện để nhập metadata đối với các file mới Điều này không đảm bảo rằng sẽ nhập được metadata nhưng nếu không có nó thì gần như sẽ không có cơ hội nhập metadata Giản đồ này cũng có thể được sử dụng đảm bảo rằng các file là thích hợp giảm khả năng metadata không đúng dạng Cuối cùng, giản đồ có thể được sử dụng nhằm tự động tạo giao diện cho việc tìm kiếm metadata, cho phép người sử dụng tận dụng được metadata sẵn có để thực hiện mục tiêu tìm kiếm một cách có hiệu quả

Việc sử dụng định dạng ‘‘text’’ chuẩn hóa làm cho người sử dụng dễ dàng xác định được định dạng của chính họ Mỗi định dạng đòi hỏi một phần mềm tuỳ theo yêu cầu của khách hàng, thay vì sử dụng cùng thuật toán để thực hiện chúng

Việc thiết kế giải quyết vấn đề các ứng dụng chia sẻ dữ liệu phổ biến không được đưa ra cho người sử dụng Thay vì đó, chúng được nhúng vào mã ứng dụng Việc cho phép người sử dụng tạo các cộng đồng của chính họ đòi hỏi đưa ra các quyết định và cho phép chúng trở thành đặc trưng SNS-P2P đưa ra một lược đồ sắp xếp các trường mà cộng đồng bao hàm Lược đồ đối với các cộng đồng chỉ ra một định dạng chuẩn (viết dưới dạng XML) cho các file của cộng đồng SNS-P2P Phương thức xác định cộng đồng này mở rộng hơn đối với người sử dụng – cho phép các cộng đồng đã tồn tại được sắp xếp lại hoặc có thể dễ dàng tạo các cộng đồng mới Ngoài ra, các đáp ứng được tạo bên ngoài ứng dụng - thay vì mã hóa cứng chúng, nên ứng dụng phải được làm sáng tỏ và minh chứng cho các đáp ứng đó

Các cộng đồng là các đối tượng

Ý tưởng về cộng đồng trong các ứng dụng đã tồn tại đơn giản là :một ý tưởng Việc tạo một cộng đồng mới là vấn đề thiết kế phần mềm Việc tìm kiếm cộng đồng liên quan đến việc trao đổi với bạn bè, hoặc đọc các bản tin mà dịch vụ là tốt nhất Ý tưởng được thực hiện một cách cụ thể bằng cách diễn đạt cộng đồng như một file XML Một file có thể được thực hiện bằng tay nhờ máy tính dễ dàng hơn một ý tưởng

Ý tưởng cộng đồng là các đối tượng chính là chìa khóa của việc tìm kiếm cộng đồng SNS-P2P Rốt cuộc, cộng đồng SNS-P2P là các ứng dụng chia sẻ dữ liệu với khả năng tìm kiếm và tải các file Như là một đối tượng, cộng đồng có thể tận

dụng từ cùng cơ sở hạ tầng mạng Việc tìm kiếm một cộng đồng đòi hỏi mô tả cộng đồng mà bạn tìm kiếm và gửi việc tìm kiếm tới các nút khác trong mạng Việc kết nối cộng đồng đơn giản là một vấn đề tải đối tượng cộng đồng tương ứng

1.5 Những đóng góp

Những đóng góp của đồ án này cho ý tưởng sáng tạo ở trên là việc cải thiện tìm kiếm trong các hệ thống chia sẻ file và việc đơn giản hóa việc tạo và dò tìm các cộng đồng chia sẻ file

1.5.1 Cải thiện tìm kiếm

SNS-P2P cải thiện việc thực thi ý tưởng trên trong các hệ thống chia sẻ dữ liệu bằng cách đem việc tìm kiếm metadata đến một dải định dạng rộng hơn Trong các ứng dụng đã tồn tại thì nói chung khó có khả năng cung cấp các định dạng file không phổ biến Điều này cho thấy một rào cản đối với việc sử dụng chia sẻ dữ liệu ngang hàng đối với một loạt ứng dụng rộng rãi Điểm chính của việc cung cấp các khả năng tìm kiếm được cải thiện mà không cần có việc điều khiển tùy biến cho mỗi định dạng file chính là một lớp metadata chuẩn

Lớp metadata chuẩn

Việc sử dụng các lược đồ để xác định các định dạng được yêu cầu bởi tất cả cộng đồng SNS-P2P Từ giản đồ, SNS-P2P có thể tạo ra một ứng dụng Vì giản đồ mang thông tin về dữ liệu nào được trình bày trong file nên nó được sử dụng cho

cả việc tạo và tìm kiếm Khi tạo một file mới, SNS-P2P có thể nhắc các trường bắt buộc để tạo một file mới, hoặc sử dụng giản đồ để làm cho một file đã tồn tại có hiệu lực Khi tìm kiếm, SNS-P2P cung cấp thông tin tìm kiếm về những trường sẵn có để tìm Điều này được thực hiện bởi cơ sở dữ liệu có khả năng thực hiện câu trả lời phức tạp về metadata có cấu trúc Tất cả các chức năng này có thể được tạo cho bất cứ giản đồ nào được viết theo định dạng chuẩn

Chức năng này tạo thành một lớp metadata chuẩn do nó không phụ thuộc vào giao thức ngang hàng lớp dưới Như đã thảo luận phía trước, danh sách các định dạng (được hỗ trợ bằng việc tìm kiếm metadata) thường được quyết định bởi sự lựa chọn giao thức Lớp metadata SNS-P2P có thể được thực hiện đầu tiên trước các giao thức cho phép hai thông số của chúng biến đổi độc lập nhau

1.5.2 Đơn giản hóa việc tạo và dò tìm cộng đồng

Cải thiện việc tìm kiếm đã được mô tả ở trên là điều kiện tiền đề cho nhân tố thứ hai: đơn giản hóa việc tạo và tìm kiếm cộng đồng Các cộng đồng SNS-P2P là tập duy nhất (định dạng, giao thức, …) Định dạng (ví dụ, giản đồ) cho phép mỗi cộng đồng cung cấp các dịch vụ cho việc tạo và tìm kiếm các file Khả năng này là có

thể đươc bàn đến nếu người sử dụng không thể tạo và tìm kiếm quan trọng hơn các cộng đồng khác nhau

Các cộng đồng được thiết kế cho người dùng

SNS-P2P là một cơ cấu hợp nhất cho phép bất cứ người nào thiết kế cộng đồng chia sẻ dữ liệu Khía cạnh này xác định một cộng đồng hoạt động được tách riêng

ra như thế nào và cấu hình của định dạng và các khía cạnh khác có thể được chỉ rõ trong file XML đơn giản và chuẩn hóa Về cơ bản, nó chỉ rõ việc tạo cộng đồng và hàm ý lợi ích của việc chia sẻ dữ liệu ngang hàng có thể được mở rộng xa hơn phạm vi sử dụng hẹp

các tiêu chuẩn biến đổi Điều này đơn giản hơn phương thức ad-hoc (từ mào đầu,

các tìm kiếm web) được dùng để tìm kiếm ngày nay

Hiệu năng và các lợi ích khả triển

Việc tìm kiếm trong các mạng ngang hàng có thể khá tốn kém do số lượng đối tượng và nút liên quan Kiểu ngang hàng tập trung đòi hỏi cơ sở dữ liệu lớn để duy trì thông tin về nơi các đối tượng được lưu trữ Kiểu phân tán dung hòa giữa yếu tố kích thước cơ sở dữ liệu với các yêu cầu phải truy vấn nhiều nút Các cộng đồng đưa ra phương thức là chia phần các nguồn tài nguồn một cách thông minh Nghiên cứu hẹp cộng đồng giảm tải đối với các nguồn tài nguyên bên ngoài cộng đồng mà không ảnh hưởng đến chất lượng của kết quả Kết quả này mang lại khả năng tìm kiếm tốt hơn và cho phép các cộng đồng tăng quy mô sử dụng các nguồn tài nguyên và các nút hơn chúng có thể

1.6 Tổng quan luận văn

Đồ án này đại thể được chia thành các phần như sau: phần giới thiệu, Mô tả ý tưởng, thiết kế và ước lượng hiệu năng Phần này bao gồm phần mở đầu Phần tiếp theo trình bày chi tiết về việc nghiên cứu trường trong các hệ thống chia sẻ file đã tồn tại Các kết quả đã có được ước lượng với khía cạnh hỗ trợ việc tìm kiếm và khả năng tạo và tìm kiếm các cộng đồng

Phần thiết kế được giới thiệu bằng việc thảo luận khá kỹ ý nghĩa “cộng đồng” trong cơ cấu SNS-P2P Các phần tiếp theo miêu tả việc thiết kế SNS-P2P ở viễn cảnh mức cao và sau đó đi vào chi tiết Phần này cũng bao gồm việc thảo luận XML và tại sao nó được lựa chọn cho giản đồ và cho các ứng dụng khác trong

sử dụng để đánh giá phương pháp sau việc thảo luận các kết quả Kết luận tóm tắt

và hướng phát triển nghiên cứu trong tương lai cũng được đề cập đến trong đồ án

và tìm kiếm các cộng đồng chia sẻ dữ liệu như thế nào

Một trong những phương pháp dễ dàng nhất nhằm cải thiện chất lượng của các kết quả tìm kiếm là sử dụng metadata Nói chung, các ứng dụng chia sẻ dữ liệu ngang hàng có xu hướng sử dụng metadata nhiều hơn Metadata cũng có thể được sử dụng trong các hệ thống không tập trung như Gnutella nhằm cải thiện hiệu năng cũng như chất lượng kết quả Phần này cũng thảo luận về các cộng đồng như một phương thức quan trọng để cải thiện việc tìm kiếm Chúng ta thảo luận một vài phương pháp khác nhau để chọn các node thuộc về mỗi cộng đồng Cuối cùng, chúng ta nói về một lớp các hệ thống được gọi là các hệ thống “trung tâm-cục bộ”

mà tại đó việc tìm kiếm có thể sẽ khó khăn Mặc dù vậy, có một vài đề xuất thú vị

để mang lại các tiện ích tìm kiếm trong các hệ thống này mà có thể có ứng dụng rộng hơn

Vấn đề tạo và tìm kiếm các cộng đồng trong các ứng dụng hiện có là chủ đề chính tiếp theo trong việc thực thi ý tưởng Tìm kiếm metadata là rất quan trọng đối với khả năng sử dụng các cộng đồng chia sẻ dữ liệu và việc tìm kiếm không đầy đủ có thể là rào cản việc tạo mới các cộng đồng chia sẻ dữ liệu có hiệu quả Chúng ta đặt

Tất cả các metadata trong các hệ thống ngang hàng theo một vài cách là có “cấu trúc” nhằm cho phép các máy tính phân tích và so sánh chúng Xu hướng trong thời gian tới là tăng thông tin và thậm chó làm cho nó trở nên dễ hơn để các máy tính điều khiển Chúng ta bắt đầu bằng cách thảo luận các mức khác nhau mà metadata được sử dụng trong các ứng dụng hiện nay

2.2.1 Metadata

Như đã thảo luận phía trước, thiết kế Napster ban đầu sử dụng một phần metadata duy nhất – tên file để làm thuận lợi công việc tìm kiếm Kết quả đơn giản này

chứng tỏ có hiệu quả khi thông tin quan trọng về MP3s – ‘‘ artist’’ và ‘‘title’’ có

thể dễ dàng phù hợp với không gian của tên file Vấn đề này được thực hiện trên

là sẵn có và chúng được tìm thấy ở đâu trong nhãn Kazaa xác định các nhãn và cho phép người sử dụng thực hiện tìm kiếm theo các trường khác nhau Giới hạn

về nhãn ID3 không linh hoạt – nó chỉ mô tả một kiểu đối tượng: MP3 Không có cách nào để mở rộng nó nhằm mô tả các định dạng khác

Hình 1: Bố trí bên trong của File được đính thẻ ID3v1[Nilson00]

XML là phương thức biểu diễn metadata phổ biến hơn cả Các trường sẵn có và sự sắp xếp chúng được cấu hình Mặc dù linh hoạt nhưng không đủ sự thoả thuận rằng phần mềm dùng để phân tích các tài liệu XML nói chung là khá rộng rãi Các thuộc tính này nghĩa là XML có thể thích ứng để diễn tả metadata về phạm vi đối tượng rộng lớn hơn với khả năng xử lý dữ liệu của máy tính Limewire là một ví

dụ về mạng ngang hàng có sử dụng XML để diễn tả cấu trúc metadata cho các loại file mà nó hỗ trợ

Limewire bao gồm vài giản đồ được viết bằng ngôn ngữ dựa trên XML gọi là Giản đồ XML [Thadani01] Theo W3C, Giản đồ XML cung cấp một định nghĩa cho “xác định cấu trúc, nội dung và ý nghĩa của các tài liệu XML” [W3C01] Giản

đồ mô tả metadata của các loại file khác nhau – âm thanh, hình ảnh, tài liệu, …

được biểu diễn như thế nào Giản đồ XML cho phép người sáng tạo Limewire định rõ metadata có cấu trúc được đọc bằng máy cho một loạt các định dạng file rộng lớn hơn Napster Nhưng không may là giản đồ được gán vào ứng dụng Limewire làm cho nó khó mở rộng hỗ trợ các loại file mới

Hình 3 Ví dụ không gian truy vấn text đối với các tài liệu về “SNS-P2P”

JxtaSearch định rõ cấu trúc của queryspace, các bản tin đăng nhập, ví dụ như sử dụng giản đồ thông thường hơn giản đồ XML

Đáng quan tâm là Jxta tự hỗ trợ ý tưởng công bố metadata với khái niệm “quảng bá” Mặc dù không được sử dụng rõ ràng cho việc chia sẻ dữ liệu nhưng quảng bá

là các tài liệu có cấu trúc XML được sử dụng để công bố thông tin về các nguồn tài nguyên Jxta (ngang hàng, nhóm ngang hàng, dịch vụ, …) Một vài quảng bá chính được định nghĩa và người sử dụng có thể biên tập lại hoặc gạt bỏ chúng nhờ

sử dụng Giản đồ XML, mặc cho cơ cấu không rõ ràng từ các đặc điểm Quảng bá

có thể thấy bằng cách sử dụng Giao thức Tìm kiếm Ngang hàng (Peer Discovery Protocol – PDP)

2.2.2 Định tuyến truy vấn

Query Routing là một cách quan trọng mà metadata có thể được sử dụng để cải thiện chất lượng tìm kiếm Công việc nghiên cứu trong lĩnh vực này được thúc đẩy bởi vấn đề định rõ trong các hệ thống ngang hàng “thuần tuý” hoặc các hệ thống không tập trung Trước khi thảo luận chi tiết vấn đề query routing thì trước tiên chúng ta hãy đối chiếu sự trái ngược giữa các hệ thống chia sẻ dữ liệu ngang hàng tập trung và không tập trung trên phương diện tìm kiếm

Ý tưởng đằng sau Napster đã lụi tàn hiện nay là sử dụng cơ sở dữ liệu tập trung để

dò vết các file bị mỗi peer chiếm giữ Ứng dụng ngang hàng khác gần đây, hệ thống bản tin khẩn cấp ICQ [ICQ03] cũng dựa trên ý tưởng tương tự ICQ sử dụng một danh sách tập trung lưu trữ thông tin về từng vị trí của người sử dụng trong mạng và liệu chúng có được thể hiện hay không

Central Server

Peer

Peer

Peer

Central Server

Peer queries central server, returns

peers with matching results

Central Server

Peer

Peer

Peer

Central Server

Peer queries central server, returns

peers with matching results

Hình 4: Mô hình mạng ngang hàng lai

Trong cả hai ứng dụng, thông tin về các nút khác được lưu trữ trong cơ sở dữ liệu trung tâm Việc tìm kiếm được phát đến máy chủ trung tâm và sau đó chuyển thông tin về nút ngang hàng đầu xa nơi mà file hay người sử dụng có thể được tìm thấy Với thông tin này, client nối trực tiếp đến nút ngang hàng đầu xa và thực hiện tải hoặc trao đổi Sự tin cậy vào máy chủ trung tâm làm cho các hệ thống trở thành tập trung Các hệ thống cũng được xem như “lai” bởi sự kết nối tương tác giữa chủ - tớ và ngang hàng

Các hệ thống không dựa vào quyền lực tập trung được coi là các hệ thống ngang hàng “thuần tuý” Hai ví dụ cụ thể là Gnutella và Freenet Trong các hệ thống này, các nút ngang hàng vừa hoạt động là máy chủ vừa hoạt như client, vì vậy chúng thường được xem như các “đầy tớ”[Kan01] Trong Gnutella, yêu cầu tìm kiếm gửi

tới các nút lân cận Các nút lân cận đồng thời gửi trở lại bất kỳ sự phù hợp do cơ

sở dữ liệu của chúng và gửi tiếp yêu cầu đến các nút lân cận của chúng

Hình 5: Mô hình Gnutella (Không tập trung)

Các query gửi đi nhanh hơn và xa hơn từ các nút ban đầu với nỗ lực tới càng nhiều nút như có có thể Tại mỗi nút, trường thời gian sống – time to live (TTL) của yêu cầu lại giảm đi Các yêu cầu với thời gian sống bằng không sẽ bị loại bỏ khỏi lưu lượng có giới hạn Thời gian sống TTL hạn chế buộc phạm vi tuân theo

sự truyền lan query Các kết quả tìm kiếm quay trở lại nút ban đầu thông qua cùng một đường Như trong Napster, tải được thực hiện bằng kết nối trực tiếp đến các nút ngang hàng đang chiếm giữ

search origin

match

Query sent to neighbours which relay to their

neighbours, results return through same path

match

Peer retrieves match directly from peer

search origin

Query Routing là một trong những vấn đề hiệu quả nhất của công tác nghiên cứu việc cải thiện quy mô của Gnutella (và các hệ thống ngang hàng thuần tuý nói chung) Rõ ràng, việc đưa tất cả các nút trong một phạm vi cho phép sẽ rất tốn kém về băng thông Kết quả tối ưu nhất sẽ là các query chỉ được chuyển tới các nút mà sẽ mang trở lại sự thích hợp tốt Kỹ thuật này cải thiện việc tìm kiếm: đối với cùng một lưu lượng mạng, chất lượng kết quả được cải thiện Trong các hệ thống ngang hàng lai, query routing không được yêu cầu khi máy chủ trung tâm thực hiện tất cả các yêu cầu tìm kiếm

Việc định tuyến metadata làm cơ cở cho các hệ thống như đề xuất query routing của Limewire [Rohrs02], Routing Indices [Crespo02], và Neurogrid [Joseph02] Cũng được xem như “định tuyến ngữ nghĩa”[Joseph02b], các hệ thống sử dụng chính query của bản thân để thông báo các quyết định của chúng Các bộ định tuyến Internet có thể xác định giao diện mà sẽ mang gói tới đích của chúng Các

bộ định tuyến query sẽ cố xác định đối với từ khóa đã cho nút lân cận nào sẽ mang query gần với tài liệu thích hợp Sự gần được định nghĩa như là sự tương tự giữa metadata được chỉ rõ trong query và metadata của tài liệu

Đề xuất query routing của Limewire giống với các kết quả định tuyến truyền thống Mỗi nút duy trì một bảng liệt kê số lượng các hop yêu cầu để tới một nút với tài liệu phù hợp với từ khóa đã chỉ rõ đối với mỗi nút lân cận Việc tìm kiếm được định hướng tới nút lân cận quảng bá số lượng hop ít nhất cho từ khóa Các nút học và cập nhật tổng số nút bằng cách tra các bảng định tuyến với nút lân cận Kết quả Routing Indices sử dụng thông tin về số lượng tài liệu có thể truy nhập qua các nút lân cận Khi hai nút thiết lập một kết nối, chúng có thể trao đổi thông

tin trên tổng số tài liệu gộp chung có thể truy nhập qua các nút lân cận Trả lời và chuyển đến các nút với tỷ lệ tài liệu cao trên một từ khóa đã cho – các nút với sự thu thập lớn hơn (không phụ thuộc vào đối tượng) sẽ được ủng hộ

7 4

11 Node2

8 1

8 Node1

5 5

10 Node0

TopicB TopicA

Total Results

node0

node1

node2

Query for TopicA only forwarded to Node2 since it

has higher proportion of relevant matches.

3 1

Node2

1 2

Node1

TopicB (hops) TopicA

(hops)

7 4

11 Node2

8 1

8 Node1

5 5

10 Node0

TopicB TopicA

Total Results

node0

node1

node2

Query for TopicA only forwarded to Node2 since it

has higher proportion of relevant matches.

3 1

Node2

1 2

Node1

TopicB (hops) TopicA

(hops)

Hình 6: Hai phương pháp định tuyến truy vấn

[Thadani01b]Limewire và RI lấy thông tin định tuyến từ các nút khác tại mức bề mặt Điều này có thể gây ra vấn đề là nếu như các nút quảng bá metadata không đúng hoặc sai lạc Neurdrid xác định vấn đề bằng cách dựa vào việc sử dụng phản hồi nhằm đánh giá độ tin cậy của kết quả - ví dụ: “Nếu một máy chủ đầu xa được query với từ khóa như “automobile” và chuyển quảng bá trở lại cho các sản phẩm mất trọng lượng thì độ tin cậy của máy chủ này với câu hỏi đó sẽ giảm” [Joseph02] Mỗi nút lân cận kết hợp với các từ khóa khác nhau với một sức mạnh

có thể được củng cố hoặc suy yếu Người sử dụng có thể đặt sự phản hồi trên chất

sử dụng các query XML, chúng xem rằng việc tăng XML được tách trước khi phân tích liệu tài liệu có phù hợp với query [Thadani01b]

2.2.3 Các cộng đồng

Kết quả khác nhằm tối ưu hóa việc tìm kiếm là để định nghĩa rõ ràng một tập nhỏ các nút dường như mang sự thích hợp trở lại và sau đó hạn chế sự tìm kiếm của một nút chỉ tới các nút khác của nó Nhờ định tuyến query đến các nút trong cộng đồng mà lưu lượng sẽ giảm mà không giảm chất lượng của kết quả JxtaSearch [Waterhouse01], Associative P2P [Cohen03] và Alpine [Alpine03] tất cả nằm trong danh sách này Một sự khác biệt chính giữa các hệ thống này là phương thức được dùng để định nghĩa cộng đồng

Các hệ thống JxtaSearch bao gồm người tiêu thụ, nhà cung cấp và hub Người tiêu thụ phát các yêu cầu tìm kiếm mà các nhà cung cấp phục vụ Các query được định

tuyến tới nhà cung cấp thông qua các hub Các nút ngang hàng có thể thực hiện một hay nhiều quy tắc hơn Trong JxtaSearch, mối quan tâm cộng đồng được định nghĩa bởi queryspace Queryspace xác định “không gian” của các query mà một nhà cung cấp có tư cách trả lời và bao gồm một loạt câu hỏi và một hoặc nhiều thuộc tính hơn Ví dụ, nhà cung cấp có thể quảng bá rằng họ có thể thực hiện loại yêu cầu “conference paper” nơi mà chủ đề phù hợp với “peer – to – peer” Các query tới phù hợp với mẫu được định hướng bởi các hub đến cộng đồng các nhà cung cấp Jxta, môi trường được sử dụng để thực hiện JxtaSearch, cũng bao gồm khái niệm cộng đồng hoặc “nhóm ngang hàng – peer groups” cái mà được sử dụng

để xác định một tập các nút ngang hàng cung cấp dịch vụ hơn là việc tìm kiếm định tuyến

node1

node0

Each node connects directly to the peers they’ve grouped.

node0’s “music” group

node1’s “music” group

node1

node0

Each node connects directly to the peers they’ve grouped.

node0’s “music” group node1’s “music” group

Hình 7: Mô hình Alpine