Xây dựng giải thuật phân bố dữ liệu trên mạng internet

Hướng tiếp cận có ưu điểm là đã có sẳn một multicast protocol và protocol này chạy rất hiệu quả, ít chiếm băng thông trong mạng LAN, router chỉ cần gửi một gói dữ liệu là đủ để thực hiện

Trường Đại Học Bách Khoa

NGUYỄN ANH TÚ

XÂY DỰNG GIẢI THUẬT PHÂN BỐ

DỮ LIỆU TRÊN MẠNG INTERNET

Chuyên ngành: Khoa học Máy tính

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 11 năm 2007

ĐẠI HỌC QUỐC GIA TP HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

- -oOo -

Tp HCM, ngày 05 tháng 11 năm 2007

NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ và tên học viên : Nguyễn Anh Tú Giới tính : Nam
/ Nữ  Ngày, tháng, năm sinh : 22/05/1979 Nơi sinh : Bình Định

Chuyên ngành : Khoa học Máy tính

Khoá : 2005

1- TÊN ĐỀ TÀI :

XÂY DỰNG GIẢI THUẬT PHÂN BỐ DỮ LIỆU TRÊN MẠNG INTERNET

2- NHIỆM VỤ LUẬN VĂN :

3- NGÀY GIAO NHIỆM VỤ :

4- NGÀY HOÀN THÀNH NHIỆM VỤ :

5- HỌ VÀ TÊN CÁN BỘ HƯỚNG DẪN : TS Thoại Nam

Nội dung và đề cương Luận văn thạc sĩ đã được Hội Đồng Chuyên Ngành thông qua

(Họ tên và chữ ký)

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

Cán bộ hướng dẫn khoa học : TS Thoại Nam

Cán bộ chấm nhận xét 1 :

Cán bộ chấm nhận xét 2 :

Luận văn thạc sĩ được bảo vệ tại

HỘI ĐỒNG CHẤM BẢO VỆ LUẬN VĂN THẠC SĨ

TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày tháng năm 2007

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện và chưa

có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở trường này hoặc trường khác

Ngày 05 tháng 11 năm 2007 Nguyễn Anh Tú

Tôi xin gởi lời cảm ơn chân thành và sâu sắc nhất đến TS Thoại Nam, người Thầy đã tận tình hướng dẫn tôi trong suốt quá trình từ đại học tới cao học và tạo mọi điều kiện để tôi có thể hoàn thành luận văn này

Tôi cũng xin cảm ơn gia đình đã động viên và tạo mọi điều kiện tốt nhất để tôi có thể tiếp tục theo đuổi việc học tập nghiên cứu Tôi trân trọng dành tặng thành quả của luận văn này cho Cha Mẹ Nhờ công lao dưỡng dục của Người mà chúng con mới có được thành quả như ngày hôm nay Con xin hứa sẽ tiếp tục cố gắng phấn đấu để vươn cao hơn nữa

Chương 1:

GIỚI THIỆU 1

1 Đặt Vấn Đề 1

2 Các Giải Pháp Hiện Hữu 2

2.1 Server-Based Solution 2

2.2 Complete-Graph-Based Solution 3

2.3 Tree/Mesh Multicast Solution 3

3 Sơ Lược Về Giải Pháp 3

4 Kết Quả 5

Chương 2: TỔNG QUAN VÀ CÁC GIẢI PHÁP LIÊN QUAN 7

1 Multicast Protocols 7

1.1 Nice 7

1.2 Narada 10

1.3 PRISM 14

1.4 Yoid 14

1.5 ALMI 17

1.6 Host Multicast Tree Protocol 18

2 Kết Luận 20

Chương 3: SOLUTION: DYNAMIC NETWORK CONDITION ADAPTING MULTI-SOURCE MULTICAST PROTOCOL 22

1 Đặt Vấn Đề 22

2 Giải pháp 22

2.1 Mesh Building 22

2.2 Data Routing 22

2.2.1 Overview 22

2.2.2 Routing Version 24

2.2.3 Routing Table Organization 24

2.2.4 Routing Algorithm 27

2.3 Single-Source Multicast Protocol 28

2.3.1 Message Types 28

2.3.2 Data Structures 29

2.3.3 State Machine Diagram 31

2.3.4 Activity Diagrams 31

2.4 Multi-Source Multicast Protocol 36

2.4.1 Congested Detection 37

2.4.1.1 Overview 37

2.4.1.2 Congestion Types 37

2.4.1.3 Message Types 37

2.4.1.4 Data Structures 38

2.4.1.5 Congestion Level Control 41

2.4.1.6 End Point Relaxation 41

2.4.1.7 Congestion Detecting Algorithm 41

a Required Supports from TCP Layer 41

b Configuration Variables 42

c Message Queue Congestion Threshold 42

d Message Queue Congestion Threshold Delta 42

e Average Value of Sending Duartion 42

f Average Value of Receiving Duration 42

2.4.2 Network Condition Adaption 50

2.4.2.1 Overview 50

2.4.2.2 Message Types 50

2.4.2.3 Data Structures 51

2.4.2.4 Parent Changing Protocol 52

Chương 4: MÔ PHỎNG ĐÁNH GIÁ 62

1 Test Case 1 62

2 Test Case 2 63

3 Test Case 3 64

4 Test Case 4 65

5 Test Case 5 67

6 Test Case 6 68

7 Test Case 7 69

8 Test Case 8 70

9 Test Case 9 71

10 Test Case 10 73

11 Test Case 11 74

KẾT LUẬN 76

THAM KHẢO 77

Phụ Lục Chương 3: SOLUTION: DYNAMIC NETWORK CONDITION ADAPTING MULTI-SOURCE MULTICAST PROTOCOL 78

1 Mesh Building 78

1.1 Node Management 78

1.1.1 Overview 78

1.1.2 Message Types 78

1.1.3 Data Structures 79

1.1.4 Ping Protocol 80

1.1.5 Group Joining Protocol 83

1.1.6 Group Leaving Protocol 83

1.1.7 Died Node Detection 83

1.2 Neighbor Management 84

1.2.1 Overview 84

1.2.2 Message Types 84

1.2.3 Data Structures 85

1.2.4 Neighbor Adding Protocol 86

1.2.5 Neighbor Removing Protocol 88

1.2.6 Neighbors List Improvement 91

1.2.7 Ping Protocol 92

2 Single-Source Multicast Protocol 93

2.1 Broadcast Cancellation 93

2.2 Neighbor Removing 93

3 Multi-Source Multicast Protocol 95

3.1 Converged Detection 95

3.1.1 Data Structures 95

3.1.2 Message Types 96

3.1.3 Configuration Variables 96

3.1.4 The Algorithm 97

Phụ Lục Môi Trường Mô Phỏng:

Network Simulator 101

1 Overview 101

2 Examples 101

2.1 OTcl Script 101

2.2 C++ Code 102

Phụ Lục Thuật Ngữ: CÁC THUẬT NGỮ 104

1 ALM 104

2 BOM 104

3 Broadcast 104

4 Broadcast Message 104

5 Control Message 104

