Truyền thông hỏi-đáp

Như thông thường, thao tác gọi thủ tục và chờ kết quả là tương tự cặp TT hỏi/đáp đồng bộ. Điều tương tự giữa lời gọi thủ tục và TT là động lực thúc đẩy nguyên thủy khi dùng lời gọi thủ tục như trừu tượng mức cao cho TT. Một RPC có dạng một lời gọi thủ tục thông thường với các tham số input và output phù hợp của nó. Do không có phân biệt về cú pháp giữa lời gọi thủ tục từ xa và một lời gọi thủ tục cục bộ nên RPC cung cấp sự truy cập trong suốt tới các thao tác từ xa. Tuy nhiên, ngữ nghĩa của chúng là khác nhau do thực hiện thủ tục từ xa bao hàm độ trễ và lượng lỗi có thể trong thao tác mạng. ứng dụng người dùng cần biết về sự khác biệt này và mối liên quan của chúng. Tuy vậy nhưng RPC là cách đơn giản và trong sáng hoàn thành được tính trong suốt TT bằng cách che dấu lời gọi hệ thống mức thấp, sự biến đổi dữ liệu và TT mạng từ ứng dụng người dùng. Như đã biết (chương II) RPC hỗ trợ một dịch vụ trình diễn giữa tầng giao vận và tầng ứng dụng. RPC có thể được chú ý như một API đối với dịch vụ giao vận. Thao tác RPC cơ sở trong mô hình Client/Server được chỉ ra trong hình 4.10.

Mô tả ngắn gọn về thi hành lời gọi thủ tục từ xa. Giả thiết rằng thông tin cần thiết cho kết nối RPC đã được khởi tạo giữa khách và phục vụ như trong hình 4.10. Lời gọi thủ tục từ xa được khởi tạo từ khách thông qua một lời gọi request, được kết nối với thủ tục nền khách tại nền khách. Thủ tục nền khách chịu trách nhiệm đóng gói lời gọi và tham số của nó thành một TĐ để truyền (điển hình sử dụng API socket) dọc theo mạng nhờ dịch vụ giao vận. TĐ này được dịch vụ giao vận phục vụ tiếp nhận và dịch vụ này chuyển nó tới nền phục vụ. Nền phục vụ là điểm vào chính của phục vụ. Nó tách TĐ thành một lời gọi hỏi với các tham số tương ứng và kích hoạt thủ tục tại phục vụ. Khi hoàn thiện dịch vụ, thủ tục phục vụ đưa lời đáp tới nền phục vụ để đóng gói các tham số thành một TĐ và gửi nó tới dịch vụ giao vận. Quá trình nhận được thực hiện tại phía khách, và được kết thúc bằng việc nhận được trả lời và loại bỏ việc thực hiện lời gọi.

Thao tác RPC cơ sở nảy sinh một số vấn đề đáng chú ý sau đây:

-Truyền tham số và biến đổi dữ liệu: Kiểu dữ liệu được truyền và dữ liệu được trình bày trong TĐ theo cách nào ?

-Liên kết: Làm thế nào khách có thể định vị được phục vụ và bằng cách nào phục vụ ghi nhận được dịch vụ của nó (tạo ra dịch vụ có thể nhìn được từ xa) ?

-Biên dịch: Thủ tục nền đến từ đâu và làm cách nào chúng liên kết tới QT khách và QT phục vụ?

-Loại bỏ và kiểm soát lỗi: Làm cách nào để kết xuất lỗi và giả thiết nào cần có về lỗi trong hệ thống ?

- An toàn: RPC an toàn ?

Ba vấn đề đầu tiên được trình bày như dưới đây.

Truyền tham số và biến đổi dữ liệu

