The other common model of interprocess communication is byte streams. In
this model there is a (one way or two way) connection between two processes,
sometimes called a virtual circuit. When one side puts data into this
connection, the data appears in the same order on the other side. There is
no structure on the data. This is like a Unix pipe.
The socket communications facility in Unix uses this model. When you create a socket, before you can start sending data on it you need to connect it to another socket, which will be the destination of that data. Then whenever you put data into the socket using write, the process on the other end can get the data by executing a read on its socket.
Stream communication is connection based. This means that the two endpoints of the communication facility always send their data to one another. You will need to implement a method for making the initial connection, and for sending data once the connection is made.
In Unix, when a process is ready to start a stream communication session, it announces this by accepting connections to a mail box and listening for activity. When a process wants to communicate with another process which is accepting connections, it connects to it. Once the connection has been made the two processes communicate by reading and writeing on the connected sockets.
The Unix man pages on connect, accept, listen and bind describe the function of these procedures in the Unix environment. You will be specifically interested in SOCK STREAM type sockets. You can combine the function of several of these (for instance bind, listen and accept) in your implementation.
The rlogin program is a good example of an application in which
streams are the correct communication model. On the client side of
rlogin the program takes the user key events and sends them off to the
other end. The client also takes the data out of the socket whenever
some appears and puts it on the users screen. The server end gets data
from the socket and sends it to the program which is being run currently
on the server end (this is initially the shell), and takes the output
of that program and sticks it into the socket.