 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is related to teleconferencing systems. More
specifically, the present invention is related to mechanisms for
communicating data among a plurality of participants in an electronic
conferencing system.
2. Background Information
One of the more developing areas of computer networking is the field of
electronic conferencing. Conferencing provides the ability to have an
electronic on-line "meeting" between a plurality of users on computer
systems in a variety of locations. Users at a variety of sites may
communicate with one another as if they were in the same room. Using such
application programs, modern communication systems have enabled the
ability to have a meeting wherein all users participate in the meeting
through their individual computer systems and share data, graphics, text
and other types of information. Users may communicate with one another
sharing data in the form of graphical images, text or other annotations
and other information represented on the computer system display. This is
analogous to a meeting where participants in a face-to-face meeting may
display information to one another on a white or blackboard and other
participants may add annotations, delete or otherwise modify the board. It
is also anticipated that as bandwidth of communication media improves and
compression standards for graphical data also become more robust that
video data may also be shared among a plurality of connected users during
such teleconferences.
One of the requisites of an electronic conferencing system is the need to
replicate the same data on all users' displays participating in the
conference. Such systems typically implement this capability in a variety
of ways. The most common is the client/server model wherein a single
connected node acts as a "server" of other nodes in the system and the
remaining nodes connected in the conference act as slaves or clients to
the server process. Thus, each of the clients merely receive data from the
central machine to update their displays. Such systems, however, are
entirely dependent upon the service being provided by the server and the
throughput of the communication medium. Obviously, systems wherein the
clients merely act as displays and inputs for user requests suffer from
severe performance problems due to resulting updates of data from the
server, which is typically handled serially by the server.
Another prior art solution for maintaining all of a participant's display
in a conferencing system synchronous rely on a distributed client/server
system. In a distributed client/server approach a shared object structure
is kept on the server and clients are made aware of changes of that
distributed information through alerts or demons. The disadvantage of this
approach, similar to the centralized client/server approach is the
reliance on the architecture itself. This includes a data conferencing
application which must be able to connect several users over a phone line
from point to point without requiring access to a centralized common
server.
In the client/server approach, moreover, performance suffers greatly
because requests to add or delete objects such as annotations, graphical
images or other information on a participant's display is entirely
dependent upon communication from the server. Thus, real-time performance
severely suffers in prior art client/server models since approval to act
and manipulate upon objects on a participant's display is entirely
dependent upon a whole set of dependent variables such as the number of
requests to the server pending, the throughput of the communication
medium, the number of participants connected, etc.
Yet another prior art approach for maintaining synchronicity of a plurality
of participants in a conferencing system is the use of a distributed
object-oriented system. This is a generalized approach which relies upon
extensions, in one prior art solution, of the SmallTalk language itself.
In this prior art system, "local" objects send messages to "proxy" objects
which are local representatives for objects in the "shared" object space.
The proxy objects communicate with the real objects through an RPC (Remote
Procedure Call) mechanism. RPC is a protocol governing the method with
which an application activates processes on other nodes and retrieves the
results. Such a conventional mechanism is defined by Sun Microsystems,
Inc. and described in RFC-1057 that provides a standard for initiating and
controlling processes on remote or distributed computer systems.
The problem with this approach is in its generality which requires
extensive support for sharing any object while making no assumptions about
the behavior of objects. This has two disadvantages. First, a complex
"SmallTalk system" is needed to support the distribution of objects in
general. Second, the concurrency problem for any object is difficult
because multiple participants may have different objects in their systems
and such different objects may not be ale to be communicated to the
remaining users.
Yet another of the disadvantages of prior art data conferencing systems is
their ability to support the transfer of very large blocks of information.
Typically, such systems have relied upon point-to-point communication
schemes wherein individual nodes such as the server, in the client/server
model, must transmit the information from one individual node to the
server and then from the server to the remaining participants' systems.
Also, the transfer of very large pieces of data, such as files and/or
images or other data, consumes lots of resources in the system and
bandwidth of the communication medium. Thus, prior art conferencing
systems suffer from severe performance penalties caused by the amount of
data which may be transmitted within the system during a teleconference.
Thus, prior art data conferencing systems suffer from many disadvantages.
SUMMARY AND OBJECTS OF THE PRESENT INVENTION
The present invention relates to methods and apparatus for communication
between agents in an electronic conferencing system. In an electronic
conferencing system wherein data is shared between a plurality of
participants during an electronic conference, a method is disclosed for
maintaining consistency of the data among the participants during the
electronic conference. The method of the present invention comprises the
following steps:a) each participant in the electronic conferencing system
maintains a local copy of the shared data for the electronic conference
during the electronic conference;b) one of the participants commences to
perform modifications to an associated local copy of the shared data;c)
subsequent to the step of commencing modifications, a participant requests
an index for the modifications from an arbitrator participant, wherein the
modifications to the associated local copy of the shared data may continue
to be performed;d) the arbitrator participant responds to the participant
requesting the index for the modifications;and e) a participant modifies
the associated local copy of the shared data according to the index
received from the arbitrator participant and then transmits the local
modifications to the plurality of participants.
One of the objects of the present invention is to provide a data
conferencing system wherein real-time performance of individual
participants in a data conferencing system do not suffer from performance
problems due to medium throughput.
Another of the objects of the present invention is to provide an improved
data conferencing system which enable users to have more or less real-time
response from their individual systems in the conference.
Another of the objects of the present invention is to overcome the prior
art disadvantages of the client/server model provided in certain
conferencing applications.
Another of the objects of the present invention is to provide a system
which provides concurrency among a plurality of participants in a
conferencing application, however, not having the attendant disadvantages
of real-time impacts upon performance due to such demands of concurrency.
Another of the objects of the present invention is to provide the
capability to transfer very large pieces of data without impacting upon
real-time performance of users in a conferencing application program.
Other objects, features and advantages of the present invention will be
apparent from viewing the figures and the description which follows below.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation
in the figures of the accompanying in which like references indicate
similar elements and in which:
FIG. 1a illustrates a topology of a system in which various agents may be
connected in a conferencing system.
FIG. 1b illustrates a block diagram of circuitry contained in one agent
participating in a conferencing system.
FIG. 2 illustrates a block diagram of the various control procedures which
are present in an agent participating in a conference.
FIG. 3 illustrates a block diagram of classes used in one implemented
embodiment of the present invention.
FIG. 4 illustrates the types of annotations which may be performed upon a
user interface display of a single agent within various implementations of
the preferred embodiment.
FIG. 5 illustrates the object hierarchy used in certain embodiments of the
present invention.
FIGS. 6a and 6b illustrate process-flow diagrams of a process performed
upon detection of an event requiring the creation/deletion/modification of
objects during an electronic conference which may be executed from an
event loop of the object manager in one embodiment of the present
invention.
FIGS. 7a-7e illustrate object structures maintained by an arbitrator and an
agent in a conferencing system during various time periods when an agent
is performing actions in his local system. FIG. 8 illustrates a method
used for the deferred transfer of very large binary object data within
certain embodiments of the present invention. FIG. 9 illustrates an object
data request process flow diagram used in one embodiment of the present
invention. FIG. 10 illustrates the determination of a transport qualifier
used for transferring large object data in one embodiment of the present
invention. FIG. 11 illustrates a process flow diagram of a process used
for determining the need for a partial request of large object data in one
embodiment of the present invention. FIGS. 12a-12c illustrate various
stages of completion of the transfer of very large object data in one
embodiment of the present invention. FIG. 13 illustrates the Background
Transfer Manager architecture. FIGS. 14-15 illustrate the processing logic
for the participant Connection/Disconnection Logic. FIG. 16 illustrates a
transfer queue entry. FIG. 17 illustrates an example of the transfer
request reprioritization process. FIG. 18 illustrates an example of the
Clear-to-Send processing of a transfer queue entry. FIGS. 19-20 illustrate
the Request Processing Logic of the present invention.
DETAILED DESCRIPTION
The present invention relates to methods and apparatus for communication
between agents in an electronic conferencing system. Although present
invention will be described with reference to specific signal names,
formats, time intervals and other specific information, these are to be
viewed to be used for illustration purposes only and not to be construed
as limiting the present invention. It can be appreciated by one skilled in
the art that many departures and modifications may be made without
departing from the overall spirit and scope of the present invention.
As illustrated in FIG. 1a, a communication system may comprise a plurality
of agents such as 11-14 which are all coupled to a communication medium,
e.g., 20 illustrated in FIG. 1a. In certain embodiments of the present
invention, each individual agent coupled to the medium 20 has equivalent
capabilities to provide communication between the agents. The implemented
conferencing system uses a distributed approach wherein each of the agents
11-14 maintains local copies of the conferencing structure (called a
"meeting") which shall be consistent with one another. In addition, one of
the agents 13, in one embodiment of the present invention, acts as an
arbitrator to grant requests to add objects to various structures within
each agent to maintain consistency among the displayed objects on each of
the agents' systems. The system used in various embodiments of the present
invention uses a distributed architecture, wherein each agent 11-14
maintains local copies of all the objects being used in the electronic
conference. Thus, displays, text, graphics and other information displayed
on the agents' computer system displays are represented in data structure
maintained in each of the systems' local memory and/or media devices
coupled to those systems. Thus, the present system comprises a hybrid of
the client/server architecture wherein, instead of maintaining centralized
copies of all the objects in the electronic conferencing system, each
agent maintains a local copy of the data so that changes to the data may
be more or less immediate. The structure of one agent, which may be
coupled to the communication medium such as 20 illustrated in FIG. 1a, is
illustrated with reference to FIG. 1b.
Referring to FIG. 1b, a system upon which one embodiment of an agent (e.g.,
11 of FIG.1a) of the present invention is implemented is shown as 100. 100
comprises a bus or other communication means 101 for communicating
information, and a processing means 102 coupled with bus 101 for
processing information. System 100 further comprises a random access
memory (RAM) or other volatile storage device 104 (referred to as main
memory), coupled to bus 101 for storing information and instructions to be
executed by processor 102. Main memory 104 also may be used for storing
temporary variables or other intermediate information during execution of
instructions by processor 102. System 100 also comprises a read only
memory (ROM) and/or other static storage device 106 coupled to bus 101 for
storing static information and instructions for processor 102, and a data
storage device 107 such as a magnetic disk or optical disk and its
corresponding disk drive. Data storage device 107 is coupled to bus 101
for storing information and instructions. System 100 may further be
coupled to a display device 121, such as a cathode ray tube (CRT) or
liquid crystal display (LCD) coupled to bus 101 for displaying information
to a computer user. An alphanumeric input device 122, including
alphanumeric and other keys, may also be coupled to bus 101 for
communicating information and command selections to processor 102.An
additional user input device is cursor control 123, such as a mouse, a
trackball, stylus, or cursor direction keys, coupled to bus 101 for
communicating direction information and command selections to processor
102, and for controlling cursor movement on display 121. Another device
which may be coupled to bus 101 is hard copy device 124 which may be used
for printing instructions, data, or other information on a medium such as
paper, film, or similar types of media. In the described embodiments,
another device which is coupled to bus 101 is a communication device 125
which is used for communicating with other agents. This communication
device may include any of a number of commercially available networking
peripheral devices such as those used for coupling to an Ethernet or
Token-Ring communication medium. Note, also, that any or all of the
components of system 100 and associated hardware may be used in various
embodiments, however, it can be appreciated that any configuration of the
system may be used for various purposes according to the particular
implementation.
In one embodiment, system 100 is an IBM compatible type personal computer.
Processor 102 may be one of the 80.times.86 compatible microprocessors,
such as the 80386, 80486 or Pentium.TM. brand microprocessor manufactured
by Intel Corporation, Inc. of Santa Clara, Calif.
Note that the following discussion of various embodiments discussed herein
will refer specifically to a series of routines which are generated in a
high-level object oriented programming language (e.g., the Microsoft
C/C++) available from Microsoft,Inc. Redmond, WA. This series of routines
is compiled, linked, and then run as object code in system 100 during
run-time. It can be appreciated by one skilled in the art, however, that
the following methods and apparatus may be implemented in special purpose
hardware devices, such as discrete logic devices, large scale integrated
circuits (LSI's), application-specific integrated circuits (ASIC's), or
other specialized hardware. The description here has equal application to
apparatus having similar function.
Software Organization of an Agent
Operative within each agent during conference run time is a series of
software procedures which are organized in the manner illustrated with
reference to FIG. 2. FIG. 2 illustrates 200 which is a general block
diagram of the organization of the processes within a single agent in one
embodiment of the present invention. The software organization 200 within
a single agent comprises a multi-point process 240 which is responsible
for direct communication onto the communication medium 260 so that other
agents 250 may be communicated with. This provides all the low-level
communication functions which allow direct accessing communication medium
260. In different embodiments of the present invention, communication
medium 260 may be any one of the various networking standards used
including local area networks such as Ethernet, Token-Ring or other types
of networking standards. Communication medium 260 may also be a telephone
network and modem connection or other data communications medium.
Multi-point function 240 thus provides all the necessary packetization and
responses to communication received over communication medium 260.
The next higher level in the software organization 200 of a single agent is
the conference manager 230 which provides all the necessary executive
functionality for communication with the low level communication functions
240 and the higher level functions provided by the human interface process
210 and the object manager 220. The conference manager 230 controls the
object manager 220 through a series of callbacks to commands in the
conferencing system which are desired to be executed. Conference manager
230 also executes the callbacks in object manager 220 according to
messages which are received from the communication process 240 and directs
the creation, deletion or other action upon objects in the system. As will
be described in more detail below, objects within the system such as
annotations, pages, commands and other objects used within the system are
treated using an object-oriented system wherein hierarchies of objects are
defined. This will be described in more detail below.
Communication from object manager 220 to conference manager 230 is provided
via messages which are passed to the multi-point link manager 240 for the
creation of objects, arbitration between the arbitrator and the agent and
communication with other agents in the conference. Moreover, conference
manager 230 directs human interface process 210 via pointers to display
various things on the display. Results from the display of human interface
functions are passed back to the conference manager 230 via messaging.
Object manager 220 is a process which is operative during run time to keep
track of the various objects used during a conference between the agent
and other agents in the system. The object manager coordinates the meeting
between the agents. The object manager keeps track of all objects created
during the meeting, including, other agents, the various things displayed
during the conference and other objects. In addition, the object manager
is used for maintaining the status of the meeting and keeping all the
other agents synchronized with the current agent. Contents of a meeting
may be saved and retrieved from mass storage (e.g., 107 of FIG. 1b) when
exiting or entering a conference. The object manager also exchanges
meeting contents with other object managers in other agents to keep copies
of the meeting synchronized.
Each object manager 220 maintains its own local copy of the meeting which
is provided to human interface 210 as required. Object manager 220 informs
human interface 210 about changes from other agents participating in the
meeting. Human interface layer 210 then may adjust the display as
directed. Human interface 210 also informs the object manager about
changes that the user wishes to make to the current meeting. Object
manager 220 then synchronizes the changes with all other object managers
participating in the meeting. The object manager controls the human
interface through messaging, as does the human interface direct the object
manager to perform certain actions upon objects, according to the
adjustment of the display under control of human interface 210. A brief
overview of the structure of objects in one embodiment of present
invention is illustrated with reference to FIG. 3.
Object Classification Structure
FIG. 3 illustrates a general classification of the high level objects which
are used in one embodiment of the present invention. In this embodiment,
the object manager class 300 comprises the broadest classification of
objects within the system. Generally, within the object manager class, are
two general areas, public meetings 310 and private meetings 320. The
object manager maintains information that the user has entered into his
private space in the private meeting object class 320 which is distinct
from the public meeting object class 310. Each is maintained as a separate
structure of objects within the meeting class. Therefore, during a public
meeting stored in public meeting class 310, a user may similarly store
private information 320 also to be associated with that same meeting.
In addition, object manager 220 maintains information about the user in
classification 330 and arbitrator 340, of which there is only one during
any one electronic conference and the other participants in the meeting in
a participants classification 350. These are all also members of the
object manager class. Object manager 300 keeps track of the participants
in the meeting, such as when new participants join the meeting new
participants' copies of the meeting are brought into synchronization with
all of the other participants'. As participants leave the meeting, all of
the users' contributions are ensured to be shared before the participant
leaves the meeting.
One of the agents or participants in the meeting is known as the
arbitrator. This is represented in the arbitrator class 340. The
arbitrator resolves conflicts between users when question of control of
meeting properties arise. The arbitrator determines which participant
controls an annotation, how many pages exist in the present meeting,etc.
It also keeps a master copy of the meeting that all other participants
synchronize to. Object mangers within each agent or participant coordinate
who the arbitrator is and assign a new arbitrator when the assigned
arbitrator leaves the meeting or as dictated by other conference
events--such as opening/merging a meeting file in which the participant
opening/merging the meeting file becomes the arbitrator prior to
opening/merging the file. In one implementation of the present invention,
the first user to start a meeting is assigned the arbitrator.
A very rough approximation of the types of objects which may be present
upon a participant's display is illustrated with reference to FIG. 4.
Generally, a user will have a meeting area 400 on his display in which
various information may be entered. Typically, each meeting comprises a
series of pages which is analogous to a single white board or shared
display space which users in a room could access. Analogously, one
embodiment of the present invention uses the notebook metaphor which is,
in fact, a shared "notebook" among a plurality of participants in the
meeting into which every participant may enter information. The shared
area or notebook comprises a plurality of pages 410 onto which annotations
may be made. Users may create or delete pages at will, subject to certain
conditions. Annotations on the pages may comprise one of at least four
types, in one embodiment of the present invention. The first three of
these types are illustrated in FIG. 4. For instance, a page 410 may
comprise a drawing annotation 411 which is typically an object-oriented
drawing created by a single user. Such object-oriented drawing
illustrations as 411 comprise a description of point positions and
segments between them and are well-known to those in the prior art.
Annotations may also comprise graphic annotations 412 which are generally
bit-map representations of graphic image data. Textual annotations 413 may
be placed upon a page. Textual annotations can be any of the user's
choosing and, including in certain prior art implementations, allowing
users to choose style, point size, font and other formatting information
as is typical in the prior art. One other annotation which may be used in
one embodiment of the present invention is the OLE annotation using the
Object Linking and Embedding (OLE) protocol available from Microsoft
Corporation of Redmond, Wash. OLE annotations may reference other
"objects" created and/or maintained by other application programs and
which may be either linked or embedded using OLE. Each of these
annotations is stored as an object under an "annotation" classification
which is associated with objects in the page classification. FIG. 5
illustrates the classification for objects used in one embodiment of the
present invention.
The overall structure of the object classes is illustrated with reference
to Figure 5. FIG. 5 includes the meeting object, user, arbitrator,
participants and annotation objects which were discussed and illustrated
with reference to FIGS. 3 and 4 above. In FIG. 5, relationships are
illustrated with reference to the dotted line/solid bar representation
wherein inheritance relationships are shown by the arrowhead with the
direction of the inheritance following the orientation of the arrowhead.
In addition, each of the relationships illustrated in the figures indicate
multiple relationships. That is, if a relationship is n:1 that means that
there may be n of the sub-class objects under the parent object. For
example, as was illustrated and discussed with reference to FIG. 3 and now
shown on FIG. 5, the CObjectManager 501 has two CCMeeting object classes:
the "public" meeting and the "private" meeting shown in FIG. 3. In
addition, the CCMeeting object class 506 has Participant objects 509
associated with it, those shown as 350 in FIG. 3. In addition, the
CCMeeting object classification 506 references the CCPage object 508. The
CCPage classification is used for defining all the pages which may fall
under a specific meeting. Under the CCPage classification 508, are the
annotation classifications (under the class CCAnnotation 532) which are
shown with their various inheritance relationships in the lower section of
the diagram. Thus, the CCAnnotation classification 532 may comprise
objects inheriting all relationships of the annotation object, for text
annotations contained within the class CCTextAnnotation 521, the
CCGraphicAnnotation 522 for representing graphic or bitmap annotations
such as 412 in FIG. 4 and the CCDrawAnnotation class 523 for referencing
drawing annotations such as 411 shown in FIG. 4. One other annotation
which may be used in one embodiment of the present invention is the
CCOLEAnnotation class 520 which is part of the COLEDocument classification
503 for performing object linking and embedding using the Object Linking
and Embedding (OLE) protocol available from Microsoft Corporation of
Redmond, Wash. Annotations may, thus, be references to "objects" created
and/or maintained by other application programs and which may be either
linked or embedded using OLE.
Other classifications are available from the Object Manager, classification
501 such as the CCPerson classification 512 which is associated with a
CCPassword classification 510 for associating user passwords with person
objects. Also, each person has an associated CCAddress class 513 and a
CCPhone class 514 for defining participant network addresses and/or access
telephone numbers.
Finally, the remaining set of object classes shown in FIG. 5 includes the
CCCachableBlob object classification 515 and the CCBlob class 516 which
has a relationship and inherits characteristics from the annotation object
classification and the CCCachableBlob object classifications 532 and 515.
The CCBlob 516 is used for representing very large objects in various
embodiments of the present invention. Various embodiments of the present
invention allow very large binary objects, known in this embodiment as
Binary Large Objects or BLOBs, which may be any type of data. These very
large binary objects may also be shared and distributed among users.
Further, various embodiments of the present invention allow for such
objects to be transferred only upon demand of specific users and/or when
medium traffic allows. In this manner, the communication medium is not
burdened with the task of transmitting these very large binary objects,
unless absolutely required. Very large binary objects or BLOBs may be used
for representing any type of information, however, in certain embodiments
they may only be used for representing large bitmap data or other
graphical image data such as compressed animations or audio information
such as those represented in MPEG (Motion Picture Experts Group)or JPEG
(Joint Photographers Experts Group) format. It is anticipated in
alternative embodiments that other binary data may be transmitted using
these techniques, including executable program data.
Overview of Operation of Deferred Synchronization
As already has been discussed, each of the participants in a conference
maintains its own data regarding the current state of display of the
shared notebook for all users in the conference. In this manner, no
individual participant is dependent upon the accessing of a central server
for the display of its own information. However, a special participant in
the conference is known as the "arbitrator" and the arbitrator maintains
an "official version" of a meeting. All other participants are required to
keep their versions synchronized with the arbitrator's official copy. A
second participant may become an arbitrator either upon its own request or
upon the arbitrator desiring to cease participating in the conference. In
this case, all other participants are also informed of the change and a
new arbitrator can start functioning. In one embodiment of the present
invention, the arbitrator of a conference is the original participant that
began the meeting.
The arbitrator also acts as a central system upon which annotations in the
official copy of the meeting structure are approved. Although users may
make changes to their own local copies of the meeting structure in
real-time, without authority from the arbitrator, in order for the meeting
to be maintained as consistent among all the participants, the arbitrator
must make a final decision about the position of certain annotations. The
allowing of a single participant to modify its meeting structure without
the authority of the arbitrator and the later synchronization of that
meeting structure with the other participants in the conference will, for
the remainder of this application, be referred to as deferred
synchronization.
Associated with each page and annotation class object in the meeting
structure is a variable indicating whether the page or annotation has been
synchronized with other participants in the conference. This is known as
the "blocked" flag and this flag is set true until the page or annotation
object has been synchronized with the other participants. In addition, the
arbitrator maintains and grants object indices to new objects as they are
created and/or modified by a particular agent, thus keeping the entire
meeting synchronized among all the participants. The agent then requesting
the addition and/or modification of objects receives messages from the
arbitrator indicating a new object index, so that the participant may
update his local meeting structure to comply with the remaining
participants in the meeting. In addition, the blocked flag may then be
changed to false indicating that the objects in question are now
synchronized and no further communication needs to be performed with the
arbitrator for the present time.
For example, one participant may decide to add an annotation to an existing
page. Human Interface process 210 detects this request and sends a message
to object manager 220 in order to add the annotation. Then a request is
sent by the object manager 220 of the requesting participant to the object
manger of the arbitrator. In addition, the object manager will add an
object to its local meeting structure with the flag indicating that the
annotation is "blocked" indicating that the object has not been
synchronized with other participants in the meeting. In addition, in the
communication to the arbitrator, the participant has indicated its
participant index and a request for an object index from the arbitrator.
Then the user of the agent may continue operation upon the annotation,
until the object index is received back from the arbitrator. Once the
object index has been received, the participant may update its meeting
structure to comply with the index received back from the arbitrator. A
more detailed discussion of this will be shown and discussed with
reference to FIGS. 6a-7e.
Detail of Process for Deferred Synchronization
FIGS. 6a and 6b illustrate detailed process steps for a process 600 which
may be executed upon the detection of a request to execute a command
requiring synchronization with other participants in a meeting within the
event loop of the conference manager. Thus, process 600 may be entered
upon detection of a creation of a new object, modification of an existing
object or the deletion of an object as detected by human interface 210 on
FIG. 2. Process 600 may start at a typical process entry point such as 601
illustrated in FIG. 6a. Then, it is determined whether the command is one
which requires deferred arbitration at step 602. If not, then the current
operation may be performed with normal communication and the associated
latency, if any, between the current agent and any other participants in
the conference at step 613. Then, at step 620, process 600 may exit at a
typical process exit point.
If, however, it was a command which requires deferred arbitration, that is,
timing requirements for meeting synchronization are relaxed and the user
may make any modifications to the local meeting structure without the
latency incurred by synchronization with other agents and continues at
step 603. At step 603 it is determined whether the current command has
occurred to change an object which is already "blocked". An object will
only be indicated as blocked if it has been determined that the object was
previously modified, deleted or added and the object has not yet been
synchronized with other participants in the conference. This flag, as
already discussed, is only set upon detection of a change, but prior to
the assignment of an object index by the arbitrator. If it is not blocked
(e.g., this is an initial action upon the object), then at step 604, it is
determined whether the request has been detected for a deletion of the
object. Deletion requires a specific series of steps, since ownership of
all the objects requested to be deleted must be acquired prior to any
deletion. This process also requires communication with other participants
in the conference as shown on FIG. 6b. First, at step 614, it is
determined whether ownership of the object has been obtained. This
includes ownership of all the objects and sub-objects. If not, then such
ownership is requested from each of the owners of the objects at step 615.
If ownership is granted, as detected at step 616, or ownership of the
object had already been obtained as detected at 614, then the process may
continue back at step 605 illustrated on FIG. 6a. If not, then the delete
failed as indicated at step 617, and the process returns at a typical
process exit point such as that shown as 620 in FIG. 6a.
At step 605 it has now been determined that the object is one which has
previously not been blocked, that is, it has previously been synchronized,
and now some sort of change is occurring to the object. Thus, when this
occurs, a request must be sent to request an object index for the object
in order for the participant to be synchronized with all the other
participants. However, the user may continue to make changes and perform
other operations even prior to the receipt of the object index from the
arbitrator. Thus, changes will therefore be local only, until the later
synchronization of the meeting structure of the requesting participant
with other participants in the meeting. The requested changes by the user
are performed locally only at step 606, making all changes to the meeting
structure which are permissible, and the changes are indicated as blocked
at step 607. Then, this sub-process within the event loop may be exited at
step 620, a typical process exit point.
Process 600 continues through the initial steps, 601,602 and 603 for
blocked objects for which commands have been received. If the object is
detected as "blocked", that is a request has been sent to the arbitrator
for an object index, however, no response has yet been received the
process 600 continues at step 609. Step 609 detects whether the response
containing the object index has been received from the arbitrato | | |