6 Current Node 104

7 Data Message 104

8 DPC 104

9 End Point 104

10 FCP 104

11 Joined Node 104

12 Left Node 104

13 List Structure 105

14 Map structure 105

15 Member Node 105

16 SSMP 105

17 Multicast 105

18 Multicast Tree 105

19 Node 105

20 Overlay Link 105

21 Peer Node 105

22 Protocol Message 105

23 Rendezvous Point (RP) 105

24 Source Node 105

25 MSMP 105

26 VCA 106

so với kiểu hội nghi truyền thống

Với xu thế này, hướng đề tài sẽ đi vào việc nghiên cứu một giải thuật phân bố dữ liệu trên internet đặc thù cho các ứng dụng video conference

Có ba hướng chính trong việc xây dựng các ứng dụng video conference Hướng thứ nhất dựa trên nền IP multicast, một thành phần trong cơ sở hạ tầng TCP/IP Hướng tiếp cận có ưu điểm là đã có sẳn một multicast protocol và protocol này chạy rất hiệu quả, ít chiếm băng thông (trong mạng LAN, router chỉ cần gửi một gói dữ liệu là đủ để thực hiện lệnh multicast đến một nhóm các computer trong mạng) Nhưng nó lại có một số hạn chế như sau: 1) IP multicast cần sự hỗ trợ từ phía hệ điều hành (OS), nhưng hiện nay phần lớn OS đều hỗ trợ chức năng này 2) Cần sự hỗ trợ cho IP multicast procol ở các router Thông thường, hiện nay các router đều có hỗ trợ IP multicast, nhưng tính năng này đôi khi bị các nhà quản trị mạng tắt đi vì một hay nhiều lý do nào đó 3) IP multicast có không gian địa chỉ nhỏ 27 bit Vấn

đề này được giải quyết với IPv6 4) vấn đề bảng routing kích thước lớn ở mỗi router tham gia vào quá trình multicast Mỗi router phải duy trì bảng routing cho mỗi nhóm IP multicast Hướng tiếp cận thứ hai là Application Layer Multicast (ALM), một hướng không phụ thuộc sự hỗ trợ multicast của cơ sở hạ tầng mạng và không cần sự hỗ trợ về mặt cấu hình từ các nhà quản trị mạng Hướng này sử dụng unicast để thực hiện việc multicast dữ liệu, cho nên nó không hiệu quả về mặt băng thông so với IP multicast Hướng thứ ba là kết hợp giữa IP multicast và ALM Xem các IP multicast-enabled island như là một host đơn và

sử dụng ALM cho các host này

Các Video conference Application (VCA) thường là các nhóm multicast có kích thước nhỏ nên việc sử dụng IP multicast không được hiệu quả lắm vì vấn đề quản lý quá nhiều nhóm multicast nhỏ ở các router Giải pháp ALM là một lựa chọn khác cho VCA ALM sử dụng vài member trong nhóm multicast như là các router, thay thế chức năng của các network router Các giải pháp ALM không phụ vào sự hỗ trợ của các network router, giúp VCA để triển khai hơn

Để ALM là một lựa chọn thay thế đủ tốt cho IP multicast đối với các nhóm nhỏ có nhiều source node (node phát data) thì một ALM protocol cần phải có một cơ chế tận dụng tốt những node có bandwidth lớn

và sử dụng các node này như là các router node cho nhóm multicast Nhiệm vụ của các router node này là nhận data message từ một source node và forward data message này đến các node khác Số lượng các node được forward bởi một router node tùy thuộc vào lượng bandwidth dư thừa của chính router node đó

Như vậy mục tiêu của đề tài này là xây dựng một ALM protocol cho VCA với các đặc tính sau:

- Có nhiều source node

- Số source node có thể nhỏ hơn tổng số node

- Các source node có cùng data rate (tốc độ phát data)

- Yêu cầu về delay của data message không được xem xét

- Phục vụ cho nhóm multicast có link vật lý có bandwidth khả dụng bất đối xứng hoặc có link đối xứng và số source node nhỏ hơn tổng số node trong nhóm multicast

- Tìm một multicast tree cho mỗi source node sao cho đáp ứng được yêu cầu về data rate mà không gây nghẽn Không cố gắng tìm lời giải tốt nhất

- Khả năng thích ứng với điều kiện thay đổi động của network Tự động thay đổi các multicast tree

để thích ứng với điều kiện network mới

- Thời gian hội tụ về lời giải khả dụng đủ nhanh

- Phục vụ cho nhóm multicast có kích thước nhỏ

- Dựa trên nền TCP/IP

Như vậy bài toán mà đề tài này đặt ra như sau:

- Input: cho trước một nhóm multicast có m member node và n source node (node phát) có data rate

D r kbps , n ≤ m Network Topology và bandwidth đường truyền giữa các member node không

được biết trước

- Output: bảng routing tại mỗi member node Tổng hợp các bảng routing này lại sẽ có được multicast tree cho mỗi source node

Chỉ đề cập đến các giải pháp không phụ thuộc nhà cung cấp hạ tầng network IP Multicast and Satellite Multicast là các giải pháp phụ thuộc nhà cung cấp hạ tầng network

2.1 Server-Based Solution

Có một server đóng vai trò như một router (server này được gọi là reflector), nhận data message từ member node và forward message này đến các member node khác Có thể có nhiều reflector phối hợp cùng nhau và mỗi member node (participant) chỉ kết nối đến một reflector

Giải pháp này sử dụng bandwidth tại mỗi member node ở mức tối thiểu, nhưng sử dụng rất nhiều

bandwidth tại mỗi reflector

Reflector Participant

2.2 Complete-Graph-Based Solution

Xem mỗi kết nối giữa hai member node là một cạnh, thì graph được hình thành từ tập các node của nhóm multicast là một complete graph Đây là giải pháp đơn giản nhất và chỉ phù hợp với nhóm multicast có số source node bằng số member node và các link vật lý của mỗi node có bandwidth khả dụng đối xứng hoặc vấn đề tối ưu bandwidth là không quan trọng

Hình 1.2

2.3 Tree/Mesh Multicast Solution

Các multicast protocol như Narada, Nice, ALMI, HMTP đều có thể sử dụng cho VCA Trong đó Narada tập trung cho việc tối ưu latency cho data message, nhưng chưa tập trung cho việc tối ưu bandwidth, xử lý hiện tượng multicast mesh không đáp ứng được data rate yêu cầu Các protocol còn lại dựa chủ yếu vào một cấu trúc cây dùng chung để multicast, cách làm này không thực sự hiệu quả cho multicast với nhiều source node và gây ra delay lớn khi source node ở vị trí node lá Và vấn đề tối ưu bandwidth cũng như Narada, chưa giải quyết tốt

Các node trong nhóm multicast được tổ chức thành một mesh Mỗi source node sử dụng một multicast tree riêng biệt để multicast data message đến các node còn lại trong nhóm multicast Mỗi cạnh của multicast tree là một cạnh của cấu trúc mesh

Hình 1.3, 1.4, 1.5, 1.6 trình bày cấu trúc mesh và các multicast tree của một nhóm multicast gồm 4 node

