위키원
"원격 프로시저 호출"의 두 판 사이의 차이
잔글 |
|||
| (같은 사용자의 중간 판 4개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''RPC''' | + | '''원격 프로시저 호출'''<!--원격프로시저호출, 원격프로시저 호출, 원격 프로시저호출--> 또는 '''RPC'''(Remote Procedure Call)는 별도의 원격제어를 위한 코딩 없이 다른 주소 공간에서 [[함수]]나 [[프로시저]]를 실행할 수 있게 하는 프로세스간 통신 기술이다. '''리모트 프로시저 콜'''이라고도 한다. 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.<ref name>블로그 쥔장, 〈[http://www.simpleisbest.net/archive/2005/06/13/159.aspx RPC에 대하여... (1) : RPC 가 사용하는 TCP/IP 포트는 ?]〉, 《SimpleIsBest.NET》, 2005-06-13</ref> |
| − | Remote Procedure Call | ||
| − | <ref> | ||
| − | |||
==개요== | ==개요== | ||
| − | + | [[객체지향]]의 원칙을 사용하는 소프트웨어의 경우 원격 프로시저 호출을 '''원격호출'''<!--원격 호출-->(remote invocation) 또는 '''원격 메소드 호출'''(remote method invocation)이라고 일컫는다. 가끔 ONC RPC와 DCE/RPC와 같은 비호환 대상을 수행하기 위해 쓰이는 다른 수많은 기술이 있다.<ref name="위키백과">〈[https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C 원격 프로시저 호출]〉, 《위키백과》</ref> | |
| − | |||
| − | |||
| − | |||
| − | 가끔 ONC RPC와 DCE/RPC와 같은 비호환 대상을 수행하기 위해 쓰이는 다른 수많은 기술이 있다. | ||
| − | <ref> | ||
==특징== | ==특징== | ||
| − | |||
RPC 프로그래밍 [[인터페이스]]는 다양한 계층이 있다. 그들의 범위는 라이브러리 함수들을 호출하는 것과 같은 방법으로 사용자들이 시스템이 제공하는 RPC 함수들을 호출하는 최상위 계층으로부터, RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층까지 있다. | RPC 프로그래밍 [[인터페이스]]는 다양한 계층이 있다. 그들의 범위는 라이브러리 함수들을 호출하는 것과 같은 방법으로 사용자들이 시스템이 제공하는 RPC 함수들을 호출하는 최상위 계층으로부터, RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층까지 있다. | ||
| 24번째 줄: | 15번째 줄: | ||
그러나, 이러한 접근 방식의 결점은 rpcgen이 생성한 클라이언트 서버프로그램에 의하여 사용되는 네트워크 트랜스포트의 어떤 자세한 속성들에 대하여 제어하기 어렵다는 것이다. 또한 이러한 클라이언트 서버는 [[XDR]] 함수들에 의하여 사용되는 동적 메모리를 관리할 수 없다. | 그러나, 이러한 접근 방식의 결점은 rpcgen이 생성한 클라이언트 서버프로그램에 의하여 사용되는 네트워크 트랜스포트의 어떤 자세한 속성들에 대하여 제어하기 어렵다는 것이다. 또한 이러한 클라이언트 서버는 [[XDR]] 함수들에 의하여 사용되는 동적 메모리를 관리할 수 없다. | ||
| − | RPC 프로그래밍 인터페이스의 최하위 계층은 RPC 클라이언트와 서버 프로그램들을 생성하기 위하여 RPC API들을 생성하는 것이다. 이것의 장점은 사용자들이 프로세스에 의하여 사용되는 네트워크 [[트랜스포트]]와 XDR 함수에 있는 동적 메모리 관리를 직접 제어할 수 있다는 것이다. 그러나, 이는 사용자 부분에서의 더 많은 프로그래밍 노력이 필요하게 된다 | + | RPC 프로그래밍 인터페이스의 최하위 계층은 RPC 클라이언트와 서버 프로그램들을 생성하기 위하여 RPC API들을 생성하는 것이다. 이것의 장점은 사용자들이 프로세스에 의하여 사용되는 네트워크 [[트랜스포트]]와 XDR 함수에 있는 동적 메모리 관리를 직접 제어할 수 있다는 것이다. 그러나, 이는 사용자 부분에서의 더 많은 프로그래밍 노력이 필요하게 된다.<ref name="위키백과"></ref> |
| − | <ref> | ||
===장점=== | ===장점=== | ||
| − | 비즈니스 로직에 집중할 수 있다. | + | * 비즈니스 로직에 집중할 수 있다. |
| − | 다양한 언어를 가진 환경에서 쉽게 확장할 수 있다. | + | * 다양한 언어를 가진 환경에서 쉽게 확장할 수 있다. |
| − | 쉽게 인터페이스 협업이 가능하다. | + | * 쉽게 인터페이스 협업이 가능하다. |
===단점=== | ===단점=== | ||
| − | 새로운 학습 비용이 든다. | + | * 새로운 학습 비용이 든다. |
| − | 사람의 눈으로 읽기 힘들다. | + | * 사람의 눈으로 읽기 힘들다.<ref name="Que">Que Sera Sera, 〈[https://nesoy.github.io/articles/2019-07/RPC RPC란?]〉, 《Nesoy Blog》, 2019-07-09</ref> |
| − | |||
| − | <ref> | ||
===목표=== | ===목표=== | ||
| − | 클라이언트 - 서버간의 커뮤니케이션에 필요한 상세한 정보는 최대한 감추고클라이언트는 일반 메소드를 호출하는 것처럼 호출하면 된다. | + | * 클라이언트 - 서버간의 커뮤니케이션에 필요한 상세한 정보는 최대한 감추고클라이언트는 일반 메소드를 호출하는 것처럼 호출하면 된다. |
| − | 서버도 마찬가지로 일반 메소드를 다루는 것처럼 만드는 것이다. | + | * 서버도 마찬가지로 일반 메소드를 다루는 것처럼 만드는 것이다.<ref name="Que"></ref> |
| − | <ref> | ||
==이용== | ==이용== | ||
| − | + | RPC 모델의 가장 보편적인 모델과 수행 방법에는 개방 소프트웨어 재단의 분산 컴퓨팅 환경(DCE; Distributed Computing Environment)이다. [[IEEE]]는 1991년 11월에 ISO Remote Procedure Call Specification, ISO/IEC CD 11578 N6561, ISO/IEC에서 RPC를 정의하였다. RPC는 OSI 참조 모델 안의 전달계층과 응용계층을 연결한다. RPC는 네트워크 내에 분산되어 있는 여러 프로그램들을 포함하는 응용 프로그램 개발을 쉽게 한다. 클라이언트/서버 통신을 위한 대체방안으로는 메시지 큐잉과 IBM의 [[APPC]] (선진 프로그램 간 통신) 등이 있다. | |
RPC는 동일하거나 다른 컴퓨터 프로세스의 함수를 호출하는 데 사용되는 프로토콜로서 [[소켓]](socket)을 이용하여도 이러한 기능을 수행할 수 있지만, RPC는 다양한 기능을 제공하여 좀 더 유연하게 다른 컴퓨터와의 통신을 할 수 있다. | RPC는 동일하거나 다른 컴퓨터 프로세스의 함수를 호출하는 데 사용되는 프로토콜로서 [[소켓]](socket)을 이용하여도 이러한 기능을 수행할 수 있지만, RPC는 다양한 기능을 제공하여 좀 더 유연하게 다른 컴퓨터와의 통신을 할 수 있다. | ||
| + | |||
RPC는 이를테면 다음과 같은 경우에 사용된다. | RPC는 이를테면 다음과 같은 경우에 사용된다. | ||
| + | * 윈도우 인증 | ||
| + | * MSMQ | ||
| + | * 익스체인지 서버 | ||
| + | * SMS 서버 | ||
| + | * DCOM | ||
| + | * DTC | ||
| − | + | RPC는 원격 호출에 사용되는 프로토콜이지만 세부적인 네트워크 전송시는 하부 프로토콜 중 하나를 사용하도록 설계되었다.<ref name="위키백과"></ref> | |
| − | + | * [[TCP/IP]] | |
| − | + | * IPX | |
| − | * | + | * Named Pipe |
| − | * | ||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==활용== | ==활용== | ||
| − | + | ===프로그래밍=== | |
# Client | # Client | ||
| − | z = function(x, y) | + | z = function(x, y) |
# Server | # Server | ||
| − | function(x, y) { | + | function(x, y) { |
| − | compute x, y | + | compute x, y |
| − | return z | + | return z |
| − | } | + | } |
| − | RPC는 이 정도의 수준으로 | + | RPC는 이 정도의 수준으로 프로그래밍하기를 원한다. 이를 통해 초보자 프로그래머도 원격 함수를 쉽게 사용할 수 있다. |
| − | 이를 통해 초보자 프로그래머도 원격 함수를 쉽게 사용할 수 있다. | ||
===진행방법=== | ===진행방법=== | ||
| − | '''Caller / Callee''' | + | * '''Caller / Callee''' : 사용자(Client / Server)가 필요한 비즈니스 로직을 작성하는 Layer IDL(interface definition language)로 작성한다. |
| − | + | * '''Stub''' : Stub Compiler가 IDL 파일을 읽어 원하는 Language로 생성하고 Parameter Object를 Message로 marshalling/unmarshalling하는 Layer이다. | |
| − | + | * '''RPC RunTime''' : Server와 Client를 Binding하는 Layer 커뮤니케이션 중 발생한 에러 처리도 진행한다 | |
| − | '''Stub''' | ||
| − | |||
| − | |||
| − | * | ||
| − | |||
| − | |||
===RPC 클라이언트 연결=== | ===RPC 클라이언트 연결=== | ||
| − | + | ; Static Binding | |
| − | *서버 주소 Hard Coding | + | * 서버 주소 Hard Coding |
| − | *간단하고 효율적이다 | + | * 간단하고 효율적이다. |
| − | *서버 주소 변경에 약하다. | + | * 서버 주소 변경에 약하다. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ; Dynamic Binding | ||
| + | * 주소 변경에 매우 유동적이다. | ||
| + | * 여분의 서버를 둬야 하는 단점이 있다.<ref name="Que"></ref> | ||
{{각주}} | {{각주}} | ||
| + | ==참고자료== | ||
| + | * 〈[https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C 원격 프로시저 호출]〉, 《위키백과》 | ||
| + | * 블로그 쥔장, 〈[http://www.simpleisbest.net/archive/2005/06/13/159.aspx RPC에 대하여... (1) : RPC 가 사용하는 TCP/IP 포트는 ?]〉, 《SimpleIsBest.NET》, 2005-06-13 | ||
| + | * 남보은, 〈[http://www.ccreview.co.kr/news/articleView.html?idxno=54870 보은농협 RPC 통합 전망]〉, 《충청리뷰》, 2009-04-17 | ||
| + | * Que Sera Sera, 〈[https://nesoy.github.io/articles/2019-07/RPC RPC란?]〉, 《Nesoy Blog》, 2019-07-09 | ||
| + | == 같이 보기 == | ||
| + | * [[프로토콜]] | ||
| + | * [[프로시저]] | ||
| − | + | {{인터넷|검토 필요}} | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
2019년 8월 11일 (일) 05:27 기준 최신판
원격 프로시저 호출 또는 RPC(Remote Procedure Call)는 별도의 원격제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스간 통신 기술이다. 리모트 프로시저 콜이라고도 한다. 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.[1]
개요[편집]
객체지향의 원칙을 사용하는 소프트웨어의 경우 원격 프로시저 호출을 원격호출(remote invocation) 또는 원격 메소드 호출(remote method invocation)이라고 일컫는다. 가끔 ONC RPC와 DCE/RPC와 같은 비호환 대상을 수행하기 위해 쓰이는 다른 수많은 기술이 있다.[2]
특징[편집]
RPC 프로그래밍 인터페이스는 다양한 계층이 있다. 그들의 범위는 라이브러리 함수들을 호출하는 것과 같은 방법으로 사용자들이 시스템이 제공하는 RPC 함수들을 호출하는 최상위 계층으로부터, RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층까지 있다.
최상위 계층에는 원격 시스템의 정보를 수집하기 위하여 사용자들이 직접호출할 수 있는 시스템이 제공하는 RPC 함수들이 있다. 이 함수들은 일반적으로 라이브러리 함수처럼 사용될 수 있다. 다만 그들을 사용하기 위해서는 RPC 라이브러리 함수의 목적 코드를 포함하는 등의 특별한 설정이 필요하다.
RPC 라이브러리 함수들의 장점은 쉽게 사용할 수 있고 프로그래밍 부담이 적다는 것이다. 그러나, 시스템에서 정의된 RPC 라이브러리 함수들은 많지 않다. 그러므로, 이 함수들을 통한 응용에는 한계가 있다.
RPC 프로그래밍의 두 번째 계층에서는 RPC 클라이언트와 서버의 스터브(stub) 루틴을 자동적으로 생성하기 위하여 rpcgen 컴파일러를 사용한다. 사용자들은 단지 클라이언트와 서버 프로그램을 생성하기 위한 클라이언트의 main 함수와 서버의 RPC 함수들만 작성한다. 또한 rpcgen 컴파일러를 통해 클라이언트와 서버 사이에 데이터를 전송하기 위하여사용자가 정의한 어떠한 데이터 유형이든지 XDR 형식으로 변환하는 XDR 함수들을 생성할 수 있다. rpcgen 컴파일러를 사용하여 얻는 장점은 사용자들이 RPC 함수들과 클라이언트의 main함수를 작성하는 데 주력할 수 있다는 것이다. 즉, 하위 계층의 RPC API들에 대해 알 필요가 없다. 이는 프로그래밍 노력을 절약하고 오류 발생 가능성을 줄여준다.
그러나, 이러한 접근 방식의 결점은 rpcgen이 생성한 클라이언트 서버프로그램에 의하여 사용되는 네트워크 트랜스포트의 어떤 자세한 속성들에 대하여 제어하기 어렵다는 것이다. 또한 이러한 클라이언트 서버는 XDR 함수들에 의하여 사용되는 동적 메모리를 관리할 수 없다.
RPC 프로그래밍 인터페이스의 최하위 계층은 RPC 클라이언트와 서버 프로그램들을 생성하기 위하여 RPC API들을 생성하는 것이다. 이것의 장점은 사용자들이 프로세스에 의하여 사용되는 네트워크 트랜스포트와 XDR 함수에 있는 동적 메모리 관리를 직접 제어할 수 있다는 것이다. 그러나, 이는 사용자 부분에서의 더 많은 프로그래밍 노력이 필요하게 된다.[2]
장점[편집]
- 비즈니스 로직에 집중할 수 있다.
- 다양한 언어를 가진 환경에서 쉽게 확장할 수 있다.
- 쉽게 인터페이스 협업이 가능하다.
단점[편집]
- 새로운 학습 비용이 든다.
- 사람의 눈으로 읽기 힘들다.[3]
목표[편집]
- 클라이언트 - 서버간의 커뮤니케이션에 필요한 상세한 정보는 최대한 감추고클라이언트는 일반 메소드를 호출하는 것처럼 호출하면 된다.
- 서버도 마찬가지로 일반 메소드를 다루는 것처럼 만드는 것이다.[3]
이용[편집]
RPC 모델의 가장 보편적인 모델과 수행 방법에는 개방 소프트웨어 재단의 분산 컴퓨팅 환경(DCE; Distributed Computing Environment)이다. IEEE는 1991년 11월에 ISO Remote Procedure Call Specification, ISO/IEC CD 11578 N6561, ISO/IEC에서 RPC를 정의하였다. RPC는 OSI 참조 모델 안의 전달계층과 응용계층을 연결한다. RPC는 네트워크 내에 분산되어 있는 여러 프로그램들을 포함하는 응용 프로그램 개발을 쉽게 한다. 클라이언트/서버 통신을 위한 대체방안으로는 메시지 큐잉과 IBM의 APPC (선진 프로그램 간 통신) 등이 있다.
RPC는 동일하거나 다른 컴퓨터 프로세스의 함수를 호출하는 데 사용되는 프로토콜로서 소켓(socket)을 이용하여도 이러한 기능을 수행할 수 있지만, RPC는 다양한 기능을 제공하여 좀 더 유연하게 다른 컴퓨터와의 통신을 할 수 있다.
RPC는 이를테면 다음과 같은 경우에 사용된다.
- 윈도우 인증
- MSMQ
- 익스체인지 서버
- SMS 서버
- DCOM
- DTC
RPC는 원격 호출에 사용되는 프로토콜이지만 세부적인 네트워크 전송시는 하부 프로토콜 중 하나를 사용하도록 설계되었다.[2]
- TCP/IP
- IPX
- Named Pipe
활용[편집]
프로그래밍[편집]
- Client
z = function(x, y)
- Server
function(x, y) {
compute x, y
return z
}
RPC는 이 정도의 수준으로 프로그래밍하기를 원한다. 이를 통해 초보자 프로그래머도 원격 함수를 쉽게 사용할 수 있다.
진행방법[편집]
- Caller / Callee : 사용자(Client / Server)가 필요한 비즈니스 로직을 작성하는 Layer IDL(interface definition language)로 작성한다.
- Stub : Stub Compiler가 IDL 파일을 읽어 원하는 Language로 생성하고 Parameter Object를 Message로 marshalling/unmarshalling하는 Layer이다.
- RPC RunTime : Server와 Client를 Binding하는 Layer 커뮤니케이션 중 발생한 에러 처리도 진행한다
RPC 클라이언트 연결[편집]
- Static Binding
- 서버 주소 Hard Coding
- 간단하고 효율적이다.
- 서버 주소 변경에 약하다.
- Dynamic Binding
- 주소 변경에 매우 유동적이다.
- 여분의 서버를 둬야 하는 단점이 있다.[3]
각주[편집]
- ↑ 블로그 쥔장, 〈RPC에 대하여... (1) : RPC 가 사용하는 TCP/IP 포트는 ?〉, 《SimpleIsBest.NET》, 2005-06-13
- ↑ 2.0 2.1 2.2 〈원격 프로시저 호출〉, 《위키백과》
- ↑ 3.0 3.1 3.2 Que Sera Sera, 〈RPC란?〉, 《Nesoy Blog》, 2019-07-09
참고자료[편집]
- 〈원격 프로시저 호출〉, 《위키백과》
- 블로그 쥔장, 〈RPC에 대하여... (1) : RPC 가 사용하는 TCP/IP 포트는 ?〉, 《SimpleIsBest.NET》, 2005-06-13
- 남보은, 〈보은농협 RPC 통합 전망〉, 《충청리뷰》, 2009-04-17
- Que Sera Sera, 〈RPC란?〉, 《Nesoy Blog》, 2019-07-09
같이 보기[편집]
