Hệ Điều Hành Phân Tán Chorus (Phần 4)

Phần 4: Truyền thông trong Chorus

Mô hình truyền thông cơ bản trong Chorus là các thông điệp được truyền qua. Trong phần này chúng ta sẽ thảo luận về các thông điệp, các cổng, các hoạt động truyền thông, và bao gồm các cuộc gọi từ hạt nhân.

4.1 Thông điệp (Messages)

Mỗi thông điệp (message) có chứa một tiêu đề (header), một phần cố định (fixed part) và phần thân tùy chọn (body). Phần đầu xác định nguồn và đích, có định danh bảo vệ khác nhau và cờ báo hiệu. Các phần cố định, nếu có, luôn luôn 64 byte dài và hoàn toàn dưới sự kiểm soát của người dùng. Phần thân có thể thay đổi kích thước, với tối đa là 64K byte, và cũng hoàn toàn dưới sự kiểm soát của người dùng. Từ quan điểm của hạt nhân xem xét, thì cả phần cố định và phần thân là không định kiểu mảng byte, nghĩa là các hạt nhân không quan tâm những gì có trong đó.

Khi một message được gửi đến một thread trên một máy khác, nó luôn luôn là bản sao chép. Tuy nhiên, khi nó được gửi đến một thread trên cùng một máy, có một sự lựa chọn giữa sao chép nó hay ánh xạ nó vào không gian địa chỉ của người nhận. Trong trường hợp này, nếu người nhận viết lên một trang được ánh xạ tới, một bản sao chính được làm tại chỗ. Khi một thông điệp không phải là một số nguyên các trang nhưng thông điệp đã được ánh xạ, một số dữ liệu chỉ cần vượt ra ngoài bộ đệm sẽ bị mất khi các trang cuối cùng (hoặc đầu tiên) mà ánh xạ tới.

Một dạng khác của thông điệp là minimessage, mà chỉ được sử dụng giữa các tiến trình hạt nhân cho đồng bộ hóa các thông điệp ngắn, thường là để báo hiệu sự xuất hiện của một ngắt. Các minimessages được gửi đến miniports đặc biệt.

4.2 Cổng (Port)

Message được gửi đến cổng (port), mỗi cổng trong số đó có thể lưu trữ  một số lượng nhất định các thông điệp. Nếu một thông báo được gửi tới một cổng đã đầy, người gửi bị đình chỉ cho đến khi có đủ không gian. Khi cổng được tạo ra, cả định danh duy nhất và một định danh cục bộ được trả lại cho người gọi. Sau đó là được sử dụng trong tiến trình xem xét các cổng trực tiếp. Chỉ Thread trong tiến trình hiện tại đang nắm giữ cổng có thể được đọc từ cổng.

Khi một tiến trình được tạo ra, nó sẽ tự động được gán một cổng mặc định mà hạt nhân sử dụng để gửi thông điệp ngoại lệ. Nó cũng có thể được tạo thêm nhiều cổng phụ (additional ports) nếu cần. Các cổng phụ (nhưng không phải là cổng mặc định) có thể được chuyển đến các tiến trình khác, ngay cả trên các máy khác. Khi một cổng bị chuyển, tất cả các message hiện tại nó chứa có thể di chuyển cùng với nó. Sự di động của cổng rất hữu ích, ví dụ, khi một máy chủ trên một máy tính muốn một máy chủ trên một máy khác nhau đảm nhận công việc của mình. Bằng cách này, các dịch vụ có thể được duy trì trong một cách tường minh.

Chorus cung cấp một cách để gộp một số cổng với nhau thành một nhóm các cổng (port group). Để làm như vậy, tiến trình đầu tiên tạo ra với một nhóm cổng trống và được trở lại một khả năng cho nó. Sử dụng khả năng này, nó có thể thêm các cổng vào nhóm, và sau đó nó có thể sử dụng khả năng xóa cổng khỏi nhóm. Một cổng có thể có mặt trong nhiều nhóm, như minh họa trong hình. 4.1.

Hình 4.1. Một cổng có thể là thành viên của nhiều nhóm cổng

Các nhóm cổng thường được sử dụng để cung cấp các dịch vụ cấu hình lại. Ban đầu thiế lập một số máy chủ thuộc về nhóm, cung cấp một số dịch vụ. Khách hàng có thể gửi message cho nhóm mà không cần phải biết được máy chủ có đang hoạt động. Sau đó, các máy chủ mới có thể tham gia vào nhóm và những máy chủ trước có thể mang đi mà không làm gián đoạn các dịch vụ và không ảnh hưởng tới các máy khách.