và các node này đều là source node

Quá trình hình thành multicast tree cho mỗi source node gồm hai giai đoạn:

- Broadcast trên mesh (BOM) để xây dựng các multicast tree ban đầu Các multicast tree này chưa

là các multicast tree cuối cùng

- Dùng cơ chế phát hiện, xử lý nghẽn (DPC) để chỉnh sửa dần các multicast tree ban đầu Quá trình chỉnh sửa này sẽ dừng lại khi các multicast tree thỏa mãn yêu cầu của bài toán

BOM được chạy đầu tiên để tạo ra các multicast tree khởi đầu cho các source node Sau đó các source node bắt đầu phát data DPC giám sát quá trình lan truyền data message trên mỗi multicast tree Khi có hiện tượng nghẽn tại một member node nào đó, DPC tiến hành xử lý, chọn một multicast tree và thay đổi cấu trúc của nó dựa trên các thông tin routing đã thu thập được bởi BOM Quá trình xử lý của DPC có tinh chất lặp đi, lặp lại đến khi nào hết nghẽn thì dừng lại Khi DPC nhận thấy rằng thông tin routing được thu thập bởi BOM ở lần chạy trước chưa đủ để protocol hội tụ, nó kích hoạt BOM chạy lại để thu thập lại thông tin routing mới đầy đủ hơn

BOM hoạt động theo cơ chế sau: source node gửi broadcast message đến các neighbor, các neighbor của source node đến lượt mình forward broadcast message vừa nhận được đến các neighbor của nó ngoại trừ neighbor mà nó vừa nhận broadcast message Quá trình này cứ thế diễn ra cho đến khi tất cả các node đều

đã nhận được broadcast message mỗi node trên mesh lưu thông tin về các neighbor mà nó nhận hoặc gửi broadcast message Hình 1.7 trình bày cơ chế hoạt động này Node 0 là node phát data Các cạnh màu đỏ chỉ multicast tree kết quả Các mũi tên màu đỏ chỉ hướng các broadcast message được gửi bởi node đang xét

Bandwidth (BW) Description X/Y : Recv BW = X units, Send BW = Y units

Converge Time

Hình 1.8 trình bày bảng kết quả thử nghiệm với các nhóm multicast (network topology như trong hình 1.9) có từ 4 đến 10 member và tất cả các member đều là source node Tốc độ phát data của tất các member

node như nhau và có giá trị là 1 unit

multicast mới như protocol này

Nice quản lý các member theo cơ chế phân cấp, gom các member nằm ở gần nhau vào trong một cluster,

mỗi cluster có số lượng các member nằm trong khoảng từ k đến 3*k – 1 Các cluster được phân nhóm theo

layer Member đóng vai trò là root của hệ phân cấp này nằm ở layer cao nhất và layer này chỉ có một member Tất các member thuộc nhóm multicast (mỗi nhóm multicast có một cây phân cấp) đều nằm ở layer thấp nhất, layer 0 Mỗi cluster có một member được chọn làm leader, member này phải nằm ở vị trí trung tâm của cluster Việc chọn leader ở vị trí trung tâm nhằm mục đích tối ưu hoạt động quản lý và gửi data đến các member của cluster

Tập hợp các leader của layer i hình thành nên layer i+1, các member (leader) ở layer i+1 được phân nhóm thành các cluster của layer i+1 Như vậy một member ở layer i thì nó cũng nằm ở layer j và làm leader của một cluster mà nó thuộc về trong layer j này với 0≤ j<i

Một member có thể thuộc về nhiều cluster khác nhau Nhưng ở một layer, thì một member chỉ có thể thuộc về một cluster

Nice quản lý các member theo cơ chế phân bố Leader chịu trách nhiệm quản lý các member trong cluster của nó Mỗi member chỉ kết nối trực tiếp đến các member khác trong cùng cluster mà member thuộc về

Các member trong một cluster định kỳ gửi thông điệp HeartBeat cho nhau nhằm mục đích xác định sự tồn tại của member trong cluster và tinh chế cây phân cấp Nếu member gửi HeartBeat là leader thì nội dung của thông điệp HeartBeat chứa danh sách các member của cluster Nếu member gửi HeartBeat không là

leader, thì nội dung của thông điệp chỉ là khoảng cách được ước tính giữa member gửi và member nhận Leader cũng định kỳ gửi danh sách các member của cluster thuộc layer trên (layer cao hơn layer hiện thời

1 bậc) mà leader thuộc về, nhằm mục đích để các member của leader join cluster khác cùng layer (tinh chế cây phân cấp)

Một ví dụ của cây phân cấp

Cluster Leader is member

of the cluster that it plays roles as leader.

Lmax: index of the top most

+member

* 0 * contains >>

{index>0 and index in indexes}

Cluster index

Mỗi member I định kỳ duyệt danh sách các member của cluster thuộc layer trên mà leader của I thuộc về,

và tìm member J gần nó nhất Nếu J khác leader của I thì I rời cluster hiện thời và join vào cluster của J (J làm leader của cluster mới này)

Khi một host Y muốn join vào một nhóm multicast, nó đầu tiên contact đến một host khác được biết trước gọi là Rendezvous Point (RP) và RP trả về địa chỉ của member X là root của cây phân cấp của nhóm multicast Mục tiêu của Y là join vào cluster gần nó nhất thuộc layer 0 của cây phân cấp Hình vẽ bên dưới

sẽ minh họa chi tiết quá trình join một layer Trong ngữ cảnh hiện tại thì join layer 0

Khi một member muốn rời khỏi nhóm multicast, nó gửi thông điệp Remove đến tất cả các cluster mà nó

chúng) của nó ngoại trừ các peer thuộc cùng cluster với peer gửi dữ liệu đến nó

- Li: index of target layer i needed to join to.

- Lmax : index of the topmost layer.

- CL(i,X): a cluster at layer i and X is also a member of this cluster.

query RP for the host X in the topmost layer (the root host of the tree)

query host X for the collection Z of its peers at layer i-1 (members of CL(i-1,X) in which X is a leader)

join CL(i,X) [ i=Li ]

i:=Lmax

find a closest member Y

to X in the collection Z i:=i-1

[ i=Li ]

X:=Y

Các bước của quá trình join một layer

2 ví dụ của cơ chế multicast

Trong 2 hình trên, hình bên trái member phát dữ liệu là A7 và hình bên phải member phát dữ liệu là C0 A i thuộc về layer 0, B i thuộc về layer 1 và 0, C0 thuộc về layer 2, 1, 0 và là leader của chính nó và các B i

Tóm lại, Nice có thể được dùng cho các ứng dụng với nhiều member phát dữ liệu Trong trường hợp xấu nhất (member phát dữ liệu và member nhận dữ liệu nằm ở 2 bên rìa của cây phân cấp), latency gấp đôi trường hợp tối ưu (member phát dữ liệu nằm ở root) Tuy nhiên Nice không phù hợp cho các ứng dụng có ràng buộc chặt về latency như video conference Hơn nữa Nice không có cơ chế tận dụng các đường truyền có băng thông lớn của member để nâng cao tốc độ multicast chung của cả nhóm multicast Nice có một điểm yếu trong việc kháng lỗi, khi một member chết đột ngột thì cây phân cấp sẽ bị phân hoạch và tất các member mà member nay làm leader sẽ không nhận được dữ liệu gửi tới chúng thông qua leader này

