CHƢƠNG 2 : HỆ THỐNG LUỒNG VIDEO QUA MẠNG NGANG HÀNG
3.2 Q trình truyền tin multicast trong nhóm Scribe
3.2.1 Chi tiết giải thuật
Mơ hình
Mơ hình thực thi Scribe là một mạng Pastry trong đó các máy có cài đặt chương trình ứng dụng của Scribe. Chương trình ứng dụng này sẽ cung cấp cho các máy này hai phương thức là forward (được gọi khi một thông điệp định tuyến qua một nút) và deliver (được gọi khi thơng điệp đến một nút mà có nodeId gần với key nhất hoặc nội dung thơng điệp chính là địa chỉ của nút đó). Các thơng điệp trong Scribe có 4 kiểu là: JOIN (xin tham gia vào một nhóm), CREATE (tạo một nhóm mới), LEAVE (rời khỏi nhóm), MULTICAST (truyền thơng điệp multicast).
- Quản lý nhóm:
Mỗi nhóm truyền multicast có một định danh groupId duy nhất.
Scribe node (tức là nút trong mạng có cài chương trình ứng dụng Scribe) có Id gần với Id của nhóm (groupId) nhất được gọi là “điểm gặp” và nó cũng chính là gốc của cây multicast tương ứng với groupId này ln).
- Tạo nhóm: Một nút Scribe nào đó muốn khởi tạo một nhóm thì các bước thực
hiện sẽ là:
B1: Nút Scribe dùng Pastry định tuyến thông điệp router (CREATE , groupId). B2: Giao thức Pastry sẽ gửi thông điệp này tới điểm cuối là một nút có nodeId
gần với groupId nhất. Và nút này sẽ được xem như là gốc của nhóm mới tạo ra.
B3: Hệ thống sẽ kiểm tra độ an tồn, các thơng tin về chứng thực. Nếu khơng có
vấn đề gì thì sẽ thêm nhóm mới vào danh sách nhóm đã biết trong mạng.
Trong việc tạo nhóm, bước quan trọng nhất chính là bước kiểm tra độ an toàn và chứng thực thơng tin, vì điều này có ảnh hưởng rất lớn tới sự an toàn của toàn mạng nói chung chứ khơng chỉ riêng sự an tồn của nhóm multicast.
- Quản lý thành viên:
Một nhóm về phương diện logic là một cây multicast có gốc là “điểm gặp”, mỗi khi có một nút mới được join vào nhóm thì nó sẽ trở thành một thành viên của nhóm cũng như trở thành một thành phần của cây multicast, vì thế phải có cơ chế hợp l để tổ chức, quản lý các thành viên của nhóm. Nếu một nút Scribe là một phần của nhóm thì về phương diện cây multicast thì nó là một forwarder. Mỗi một forwarder duy trì một bảng gọi là children table mà mỗi mục của bảng này sẽ gồm 2 trường : địa chỉ IP của một nút con nào đó của nó (IP Adds) và nodeId tương ứng của nút con đó.
Lê Ngọc Anh – D09VT2 58
3.2.2 Qu tr nh gia nhập nhóm (join group):
Khi một nút muốn join vào một nhóm nào đó, nó sẽ thực hiện các bước sau:
Gửi thơng điệp JOIN với groupId của nhóm cần tham gia làm key: route (JOIN,
groupId).
Giao thức Pastry sẽ định tuyến nó tới “điểm gặp”.
- Nếu nút trung gian trong q trình truyền thơng điệp là một forwarder (một thành phần của nhóm đang định tham gia vào) thì đơn giản chỉ là thêm nút cần tham gia vào làm một nút con của nút forwarder này.
- Nếu nút trung gian khơng phải là một forwarder của nhóm cần tham gia vào thì thực hiện các bước:
+ Tạo một children table cho nút trung gian và thêm thông tin của nút cần tham gia vào bảng này.
+ Gửi thông điệp JOIN của nút trung gian tới “điểm gặp” ( lúc này thay cho việc thực hiện tham gia nút ban đầu, ta đi tham gia nút trung gian vào nhóm). Và cứ thực hiện đệ quy như thế này ta sẽ có được một danh sách các nút mới tham gia vào nhóm thay vì chỉ một nút như ban đầu.
Để dễ hiểu, ta xét ví dụ sau: Một nhóm có “điểm gặp” là A có nodeId = 1100 (như ở hình vẽ dưới).
Hình 3.3 Quá trình 1 nút gia nhập vào nhóm
Nút B có nodeId là 0111 muốn tham gia vào nhóm có A là gốc, nó sẽ gửi gói tin route (JOIN,x) với x là groupId của nhóm này, giao thức Pastry sẽ định tuyến gói tin tới nút D có nodeId là 1001. Nhưng nút D không phải là một thành phần của nhóm này cho nên D sẽ tạo ra một children table của nó và thêm vào đó mục (122.45.1.23 ; 0111). Tiế theo D sẽ gửi gói tin yêu cầu tham gia vào nhóm có gốc A : route (JOIN ,x). Tiếp tục giao thức Pastry lại định tuyến nó tới nút E và E cũng khơng phải thành viên của nhóm này. Vì thế E cũng tạo ra một children table của nó và thêm mục (172.16.2.13; 1001). Và sau đó E gửi gói tin route (JOIN,x). Gói tin này tiếp tục được định tuyến và tới A vì A là một thành phần của nhóm cho nên ở đây A sẽ thêm mục
Lê Ngọc Anh – D09VT2 59
(10.10.1.123;1101) vào children table của nó. Kết quả là ta sẽ có thêm 3 thành phần mới của nhóm là B, D và E.
3.2.3 Quá tr nh rời nhóm (leave group)
Khi một nút nào đó muốn rời khỏi nhóm thì nó sẽ ghi một cách cục bộ rằng nó đã rời khỏi nhóm (tức là chỉ một mình nó biết là nó đã rời khỏi mạng). Sau đó nếu bảng children table của nút này là rỗng (tức là nó khơng có con trong cây multicast) thì nó sẽ gửi thơng điệp LEAVE tới cha của nó trong cây multicast. Thơng điệp này sẽ được đệ quy trong cây multicast cho tới khi nó tới một nút mà nút có con đã rời khỏi như trong trường hợp nó khơng có con nào cả. Sau đó các con của nó sẽ xem như nó bị lỗi và thực thi theo cơ chế sửa lỗi (sẽ trình bày ở dưới).
Với cách gia nhập và rời khỏi nhóm như thế này và với đặc tính phân phối ngẫu nhiên của Pastry thì cây multicast sẽ được xây dựng một cách đồng đều theo nghĩa là không một nút nào trong cây mutlicast, ngay cả nút gốc phải chịu quá nhiều kết nối tới các nút khác. Việc này giúp cho Scribe có khả năng mở rộng về kích thước cũng mhư về khả năng, tức là cả khi tăng số lượng nút trong nhóm hay tăng các gói tin multicast gửi đến mạng thì Scribe vẫn có thể đảm đương được.
3.2.4 Truyền tin multicast tới mạng
Khi một nút nào đó muốn truyền multicast tới các điểm trong một nhóm nào đó thì nó sẽ gửi thơng điệp multicast tới “điểm gặp” (route (MULTICAST,rootId). Sau khi điểm gặp nhận được thông điệp này nó sẽ gửi trả lại nút kia IP của nó (rootIP), sau đó nút này sẽ truyền thơng tin muốn gửi tới điểm gặp. Điểm gặp này sẽ sao chép gói tin multicast này và gửi cho các con của nó trong cây multicast ( nếu có ). Các điểm con này khi nhận được dữ liệu cũng lại tiếp tục sao chép dữ liệu đó và gửi tới các con của nó trong cây ( nếu có ). Cứ lặp đi lặp lại như vậy và chỉ dừng lại việc này khi dữ liệu tới các nút là nút lá của cây.
Hình 3.4 Truyền tin multicast trong nhóm Scribe
Giả sử như hình vẽ ở trên, Sender là nút cần gửi dữ liệu cho cây multicast có gốc là 1100. Nó sẽ gửi gói tin route (MULTICAST, 1100). Nút 1100 nhận được gói tin và
Lê Ngọc Anh – D09VT2 60
trả lại cho sender địa chỉ IP của nó. Từ lúc này sender giao tiếp với nút gốc này thông qua IP (bây giờ là quan hệ trong giao thức TCP/IP chứ không liên quan tới Pastry hay P2P). Sender gửi dữ liệu cho nút gốc 1100. Nút này sẽ tạo ra một bản sao dữ liệu và gửi cho con của nó là 1101. Nút 1101 nhận được dữ liệu từ root, nó cũng sẽ tạo ra một bản sao và gửi cho 1001 là con của nó. Nút 1001 lại sao chép dữ liệu và gửi cho 0111 và 0100 là thành viên trong children table của nó. Khi các nút 0100 và 0111 nhận được dữ liệu, do nó là lá của cây multicast nên nó khơng làm gì nữa.
Trong vấn đề truyền dữ liệu multicast này có một điểm thú vị là khi sender muốn gửi dữ liệu multicast tới nhóm của nó lại phải xin và nhận IP của nút gốc rồi để sau đó giao tiếp với nút này dựa vào IP mà không sử dụng giao thức Pastry để gửi dữ liệu. Đơn giản là việc định tuyến cũng như việc gửi thông tin qua Pastry là một việc làm rất tốn thời gian và tai nguyên mạng, mà bình thường một sender khơng chỉ gửi một gói tin multicast tới mạng mà nó gửi một số hoặc nhiều gói tin. Do đó việc sender lưu IP của nút root và gửi gói tin trực tiếp sẽ tiết kiệm được thời gian cũng như tài nguyên mạng. Tuy nhiên nếu nút gốc bị lỗi hoặc bị rời khỏi mạng thì sender phải tìm lại IP của nút root mới và tiếp tục truyền thông tin.
3.2.5 Sửa cây multicast
Vì Scribe làm việc trong mơi trường mạng, do đó muốn duy trì được sự ổn định của nhóm thì cần phải có các cơ chế hợp l để giải quyết các vấn đề thường gặp phải trong mạng ngang hàng. Phần này sẽ đi sâu vào việc làm sao để sửa chữa một cây multicast khi một nút bị rời khỏi mạng.
Trong Scribe, nút cha sẽ định kỳ gửi các gói tin heartbeat tới nút con của nó nhằm thông báo sự tồn tại của mình trong cây. Nếu nút con khơng nhận được gói tin heartbeat do cha nó gửi tới trong một thời gian nào đó, nó sẽ xem như nút cha của nó bị lỗi. Và nó sẽ tự động tìm một nút cha khác thay thế, bằng cách gửi thông điệp JOIN với key là groupId của nhóm hiện tại (q trình này giống như q trình gia nhập vào nhóm).
Lê Ngọc Anh – D09VT2 61
Giả sử như hình vẽ trên, ban đầu ta có cây multicast với gốc là nút 1100, trong cây nút 1001 có cha là nút 1101. Khi nút 1001 không nhận được heartbeat của 1101 trong một khoảng thời gian nào đó, nó sẽ xem như 1101 bị lỗi và nó sẽ tự động gửi gói tin route (JOIN,groupId). Tiếp theo giống như trong quá trình gia nhập nhóm. Cây multicast sẽ được xây dựng lại và bây giờ thì nút 1001 nhận một nút mới là 1111 là cha mới của nó (như hình vẽ).
Trong trường hợp nút gốc bị lỗi thì các con của nó cũng chạy giải thuật như trên. Khi đó giải thuật Pastry sẽ tự chọn ra một nút gốc mới có nodetId gần nhất (tính theo hiện thời) với groupId và nhóm sẽ lại được duy trì như bình thường.
Vì khả năng chống lỗi cao như thế này, Scribe ln có tính sẵn sàng cao và chống chịu lỗi tốt, cho dù có nhiều nút lỗi cùng một lúc thì sau một thời gian ngắn cây multicast lại được xây dựng lại và ổn định như trước.
3.3 Cải thiện Scribe bằng cấu trúc Splitstream
Hiện nay, đã có những nghiên cứu xây dựng cây multicast dành cho truyền video streaming trên mạng ngang hàng có cấu trúc như Splitstream. Splitstream được xây dựng dựa trên nền tảng Pastry, Scribe và thêm vào đó một số giải pháp để hạn chế tình trạng quá tải tại một số nút tham gia mạng
3.3.1 Giới thiệu SplitStream
SplitStream là một hệ thống cây đa luồng đề xuất trong năm 2003 của trung tâm nghiên cứu của Microsoft. SplitStream được thiết kế để khắc phục tải trọng (load) chuyển tiếp không ổn định trong hệ thống multicast thông thường dựa trên đa cây. Ý tưởng chính của SplitStream là phân chia các luồng vào các khối độc lập không giống nhau và mỗi khối được truyền multicast sử dụng một cây riêng biệt. Để đảm bảo rằng các tải trọng được chuyển tiếp có thể được lan truyền trên tất cả các peer tham gia, một mạng lưới cây được xây dựng trong đó một nút là một nút nội bộ trong nhiều nhất là một cây và là một nút lá trong tất cả các cây khác. Một tập hợp các cây như vậy được gọi là interior – node - disjoint. Hình 3.6 minh họa cách SplitStream cân bằng tải được chia thành hai đường và gói tin được multicast trong hai cây riêng biệt. Mỗi peer, xa so với nguồn, nhận được cả hai luồng tin. Mỗi peer là một nút bên trong chỉ có một cây và là chuyển tiếp các khối nội dung đến hai nút con. Khi một nút bị quá tải nhận được yêu cầu từ nút con, nó hoặc là từ chối hoặc chấp nhận nút con và từ chối một nút con hiện tại của mình, nút con bị từ chối là kém hấp dẫn hơn so với nút con mới. Một nút sẽ được mong muốn nhiều hơn nếu nodeId của nó gần hơn với nút cha của nó.
SplitStream xây dựng các cây multicast cho các luồng trong khi vẫn quan tâm những hạn chế băng thơng trong và băng thơng bên ngồi của các peer. Nó cung cấp khả năng phục hồi thất bại các liên kết nút ra đi không báo trước và cây multicast được sửa chữa. Một trong những vấn đề chính với SplitStream là tác động của các nút
Lê Ngọc Anh – D09VT2 62
với băng thông không đồng nhất về hiệu quả của nó. Một vấn đề khác là trong một interior – node - disjoint, các nút nhận gói tin riêng biệt với độ trễ khác nhau ví dụ như các nút được đặt trong khoảng cách khác nhau từ gốc của cây. Điều này là không mong muốn cho một ứng dụng luồng truyền thơng trực tuyến, trong đó việc địi hỏi thời gian thực chính xác. Thêm vấn đề khác là tăng cường quy mơ hệ thống để cây có độ sâu lớn hơn và các nút được đặt trong khoảng cách đa dạng từ nguồn.
Hình 3.6 Một ví dụ đơn giản minh họa cách tiếp cận của SplitStream 3.3.2 Cơ chế xây dựng luồng trong SplitStream 3.3.2 Cơ chế xây dựng luồng trong SplitStream
Splitstream có thể được xem như là việc chọn lựa các cây Scribe để tạo nên cây multicast đa luồng. Việc lựa chọn các cấy Scribe sẽ dễ dàng tạo nên cây mulitcast đa luồng với tính chất: 1 nút là nút trong của 1 luồng sẽ là nút lá trong các luồng cịn lại.
Hình 3.7 Splitstream F luồng
Việc xây dựng các luồng khá đơn giản. Như ở trên hình 3.7, với khơng gian Pastry được đánh địa chỉ các nút gồm F ký tự. Splitstream sẽ chọn ra các luồng có tên là 0x, 1x, …, Fx để các nút sau khi gia nhập vào cây multicast đa luồng có thể đảm bảo. Nút có Id bắt đầu là 0x sẽ là nút trong của cây multicast stripeId 0x và là nút lá của tất cả
Lê Ngọc Anh – D09VT2 63
các luồng cịn lại. Tương tự nút có Id bắt đầu là 1x sẽ là nút trong của cây multicast stripeId 1x và là lá của tất cả các luồng còn lại.
Tuy nhiên, Splitstream sẽ gặp các vấn đề tại các máy (peer) tham gia nếu chỉ đơn thuần lựa chọn các cây Scribe để truyền các luồng vào thì là chưa đủ đáp ứng tính chất multicast.
- Không giới hạn được băng thông đi ra của 1 peer do như cầu join của các peer khác: khi 1 peer đã vượt quá băng thơng giới hạn đi ra thì các peer khác vẫn muốn gia nhập vào luồng của các peer này. Nếu vẫn duy trì cơ chế như cây Scribe thì sẽ có một số peer thật sự khơng nhận được dữ liệu từ 1 vài luồng do nút cha của nó khơng gửi dữ liệu thực sự đến cho nó.
Splitstream sử dụng cơ chế mới để giải quyết vấn đề tại các nút mà băng thông đi ra đã bị vượt quá giới hạn. Cơ chế này bao gồm:
- B1 : Xác định nút cha:
H nh 3.8 X c định nút cha khi băng thông đi ra vƣợt quá giới hạn
Trong ví dụ trên nút với Id là 080* đã bị limit outdegree (băng thông đi ra vượt quá giới hạn) thì nhận được yêu cầu join vào của nút với Id 001* ở luồng 0800. Nút 080* sẽ xem xét tất cả các nút con của nó để loại đi 1 nút con. Hình 3.8 (1) – (2) là trường hợp có nút con 9* nhận được nút 080* làm cha trong luồng 1800 khác với luồng 0800. Nút 080* sẽ nhận được nút 001* làm con và loại bỏ nút 9*. Sau đó nút 085* lại yêu cầu join vào nút 080*. Hình 3.8 (3) – (4) là trường hợp các nút con đều nhận 080* là cha trong luồng 0800, xét đến Id của các nút con. Nút 001* là nút có Id với số ký tự tính từ trái sang phải khác với luồng 0800 nhất. Nút 001* sẽ trở thành nút orphan và nút 085* được nhận làm nút con.
Lê Ngọc Anh – D09VT2 64
- B2: Nếu sau bước 1 vẫn có nút orphan (tức là nút chưa tìm được nút cha) sẽ tiến hành bước này. Nút orphan sẽ gửi unicast đến SCG (Spare Capacity Group) để tìm được nút cha. SCG là tập hợp tất cả các nút mà băng thông đi ra chưa vượt quá giới