4.3. Hoạt động truyền thông

Hai loại hoạt động truyền thông được cung cấp bởi Chorus: gửi không đồng bộ (Asynchronous send) và RPC. Gửi Không đồng bộ cho phép một thread chỉ đơn giản để gửi thông điệp đến cổng. Không có gì đảm bảo rằng thông điệp đến và không có thông báo nếu gặp sự cố. Đây là dạng chuẩn nhất của gói dữ liệu và cho phép người dùng xây dựng các mô hình truyền thông tùy ý trên nó.

Các hoạt động truyền thông khác là RPC. Khi một tiến trình thực hiện một hoạt động RPC, nó sẽ bị khóa tự động cho đến khi nào có thông báo trả lời đến, hoặc bộ hẹn giờ RPC hết hạn, vào thời điểm đó người gửi là hết bị khóa. Thông điệp đó không cấm người gửi phải bắt buộc là sẽ có thông điệp phản hồi. Bất kỳ thông điệp nào không qua giao dịch nhận dạng của RPC sẽ được lưu trữ tại cổng để sử dụng trong tương lai, nhưng sẽ không phản hồi lại người gửi.

RPCs sử dụng ít nhất một lần nghĩa, có nghĩa là trong trường hợp một giao tiếp không thể khôi phục hoặc không chế biến, hệ thống phải bảo đảm sẽ có một RPC trả về một mã lỗi hơn là thay đổi, hoạt động được thực thi nhiều hơn một lần.

Nó cũng có thể gửi tin nhắn cho một nhóm cổng. Tùy chọn khác nhau được kích hoạt, như hình. 4.2. Các tùy chọn này xác định nhiều thông điệp được gửi và đến các cổng.

Hình 4.2. Tùy chọn cho việc gửi đến các nhóm cổng.

(a) Gửi đến tất cả cổng

(b) Gửi tới một cổng và được chọn

(c) Gửi tới cùng một cổng ở một trạng thái chỉ định

(d) Gửi tới cổng đang không ở trạng thái được chỉ định

Lựa chọn (a) trong hình. 4.2 sẽ gửi thông điệp tới tất cả các cổng trong nhóm. Để lưu trữ có độ tin cậy, một tiến trình có thể có tất cả các tập tin dữ liệu lưu trữ máy chủ nào đó. Option (b) gửi nó đến chỉ một cổng, nhưng cho phép hệ thống chọn một. Khi một tiến trình chỉ muốn một số dịch vụ, chẳng hạn như ngày tháng hiện hành, nhưng không quan tâm nó đến từ đâu, tùy chọn này là sự lựa chọn tốt nhất, như hệ thống sau đó có thể chọn cách hiệu quả nhất để cung cấp các dịch vụ.

Hai tùy chọn khác cũng được gửi tới chỉ một cổng, nhưng giới hạn sự lựa chọn hệ thống có thể thực hiện. Trong (c), người gọi có thể xác định rằng các cổng phải được trên một trạng thái cụ thể, ví dụ, để cân bằng tải hệ thống. Lựa chọn (d) cho rằng bất kỳ cổng nào không có trong trạng thái chỉ định có thể được sử dụng.

Để nhận được một thông điệp, một thread nói với hạt nhân gọi cổng nó muốn nhận. Nếu một thông điệp kích hoạt, phần cố định của tin nhắn được sao chép vào không gian địa chỉ của người gọi, và cơ thể, nếu có, là hoặc sao chép hoặc ánh xạ vào, tùy thuộc vào các tùy chọn. Nếu thông điệp không được kích hoạt, các thread bị treo cho đến khi một thông điệp đến hoặc bộ đếm thời gian người sử dụng quy định hết hạn.

Hơn nữa, một tiến trình có thể xác định rằng nó muốn nhận được từ một trong những cổng nó sở hữu, nhưng nó không quan tâm đến chúng. Tùy chọn này có thể được cải thiện bằng cách vô hiệu hóa một số các cổng, trong trường hợp này chỉ kích hoạt các cổng đủ điều kiện đáp ứng yêu cầu. Cuối cùng, các cổng có thể được gán ưu tiên, có nghĩa là nếu có nhiều hơn một cổng được nhận một thông điệp, các cổng với các ưu tiên cao nhất sẽ được chọn. Các cổng có thể được kích hoạt và vô hiệu hoá tự động, và các ưu tiên của chúng có thể được thay đổi.