Và có một hạn chế nữa về mặt băng thông là member đóng vai trò là root phải làm leader của n cluster (n

là chỉ số của layer cao nhất), điều này có nghĩa là root trong trường hợp xấu nhất nó phải gửi dữ liệu đến

tất cả các member của n cluster, điều này sẽ hạn chế băng thông chung của cả nhóm multicast rất nhiều

1.2 Narada

Narada [2] là một protocol được thiết kế tập trung cho các ứng dụng multicast có số lượng các member nhỏ và trung bình, khoảng vài trăm member trở lại Narada tập trung tối ưu giá trị latency của quá trình multicast dữ liệu với nhiều node phát (multi-source), vì vậy Narada đặc biệt phù hợp cho các ứng dụng có đòi hỏi ràng buộc chặt về latency như video conference, multi-party network game

Narada sử dụng các member để xây dựng nên một mesh vừa dùng cho chức năng quản lý các member vừa dùng cho việc truyền dữ liệu Việc truyền dữ liệu từ node source (node phát dữ liệu) đến các node khác theo một path dạng tree, có gốc tại node source, và tree này cũng được gọi là reverse shortest path spanning tree Mỗi member lưu danh sách của tất cả các member khác trong nhóm multicast Narada định

kỳ chạy giải thuật distance vector trên mesh để xây dựng nên các reverse shortest path spanning tree cho

mỗi node phát Và các tree này được thể hiện ở bảng routing của mỗi node

Narada dùng mesh để lan truyền thông tin membership Mỗi member định kỳ trao đổi với các neighbour

thông tin mà nó biết về danh sách các member của nhóm multicast (dùng thông điệp refresh) Và đây

cũng là cách Narada dùng để detect xem một member trong mesh có alive hay không Nếu một node Y không nhận thông điệp refresh từ neighbour X của nó sau một khoảng T thì X sẽ đưa Y vào hàng một hàng đợi Q của nó, và sau đó nó sẽ chạy một giải thuật để detect có hay không Y thực sự chết, nếu Y không chết thì tạo một kết nối mới đến Y thay cho kết nối cũ bị đứt Và đây cũng là cách mà Narada dùng để repair

mesh Hình vẽ bên dưới sẽ trình bày chi tiết giải thuật repair mesh này

Narada cũng có cơ chế tinh chế mesh nhằm đáp ứng tình trạng thay đổi động của network và đưa cấu trúc mesh từng bước hội tụ về trạng thái tối ưu Narada thực hiện việc tinh chế mesh bằng cách thêm vào mesh các link mới có tác dụng giảm latency của mesh và loại bỏ khỏi mesh các link ít được sử trong việc truyền

for each member m (m not i) begin

CL = current latency between i and m along mesh

NL = new latency between i and m along mesh if edge i - j

were added

if (NL < CL)

utility + = (CL-NL)/CL end

return utility

}

- i: current member.

- Let Q be a queue of members for which i has stopped receiving sequence number updates for at least Tm

time

- Let T be maximum time an entry may remain in Q.

- Member runs this periodically and probabilistically deletes a member from the head of the queue The

deleted member is probed and it is either determined to be dead, or a link is added to it The scheduling

prob = Length(Q)/ GroupSize

[ k is dead ]

k:=

Dequeue(Q) [ this run matches prob ]

add a link to k

Giải thuật repair mesh

Cũng vậy, mỗi node i định kỳ duyệt các neighbour u của nó và đánh giá mức độ hữu dụng của link giữa i

và u cho mục đích truyền dữ liệu Sau đó node i sẽ chọn một neighbour j có giá trị hữu dụng thấp nhất Nếu giá trị hữu dụng của j nhỏ hơn một ngưỡng cho trước thì link giữa i và j sẽ bị loại bỏ Dưới đây là

trình bày chi tiết hàm đánh giá mức độ hữu dụng của link

EvaluateConsensusCost(j)

{

/* i : current member */

Costij = number of members for which i uses j as next hop for forwarding packets.

Costji = number of members for which j uses i as next hop for forwarding packets

return max(Costij , Costji)

group

sequence number updates from for at leas t Tm time.

Member

refres h() EvaluateUtility() EvaluateConsensusCost()

<<host>>

Routing Entry

target : addre ss next h op : addre ss cost

Queue 1

0 *

routing t able

Mô hình tổ chức mesh của Narada

Khi một host X muốn join vào nhóm multicast, X đầu tiên contact với một host được biết trước (Rendezvous Point) cho danh sách các member của nhóm Rồi X lấy ngẫu nhiên vài member từ danh sách

đó và gửi request yêu cầu trở thành neigbour đến chúng Sau khi join thành công, X bắt trao đổi thông điệp refresh với các neighbour của nó

Khi một member muốn rời nhóm multicast, nó gửi thông điệp leave đến tất cả các neighbour của nó, và

sau đó sự kiện này sẽ lan truyền trên mesh đến tất cả các member khác

Về vấn multicast dữ liệu trên mesh, khi một node X nhận được một gói dữ liệu từ một node Z , X duyệt bảng routing của các neighbour của nó và forward gói dữ liệu này đến các neighbour Y sử dụng X như là next hop trong đường dẫn ngắn nhất từ chúng (Y) đến node phát của gói dữ liệu này (source node)

Tóm lại, Narada là một protocol rất phù hợp cho mục tiêu của chúng ta về ứng dụng video conference Và Narada có tính kháng lỗi rất tốt Khi một node bị chết đột ngột, thì mesh vẫn có nhiều khả năng không bị phân hoạch Tuy nhiên protocol này có một số điểm chưa tối ưu như sau:

Hiện thời protocol chỉ sử dụng latency như là thước đo để cost của một link Nhưng thực tế trong ứng dụng video conference thì yếu tố băng thông của link đóng góp một vai trò rất quan trọng bên cạnh latency trong việc định cost của link khi thêm link mới hoặc routing các gói dữ liệu

Cơ chế xây dựng mesh khởi đầu và tinh chế mesh chưa đạt được sự tối ưu cao

Khi xây dựng một cây multicast cho mỗi node phát, Narada không để ý đến cost phát sinh trên một link

Các link thuộc về cùng một node có thể share cùng một đường truyền vật lý, như vậy băng thông của các link đó phụ thuộc lẫn nhau

1.3 PRISM

PRISM [3] là một kiến trúc hướng đến các ứng dụng streaming dữ liệu với chất lượng cao trên nền IP như xem truyền hình trực tuyến, video on demand Do tập trung vào loại ứng dụng này, nên PRISM cần một cơ sơ hạ tầng network rất mạnh với các server và đường truyền tốc độ cao giữa các server Có hai loại server: 1) Live Source: đóng vai trò như là một nguồn phát dữ liệu, một streaming server; 2) Portal: đóng vai trò như là một edge server, cache và phân phối dữ liệu đến các client Các ứng dụng trên máy client phải kết nối đến một portal server này mới có thể hoạt động được

