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

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

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

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

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ộ ội dung đượ n 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ữ ệu được nêu trong luận văn là hoàn toàn trung thực và rõ lirà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 năm 2013 12

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 cám ơn chân thành tới l 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 năm 2013 12

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Ụ 3 C 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ẻ ất cứ tài nguyên nào với các client khác ngoạ b 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ý ập trung: dữ ệ được lưu ữ ập trung trên server thay vì nằm rả t li u tr t 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ỉ ần thực hiện trên server Trong ctrườ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ữ ệu tập trung trên server đồng nghĩa với việc kiểm soát dễ li 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 ới rất nhiều tùy chọn linh hoạv 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ể ể đến như k : 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ủ ật lý Các v

ứ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ý uy nhiên T 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ữ ệ Như vậy tính co giãn của hệ thống vẫn không đượ ả li u c đ m bả Ngoài ra sửo

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

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

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ỉ ử ụng dị s d ch

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

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

bi t khi ệ ứng dụng chia sẻ ữ ệu ớ , băng thông ệ ống được chia ra trên các máy, d li l n h th

đả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ế ữ ệ , lưu trữ li u phân tán dữ ệ li u trên các node và các cơ ch m ế đả

bảo dữ ệu sẵn sàng khi có số lượng node nhất định rời khỏi hệ ố li 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ữ ệu được lưu trữ li 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 an toàn và ầu 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ạ cơ chếp, phân tán d u trên các ữliệ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ứ trong luận u 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ậ đề xuấ trong luận văn n t

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

Trong ph n th nghi m, tôi tiầ ử ệ ến hành áp dụng mô hình đề ất vào ứ xu 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 luầ ủa ậ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ở ứng dụng gọi là server; các ứi 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ệ ống mạng máy tính trên các máy vật lý khác nhau, tuy thnhiê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ề ứng dụ server và chia sẻ tài nguyên với các client u ng

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

liệu yêu cầ cung cấu p dịch vụ ới server Do đó, client là ứng dụng khởi tạo phiên kết 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ổ ến trong các ứng dụng mạng Email, WWW là các ứng dụng điể bi n hình c a mô hình này ủ

Client-Server mô tả ối quan hệ ộng tác giữa nhiề ứng dụ trong một hệ ố m c u ng 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 lý; client là mọ ản ộ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ử ụng cùng tài nguyên được chia sẻ ại cùng mộ d t t

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

cầu; server nhận và trả ề ết quả Để ực hiện giao tiếp giữa các máy tính, trước tiên v k thchú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ứ giao tiếc 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ẽ ạm ngừng cho tới khi tiến trình nhận phát ra t

lệnh nhận dữ ệ Tương tự ới tiến trình nhận dữ ệu, nếu tiến trình nào đó li u v li(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ẽ ị ạm ngừng cho tới khi b t 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ồ ữ ệu đó hay không Tương tựi d li 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 requestresponse theo chế độ: b phong t a Các công ngh có thị ỏ ệ ể ế đến như k Java Socket,

-.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ờ ẫn tớ làm chậ ứng dụng (đặc biệt là ứng dụng server Để d i m ) 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 để ểm tra dữ ệu (đã nhận, đã gửi hoặc đã ki li

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ữ ệu đã sẵ li 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 để ệu năng đạ hi 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à ản lý bộqu

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ế ạt độ ho 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 để ử lý 1 request, do đó để x 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ử ụng để ạ d 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 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

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

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] ủ

Đặ điểc 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ệ ống cao hơn th

• Ứ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ả ại kết quả cho client  l Quay

lại bước 1

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

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

b Concurrent server: server có thể ục vụ cho nhiều client tại một thời điểm Quá phtrì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 để ử lý yêu cầu của client x

 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ể ử lý các yêu cầ x 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ệ client có thển, đượ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ề ử lý độu x 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ế ối thườẫ ầ ộ t n 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ầ ết nối tới server Tương phản k 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ẻ ực hiện yêu cầu tính toán tới cùng một server Do đó, thnhì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 ch v x lý nghi p dị ụ ử ệ

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ộ ệ ống khi các máy client cần chạy cấu hình h ththấ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ệ ống sử ụng thin client là các máy có năng lực tính toán th d

-thấp và chỉ cung cấp giao diện đồ ọa cho người sử ụng, ngoài ra các xử lý h dkhá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ớ người 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ữ ữ ệu tập trung Tầng trình diễn thông thường là d liclient, 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ử được lý 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ữ ệu cũng làm li

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ở ữ ệu như Oracale, S d li QL 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ổ ợ ần thiết cho ứ tr c 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: ài nguyên tập trung làm cho nó dễ dàng hơn để sao lưu tcá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ữ ập trung tlà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ể ự động triển khai toàn hệ ống thay đổ t th 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ử ụng d

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ó th làm có ể tăng kh ả năng ủ c a máy nhỏ, giúp các máy nhỏ ực th

hi n ệ được những công vi mà ệc trướ đây chỉ ực ệ được trên các c th hi n 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: hông thường, các máy chủ trung tâm phải đủ tmạ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: serverphả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 Mô hình peer to peer -

-M ng ngang hàng là ki n trúc m ng phi t p trung và phân tán ạ ế ạ ậ trong đó các node trong mạng (được gọi là peer) vừa đóng vai trò là node cung cấ ẫn sử ụp l d ng tài

nguyên, khác v i mô hình t p trung c a client-server ớ ậ ủ trong đó các node client yêu cầu truy c p tài nguyên cung c p b i server trung tâm ậ ấ ở

Trong một hệ ố th ng m ng ngang hàng, các tác v ạ ụ (như là: tìm kiếm file, streaming video/ audio) được chia sẻ ữa các gi node được kế ố ớt n i v i nhau, mỗi peer dành m t ộ

ph n tài nguyên cầ ủa mình (như năng lực xử lý, kh ả năng lưu trữ, băng thông mạng) cho các thành viên khác trong m ng mà không cạ ần tới server trung tâm

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 ạng phủm

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

ngẫu nhiên với nhau (Gnutella, Gossip và Kazaa là những ví dụ ủa mạng P2P cphi 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ế Hơn thế ữa, với cấ trúc mạm) n u 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ổ ến, được lưu trên nhiề bi 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ỉ ệ thành công cao và tương đương l nhau

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

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

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, ng phạ ấ mạ ủ đượ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ữ ệu nó li

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

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

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ữ ệu đó li Bảng băm lưu trữ các p (key value) cặ , 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ế ảng băm phân tán như: m 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ộ ố ấn đề như: (i) chi phí cho quả v ng bá (thông báo cho các peer biế ề t vtì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) i trên ế ạ tả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 ấ ệ ả ả ế

hoạch cho các ứng d ng.ụ

c Mô hình lai

Mô hình lai kết hợp giữa P2P và client server Mô hình lai phổ biến sử dụng một máy chủ trung tâm giúp các peer tìm kiếm các peer khác trong mạng Spotify là một ví dụ về mô hình này

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

Streaming

Hình 2.15: Mô hình ng d ng Spotifyứ ụTrong khi phát streaming, client không download dữ liệu từ server trừ khi điều đó cần thiết để tăng chất lượng phát nhạc hoặc giảm trễ hệ thống Như mô

tả ở trên, khi một người dùng truy cập ngẫu nhiên, một request lấy dữ liệu được gửi tới server Client đưa ra quyết định lấy dữ liệu tiếp theo ở đâu dựa trên khả năng của buffer Giả sử kết nối tới server ổn định hơn kết nối tới các peer, nế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 GnutellaạCá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