4.4 Truyền thông semantics (Communication semantics)

Các cơ chế truyền thông đa tiến trình Chorus (IPC) cho phép các thread liên lạc bằng cách gửi thông điệp không đồng bộ hoặc bằng cách đặt các cuộc gọi thủ tục từ xa (RPC). Khi gửi một thông điệp không đồng bộ, phần dẫn (emmiter) sẽ bị khóa chỉ trong nội bộ của thông điệp.
Hệ thống không đảm bảo rằng thông điệp sẽ được nhận bởi các cổng đích.
Khi các cổng đích là không hợp lệ, người gửi không được thông báo và thông điệp sẽ bị loại.
Ngược lại, giao thức RPC cho phép xây dựng các dịch vụ sử dụng mô hình “máy chủ/khách”. RPC đảm bảo rằng các câu trả lời nhận được bởi máy khách là của các máy chủ tương ứng với yêu cầu của máy khách. RPC cũng cho phép một máy khách cho biết nếu yêu cầu của nó đã được nhận được bởi máy chủ, nếu máy chủ đã vô hiệu trước khi phát ra một phản hồi, hay nếu các đường dẫn liên lạc đã bị phá vỡ.
Không đồng bộ IPC và đồng bộ RPC là dịch vụ thông tin chỉ cung cấp bởi Chorus Nucleus. Các IPC không đồng bộ dịch vụ cơ bản là đủ để cho phép xây dựng các giao thức phức tạp hơn trong các hệ thống con. Nó làm giảm lưu lượng mạng trong trường hợp thành công, đạt hiệu suất cao hơn và rộng hơn vào các mạng lớn hay bận.
RPC là một khái niệm đơn giản, dễ hiểu, trong ngôn ngữ cấu trúc hiện nay, và dễ dàng xử lý trong trường hợp lỗi hoặc treo máy. Các Nucleus không cung cấp “kiểm soát lưu lượng”  khi yêu cầu ứng dụng rất khác nhau.

4.5. Lời gọi hạt nhân (Kernel Calls for Communication)

Các cuộc gọi quản lý cổng được thể hiện trong hình. 4.3. Việc đầu tiên cho phép các cổng được tạo ra, phá hủy, kích hoạt, và vô hiệu hóa. Việc cuối cùng là xác định một cổng và một tiến trình. Sau khi cuộc gọi hoàn thành, cổng không còn thuộc về chủ sở hữu ban đầu của nó (không cần phải là người gọi) mà thay vào đó thuộc về tiến trình đích. Nó bây giờ có thể đọc được các tin nhắn từ cổng.

Call Description
portCreate Tạo cổng và khả năng của nó
portDelete Hủy cổng
portEnable Kích hoạt cổng và đếm các thông điệp nhận được từ các cổng
portDisable Vô hiệu hóa cổng
portMigrate Dời cổng đến tiến trình khác

Hình 4.3. Chọn lời gọi quản lý cổng.

Ba lời gọi để quản lý các nhóm cổng. Chúng được liệt kê trong hình. 4.4. Đầu tiên, grpAllocate, tạo ra một nhóm cổng mới và trả về một khả năng cho nó để gọi. Sử dụng khả năng này, người gọi hoặc tiến trình khác sau đó sử dụng các khả năng có thể thêm hoặc xóa cổng khỏi nhóm.

Call Description
grpAllocate Tạo nhóm cổng
grpPortInsert Thêm cổng mới cho nhóm
grpPortRemove Xóa cổng từ nhóm

Hình 4.4. Lời gọi cho nhóm cổng

Lời gọi từ hạt nhân cho việc gửi và nhận tin nhắn. IpcSend gửi một thông điệp không đồng bộ với một cổng cụ thể hoặc một nhóm cổng. IpcReceive khóa trừ khi một thông điệp đến từ một cổng đặc biêt. Thông điệp này có thể đã được gửi trực tiếp đến cổng, cho một nhóm cổng trong đó cổng quy định là một thành viên, hoặc tất cả các cổng kích hoạt (giả sử rằng các cổng quy định được kích hoạt). Phần cố định trong địa chỉ nào đó được sao chép phải được cung cấp, nhưng một địa chỉ cho phần thân là tùy chọn, bởi vì kích thước không phải luôn luôn được biết. Nếu bộ đệm không được cung cấp cho phần than thì lời gọi ipcGetData có thể được thực hiện để thu được phần thân (kích thước được biết đến khi nó được trả về bởi các IpcReceive gọi). Một thông điệp trả lời có thể được gửi bằng cách sử dụng ipcReply. Cuối cùng, ipcCall thực hiện một cuộc gọi thủ tục từ xa.

