As already explained, a session can be thought of as a handle on a channel that is implemented by some protocol. One can also view it as an object that exports a pair of operations: one for sending messages, and one for receiving messages:
XkHandle xPush(Sessn lls, Msg *message)
XkReturn xPop(Sessn hls, Sessn lls, Msg *message, void *hdr)
The implementation of xPush and xPop is where the real work of a protocol is carried out---it's where headers are added to and stripped from messages, and then interpreted. In short, these two routines implement the algorithm that defines the protocol.
The operation of xPush is fairly straightforward. It is invoked by a high-level session to pass a message down to some low-level session ( lls) that it had opened at some earlier time. lls then goes off and does what is needed with the message---perhaps using xPush to pass it down to a still lower level session. This is illustrated in Figure 3. In this figure we see three sessions, each of which implements one protocol in a stack, passing a message down the stack using xPush.
Passing messages back up the stack using xPop is more complicated. The main problem is that a session does not know what session is above it---all it knows is the protocol that is above it. So, a low-level session lls invokes the xDemux routine of the protocol above it. That protocol, since it did the work of opening the high level session hls to which this message needs to go, is able to pass the message to hls using its xPop routine. How does a protocol's xDemux routine know which of its potentially many sessions to pass the message up to? It uses the demultiplexing key found in its header.
In addition to the hls that is being called and the message being passed to it, xPop takes two other arguments. First, lls identifies the low-level session that handed up this message via xDemux. Second, since xDemux has to inspect the message header to select the session on which to call xPop---i.e., it has already gone to the effort of extracting the protocol's header---it passes the header ( hdr) as the final argument to xPop. This chain of events is illustrated in Figure 4.
To see how this works in practice, imagine we want to send a message using the TCP and IP protocols. An application program opens a channel by performing xOpen on TCP; TCP returns a session object to the application. TCP opens an IP channel by performing xOpen on IP; IP returns a session object to TCP. When the application wants to send a message, it invokes the xPush operation of the TCP session; this session in turn invokes the xPush operation of the IP session, which ultimately causes the message to be sent.
Now suppose an incoming message is delivered to the IP session. This session has no idea about the TCP session above it, so it does the only thing it knows how to do---it passes the message up to the TCP protocol using xDemux. The TCP protocol knows about all the TCP sessions, and so passes the message up to the appropriate TCP session using xPop. TCP's xDemux uses the demux key it found in the TCP header to select among all the TCP sessions.
The final operation that we need to be able to perform is one to close a session, which in effect closes the channel to the other machine.
XkReturn xClose(Sessn session)
Figure 3: Using xPush to pass a message down a stack.
Figure 4: Using xDemux and xPop to pass a message up a stack.
In addition to sessions and protocols, this discussion has introduced two other x-kernel object classes: messages and participants. Both classes represent exactly what you think they do---the messages that protocols send to each other (corresponding to type definition Msg), and the addresses of participants that are communicating over some channel (corresponding to type definition Part). Message and participant objects are discussed in more detail in later sections.