PRISM Data Plane

Tóm lại với kiến trúc này, hoàn toàn không thể áp dụng cho ứng dụng video conference của chúng ta

1.4 Yoid

Yoid [4] là một kiến trúc multicast mục đích chung, hướng tới hỗ trợ nhiều loại ứng dụng khác nhau Yoid không đứng tách rời IP multicast, mà tận dụng nó bất cứ nơi nào có thể Ở những nơi mà IP multicast hoạt động được thì Yoid thiết lập một nhóm IP multi cast ở đó và xem nhóm này như là một phần tử đơn trong hoạt động quản lý member Yoid hỗ trợ cả hai kiến trúc host-based (tất cả các member trong nhóm multicast đều là endhost) và servered-based (vài member trong nhóm multicast là server) Yoid hỗ trợ multicast across space và across time (như ứng dụng email, không ràng buộc thời điểm nhận), trong đó IP multicast chỉ hỗ trợ across space

Với mỗi nhóm multicast Yoid sử dụng hai cấu trúc tree và mesh để truyền dữ liệu và quản lý các member tương ứng Mesh có thể được sử dụng để truyền dữ liệu trong những hợp đặc biệt như khi cấu trúc tree bị phân hoạch do một member trong tree bị chết đột ngột

Mỗi nhóm multicast có một hay nhiều rendezvous host, host này đứng bên ngoài cấu trúc tree và mesh của nhóm Các host này đóng vai trò là điểm nhập, nơi mà các host muốn gia nhập nhóm multicast phải contact đầu tiên Và địa chỉ của các rendezvous host này được biết trước bởi các host muốn gia nhập nhóm Các rendezvous host chứa danh sách của vài hoặc tất các member trong nhóm multicast

Cấu trúc tree là một cây n-phân, trong đó n là giá trị được chọn trước Các node trung gian gọi là transit

member (node nhận và chuyển dữ liệu đến các neighbour khác hoặc là node phát dữ liệu), các node lá gọi

là leaf member (node chỉ nhận dữ liệu hoặc là một node phát dữ liệu) Trong trường hợp có nhóm IP multicast (cluster) thì một thành viên trong nhóm được bầu làm head đóng vai trò đại diện cho cả nhóm Các thành viên còn lại của nhóm được gọi là feet Các feet gửi và nhận dữ liệu đều thông qua head của nhóm Hình vẽ dưới đây sẽ minh họa một cấu trúc cây của Yoid Đường link giữa hai node cha - con có một mũi tên hướng từ node con đến node cha chỉ để thể hiện quan hệ cha - con

Yoid Tree Và Các Thuật Ngữ

Các member cố gắng tìm các neighbour (node cha và các node anh em) càng gần chúng càng tốt và dùng latency làm thước đo mức độ gần nhau giữa các member Các member có thể giới hạn bản thân chúng chỉ làm node lá thôi Một member có thể là một endhost hoặc yoid server Thông thường yoid server là một transit member và được cài đặt trong cơ sở hạ tầng mạng với các mục đích tường minh

Trong cấu trúc mesh, mỗi node X chỉ duy trì một danh sách của các mesh neighbour của nó và mỗi mesh neighbour này không là một tree neighbour của X trong cấu trúc tree nhằm mục đích tránh sự phân hoạch đồng thời ở hai cấu trúc khi có node bị chết đột ngột Mỗi mesh neighbour của X là một node Y đó không

có mesh link nào nối trực tiếp từ Y đến X Mỗi node có 3 hoặc 4 mesh neighbour Các mesh neighbour của

mỗi node được chọn một cách ngẫu nhiên theo cơ chế yoid mesh anycast (một thông điệp được truyền trong mesh một cách ngẫu nhiên và ngẫu nhiên dừng lại ở một node)

Khi một host muốn join vào nhóm multicast, nó đầu tiên kiểm tra xem có thể join vào một nhóm IP multicast cục bộ (cluster), động tác này có thể không cần contact với rendezvous server Nếu không có cluster nào để join vào, nó sẽ bắt đầu quá trình tìm một parent còn đủ khả năng để nhận nó làm con và parent này là node gần nó nhất mà nó biết được

Khi một member muốn rời nhóm multicast, nó đầu tiên gửi một thông điệp đến rendezvous server để thông báo việc rời nhóm và cảnh báo các children của nó về sự kiện này

Yoid cũng thực hiện việc tinh chế cấu trúc tree theo định kỳ Mỗi member I định kỳ chọn ra một member

X trong danh sách các member tiềm năng sao cho X gần nó nhất Nếu X gần I hơn parent J của I thì I sẽ rời J mang theo các con cháu đến node X và nhận X làm parent mới

Các member trong danh sách các member tiềm năng của mỗi node I không được là con cháu của I Mỗi member I có được danh sách các member tiềm năng (stand-by member hay là các member còn có đủ chỗ

để nhận member khác làm con) bằng cách : 1) từ rendezvous server khi join nhóm multicast; 2) từ thông

tin trong các thông điệp điều khiển khác nhau như root path của các member khác, intent to join path; 3)

được dùng khi danh sách không có đủ số stand-by member cần thiết (có thể một số member trong danh

sach đã không còn là stand-by member) Member I duyệt con cháu của các member trong danh sách này

để tìm các stand-by member cần thiết; 4) dùng yoid tree-any cast Gửi thông điệp member discovery đến

node cha Khi danh sách đầy thì các entry cũ nhất sẽ bi loại bỏ

Khi một member X tìm được một parent gần nó nhất, nó bắt đầu gia nhập với parent mới (đem theo cả con cháu) và gửi thông điệp root path (tập hợp các member trong path từ X đến root) đến các con cháu của nó

Nếu một member nhận root path từ cha của nó và root path này cũng chứa chính bản thân nó, thì member bắt đầu quá trình chọn một parent khác vì đã có một chu trình (loop) trong cấu trúc tree chứa member và node gửi thông điệp root path này Yoid có cơ chế phát hiện ra loop có thể xảy trước khi join với một parent Tuy nhiên, khi loop vẫn có thể xảy ra khi có những thay đổi đồng thời về parent

Loop được hình thành bởi hai thay đổi đồng thời

Loop được hình thành bởi ba thay đổi không tương thích

Khi một node trong cấu trúc tree bị chết đột ngột, cấu trúc tree này sẽ bị phân hoạch Yoid xử lý hiện

tượng này bằng cách dùng cơ chế như sau: root của mỗi phân hoạch broastcast thông điệp “I am the root” trên mesh và định kỳ thông báo rendezvous server về sự kiện nó là root Khi một root nhận thông điệp “I

am the root” của một node khác, nó đưa node này vào danh sách các member tiềm năng và sau đó bắt đầu quá tìm parent Và kết quả sau cùng sẽ chỉ còn một root và cấu trúc tree được liên thông trở lại