Quy tắc truyền tham số và biến đổi dữ liệu/TĐ RPC được coi là việc sắp xếp lại tham số. Sắp xếp tham số là trách nhiệm nguyên thủy của thủ tục nền. Tồn tại nhiều ngữ nghĩa cho việc truyền tham số đối với lời gọi thủ tục trong ngôn ngữ lập trình bậc cao hiện hành. Đó là các cách thức gọi theo giá trị, gọi theo tên, gọi theo chỉ dẫn, và gọi qua sao chép/khôi phục. Phương pháp gọi theo giá trị trong RPC là trực tiếp. Một giá trị được truyền cho thủ tục được sao vào một biến cục bộ tại điểm vào của thủ tục. Sự thay đổi của biến cục bộ trong lời gọi thủ tục không ảnh hưởng đến lời gọi thủ tục. Gọi theo tên đòi hỏi việc đánh giá biểu thức ký hiệu trong khi thực hiện động là không thực sự dễ dàng trong môi trường biên dịch. Truyền tham số theo chỉ dẫn chuyển con trỏ địa chỉ sẽ gây nên sự lúng túng nếu không giảm ngữ nghĩa trong hệ phân tán với hoàn cảnh là không có bộ nhớ trong chia xẻ. Bởi vậy, gọi theo chỉ dẫn không phải là phương pháp truyền tham số thích hợp đối với RPC. Gọi theo sao chép/khôi phục kết hợp của gọi theo giá trị và gọi theo chỉ dẫn. Nó là gọi theo giá trị tại điểm vào của lời gọi thủ tục và gọi theo chỉ dẫn có hạn chế tại điểm ra của RPC. Kết quả được sao lại trở lại cho thủ tục gọi; khi hoàn thành thủ tục gọi không tạo ra bất kỳ chỉ dẫn bộ nhớ nào trong quá trình thực hiện thủ tục. Cách thức này có thể được dùng để nắm giữ các con trỏ nhằm đơn giản hóa các cấu trúc dữ liệu kiểu mảng. Cấu trúc con trỏ phức tạp, chẳng hạn như cây và đồ thị, sẽ khó thi hành RPC với mục tiêu nắm giữ mà không cần công sức và phí tổn nào đó. Đa số các thi hành RPC giả thiết tham số được truyền là gọi theo giá trị và gọi theo sao chép/khôi phục.

Dữ liệu trong ngôn ngữ bậc cao thường được định kiểu theo cấu trúc xác định-tốt. Kiểm tra kiểu tĩnh được trình biên dịch thực hiện khi đối sánh phù hợp hóa kiểu giữa thủ tục nền với khách hoặc phục vụ. Kiểm tra kiểu xuyên qua các máy là khó khăn hơn vì dữ liệu được chuyển thông qua TĐ liên chương trình. Vì vậy, một câu hỏi được nảy sinh là có cần hay không dữ liệu mang kèm theo thông tin kiểu để kiểm tra kiểu động? Hơn nữa, mỗi máy tính lại có cách trình bày dữ liệu riêng của mình. Ví dụ, kiểu integer có thể được trình bày dạng phần bù 2 trong một máy 32 bit song lại có thể là dạng có dấu với lượng 16 bit trong một máy khác. Đối với văn bản, một số máy dùng mã ASCII trong khi một số máy khác dùng EBCDIC. Sự khác nhau này do tính hỗn tạp các thành phần trong hệ thống tạo ra tính cần thiết phải biến đổi dữ liệu trong truyền thông ngang hàng. Tình huống rắc rối hơn khi xem xét việc trình bày chuỗi bit và byte trong kênh truyền thông. Nói riêng, các máy khác nhau có chuẩn khác nhau để các bit hoặc byte trong TĐ được truyền ít nhất hoặc hầu hết chữ số có dấu được truyền trước.

Quy tắc liên quan tới giao vận TĐ trong mạng được gọi là cú pháp giao vận. Một số chuẩn biến đổi dữ liệu tường minh bắt buộc được công nhận trong mọi hệ thống khi trình bày dữ liệu (hoặc CSDL) hỗn tạp. Nếu như n cách trình bày dữ liệu thì phải có n*(n-1)/2 cách biến đổi dữ liệu. Giải pháp tốt hơn là tạo ra một ngôn ngữ vạn năng hoặc bộ biểu diễn dữ liệu hợp chuẩn mà mỗi QT TT cần dịch đối với ngôn ngữ hoặc biểu diễn dữ liệu riêng của nó. Rút gọn này cho phép chỉ cần 2*n phép biến đổi đối với hệ thống n cách trình bày. Đáng tiếc là việc sử dụng một ngôn ngữ vạn năng đòi hỏi phải tăng thêm nhiều chi phí về đóng gói và tách gói. Vì vậy, một số nhà sản xuất đề xuất là ngôn ngữ vạn năng được định danh bằng ngôn ngữ bản địa của máy tính do hãng chế tạo. Điểm tối ưu ở chỗ ngăn ngừa được việc dịch nếu các QT TT có thể ngầm định rằng chúng chia xẻ cùng một dạng tự nhiên. Ba vấn đề đáng chú ý trong chuyển đổi dữ liệu tới TĐ và từ TĐ tới dữ liệu như bàn luận trên đây là định kiểu dữ liệu, biểu diễn dữ liệu và cú pháp giao vận dữ liệu.