Call Description
ipcSend Gửi thông điệp không đồng bộ
ipcReceive Khóa cho đến khi thông điệp đến
ipcGetData Nhận phần thân của thông điệp hiện tại
ipcReply Gửi phản hồi tới thông điệp hiện tại
ipcCall Gọi một thù tục từ xa

Hình 4.5. Chọn lời gọi truyền thông.

Phần 5: Định danh (Name Entities)

5.1 Định danh duy nhất (Unique Identifier)

Tất cả đối tượng của Chorus như tác nhân, cổng, và các phân đoạn (segments) được tham chiếu một cách tổng thể bằng cách sử dụng định danh duy nhất (UIs).

Chorus là một hệ thống phân tán, điều quan trọng là có một cách đặt tên các đối tượng trong một tập của các trạng thái đại diện cho một miền Chorus (Chorus domain). Các cấu trúc tiêu chuẩn sử dụng cho một định danh duy nhất cho phép các đơn vị quản lý riêng biệt được dễ dàng kết nối với nhau

Chorus Nucleus thực hiện một dịch vụ định vị định danh duy nhất (UILS) cho phép thực thể hệ thống sử dụng định danh duy nhất tham chiếu các đối tượng Chorus mà không có nhận dạng của mình tại vị trí hiện thời.

Chorus Nucleus đảm bảo rằng UI sẽ tồn tại ít nhất một trạng thái và sẽ không bao giờ sử dụng lại. UI là một cấu trúc 128 bit, có tính duy nhất được xây dựng bằng phương pháp cổ điển. Các dịch vụ định vị sử dụng một vài gợi ý cho việc tìm kiếm các đối tượng đại diện bởi UIs.

Các Nucleus không kiểm soát sự lan truyền của định danh duy nhất, đó là trách nhiệm của các hệ thống con cá nhân.

Hình 5.1  Tiến trình, luồng, vùng, thông điệp và cổng được định danh bởi UIs

5.2 Định danh cục bộ (Local Identifiers)

 

Định danh cục bộ (LIS) được sử dụng trong bối cảnh của một máy chủ để xác định các nguồn tài nguyên liên quan với máy chủ. Những định danh này được đại diện bởi số nguyên và được tạo ra bởi các máy chủ cục bộ. Chúng có thể truyền giữa các thực thể bên trong Chorus miền, nhưng chỉ có nghĩa khi tài nguyên tham chiếu của máy chủ đã tạo ra chúng. Đặc biệt, các định danh có thể đại diện một thứ tự trong bảng máy chủ hay một con trỏ đến một cấu trúc dữ liệu máy chủ.

5.3 Xác thực (Authentication)

Các Chorus Nucleus cung cấp khả năng bảo vệ các đối tượng được quản lý bởi các máy chủ hệ thống con. Vì tất cả các dịch vụ được gọi thông qua cơ chế Chorus IPC, sự hỗ trợ cung cấp không thể thiếu cơ chế này.
Nucleus hỗ trợ một định danh bảo vệ (protection identifier) cho mỗi tác nhân và cổng. Cấu trúc của các định danh là cố định, nhưng Nucleus không liên kết bất kỳ giá trị ngữ nghĩa nào với chúng. Định danh bảo vệ có thể được thay đổi bởi thread đáng tin cậy. Ngoài ra, tác nhân hoặc cổng có thể kế thừa định danh bảo vệ của các tác nhân đã tạo ra nó.
Mỗi thông điệp được gửi bởi một tác nhân có kiểm soát của Nucleus với các định danh bảo vệ của nó từ nguồn tác nhân và cổng. Những giá trị này có thể được đọc nhưng không được sửa đổi bởi người nhận của thông điệp và có thể được sử dụng để xác định danh tính của người yêu cầu của dịch vụ.

(Hết phần 4-5)

Leave a Reply