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.
