안녕하세요~ 이번 포스트는 RPC에 대해서 몇자 끄적여 보려구 합니다. RPC는 Windows 운영체제에서 매우 중요한 프로토콜입니다만, 웹 서비스다 뭐다 해서 점차로 관심을 잃어 가고 있습니다. 하지만 시스템 개발을 하다보면 이 RPC와 연관된 문제에 자주 부닥치곤 합니다. 기계적으로 암기하여 문제를 해결하는 것 보다는 원리를 알면 좋을 것 같아서 RPC에서 꼭 필요한 부분만을 설명해 봅니다. RPC 프로그래밍은 C/C++를 요구하는 만큼 좀 빡신 관계로 RPC 프로그래밍에 대한 이야기는 하지 않습니다.

About RPC... (1)

RPC 에 대해서 한두 번쯤은 들어보았을 것이다. 이 RPC는 한 때 인터넷을 마비시켰던 모 바이러스 덕에 더 유명해진 용어(?)이다. RPC란 Remote Procedure Call 의 약자로서 원격 컴퓨터나 프로세스에 존재하는 함수를 호출하는데 사용하는 프로토콜 이름이다. 원래 RPC는 DCE 란 회사에서 만들어낸 프로토콜로서 마이크로소프트는 Windows NT 시절부터 지금까지, 그리고 앞으로 나올 64비트 운영체제까지 RPC를 주요 프로토콜로서 사용할 것이다.

왜 뜬금 없이 RPC 냐고? 아마 이 RPC에 관련된 프로그램을 작성할 기회는 매우, 극히, 아주, 정말로, 적을 것이다. 하지만 RPC에 관심을 안가질 수 없는 이유가 있다. 이제부터 RPC에 대한 썰을 좀 풀어보도록 하겠다. 즐~

RPC는 동일 컴퓨터 상의 다른 프로세스나 다른 컴퓨터 상의 프로세스의 함수(C 수준의 함수, 프로시저나 함수나 그게 그거다... 따지지 말자...)를 호출하는데 사용하는 프로토콜이다. 달랑 소켓(socket) 만을 이용하여도 가능하지만 다양한 기능을 제공하는 RPC 덕에 손쉽게 다른 컴퓨터와의 통신을 마치 로컬 함수를 호출하듯이 할 수 있다는 것이다. RPC는 다양한 곳에서 사용되고 있다. Windows 인증,  MSMQ, Exchange Server, SMS Server, DCOM, DTC (Distributed Transaction Coordinator) 등등 이루 열거하기도 힘들 많큼 많은 Windows 운영체제 서비스와 독립 서버 제품군에서 RPC를 사용하고 있다.

다른 것은 다 개 무시하고... DTC 가 RPC를 사용한다는 점에 오늘은 주목해 보자. DTC라 함은 분산 트랜잭션을 관장하는 마이크로소프트의 TM (Transaction Manager) 이자 COM+를 이용하여 SQL Server와 트랜잭션을 사용하려 치면 반드시 사용해야 하는 중요한 서비스이다. 그런데 이 녀석이 사용하는 프로토콜이 RPC 라는 것이다. 또한 DCOM 역시 원격 COM+ 객체를 호출할 때 사용되는 분산 객체 프로토콜 아닌가? 닷넷이 대세인 지금이야 찬밥신세지만 여전히 DCOM은 알게 모르게 아주 많이 사용되고 있다는 점을 간과하지 않는다면, 이 DCOM의 하부에서 작동하는 RPC에 눈길 한번 안 줄래야 안줄 수가 없는 것이다.

게다가 요즘 심심치 않게 필자에게 들어오는 질문은 COM+를 사용하는데 SQL Server와 트랜잭션이 안 된다는 것이다. Windows 2003 서버에 COM+ 컴포넌트를 작성하고(닷넷이건 아니건 상관없이) 또 다른 Windows 2003 서버에 SQL Server를 두었는데... 트랜잭션 속성을 Required 로 하면 오류가 발생한다는 것이다. 이러한 오류의 99%는 두 서버 사이의 DTC 통신상의 문제이며 이는 곧 RPC 통신이 제대로 안되기 때문인 경우인 것이다.

지금까지 필자의 썰로 RPC를 소 닭보듯이 쳐다만 볼 것이 아니라는 것임을 동의 했다면 이 글을 계속 읽어 갈 것이고... 그렇지 않다면 남는 시간에 싸이질을 하거나 다른 유용한 작업을 하기 바란다...

RPC Endpoint Mapper & Dynamic Binding

RPC는 원격 호출에 사용되는 프로토콜임에도 불구하고 구체적인 네트워크 전송은 다양한 하부 프로토콜 중 하나를 사용하도록 유연하게 설계되어 있다. 따라서 RPC의 전송 프로토콜(transmit protocol)로서 TCP/IP, IPX, Named Pipe 등을 사용할 수 있다. 물론 이들 중 TCP/IP가 가장 많이 사용되며 RPC의 프로토콜 우선 순위 중 가장 첫번째 설정임은 두말하면 입 아프다 (실제로 Windows NT 에서는 Named Pipe가 최 우선이였지만 Windows 2000 부터는 TCP/IP가 가장 우선되는 프로토콜이 되었다).

RPC 호출을 수행하기 위해서는 RPC 서버가 존재하는 네트워크 주소(network address)와 종점(end point)을 알아야 한다. 이 네트워크 주소와 종점은 RPC의 전송 프로토콜이 뭐냐에 따라 달라짐은 당연 빤스 되겠다. 다른 프로토콜 이야기를 하면 입만 아파지므로(사실 잘 알지도 못하며 알고 싶은 욕망도 읍따...) TCP/IP 이야기만 하는 것이 좋을 듯하다. TCP/IP  에서 네트워크 주소는 당연 IP 주소일 것이고 종점이라는 것은 IP 포트가 되겠다. 소켓 프로그램을 해본 사람은 감이 팍 올 것이며, 그렇지 않은 사람이라도 웹이 80 번 포트를 쓴다는 것을 알 터이니, 그 80 번 포트를 종점으로 이해하문 되긋다.

