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
F Nhóm 1 Nhóm 2 C A G D E B
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à
Nền phục vụ TĐ tới Tham số tham số tới TĐ Giao vận Nhận Gửi Server Gọi hỏi Nhận đáp Nền Khách TĐ tới Tham số tham số tới TĐ Giao vận Nhận Gửi Khách Nhận đáp Gọi hỏi Hình 4.10. Dòng lời gọi từ xa
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. (adsbygoogle = window.adsbygoogle || []).push({});
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.12. Liên kết khách và phục vụ 3 4 port # thẻ khách 2 phục vụ Ghi ch−ơng trình, xêry, cổng Bộ ánh xạ cổng 1 máy phục vụ khách máy khách phục vụ th− viện địa chỉ máy phục vụ hoặc thẻ tới phục vụ ghi nhận dịch vụ creat (bộ liên kết hoặc bộ giao dịch) thẻ file ch−ơng trình khách th− viện thời gian chạy RPC ch−ơng trình phục vụ nền khách nền phục vụ biên dịch ch−ơng trình chính khách các thủ tục phục vụ đặc tả giao diện bộ sinh RPC biên dịch Hình 4.13. Sinh và dịch ch−ơng trình RPC
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ụ.