Pruning

 
CU-SeeMe Development Group
Document Draft:  006
Protocol Feature Designer: Tim Dorcey, [email protected]
Document Author: Richard Kennerly, [email protected]
Revised: Feb 26, 1996

Protocol Specification - "Pruning" for AuxData

Status:
-------
Implemented in Mac CU-SeeMe 0.67 and earlier
Implemented in Windows CU-SeeMe 0.84
          

Abstract:
---------

   "Pruning" refers to the process whereby a reflector is able to
determine which clients should receive which types of AuxData
from whom and forward packets accordingly.  This is accomplished
by including mapping information in OpenContinue Packets that
indicates which AuxData types a client wants to receive from
which clients.

   The method used to accomplish this is somewhat indirect - the goal
is to allow each user to indicate which auxdata types it wishes to
receive from each of the participants in a conference.  If this
were accomplished by simply listing 32-bit AuxData types desired
from each participant there would be 4 Bytes/AuxDataType x
NAuxDataTypes for each participant needed in OpenContinue Packets.
In a conference with 8 active AuxDataTypes there would be 32 bytes
used for each Participant - in a conference of 16 Participants,
this would amount to 512 bytes just for AuxData pruning.  The
Pruning scheme described below reduces this number from 32 bytes
per client to 1 byte per client plus 6 bytes per AuxData type plus
8 bytes in additional headers (72 bytes instead of 512 in the above
example).

Definitions:
------------

   kAuxTMAdvExtraType is the dataType to be specified in the OCExtraHeader:

#define kAuxTMAdvExtraType     1        // Advertise Aux Data bit mapping


Packet Format:
--------------

The components of an OpenContinue Packet which includes AuxData
Pruning information are arranged as follows:

OpenContinue Packet
OCExtraHeader for AuxData Pruning.
TMapHeader
TypeMap[count]

Note: For historical reasons the AuxData Pruning OCExtraHeader
information must be the first OCExtra type after the OpenContinue
Packet's ClientInfo array.


OCExtraHeader:

0              8              16             24            31
+--------------+--------------+--------------+--------------+
|          DataType           |          Byte Count         |
+--------------+--------------+--------------+--------------+


TypeMap Header:

0              8              16             24            31
+--------------+--------------+--------------+--------------+
|       TypeMap Count         |      Header Sequence #      |
+--------------+--------------+--------------+--------------+


TypeMap array:

0              8              16             24            31
+--------------+--------------+--------------+--------------+
|       TypeMap bit           |     4-byte AuxData Type --> |
+--------------+--------------+--------------+--------------+
|   AuxData Type (con't)....  |
+--------------+--------------+


Implementation:
---------------

  There are two parts to the Pruning mechanism:

1) Mapping relationships between 32-bit AuxData types and bit
   positions in an 8-bit Prune Byte are included in an extension
   to the OpenContinue Packet.  This is implemented using the
   OCExtraHeader extension.  See the CU-SeeMe Document Draft-001
   for a description of how to use the OCExtraHeader functionality.

2) The ClientInfo array in the OpenContinue packet includes the 8-bit
   "prune" or "aux" byte for each client.  This indicates which
   aux data types we wish to receive from that client.

   A client advertises the types of auxdata it is capable of sending


See Also:
---------

Document on OCExtraHeader Extension by Rich Kennerly
Document on AuxData by Larry Chace