Pruning

 

CU-SeeMe Development Group

Document Draft:  006

Protocol Feature Designer: Tim Dorcey, td11@cornell.edu

Document Author: Richard Kennerly, rbk1@cornell.edu

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