Một trong những phát triển quan trọng nhất nhằm chuẩn hóa việc định kiểu và biểu diễn dữ liệu là Bộ chú giải cú pháp trừu tượng 1 (ASN.1). ASN.1 là một ngôn ngữ định nghĩa cấu trúc dữ liệu và được sử dụng rộng rãi để đặc tả khuôn dạng các giao thức chỉnh thể dữ liệu trong TT mạng. Cú pháp giao vận và ASN.1 là điều kiện chính để xây dựng dịch vụ trình diễn mạng. ASN.1 có thể được dùng trực tiếp trong trình diễn dữ liệu để thi hành RPC. Các thi hành RPC hiện tại thường dùng một tập con của ASN.1. Nếu RPC được hỗ trợ trong một miền đơn thì nền khách và nền phục vụ là cộng tác mật thiết. Kiểu dữ liệu được kiểm tra khi sinh và dịch các thủ tục nền. Khi đó không cần cung cấp thông tin kiểu trong TĐ (tức là kiểu đã tường minh trong ASN.1). Trong hệ hỗn tạp, vấn đề liên quan đến cú pháp giao vận được bỏ qua. Các ví dụ kinh điển về ngôn ngữ mô tả và trình diễn dữ liệu đối với RPC là XDR (eXternal Data Representation) của Sun và IDL (Interface Definition Language) của DCE. Cả hai tương tự với ASN.1 song định nghĩa cấu trúc dữ liệu và giao diện thủ tục là đơn giản hơn.

Liên kết

Phục vụ buộc phải tồn tại trước khi khách tạo ra một lời gọi thủ tục tới nó. Dịch vụ này được đặc tả bằng một giao diện phục vụ khi dùng một ngôn ngữ định nghĩa giao diện, chẳng hạn XDR. Một đặc tả giao diện phục vụ điển hình có khuôn dạng được trình bày như hình 4.11. Ví dụ này mô tả hai thủ tục và được định danh duy nhất qua chương trình và số hiệu phiên bản của nó. Khách có thể định vị phục vụ bằng việc quảng bá yêu cầu đối với dịch vụ. Tuy nhiên, giải pháp hiệu quả hơn là đi tới tên riêng phục vụ mà địa chỉ của nó đã được định vị tốt, nếu điều đó là cho phép.

program PROGRAMME {

version VERSIONNAME {

long PROCEDUREA (parameters) = 1; /* procedure number = 1 */

string PROCEDUREB (parameters) = 2; /* procedure number = 2 */

} = 1 ; /* version number = 1 */

} = 12345 ; /* program number = 12345 */

Hình 4.11. Một đặc tả giao thức phục vụ

Hình 4.12 minh họa việc liên kết giữa khách và phục vụ. Liên kết đó được giải thích qua các bước sau đây:

1. Khi phục vụ được khởi động, nó ghi nhận nút TT của mình bằng việc gửi một yêu cầu tới bộ ánh xạ cổng. Yêu cầu này bao gồm chương trình của phục vụ, số hiệu phiên bản cùng với số hiệu cổng mà phục vụ dùng để nghe (listen). Bộ ánh xạ cổng quản lý việc ánh xạ giữa số hiệu chương trình và số hiệu cổng. Giả thiết rằng ánh xạ cổng là một QT phục vụ chạy ngầm (daemon) với địa chỉ cổng đã được biết tốt.

2. Trước khi tạo một lời gọi thủ tục từ xa, QT khách bắt buộc tiếp xúc với bộ ánh xạ cổng của hệ thống từ xa để thu được một thẻ (handing) truy nhập tới phục vụ với chương trình riêng và số hiệu phiên bản. Điều này đạt được nhờ việc gọi một chương trình con (routine) creat của thư viện thời gian chạy RPC và creat gửi một TĐ chứa tên máy phục vụ, chương trình và số hiệu phiên bản, cùng giao thức giao vận (UDP hoặc TCP) tới bộ ánh xạ cổng từ xa.

