One goal behind the development of the remote procedure call (RPC) protocol was to build a solution for the limited number of service ports available in the TCP and UDP protocols. In both TCP and UDP, ports are defined in a 2-byte field, which limits the number of ports to 65,536.
Instead of using static service-port mappings, RPC provides a dynamic service-port mapping function. In RPC, incoming RPC calls are mapped to a variable port in the 1024 to 65,535 range. Although RPC uses variable service ports, it needs a unique way to identify services. The RPC protocol resolves this need by using a special service identifier and a dedicated Portmapper service. The unique RPC identifier is called the RPC service number. Service numbers are defined in a 4-byte field, which provides up to 4,294,967,296 possible service numbers. The Portmapper service listens on a static port (TCP or UDP port 135). The service exists primarily to map the unique RPC service number on a variable TCP/UDP port. Thus, RPC can provide both a unique way to identify RPC services and a way to dynamically allocate the scarce number of TCP/UDP service ports.
Figure A illustrates how this dynamic port allocation works. In Step 1, the RPC server starts and registers with the RPC Portmapper service. The RPC portmapper maps the RPC service number to a port in the range 1024 to 65,535. In Step 2, the portmapper returns the port to the RPC server. The first two steps are known as the RPC registration steps. The RPC client then wants to connect to the RPC server. To find out the exact port on which the server is listening, the RPC client contacts the portmapper (Step 3). The portmapper then maps the RPC service number it received from the client to the server’s port and returns the number to the client (Step 4). Finally, the RPC client connects to the server (Step 5), and the server replies to the client (Step 6).
