Mixing sendAgile and RMC messages on the SSC
--------------------------------------------
A common misconcpetion about RMC is that any application that must handle sendAgile
messages and RMC messages requires two application names (i.e: endpoints names like
"ncm" and "ncm_rmc". This is *NOT* true, and can lead to depletion of the precious few
appid's we have. More importantly, it is the wrong approach and should be avoided when
converting code to RMC.

On the listening side, RMC supports both types of transfers against a single session
with a single name. When RMC messages are sent to a session, RMC interogates the message
for a properly formatted header: if this header is absent, the message is assumed to be
a sendAgile message.

Applications that need to support both types of transfers can do so easily. The rmc_init()
is used to specify a msg allocation callback that's fired when a agile message (also called
a NON_RMC_MSG) is detected. Callers code this callback to return a message with three
sg_list buffers: the first is for the data payload, the second is for the recvfrom address
and the third is for the appname of the sender. The recvfrom and appname sizes are fixed -
the data payload size is passed into the callback.

When the NON_RMC_MSG callback is used, it allows the normal RMC listening mechanism to be
easily multiplexed for either agile or RMC messages.  All msg structures retrieved by
the calls rmc_waitfor_msg() or rmc_get_completed_msg() are stamped with hdr flags that
indicate the type of RMC message recieved or whether the message is and agile message.
Since the conventions is that the data payload is in sg_list[0] in either case, most
applications can easily dispatch the message identically. Note that for applications that
return responses, the recieved request msg also indicates the response type: if the type is
RMC, a properly formatted response message is formatted from the info contained in the request 
msg strucutre. If the type is NOT_RMC_MSG, all the information necessary to generate a
valid sendAgileMsg information is also available in the request msg: the return address, 
the return appname, and even the socket - the listen session socket (referenced by the
msg struct) can be retrieved using the rmc_sess_to_sock() call and used in the sendAgileMsg
call.

Mixing sendAgile and RMC messages in the EEE world
--------------------------------------------------
EEE applications can also mix agile and RMC messages. Since RMC is implemeneted as an
intermediary application, all messages directed to EEE cpu's are really directed to the
RMC application. When recieved, the RMC application moves the messages to the proper 
client application session completed queue and calls the rcv_callback registered with
the rmc_listen() call. This mechanism leaves the eee_rcv() function for the client applications
unused. If the applicaiton want to handle agile messages, it can register an eee_rcv()
call in addition to the rcv_callback registered via the rmc_listen() call. Messages picked
up via the rcv_callback are guaranteed to be RMC types, and messages picked up via the 
eee_rcv() are of agile type.

Applicaitons that recieve message via eee_rcv() are free to process them as wished. If the
application supports a single unified dispatch that handles RMC messages, the eee_rcv() 
routine may wrap the eee_desc_t in an rmc msg allocated via the rmc_alloc_msg(0) call. The
application simply sets the flag RMC_NOT_RMC_MSG in the msg->ihdr and links the eee_desc
to the msg->edesc field. When the message is free, the application needs to NULL the
msg->edesc field before call rmc_free_msg().