3. Bộ ánh xạ cổng qua kiểm tra chương trình và số hiệu phiên bản trong bảng của nó để cung cấp (trả lại) số hiệu cổng của phục vụ tới hệ thống khách.

4. Hệ thống khách xây dựng một thẻ khách cho QT khách để sử dụng sau này trong lời gọi thủ tục từ xa. Quá trình liên kết thiết lập các kết nối socket giữa khách và phục vụ.

Trong trường hợp tổng quát hơn khi chưa biết được máy phục vụ, khách cần định vị máy phục vụ bằng cách tiếp xúc với một phục vụ thư viện (đôi lúc được gọi là bộ liên kết, bộ giao dịch) để định vị địa chỉ của hệ thống phục vụ. Các đường nét rời trong hình 4.12 trình bày thao tác bổ sung này.

Biên dịch RPC

Biên dịch các RPC đòi hỏi ba thành phần chính trong bó RPC:

- Một file đặc tả giao diện;

- Một bộ sinh RPC có chức năng nhận input là file đặc tả giao diện và sản xuất ra output là mã nguồn các thủ tục nền khách và phục vụ;

- Một thư viện thời gian chạy để hỗ trợ việc thực hiện RPC bao gồm cả hỗ trợ việc liên kết, biến đổi dữ liệu và truyền thông.

Hình 4.13 trình bày công việc sinh các thủ tục nền và biên dịch chương trình RPC. Bộ sinh RPC khởi tạo các thủ tục nền và một thẻ file vì tính biên dịch độc lập của các chương trình khách và phục vụ. Do cả thủ tục nền phục vụ và thủ tục nền khách được sinh ra bởi cùng một file giao diện cho nên chúng phù hợp cú pháp với nhau. Mã ghi nhận một phục vụ được chứa trong nền phục vụ như là phần khởi động của QT phục vụ. Lời gọi hệ thống liên kết một khách tới phục vụ này được cho trong QT khách. Lời gọi hệ thống được thực hiện trong lần đầu tiên khi khách có lời gọi RPC tới phục vụ.

Dù tương tự về khái niệm và cú pháp, RPC vẫn khác với lời gọi thủ tục cục bộ do hạn chế mạng và lỗi. Hai vấn đề cơ bản, loại bỏ và lỗi, cần được định vị đối với thi hành RPC. Loại bỏ là các trạng thái khác thường xảy ra khi thực hiện các thủ tục nền và thủ tục phục vụ. Lỗi là vấn đề gây ra bởi sự đổ vỡ của khách, phục vụ hoặc mạng TT.

Kiểm soát loại bỏ

Loại bỏ trong thủ tục phục vụ, chẳng hạn như overflow/underflow hoặc vi phạm bảo vệ trong khi thực hiện thủ tục bắt buộc phải được kết xuất tới khách. Theo một nghĩa khác, một khách hoặc một thủ tục nền của nó có thể dừng việc thực hiện một thủ tục phục vụ. Những câu hỏi cơ bản là:

-Bằng cách nào phục vụ kết xuất thông tin trạng thái tới khách ?

-Bằng cách nào khách gửi thông tin điều khiển tới phục vụ ?

Các bài toán này được giải quyết dễ dàng theo quy ước trong lời gọi thủ tục cục bộ nhờ sử dụng biến toàn cục chia xẻ và tín hiệu. Ví dụ, trong UNIX biến toàn cục errno được dùng để kết xuất trạng thái sai sót, và các tín hiệu (hoặc ngắt) có thể được dùng để thực hiện điều khiển đối với các QT khác.

