Hệ thống bao gồm ba thành phần chính: giao diện người cung cấp sự kiện, giao diện người yêu cầu sự kiện và mạng ngang hàng có cấu trúc.
Mạng ngang hàng có cấu trúc được sử dụng trong hệ thống này dựa trên mô hình mạng Chord. Mạng này đóng vai trò nền tảng hoạt động của toàn bộ hệ thống, các thông tin trong hệ thống sẽ được lưu trữ và tìm kiếm tại đây. Vì vậy, nó phải cung cấp được đầy đủ các giao thức cho hai thành phần giao diện còn lại.
Nhiệm vụ của hai thành phần giao diện chỉ là thu thập thông tin của người sử dụng, mã hóa theo chuẩn của hệ thống, sau đó sử dụng các giao thức tìm kiếm và lưu trữ sẵn có trong mạng Chord để hoạt động. Tại giao diện cung cấp sự kiện, người cung cấp có thể lựa chọn các thuộc tính của sự kiện cần cung cấp, sau đó nhập thông tin về sự kiện này và gửi lên mạng. Mỗi thuộc tính trong sự kiện sẽ được hệ thống băm thành một khóa riêng và lưu trữ tại những nút khác nhau trên mạng. Việc lưu trữ này sẽ giúp quá trình tìm kiếm sự kiện dễ dàng hơn. Người yêu cầu sự kiện có thể lựa chọn một thuộc tính chung của sự kiện, tất cả các sự kiện được cung cấp mà có thuộc tính này sẽ đều được trả lại cho người yêu cầu.
C á c k h ó a s ẽ đ ư ợ c lư u v à o 1 b ả n g
Hình 16: Hoạt động của hệ thống thông báo sự kiện
Như hình trên, sự kiện được cung cấp gồm 3 cặp thuộc tính giá trị (Type = Bóng đá), (Giải đấu = Seria A) và (Trận đấu = ACMilan-InterMilan). Mỗi cặp thuộc tính giá trị này sẽ được băm thành một khóa khác nhau. Mỗi khóa kèm với tên và thông tin sự kiện sẽ được lưu trữ tại những nút khác nhau trên mạng (tùy vào bảng DTH trong mạng Chord). Như vậy, những thuộc tính ở mức cao trên cây thuộc tính có thể có rất nhiều những sự kiện được cung cấp kèm với nó.
Khi người yêu cầu cần một sự kiện nào đó. Họ sẽ lựa chọn theo những thuộc tính mà mình cần. Ví dụ ở hình trên, người yêu cầu sự kiện lựa chọn 2 cặp thuộc tính giá trị là (Type = Bóng đá) và (Giải đấu = Seria A). Trong 2 cặp thuộc tính giá trị này, chỉ có cặp thuộc tính (Giải đấu = Seria A) là được băm thành khóa. Do đây là thuộc tính nằm bên dưới trong cây thuộc tính, vì vậy tất cả những sự kiện có thuộc tính (Giải đấu = Seria A) đều sẽ có thuộc tính (Type = Bóng đá), nên chỉ cần băm thuộc tính này là đủ.
Để đáp ứng được các yêu cầu sự kiện một cách đầy đủ nhất. Hệ thống sẽ tiến hành lưu trữ lại cả thông tin sự kiện và yêu cầu sự kiện trên các nút trong mạng Chord. Hai loại thông báo này được lưu trữ theo những chuẩn cố định để dễ dàng hơn trong việc tìm kiếm.
- Thông tin sự kiện được lưu trữ theo cấu trúc: (Khóa, các thuộc tính của sự kiện, chi tiết thông tin sự kiện).
- Yêu cầu sự kiện được lưu trữ theo cấu trúc: (Khóa, thuộc tính của sự kiện, địa chỉ IP, cổng). Trong đó địa chỉ IP và cổng là của nút yêu cầu sự kiện, khi có thông tin sự kiện thỏa mãn, thông tin này sẽ được gửi về nút tương ứng dựa trên các thông số này.
Quá trình cung cấp sự kiện và tìm kiếm sự kiện đều diễn ra theo cả hai chiều, bao gồm cả việc lưu trữ và tìm kiếm. Khi người sử dụng yêu cầu một sự kiện nào đó, yêu cầu này sẽ được lưu trữ lại, và mạng Chord cũng tiến hành tìm kiếm các sự kiện đã có thỏa mãn yêu cầu để trả lại cho người sử dụng. Ngược lại, khi có một sự kiện được cung cấp, ngoài việc lưu trữ lại các sự kiện này, hệ thống cũng sẽ tìm kiếm các yêu cầu đã được lưu trữ sẵn. Nếu tìm thấy yêu cầu thỏa mãn, sự kiện sẽ được gửi ngay đến người sử dụng dựa trên các thông số lưu trữ trên hệ thống. Phương pháp này sẽ làm giảm tải truyền trên mạng, giúp hệ thống hoạt động ổn định hơn.
3.5. Kết luận
Chương này trình bày về mục đích, yêu cầu, phương pháp xây dựng và cấu trúc của dịch vụ thông báo sự kiện dựa trên mạng ngang hàng có cấu trúc đã đề xuất.
Qua chương này ta thấy dịch vụ thông báo sự kiện dựa trên mạng ngang hàng có thể đáp ứng được các yêu cầu: thời gian phản hồi của dịch vụ nhanh và hệ thống có thể dễ dàng mở rộng. Trong chương tiếp theo chúng ta sẽ thử nghiệm và đánh giá về hiệu quả của hệ thống.
CHƯƠNG 4. THỰC THI VÀ ĐÁNH GIÁ CHƯƠNG TRÌNH
4.1. Triển khai hệ thống
Hình 17: Mô hình thử nghiệm
- Thực hiện triển khai hệ thống trên 6 node có cấu hình mạng:
Peer 1: Địa chỉ IP là 169.254.80.1 Peer 2: Địa chỉ IP là 169.254.80.2 Peer 3: Địa chỉ IP là 169.254.80.3 Peer 4: Địa chỉ IP là 169.254.80.4 Peer 5: Địa chỉ IP là 169.254.80.5 Peer 6: Địa chỉ IP là 169.254.80.6
- Tiến hành cung cấp sự kiện lên mạng
Hình 18: Giao diện chức năng cung cấp sự kiện
- Thực hiện yêu cầu sự kiện
- Hệ thống hiển thị thông báo đến node đã yêu cầu sự kiện
Hình 20: Giao diện thông báo sự kiện
- Thử nghiệm tăng số yêu cầu sự kiện đến hệ thống
Tiến hành thử nghiệm với số yêu cầu đến hệ thống lần lượt là: 1 yêu cầu, 2 yêu cầu, 4 yêu cầu, 6 yêu cầu
- Chương trình sẽ lưu lại thời gian tại các thời điểm sau:
Trường hợp 1: Thực hiện yêu cầu sự kiện cho các sự kiện đã được cung cấp trên
mạng
- Thời điểm t1.1: thời điểm node đầu tiên bắt đầu gửi yêu cầu sự kiện.
- Thời điểm t1.2: một máy trong Chord nhận được yêu cầu sự kiện và đồng thời máy tính này sẽ gửi truy vấn tìm kiếm ngay lúc này. (adsbygoogle = window.adsbygoogle || []).push({});
- Thời điểm t1.3: Thời điểm máy tính trong mạng Chord nhận được sự kiện yêu cầu và gửi ngay kết quả cho node yêu cầu sự kiện.
- Thời điểm t1.4: Thời điểm node yêu cầu sự kiện nhận được thông báo
- Từ các mốc thời gian trên có thể tính được:
- Thời gian gửi yêu cầu sự kiện=t1.2-t1.1
- Thời gian tìm kiếm sự kiện trên mạng Chord=t1.3-t1.2
- Thời gian gửi thông báo đến node yêu cầu sự kiện=t1.4-t1.3
- Thời điểm t2.1: thời điểm 1 node bắt đầu cung cấp sự kiện lên hệ thống.
- Thời điểm t2.2: thời điểm các node phụ trách khóa nhận được sự kiện cung cấp
- Thời điểm t2.3 : Thời điểm tìm được yêu cầu tương ứng với sự kiện
- Thời điểm t2.4 : Thời điểm node gửi yêu cầu sự kiện nhận được thông báo
- Từ các mốc thời gian trên có thể tính được:
- Thời gian cung cấp sự kiện = t2.2-t2.1
- Thời gian tìm kiếm sự kiện trên mạng Chord = t2.3-t2.2
- Thời gian gửi thông báo đến node yêu cầu sự kiện = t2.4-t2.3