// 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
//		- Important issue is to make sure that QoS is maintained.  
//		Ordering should be dictated by the sequence number of the 
//		first packet in the message.
//      - Another important issue is to guarantee correctness in the
//		face of failures.  How to guarantee that sequence numbers don't
//		collide for a message, in the face of failures?  TODO.
//
//	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.  The replyRequested flag (bit 9 of
//		typing field) is used to indicate which messages need a reply.
//
//	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.                                               
//
//  Multiplexing multiple small messages into a single packet
//		- It is much more efficient to send a single large packet
//		rather than many small packets, so this layer will buffer
//		multiple small packets into a larger one.  This requires
//		a timeout on the buffering Q to determine when to flush 
//		the packets, as well as a flush command.  All of the messages
//		except the last in a packet must have their flag 4 set, which
//		causes them to have a length of their data field included.
//		This allows the destination to calculate the boundaries for
//		each of the messages.
//
// 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, assigned by the messaging layer
//	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     
// Multiplexing packets				2 bytes, flag 4
//	The length of the data field of the message
// 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 (IP Address + Port)
//
//
// 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     Is there another message after this one (adds length field)?
//  9       5     Is a reply requested for this message?
//
// 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	
//	A single queue is needed per token ring.
//
//Reply-to
//	No data structures needed!  For now, we won't put in callbacks for
//	messages.  The message sequence number is included with the reply
//	field itself, so no storage is needed.  If callbacks are added in,
//	a single queue per token ring would be needed.
//		
//Clients and domains.  Need to have a list of token rings.  Each token ring 
//	Each token ring (group) has a queue of clients accepted to it.
//	Each client in this queue has a list of domains that it is accepted to.
//	A client may subscribe to a 0 domain, which indicates all domains.