Giải pháp sử dụng p2p như công cụ truyền thông cho các ứng dụng client server

P2P là một mô hình triển khai ứng dụng phân tán, trong đó mỗi node trong mạng được gọi là “peer” vừa đóng cả vai trò là node cung cấp lẫn node sử dụng dịch vụ, khác với mô hình client-se

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

- LƯƠNG QUY THỌ

GIẢI PHÁP SỬ DỤNG P2P NHƯ CÔNG CỤ TRUYỀN THÔNG

CHO CÁC ỨNG DỤNG CLIENT-SERVER

Chuyên ngành : Công nghệ thông tin

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

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

PGS.TS HÀ QUỐC TRUNG

Hà Nội – 2013

LỜI CAM ĐOAN

Tôi là Lương Quy Thọ, học viên cao học lớp 11BCNTT khóa 2011B do giáo viên hướng dẫn là PGS.TS Hà Quốc Trung hướng dẫn

Tôi xin cam đoan toàn bộ nội dung được trình bày trong bản luận văn “Giải pháp

s ử dụng P2P như công cụ truyền thông cho các ứng dụng Client-Server” này là kết

quả tìm hiểu và nghiên cứu của riêng tôi dưới sự hướng dẫn của PGS.TS Hà Quốc

Trung Các kết quả và dữ liệu được nêu trong luận văn là hoàn toàn trung thực và rõ ràng Mọi thông tin trích dẫn đều được tuân theo luật sở hữu trí tuệ, liệt kê rõ ràng các tài liệu tham khảo Tôi xin chịu hoàn toàn trách nhiệm với những nội dung được viết trong luận văn này

Hà n ội, ngày 18 tháng 12 năm 2013

Học viên

Lương Quy Thọ

LỜI CẢM ƠN

Tôi xin gửi lời cám ơn sâu sắc tới PGS.TS Hà Quốc Trung, người đã tận tình hướng

dẫn để tôi có thể hoàn thành luận văn

Tôi cũng xin gửi lời cám ơn chân thành tới quý thầy cô viện Công nghệ thông tin và truyền thông, viện Đào tạo sau đại học đã truyền dạy những kiến thức quý báu trong khoá học này

Tôi xin gửi lời cám ơn tới ban tổ chức hội nghị khoa học ACM-SoICT 2013 đã cho tôi cơ hội hoàn thiện hơn các nghiên cứu của mình

Cuối cùng, tôi xin gửi lời cám ơn tới gia đình, bạn bè, cơ quan công tác đã giúp đỡ trong quá trình thực hiện luận văn này

Hà n ội, ngày 18 tháng 12 năm 2013

Học viên

L ương Quy Thọ

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH MỤC HÌNH VẼ, ĐỒ THỊ 5

CHƯƠNG I: TỔNG QUAN 6

CHƯƠNG II: CƠ SỞ LÝ THUYẾT 10

2.1 Mô hình Client-Server 10

2.2.1 Phân loại server 15

2.2.2 Phân loại client 16

2.2.3 Kiến trúc client-server 17

2.2.4 Ưu điểm và nhược điểm của mô hình client-server 21

2.2 Mô hình peer-to-peer 23

2.2.1 Mạng P2P 24

2.2.2 Định tuyến và dò tìm tài nguyên 24

2.2.3 Phân loại mạng P2P 24

2.2.4 Ứng dụng của P2P trong thực tế 28

2.3 Thuật toán thay thế trang 39

2.3.1 Tổng quan 39

2.3.2 Quá trình tiền dọn sạch 40

2.3.3 Quản lý trang trước kỳ hạn 41

2.3.4 Thuật toán đánh dấu 41

2.3.5 Thuật toán thay thế trang 42

2.4 Công nghệ triển khai ứng dụng P2P 53

2.4.1 Công nghệ JXTA 53

2.4.2 Công nghệ WebRTC 56

CHƯƠNG III: MÔ HÌNH CHIA SẺ CACHE SỬ DỤNG P2P 60

3.1 Caching model 60

3.2 Local proxy model 64

3.3 Shared-caching model 65

CHƯƠNG IV: THIẾT KẾ ỨNG DỤNG CHIA SẺ FILE SỬ DỤNG MÔ HÌNH CHIA SẺ CACHE 69

4.1 Giới thiệu ứng dụng 69

4.2 Thiết kế ứng dụng 70

4.2.1 Thiết kế chức năng 70

4.2.2 Thiết kế module 71

4.2.3 Tổ chức dữ liệu 74

4.3 Công nghệ sử dụng 78

4.4 Thử nghiệm 80

CHƯƠNG V: KẾT LUẬN 84

DANH MỤC HÌNH VẼ, ĐỒ THỊ

Hình 2.1: Mô hình Client-Server 10

Hình 2.2: Trao đổi dữ liệu giữa Client và Server trong chế độ bị phong tỏa 12

Hình 2.3: Năng lực xử lý của Nginx so với Apache web server 13

Hình 2.4: So sánh khả năng quản lý bộ nhớ giữa Nginx và Apache web server 14

Hình 2.5: Cơ chế hoạt động của blocking-server 14

Hình 2.6: cơ chế hoạt động của non-blocking server [ref] 15

Hình 2.7: Phân loại client 17

Hình 2.8: Phân loại Client-Server theo kiến trúc logic 18

Hình 2.9: Kiến trúc Client-Server 2 tầng 19

Hình 2.10: Kiến trúc Client-Server 3 tầng 20

Hình 2.11: Kiến trúc Client-Server n tầng 21

Hình 2.12: Mạng phi cấu trúc 25

Hình 2.13: Mô hình mạng có cấu trúc 26

Hình 2.14: Cơ chế của bàng băm phân tán DHT 26

Hình 2.15: Mô hình ứng dụng Spotify 31

Hình 2.16: Mô hình mạng Napster 35

Hình 2.17: Mô hình mạng Gnutella 37

Hình 2.18: Kiến trúc JXTA 55

Hình 2.19: Kiến trúc WebRTC 58

Hình 3.1: Caching model 60

Hình 3.2: Cơ chế hoạt động mô hình Caching model 62

Hình 3.3: Mô hình Local-Proxy 65

Hình 3.4: Shared-caching Model 66

Hình 3.5: Cơ chế hoạt động mô hình Shared-caching model 68

Hình 4.1: Mô hình hoạt động ứng dụng Quicknode 69

Hình 4.2: Các module trong ứng dụng Quicknode 74

Hình 4.3: Tốc độ download P2P và Client-Server 82

Hình 4.4: Đồ thị thời gian và tốc độ download file (kích thước 48,11MB) 83

CHƯƠNG I: TỔNG QUAN

Mô hình client-server là mô hình triển khai ứng dụng phân tán phổ biến hiện nay

bởi khả năng phát triển và triển khai ứng dụng dễ dàng Trong mô hình này, thành phần cung cấp các dịch vụ hay tài nguyên được gọi là server, thành phần gọi các service được cung cấp bởi server gọi là client Thông thường các client và server được đặt trên các máy vật lý khác nhau và giao tiếp với nhau thông qua hệ thống mạng Một máy server chạy một hoặc nhiều ứng dụng server, các ứng dụng server chia sẻ tài nguyên

với các client Một client không chia sẻ bất cứ tài nguyên nào với các client khác ngoại

trừ việc gửi truy vấn tới các dịch vụ của máy server

Mô hình client-server được phát triển bởi Xerox PARC vào năm 1970 Các ứng

