1. Truyền thông

1.1. Nền tảng

Truyền thông làm một yếu tố tối quan trọng trong hệ phân tán. Sẽ là vô ích khi chúng ta tìm hiểu về hệ phân tán mà lại không quan tâm đến cách thức các tiến trình trong các máy khác nhau trao đổi thông tin.

Mô hình truyền thông trong mạng phân tán tương tự như trên mô hình tham chiếu OSI trong mạng máy tính: nó được chia thành các tầng, mỗi tầng đảm nhiệm một công việc cụ thể trong quá trình truyền thông. Sự khác biệt cơ bản nhất của mô hình truyền thông trong hệ phân tán so với mô hình truyền thông trong mạng máy tính là sự có mặt của tầng trung gian (middleware layer) thay thế cho tầng phiên và tầng trình diễn.

1.1.1. Kiến trúc phân tầng

Mô hình giao thức phân tầng (Layered Protocol)

Hình 4.1: Mô hình OSI bảy tầng

Mô hình giao thức phần trung gian (Middleware Protocol)

Hình 4.2: Middleware Protocol

1.1.2. Các mô hình truyền thông

1.1.2.1. Persistent communication

Email là một ví dụ của persistent communication, một bức thư được submit để gửi đi sẽ được lưu trữ trong phần trung gian truyền thông (communication middleware) cho đến khi nó được gửi đến cho người nhận. Trong trường hợp đó, middleware sẽ lưu trữ thư tại một hay nhiều các công ụ lưu trữ như trong Hình 4.3, do đó, ứng dụng gửi sẽ không cần thiết phải tiếp tục thực thi sau khi đã gửi (submitting) tin. Tương tự vậy, ứng dụng nhận cũng không cần phải đang thực thi khi thư được gửi.

Hình 4.3: Viewing middleware as an intermediate (distributed) service in application-level communication

1.1.2.2. Transient  communication

Trong hình thức này, thông thư chỉ được lưu trong hệ thống truyền thông chừng nào ứng dụng gửi và nhận đều đang thực thi. Cụ thể hơn, trong Hình 4.3, middleware không thể chuyển giao thư do việc truyền thông bị gián đoạn (transmission interrupt), hoặc bên nhận đang không online. Nó sẽ hủy thư đi.

1.1.2.3. Asyschronous communication

Phía gửi sẽ tiếp tục ngay sau khi nó vừa gửi thư (submit for transmission). Điều này có nghĩa là thông điệp (tạm thời) được lưu trữ bởi middleware ngay sau submission.

1.1.2.4. Syschronous communication

Phía gửi bị phong tỏa cho tới khi thư đã được chấp nhận. Có ba điểm đồng bộ: một, phía gửi bị block tới khi middleware báo đã được chuyển giao yêu cầu, hai, phía gửi đồng bộ tới khi yêu cầu được gửi tới nơi nhận, ba, đồng bộ xảy ra khi phía gửi chờ tới khi yêu cầu đã hoàn toàn được xử lí (phía nhận gửi response).

Có nhiều kết hợp giữa persistence và synchronization trong thực tế. Một phổ biến là persistence kết hợp với đồng bộ ở trình yêu cầu (request submission), một thiết kế phổ biến cho các hệ thống hàng đợi thông điệp. Tương tự, transient với synchronization sau khi yêu cầu được hoàn toàn xử lí cũng được dùng rộng rãi.

Ngoài ra còn có discrete/streaming communication. streaming bao gồm gửi nhiều thông điệp, lần lượt từng cái, các thông điệp là liên quan theo thứ tự được gửi vì chúng là quan hệ thời gian.

1.2. Các loại Middleware phổ dụng

Có bốn loại Middleware phổ dụng:

1.2.1. Lời gọi thủ tục từ xa (RPC)

Thực hiện chủ yếu theo mô hình Client/Server. Khi một tiến trình trên máy A ( client) gọi một thủ tục trên máy B (server), tiến trình gọi trên A sẽ bị treo, và quá trình thực thi thủ tục được gọi diễn ra trên máy B. Thông tin được truyền từ phía gọi (A) sang phía nhận (B) trong các tham số, và được trả về dưới dạng kết quả của thủ tục. Phương pháp này được gọi là lời gọi thủ tục từ xa ( RPC – Remote Procedure call)

