Ứng dụng kỹ thuật p2p vào internet TV cách tiếp cận và phát triển giải pháp pulse

MỤC LỤC ƯƠ Ớ THIỆU ƯƠ ĐỊ Tổng quan Mục tiêu phạm vi Tổ chức luận văn NGHĨA, KIẾN THỨC CƠ BẢN Một vài mơ hình mạng 1.1 Mơ hình client-server 1.1.1 Những điểm thuận lợi 1.1.2 Những hạn chế 10 1.2 Mơ hình IP multicast 10 1.2.1 Những thuận lợi 10 1.2.2 Hạn chế 10 1.3 Mạng peer-to-peer (P2P) 10 Sự đời kỹ thuật ALM, phân loại 11 2.1 Sự đời kỹ thuật ALM 11 2.2 Phân loại ALM 13 ƯƠ Ấ 14 ĐỀ VÀ CÁC GIẢI PHÁP LIÊN QUAN 14 Một số vấn đề ứng dụng Internet TV 14 Một số giải thuật truyền liệu phân tán 1-to-N 14 2.1 ALMI 14 2.1.1 Giới thiệu 14 2.1.2 Giải thuật thêm thành viên vào hệ thống 15 2.1.3 Cách trì 16 2.1.4 Cách truyền liệu hệ thống 17 2.1.5 Một số đặc điểm ALMI 17 2.2 CAN 17 2.2.1 Giới thiệu 17 2.2.2 Giải thuật peer tham gia vào CAN 17 2.2.3 Cách trì peer CAN 18 2.2.4 Cách truyền liệu CAN 19 2.2.5 Đặc điểm 19 2.3 HMTP (Host Multicast Tree Protocol) 20 2.3.1 Giới thiệu 20 2.3.2 Giải thuật thành viên gia nhập vào hệ thống 21 2.3.3 Cách trì thành viên nhóm 21 2.3.4 Cách truyền liệu 21 2.3.5 Đặc điểm 21 2.4 NICE 22 2.4.1 Giới thiệu 22 .2.4.2 Giải thuật gia nhập thành viên 22 2.4.3 Cách trì giải thuật thành viên rời khỏi nhóm 24 2.4.4 Cách truyền liệu NICE 24 2.4.5 Đặc điểm 24 2.5 Scribe/Pastry 24 2.5.1 Pastry protocol 25 2.5.2 Giải thuật peer tham gia vào Pastry 26 2.5.3 Scribe 27 2.5.4 Giải thuật peer tham gia vào scribe 27 2.5.5 Đặc điểm 27 Một vài loại hệ thống P2P live streaming 27 3.1 Hệ thống P2P live streaming có cấu trúc 27 3.1.1 Một đơn 28 3.1.2 Nhiều 28 3.2 Hệ thống P2P live streaming khơng có cấu trúc 29 Một vài giải pháp P2P live streaming 29 4.1 Giải pháp P2PCast 29 4.1.1 Mục tiêu 30 4.1.2 Môi trường giả định 30 4.1.3 Những nguyên tắc thiết kế 31 4.1.4 Giao thức P2Pcast 31 4.1.4.1 Giải thuật peer tham gia vào hệ thống 32 4.1.4.2 Giải thuật xóa peer từ hệ thống 35 4.1.5 Kiến trúc P2Pcast 36 4.2 Giải pháp PULSE 36 4.2.1 Khái niệm chung 37 4.2.1.1 The stream 37 4.2.1.2 Quản lý tri thức 38 4.2.1.3 Trao đổi chunk hệ thống 38 4.2.1.4 Lựa chọn chunk 39 4.2.2 Giải thuật 40 4.2.2.1 Một peer tham gia vào hệ thống 40 4.2.2.2 Quản lý peers hệ thống 41 4.2.2.3 Việc đồng thời gian peers hệ thống 43 4.2.2.4 Lựa chọn peer để gửi Red Message 44 4.2.2.5 Việc trao đổi chunk hệ thống 45 4.2.2.6 Một peer rời khỏi hệ thống 45 4.2.3 Kiến trúc hệ thống 46 Đánh giá 48 ƯƠ Ả 49 PHÁP PULSE CẢI TIẾN 49 Tổng quan 49 Một vài hạn chế giải pháp PULSE 49 Giải pháp cải tiến 50 3.1 Xây dựng server để quản lý peers hệ thống 50 3.2 Giải thuật peer tham gia vào hệ thống 51 .3.3 3.4 ƯƠ Giải thuật peer rời khỏi hệ thống 52 Trao đổi chunk hệ thống 52 53 SÁNH, ĐÁNH GIÁ 53 Đánh giá số lượng thông điệp 53 Ưu điểm 54 2.1 Về mặt giải thuật 54 2.2 Về mặt sử dụng 55 Nhược điểm 55 ƯƠ Ế À Ụ Ụ 56 LUẬN VÀ HƯỚNG PHÁT TRIỂN 56 LIỆU THAM KHẢO 58 LỤC A: Định dạng thông điệp 60 LỤC B: Pulse file 66 DANH MỤC HÌNH ình ình ình ình ình ình 2.1: Mơ hình mạng client- 2.2: Mơ hình mạng IP 10 2.3: Mơ hình mạng 11 2.4: ALM dùng Multiple 12 2.5: ALM dùng lớp mạng bao 12 ủ 2.6: Phân loại kỹ thuật 13 (a) N yêu cầu gia nhập nhận dẫn từ peer điều 15 ển (b) N khảo sát node có gửi kết đển node điều 16 ển (c) N yêu cầu để làm C cha 16 ình ình ình ình ình ình ình ình ình ình ình ình ình ình ình ình ình 3.1: Một peer tham gia vào hệ thống dùng giải thuật 16 3.2: Một peer tham gia vào hệ thống dùng 18 3.3: Truyền liệu dùng giải thuật 19 3.4: Kiến trúc 20 3.5: Kiến trúc 22 3.6: Một peer tham gia vào hệ thống dùng 23 3.7: Truyền liệu dùng giải thuật 24 3.8: Bảng định tuyến Pastry cho peer với ID 0x65a1… 25 3.9: Cách tìm đường 26 3.10: Peer ngẫu nhiên incomplete 33 3.11: Peer ngẫu nhiên only-child 33 3.12: Peer ngẫu nhiên complete 34 3.13: Một peer rời khỏi hệ 35 ống 3.14: Kiến trúc 36 3.15: Cấu trúc đệm 37 ệu 3.16: Lược đồ peer tham gia vào hệ 40 ống 3.17: Lược đồ đồng thời gian contact 43 ình ình ình ình ình ình ình ình ình ình ình ình ình 3.18: Sắp xếp peer cho việc lựa chọn Red 44 3.19: Kiến trúc 47 4.1: Tượng tác source-server- 50 4.2: Lược đồ peer tham gia vào hệ 51 ống A.1: Pulse message 60 A.2: Hello 61 A.3: Blue 61 A.4: Bye 62 A.5: Synchronization 62 A.6: Red 63 A.7: Data 64 A.8: Hello temp 65 A.9: Response PULSE 65 CHƯƠNG GIỚI THIỆU 1.1 Tổng quan Từ năm 90, Internet kênh để truyền bá thơng tin Khi Internet phát triển có nhiều hạn chế không mở rộng, băng thông hổ trợ 56Kbps thông qua đường dây điện thoại Từ năm 2000, kỹ thuật Internet đời giúp cải thiện băng thông nhiều Với phát triển này, ngày Internet không kênh thơng tin mà cịn cung cấp nhiều dịch vụ ứng dụng cần băng thông rộng Một loại ứng dụng yêu cầu Internet băng thông ộr ng truyền liệu đa truyền thông (multimedia data) Cách đơn giản để truyền file đa truyền thông thực truyền gói file Nội dung đơn giản file mà kích thước xác định nơi gửi Người dùng muốn xem file này, họ phải lấy file trước xem Có nhiều cách để lấy file, lấy dựa vào ứng dụng client-server hay dựa vào ứng dụng chia sẻ file P2P (Peer-to-Peer), v.v Cũng có cách khác để truyền file đa truyền thơng, mà nội dung truyền thành dịng liệu liên tục từ nguồn Người dùng khơng cần phải lấy toàn file trước xem mà cần tái tạo lại dòng liệu nhận xem trực tiếp Có hai cách để truyền liệu liên tục: theo yêu cầu live streaming Dữ liệu truyền theo yêu cầu: nội dung liệu đa truyền thơng biết trước kích thước lưu trữ nguồn lấy Khi người dùng muốn xem file này, họ tương tác với nơi chứa file để lấy Vấn đề lớn với cách người dùng phải đợi để tìm nơi chứa file Live streaming: hay gọi truyền liệu thời gian thực V ới cách nội dung liệu đa truyền thông truyền tạo từ nguồn mà không cần yêu cầu Người xem phải xem thông tin họ tham gia vào hệ thống Với đặc điểm này, kích thước liệu khơng định trước người xem khơng biết kết thúc Khó khăn lớn với phương pháp thời gian trễ từ người xem so với nguồn Mơ hình client-server thích ợhp cho phương pháp truyền liệu live streaming, khơng thể thực để đáp ứng số lượng người xem lớn Bởi server có lượng băng thơng cố định phục vụ cho lượng người xem giới hạn Để khắc phục hạn chế trên, kỹ thuật IP Multicast xem phương pháp tốt để phân phối liệu từ nguồn đến nhóm người xem Tuy nhiên việc phát triển IP Multicast có nhiều hạn chế Đầu tiên yêu cầu thay đổi thiết bị mạng có, điều khó khăn, phức tạp tăng trùng lặp liệu router khơng phải tất thiết bị mạng hổ trợ sẵn IP Multicast Ngoài ra, l ý quan trọng nhiều nhà cung cấp dịch vụ tắt chức này, họ khơng muốn người dùng dùng dịch vụ họ mà không trả tiền Từ ý tưởng xây dựng multica st mức ứng dụng [9] hình thành Những gói liệu khơng cịn tái tạo router mà tái tạo thiết bị tham gia vào mạng (hosts) Điều giải hạn chế thay đổi sở hạ tầng mơ hình IP Multicast giải vấn đề mở rộng mơ hình client-server Có nhiều ứng dụng phát triển dựa kỹ thuật Một kỹ thuật khác dùng mạng P2P cho việc truyền liệu live streaming Những peer mạng hoạt động client s erver thời điểm Hệ thống P2P live streaming tổ chức peer thành lớp bao phủ để nhắm tới vấn đề sau:  Sự phân tán: khơng có tập trung, phải có cộng tác peer tham gia vào, cơng việc peer hoàn thành cách cục Với đặc điểm hệ thống khơng có vấn đề giới hạn tài nguyên, đồng thời peer chết không nguyên nhân hệ thống chết  Chất lượng đường truyền liệu: từ liệu nhân host tăng độ an toàn cho liệu , hệ thống đường truyền liệu từ nguồn tới peer khác chất lượng đường truyền phụ thuộc vào số peer tham gia vào hệ thống  Độ ổn định: host ítổn định so với router thiết bị mạng khác, host tham gia hay rời hệ thống lúc nào, chí peer chết dễ dàng tham gia vào hệ thống Vì hệ thống cần phải hạn chế ảnh hưởng peer tham gia vào rời khỏi hệ thống  Thông điệp điều khiển: hệ thống cần có thơng điệp điều khiển để trì hệ thống Vấn đề để giảm số lượng thông điệp điều khiển trao đổi peer  Khả thích nghi: điều liên quan tới tính khơng đồng peer hệ thống Những host có lượng tài nguyên khác Những hệ thống phải khám phá tất tài nguyên sẵn có peer tham gia vào hệ thống  Sự công bằng: ứng dụng phải quan tâm tới công bằng, hệ thống nhắm tới việc peer muốn tải liệu phải đóng góp vào việc truyền liệu  Nội dung: nội dung phải nhân host, truyền cho peer khác khoảng thời gian Vấn đề liệu chậm trễ phải xem xét Từ cho thấy kỹ thuật mạng P2P phù hợp với ứng dụng live streaming Hiện có ứng dụng live streaming dùng kỹ thuật mạng P2Pcast [12], giải pháp dùng mạng P2P có ấcu trúc PULSE [ 20], giải pháp mạng P2P khơng có cấu trúc Với khả dễ mở rộng giải pháp PULSE phù hợp với u cầu ứng dụng Internet TV Tuy nhiên vài hạn chế giải pháp PULSE vấn đề tải nguồn peer muốn tham gia vào hệ thống phải tương tác với nguồn, số lượng thông điệp trao đổi nhiều tăng theo số lượng peer có hệ thống mà ảnh hưởng đến băng thơng, ngồi vấn đề khơng đồng thơng tin cấu hình nguyên nhân peer tham gia vào hệ thống thành công 1.2 Mục tiêu phạm vi Mục tiêu đề tài đưa giải pháp cải tiến từ giải pháp PULSE để khắc phục hạn chế giải pháp PULSE Đề tài trọng việc tham gia rời hệ thống nhanh số peer Ngoài ra, đề tài giảm thiểu lượng thông điệp điều khiển trao đổi Mà cụ thể, peer tham gia vào hệ thống liên lạc với peer ngẫu nhiên (contact peer) từ peer tồn hệ thống Đồng thời, peer kết nối nhận liệu tạm thời từ contact peer khoảng thời gian qui định Với cải tiến này, vấn đề tải nguồn không đồng liệu giải Đồng thời số lượng thông điệp điều khiển peer tham gia vào hay rời hệ thống nhanh số thay phụ thuộc vào số lượng peer có hệ thống 1.3 Tổ chức luận văn Phần lại luận văn chia thành chương sau: Chương 2: định nghĩa, kiến thức Chương 3: vấn đề giải pháp liên quan Chương 4: giải pháp PULSE cải tiến Chương 5: so sánh, đánh giá Chương 6: kết luận, hướng phát triển CHƯƠNG ĐỊNH NGHĨA, KIẾN THỨC CƠ BẢN 2.1 Một vài mơ hình mạng 2.1.1 Mơ hình client-server Client-server mơ hình phổ biến Trong mơ hình có server trung tâm, tất client phải giao tiếp với server Dữ liệu truyền trực tiếp từ server đến client ngược lại mà không thông qua client trung gian Hình 2.1: Mơ hình mạng client-server 2.1.1.1 Những điểm thuận lợi  Tất liệu lưu trữ máy chủ có tính bảo mật cao Ngồi cịn điều khiển việc truy xuất liệu máy Client  Dữ liệu lưu trữ tập trung dễ dàng cho việc cập nhập liệu cần thiết 2.1.1.2 Những hạn chế  Tắt nghẽn đường truyền mạng  Dữ liệu lưu máy chủ dẫn đến việc mát liệu đường truyền 2.1.2 Mơ hình IP multicast IP Multicast kiểu truyền liệu mạng, liệu đượ c truyền từ peer đến nhóm peer lại Việc thực truyền nhận hay định tuyến dựa vào lớp mơ hình OSI Hình 2.2: Mơ hình mạng IP Multicast 2.1.2.1 Những thuận lợi  Hiệu mặt truyền liệu  Dữ liệu truyền nhanh so với mơ hình Unicast 2.1.2.2 Hạn chế  Khó quản lý mạng  Khó mở rộng  Khó giải vấn đề tắt nghẽn  Chưa có khả chịu đựng lỗi 2.1.3 Mạng peer-to-peer (P2P) Mạng P2P khai thác kết nối thành viên mạng tận dụng băng thông thành viên tham gia vào mạng tập trung tài nguyên máy chủ Mạng hữu dụng cho nhiều ứng dụng: file sharing, video streaming … Một mạng P2P nguyên gốc không tồn khái niệm máy chủ máy khách riêng lẻ, tồn peers ngang hàng nhau, m ột pee r mô chức client server peer khác mạng 10 CHƯƠNG SO SÁNH, ĐÁNH GIÁ 5.1 Đánh giá số lượng thông điệp Đề tài giải nhiều vấn đề: tải nguồn, khơng đồng thơng tin cấu hình giảm số lượng thông điệp trao đổi peer tham gia vào hay rời hệ thống cách nhanh chóng Trong phần trình bày kết thực nghiệm số lượng thông điệp trao đổi Những vấn đề cịn lại thấy cải tiến cách hiển nhiên Tuy nhiên hạn chế tài nguyên nên giả lập 17 peers máy P: số lượng peer tồn hệ thống N1: số lượng thông điệp trao đổi peer tham gia vào hệ thống với giải thuật cũ N2: số lượng thông điệp trao đổi peer tham gia vào hệ thống với giải thuật L1: số lượng thông điệp trao đổi peer rời hệ thống với giải thuật cũ L2: số lượng thông điệp trao đổi peer rời hệ thống với giải thuật P N1 N2 10 21 35 16 82 Bảng 5.1: Số lượng thông điệp trao đổi peer tham gia vào hệ thống S ố lượng thông điệp 90 80 70 60 50 40 30 20 10 N1 N2 16 Số lượng peer Biểu đồ thể số lượng thông điệp trao đổi peer tham gia vào hệ thống 53 P L1 L2 1 1 17 Bảng 5.2: Số lượng thông điệp trao đổi peer rời hệ thống S ố lượng Bye Message 3.5 L1 2.5 L2 1.5 0.5 17 Số lượng peer hệ thống Biểu đồ thể số lượng thông điệp trao đổi peer rời khỏi hệ thống Từ cho thấy với giải thuật mới, số lượng thông điệp trao đổi peer tham gia hay rời hệ thống khoảng thời gian qui định số, với giải thuật cũ, số lượng thông điệp trao đổi tăng nhanh theo số lượng peer hệ thống ; số lượng thông điệp tối đa có peer tham gia hay rời hệ thống (N+6) + 5.2 Ưu điểm 5.2.1 Về mặt giải thuật Bởi contact peer chọn ngẫu nhiên từ danh sách peer ồt n hệ thống giảm tải cho nguồn so với giải pháp PULSE nguyên thủy Một peer tham gia vào hệ thống kết nối tạm thời đến contact peer mà peer khác hệ thống khơng biết Điều làm giảm số lượng thông điệp trao đổi peer tham gia hệ thống Trong khoảng thời gian kết nối tạm, peer muốn rời khỏi hệ thống thơng báo với contact peer hệ thống, ảnh hưởng cục 54 giảm số lượng thông điệp trao đổi , điều thuận lợi cho việc chuyển kênh internet TV 5.2.2 Về mặt sử dụng Khi nguồn bắt đầu truyền liệu tạo file cấu hình “.pulse” mà chứa thơng tin đệm, tốc độ truyền thời gian bắt đầu nguồn Một peer muốn tham gia vào hệ thống cần biết thông tin file Với giải thuật mới, thông tin lưu trữ server peer muốn tham gia vào hệ thống liên lạc với server để lấy thông tin thơng tin suốt với người dùng 5.3 Nhược điểm Dùng server để lưu điều phối contact peer, điều nguyên nhân tải server Contact peer chọn ngẫu nhiên từ peer hệ thống, có nhiều peer tham gia kết nối tạm vào contact peer nguyên nhân gây cạn kiệt tài nguyên contact peer 55 CHƯƠNG KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN Sự phát triển Internet băng thông rộng đáp ứng yêu cầu số ứng dụng, ứng dụng Internet TV Đề tài tìm hiểu yêu cầu ứng dụng Internet TV, số giải thuật ALM có Ngồi ra, đề tài tìm hiểu kỹ thuật mạng P2P giải vấn đề thắt nút mạng client-server truyền thống Một số phương pháp dùng kỹ thuật mạng P2P: phương pháp có cấu trúc, phương pháp khơng có cấu trúc phương pháp lai Đề tài tìm hiểu chi tiết hai giải pháp P2Pcast, giải pháp dùng phương pháp P2P có cấu trúc PULSE, giải pháp dùng phươn g pháp P2P khơng có cấu trúc Mỗi phương pháp có điểm mạnh yếu riêng , tùy thuộc vào yêu cầu ứng dụng mà chọn phương pháp tương ứng Với yêu cầu mở rộng ứng dụng Internet TV, phương pháp P2P khơng có cấu trúc thích hợp ứng dụng dùng phương pháp khơng có cấu trúc PULSE Giải pháp PULSE nguyên thủy có hạn chế tải nguồn peer muốn tham gia vào hệ thống phải tương tác với nguồn, số lượng thông điệp trao đổi nhiều tăng theo số lượng peer có hệ thống mà ảnh hưởng đến băng thơng, ngồi vấn đề khơng đồng thơng tin cấu hình ngun nhân peer tham gia vào hệ thống thành công Giải pháp đề tài phát triển từ giải pháp PULSE trọng việc yếu tố gia nhập rời khỏi nhóm nhanh số nút Ngoài ra, đề tài tập trung giảm thiểu số lượng thông điệp điều khiển Mà cụ thể xây dựng server trung gian để quản lý peer tồn hệ thống peer tham gia tạm vào hệ thống khoảng thời gian trước tham gia thức Kết đo đạc từ chương cho thấy, giải pháp cải tiến giải vấn đề hạn chế Tuy nhiên với phức tạp thời gian hạn chế, chắn hệ thống khơng tránh khỏi khuyết điểm mà cần có hướng phát triển tiếp theo: Trong đề tài chưa đề cập việc phân vùng peer để server quản lý cung cấp contact peer tốt cho new peer, điều ảnh hưởng đến thời gian gia nhập vào hệ thống new peer Nếu có nhiều peer kết nối tạm vào contact peer hệ thống mà nguyên nhân cạn kiệt tài nguyên contact peer Vì cần phải đưa 56 trọng số băng thông số lượng peer tạm tối đa để định xem contact peer có nên nhận thêm peer tạm hay khơng Nếu có nhiều peer tham gia vào hệ thống lúc nguyên nhân tải server Thật khó để giải vấn đề này, dùng server mạnh redundant server cách tốt để hạn chế vần đề 57 TÀI LIỆU THAM KHẢO [1] ALMI: D Pendarakis, S Shi, D Verma, and M Waldvogel, Almi: An Application Level Multicast Infrastructure In Proceedings of the 3rd USENIX Symposium on Internet Technologies and Systems (USITS), pages 49 60, 2001 [2] CAN: S Ratnasamy, M Handley, R Karp, and S Shenker ApplicationLevel Multicast using Content-Addressable, in Proc of NGC, Nov 2001 [3] DVMRP: Distance Vector Multicast Routing Protocol, RFC 1075, ://www.ietf.org/rfc/rfc1075.txt [4] HMTP: B Zhang, S Jamin, and L Zhang Host Multicast: A framework for delivering multicast to end users In Proceedings of IEEE Infocom, June 2002 [5] Narada: Y Chu, S G Rao, S Seshan, and H Zhang A Case for End System Multicast [6] NICE: S Banerjee, B Bhattacharjee, and C Kommareddy Scalable Application Layer Multicast [7] Yoid: P Francis Yoid: Extending the Multicast Internet Architecture, 1999 White paper ://www.aciri.org/yoid/ [8] ://en.wikipedia.org/wiki/Peer-to-peer [9] Nick Blundell: Voice over Application-Level Multicast [10] Peter druschel: SplitStream: High Bandwidth Context Distribution in Coorperative Enviroments [11] Maya Dobuzhskaya: Zebra: Peer To Peer Multicast for Live Streaming Video 58 [12] Antonio Nicolosi: P2Pcast: A peer-to-peer Multicast Scheme for Streaming Data [13] Xinyan Zhang: CoolStreaming/DONet: A Data-Driven Overlay Network for Efficient Live Media Streaming [14] Laurent Massoulie, Andy Twigg, Christos Gkantsidis, and Pablo Rodriguez:Randomized Decentralized Broadcasting Algorithms [15] Fabio Pianese: "P2P Live Media Streamig: Delivering Data Streams to Massive Audiences within Strict Timing Constraints", master thesis, September 2004 [16] ://en.wikipedia.org/wiki/PULSE_(P2PTV) [17] ://www.napa-wine.eu/cgi-bin/twiki/view/Public/PULSE [18] David Karoly, 2008 04 24 Pulse Quick Start Guide [19] Fabio Pianese, Joaquin Keller, Ernst Biersack: "Pulse, a flexible P2P Live Streaming System", Proceedings IEEE Infocom, April 2006 [20] Diego perino: The PULSE system: A New P2P Protocol for Live Streaming [21] Deigo Perino: P2P System Live Streaming and Measurements on Internet [22] Fabio Pianese and Diego perino: Resource and Locality Awareness in an Incentive-based P2P Live Streaming System [23] Diego Perino and Fabien Mathieu: Distribution Trees’ Analysis of PULSE, an Unstructured P2P Live Streaming System [24] Fabio Pianese: PULSE A Practical Approach To P2P Live Streaming [25] David L Mills: RFC1305 - Network Time Protocol (Version 3) Specification , Implementation and Analysis 59 PHỤ LỤC A: Định dạng thông điệp Pulse header 3 456 78 90 23 45 67 89 12 45 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pulse version | Message type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender peer IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender peer TCP port | Sender peer UDP port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.1: Pulse message header Pulse version: trường định phiên mà bên gửi dùng Message type: để phân biệt kiểu thông điệp protocol Flags: Có flags dùng PULSE protocol: connected contact, chi tiết flags trình bày lúc dùng Sender peer IP address: trường 32 bits định IP address peer mà gửi thông điệp Sender TCP port: dùng để định port dùng cho kết nối TCP Sender UDP port: dùng để định port dùng cho kết nối UDP 60 Hello message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originate Timestamp (64 bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.2: Hello message Originate timestamp: trường 64 bits mà định thời gian thông điệp gửi bên gửi The contact _flag: contact flag dùng thông điệp để bên nhận nhận thông điệp peer hay nhận từ peer tồn Blue message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transmit Timestamp (64 bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tb_avg | Td | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.3: Blue message Transmit timestamp: trường 64 bits mà định thời gian blue message gửi Tbavg: Tbavg bên gửi Td: Td bên gửi 61 Bye message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replace peer IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replace peer TCP port | Replace peer UDP Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.4: Bye message Replace peer IP address: IP address peer dùng để thay cho sender peer từ PartialView bên nhận Replace peer TCP port: TCP port peer dùng để thay cho sender peer từ PartialView bên nhận Replace peer UDP port: UDP port peer dùng để thay cho sender peer từ PartialView bên nhận Syncronization message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originate Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receive Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transmit Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender peer clock derive (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.5: Synchronization message 62 Originate timestamp: thời gian Hello Message gửi new peer Receive timestamp: thời gian Hello Message nhận local peer Transmit timestamp: thời gian Synchroniztion Message gửi local peer Sender peer clock derive: độ chậm trễ local peer so với nguồn Red message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transmit Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk@Tb_ist | Tb_avg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Td | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Bitmap (64*n) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request n-1 | Request n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.6: Red message Transmit timestamp: thời gian Red Message gửi local peer Chunk@Tbist: Tbist peer gửi Tbavg: Tbavg peer gửi Td: Td peer gửi Bitmap: chuỗi bits đại diện cho trading window peer gửi Những bits có giá trị hay Giá trị định peer gửi có chunk vị trí tương ứng trading window Chiều dài Bitmap phụ thuộc vào chiều dài trading window mà nhập từ file cấu hình PULSE 63 Request i: trường định chunk yêu cầu peer gửi peer nhận Số lượng chunk yêu cầu tối đa cấu hình PULSE file Nếu khơng có đủ u cầu giá trị điền vào field The connected _flag: dùng thơng điệp để định peer gửi có đủ số lượng chunk đệm hay chưa Data message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk number | Data legnth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Chunk generation time (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data (data length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.7: Data message Chunk number: số thứ tự chunk mà gửi packet Data length: số lượng bytes nội dung liệu chunk truyền thông điệp Chunk generation time: thời gian chunk tạo nguồn Data: chứa nội dung chunk, chiều dài định nghĩa file cấu hình PULSE 64 Hello temp message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originate Timestamp (64 bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.8: Hello temp message Originate timestamp: trường 64 bits mà định thời gian thông điệp gửi new peer Response PULSE message 34 56 78 90 12 45 67 89 01 34 67 89 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | contact peer (64 bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PULSE buffer (length of pulse file) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình A.9: Response PULSE message Contact peer: chứa IP address, TCP port, UDP port contact peer PULSE buffer: chứa nội dung PULSE file 65 PHỤ LỤC B: Pulse file Example of “.pulse” file Stream_initial_time 1155815656.75 Chunk_size 8000 Stream_rate 128000 Sliding_window_size 32 Tk 100 Admitted_packet_lost Value_of _Tb_at_bootstrapt 56 Max_value_for_Tb_at_bootstrap 64 Reconnect_threshold 394 Interval_of_time_used_to_compute_Tb_avg Contact_IP 172.24.11.33 Contact_TCP_port 2222 Contact_UDP_port 2224 Example of node configuration's file Red_message_rate 16 Blue_message_rate 0.01 Max_upload_rate Max_download_rate TCP_port 2225 UDP_port 2226 Max_number_of_peers_in_red_message_list 16 Max_number_of_missing_peer Max_number_of_missing_peer_selected_by_tft 66 Max_number_of_forward_peers Epoch_duration History_score_initial_value 10 Total_max_requests Max_peer_to_send_requests Max_requests_to_send_to_each_peer Request_timeout 0.25 Inteval_of_time_used_to_average_the_rate 2.0 Max_number_of_times_to_forward_a_Blue_msg Max_number_of_time_to_forward_an_Hello_msg Heartbeat_timeout_blue 1000 Reconnection_timeout 50000 Red_knowledge_timeout 1.0 Blue_knowledge_timeout 1000.0 67 ... thấy kỹ thuật mạng P2P phù hợp với ứng dụng live streaming Hiện có ứng dụng live streaming dùng kỹ thuật mạng P2Pcast [12], giải pháp dùng mạng P2P có ấcu trúc PULSE [ 20], giải pháp mạng P2P. .. Phân loại kỹ thuật ALM 13 CHƯƠNG VẤN ĐỀ VÀ CÁC GIẢI PHÁP LIÊN QUAN 3.1 Một số vấn đề ứng dụng Internet TV Internet TV ngày trở nên phổ biến, nhiên việc phát tr iển ứng dụng internet TV phải đảm... 3.4.2.2 Giải thuật Trong đoạn mô tả vài giải thuật giải pháp PULSE 3.4.2.2.1 Một peer tham gia vào hệ thống Một peer muốn tham gia vào hệ thống P2P cấu trúc cần biết điểm giao tiếp mạng Điểm giao tiếp