RPCs는 전통적인 프로그램에 포함된 서브루틴을 호출하는 것과 같은 모습을 하고 있으나, 네트워크로 연결된 서버 사으이 원격 프로시저를 호출한다는 것이 큰 차이점이다. RPCs의 장점은 기존 개발자들에게 익숙하다는 것인데 네트워크나 OS가 복잡함을 숨기고 쉽게 네트워크 상에서의 통신 어플리케이션을 작성 할 수 있다.

RPCs는 클라이언트에서 입력 값을 실어 원격 서버에 있는 프로시저를 호출하게 되고 호출된 프로시저는 수행된 결과를 클라이언트 프로세스에게 전달하는 방법을 취하는데, 여기서 클라이언트 프로세스는 프로시저가 완전히 수행될 때까지 일시 정지 상태가 된다. 이것은 RPCs가 통신에 있어 동기적(synchronous) 방식을 취한다는 것과 RPC를 통한 C/S는 클라이언트와 서버가 단단히 결합되어 있음을 알 수 있다.

RPCs는 C/S 시스템 구축에 많은 기여를 했으며, 현재 대부분 시스템에서 사용하고 있는 기술이기도 하다. RPCs 구조를 사용하는 기술들이 생겨났는데, 예를들면 네트워크 파일 시스템(NFS)은 미들웨어 계층에서 RPC를 사용했고, 특히 OSF의 표준 미들웨어인 DCE는 통신 서비스로 RPC를 사용하여 RPC의 중요성을 한층 높였다. IDC(Interface Definition Language)을 통한 프로그래밍 모델은 DCE/RPC를 사용하는 Microsoft사의 DCOM과 ORB를 사용하는 OMG 표준 CORBA 등의 객체지향 미들웨어로 자연스럽게 이어지고 있다.

RPCs는 기업내 기간업무를 구축하는데 있어 중요한 역할을 한 TP-MONITOR인 IBM의 CICS6000, Trnsac의 ENCINA, BEA의 TUXEDO, TmaxSoft의 TMAX등이 어플리케이션간 통신 미들웨어로 사용되고 있으며, ERP(Enterprise Resource Plan)로 알려진 어플리케이션 패키지인 SAP사의 R/3는 원격 함수 호출(Remote Function Call) 형태의 기술이 사용되고 있다.

RPCs의 구조는 이해하기 쉽고, 개발하기에 용이함이 있지만, 현재의 C/S 시스템을 구축하기에는 몇 가지 문제점을 안고 있다. 즉, 클라이언트와 서버가 동기적으로 동작되기 때문에 클라이언트가 서버의 프로시저를 호출한 뒤에는 서버 프로세스가 완료될 때까지 클라이언트는 서버에 종속되어야 한다. 또한 RPC는 구조상 높은 속도의 네트워크 환경을 요구하는데, 그 이유는 RPC를 사용하여 C/S 통신을 할 때 네트워크 사이에는 많은 양의 작업이 이루어지기 때문이다.

그러나 앞으로 네트워크 속도가 빠르게 향상될 것으로 보아 기존의 RPCs에 기반하여 구축된 C/S 시스템은 별다른 문제가 없으리라 생각되며, DCE/RPC 등을 사용했을 경우 분산 객체인 CORBA나 DCOM등과의 연결 및 확장에는 아무런 문제가 없다.