// This is the interface for the MESSAGING LAYER
// This layer includes the following functionality:
//	Segmentation and reassembly
//		- Messages are broken into pieces and given sequence 
//		numbers (x of n format) so that they can be reassembled
//		and delivered atomically at the destination, if desired
//	Domain filtering
//		- Domains provide a filtering level beyond token
//		rings.  This is useful for systems where there are lots of 
//		groups with the same set of members.
//	Replies to messages
//		- For handled messages (or other messages) a reply-to field
//		can be appended which specifies the message that this is
//		replying to.  This is then delivered up to the application,
//		which may be blocking waiting for this message.  This involves
//		keeping track of a table of messages which have been sent out
//	 	that have indicated they need a reply, and matching them up 
//		with replies that come in.
//	Client registration in groups
//		- This allows multiple clients to use a single copy of RMP.
//		This involves maintaining a list of which clients are currently
//		subscribing to which groups (if used) for each token ring.
//		Then when a packet is delivered to that ring, a list of client
//		destinations is derived from this list and delivered to the 
//		application.  The application can use this information to 
//		send the message to the appropriate destinations.
//		When clients are used, the sending client is appended to 
//		messages, to inform the destination of the real source of 
//		the packet.
//
// For this, the following extra fields have to be added.  These fields (and the 
// corresponding functionality) are selectable on a per message basis:
// Typing information			  	2 bytes (REQUIRED)
// Segmentation and reassembly			6 bytes, flag 0   
//	2 bytes message number from this application, determined by the sequence 
//		number given (by RMP) to the first packet of the message
//	2 bytes packet number
//	2 bytes total number of packets
// Domain filtering				2 bytes, flag 1
//	The domain number	
// Multiple clients				2 bytes, flag 2
//	The client number which sent the packet
// Reply to field				8 bytes, flag 3
//	2 bytes message number, as defined in segmentation and reassembly
//	6 bytes message source, equal to the RMP process ID
//
// The typing information field is mandatory.  The values 0-4095 are reserved for
// official layers in the extended library.  Values above this can be reserved by 
// other protocols that are built on top of RMP so that conflict between protocols
// can be detected and avoided.

// For packets that fall in the 0-4095 range, the following format for the type
// field is mandated:
//  0                   1           
//  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |0 0 0 0|   FLAGS   |   LAYER   |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// 	Bits 0-3: 0
//	Bits 5-9: Flags
//	Bits 8-15: Destination Layer
//
// BIT    FLAG    PURPOSE
// ---    ----    -------
//  4       0     Is the segmentation and reassembly field included?
//  5       1     Is the domain filtering field included? 
//  6       2     Is the multiple clients field included?
//  7       3     Is the reply-to field included?
//  8       4     Are there multiple small packets batched into this one?
//  9       5     Defined by the layer that the field is destined to
//
// The destination layer field defines which layer issued this packet
// and should therefore handle it at the destination.  If the given layer
// is not included/being used at the destination, the packet should be 
// dropped, and an error may be reported to the user.
//
// The currently defined destination layers are:
// 	0	The messaging layer
//      1	The streams layer
//	2	The RPC layer
//	3	The replicated object layer
//
// All of the other layers are independent, with the following exceptions:
//	- If segmentation and reassembly is used, the fields for the other
//		features are only included in the first packet in the message
//	- The implementation of multiple client filtering must keep track
//		of the list of domains that each client is using

Data structures:  
Segmentation and reassembly	
	One queue per token ring.  Search queue for messages. 
	Code is done in main.c.  Easy port.  Oh, yeah.  Also have to
	break up into packets, which is done in rmp_api.c.

Reply-to
	Needs to hold on to a list of packets that are requesting replies
	Then will send a pointer to those packets back???  Hmm...
	Need a general mechanism.  What about handled packets?
	We just need a general way of identifying the packets...don't
	need the packets themselves.  Hmm....  Easy implementation, however.
	
Clients and domains.  Need to have a list of token rings.  Each token ring 
	has a list of which domains exist.  Each domain has a list of 
	clients.  Each token ring would also need to have a list of 
	clients with * accepts over domains.  Then would need to be able
	to remove things by scanning through each list.