Trong khi ý tướng của phương pháp là đơn giản như vậy, thì trong thực tế, vẫn còn tồn tại nhiều vấn đề liên quan đến nó.

·         Thứ nhất, do phía gọi và phía bị gọi nằm ở hai máy tính khác nhau, nên chúng sẽ được thực thi trên những không gian địa chỉ khác nhau, và điều này gây ra sự phức tạp không nhỏ.

·         Thứ hai, tham số và kết quả trả về cũng phải được truyền di, điều này cũng gây ra sự phức tạp nếu như hai máy là không tương tự nhau.

·         Cuối cùng, trong quá trình thực hiện, có thể một trong hai máy xảy ra lỗi, và lỗi này có thể gây ra một số vấn đề khác nữa.

Tuy nhiên, các khó khăn này đều đã được khắc phục phần nào, và RPC vẫn đang là một trong những kĩ thuật phổ biến được sử dụng bởi nhiều hệ phân tán.

Người ta phân RPC ra làm hai loại : Synchronous RPC và Asynchronos RPC.

Hình 4.4: Synchronous RPC (a) và Asynchronous RPC (b)

·         Với truyền thông đồng bộ, sau khi client đưa ra request, nó sẽ phải chờ phản hồi từ phía server. Trong thời gian đó, nó không làm gì cả, và đó cũng chính là một nhược điểm của việc truyền đồng bộ. Điều này sẽ dẫn tới việc chờ đợi vô ích của tiến trình gọi trên client, nhất là khi lời gọi không có kết quả trả về, trong khi nó có thể thực hiện một số công việc hữu ích khác. Một số ví dụ về việc tiến trình gọi không cần phải đợi kết quả trả về, đó là việc thêm một entry vào cơ sở dữ liệu, khởi động một dịch vụ từ xa, xử lý hàng loạt ( batch processing)… Chính vì vậy mà khái niệm truyền thông không đồng bộ được đưa ra.

·         Với truyền thông không đồng bộ, sau khi server nhận được request, nó sẽ gửi một tín hiệu ACK về cho client để báo nhận. Khi client nhận được tín hiệu ack này ,nó có thể thực hiện các công việc khác trong thời gian server xử lý request kia.

1.2.2. Triệu gọi đối tượng từ xa (RMI)

[trang 458]

Khi một client được gán vào một đối tượng, nó có thể gọi phương thức của đối tượng đó thông qua proxy. Điều này được gọi là lời gọi phương thức từ xa (remote method invocation) hay RMI. RMI khá giống với RPC khi chúng ta đề cập đến các vấn đề như che giấu thông tin hay truyền tham số. Điểm khác biệt lớn nhất giữa chúng, đó là RMI thường hỗ trợ tham chiếu đối tượng ở cấp độ toàn hệ thống, hơn nữa, chúng ta không cần thiết phải có một khối client dùng chung và một khối server tương ứng, chúng ta chỉ cần tích hợp một khối đối tượng đặc thù như trên @@

Cách đơn giản nhất để hỗ trợ RMI, đó là chỉ ra các giao diện của đối tượng trong một ngôn ngữ định nghĩa giao diện, ngoài ra, chúng ta cũng có thẻ sử dụng ngôn ngữ dựa trên đối tượng như Java. Ở đây, chúng ta phân biệt lời gọi động và lời gọi tĩnh:

·         Lời gọi tĩnh: đó là cách tiếp cận khi chúng ta sử dụng các định nghĩa giao diện có sẵn. Lời gọi tĩnh đòi hòi giao diễn của đối tượng phải được xác định tại thời điểm ứng dụng client được phát triển. Nó cũng chỉ ra rằng, nếu giao diện thay đổi thì các ứng dụng client cũng cần phải biên dịch lại trước khi chúng ta có thể sử dụng ứng dụng mới.

·         Lời gọi động : Đó là khi chúng ta tạo ra lời gọi tại thời điểm runtime. Sự khác biệt cơ bản của nó với lời gọi tĩnh, đó là một ứng dụng sẽ lựa chọn tại thời điểm runtime phương thức tạo sẽ được gọi tại đối tượng từ xa. Lời gọi động thường có dạng

