Patent Application
20050276234
The International Telecommunication Union (ITU) Telecommunications. Standardization Sector's recommendation for data protocols for multimedia conferencing (ITU T.120) defines a standard for multipoint communication services, which is the basic architecture used by most of current popular media conferencing products such as Microsoft Net-Meeting, IBM Same-Time, WebEx Web-Meeting and most traditional teleconferencing products.
In general, a multipoint communication service provides a multipoint connection-oriented data service. It collects point-to-point transport connections and combines them to form a multipoint domain. Within that domain a large number of logical channels are provided that can provide one-to-one, one-to-many and many-to-one data delivery.
With the increasing popularity of internet multimedia conferencing, a high performance and scalable system to accommodate large number of participants from different location within a limited network bandwidth is required. To achieve such a goal, the conference data delivery needs to be distributed. In general, conference data falls into three categories: (1) real time media data; (2) resource data, which assists in establishing communications among client applications and helps peer clients to discover a common resource on which to communicate; and (3) necessary history media data and status information, required by the newly joined client for synchronization purposes.
A distributed real time multipoint communication server architecture has now been used by some commercial products or services to distribute the category (1) data. In this architecture, a central registry repository at the top server is still used to store all the category (2) and category (3) data. When there are large numbers of participants, since all the category (2) and (3) data will be delivered to all participants via the central repository at the top server, it will overburden the top server and eventually affect the overall service quality of the system.
Thus, there exists a need to address the above problem that when there are a large numbers of participants joining a conference from different locations, the top server will not be overburdened.
The present invention solves this need. The present invention is directed to an architecture and method for effectively distributing the delivery of category (2) and category (3) data in a multipoint communication system in such a way that each participant in the multipoint communication system can get the data from its closest local server. Thus the top server is not the only server responsible for delivering this data and therefore the system can operate more efficiently.
The database architecture according to principles of the present invention is a distributed real time multipoint communication registry-database (COMM-DB) defined within a distributed multipoint communication system. This distributed database is used by multipoint communication system clients, or client applications, to share (store and retrieve) configuration data, resource objects and history media content and status information, which can assist in establishing communications among the client applications, help peer clients to discover a common resource on which to communicate, and also can cache the media contents for future use.
Additionally, a method for efficiently distributing conferencing data in a distributed multipoint communication system is provided. The method includes steps of providing a distributed real time communication database defined within the multipoint communication network topology and using the real time distributed communication database to share conferencing data between participating clients, such that a client can obtain required conferencing data from its closest server.
Other features and advantages of the invention, both as to its structure and its operation, will best be understood and appreciated by those of ordinary skill in the art upon consideration of the following detailed description and accompanying drawings, in which:
Referring to
The internal data structure of a COMM-DB can be seen in
A description of the COMM-DB Key and commands performed on Keys will now be discussed. In accordance with principles of the present invention, a Key defines properties of clients participating in the distributed multipoint communication system. It should be understood by those skilled in the art that a client as referred to herein means a client or client application. A Key consists of the following elements: Key name, Key ID and Key attributes. The Key elements are described as follows.
Key Name
Each COMM-DB key has a name assigned by the client consisting of one or more printable ANSI characters—that is, characters ranging from values 32 through 127. Key names cannot include a space, a backslash (\), or a wildcard character (* or ?). The name of each sub-key is unique with respect to the key that is immediately above it in the hierarchy. Key names are not localized into other languages, although object's name may be.
Key name length is limited to 256 characters.
Key ID
Once a key is registered, a unique 4 byte long unsigned ID will be assigned to this key by the server. The lower two bytes of the ID serve as an index for distributed multipoint communication system to quickly locate this key object in later COMM-DB operations, the higher two bytes contain a random number for validation.
In each COMM-DB, there exists a key array. Each element of the array refers to actual key object. To locate a key object by key_id, it only takes one basic instruction:
Modification Permission
This attribute defines who has the permission to modify/delete the key. Three types of permissions are defined:
Monitor Channel
This attribute defines the monitor channel for the key and its sub objects. Any change to this key and its sub objects will be notified to all the nodes which have joined this monitor channel.
When a new client joins this channel, it will automatically be notified with all the contents (key info, sub key and sub contents) of this key.
Ownership
It specifies who own this key. When Modification Permission is set as Owner-Only, ownership is required to modify/delete this key and sub objects.
The commands which can be executed for COMM-DB keys are described below and illustrated in
Referring to
This table shows the parameters used in register-key events:
Referring now to
This table shows the parameters used in delete-key events:
A further Key command is shown in
This table shows the parameters used in retrieve-key events:
A still further Key command is illustrated in
The COMM-DB objects and operations will now be described with reference to
Each COMM-DB object resides as a leaf in the hierarchically structured tree. The object inherits the ownership, modification permission and monitor channel from its parent key. Common COMM-DB object attributes are as follows.
Object Name
Each object has a name consisting of one or more UTF-8 encoded characters to support localized application languages. The name of each object is unique with respect to the parent key that is immediately above it in the hierarchy.
Object name length is limited to 32 bytes.
Object ID
Once an object is registered, a unique 4 byte long unsigned ID is assigned to this object. The lower two bytes serve as an index to quickly locate this object in future object-operations, the higher two bytes contain a two bytes random number for validation. The format of the Object ID is similar to the Key ID described hereinabove.
Objects are stored in an array under its parent key. To locate an object under its parent key by object_id, it only takes one step:
An Object is categorized by its type. Each object type has its own data structure and operations. The object types can vary depending on the applications being run, and the object types set forth herein are for exemplary purposes only. Those of ordinary skill in the art would recognize that other object types can be defined for other applications. The following object types will be described in detail below and used as examples for illustrating principles of the present invention.
Object tag is a 4 byte long unsigned value set by the application. It is only meaningful to the application.
Object Data Delivery Flag
This flag is an unsigned byte, it defines generally how an object requires the multipoint communication server to delivery its data and command, for example, in which priority and in what model (uniform or non-uniform). The structure of the object data delivery flag is shown in the table below.
Uniform sequencing is necessary when operation on a same object is requested simultaneously from several client applications, and must be received in the same sequence by all receivers. All the uniformly sequenced requests are routed to the Top COMM-DB 20 and from there dispatched in the same order to all the receiver clients, including the sender if it is a member of the monitor channel. If the sequence of the operation of this object is not important, or the client application can ensure the sequence through other means, the uniform bit here is not necessarily set.
Similar to the commands described above with respect to the COMM-DB keys, common object operations can be performed according to principles of the present invention. The operations include Registering an object, Deleting an object and Retrieving an object. The sequence of messages exchanged during execution of the operations is shown in
A new object can be created by a client application issuing a Register-Object-Request command to the top COMM-DB. After receiving this request, the top COMM-DB needs to check if this object already exists or if the requestor has the permission by checking its parent key's modification permission attribute. If this is not a duplicated object and it is allowed, the top COMM-DB will create the new object, assign an object id for it, and insert it into the local tree repository, then confirm the requestor with a SUCCESS Register-Object-Confirm message. Otherwise, top COMM-DB will confirm the requestor with a FAILURE Register-Object-Confirm message. Upon the successful registration, the top COMM-DB will issue a Register-Object-Indication message to all the nodes joined to its monitor channel. After receiving the Register-Object-Indication message, client applications may handle it according to their own application logic and sub COMM-DBs will insert this new object into its local tree repository.
The following table shows the parameters used in register-object events:
An object can also be deleted by a client application issuing a Delete-Object-Request command to the top COMM-DB. After receiving this request, the top COMM-DB needs to check if the requestor has the permission by checking its parent key's modification permission attribute. If it is allowed, the top COMM-DB will delete this object from the local tree repository. Upon the successful deletion, the top COMM-DB will issue a Delete-Object-Indication message to all the nodes joined to its monitor channel. After receiving the Delete-Object-Indication message, client applications may handle it according their own application logic, and sub COMM-DBs will delete this object from its local tree repository.
The following table shows the parameters used in delete-object events:
Additionally, client applications may issue a Retrieve-Object-Request command to its parent COMM-DB to retrieve object information. After receiving this request, the parent COMM-DB needs to return this object's information to the requester.
The following table shows the parameters used in retrieve-object events:
The object types set forth above will now be described in detail.
Parameter Object
Parameter object is defined for peer client applications to share a dynamic binary value. The major difference between this object with all others is that monitoring client applications will be notified of its value in the register-object-indication, it doesn't need an extra object-content-indication message for the notification.
Extra data used in register-object events:
Parameter Object Operations
Parameter Update
Client applications may update a parameter value by issuing a Parameter-Update-Request command. Both uniform and non-uniform mode are supported. The sequence of events during a parameter update operation in uniform and non-uniform mode is shown in
When a COMM-DB receives this request, it will check the permission, update the value in the local repository, and redistribute the command to all other members in its monitor channel.
The following table shows the parameters used in parameter-update events:
Token Object
A token object is related to the ITU T.120 resource token, which provides a means to implement exclusive access to a given resource. For example, to ensure in a multipoint application using resources that one and only one client application holds a given resource at a given time, a token can be associated with every resource. When a client application wishes to use a specific resource, it must ask for its corresponding token, which will be granted only if no one else is holding it.
The major difference with T.120 token and that according to principles of the present invention, is that a grabber-key concept is introduced. The grabber key is a UTF-8 encoded character string with maximum length of 16 bytes. If it is set non-empty when a token is created, a client must provide the grabber-key when it tries to grab this token. Another operation difference is that when monitor channel is set, the token status and grabber change will be notified to all the members in the monitor channel. Such actions are not recommended in the T.120 protocol.
Token operations do not support non-uniform mode.
Extra data used in register-object events:
The following operations are associated with tokens and are similar to the token operations, with the exceptions noted above, defined in the ITU T.120 protocol.
The purpose of a roster object is similar to the T.120 GCC roster, which provides a means for client applications to announce its presence to its peers. However, the T.120 GCC roster can be inefficient when supporting a large number of participants through the Internet. The data structure, the functionalities and how it is propagated are implemented in a different way in accordance with principles of the present invention.
In the present invention, a roster object simply provides a general repository to store a list of records, each record associated with a client-server connection. Each application can decide if it needs its own roster according to its operation model.
Roster records are stored in a two tier tree structure. The root is a server, and leaf is a roster record associated with a local client-server connection.
A roster record is composed of:
If a client is disconnected, the local COMM-DB will remove the roster record associated with this connection from its repository, and, if the record is a public roster record, COMM-DB needs to propagate its removal to all the members in the monitor channel.
If a sub server is disconnected, the local COMM-DB will remove all the roster records under this server from its repository. Since the server disconnection event will be propagated to all the nodes within the domain, if is not necessary for COMM-DB to propagate this roster remove event to other members.
Roster operations only support none uniform mode.
Extra data used in register-object events
None
Roster Operations
Presence Announce and Update
The sequence of events occurring during a Presence Announce and Update roster operation is shown in
The following table shows the parameters used in presence-update events:
Table Object
A table object simulates a database table. Client applications can use the table object to store a list of records. Each record is identified by a 16-bit unsigned short Record-ID, and consists of an array of fields. Each record field is identified by an 8-bit index and consists of a octet string with maximum length of 65535 bytes.
The structure of a table record consists of:
Extra data used in register-object events
Table Operations
Insert Records Operation
A client application may issue a Table-Insert-Request command to insert records. Multiple records can be inserted at one request. The insert records operation supports both uniform and non-uniform mode. For non-uniform mode, the record id needs be generated by a client application and assured unique and no confirm is needed. For uniform mode, the request will be routed to the top COMM-DB, COMM-DB will generate a unique record id for this record, confirm the result and propagate the insertion to all the members joined its monitor channel.
The following table shows the parameters used in table-insert events:
Table Update Operation
A client application may issue a Table-Update-Request command to update a record. It can update either the whole record or update only partial fields of the record. The table update operation supports both uniform and non-uniform mode, as shown in
The following table shows the parameters used in table-u date events:
Delete Record Operation
Client applications may issue a Table-Delete-Record-Request to delete a table record. As shown in
The following table shows the parameters used in table-delete events:
Handle Object
A handle object relates to the ITU T.120 GCC Handle concept. It is used to generate a unique 32-bit Handle for a client application within the scope of a single domain. Extra data used in register-object events: None
The following operations are associated with handles and are similar to the handle operations defined in the ITU T.120 protocol.
A counter object provides a group of counters to client applications.
Extra data used in register-object events:
Counter Operations
Update Counter
The following table shows the parameters used in counter-update events:
Queue Object
A Queue object provides client applications with a shared storage to store a list of data items. The difference between a queue object and a table object is that each queue item is identified by its sender node id and send sequence number, and operation of update-queue-item is not supported. Queue objects support both uniform and non-uniform operation modes.
A Queue object consists of:
Extra data used in register-object events
Queue Operations
Add Item
A client application may issue a Queue-Add-Item-Request command to add a new queue item in both uniform and non-uniform mode, as shown in
The following table shows the parameters used in queue-add-item events:
Remove Item
A client application may issue a Queue-Remove-Item-Request command to remove a queue item.
The following table shows the parameters used in queue-remove-item events:
Edit Object
An Edit object provides a shared edit space for client applications to edit. Client applications only submit the changed portion rather than the whole edit data. Both uniform and non-uniform operation modes are supported by edit objects.
Extra data used in register-object events: None
Edit Operations
Update
a and 19b show the sequence of events for an edit-update operation in uniform and non-uniform modes, respectively. A client application issues an Edit-Update-Request command to update the edit data, along with submission of the changed portion. The COMM-DB will replace the specified area of the previous edit data with the submitted changed data.
The following table shows the parameters used in edit-update events:
Cache Object
A cache object provides an efficient way for client applications to manage, upload and download large cacheable documents, images, files, etc. The cache object can also leverage existing Internet cache infrastructure when the data travels through the Internet.
A cache object consists of a list of cacheable data items. Each cacheable data item is identified by a 16-bit unsigned short index. Cacheable data items are stored in the COMM-DB local file system so that a client application can download it through a standard web server via http get request, thus leveraging the prevalent internet cache infrastructure.
Extra data used in register-object events: None
Operations
Upload and Download Cacheable Data.
The following table shows the parameters used in cache-data-update events:
Adjust Pending Cache Data Upload and Download Order
Since client applications may request an upload or download of a large number of large blocks of cache data at same time, it is likely that the upload/download requests will get queued in each local connection buffer. The COMM-DB architecture according to principles of the present invention provides a means for a client application to dynamically adjust the pending upload and download order by issuing a cache-set-data-first command. The sequence of events occurring during the cache-set-data-first operation is shown in
The COMM-DB architecture and method of the present invention provide several advantages to a distributed multipoint communication system. Because the COMM-DB architecture is a real time distributed database managing resources in a hierarchical tree structure, the COMM-DB closely models the application resource data model. This enables the distributed multipoint communication system to operate efficiently. Additionally, since the COMM-DB is a distributed repository, rather than a central repository, the inventive architecture helps prevent the top server of the multipoint communication system from being overburdened. Further, the present invention provides ways to prioritized the transmission of resource data and provides an efficient and effective way to monitor and synchronize any database changes.
Having thus described various features of the invention, it will now be understood by those skilled in the art that changes in construction and differing embodiments and applications of the invention will suggest themselves without departure from the spirit and scope of the invention. The disclosures and the description herein are purely illustrative and are not intended to be in any sense limiting. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