Trên mạng máy tính, không thể sử dụng cả biến chia xẻ lẫn ngắt trực tiếp. Trao đổi điều khiển và trạng thái bắt buộc phải nhờ cậy vào kênh dữ liệu. Tình huống này tương tự vấn đề trong TT dữ liệu khi kênh tín hiệu buộc phải hoặc tìm vị trí của mình trong kênh dữ liệu chuẩn (băng tín hiệu-lõm) hoặc sử dụng một kênh riêng (băng tín hiệu-lồi). Nhiều dịch vụ giao vận cung cấp lựa chọn dữ liệu cờ như điểm lồi của băng thông tin trong dịch vụ nguyên thủy gửi. Cũng có thể dùng kênh riêng (kết nối socket) để khử bỏ đòi hỏi nhận biết tín hiệu từ dữ liệu chuẩn. Tiếp cận như vậy là mềm dẻo hơn đối với RPC do đa số thi hành hệ thống sẵn có giả thiết cổng bội đối với mỗi QT (với mục đích tương tự, chẳng hạn như TT tới nhân). Trong những trường hợp khác, việc gửi và nhận thông tin điều khiển và trạng thái được thi hành như một phần của hỗ trợ thư viện nền và cần phải trong suốt tới QT khách.

Kiểm soát lỗi

Khả năng lỗi xảy ra từ lời gọi thủ tục từ xa là khác với lời gọi thủ tục cục bộ. Việc kiểm soát lỗi để che dấu và trong suốt cho người dùng RPC là một công việc nặng nề. Lỗi xảy ra khi khách không thể định vị được phục vụ tại thời điểm khởi tạo lời gọi RPC. Điều đó xảy ra do phục vụ không tồn tại hoặc phục vụ bị đổ vỡ. Lỗi cũng xảy ra khi khách đang dùng một chương trình hoặc số hiệu phiên bản lỗi thời. Vấn đề này tương tự với loại bỏ hơn là lỗi và có thể được kết xuất như loại bỏ. Mỗi khi phục vụ được định vị và TĐ hỏi đã được gửi tới phục vụ, TĐ có thể bị trễ hoặc mất. Tương tự, TĐ đáp có thể bị trễ hoặc mất. Việc mất TĐ được phát hiện do thời gian quá hạn hoặc không có lời đáp từ phục vụ. TĐ bị trễ hoặc mất có thể được truyền lại.

-Sự truyền lại câu hỏi (từ khách) lại là nguyên nhân của kiểu bài toán khác. Nếu câu hỏi không mất mà đơn thuần chỉ là bị làm chậm, thì phục vụ nhận được hai câu hỏi từ phía khách trong khi mong đợi chỉ một câu hỏi đến đó. Một giải pháp cho vấn đề này là tạo ra tính bất biến của câu hỏi theo nghĩa câu hỏi được thực hiện với số lần bất kỳ đều nhận cùng một hiệu quả. Ví dụ hệ thống file NFS cung cấp chỉ một dịch vụ bất biến (ví dụ, đọc khối, ghi giá trị vào khối, song không gắn một khối vào một file). Không phải mọi dịch vụ đều có tính bất biến (chẳng hạn như phục vụ khóa). Trong trường hợp này, khách gắn một số hiệu dãy vào mỗi câu hỏi để cho phục vụ có thể phát hiện ra sự đúp hoặc lỗi thời của TĐ hỏi. Nếu phục vụ nhận được sự đúp, nó truyền lại kết quả được kết xuất từ yêu cầu đầu tiên. Chú ý rằng, phục vụ cần giữ lại vết của số hiệu dãy của yêu cầu cuối cùng của mỗi khách và kết quả sinh ra đối với yêu cầu đó. Số hiệu dãy đối với lời gọi RPC khách là không thật sự cần thiết nếu RPC được chạy theo dịch vụ giao vận TCP hướng kết nối tin cậy do dịch vụ đã sắp xếp TĐ và loại trừ sự đúp.

Thi hành điển hình một RPC không dùng đến số hiệu dãy. Phục vụ không chú ý đến khách là ai, có bao nhiêu khách tạo ra câu hỏi như thể là nó đã có cách phát hiện sự đúp. Ví dụ, một giao thức UDP thi hành RPC trên máy Sun dùng một số ngẫu nhiên duy nhất xid, được gọi là số hiệu giao dịch hoặc nonce (số được dùng chỉ một lần) cho mỗi TĐ hỏi (giao dịch). xid được dùng nhằm liên kết hỏi và đáp. Phục vụ RPC duy trì một bảng cache được chỉ số hóa theo chương trình và số hiệu phiên bản, số hiệu thủ tục, địa chỉ UDP khách và xid cho mỗi giao dịch hoàn thiện. Kết quả của lần gọi trước đây được trả cho người gọi nếu câu hỏi mới đã có sẵn trên cache. Nếu TĐ đáp là đúp trong bất kỳ lý do nào thì xid được khách dùng để loại bỏ sự đúp hoặc thậm chí cả lời đáp sai sót.

