Broadcasting Remote Procedure Calls

In broadcast RPC-based protocols, the client sends a broadcast packet to the network and waits for numerous replies. Broadcast RPC uses only packet-based protocols, such as User Datagram Protocol/Internet Protocol (UDP/IP), for its transports.

Servers that support broadcast protocols respond only when the request is successfully processed and remain silent when errors occur. Broadcast RPC requires the RPC port mapper service to achieve its semantics. The portmap daemon converts RPC program numbers into Internet protocol port numbers. See Broadcasting a Remote Procedure Call Example.

The main differences between broadcast RPC and normal RPC are as follows:

• Normal RPC expects only one answer, while broadcast RPC expects one or more answers from each responding machine.
• The implementation of broadcast RPC treats unsuccessful responses as garbage by filtering them out. Therefore, if there is a version mismatch between the broadcaster and a remote service, the user of broadcast RPC may never know.
• All broadcast messages are sent to the port-mapping port. As a result, only services that register themselves with their port mapper are accessible through the broadcast RPC mechanism.
• Broadcast requests are limited in size to the maximum transfer unit (MTU) of the local network. For the Ethernet system, the MTU is 1500 bytes.
• Broadcast RPC is supported only by packet-oriented (connectionless) transport protocols such as UPD/IP.