Về vấn đề truyền dữ liệu trên cấu trúc tree, node phát dữ có thể ở vị trí bất kỳ trong tree Khi một node nhận được một gói dữ liệu, nó sẽ chuyển gói dữ liệu này đến tất cả các neighbour khác ngoại trừ member gửi dữ liệu đến nó

Tóm lại, kiến trúc Yoid chỉ phục vụ cho mục đích chung, nên không phù hợp cho các ứng dụng đòi hỏi ràng buộc chặt về latency như video conference của chúng ta Nhưng những ý tưởng của nó sẽ giúp chúng

ta nhiều trong việc cải tiến giải thuật được chọn sắp tới của chúng ta

1.5 ALMI

ALMI [5] là một protocol được thiết kế tập trung cho các ứng dụng multi-source(nhiều node phát) có số lượng member nhỏ Sử dụng tiếp cận tập trung để quản lý các member Mục tiêu của ALMI là để thay thế cho sự không hiệu quả của IP multicast cho những nhóm tương đối nhỏ Và sử dụng ALMI sẽ hiệu quả hơn

ALMI sử dụng hai cấu trúc MST tree (minimum spanning tree) và monitoring graph để truyền dữ liệu và giám sát các member tương ứng

ALMI sử dụng một session controller đóng vai trò như là một rendezvous server Mỗi nhóm multicast có một sesstion riêng trong session contoller Session controller quản lý tất cả các member và các thao tác trên MST Tree (thêm/xóa node, xây dựng cây) Thông điệp điều khiển thì unicast giữa member và session

controller Sau khi có sự thay đổi trong các neighbour của node X, session controller gửi danh sách các children và parent của X đến X Các children giám sát parent của chúng để xác định tính aliveness của

parent

Trong cấu trúc monitoring graph, mỗi node (member) nhận danh sách các neighbour của mình từ session controller và thực hiện việc giám sát (đo delay) các neighbour đó theo định kỳ Session controller dùng kết quả giám sát này để tính ra MST Tree Session controller không tham gia vào quá trình truyền dữ liệu trên MST Tree

Khi một host muốm join vào nhóm multicast, nó đầu tiên contact session controller và session controller trả về danh sách các anh chị em (host chấp nhận kết nối từ) của nó và parent (host khởi tạo kết nối đến)

Khi một member muốn rời nhóm multicast, nó sẽ thông báo sự kiện này đến session controller và các tree neighbour của nó Và các children của nó khi nhận được thông điệp này, chúng sẽ contact session controller để rejoin lại nhóm multicast

Khi kết nối giữa child I và parent của nó bị đứt, I sẽ gửi thông điệp rejoin đến session controller Nếu parent J phát hiện kết nối từ child X đến nó bị dứt, nó chỉ đơn giản close kết nối đó

Cơ chế truyền dữ liệu multicast trên MST Tree tương tự như của yoid tree Nhưng có điểm khác biệt ở

chỗ, mỗi node X duy trì một cache của các tree version gần đây nhất (danh sách các neighbour của mỗi version) Khi một gói dữ liệu đến, X sẽ chuyển gói dữ liệu này theo tree có version khớp với version của

gói dữ liệu Nếu không có entry nào trong cache khớp với gói dữ liệu và version của gói dữ liệu nhỏ hơn

version mới nhất của tree thì gói dữ liệu này sẽ bị hủy, ngược lại X sẽ rejoin lại nhóm multicast để lấy

version mới nhất của tree

Tóm lại, cấu trúc tree mà ALMI sử dụng không thực sự tối ưu cho multi-source (chỉ tối ưu cho source) và có nhược điểm tạo ra lổ hổng latency khi có một link trong cấu trúc cây bị đứt và MST Tree thì không đảm bảo đường đi từ một node trong tree đến source-node là ngắn nhất Nói chung ALMI chỉ phù hợp cho các ứng dụng có số lượng member khá nhỏ và không yêu cầu tối ưu về mặt latency và băng thông

single-để đạt tốc độ multicast chung cao nhất

1.6 Host Multicast Tree Protocol

Host Multicast Tree Protolcol (HMTP) [6] được thiết kế để cung cấp một phương tiện multicast không phụ thuộc vào sự có sẳn của IP multicast, nhưng nó sẽ tận dụng IP multicast khi có thể (tận dụng các IP multicast-enabled island) Che dấu sự không sẳn có của IP multicast (hỗ trợ IP multicast service model) HMTP giả sử rằng tất cả các member tham gia vào nhóm multicast đều hỗ trợ IP multicast Trong phạm vi một island, naive IP multicast được sử dụng để gửi và nhận dữ liệu

Cấu trúc tree của HMTP là một cây n-phân, có một node đặc biệt được gán làm root của cây Mỗi node trong cây là một designed member (DM) DM là một member đóng vai trò như là leader của island (nhóm IP multicast), và thay mặt nhóm để gửi/nhận dữ liệu ra/từ bên ngoài Các node con cố gắng tìm node gần nó nhất làm node cha

Kiến trúc Host-Multicast

Tương tự như các protocol khác, HMTP cũng có một host multicast rendezvous point (HMRP) đóng vai trò như là điểm nhập để các host tham gia vào nhóm multicast HMRP không tham gia vào quá trình truyền dữ liệu multicast

Khi một host X muốn tham gia vào nhóm multicast, nó đầu tiên kiểm tra xem nó có thể join vào một

nhóm local IP multicast hay không Nếu có thì join vào nhóm IP multicast này, còn không thì join vào cây multicast Để join vào cây multicast nó đầu tiên truy vấn HMRP cho root của cây multicast và xem root

này như là một parent tiềm năng đầu tiên Bắt đầu từ một parent tiềm năng I, X tìm một node J trong danh sách các neighbour của I sao cho J gần X nhất Nếu J khác I thì đưa J vào danh sách các parent tiềm năng của X và lặp lại quá trình trên với parent tiềm năng bắt đầu là J cho đến một node lá thì dừng lại và chọn node làm parent của X Còn ngược lại chọn J làm parent cho X

Khi một member X muốn rời nhóm multicast, nó cảnh báo sự kiện này đến tất cả các tree neighbour của

nó Khi node cha nhận được thông điệp này, nó loại X ra khỏi danh sách các children của nó Khi node

con nhận được thông điệp này, nó bắt đầu quá trình tìm cha mới Quá trình tìm cha này bắt đầu tại node

cha của X theo root path của X đến root Các node trong root path này đóng vai trò như là các parent tiềm

năng của các node con

HMTP cũng có cơ chế tinh chế cấu trúc cây theo định kỳ Mỗi node X định kỳ bắt đầu quá trình tìm một parent mới Y, nếu Y gần hơn parent của X thì X sẽ chọn Y làm parent mới và cập nhật lại root path của các node con bằng cách gửi thông điệp path đến chúng Quá trình tìm parent mới này bắt đầu tại một node được lấy ngẫu trong root path (được xem như là các parent tiềm năng của X) của X, và việc chọn node gần

X nhất trong danh sách các neighbour của parent tiềm năng hiện thời có thể được điều chỉnh một chút để