-Đỗ vỡ phục vụ là bài toán nguy kịch hơn. Ngay cả khi kết nối TCP tin cậy, thì câu hỏi đúp cũng có thể được phân phát tới phục vụ. Vấn đề này có thể xuất hiện nếu khách đã chờ lời đáp cho câu hỏi của nó đã quá hạn (chẳng hạn, vượt quá hạn TCP). Khách cố gắng thiết lập lại kết nối. Khi kết nối được thiết lập lại (có thể sau khi phục vụ khôi phục lại từ lỗi), khách truyền lại lời hỏi của mình. Chú ý rằng, lỗi của kết nối TCP không có nghĩa là phục vụ bị đỗ vỡ vì rằng trong vài trường hợp kết nối TCP bị đứt do vấn đề mạng, tràn vùng đệm ... Có chăng khi phục vụ bị lỗi, dịch vụ có thể được thực hiện hoặc không. Nếu kết nối TCP bị đứt nhưng phục vụ không bị đổ vỡ, bảng cache được kiểm tra để xác định yêu cầu có đúp hay không. Nếu phục vụ bị đổ vỡ, bảng cache bị mất. Trong trường hợp này, phục vụ có thể chọn đề xuất một loại bỏ tại QT khách và QT khách hoặc chờ cho phục vụ khôi phục lại hoăc từ bỏ ngay lập tức. Từ đó dẫn đến ba giả thiết khả năng cho ngữ nghĩa lời gọi RPC khi hiện diện lỗi:

-phục vụ đề xuất một loại bỏ và khách thử lại thao tác khi phục vụ hồi phục. Do thao tác sẽ được thi hành ít nhất một lần thì ít nhất phải có một lần ngữ nghĩa. Ngữ nghĩa này được thừa nhận cho thao tác bất biến.

-phục vụ đề xuất một loại bỏ và khách từ bỏ ngay lập tức. Do thao tác yêu cầu có thể đã được thực hiện bởi phục vụ trước khi bị đổ vỡ, tồn tại ít nhất một ngữ nghĩa.

-phục vụ không kết xuất lỗi nào cả, và khách gửi lại yêu cầu của nó cho đến khi nó được đáp hoặc từ bỏ. Điều này cũng có thể ngữ nghĩa do thao tác có thể đã được thực hiện số lượng lần bất kỳ (bao gồm cả không lần nào).

Đương nhiên, ngữ nghĩa RPC mong muốn nhất là một lần chính xác. Khó khăn khi hoàn thành một lần chính xác mà không cần đòi hỏi sự cố gắng. Do vấn đề ở chỗ bị mất bảng cache, giải pháp là ngữ nghĩa ít nhất một lần và chặt đoạn bảng cache lên bộ nhớ ngoài. Khi phục vụ được hồi phục, nó tải lại bảng cache từ các đoạn của nó. Tuy nhiên, thao tác thích hợp mỗi dịch vụ bắt buộc được thực hiện như một giao dịch tại phục vụ. Điều này đòi hỏi quá nhiều chi phí đối với nhiều ứng dụng.

-Cuối cùng, nếu QT khách đỗ vỡ (hoặc kết thúc vội vã) trước khi phục vụ hoàn thiện yêu cầu của khách, phục vụ có một tính toán orphan (đơn độc) và đáp của nó là không được phân phát. Không có cách dễ dàng để phục vụ kiểm tra sự biến mất của khách ngoại trừ việc dùng quá hạn hoặc chờ khách lỗi để reboot và loan báo sự hiện diện mới của nó. Tính toán đơn độc tiêu thụ các tài nguyên phục vụ (không gian bộ nhớ, khoá) và cũng có thể làm lộn xộn khách với câu đáp không có giá trị trong kết nối trước. Tính toán đơn độc có thể bị loại trừ theo các cách sau đây:

-Bằng khách: Nhờ vào việc reboot khách lỗi, khách đó làm sạch một cách rõ ràng các tính toán đơn độc trước đây. Đòi hỏi khách nhận thức được hoạt động của lời gọi thủ tục chưa kết thúc trước đây của nó và năng lực định vị các lời gọi đó.

