%
% chan.tex
%
% $Revision: 1.2 $
% $Date: 1996/02/02 00:04:22 $
%

\subsection{CHAN}

\topic{NAME}
CHAN (RPC Channel Micro-Protocol)

\topic{SPECIFICATION}

\noindent 
S. O'Malley and L. Peterson.  A Dynamic Network Architecture.  {\it
ACM Transactions on Computer Systems 10}, 2 (May 1992), 110--143.

\medskip
\noindent  B. Welch. {\it The Sprite remote procedure call}. 
University of California at Berkeley, Tech Report UCB/CSD 86/302,
June 1986.

\topic{SYNOPSIS}

\noindent CHAN is a single protocol version of Sprite RPC's reliable
request-reply channel. The algorithm was extracted from Sprite and
made into a stand-alone protocol. Each CHAN session supports the
Birrell-Nelson implicit acking RPC algorithm between two hosts.

CHAN provides ``at most once'' RPC semantics.  When a CHAN call
returns successfully, the protocol guarantees that the request has
been processed exactly once by the server.  If CHAN returns
unsuccessfully (XK\_FAILURE), the server may have processed the
request once, or it may not have seen the request at all.  

Channel numbers are entirely internal to the CHAN protocol.  When a
new client channel session is created, a new host-host channel number
is selected internally by CHAN.  When protocols openEnable CHAN, they
will receive connections from any channel number on any remote host.  
Each open of CHAN by a client session will result in the passive
creation of a corresponding session on the server.

Each channel session will accept only a single outstanding request.
Sending additional requests on a channel before the first request has
returned is not allowed. 

CHAN relies on the BIDCTL and BID protocols to determine when a peer
has rebooted.  When notified of a peer's reboot, CHAN will disable all
active channels to that host.  Outstanding calls will return
XK\_FAILURE, as will all subsequent calls on that channel session.
Replies sent through disabled server channels will be discarded.

CHAN must know several things about the transport protocol used 
to actually send the message. This information is represented in 
the following structure:

\begin{verbatim}
typedef struct {
    XObj transport;
    int  ticket;
    int  reliable;
    int  expensive;
    unsigned int timeout;
} chan_info_t;
\end{verbatim}

This structure is defined in the CHAN session state and a pointer 
to it is attached as an attribute to each outgoing message. Before 
the message is send CHAN zero's out all fields of the structure.
When xPush returns CHAN assumes that some lower level 
protocol may have filled in the fields.
 
If transport has been defined CHAN will perform a FREERESOURCES control 
operation on transport when the current message has been acked. If 
the lower level protocol is reliable CHAN will never retransmit the 
entire message and will not start a timer. If the lower level protocol 
is expensive CHAN will not retransmit the entire message when it times 
out. It simply requests an ACK. The timeout field is ignored for the 
moment. If transport has been defined CHAN will invoke a 
CHAN\_RETRANSMIT control operation on it before retransmitting. 
If this control operation returns 0 CHAN will not retransmit the 
body of the message. This allows  a lower level protocol like BLAST 
to discourage CHAN from retransmitting while the message is still being 
sent.

\topic{REALM}

\noindent
CHAN lies on the boundary between the ASYNC realm and the RPC realm.
That is, it looks like an ASYNC protocol to protocols below it, and
an RPC protocol to protocols above it.

\topic{CONTROL OPERATIONS}

\begin{description}

\item[{\tt CHAN\_ABORT\_CALL:}]
When invoked on a channel session, it causes the current call (if one
is outstanding) to abort and return XK\_FAILURE.
\begin{description}
\item[{\rm Input:}] {\tt none }
\item[{\rm Output:}] {\tt none }
\end{description}

\end{description}

\topic{PARTICIPANTS}

\noindent
CHAN neither removes from nor adds to the participant stacks, passing
the participants untouched to the transport protocol on an open and
ignoring the participant structure on an openenable.

\topic{CONFIGURATION}

\noindent
CHAN requires its lower transport protocol configured as the first
lower protocol and BIDCTL configured as the second lower protocol.
CHAN requires that it's transport protocol will deliver incoming messages
from different hosts through different lower sessions and that all
CHAN messages from the same host come from the same lower session.

CHAN is a realm boundary protocol which assumes its transport protocol is
symmetric (in the ASYNC realm.)

Because CHAN affixes a pointer to the outgoing message 
it must be in the same address space as any transport 
protocol which will attempt to set the structure passed 
in the attribute.

\topic{AUTHOR}

\noindent Sean O'Malley