dụng Email, WWW là các ví dụ điển hình của mô hình client-server Đặc điểm nổi bật

của kiến trúc client-server gồm:

• Quản lý tập trung: dữ liệu được lưu trữ tập trung trên server thay vì nằm rải rác trên nhiều máy, giúp đơn giản hóa việc truy xuất và cập nhật dữ liệu

• Dễ bảo trì: nhờ khả năng quản lý tập trung mà công việc bảo trì cũng trở nên

dễ dàng hơn vì phần lớn việc bảo trì chỉ cần thực hiện trên server Trong trường hợp hệ thống có nhiều server với thiết bị dự phòng, quá trình bảo trì (như sửa chữa, thay thế server) có thể diễn ra hoàn toàn trong suốt với client

• Bảo mật: dữ liệu tập trung trên server đồng nghĩa với việc kiểm soát dễ dàng

và an toàn hơn

Các ưu điểm trên khiến ứng dụng phát triển theo mô hình Client-Server trở nên dễ dàng và linh hoạt:

• Ứng dụng sau khi được phân tích nghiệp vụ sẽ thiết kế được protocol chuẩn giao tiếp giữa client và server

• Tuân theo protocol, ứng dụng client và server có thể phát triển độc lập, và có

thể sử dụng các công nghệ khác nhau với rất nhiều tùy chọn linh hoạt (server: Java, Python, Ruby; client: Java Swing, C# Winform, HTML5, Mobile) Các ứng dụng client-server được phát triển độc lập cũng đảm bảo khả năng dễ nâng

cấp, bảo trì

• Ứng dụng client-server còn dễ dàng phát triển ở chỗ: có rất nhiều tùy chọn giao

thức kết nối giữa client-server và các tùy chọn này đều hỗ trợ mặc định trong các ngôn ngữ phát triển Các giao thức phổ biến có thể kể đến như: TCP/IP, UDP, HTTP

• Việc triển khai ứng dụng cũng dễ dàng: cài đặt server trên máy chủ vật lý Các ứng dụng client được phân phối qua mạng và được người dùng cài đặt vào máy

của mình Các công nghệ: web application, Java Webstart, NET Oneclick cho phép ứng dụng tự động nâng cấp khi có thay đổi trên server

Bên cạnh các ưu điểm của mô hình client-server, các đặc điểm của mô hình này cũng tạo ra các yếu điểm đó là server bottleneck Server bottleneck có thể xử lý bằng các giải pháp scale-up ứng dụng như: nâng cấp server, sử dụng load balancing[1] để phân tải ra nhiều máy chủ vật lý Tuy nhiên các giải pháp trên thường có chi phí rất cao Với các ứng dụng chia sẻ giao tiếp thời gian thực (Audio, Video) hay các ứng

dụng chia sẻ file cũng cần server có băng thông rất lớn

Bên cạnh giải pháp scale-up hệ thống, giải pháp sử dụng cache tại client là giải pháp thường sử dụng nhất Dữ liệu được chuyển qua client sẽ được cache lại phục vụ cho lần sử dụng tiếp theo, một cơ chế cache hiệu quả có thể cải thiện đáng kể hiệu năng truy cập service từ server Các thuật toán cache được gọi là: “page replacement algorithm”[5] Tuy nhiên nếu cache miss xảy ra, client vẫn phải liên lạc với server để

lấy dữ liệu Như vậy tính co giãn của hệ thống vẫn không được đảm bảo Ngoài ra sử

dụng cache có thể không giải quyết được bài toán chia sẻ dữ liệu realtime, khi có nhiều client cùng đăng ký nhận thông tin broadcast từ server

Giải pháp khác có thể giải quyết bottleneck ở server là triển khai ứng dụng theo

mô hình Peer-to-peer (P2P) P2P là một mô hình triển khai ứng dụng phân tán, trong

đó mỗi node trong mạng (được gọi là “peer”) vừa đóng cả vai trò là node cung cấp lẫn node sử dụng dịch vụ, khác với mô hình client-server trong đó client chỉ sử dụng dịch

vụ cung cấp bởi server Việc mỗi node trong mô hình P2P vừa đóng vai trò là node sử

dụng lẫn cung cấp dịch vụ dẫn đến các xử lý trên toàn bộ hệ thống được phân chia ra các node trong mạng do đó giải quyết vấn đề bottleneck của mô hình client-server, đặc

biệt khi ứng dụng chia sẻ dữ liệu lớn, băng thông hệ thống được chia ra trên các máy, đảm bảo khả năng mở rộng hệ thống với chi phí tối ưu

Tuy nhiên mô hình P2P cũng có yếu điểm đó là: triển khai phức tạp hơn do các thao tác: tìm kiếm dữ liệu, lưu trữ phân tán dữ liệu trên các node và các cơ chế đảm

bảo dữ liệu sẵn sàng khi có số lượng node nhất định rời khỏi hệ thống Mặt khác mô hình P2P cũng khó khăn hơn trong việc bảo trì và nâng cấp hệ thống so với ứng dụng client-server xử lý tập trung trên server Ngoài ra 1 điểm khác làm cho P2P không phải

lựa chọn số 1 cho các ứng dụng phân tán là tính an toàn của dữ liệu được lưu trữ phân tán tại nhiều node Một số ứng dụng thậm chí không thể triển khai theo mô hình P2P

do yêu cầu an toàn và lưu trữ tập trung dữ liệu: các ứng dụng có dữ liệu nhạy cảm: ứng

dụng ngân hàng core-banking, ứng dụng chứng khoán, ứng dụng mail…

Qua các tìm hiểu ta có thể trên rút ra:

• Ứng dụng dựa trên mô hình Client-Server dễ phát triển nhưng gặp server bottleneck và giới hạn băng thông

• Ứng dụng dựa trên mô hình P2P làm hệ thống có tính co dãn cao nhưng khó triển khai do: lookup service, protocol phức tạp,cơ chế phân tán dữ liệu trên các node và đảm bảo tính dữ liệu sẵn sàng cao phức tạp

Đề tài tôi chọn nghiên cứu trong luận văn là “Giải pháp sử dụng P2P như công cụ truyền thông cho các ứng dụng Client-Server” Mô hình được tôi nghiên cứu trong luận văn sử dụng mô hình P2P kết hợp với Client-Server và Cache để scale-out hệ thống,

giải quyết bottleneck của server cũng như sự phức tạp trong triển khai ứng dụng P2P đồng thời vẫn tận dụng được tính đơn giản của mô hình Client-Server và khả năng co giãn cao của hệ thống dựa trên P2P Ngoài ra hướng tiếp cận đề xuất trong luận văn

của tôi hướng tới việc nâng cấp ứng dụng Client-Server có sẵn để sử dụng thêm kết nối P2P và Cache

Trong phần thử nghiệm, tôi tiến hành áp dụng mô hình đề xuất vào ứng dụng chia

sẻ file để đưa ra các số liệu về hiệu năng của mô hình cũng như khả năng ứng dụng mô hình vào các hệ thống sử dụng mô hình Client-Server đã có

CHƯƠNG II: CƠ SỞ LÝ THUYẾT

Trong phần này tôi trình bày về cơ sở lý thuyết liên quan đến mô hình

Client-Server, mô hình P2P, thuật toán thay thế trang (page replacement algorithm[5]) sử dụng trong quản lý cache và các công nghệ sử dụng trong triển khai ứng dụng P2P

Dựa trên cơ sở lý thuyết này, tôi sẽ đề xuất mô hình lý thuyết và ứng dụng thí

nghiệm được trình bày trong các phần sau của luận văn

2.1 Mô hình Client-Server

Trong khoa học máy tính, mô hình Client-Server là một mô hình ứng dụng phân tán

mà các dịch vụ được xử lý và cung cấp bởi ứng dụng gọi là server; các ứng dụng gửi yêu cầu cung cấp dịch vụ tới server gọi là client Thông thường client và server giao

tiếp với nhau thông qua hệ thống mạng máy tính trên các máy vật lý khác nhau, tuy nhiên cả client và server vẫn có khả năng chạy trên cùng một máy vật lý Một server

vật lý có thể chạy một hoặc nhiều ứng dụng server và chia sẻ tài nguyên với các client

Một client không chia sẻ bất cứ tài nguyên nào của nó ngoại trừ thông qua việc gửi dữ

liệu yêu cầu cung cấp dịch vụ tới server Do đó, client là ứng dụng khởi tạo phiên kết

nối tới server và server là ứng dụng luôn thực hiện chờ kết nối từ client

Hình 2.1: Mô hình Client-Server

Mô hình Client-Server được phát triển bởi Xerox PARC vào những năm 1970 Hiện

tại mô hình rất phổ biến trong các ứng dụng mạng Email, WWW là các ứng dụng điển hình của mô hình này

Client-Server mô tả mối quan hệ cộng tác giữa nhiều ứng dụng trong một hệ thống Thành phần server cung cấp dịch vụ cho một hoặc nhiều client khi nhận được yêu cầu Trong mô hình này, mỗi máy tính trong mạng giữ một trong hai vai trò: client hoặc server Server là máy tính chia sẻ có chọn lọc tài nguyên mà nó quản lý; client là một máy tính hoặc chương trình khởi tạo liên lạc với server để sử dụng các tài nguyên mà server cung cấp Dữ liệu, CPU, máy in, thiết bị lưu trữ dữ liệu là một vài trong số các tài nguyên mà một server thường cung cấp

Chia sẻ tài nguyên máy tính trong mô hình Client-Server còn gọi là time-sharing

bởi nó cho phép nhiều ứng dụng sử dụng cùng tài nguyên được chia sẻ tại cùng một

thời điểm

Một máy tính cho dù là client hay server hay cả 2, nó đều có thể thực hiện nhiều

chức năng như: chạy ứng dụng máy chủ web, file server cùng lúc để cung cấp các loại

dữ liệu khác nhau cho từng yêu cầu khác nhau từ client Ứng dụng client cũng có thể giao tiếp với ứng dụng server trên cùng một máy vật lý Giao tiếp giữa 2 ứng dụng máy

chủ, chẳng hạn như thực hiện đồng bộ hóa dữ liệu, gọi là giao tiếp server-to-server

Client và Server trao đổi thông điệp theo cơ chế request-response: client gửi yêu

cầu; server nhận và trả về kết quả Để thực hiện giao tiếp giữa các máy tính, trước tiên chúng cần phải sử dụng cùng một ngôn ngữ, tuân theo một quy tắc giao tiếp đã định

sẵn Ngôn ngữ và quy tắc giao tiếp gọi chung là giao thức giao tiếp Tất cả các giao

thức Client-Server được xử lý ở tầng ứng dụng (application layer)

Hình 2.2: Trao đổi dữ liệu giữa Client và Server trong chế độ bị phong tỏa

Quá trình trao đổi thông điệp giữa client và server có thể diễn ra theo hai chế độ: bị phong tỏa (blocking) và không bị phong tỏa (non-blocking)

a Chế độ bị phong tỏa:

Trong chế độ bị phong tỏa, khi tiến trình client hoặc server phát ra lệnh gửi dữ

liệu, việc thực thi của tiến trình sẽ tạm ngừng cho tới khi tiến trình nhận phát ra

lệnh nhận dữ liệu Tương tự với tiến trình nhận dữ liệu, nếu tiến trình nào đó (client hoặc server) phát ra lệnh nhận dữ liệu mà tại thời điểm đó chưa có dữ

liệu gửi tới thì việc thực thi của tiến trình cũng sẽ bị tạm ngừng cho tới khi có

dữ liệu gửi tới

b Chế độ không bị phong tỏa

Trong chế độ này, khi tiến trình client hay server phát ra lệnh gửi dữ liệu, việc

thực thi của tiến trình vẫn được tiến hành mà không quan tâm đến việc có tiến trình nào phát ra lệnh nhận và phản hồi dữ liệu đó hay không Tương tự cho trường hợp nhận dữ liệu, khi tiến trình phát ra lệnh nhận dữ liệu, nó sẽ nhận dữ

liệu hiện có, việc thực thi của tiến trình vẫn được tiến hành mà không quan tâm đến việc có tiến trình nào phát ra lệnh gửi dữ liệu tiếp hay không

Rất nhiều nền tảng cho phép phát triển các ứng dụng client-server sử dụng response theo chế độ: bị phong tỏa Các công nghệ có thể kế đến như Java Socket,

request-.NET Socket, PHP Phát triển ứng dụng ở chế độ này dễ dàng cho người phát triển do:

thực hiện request tại một nơi và chờ nhận được kết quả (hoặc exception nếu timeout) ngay tại đó Tuy nhiên yếu điểm của chế độ này là việc các thread bị block cho tới khi

có kết quả của thao tác (hoặc exception) do đó khi hoạt động hệ thống có thể tồn tại rất nhiều thread chờ dẫn tới làm chậm ứng dụng (đặc biệt là ứng dụng server) Để khắc

phục yếu điểm của chế độ này, các nền tảng như: Java, NET đưa ra các cài đặt hiệu

quả cho phép sử dụng đồng thời các cơ chế sau để cải thiện hiệu năng hệ thống:

• Tập các thread gọi là ThreadPool để kiểm tra dữ liệu (đã nhận, đã gửi hoặc đã

có kết quả chưa)

• Cơ chế wait/ notify sẽ đóng băng thread khi cần phải chờ dữ liệu và kích hoạt thread trở lại khi dữ liệu đã sẵn sàng Việc kích hoạt được thực hiện bởi các thread trong ThreadPool

Các cơ chế trên cải thiện rất nhiều hiệu năng hệ thống, tuy nhiên để hiệu năng đạt

tới cấp độ cao hơn, Non-block thường được sử dụng

Các nền tảng cho phép phát triển ứng dụng Non-blocking như: NET asynchronous

IO, Java Vert.x và Nodejs[2] Bên cạnh đó 1 số server cũng được phát triển theo hướng

tiếp cận này, điển hình là Nginx Hình vẽ sau so sánh khả năng đáp ứng và quản lý bộ

nhớ của web server Nginx và Apache (blocking-server):

Hình 2.3: Năng lực xử lý của Nginx so với Apache web server

Hình 2.4: So sánh khả năng quản lý bộ nhớ giữa Nginx và Apache web server Khác biệt về cơ chế hoạt động giữa server blocking và non-blocking có thể thấy qua hình vẽ sau:

Hình 2.5: Cơ chế hoạt động của blocking-server Blocking server thường sử dụng 1 thread để xử lý 1 request, do đó để phục vụ hàng nghìn request tại một thời điểm, cần có hàng nghìn thread tương ứng Mặt khác tài nguyên sử dụng để tạo và duy trì 1 thread không nhỏ nên blocking server có hiệu năng

sử dụng tài nguyên thấp hơn

Xử lý request trong non-blocking server không ánh xạ 1-1 với thread Thay vào đó server non-blocking sử dụng vòng lặp IO (input-output) và cơ chế event-driven để xử

lý request Khi có request, event driven server phát ra sự kiện và đưa vào IO Loop, IO

Loop sử dụng 1 thread duy nhất trên mỗi core CPU để lặp qua và xử lý tất cả các sự

kiện được đưa đến cho tới khi xử lý xong và loại bỏ sự kiện ra khỏi vòng lặp

Hình 2.6: cơ chế hoạt động của non-blocking server [ref]

Đặc điểm của server triển khai theo cơ chế này:

• Server không phải tạo và quản lý nhiều thread Không phải lo tới threadsafe

hoặc deadlock như blocking server nên hiệu năng hệ thống cao hơn

• Ứng dụng khó phát triển hơn do tính bất đồng bộ: gửi yêu cầu tại 1 nơi, nhận kết

quả tại một nơi khác

2.2.1 Phân lo ại server

Server được chia làm 2 loại như sau:

a Interactive server: server phục vụ các client một cách tuần tự, sau khi phục vụ client này xong, sẽ phục vụ cho các yêu cầu của client khác Quá trình phục vụ tuân theo vòng lặp:

Chờ đợi yêu cầu từ client  Xử lý yêu cầu và trả lại kết quả cho client  Quay

lại bước 1

Interactive server có thiết kế khá đơn giản và phù hợp nhất với cho các ứng

dụng có thời gian trả lời ngắn Nếu thời gian phục vụ cho 1 yêu cầu dài thì thời gian phải chờ đợi là không thể chấp nhận được

b Concurrent server: server có thể phục vụ cho nhiều client tại một thời điểm Quá trình phục vụ theo vòng lặp như sau:

Chờ đợi yêu cầu từ client  Khởi tạo một tiến trình để xử lý yêu cầu của client

 Quay lại bước 1

Để sử dụng concurrent server có thể dùng một trong 2 cách sau:

Mỗi triến trình phục vụ riêng 1 client

Sử dụng ThreadPool: tạo ra một tập các triến trình để có thể xử lý các yêu cầu

của client

2.2.2 Phân loại client

Dựa trên các chức năng và khối lượng công việc mà client thực hiện, client có thể được phân thành hai loại:

a Fat client: là các client có đủ sức mạnh và hoạt động hạn chế sự phụ thuộc vào các server

Fat client (hay còn gọi là heavy, rich hoặc thick client) là một máy vật lý trong mô hình client-server hoặc trong hệ thống mạng, cung cấp nhiều xử lý độc

lập với máy chủ trung tâm

So với Thin client, Fat client vẫn yêu cầu một kết nối thường xuyên tới máy

chủ trung tâm (hoặc kết nối vào 1 mạng), nhưng thường nó được đặc trưng bởi

khả năng thực hiện nhiều tính toán mà không cần kết nối tới server Tương phản

với thin client luôn tránh các xử lý nhiều nhất có thể và gửi yêu cầu xử lý tới server mỗi lần dữ liệu được nhập và cần xử lý hoặc validate

b Thin client: là các client rất hạn chế chức năng và phụ thuộc nhiều vào server Thin client (hay còn gọi là lean client hoặc slim client) là một máy vật lý hoặc

một chương trình có hoạt động phụ thuộc rất nhiều vào các máy tính hoặc chương trình khác (server) Khác với các fat client được thiết kế để thực hiện công việc tương đối độc lập với server (các yêu cầu xử lý ở server ít và thường

không phức tạp) Ở thin client, server cung cấp dịch vụ cho client từ lưu trữ dữ

liệu tới xử lý dữ liệu client gửi lên

Thin client là một thành phần của một hạ tầng ứng dụng lớn, trong đó rất nhiều client chia sẻ thực hiện yêu cầu tính toán tới cùng một server Do đó, nhìn theo kiến trúc hướng dịch vụ (Service Oriented Architecture-SOA) thin client cũng có thể được xem như là hệ thống cung cấp các dịch vụ xử lý nghiệp

vụ thông qua các giao diện người dùng mà nó cung cấp

Điện toán sử dụng thin-client cũng làm giảm đáng kể chi phí phần cứng và

bản quyền phần mềm cho toàn bộ hệ thống khi các máy client cần chạy cấu hình

thấp với các phần mềm rất cơ bản (hệ điều hành nguồn mở, trình duyệt, các

phần mềm hỗ trợ khác)

Hầu hết các hệ thống sử dụng thin-client là các máy có năng lực tính toán

thấp và chỉ cung cấp giao diện đồ họa cho người sử dụng, ngoài ra các xử lý khác được cung cấp bởi server

Hình 2.7: Phân loại client

2.2.3 Kiến trúc client-server

Về mặt logic, một ứng dụng client-server thường được chia thành 3 tầng:

• Tầng trình diễn: chị trách nhiệm hiển thị các thông tin và tương tác với người dùng Tầng trình diễn nằm ở Client

• Tầng nghiệp vụ: xử lý các yêu cầu nghiệp vụ và phối hợp ứng dụng Tầng này thường nằm ở server với các ứng dụng sử dụng thin-client Với các ứng dụng sử

dụng fat-client, tầng này có thể nằm ở cả client và server

• Tầng cơ sở dữ liệu: quản lý dữ liệu của chương trình Tầng này nằm ở server

Hình 2.8: Phân loại Client-Server theo kiến trúc logic Tuy nhiên tùy thuộc vào mức độ phức tạp và cách thiết kế, ứng dụng client server

có thể là ứng dụng: 2-tầng, 3-tầng hoặc n-tầng

a Client-server 2 tầng

Kiến trúc client server đơn giản nhất là kiến trúc hai tầng Một ứng dụng hai

tầng cung cấp nhiều trạm làm việc với một tầng trình diễn thống nhất, tầng này truyền tin với tầng lưu trữ dữ liệu tập trung Tầng trình diễn thông thường là client, và tầng lưu trữ dữ liệu là server

Hầu hết các ứng dụng Internet như là email, telnet, ftp thậm chí là cả Web là các ứng dụng hai tầng

Trong ứng dụng hai tầng truyền thống, khối lượng công việc xử lý được dành cho phía client trong khi server chỉ đơn giản đóng vai trò như là chương trình kiểm soát luồng vào ra giữa ứng dụng và dữ liệu Kết quả là không chỉ

hiệu năng của ứng dụng bị giảm đi do tài nguyên hạn chế của PC, mà khối lượng dữ liệu truyền đi trên mạng cũng tăng theo Khi toàn bộ ứng dụng được

xử lý trên một PC, ứng dụng bắt buộc phải yêu cầu nhiều dữ liệu trước khi đưa

ra bất kỳ kết quả xử lý nào cho người dùng Nhiều yêu cầu dữ liệu cũng làm

giảm hiệu năng của mạng Một vấn đề thường gặp khác đối với ứng dụng hai

tầng là vấn đề bảo trì Chỉ cần một thay đổi nhỏ đối với ứng dụng cũng cần phải thay đổi lại toàn bộ ứng dụng client và server

Hình 2.10: Kiến trúc Client-Server 3 tầng Theo kiến trúc ba tầng, một ứng dụng được chia thành ba tầng tách biệt nhau

về mặt logic Tầng đầu tiên là tầng trình diễn thường bao gồm các giao diện đồ

họa Tầng thứ hai, còn được gọi là tầng trung gian hay tầng tác nghiệp Tầng thứ

ba chứa dữ liệu cần cho ứng dụng Tầng thứ ba về cơ bản là chương trình thực

hiện các lời gọi hàm để tìm kiếm dữ liệu cần thiết Tầng trình diễn nhận dữ liệu

và định dạng nó để hiển thị Sự tách biệt giữa chức năng xử lý với giao diện đã

tạo nên sự linh hoạt cho việc thiết kế ứng dụng Nhiều giao diện người dùng được xây dựng và triển khai mà không làm thay đổi logic ứng dụng

Tầng thứ ba chứa dữ liệu cần thiết cho ứng dụng Dữ liệu này có thể bao

gồm bất kỳ nguồn thông tin nào, bao gồm cơ sở dữ liệu như Oracale, SQL Server hoặc tài liệu XML

c Client-server n tầng

Kiến trúc n-tầng được chia thành các tầng như sau:

• Tầng giao diện người dùng: quản lý tương tác của người dùng với ứng dụng

• Tầng logic trình diễn: xác định cách thức hiển thị giao diện người dùng và các yêu cầu của người dùng được quản lý như thế nào

• Tầng logic tác nghiệp: mô hình hóa các quy tắc tác nghiệp,

• Tầng các dịch vụ hạ tầng: cung cấp một chức năng bổ trợ cần thiết cho ứng

dụng như các thành phần (truyền thông điệp, hỗ trợ giao tác)

Hình 2.11: Kiến trúc Client-Server n tầng

Ưu điểm của mô hình 3 tầng, n tầng (nhiều tầng) là:

• Tăng khả năng linh động, việc thay đổi các tầng logic là độc lập với nhau

• Tăng tính bảo mật

• Tăng hiệu năng khi các tác vụ được chia sẻ giữa các tầng Nhược điểm của mô hình nhiều tầng là:

• Tăng sự phức tạp trong triển khai và kiểm thử

• Tăng sự cần thiết của việc cân bằng tải và chịu lỗi

2.2.4 Ưu điểm và nhược điểm của mô hình client-server

a Ưu điểm

• Tập trung: tài nguyên tập trung làm cho nó dễ dàng hơn để sao lưu các tập tin, bảo vệ chống lại các mối đe dọa độc hại và chia sẻ tài nguyên Trong một mô hình client-server, máy in và các ổ đĩa lưu trữ

có thể được chia sẻ Thay vì cài đặt một máy in cho mỗi máy tính, các công ty có thể cài đặt máy in ở cấp độ máy chủ, cho phép các máy in được chia sẻ như một tài nguyên Điều này giúp tiết kiệm không chỉ là

tiền, mà còn là không gian có giá trị Một không gian lưu trữ tập trung làm cho nó dễ dàng hơn để sao lưu và lấy các tập tin trong trường hợp

mất dữ liệu Ngoài ra, máy chủ có thể quản lý chính sách mạng, làm cho một mạng client-server an toàn hơn

• Tính linh hoạt: một lợi thế quan trọng khác sinh ra trong quản lý tập trung là nó rất dễ dàng để triển khai cập nhật hoặc nâng cấp Một

mạng client-server có thể tự động triển khai toàn hệ thống thay đổi khác nhau, từ một nâng cấp lớn cho hệ điều hành mới để cập nhật thường xuyên như các tập tin dữ liệu chống virus hoặc các bản vá lỗi

của Microsoft với sự can thiệp của người dùng tối thiểu Nâng cấp và

cập nhật cũng có thể làm việc trong nền mà không có người sử dụng

biết rằng các chương trình đang được cập nhật hoặc nâng cấp

• Khả năng mở rộng: trong một mô hình client-server, một quản trị viên

có thể dễ dàng kết hợp các máy tính vào mạng và cài đặt tất cả các ứng dụng cần thiết Tất cả mọi thứ cần thiết có thể được đẩy dễ dàng

từ server đến các client

• Nó có thể làm tăng khả năng của máy nhỏ, giúp các máy nhỏ thực

hiện được những công việc mà trước đây chỉ thực hiện được trên các máy lớn, từ đó dẫn tới giảm chi phí thiết bị

b Nhược điểm

• Chi phí cho server lớn: thông thường, các máy chủ trung tâm phải đủ mạnh để duy trì và chia sẻ tài nguyên với các máy tính khác trên mạng Điều này đòi hỏi một chi phí đáng kể

• Sự phụ thuộc: mô hình mạng client-server dựa trên chức năng và server Nếu server gặp vấn đề, toàn bộ mạng không thể hoạt động

• Thắt cổ chai: server phải xử lý phần lớn công việc điều này có thể gây

ra tắc nghẽn mạng trên mạng và làm chậm thời gian trả lời cho các client

• Bảo trì: mô hình Client Server thường đòi hỏi một đội ngũ nhân viên với ít nhất một quản trị viên mạng lưới duy nhất để quản lý và duy trì các thiết bị và mạng Trong mô hình khác, chẳng hạn như peer-to-peer, không yêu cầu một quản trị để duy trì máy móc, công việc này được phân phối cho các peer

• An toàn: bởi vì tất cả các thông tin quan trọng được lưu trữ trên server, điều này tạo ra một mối quan tâm an ninh Tập trung các thông tin và dữ liệu này phải được bảo vệ từ tin tặc nguy hiểm, sự cố, các mối đe dọa tiềm năng

2.2.2 Định tuyến và dò tìm tài nguyên

Một cách tổng quát, mạng P2P chính là một dạng mạng phủ trên nền các cấu trúc liên kết mạng vật lý, trong đó các node trong mạng phủ tạo thành tập con của các node trong mạng vật lý Dữ liệu vẫn được trao đổi thông qua mạng TCP/IP nằm dưới nhưng

ở tầng ứng dụng, các peer có thể giao tiếp trực tiếp với peer khác thông qua các liên kết logic mà mạng phủ cung cấp (mỗi liên kết tương ứng với một đường đi trong mạng vật lý)

Mạng phủ sử dụng để đánh chỉ mục và dò tìm các peer, và cũng làm cho hệ thống P2P độc lập với cấu trúc liên kết mạng vật lý Dựa vào cách thức liên kết các node và cách đánh chỉ mục cũng như bố trí tài nguyên, mạng P2P được chia ra: mạng có cấu trúc và phi cấu trúc (hoặc phiên bản lai giữa 2 loại này)

2.2.3 Phân loại mạng P2P

a M ạng phi cấu trúc

Hình 2.12: Mạng phi cấu trúc

Mạng P2P phi cấu trúc là mạng không bắt buộc các node trong mạng phủ

phải tuân theo một cấu trúc sắp xếp nào mà chúng tạo bởi các node có kết nối

ngẫu nhiên với nhau (Gnutella, Gossip và Kazaa là những ví dụ của mạng P2P phi cấu trúc)

Bởi vì không có cấu trúc mạng bắt buộc, mạng phi cấu trúc dễ dàng khởi tạo

và cho phép tối ưu hóa trong một tập các node nhất định (trong một tập các node, hệ thống dựa vào thông số cấu hình có thể đưa ra liên kết mạng có lợi nhất trong trao đổi dữ liệu) Ngoài ra do các node trong mạng có vai trò ngang bằng nhau nên hạn chế ảnh hưởng khi có lượng lớn các node vào và ra khỏi mạng Tuy nhiên giới hạn chính của mạng phi cấu trúc cũng xuất phát từ tính phí cấu trúc của nó Đặc biệt khi một peer muốn tìm kiếm một dữ liệu trong mạng, truy

vấn này sẽ làm lụt mạng vì phải gửi tới nhiều nhất có thể các node Việc làm lụt

hệ thống sinh ra lượng lớn băng thông, CPU, memory (do yêu cầu mọi node

phải thực hiện tất cả các truy vấn tìm kiếm) Hơn thế nữa, với cấu trúc mạng như trên, việc làm lụt hệ thống cũng không đảm bảo dữ liệu tương ứng sẽ được tìm thấy Với các dữ liệu phổ biến, được lưu trên nhiều peer việc tìm kiếm các

dữ liệu này bởi mọi nút trên mạng có tỉ lệ thành công cao và tương đương nhau

Với các dữ liệu không phổ biến được lưu trữ trên lượng nhỏ các peer, việc tìm

kiếm nó từ các peer khác nhau có thể tốn chi phí rất khác nhau hoặc không

thành công

b M ạng có cấu trúc

Hình 2.13: Mô hình mạng có cấu trúc

Trong mạng P2P có cấu trúc, mạng phủ được tổ chức thành một cấu trúc liên

kết xác định với giao thức đảm bảo bất kỳ node nào có thể tìm được dữ liệu nó

cần một cách hiệu quả cho dù dữ liệu có thể không phải dữ liệu phổ thông (rất ít node lưu trữ)

Hình 2.14: Cơ chế của bàng băm phân tán DHT

Hầu hết các mạng P2P có cấu trúc sử dụng cơ chế bảng băm phân tán (DHT- distributed hash table) để lưu trữ ánh xạ của định danh dữ liệu và định danh peer chứa dữ liệu đó Bảng băm lưu trữ các cặp (key, value) cho phép các node tham gia có thể lấy dữ liệu (value) gắn với key cho trước Có rất nhiều giải thuật thực thi cơ chế mảng băm phân tán như: Chord[7], CAN, Tapestry

Tuy nhiên để việc tìm kiếm dữ liệu hiệu quả, các node trong mạng có cấu trúc phải lưu trữ được danh sách các node lân cận thỏa mãn các ràng buộc xác định Điều này dẫn tới các mạng có tần suất một node tham gia và ra khỏi hệ

thống lớn trở nên không hiệu quả do cần thời gian trễ để các node cập nhật lại danh sách lân cận của mình trước khi có thể thực hiện tìm kiếm dữ liệu Nhiều đánh giá gần đây dựa trên các mạng thực tế chỉ ra rằng giải pháp sử dụng DHT

có một số vấn đề như: (i) chi phí cho quảng bá (thông báo cho các peer biết về tình trạng hiện tại của mình) và tìm kiếm tài nguyên trong mạng cao (ii) tải trên các peer không cân bằng

Các mạng phân tán sử dụng DHT có thể kể đến như: BitTorrent, Kad network, Storm botnet, YaCy, Coral Content Distribution Network Một số dự

án nghiên cứu về DHT: Chord project, Kademlia, PAST storage ultility, P-Grid

và CoopNet content distribution system Trong lĩnh vực điện toán lưới DHT được sử dụng để tìm tài nguyên rất hiệu quả: giúp quản lý tài nguyên và lên kế

2.2.4 Ứng dụng của P2P trong thực tế

2.2.4.1 Spotify

Spotify là một dịch vụ âm nhạc trực tuyến sử dụng công nghệ P2P Dịch vụ này hiện cung cấp 8 triệu bản nhạc cho phép người dùng tùy chọn phát bản nhạc mình thích

và chuyển tới nghe 1 đoạn bất kỳ trong bản nhạc Dữ liệu được truyền từ cả server lẫn

mạng P2P Hiện tại dịch vụ có khoảng 7 triệu người dùng

Một trong những điểm khác biệt của ứng dụng Spotify client là cho phép chơi nhạc với độ trễ thấp Độ trễ trung bình để bắt đầu chơi 1 bản nhạc khoảng 265ms

a Giới thiệu về Spotify

Giao thức sử dụng trong Spotify là giao thực được thiết kế đặc biệt cho streaming file nhạc Spotify phát triển client cho trên OSX, Windows cũng như trên một số nền tảng smartphone Tuy nhiên trên nền tảng smartphone, client không tham gia vào mạng P2P mà nhận dữ liệu streaming trực tiếp từ server Về giao diện người dùng, ứng dụng cũng tương tự như các trình nghe nhạc phổ biến khác trên desktop Người dùng có thể tổ chức các bản nhạc thành playlist và chia sẻ với mọi người Tổ chức tìm kiếm nhạc dựa trên 2 khái niệm: tìm kiếm và duyệt Người dùng có thể tìm kiếm bản nhạc, albumn, tác giả và cũng có thể duyệt qua các bản nhạc: khi click vào một tác giả, người dùng được đưa tới

trang thông tin của tác giả với các bài hát được hệ thống đề xuất

Audio stream được mã hóa sử dụng Ogg Vorbis với chất lượng mặc định ở mức q5 (có tốc độ phát khoảng 160kbps) Người dùng trả phí có thể chơi nhạc ở mức chất lượng q9 (khoảng 320kbps) Cả 2 loại trên (q5 và q9) đều có thể cung cấp từ nguồn server hoặc mạng P2P Tại các peer, dữ liệu không được mã hóa lại do đó một peer có bản nhạc ở mức q9 không thể cung cấp cho một peer khác

đang cần bản nhạc tương ứng ở mức q5

Khi chơi nhạc, Spotify client sẽ theo dõi buffer của các âm thanh Nếu buffer không được làm đầy, client rơi vào tình trạng bị lặp (giật) khi phát nhạc do dữ liệu không đủ để lấp đầy một khung thời gian Tình trạng lặp này xảy ra có thể

do mạng hoặc do client không đủ tài nguyên CPU/ memory để xử lý hiệu quả dữ

liệu cache

Khác với hầu hết các ứng dụng streaming khác, Spotify sử dụng TCP thay vì UDP giúp tăng độ tin cậy của hệ thống và đơn giản hóa thiết kế Ngoài ra TCP

có cơ chế gửi lại gói tin bị mất rất cần thiết cho các ứng dụng

Kết nối giữa các node là kết nối TCP và trao đổi message trên kết nối này là trao đổi 2 chiều (multiplex) Khi một client đang online, nó duy trì một kết nói tới Spotify server Các message tầng ứng dụng được buffer, sắp xếp theo thứ tự

ưu tiên trước khi được gửi xuống buffer của TCP

Caching

Cache cực kỳ quan trong vì 2 lý do: đầu tiên từ thói quen của người dùng có thể nghe cùng một bản nhạc nhiều lần do đó cache ngăn việc download lại bản nhạc người dùng vừa nghe Thứ 2, dữ liệu cache được dùng để cung cấp cho node khác trong mạng Cache có thể lưu trữ từng phần của một track do đó khi client chỉ download 1 phần của track, phần dữ liệu đó cũng sẽ được cache lại Nội dung cache được mã hóa và không thể sử dụng bởi chương trình chơi nhạc

nào khác

Cấu hình mặc định của client cho phép sử dụng 10% dung lương chưa sử dụng của ổ cứng và trong giới hạn: ít nhất 50MB, nhiều nhất 10GB Người dùng cũng có thể thay đổi cấu hình này Theo thống kê có 56% client dùng hết từ

5GB cache trở lên, tương ứng với khoảng 1000 track trên cache

Lớp thuật toán dùng để quản lý cache trong Spotify là LRU (Least Recently Used) Thông kê dữ liệu log của hệ thống cũng chỉ ra rằng khi dữ liệu cache tương đối lớn, sử dụng các thuật toán cache khác nhau không làm tác động

nhiều nhiều tới hiệu năng hệ thống

Truy cập ngẫu nhiên

Trường hợp đơn giản nhất khi streaming là các track được chơi theo thứ tự định trước Giả sử băng thông mạng cho phép, ứng dụng chơi nhạc sẽ lấy trước một phần dữ liệu trước khi nó thực sự cần dùng tới Tuy nhiên thực tế thường khó và thú vị hơn nhiều, đó là trường hợp track được truy cập ngẫu nhiên Khoảng 39% track trên Spotify được truy cập ngẫu nhiên Trừ trường hợp client

có dữ liệu trong cache, ngoài ra hệ thống thường mất khoảng 15 giây để client truy vấn server để tìm thấy dữ liệu

Truy cập có thể đoán trước

Hầu hết (61%) track được truy cập theo thứ tự có thể đoán trước Chẳng hạn người dùng thường nghe nhạc theo thứ tự từ 1 tới hết hoặc chọn Next để chuyển tới bài tiếp theo trong danh sách Chương trình client sẽ lấy trước một phần bản nhạc tiếp theo trước khi nó thực sự được chơi Việc lấy trước dữ liệu bản nhạc cũng phải cân bằng giữa chi phí và lợi ích Nếu client bắt đầu lấy trước dữ liệu quá muộn dữ liệu sẽ không đủ để phát bản nhạc ngay tức khắc Nếu việc lấy trước dữ liệu quá sớm, băng thông bị lãng phí nếu người dùng chuyển sang truy cập ngẫu nhiên và bỏ qua bản nhạc đã lấy sẵn

Spotify client bắt đầu tìm kiếm trong mạng P2P track tiếp theo khi track đang chơi còn ít hơn hoặc bằng 30 giây Khi track hiện tại còn ít hơn hoặc bằng

10 giây, nó có thể bắt đầu đi lấy track đó nếu cần thiết Các con số t=10, 30 là các con số ước đoán do xác suất một người nghe bản nhạc tới khi bản nhạc còn

10, 30 giây sẽ nghe bản bạc tiếp theo tương ứng là 94% và 92%

Hệ thống cũng nghi nhận được: khi tính năng lấy trước bản nhạc bị tắt bỏ độ trễ trung bình khi chơi một bản nhạc là 390 ms so với mức trước đó là 265 ms Hơn nữa số lần phát nhạc rơi vào tình trạng lặp là 1,8% so với 1,0% so với trước

đó Điều đó chứng tỏ hiệu quả của việc lấy trước dữ liệu

dữ liệu trong buffer của client ít, nó sẽ yêu cầu lấy dữ liệu trực tiếp từ server Nếu buffer client đã đủ lớn dữ liệu sẽ chỉ lấy từ các peer

Trường hợp đặc biệt, khi buffer thấp xuống mức nghiêm trọng (dưới 3 giây phát nhạc), client sẽ tạm dừng upload data tới các peer đang lấy dữ liệu của nó

Lý do ở chỗ: rất nhiều người dùng có kết nối mạng bất đồng bộ, tình huống xảy

ra khi việc nén ACK làm giảm băng thông kênh download của đường truyền [ref]

Khi client lấy dữ liệu từ server, client sẽ điều tiết để không lấy quá 15 giây phát trước tính từ thời điểm hiện tại, nếu tồn tại peer có chứa dữ liệu track tương ứng (sau đó nó sẽ tìm cách lấy dữ liệu từ peer đó thay vì lấy tiếp từ server) Khi download từ mạng P2P, việc điều tiết không cần thiết, client sẽ lấy toàn bộ bản nhạc cần thiết Nếu người dùng dừng phát bản nhạc hiện tại, việc lấy dữ liệc từ peer hiện tại bị hủy bỏ

File trong mạng P2P được chia thành các đoạn độ dài 16kB Khi quyết định được các peer có dữ liệu cần, client sắp xếp các peer theo thứ tự thời gian download cần thiết (số lượng byte còn chia cho tốc độ download trung bình từ peer này) sau đó thực hiện download lần lượt các đoạn và cập nhật thời gian còn lại tương ứng với các peer

hỗ trợ live streaming, giao thức Spotify chi cho phép client cung cấp các track

mà nó đã cache được toàn bộ nội dung Điều đó cho phép giao thức trở nên đơn giản Không có phương pháp tổng quát để định tuyến trong mạng phi cấu trúc,

vì thế các peer muốn trao đổi dữ liệu phải thực hiện kết nối trực tiếp

Chia tách mạng phủ

Dịch vụ hiện tại được chạy từ 2 trung tâm dữ liệu, 1 ở London, 1 ở Stockholm Một peer lựa chọn ngẫu nhiên một data center mà nó muốn kết nối tới Mỗi data center có một mạng phủ P2P độc lập Do đó, mạng phủ P2P thực chất được phân làm 2 mạng phủ Việc phân chia thực chất không được thực hiện triệt để khi một client mất kết nối tới server, nó thực hiện kết nối lại tới server mới Nếu nó thực hiện kết nối tới server còn lại, client sẽ không thể thực hiện tạo một kết nối mới tới một peer nằm trong mạng phủ cũ được

Xác định peer

Hai cơ chế được sử dụng để xác định các peer có nội dung mà client cần Cơ chế đầu tiên sử dụng tracker đặt ở back-end, và cơ chế thứ 2 sử dụng truy vấn trong mạng phủ Trương hợp các track nhỏ, client thường chỉ cần tìm và lấy dữ liệu trong một hoặc một vài peer Tuy nhiên các track quá ngắn dẫn tới việc download 1 track mới xảy ra thường xuyên và điều quan trọng là làm giảm quá tải hệ thống Hơn thế nữa, thời gian tìm kiếm cũng là vấn đề lớn, đây là lý do chính Spotify không sử dụng DHT để tìm kiếm peer Một lý do khác dẫn tới không sử dụng DHT là mong muốn giữ giao thức đơn giản

Chức năng của tracker trong Spotify và BitTorrent cũng tương đương nhau nhưng không hoàn toàn giống nhau Spotify sử dụng một map lưu trữ ánh xạ track và peer của các peer gần đây gửi thông báo nó có chứa 1 track Peer chỉ cung cấp ra ngoài các track chứa đầy đủ dữ liệu, các peer được liệt kê trong

tracker có track đầy đủ

Tracker chỉ lưu trữ danh sách 20 peer gần nhau cho mỗi track Hơn thế nữa, client chỉ được thêm vào tracker khi chúng phát một track và không định kỳ báo cáo nội dung cache hoặc thông báo cho tracker khi nội dung bị xóa bỏ Điều đó

làm giảm tải hệ thống và đơn giản hóa cớ chế hoạt động Vì client duy trì kết nối TCP tới server do đó tracker biết client nào đang online Khi client yêu cầu tìm kiếm peer có chứa dữ liệu của track xác định, tracker đưa ra 10 peer đang online

và chứa dữ liệu Giới hạn kết quả làm giảm quá tải hệ thống

Thêm vào đó tìm kiếm sử dụng tracker, client cũng gửi yêu cầu tìm kiếm lên mạng P2P tương tự như phương pháp của Gnutella Một client gửi yêu cầu tìm kiếm tới tất cả node lân cận trong mạng phủ, các node này lại forward tới các node lân cận của nó Do dó tất cả peer trong phạm vi có khoảng cách câp 2 của node phát yêu cầu search nhận được yêu cầu và trả lời Truy vấn tìm kiếm được gửi bởi client có id gắn kèm và các peer nhớ 50 search gần nhất nó gặp cho phép loại bỏ các message trùng lặp Giới hạn này chỉ tồn tại ở lớp phủ mạng P2P của Spotify

Khi client hoạt động, làm sao chúng có thể tạo kết nối P2P trong mạng? Nếu một node vẫn được liệt kê trong danh sách của tracker với một số track mà nó đang cache, rất có thể có node tạo kết nối tới nó để lấy về track Nếu người dùng bắt đầu streaming 1 track nó sẽ tìm kiếm trong mạng P2P và kết nối tới peer có

dữ liệu

2.2.4.2 Napster

Napster là mạng ngang hàng không cấu trúc đầu tiên thu hút được đông đảo người

sử dụng trên mạng Đây là sự kết hợp của một mạng ngang hàng peer to peer và một số server trung tâm để duy trì kết nối hệ thống và danh sách dữ liệu được chia sẻ trong mạng Ngoài việc là một mạng peer to peer, Napster cũng giống như một mạng với các server Chính các server này làm cho việc tìm kiếm dữ liệu và chia sẻ giữa các máy

tính trong mạng tốt hơn, tạo nên mô hình mạng peer to peer đầu tiên được ưu chuộng với các dịch vụ chia sẻ file dữ liệu, file nhạc trên mạng Internet Napster gồm 2 thành phần, thứ nhất là server trung tâm và thứ hai là các ứng dụng trên các máy tính kết nối với nhau Một máy tính tham gia vào mạng sẽ kết nối với server trung tâm và đưa danh sách file chia sẻ trong máy tính lên server này Những máy tính khi tìm kiếm dữ liệu sẽ tìm kiếm thông tin về từ khóa trên server trung tâm để biết máy tính nào hiện đang giữ file chia sẻ đó

Hình 2.16: Mô hình mạng Napster

Để tìm kiếm một file, một truy vấn sẽ được gửi đi tới server trung tâm cùng với từ khóa tìm kiếm Server trung tâm sẽ tìm trong danh sách các file chia sẻ được đưa lên bởi các máy tính và trả về địa chỉ IP của máy tính lưu giữ file chia sẻ này Sau đó sẽ là kết nối trực tiếp giữa máy tính yêu cầu và máy tính giữ file chia sẻ, dữ liệu được truyền

giữa hai máy tính giống như trong một mạng ngang hàng Cụ thể các bước thực hiện tìm kiếm và download 1 file như sau:

1 Mở ứng dụng Napster

2 Napster kiểm tra kết nối Internet

3 Napster login vào server Mục định của server ở đây là để giữ dữ liệu chỉ mục

dữ liệu của tất cả người dùng đang online Server không chứa bất cứ file MP3 nào

4 Người dùng search file

5 Napster client truy vấn server để tìm ra máy chứa file cần tìm

6 Server báo cho Napster client kết quả tìm kiếm

7 Napster client hiển thị danh sách kết quả

8 Người dùng chọn 1 file để download

9 Napster kết nối tới máy chứa file người dùng vừa chọn

10 Download file từ máy được chọn

11 Khi việc download file thành công, kết nối P2P bị đóng lại Việc download file kết thúc

2.2.4.3 Gnutella

Bên cạnh Napster, một mô hình mạng ngang hàng không cấu trúc khác cũng rất nổi

tiếng là Gnutella Gnutella là một mạng peer to peer thuần và chủ yếu dựa trên mạng

P2P không có cấu trúc Một phiên bản thương mại của Gnutella là Limewire Các máy tính trong Gnutella được mô tả như là những “servent” (server-client), những thành viên trong mạng và được chia sẻ file trong mạng Các máy tính khác có thể lấy được những file chia sẻ này Việc tìm kiếm file trên mạng mô tả trong dưới, khi một máy

tính A tìm kiếm file X, nó sẽ gửi một thông báo broadcast tới tất cả các máy tính nó biết, được coi là hàng xóm của nó Truy vấn sau đó sẽ được chuyển dần qua các bước

và tới được máy tính có chứa file X Điểm khác biệt cơ bản giữa Gnutella và Napster là Napster vẫn sử dụng hệ thống với một máy chủ trung tâm còn Gnutella là một mạng ngang hàng đẩy đủ

Hình 2.17: Mô hình mạng GnutellaCác bước một máy thực hiện tham gia vào mạng:

1 Một peer muốn tham gia vào mạng phải biết địa chỉ của một thành viên trong mạng

2 Peer gửi yêu cầu kết nối tới máy nó biết: “GNUTELLA CONNECTION”

3 Nhận được reply “OK” Kết nối vào mạng thành công

Các bước thực hiện download một file

1 Peer gửi QUERY để tim file

2 Nếu QUERY tới được peer chứa file cần tìm, peer sẽ nhận được kết quả QUERYHIT

3 QUERYHIT chứa IP và port của peer chứa dữ liệu

4 Mở kết nối trực tiếp tới peer vừa tìm thấy

5 Download file qua kết nối trực tiếp và giao thức HTTP với port lấy được ở bước

3

2.3 Thuật toán thay thế trang

Trong hệ điều hành máy tính, thuật toán sử dụng phân trang để quản lý bộ nhớ ảo, thuật toán thay thế trang quyết định những trang được đưa ra khỏi cache khi memory cần được cấp phát mới Loại bỏ trang xảy ra khi page fault (khi dữ liệu truy xuất không

có trên bộ nhớ cache  cần phải đọc từ ổ cứng chẳng hạn) xảy ra và các page trống còn lại không đáp ứng nhu cầu cấp phát hoặc không còn page trống hoặc số page trống nhỏ hơn một ngưỡng định trước

Khi page đã được chọn để thay thế lại được tham chiếu trở lại, dữ liệu page tương ứng cần được đưa trở lại cache (đọc từ đĩa) việc này gây ra trễ lớn do phải chờ thao tác đọc/ghi hoàn thành Chất lượng thuật toán thay thế quyết định bởi: càng ít thời gian chờ xử lý đưa một trang vào cache thuật toán càng tốt Thuật toán thay thế trang phụ quan tấm đến các thông tin giới hạn khi phần cứng thực hiện truy cập các trang và khả năng đưa ra đề xuất các trang bị thay thế để giảm thiểu page miss (page không tìm thấy trong cache, page fault) trong khi cân bằng được chi phí (lưu trữ trong main memory, CPU) của thuật toán

Bài toán thay thế trang là bài toán online điển hình (dữ liệu được đưa vào hệ thống liên tục và từng phần)

2.3.1 Tổng quan

Thuật toán thay thế trang là chủ để nóng và được bàn luận rất nhiều trong những năm 1960, 1970 Và hầu như đã được định đoạt khi các thuật toán LRU (least recently used) phức tạp xuất hiện Đặc biệt, các khuynh hướng sau của hardware và phần mềm mức ứng dụng có ảnh hưởng tới hiệu năng của thuật toán:

• Kích cỡ của bộ nhớ tăng nhiều lần so với khả năng xử lý Với một vài GB bộ nhớ cache thuật toán cần một chu kỳ kiểm tra các memory frame đang dần ít được sử dụng