-Bằng phục vụ: phục vụ thỉnh thoảng thử định vị chủ nhân của các thao tác từ xa của nó và bỏ đi những thao tác không tìm thấy chủ nhân. Giải pháp này đòi hỏi sự hoán vị vai trò của khách và phục vụ, phức tạp hóa một thiết kế đơn giản khác.

-Bằng sự kết thúc: Mỗi thao tác được tương ứng với một thời gian sống cực đại. Một thao tác bị loại bỏ khi nó đạt tới thời gian kết thúc của nó (ngoài trừ khách yêu cầu thêm thời gian một cách rõ ràng).

Bảo mật là vô cùng quan trọng đối với RPC bởi hai lý do:

-RPC là hình thức thực hiện từ xa cho phép chương trình hoặc lệnh được thực hiện tại một hệ thống khác. Nó là phương tiện đầy sức mạnh thi hành hệ thống và các ứng dụng phân tán. Tuy nhiên, RPC lại là một nguồn gốc làm cho hệ thống dễ bị xâm phạm khi người dùng không thân thiện sử dụng RPC để tấn công từ xa.

-RPC đã trở thành nền tảng của tính toán Client/Server. Tất cả các đặc điểm an toàn của hệ thống máy tính sẽ được xây dựng dựa trên an toàn RPC.

RPC dựa trên trao đổi TĐ hỏi/đáp giữa khách và phục vụ. Các vấn đề an toàn nguyên thủy là tính xác thực của QT khách và QT phục vụ, tính xác thực và bí mật của TĐ, và tính xác thực điều khiển truy nhập từ khách tới phục vụ. Vấn đề an toàn máy tính phân tán tổng thể được trình bày ở chương sau. Tại đây trình bày các khái niệm thích hợp về tính xác thực lưu tâm tới RPC. Một giao thức xác thực cho RPC cần được thiết lập như sau:

-Xác thực lẫn nhau: Định danh của khách và phục vụ cần được kiểm tra. TĐ hỏi thực sự được sinh ra từ khách và được mong đợi tại phục vụ. TĐ đáp thực sự sinh ra bởi phục vụ và được mong đợi tại khách. Tính xác thực bắt buộc phải được đảm bảo đối với TĐ và đối với các QT TT.

-Tính toàn vẹn, tính tin cậy và tính nguyên bản của TĐ: TĐ hỏi/đáp không bị xáo trộn (tính toàn vẹn), nội dung của nó không bị lộ (tính tin cậy) và một TĐ không xuất hiện quá một lần (tính nguyên bản).

Thiết kế giao thức xác thực là nội dung rất phức tạp. Tính phức tạp của giao thức phụ thuộc vào mục tiêu an toàn cao đến đâu, những tấn công thích hợp nào được đoán nhận, và một số hạn chế cố hữu của hệ thống. Hệ thống an toàn cao đòi hỏi nhiều biến đổi cơ sở trong HĐH. Giải pháp thích hợp hơn mong muốn có được những đặc điểm an toàn dễ dàng bổ sung vào HĐH đang tồn tại. Nội dung dưới đây về RPC an toàn của Sun là ví dụ về tính an toàn có thể kết hợp chặt chẽ dễ dàng vào một HĐH đang tồn tại.

RPC an toàn Sun được xây dựng trong hệ thống RPC cơ sở của Sun. Giả thiết tồn tại dịch vụ thông tin mạng (NIS) tin cậy được đặt tại một phục vụ xác thực được chia xẻ trong hầu hết các giao thức xác thực. Tuy nhiên, NIS trong RPC xác thực Sun không thực hiện chức năng xác thực. Nó đơn giản được đặt ra để giữ một CSDL chứa các bản ghi về tên mạng của người dùng và khóa công khai và khóa bí mật. Các khóa này không phải là mã hóa/giải mã như chúng thông thường được dùng trong mật mã. Thay vào đó, chúng được dùng để sinh ra một khóa phiên mật mã đúng cho TT. Khóa công khai là thông tin công khai, còn khóa bí mật được tạo bởi mã hóa chúng khi dùng thuật toán mã hóa DES (Data Encryption System) với mật khẩu người dùng như một khóa mật mã. Khi người dùng login máy trạm, RPC an toàn chạy, chương trình login tiếp xúc với NIS để nhận bản ghi khóa của người dùng. Sau đó chương trình login nhắc người dùng nhập mật khẩu, sử dụng mật khẩu để giải mã khóa bí mật đã được mã hóa, và loại bỏ mật khẩu ngay lập tức sau đấy. Pha login người dùng được chỉ ra trong hình 4.14. Chú ý rằng mật khẩu người dùng không truyền trên mạng.

