We have considered how to implement basic message communication on real hardware. The next issue to consider is how does the communications client interact with the communications facility. The client in this case could be either a user program or the kernel itself. In general the kernel may provide several services and these services may in turn be clients of each other: for example the virtual memory system in Nachos is a client of the file system, and you may extend it to page over the network, which would make the virtual memory system a client of the network.
One possibility is to present the network communications as they really are, a packet transporting service. The client would be allowed to send and receive packets to and from the network. These calls do just what it sounds like they do, put a packet on the wire, and wait around for a packet to come off of the wire, respectively. The problem with these is that this is not like any other thing that programmers do, so it is not always so easy to design and implement communicating programs with these primatives.
Another possible model is to treat the communications facility like a file, using read to get a packet from the network (and wait for one if one is not available), and write to send a packet. Of course there is no natural way to talk about packet lengths and boundaries in read, so this mechanism typically loses information about when one packet begins and another ends. On the other hand, it is a simple and natural way for programmers to think about the problem.
One kind of message passing that programmers do all the time is procedure call. Calling a procedure is like passing the arguments in a message to the procedure and waiting for the procedure to send back the result, a.k.a. the return value, in another message. This is a popular form of interprocess communication which seems to be just the right model for many problems, and is something that people can work with comfortably. In fact, most systems make system calls, another form of interprocess communication, look like procedure calls for the same reason. Some systems also make remote procedure calls look exactly like procedure calls, so that the programmer might not know whether the procedure is local or remote.