요약

  • ONC RPC 서비스는 전송 포트를 실행 시점에 선택할 수 있었고, RFC 1057의 포트매퍼는 클라이언트가 이 선택을 찾아볼 수 있는 고정 지점을 제공했다.
  • 등록은 프로그램, 버전, 전송 프로토콜을 특정 기기의 한 포트에 연결하는 것이었다. 이는 디렉터리 응답이지, 신원이나 가용성에 대한 증명이 아니었다.

알려진 주소, 바뀔 수 있는 포트

한 관리자가 기기의 파일 서비스를 재시작하는 상황을 생각해 보자. 서버 프로세스는 네트워크 전체를 위해 미리 예약된 번호에 의존하는 대신, 가용한 포트를 요청할 수 있다. 하지만 호스트 주소와 찾으려는 RPC 프로그램을 아는 클라이언트는 여전히 자신의 호출을 어디로 보낼지 알아야 한다. 모든 서비스가 전 세계적으로 조율된 고정 포트를 가져야 한다면, 제한된 포트 공간은 수많은 진화하는 프로그램을 담는 복잡한 등록부로 변할 것이다.

1988년 6월 Sun Microsystems가 발행한 RFC 1057은 다른 조직 방식을 기술했다. 프로그램 번호와 버전은 클라이언트가 원하는 것이 무엇인지 나타내고, TCP 또는 UDP는 전송을 지정한다. 잘 알려진 포트 111에서 접근 가능한 로컬 포트매퍼가 이 식별자들을 서버가 선택한 포트에 연결해 준다. 클라이언트는 먼저 매퍼를 조회한 뒤 서비스에 접촉한다. RPC 호출과 그 바인딩 해석은 서로 다른 두 단계다.

PMAPPROC_SET절차가 서비스를 등록한다. 서버는 같은 기기의 매퍼에 자신의 프로그램 번호, 버전, 전송 프로토콜, 리스닝 포트를 전달한다. 매퍼는 동일한 프로그램-버전-프로토콜 조합의 중복 등록은 거부한다. 서비스가 중단되면PMAPPROC_UNSET이 등록을 제거한다. 클라이언트는PMAPPROC_GETPORT를 호출하며, 0은 해당 조합에 등록된 대응 항목이 없다는 뜻이다.

역할 분담은 단순하다. 서비스가 어디서 리스닝할지 선택하고, 매퍼가 그 선택을 예측 가능한 지점에서 조회 가능하게 만들며, 클라이언트가 반환된 포트를 사용한다. 해석 지점은 관례에 의해 고정되지만, 서비스 지점은 달라질 수 있다.

응답이 말해 주지 않았던 것

매퍼의 응답은 그 자신의 로컬 등록부 상태에 한정되었다. RFC 1057은GETPORT를 종단 간 확인으로, 네트워크 경로가 작동한다는 증거로, 그 포트를 점유한 프로그램에 대한 암호학적 선언으로 만들지 않았다. 클라이언트는 여전히 연결을 수립하고, 절차를 호출하고, 결과를 해석해야 한다. 중단된 서비스는 만료된 등록을 남길 수 있어, 발견은 성공하지만 호출은 실패할 수 있다. 반대로 대응 항목이 없다는 것은 바인딩 문제를 신호한다.

«등록됨» 대신 «발견됨»이라는 표현이 더 강하게 들릴 수 있다. 포트 번호는 서비스가 리스닝으로 등록된 위치를 나타낼 뿐, 패킷 도착, 클라이언트 수용, 절차 실행을 보장하지 않는다. RFC는 인증과 전송의 속성을 별도로 다룬다. 포트매퍼는 이들을 대체하지 않는다.

이 표는 모든 RPC 프로그램을 아우르는 전 세계 등록부가 아니었다. 그것은 서비스를 호스팅하는 기기 위에 존재했다. 클라이언트는 다른 출처로부터 그 기기의 주소를 알아야 했고, 그 다음 그 기기의 매퍼에게 전송 포트를 요청했다. 발견은 이렇게 여러 계층에 걸쳐 분산되었다. 이름이나 구성이 호스트를 제공하고, 프로그램 번호와 버전이 인터페이스를 지정하며, 매퍼가 전송 지점을 알려준다.

RFC는 또한 등록을 나열하는PMAPPROC_DUMP와 브로드캐스트 호출을 위한PMAPPROC_CALLIT을 기술했다. 클라이언트는 브로드캐스트 주소의 매퍼 고정 포트로 자신의 요청을 보냈다. 이를 수신한 각 매퍼는 자기 기기에 등록된 서비스를 호출할 수 있었다. 매퍼는 실행이 성공했을 때만 응답했고, 그렇지 않으면 침묵했다. 이 덕분에 기기마다 서로 다른 포트로의 브로드캐스트가 가능했지만, 전달을 보장하지도, 응답자 전수 조사를 제공하지도 않았다.

프로그램 번호 범위는 조율 규칙을 하나 더했다. RFC 1057은 Sun이 정의한 블록, 사용자가 정의한 블록, 임시 블록, 예약 블록을 구분했다. 따라서 프로그램의 논리적 이름은 가변적인 전송 포트와 구별되었다. 하나는 RPC 서비스를 식별하고, 다른 하나는 그 인스턴스가 리스닝하는 곳을 나타냈다.

TCP/UDP 표에서 보편 주소로

기술된 최초의 포트매퍼 버전은 TCP와 UDP 포트에 묶여 있었다. 1995년, RFC 1833은 포트매퍼 버전 2와 RPCBIND 버전 3, 4를 문서화했다. 같은 문제를 드러낸다. 전송 포트나 셀렉터는 달라질 수 있는 반면, 클라이언트는 서버 주소에서 고정된 조회 지점을 필요로 한다. RPCBIND는 전송 주소를 이른바 보편적(universal) 문자열로 표현하고 네트워크 식별자를 추가했으므로, 바인딩은 더 이상 TCP/UDP 포트에만 국한되지 않았다.

이 후속 문서는 1988년의 선택이 가진 범위를 비춰 준다. RFC 1057은 RPC 프로그램을 특정 포트에 불가분하게 묶지 않았다. 프로그램과 버전을 전송별 리스너에 연결할 수 있는 만남 지점을 정의했다. 더 늦은 RFC 5531도 RPC 메시지 프로토콜과 바인딩·만남 메커니즘 사이의 독립성을 명시적으로 다룬다.

이득은 한정되어 있었다. 클라이언트와 서버가 조회 관례를 공유하면, 클라이언트는 서비스의 포트를 미리 알 필요가 없었다. 이는 고정 포트를 아끼고 인스턴스가 로컬에서 선택하게 해 주었다. 그 대가로, 호출은 사전 대화와, 서비스의 기동·등록·중단·제거를 따라가야 하는 상태에 의존하게 되었다.

이 RFC들은 메커니즘을 기술하며, 역사적 배포 빈도나 측정된 신뢰성을 다루지 않는다. 만료된 등록이나 그 정정 속도를 정량화할 수 있게 해 주지도 않는다. 확실한 결론은 아키텍처에 관한 것이다. 포트매퍼는 안정적인 로컬 만남 지점을 통해 RPC 지점을 발견 가능하게 만들었다. 접근 가능성, 인증, 실행은 그 다음에 수립해야 할 별개의 작업으로 남았다.

1차 자료:RFC 1057 — RPC 버전 2;RFC 1833 — ONC RPC 바인딩 프로토콜;RFC 5531 — ONC RPC 버전 2.