I. Kiến trúc của RPC:
RPC được thiết kế để cung cấp cho việc truyền tải thông tin
giữa client và server dễ dànghơn, bảo mật hơn, và thuận tiện hơn cho
việc đồng bộ hóa các luồn dữ liệu. Các hàm chứa trong RPC hỗ trợ cho
việc truy cập bất kỳ chương trình nào đòi hỏi phương pháp giao tiếp từ
client đến server. Hình bên dưới sẽ cho chúng ta thấy kiến trúc của RPC
Hình 1: Kiến trúc Remote Procedure Call
II. Các thành phần của RPC
Thành phần
|
Miêu tả
|
Client or server process
|
Chương trình hoặc dịch vụ trả lời từ yêu cầu của RPC
|
RPC stubs
|
Những hệ thống chương trình con được dùng bởi client hoặc server khởi động yêu cầu RPC.
|
Marshalling engine
(NDR20 hoặc NDR64)
|
Cung cấp một giao diện chung giữa RPC Client và RPC Server và được
chia làm 2 loại: NDR20 và NDR64. NDR20 được dùng cho hạ tầng 32 bits.
Trong khi đó NDR64 được tối ưu dùng cho hạ tầng 64 bits. Client và
Server sẽ thương lượng nên chọn NDR20 hay NRD64 để giao tiếp với nhau
|
Runtime application programming interface (API)
|
Cung cấp giao diện cho RPC tới Clients hoặc Servers. Thông thường,
RPC Clients và Servers sẽ gọi hàm API (giao diện lập trình ứng dụng) để
khởi tạo RPC và chuẩn bị cấu trúc dữ liệu sẽ được sử dụng để thực hiện
cuộc gọi RPC. Lớp API sẽ quyết định nếu yêu cầu RPC đến từ marshalling
engine hoặc trực tiếp từ client/server đến máy chủ nội bộ hoặc máy chủ
từ xa. Sau đó lớp API sẽ dẫn đường cho RPC đến Connection RPC, Datagram
RPC hoặc Local RPC Layers
|
Connection RPC protocol engine
|
Được sử dụng khi RPC yêu cầu giao thức kết nối. Lớp này sẽ chỉ định
sử dụng giao thức kết nối nếu RPC được gửi đi hoặc nhận được một kết
nối hướng tới RPC
|
Datagram RPC protocol engine
|
Được sử dụng khi RPC yêu cầu giao thức phi kết nối. Lớp này sẽ chỉ
định sử dụng giao thức phi kết nối nếu RPC được gửi đi hoặc nhận được
một phi kết nối tới RPC
|
Local RPC protocol engine
|
Được sử dụng khi Server và Client đặt trong cùng một host.
|
Registry
|
Được truy cập khi dịch vụ RPC đầu tiên được tải về. Các thành phần
trong registry sẽ chỉ định dãy port IP và tên thiết bị của các card mạng
để RPC có thể kết hợp chúng lại với nhau. Trừ khi API ép buộc RPC phải
dùng, Registry sẽ không được sử dụng trong hoạt động của RPC
|
Win32 APIs
(kernel32.dll, advapi32.dll, ntdll.dll)
|
Kernel32.dll là một file thư viện động 32 bits có trong Windows
NT. File này chịu trách nhiệm quản ly bộ nhớ, các hoạt động vào ra của
hệ thống
Advapi32.dll là file nâng cao của Windows 32 dựa trên giao diện lập
trình ứng dụng. File này hỗ trợ về bảo mật và gọi các registry
Ntdll.dll là file dll quản lý chức năng các file hệ thống của Windows NT
|
SSPI
(secur32.dll)
|
Cung cấp giao diện bảo mật cho RPC. File secur32.dll sẽ thương
lượng cách dùng cho việc chứng thực và mã hóa như: Kerberos, NTLM, hoặc
Secure Sockets Layer (SSL)
|
Endpoint Mapper (EPM)
(rpcss.dll)
|
Rpcss.dll (Remote procedure call subsystem) chủ yếu cung cấp cơ sở
hạ tầng cho các dịch vụ COM, nhưng một phần của Rpcss.dll được dùng cho
EPM. RPC Server liên lạc với EPM để nhận những điểm kết thúc động và
đăng ký những điểm này vào cơ sở dữ liệu của EPM. Rồi sau đó khi RPC
Clients muốn kết nối tới RPC Server, nó sẽ liên lạc với EPM để nhờ EPM
phân giải những điểm kết thúc..
|
Active Directory
|
Chỉ được sử dụng cho quá trình xử lý RPC client khi giao diện bảo
mật cụ thể như Kerberos hoặc Negotiate như nhà cung cấp bảo mật hoặc khi
Server dùng NTLM như nhà cung cấp bảo mật
Used in the RPC client process only when the security interface
specifies Kerberos or Negotiate as the security provider or when the
server uses NTLM as the security provider.
|
Network stack
|
Được sử dụng thông qua các yêu cầu và trả lời của RPC giữa Client và Server
|
Kernel
|
Được sử dụng thông qua các yêu cầu và trả lời của RPC giữa Client và Server
|
III. Quá trình xử lý và tương tác của RPC
Các thành phần của RPC sẽ giúp cho Clients xử lý dễ dàng bằng cách gọi hàm nằm trên một chương trình từ xa. Client và Server có một địa chỉ không gian riêng; điều đó có nghĩa là mỗi nguồn tài nguyên bộ nhớ của Client và Server cấp phát cho dữ liệu sẽ được dùng bởi hàm.
Hình 2: Quá trình xử lý của RPC
Quá trình xử lý của RPC bắt đầu từ phía Client. Ứng dụng từ phía Client sẽ gọi Client stub thay vì client phải viết code triển khai cho hàm đó. Các stub sẽ được biên soạn và liên kết với các ứng dụng từ phía client trong quá trình phát triển. Thay vì chứa mã code để thực hiện thủ tục gọi hàm từ xa, các code của stub sẽ yêu cầu truy vấn những tham số từ địa chỉ không gian của Client và sau đó chuyển chúng vào thư viện chạy thực của client. Sau đó, thư viện chạy thực của client sẽ biên dịch những tham số cần thiết vào định dạng chuẩn NDR (Network Data Representation) để chuyển giao cho Server.
Tiếp theo stub của Client sẽ gọi hàm trong thư viện chạy thực của
Client (rpcrt4.dll) để gửi các yêu cầu và thông số của nó đến server.
Nếu server được đặt trong cùng 1 host với client, thư viện chạy thực có
thể sử dụng các tính năng của Local RPC (LRPC) và thông qua các yêu cầu
của RPC tới Windows kernel cho việc truyền tải đến server. Nếu server
được đặt ở một host khác, thư viện chạy thực sẽ xác định một giao thức
truyền tải thích hợp và thông qua các yêu cầu của RPC đến Network Stack
cho việc truyền tải đến server. RPC có thể dùng các cơ chế trao đổi khác
(Interprocess Communications – IPC) như: Name pipes và Winsock để thực
hiện truyền tải đến server.
Bảng dưới đây sẽ liệt kê các giao thức mạng hỗ trợ RPC và các loại RPC kết nối với giao thức tương ứng được sử dụng
Protocol
|
RPC Type
|
Transmission Control Protocol (TCP)
|
Connection–oriented
|
Sequenced Packet Exchange (SPX)
|
Connection–oriented
|
Named Pipe
|
Connection–oriented
|
HTTP
|
Connection–oriented
|
User Datagram Protocol (UDP)
|
Connectionless
|
Cluster Datagram Protocol (CDP)
|
Connectionless
|
Khi Server nhận được yêu cầu của RPC(từ phía client trong nội bộ hoặc client từ xa), các hàm trong thư viện chạy thực RPC của Server chấp nhận các yêu cầu và gọi hàm xử lý Server Stub. Server stub sẽ truy vấn các tham số từ network buffer và chọn 1 trong 2 loại NDR20 hoặc NDR64 (trong NDR Marshalling Engines), sau đó chuyển đổi chúng từ định dạng truyền tải mạng sang định dạng theo yêu cầu bởi mày chủ. Sau đó các thủ tục từ xa sẽ được chạy, có khả năng xuất ra các tham số và trả về giá trị. Khi các thủ tục từ xa hoàn tất, một chuỗi các bước tương tự sẽ trả về dữ liệu cho Client
Các thủ tục từ xa trả dữ liệu của nó về cho Server Stub, chọn 1
trong 2 loại NDR20 hoặc NDR64 (trong NDR Marshalling Engines), chuyển
đổi những tham số được xuất ra thành định dạng truyền tải mạng đến
client và trả chúng vào thư việc chạy thực RPC của Server. Sau đó thư
viện chạy thực RPC của Server sẽ truyền tải dữ liệu đến máy tính của
Client bằng LRPC hoặc qua network.
Client hoàn tất các thủ tục bằng cách chấp nhận dữ liệu qua mạng và
trả dữ liệu về để gọi hàm. Thư viện chạy thực RPC của Client nhận được
thủ tục từ xa trả về giá trị, chuyển đổi giá trị từ NDR 20 hoặc NDR64 về
định dạng được dùng bởi Client, và trả chúng về client stub.
Đối với Microsoft Windows, thư viện chạy thực được chia làm 2 phần:
1. Import Library: liên kết với các ứng dụng
2. Thư viện chạy thực RPC( RPC Runtime Library): được triển khai như là DLL
IV. Các Ports dùng cho RPC
IV. Các Ports dùng cho RPC
Các chương trình RPC Server thông thường dùng những port động (đế tránh gây xung đột với các chương trình và các giao thức đã được đăng ký trong dãy Well-known TCP Ports). Bảng dưới đây sẽ liệt kệ các port dùng cho RPC
Service Name
|
UDP
|
TCP
|
HTTP
|
80, 443, 593
|
80, 443, 593
|
Named Pipes
|
445
|
445
|
RPC Endpoint Mapper
|
135
|
135
|
RPC Server Programs
|
<Dynamically assigned>
|
<Dynamically assigned>
|
V. Một ví dụ minh họa cho cơ chế RPC
Cuối tuần, bạn đang muốn đặt hai vé xem bộ phim “Love Stories” cùng
bạn gái tại rạp chiếu phim Galaxy, nhưng bạn đang không biết phải đặt
trước số ghế nào để có được tầm nhìn hợp lý nhất, bạn phải giải quyết
vấn đề này như thế nào? Đơn giản, bạn chỉ cần thực hiện như sau:
-
Bạn (client) gọi điện thoại tới phòng vé của Galaxy (server) với số điện thoại 135 (RPC Endpoint Mapper)
-
Bạn yêu cầu nhân viên phòng vé Galaxy (server) cho bạn biết số ghế (RPC Server Programs) có tầm nhìn hợp lý nhất, ví dụ số ghế D1 và D2 (dynamic port assigned)
-
Và bạn quyết định chọn số ghế D1 và D2 để cùng thưởng thức bộ phim yêu thích cùng bạn gái.