chọn node không là gần X nhất nhằm mục đích chuyển hướng search để tìm parent tốt hơn

Mỗi node con định kỳ gửi thông điệp refresh đến node cha, và node cha đáp lại bằng thông điệp path (chứa các node trong path từ root đến node cha) Node con dùng thông điệp path này để kiêm tra nó có

nằm trong một loop hay không, nếu nó nằm trong root path của node cha thì nó nằm trong một loop và nó

sẽ ngừng việc gửi root path của nó đến các node con của nó, rời parent hiện tại và rejoin nhóm multicast

Root gửi thông điệp refresh đến HMRP để HMRP luôn biết node nào là root hiện thời của cấu trúc cây

Khi cấu trúc cây bị phân hoạch, thì nó được sửa chữa tương tự như khi có một member rời nhóm Chỉ khác ở chỗ các neighbour của node bị chết phải tự phát hiện ra điều này thông qua việc sử dụng các thông

điệp refresh, path

Cơ chế truyền dữ liệu multicast tương tự như của yoid tree

Giải thuật join nhóm multicast

Giải thuật sửa chữa cây bị phân hoạch

Tóm lại, HMTP dùng cấu trúc tree để multicast dữ liệu nên cũng nhưng vấn đề về không tối ưu latency cho multi-source, lổ hổng latency khi bị phân hoạch, cấu trúc tree dễ bị phân hoạch và không tối ưu băng thông để đạt tốc độ multicast chung cao nhất

2 Kết Luận

Nice tập trung ở các ứng dụng có số lượng lớn các member sử dụng ít bandwidth và chỉ tập trung ở khía

cạnh tối ưu chi phí quản lý các member Nice chưa giải quyết vấn đề tối ưu bandwidth

Narada tập trung ở các ứng dụng có số lượng các member nhỏ và trung bình, chỉ tập trung ở khía cạnh tối

ưu giá trị latency của message cho nhóm multicast có nhiều node phát Narada cũng chưa giải quyết vấn

đề tối ưu bandwidth

Yoid hướng đến một kiến trúc dùng chung cho nhiều loại ứng dụng khác nhau, tận dụng IP Multicast bất

cứ nơi nào có thể Yoid cũng chưa giải quyết vấn đề tối ưu bandwidth

ALMI tập trung cho các ứng dụng multicast có nhiều node phát, nhưng chỉ tối ưu cho single-source nên

cũng chưa giải quyết triệt để vấn đề tối ưu bandwidth

Host Multicast Tree hỗ trợ IP multicast service model, tận dụng IP Multicasr bất cứ khi nào có thể (sử

dụng các IP multicast-enabled island (IMEI)) Do dùng shared-tree để phân bố dữ liệu đến các IMEI nên vấn đề tối ưu bandwidth cũng chưa được giải quyết

Xét vấn đề multicast của video conference với n member node và m source node Gọi r là data rate được

yêu cầu của nhóm Với vấn đề này, yêu cầu tối thiểu về bandwidth của link theo chỉều down (từ network

về member node) của mỗi member để bài toán có nghiệm là:

m*r + {bandwidth được sử dụng để truyền các control message của protocol}

Với multicast khi bỏ qua các control message chúng ta có đẳng thức như sau:

Gọi x i : Tổng bandwidth được dùng để gửi data ra network tại một node i

yi : Tổng bandwidth được dùng để nhận data từ network tại một node i

Ta có: ∑ xi= ∑ yi với i nhận giá trị từ 1 đến n (3.1)

Nếu m = n và các link vật lý đối xứng (chỉều up và down có cùng giá trị bandwidth khả dụng) thì lúc này chỉều đi của mỗi member node cũng đều là m*r Trong trường hợp này, lời giải của bài toán cực kỳ đơn

giản và nó là một complete graph

Như vậy với vấn đề multicast này chỉ là một vấn đề lớn khi các link vật lý không đối xứng về mặt

bandwidth khả dụng hoặc n > m Lúc này vấn đề được đặt ra là giải quyết bài toán xây dựng các multicast

tree cho các source node sao cho tận dụng bandwidth dư thừa ở một số member node đề bù lại sự thiếu hụt bandwidth tại một số member node khác

Node 0 Node 2 Node 3 Node 4

Address Neighbors Address Neighbors Address Neighbors Address Neighbors

Trong hình 3.13, cột Address chỉ source address, cột Neighbors liệt kê danh sách các địa chỉ network của

các neighbor (các children node) sẽ được forward đến khi node hiện tại nhận được message có source

address trùng với giá trị của cột Address

2.2.2 Routing Version

Để tránh mất data khi apply thông tin routing mới lên mesh, protocol sử dụng cơ chế đánh dấu version cho mỗi thông tin routing và mỗi data message được đính kèm routing version mà nó sẽ được áp dụng tại mỗi node trên mesh để chọn ra thông tin routing và dùng nó để forward data message vừa nhận được đến các neighbor Mỗi node chỉ lưu hai thông tin routing của hai version khác nhau cho mỗi source address Một routing version cũ đang dùng và một routing version sắp sửa được sử dụng

Khi source node hoàn tất quá trình tìm thông tin routing mới cho data message được gửi từ nó đến tất cả các node còn lại trên mesh, nó multicast một data message mới dựa vào multicast tree vửa mới có được đến tất cả các node còn lại trên mesh Data message này được đính kèm giá trị version của thông tin routing mới này và một flag đánh dấu đây là message bắt đầu việc sử dụng thông tin routing này Khi một node trên mesh nhận data message này nó sẽ xóa các routing version cũ và chỉ giữ lại hai routing version mới nhất Tại thời điểm này có thể một data message cũ với routing version cũ đang được truyền trên mesh Và data message cũ này vẫn được truyền một cách bình thường vì thông tin routing ứng với routing version của data message cũ vẫn còn

2.2.3 Routing Table Organization

+ nSlot_: chỉ số item trong array ppSlots_

+ Owner_: link instance của class ALMProcess đại diện cho node

+ ppSlots_: array of ALMRtEntry objects

+ Address_Src_: source address (địa chỉ network của node phát data)

+ InApps_: map với key là Routing Version và value là ALMRtEItemRV object Dùng để cho biết

rằng với một giá trị của RoutingVersion thì node hiện tại nhận data packet từ neighbor nào

+ MapApps_: map với key là Routing Version và value là một list của các ALMRtEItem object

Lưu danh sách các logic link được sử dụng để forward data packet cho mỗi routing version

+ LastMsgID_: message identification number của data message mới nhất mà node hiện tại nhận

được

+ LastRtVersion_: Routing Version của data message mới nhất mà node hiện tại nhận được

class Routing Table

# MapApps_: map<int, list<ALMRtEItem> >

Chứa thông tin về một children node

+ App_: end point của logic link ứng với quan hệ neighbor giữa node hiện tại và một children

node End point này được dùng để gửi data đến neighbor (children node)

+ IsDeleted_: End point App_ được đánh đấu là không được dùng để forward data message khi

member này có giá trị TRUE

+ IsNewDataPathSent_: nếu có giá trị TRUE thì chỉ rằng đã có một message

