An important issue is how many readers and writers can exchange information at a port. Different approaches impose various restrictions on the access to ports. A bound port is the most restrictive: There may be only one reader and writer. At the other extreme, the free port allows any number of readers and writers. These are suitable for programming client/server interactions based on a family of servers providing a common service. A common service is associated with a single port; clients send their service requests to this port and servers providing the requested service receive service requests from the port. Unfortunately, implementing free ports can be quite costly if in-order messages are to be supported. The message queue associated with the port is kept at a site which, in general, is remote to both a sender and a receiver. Thus both sends and receives result in messages being sent to this site. The former put messages in this queue and the latter request messages from it. (Often the implementation used is a little different from the centralized one described above: When a message is sent to a port, it is relayed to all sites where a receive could be performed on the destination port; then, after a message has been received, all these sites are notified that a message is no longer available for receipt. However, even in this replciated case, both sends and receives result in remote communication.)
Between these two extremes are input ports and output ports. An input port has only one reader but any number of writers. It models the fairly typical many client, one server situation. Input ports are easy to implement since all receives that designate a port occur in the same process. Thus the message queue associated with a port can be kept with the receiver. Output ports, in contrast, allow any number of readers but only one writer. They are easier to implement than free ports since the message queue can be kept with the sender. However, they are not popular since the one client, many server situation is very unusual. A send to an output port has recently been termed 'anycast'. Perhaps a ``practical'' use of an output port is distribution of tickets or other resources by a ``vendor'' to a set of ``buyers'' or even more compelling the SETI project in which a cental site sends problems to be solved to user machines registered with the site.
Note that sending to an output/free port does not broadcast the message to all the receivers - a specific message is received by a single server.
Several applications can use more than one kind of port. For instance a client can enclose a bound port in a request message to the input report of a file server. This bound port can represent the opened file, and subsequent reads and write requests can be directed to this port.