Sau khi login thành công, QT khách, làm việc nhân danh người dùng, thiết lập một phiên TT với QT phục vụ như sau. Chương trình login đặt khóa bí mật của khách vào vùng nhớ phục vụ khóa. Thủ tục giống như ở phía khách cũng diễn ra ở phía phục vụ. QT phục vụ khóa tại khách và phục vụ chịu trách nhiệm sinh ra khóa phiên chung giữa khách và phục vụ. Điều đó được thực hiện bằng việc trao đổi khóa đã mũ hóa. Đầu tiên, một cặp khóa riêng và khóa công khai được gán (hoặc ghi nhận) đối với mọi khách {C1, C2, ..., Cp}và mọi phục vụ {S1, S2, ..., Sp} trong hệ thống. Các khóa này được sinh theo con đường sau đây:

 Cs và Ss là các số ngẫu nhiên 128 bit,

 Cp = αCs mod M và Sp = αSs mod M , trong đó α và M là hai hằng số đã biết.

Mặc dù khóa công khai thu được từ khoá bí mật song thao tác tìm ngược theo logarith rời rạc được đánh giá là tính toán rất tốn kém. Người dùng không thể dễ dàng suy luận được khóa bí mật từ khóa công khai tương ứng của nó, thậm chí trong trường hợp khi đã biết thuật toán. Tại phía khách, khóa phiên SKCS đươc tính qua khóa bí mật khách Cs và khóa công khai phục vụ Sp như sau:

SKCS = SpCs = (αSp)Cs = αSp°Cs

Hoàn toàn đối xứng và độc lập, phục vụ khóa tính khóa phiên SKSC nhờ khóa bí mật phục vụ Ss và khóa công khai khách Cp như sau:

SKSC = CpSp = (αCs)Sp = αCs°Sp

Có thể thấy rằng, SKCS = SKSC = SK. Khoá phiên được tính toán theo MOD M (để rõ ràng bỏ qua toán tử mod). Mỗi khi khóa phiên được sinh, khóa bí mật được xoá khỏi vùng nhớ của dịch vụ khóa. Khóa phiên theo thỏa thuận thiết lập xác thực lẫn nhau của khách và phục vụ do nó chỉ nhận được từ khóa bí mật trình diễn định danh thực sự của bộ đôi TT.

Mỗi TĐ RPC được xác thực bởi khóa kết hợp CK là một số ngẫu nhiên 56-bit được khách sinh ra và được truyền tới phục vụ nhờ khóa phiên. Khóa kết hợp được giữ trong phục vụ khóa và được dùng trong toàn bộ phiên giữa khách và phục vụ. Khóa phiên được dùng sơ bộ trong mạng còn khoá kết hợp là được chuyển giao. Khả năng bị làm hại là tối thiểu. Lý do sử dụng khóa kết hợp đối với TĐ RPC kế tiếp là nó không bắt nguồn từ khóa bí mật và bởi vậy, được lưu lại để dùng cho giai đoạn dài. Nó khác nhau trong mỗi phiên.

TĐ RPC có thể chứa thêm nhiều thông tin, bao gồm tem-thời gian, (số hiệu) lượt và một tóm tắt TĐ. Tem-thời gian được dùng để kiểm tra kết thúc TĐ. Lượt được dùng để đảm bảo không xảy ra việc lặp TĐ. Tóm tắt TĐ là một giá trị băm của dữ liệu TĐ được dùng để phát hiện bất kỳ can thiệp nào vào TĐ. Mã hóa thông tin này bằng khóa kết hợp cung cấp cả tính xác thực lẫn tính an toàn của TĐ.

Thi hành RPC của Sun là rất đơn giản. Nó dùng NIS tồn tại thay cho một phục vụ xác thực riêng biệt. Thông tin bí mật được chuyển tới mạng hoặc bảo quản tại máy khách và máy phục vụ được giữ ở mức độ tối thiểu.