NEW_DATA_PATH được gửi đến neighbor (children node) ứng với end point App_

- ALMRtEItemRV

Chứa thông tin về một parent node của node hiện tại

+ App_: end point của logic link đến neighbor là parent của node hiện tại

+ IsCRootDone_: nếu có giá trị FALSE thì chỉ rằng quá trình thay đổi parent của node hiện tại

chưa hoàn tất

- ALMTcpApp

Đại diện cho một end point của một logic link (quan hệ neighbor)

+ Neighbor_: link đến ALMNeighbor object đại diện cho quan hệ neighbor hiện thời

Find a list<ALMRtEItem> object Y in X

so that Y's routing version matches with variable "routing-version"

this message contains variables: msg-id, address-src, routing-version

For each item Z in list Y

do forward the message

to Z.App_

«constraint»

{Z.IsDeleted_=FALSE and Z.App_->Neighbor_->State_.Main_ in (READY, MARKED_UNBE)}

X.LastMsgID_=max(self, msg-id)

&X.LastRtVersion_=max(self, routing-version)

[Main_ in (READY, PRE_READY, MARKED_UNBE)]

Hình 3.15

2.3 Single-Source Multicast Protocol

- BROADCAST

Message này được dùng bởi source node trong quá trình broadcast trên mesh để tìm multicast tree cho data message được gửi từ nó Và chứa thêm danh sách địa chỉ network của các node nó đã đi qua Message này có kích thước bằng kích thước của data message

- BROADCAST_RESTART_REQ

Message này được gửi từ node detect ra quá trình broadcast bị thất bại đến source node Khi nhận được message này source node gửi message DATA_RT_FAILED đến tất cả các node khác trên mesh

+ Data_: string + VisitedAddrs: list<int>

Dùng cho mục đích thống kê quá trình broadcast

+ BCTimeDuration_: khoảng thời gian mà quá trình broadcast vừa rồi cần để thực hiện + BCTimeStart_: thời điểm mà quá trình broadcast vừa rồi bắt đầu

+ iSeq_: số tuần tự tăng dần mỗi khi quá trình broadcast hoàn tất tại source node

- ALMDataPaths

Lưu giữ thông tin về path từ root đến node hiện tại trên một multicast tree nhất định

+ MapItems_: map với key=source address (địa chỉ network của node phát data), value=

map<key=routing version, value=danh sách các địa chỉ network> Một path được truy xuất bởi cặp key {source address, routing version}

+ Owner_: link đến ALMProcess object đại diện cho node hiện tại

- ALMRoutingStateMain

Chỉ được dùng cho source node

+ NONE: trạng thái bình thường

+ NEW_VERSION: quá trình broadcast đã hoàn tất và một thông tin routing mới đang đợi

được apply

+ FAILED: quá trình broadcast đã bị thất bại do có một logic link (overlay link) bị đứt hoặc

có một node bị chết và những thông tin broadcast đang dở đang đó cần được dọn dẹp

- ALMRoutingState

Chỉ được dùng cho source node

+ RoutingVersion_: routing version hiện đang được sử dụng để multicast data trên mesh

+ MsgID: số nhận dạng message Trong quá trình broadcast các message sử dụng cùng một

giá trị MsgID cho mỗi quá trình

+ RoutingVersion: routing version hiện thời đang được áp dụng trên mesh

+ Type: message type

- ALMMsg

Class đại diện cho các message được sử dụng bởi tất cả các node trong nhóm multicast

+ Data_: chứa dữ liệu phụ thuộc vào protocol

+ VisitedAddrs: chứa danh sách địa chỉ network của các node Thông thường là địa chỉ

network của các node mà message đã đi qua chúng

- ALMBRSrcInfoState

+ NONE: quá trình broadcast đã hoàn tất cục bộ tại node hiện tại

+ BROADCAST: quá trình broadcast đang diễn ra trên mesh

+ FAILED: quá trình broadcast đã failed

- ALMBRSrcMsgTraceType

+ SEND: chỉ rằng đối tượng trace hiện tại là SEND trace và lưu thông tin về neighbor mà

node hiện tại vừa mới gửi message BROADCAST đến nó

+ RECV: chỉ rằng đối tượng trace hiện tại là RECV trace và lưu thông tin về neighbor mà

node hiện tại vừa mới nhận message BROADCAST từ nó

- ALMBRSrcMsgTrace

Lưu thông tin về mỗi message BROADCAST mà node hiện tại nhận được từ hoặc gửi đến neighbor nào Được gọi tắt là SEND/RECV trace

+ App_: end point được sử dụng để gửi/nhận message

+ IsParent_: nếu có giá trị TRUE thì chỉ rằng đối tượng hiện tại có Type_=RECV và member App_ là end point đến parent của multicast tree có routing version bằng giá trị của member

RtVersion_

+ MsgID_: MsgID của message kết hợp với đối tượng này

+ RtVersion_: Routing version của message kết hợp với đối tượng này

+ TraceTime_: thời điểm mà đối tượng hiện tại được khởi tạo

- ALMBRSrcInfo

Quản lý các ALMBRSrcMsgTrace object của một source address

+ Address_: địa chỉ network của source node

+ MsgLastSent_: message BROADCAST gần đây nhất mà node hiện tại forward đến các

neighbor

- ALMBroadcastHandler

Chịu trách nhiệm điều khiển quá trình broadcast trên mesh cho một source node Trái tim của single-source protocol nằm ở class này Mỗi instance của class ALMProcess đều có một instance của class này để xử lý các message phần broadcast

+ Owner_: link đến ALMProcess object đại diện cho node hiện tại

+ RtTable_: bảng routing của node hiện tại

2.3.3 State Machine Diagram

Hình 3.17 trình bày sơ đồ trạng thái của một ALMBRSrcInfo object Đối tượng này đại diện cho trạng thái của quá trình broadcast xuất phát từ một source node tại một node riêng biệt trên mesh Mỗi quan hệ neighbor giữa hai node có một overlay link (logic link) kết hợp để gửi và nhận message giữa hai node

BROADCAST [number of neighbors

that current node has forwarded this

message to < number of neighbors

that current node has received this

message]

ADD_ROUTING [number of neighbors that current node has received this message = number of neighbors that current has sent message BROADCAST to]

BROADCAST [current node has not

received this message yet before]

Hình 3.17

2.3.4 Activity Diagrams

Hình 3.18 trình bày sơ đồ hành vi của protocol tại phía source node Hình 3.19 trình bày chỉ tiết của hành

vi “Process Events” Thuật ngữ trace được sử dụng ở đây để nói đến một instance của class

ALMBRSrcMsgTrace Nếu đối tượng này có Type_ = SEND thì được gọi là SEND trace, con ngược lại

thì gọi là RECV trace

Member State_, MsgLastSent_ được sử dụng trong các sơ đồ là member của class ALMBRSrcInfo Mỗi

sơ đồ, mặc định kết hợp với một ALMBRSrcInfo object có member Address_ có giá trị chính là địa chỉ

network của source node đang thực hiện quá trình broadcast này