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).