本文发表在 rolia.net 枫下论坛1. Server and Client keep the identical list of RPC service numbers; (originally defined by SUN)
2. Server can dynamically (non-universally) assign port numbers above 1024 to RPC services. Port 111 (or 135 in Microsoft OS) is specifically for portmap / rpcbind service.
3. Client uses RPC service number, instead of service name or port number, to call Server for a RCP service;
4. Server’s portmap/rpcbind use the RPC service number to find the port number and return to Client;
5. Client then use the port number to call xinetd/inetd daemon for the service;
6. xinetd/inetd daemon start the service;The service communicates with the client.
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 in Windows or 111 in Unix/Linux). 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. . . .更多精彩文章及讨论,请光临枫下论坛 rolia.net