Request/Reply

Protocols using request/reply behavior send a single block of data (usually a single packet), and wait for a reply before sending another. Sometimes referred to as ping-pong behavior, request/reply is simple to understand and implement, but not very efficient. In LAN topologies with fast links, this isn't much of a concern, but WAN links will spend most of their time idle, especially if several hops are required.

Some protocols pretty much require request/reply behavior. For example, Internet's Remote Procedure Call (RPC) Protocol is used to implement subroutine calls from a program on one machine to library routines on another machine. Since most programs are single threaded, the sender has little choice but to wait for a reply before continuing the program and possibly sending another request. Hopefully, our language and compiler technology will someday easily support multi threaded code, but until then RPC will remain largely a request/reply protocol.