RPC의 특징은 이 end point 를 가변으로 설정할 수 있다는 것이다. HTTP가 80번 포트라는 고정 포트를 사용하는 반면 RPC는 end point을 구체적으로 명시하지 않을 수 있고, RPC 런타임이 이 end point를 선택할 수 있다는 것이다. 포트라는 것이 HTTP, FTP, TELNET 과 같이 유명한 포트가 아닌 다음에야 임의의 포트를 썼다가 다른 프로그램과 쫑날 수도 있기 때문에 RPC는 사용하지 않는 포트 중 하나를 임의로 사용할 수 있도록 해주는 것이다. 참으로 친절한 RPC 런타임이 아닐 수 없다.

한가지 문제는 클라이언트가 서버의 포트를 어떻게 알아내는 가가 문제이다. RPC 서버가 시작될 때 사용 중이지 않은 임의의 포트가 할당되기 때문에 서버가 재 시작되어 버리면 예전의 포트를 다시 사용하리라는 보장이 전혀 없기 때문이다. 이 때문에 RPC는 RPC 포트 매퍼 서비스란 것을 제공한다.

<< RPC 포트 매퍼 서비스 >>

RPC 포트 매퍼란 녀석이 오늘의 뽀인뜨이자 하이라이트가 되겠다. RPC 클라이언트는 서버가 사용하는 종점(IP 포트)가 무엇인가 알아내기 위한 작업을 한다. 이때 클라이언트는 RPC 서버 바인딩 정보(네트워크 주소, 종점, 인터페이스 등으로 구성된 접속 정보 정도로 생각하자)에서 종점이 주어지지 않으면 서버 컴퓨터의 포트 매퍼에 접속하여 RPC 서버가 사용하는 종점정보를 물어본다. 여기서 주의할 점은 RPC 클라이언트가 종점 매퍼에 '접속'한다는 말이다. 이 말은 종점 매퍼 역시 RPC 클라이언트와 네트워크 접속을 해야 한다는 말이며 사용하는 TCP/IP 포트가 있다는 말인 것이다. RPC 종점 매퍼가 사용하는 IP 포트는 135번이다. 이는 RPC 기반의 서비스들(앞서 나열했던 DTC, DCOM, MSMQ 등)을 사용하기 위해서는 RPC 서버가 사용하는 포트 이외에 포트 매퍼가 사용하는 135번 포트 역시 사용됨을 알 수 있다.

Test

말로만 하면 도무지 믿질 않으니 테스트를 수행해 보자. 내가 한 C/C++ 한다는 사람들은 MSDN 의 자료와 PlatformSDK 에 포함된 RPC 예제 코드를 컴파일 해서 수행시켜보면 한눈에 알 수 있을 것이다. 하지만 이런 귀차니즘을 모두 벗어 버리고, 관심 대상인 DTC를 가지고 간단한 테스트를 해보자. 먼저 TcpView 를 다운로드 받아라. 이 프로그램은 어떤 프로세스가 어떤 TCP 포트를 사용하며, 현재의 상태가 어떤지 보여주는 멋진 유틸리티이다. TcpView 를 수행해 보면 다음과 같은 화면을 볼 수 있다.

<< TCPView로 살펴본 필자의 컴퓨터 TCP/IP 상태 >>

다른 것은 무시하고 강조된 두 항목을 살펴보자. 프로세스 ID가 1220 인 svchost.exe 프로세스가 135번 포트를 LISTENING 하고 있으며 이 녀셕이 RPC 포트 매퍼 서비스임을 알 수 있다. 그리고 DTC 프로세스인 msdtc.exe 프로세스는 1026번 포트를 LISTENING 하고 있다. 간단하게 분산 트랜잭션을 수행하는 프로그램을 작성하고 이 프로그램이 필자의 SQL-Server를 액세스 하도록 하면 msdtc.exe 프로세스는 1026번 포트를 사용하여 통신하고 있음을 파악할 수 있을 것이다. 이제 MSDTC 서비스를 중단하고 다시 시작해 보자 (어떻게 하냐고? -_- 여기까지 읽어 내려온게 가상하다고 할 수 있겠다...-_-). msdtc.exe 가 사용하는 포트는 1026번이 아닌 다른 포트가 될 것이다.

CheckPoint

글이 길어지는 관계로 여기서 정리 좀 하고 다음 글에 계속 써야 할 것 같다. 지금까지의 뽀인또는 많은 Windows 기반의 서비스와 제품군들이 RPC를 사용하고 있으며, 특히 프로그래머들과 관계가 많은 COM+와 MSDTC 역시 RPC에 기반한다는 것이다 (COM+가 어떻게 RPC를 사용하는가는 난중에 설명하께~~). 그리고 이 RPC의 특성 중 하나가 고정된 TCP/IP 포트를 사용하는 것이 아니라 임의의 사용 가능한 포트 중 하나를 사용한다는 점이며, 이렇게 가변 포트를 사용하기 때문에 포트 정보를 제공하는 종점 매퍼를 가지고 있다는 점이다.

대략 눈치를 챘겠지만, 방화벽으로 막혀있는 두 컴퓨터가 RPC 기반의 서비스(COM+, MSDTC 등)를 사용할 때 어떤 TCP/IP 포트를 열어야 하는지 이제 좀 감이 갔으면 한다. 상세한 내용은 다음 글에 남기도록 하겠다...

이거 블로그 맞어? 왤케 길어? -_-