Invoke(object, method, input_params, output_params

o   Object ở đây chính là đối tượng phân tán

o   Method là tham số đặc tả chính xác phương thức nào được gọi

o   Input_param là cấu trúc dữ liệu để lưu trữ các tham số đầu vào

o   Output_param là cấu trúc dữ liệu để lưu trữ các kết quả đầu ra.

Ví dụ, với việc gán một số integer int cho một đối tượng fobject, lời gọi tĩnh và lời gọi động có dạng như sau

·         Lời gọi tĩnh:

fobject.append(int)

·         Lời gọi động:

invoke(fobject,id(append),int)

[Hoàng] (dcm anh ý chơi pdf L)

1.2.3. Truyền thông điệp (MOM)

Ở phần bên trên, em đã tìm hiểu về RPC, tuy nhiên, cũng có trường hợp RPC tỏ ra không phù hợp, nó đòi hỏi cả bên gửi và bên nhận cùng phải sẵn sàng (active) tại thời điểm diễn ra truyền thông. Tuy nhiên, đôi khi chúng ta không thể biết được liệu bên nhận yêu cầu có đang sẵn sàng (active) hay không. Chúng ta có thể giải quyết vấn đề này thông qua hệ thống messages-hàng đợi, hoặc Messages -Oriented Middleware (MOM). Hệ thống Message-hàng đợi  cung cấp hỗ trợ rộng rãi cho các giao tiếp không đồng bộ liên tục. Bản chất của các hệ thống này là chúng cung cấp dung lượng lưu trữ   cho, mà không đòi hỏi một trong hai người gửi hoặc nhận được hoạt động trong quá trình truyền messages.

1.2.4. Truyền thông hướng dòng (SOM)

Với các hình thức truyền thông ở bên trên, chúng ta chỉ quan tâm đến việc trao đổi thông tin, mà không hề quan tâm cụ thể rằng việc trao đổi thông tin sẽ diễn ra tại một thời điểm cụ thể nào, và cũng không hề quan tâm đến việc thời gian truyền là nhanh hay chậm. Hay nói khác đi, trong các mô hình truyền thông bên trên, thời gian không hề ảnh hưởng tới tính đúng đắn của việc truyền tin.

Với hình thức truyền thông hướng dòng, thời gian đóng một vai trò cự kì quan trọng. Ví dụ, nếu một đoạn âm thanh được phát lại với tốc độ (rate) khác với tốc độ của đoạn âm thanh ban đầu, nó có thể cho ra kết quả khác với đoạn âm thanh gốc. Tương tự như vậy, nếu chúng ta muốn xem một bộ phim trực tuyến trên mạng, nếu thời gian truyền của dữ liệu là quá chậm, bộ phim có thể bị gián đoạn. Như vậy, hình thức truyền thông này được cung cấp nhằm tạo điều kiện thuận lợi cho việc trao đổi các thông tin phụ thuộc vào thời gian, tức là, khi thời gian sẽ ảnh hưởng đến tính đúng đắn của thông tin được trao đổi.

1.3. Truyền thông đa điểm (MultiCast)

Truyền thông đa điểm chính là khả năng gửi dữ liệu từ một điểm tới nhiều điểm nhận. Với mô hình này, chúng ta có hai trường hợp:

·         Từ một điểm truyền đến nhiều điểm: Từ một điểm, chúng ta sẽ truyền đồng thời đến một nhóm các điểm thỏa mãn một tiêu chí nào đó.

·         Từ một điểm truyền đến tất cả các điểm: broadcast (quảng bá) : từ một điểm, chúng ta sẽ truyền đến tất cả các điểm còn lại có khả năng tiếp nhận à điều này là rất có ích, và nó được thực hiện khá nhiều trong bối cảnh hệ phân tán. Ví dụ, nếu chúng ta có một tiến trình, nếu ta muốn đưa ra một thống nhất, một chu trình nào đó mà phải tham khảo tất cả các tiến trình còn lại. Trong trường hợp này chúng ta sẽ sử dụng broadcast.