as United States
`a2) Patent Application Publication co) Pub. No.: US 2003/0018717 Al
`
` Haleyet al. (43) Pub. Date: Jan. 23, 2003
`
`
`US 20030018717A1
`
`(54) EXTENSIBLE INFORMATION
`DISTRIBUTION MECHANISM FOR SESSION
`MANAGEMENT
`
`(76)
`
`.
`Inventors: Michael Haley, San Rafacl, CA (US);
`Lars B. Karle, Portsmouth, RI (US)
`
`(52) U.S. Ce ieee cee seeseesetesnserteensees 709/205; 709/228
`
`(57)
`
`ABSTRACT
`
`Correspondence Address:
`PATENTATTORNED. PC
`57 CENTRAL ST
`,
`PO BOX 782
`ROWLEY, MA 01969 (US)
`
`A technique for managing conference state. Endpoints of the
`conference are application processes (1803) running on
`computer systems that are connected by a WAN (1811).
`Each of the application processes (1803) maintains endpoint
`state for the conference. A session manager process (1812)
`in each of the computer systems maintains session manager
`state for each of the conferences that has an endpoint on the
`computer system. The session manager conference state
`10/069,255
`(21) Appl. No.:
`includes a copy
`of the endpoint state for each of the
`:
`
`
`22) PCT Filed:=Mar. 23, 2001 me PY P
`
`
`(22)
`ve
`abs
`Ams
`conferences and the session manager (21) uses a locking
`(86) PCT No.:
`PCT/US01/09204
`mechanism to that the copies of the session manager con-
`ferencestate in all of the session managers(21) are identical.
`Related U.S. Application Data
`Whenan endpoint changesits endpoint state, it informs the
`
`
`
`
`
`60) 60/191,707, filedonMProvisional application No. session manager (21), the session manager (21) incorporates
`(60) 33,2000. apphcahon
`No.
`9
`ts
`Bled On
`NAT.
`the change into its session manager conference state, and
`,
`,
`when the locking mechanism permits, exports the change to
`Publication Classification
`the session managers (21) for all the other endpoints. When
`the session manager (21) receives a change, it incorporates
`the change into its session manager conference state.
`
`(SD)
`
`TIM, Cncecceccccssssssstecsessssseteecessssneesen GO6F 15/16
`
` Locate desired
`
`conference
`
`(100)
`
`
`
`
`onferencé
`Create new
`
`
`
`exists?
`conference
`
`
`
`(101)
`(102)
`
`
`
`
`Shutdowa
`Perform
`
`
`
`conference and close
`collaborative
`Conference
`
`
`
`
`Over?
`application
`application tasks
`
`
`
`
`(140)
`(103)
`
`
`
`
`Induce changes to
`conference specific
`
`object
`
`(107)
`Generate
`Decode info
`
`
`
`corresponding
`
`object
`info object
`
`
`(108)
`(105)
`
`
`
`Create or change
`conference
`
`specific object
`
`
`
`
`
`Session manager
`Supply info object
`
`
`to session
`notification of changed
`
`
`manager
`or new Info object
`
`
`(106)
`(108)
`
`
`
`
`Google Exhibit 1028
`Google v. VirtaMove
`
`Google Exhibit 1028
`Google v. VirtaMove
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 1 of 19
`
`US 2003/0018717 Al
`
`LA
`
`NETWORK
`
`Figure l
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 2 of 19
`
`US 2003/0018717 Al
`
`
`
`Figure 2
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 3 of 19
`
`US 2003/0018717 Al
`
`
`
`Figure 3
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 4 of 19
`
`US 2003/0018717 Al
`
`WORKSTATIONENVIRONMENT
`
`
`
`
`
`NETWORK
`
`Figure 4
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 5 of 19
`
`US 2003/0018717 Al
`
`WORKSTATION ENVIRONMENT
`
`
`
`NETWORK
`
`Figure 5
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 6 of 19
`
`US 2003/0018717 Al
`
`
`
`20
`
`Z20A
`
`
`
`20B
`
`_ 1
`
`SM
`
`21A
`
`
`
`
`[Lady
`S|
`21 a
`| |
`
`
`
`
`
`Figure 6
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 7 of 19
`
`US 2003/0018717 Al
`
`20
`
`
`21
`
`Figure 7
`
`

`

`US 2003/0018717 Al
`
`Jan. 23,2003 Sheet 8 of 19
`
`
`
`Patent Application Publication
`
`Figure 8
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 9 of 19
`
`US 2003/0018717 Al
`
`
`Oo 21
`
`
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 10 of 19
`
`US 2003/0018717 Al
`
`
`
`22
`
`Figure 10
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 11 of 19
`
`US 2003/0018717 Al
`
`
`
`Figure jl
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 12 of 19
`
`US 2003/0018717 Al
`
`Figure 12
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 13 of 19
`
`US 2003/0018717 Al
`
`(100)
`
`Locate desired
`conference
`
`
`
`
`onference
`Create new
`exists?
`conference
`
`
`(101)
`
`
`(102)
`
`
`
`
`
`
`
`
`Create or change
`conference
`specific object
`(104}
`
`
`Induce changesto
`conference specific
`object
`(107)
`
`
`Perform
`Yes
`collaborative
`Conference
`
`
`application tasks
`
`Over?
`
`
`(103)
`
`
`
`
`
`
`
`
`Generate
`
`corresponding
`info object
`(105)
`
`
`
`Decode info
`object
`(108)
`
`
`
` Supply info object
`
`
`to session
`manager
`(106)
`
`Session manager
`notification of changed
`or new info object
`(109)
`
`Shutdown
`conference and close
`application
`
`(110)
`
`Figure 13
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 14 of 19
`
`US 2003/0018717 Al
`
`Requestto locate a
`conference
`(200)
`
`Logic
`(199)
`
`Communicate
`request to the
`session manager
`(201)
`
`Contact specified
`remote session
`
`manager
`(202)
`
`Return failure
`to application
`(204)
`
` Application
`
`Return conference
`identifier to
`appllication
`(207)
`
`Retrieve
`conference
`information
`(205)
`
`Store conference
`info object
`in repository
`(206)
`
`Figure 14
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 15 of 19
`
`US 2003/0018717 Al
`
`
`
`Application
`Logic
`(299)
`
`
`
`
`
`
`Create new
`Join
`Create conference
`conference
`conference
`
`info object
`
`(300)
`
`(301)
`(307)
`
`
`
`
`
`
`
`Communicate
`Set conference
`
`conference info to
`
`
`as parent object
`of session object
`session manager
`
`
`(309)
`(303)
`
`
`
`Communicate
`
`
`Is
`No
`
`session info to
`unique?
`
`session manager
`
`
`(304)
`
`
`(310)
`
`
`Build session
`Set parent of
`
`object describing
`info object to
`
`NULL
`this end-point
`
`
`(308)
`(302)
`
`
`
`
`
`(305)
`
`Return failure
`to application
`
`Yes
`
`Add info object
`into repository
`
`(306}
`No
`
`Return success
`to application
`(312)
`
`
` Communicate info
`
`Ina
`object to other SMs in
`hierachica! conf?
`
`
`Yes
`parent conference
`
`(313)
`
`Figure 15
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 16 of 19
`
`US 2003/0018717 Al
`
`
`
`Create or modify
`conference specific
`object
`(400)
`
`Application
`Logic
`(399)
`
`
`
`Generale info object
`
`describing conference
`specific object
`
`(401)
`
`
`
`Communicate info
`obyect to
`session manager
`(402)
`
`Get parent
`conference from
`repository
`(403)
`
`(409)
`
`Return success
`(412)
`
`Find tock token
`for new info object
`
`Returnfailure
`(408)
`
`Release token
`(411)
`
`7
`
`.
`
`Wait for token
`(406)
`
`Communicate info
`object to SMsin
`parent conference
`(410)
`
`Store
`
`object
`info
`ore In oe ec
`in reposkory
`
`Figure 16
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 17 of 19
`
`US 2003/0018717 Al
`
`
`
`Info object
`
`
`Wait for
`communicated over
`
`
`network event
`WAN to SM
`
`(499)
`
`(500)
`
`
`
` Locate parent
`
`
`conference
`
`(501)
`
`
`
`Found
`Discard info
`
`Conference?
`
`object
`
`(502)
`(503)
`
`
`
` Store info object
`
`in repository
`
`(504)
`
` Determine
` Communicate
`
`- applications using
`
`this conference
`
`
`
`(505)
`
`info abject
`to application
`(506)
`
`
`
`
`
`
`Figure 17
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 18 of 19
`
`US 2003/0018717 Al
`
`
`
`Application
`process 1803(a)
`
`.
`
`.
`
`.
`
`
`
`
`
`
`
`Application
`
`
`code 20A
`
`
`
`
`Applicatian
`
`objects 30
` {application-
`
`
`specific
`representation)
`
`
`application process 1803(i) Process memory 1805
`
`
` wheneramenewenenesewenmerecnnnnaenneneereseeiteedneneenrecewey
`
`wrebeanneeneen|eeeeeeeeeeee
`
`
`
`
`
`Application
`DTD 1809
`fi{i{i:i:ii i11!tt{‘ it‘{i‘;t 'iit
`
`
`Framework
`code 20B
`
`
`
`Chent interface code 21A
`
`App
`pmcess
`:
`.
`
`
`
`
`iothr able
`infoobjects
`Info objects
`
`
`
`
`
`
`41819
`31 for
`Lock queues
`Info obj
`for
`
`
`
`
`=
`-
`1816
`-
`location table
`app. process
`
`1817
`1803(n)
`
`
` _
`
`(XML)
`
`SM
`
`DTD 4821
`
`
`- 1813(n)
`-----f----repository21B
`
`
`Networkinterface code 216
`
`
`
`
`process 1812 for session manager 21
`CT
`
`
`1801
`
`

`

`Patent Application Publication
`
`Jan. 23,2003 Sheet 19 of 19
`
`US 2003/0018717 Al
`
`Object URL 1907
`
`Parent URL 1911(1)
`
`
`
`
`Parent
`fist 7909
`
`Child hist
`4913
`
`Locklist
`1917
`
`Session’
`manager
`informa-
`tion
`1903
`
`Applica-
`ion
`informa-
`tion
`1905
`
`
`1914(n)
`
`Child URL 1915(1}
`
`
`1915(m)
`
`
`
`Lock URL 1919(1)
`
`1919{0)
`
`-
`
`.
`
`-
`
`——
`
`

`

`US 2003/0018717 Al
`
`Jan. 23, 2003
`
`EXTENSIBLE INFORMATION DISTRIBUTION
`MECHANISM FOR SESSION MANAGEMENT
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This patent application claims priority from U-S.
`provisional patent application No. 60/191,707, Michael B.
`Haley, et al., Extensible information distribution mechanism
`for session management, filed Mar. 23, 2000.
`
`BACKGROUND
`
`[0002]
`
`1. Field of Invention
`
`[0003] This inventionrelates to the dissemination of infor-
`mation in networked computer software, specifically for the
`purposes of distributed session management,
`that
`is,
`the
`managementof participating users and software modules in
`a distributed computing enviromnent
`
`[0004]
`
`2. Description of Prior Art
`
`It is common modern software practice to develop
`[0005]
`software applications which are distributed. Examples of
`such applications range from video conferencing systems to
`virtual environments and 3D games. Typically, when a
`distributed software application is running,it manifests itself
`as a collection of software applications, with each applica-
`tion running, on a workstation connected to the public
`Internet. The public Internet may be considered to operate as
`a wide area network (WAN). In our discussion here the term
`“end-point” will be used to refer to a particular application
`executing on a single workstation.
`
`[0006] These distributed software applications group each
`end-point into a conference of end-points. Here the term
`“conference”refers to the logical grouping of the end-points.
`The establishing of this conference of end-points is a com-
`plex process due to the simplicity of the underlying WAN
`protocols. Furthermore, once end-points are grouped into a
`conference it is necessary to communicate state and con-
`figuration data of the end-point applications between each
`participant. Once again this is a complex task to perform
`reliably and efficiently.
`
`In these applications a “session-manager” software
`[0007]
`componentis usually employed. This software componentis
`responsible for identifying and monitoring the participants
`in the conference and can also be made responsible for
`communicating the state and configuration information
`between end-points. Traditionally session-manager imple-
`mentations suffer from many flaws that we have overcome
`in our invention.
`
`[0008] The session-manager approach was used in the
`MBONEproject in early 1990 as presented by Hans Eriks-
`son in “MBone—The Multi-cast Backbone, INET 1993. In
`the MBONEproject a “session directory” application was
`provided which managedthe list of people with whom one
`might communicate using the IP multicast standard. Numer-
`ous protocols such as the scssion announcement protocol
`(SAP) and the session initiation protocol
`(SIP) were
`employed in this implementation. This manifestation of
`scssion management was very simple and included only the
`most basic information about the user such as a name and a
`location. It did not include any information regarding the
`uscr’s application or any information about other forms of
`
`communication open betweenusers. Also it did not operate
`as a readily usable process for applications to use for session
`management.
`
`[0009] Most “session-management” applications gener-
`ally execute as external processes on all computer worksta-
`tionsthat are participants in collaborative network sessions.
`The main application software will communicate with the
`“session-manager” to advertise its presence to the other
`participants of a conference or to announcethe existence of
`a new conference. (In our terminology here a “conference”
`refers to a logical grouping of end-point applications on the
`same WAN.) When an end-point application terminates or
`disconnects from the conference the “session-manager” ts
`also responsible for announcing this fact to the other par-
`ticipants.
`
`In most applications the usc of the “scssion-man-
`[0010]
`ager” to locate other participants and to announce one’s
`presence is only a first step. Normally this will be the
`prerequisite for initiating some other form of communica-
`tion between the known participants. An example of this
`would be a video conferencing application where once the
`participants in the videoconference are known, a digital
`video signal is generated from numerous end-points and is
`communicatedto all other end-points.In order to generalize
`and automate the initiation of this other form of communi-
`
`cation it is necessary to communicate its parameters and its
`nature between the participants. This type of “extended”
`behavior is not provided by most session manager imple-
`mentations and this is the focal point in the design of our
`system.
`
`[0011] Most early systems that required session manage-
`ment used a client-server approach, as maintaining data at a
`single source obviates the need for complex arbitration or
`locking techiniques. Howeverthese client-server based sys-
`tems suffer from numerous disadvantages such as:
`
`(a) Low error tolerance—if the server [ails
`[0012]
`then everything fails.
`
`(b) Lack of scalability—all participants need
`[0013]
`to communicate to the same network end-point.
`When the numberofparticipants exceeds a threshold
`the communication becomesprohibitively slow and
`eventually impossible.
`
`[0014] The reliability and scalability problems of the
`centralized session managers can be overcome using dis-
`tributed session managers. Examples of this approach are:
`
`[0015] U.S. Pat No. 5,748,618 to Rothrock (1998) dis-
`closes a mechanism for arbitration in a distributed data
`conferencing system for accessing shared data stored using
`a hierarchical representation. The patent is concerned with
`sharing visual data in small-scale (not suffering from the
`disadvantages mentioned above) collaborative environ-
`ments and does not consider scalability issues of moving to
`larger systems as well as generalized data distribution
`between conference participants.
`
`[0016] Similarly U.S. Pat. No. 6,643,010 to Ciscon (1997)
`addresses solcly the communication of data between cxter-
`nal processes. No consideration is given to the greater
`problem of identifying external processes and logically
`grouping them into conferences.
`
`

`

`US 2003/0018717 Al
`
`Jan. 23, 2003
`
`[0017] Some software systems (for example the Nexus
`system for developing applications, describedin I. Foster, C.
`Kesselman, Tuecke, “The Nexus Approach to Integrating
`Multithreading and Communication”, Journal of Parallel
`and distributed Computing, 37:70-82, 1996), provide ses-
`sion-management functionality.
`
`[0018] None of the prior-art session managers is both
`completely distributed and completely extensible. Session
`managers with these characteristics are required to support
`modern collaborative network software. Problems in the
`
`design of completely distributed session managers include
`the division of session management tasks between the end
`point and the session manager, the amount of state main-
`tained in each session manager, and avoiding deadlock and
`race conditions in making changesin the session managers.
`Problemsin the design of easily extensible session managers
`include making it possible to add new kindsof applications
`and conferences or use the session manager on different
`platforms without having to redesign the session manager. It
`is an object of the invention disclosed herein to overcome
`these problems and provide a completely distributed, com-
`pletely scalable, and completely extensible session manage-
`ment system.
`
`SUMMARY
`
`[0019] The session manager of the invention provides a
`completely distributed session management system by
`maintaining session manager conference state that ensures
`that each end point in a conference has a current copy of the
`endpoint conference state for the conference. A given ses-
`sion manager provides any changes made byits endpointin
`the endpoint conferencestate to the session managersfor the
`other endpoint and provides any changes in the endpoint
`conferencestate that it receives from other session managers
`to its endpoint. A distributed locking mechanism in the
`session manager conference state ensures that
`the given
`session manager sends changesto the other session manag-
`ers only whenall of the other session managers are ready to
`receive them. Complete scalability is achieved because a
`given session manager contains session manager conference
`state only for those conferences that have endpoints on the
`computer system in which the session manager ts executing.
`
`the session
`In another aspect of the invention,
`[0020]
`manager maintains a complete copy of the endpoint confer-
`ence state in the session manager conference state. Where
`the endpoint conference state is hierarchical, the copy in the
`session manager conference state uses a representation of
`the hierarchy which remains valid when part or all of the
`copy of the endpoint conference state is provided to another
`session manager.
`
`[0021] When an endpoint wishes to join a conference, all
`that is required is that its session manager obtain a copy of
`the session manager conference state from another session
`manager and provide the endpoint conference state in the
`copy to its endpoint. When an endpoint establishes a con-
`ference, the endpoint makes the endpoint conference state
`for the conference,
`the session manager makes session
`manager conference state for the conference including the
`endpoint conference state, and when another endpoint joins
`the conference, the session manager provides its session
`manager conference state to that endpoint’s session man-
`ager.
`
`[0022] The session managerof the invention is completely
`extensible because the operations it performsare restricted
`to incorporating changes in the endpoint’s endpoint confer-
`ence state into the session manager conferencestate for the
`conference, providing the changes in the session manager
`conference state to the session managers of the conference’s
`other endpoints, receiving changes from the other session
`managers, incorporating them into the session manger con-
`ference state, providing changes in the endpoint conference
`state portion of the session manager conferencestate to the
`endpoint for incorporation into the endpoint conference
`state, and using the locking mechanism to ensure that each
`session manager’s copy of the session manager conference
`state is the same as that of all
`the others. The session
`manager thus need have no knowledge whatever of the
`details of the endpoint’s endpoint conferencestate.
`
`[0023] The session manager is further independent of
`changes in endpoints, conferences, and platforms becauseit
`employsa representation for the session manager conference
`state which can represent any form of endpoint conference
`state. A translator running in the endpoint translates endpoint
`conference state into the proper form for the session man-
`ager conference state and vice-versa. In a preferred embodi-
`ment, the representation is XML, with translation to and
`from XML for a particular combination of conference,
`endpoint, and platform being defined by a DTD for the
`combination that is accessible to the translator.
`
`Still further objects and advantages will become
`(0024]
`apparent from a considcration of the ensuing description and
`drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0025] The features and benefits of the present invention
`will becomeclearer and more apparent following a detailed
`description of the preferred embodimentin conjunction with
`the following drawings:
`
`[0026] FIG. 1 shows a network level view of a worksta-
`tion with a session manager component connected to a
`WAN.
`
`[0027] FIG. 2 shows the same network level view of a
`session manager component connecting to a WAN,butthis
`diagram depicts two workstations connecting, and poten-
`tially communicating.
`
`[0028] FIG.3 shows numerous workstations connected on
`a WAN with their session managersall potentially commu-
`nicating.
`
`[0029] FIG. 4 depicts the configuration of installed soft-
`ware and networkinterfaces for a single workstation running
`a single application instance.
`
`[0030] FIG. 5 depicts the software and network interac-
`tions for a single workstation running numerousapplications
`simultaneously.
`
`FIG.6 is a diagram of logical software processes
`(0031]
`executing on a typical workstation and the separation of the
`software components internal to each process.
`
`FIG.7 contains a diagram of a typical hierarchy of
`[0032]
`objects maintained at both the application level and at the
`session managerlevel.
`
`

`

`US 2003/0018717 Al
`
`Jan. 23, 2003
`
`[0033] FIG. 8 depicts the same hierarchy of objects at
`both session manager and application levels but also depicts
`the interactions between equivalent objects.
`
`[0034] FIG. 9 is a diagram of hierarchical object commu-
`nication over a WAN from the viewpoint of one specific
`session manager.
`
`[0035] FIG. 10 shows a particular hierarchy of objects
`within a session manager, with some objects co-owned by
`conferences.
`
`[0036] FIG. 11 showsthe necessary lock groupsthat exist
`in order to facilitate ordered object access in the session
`manager.
`
`[0037] FIG. 12 depicts numerous workstations running
`session managers over WAN and sharing data through the
`use of two locking tokens.
`
`[0038] FIG. 13 is a high level flow chart of a typical
`network-based software application that is using our session
`manager.
`
`[0039] FIG. 14 is a flow chart showing the process by
`which our session manager locates conferences.
`
`[0040] FIG. 15 showsa flow chart of the techniques used
`in our session manager for creating and joming a known
`conference.
`
`[0041] FIG. 16 contains a flow chart showing the process
`by which conference-specific objects are modified or cre-
`ated.
`
`[0042] FIG. 17 depicts the flow chart for the session
`manager’s response to object updates from the network.
`
`[0043] FIG. 18 is a detailed overview of a session man-
`ager and a set of application processes in a workstation.
`
`[0044] FIG. 19 is a detailed view of an info object.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`[0045]
`
`System Hardware
`
`the reference system
`FIGS. 1 though 3 depict
`[0046]
`hardware necessary for executing our invention, consisting
`of one or more workstations connected to a WAN. The
`
`workstations referred to contain a microprocessor and pri-
`mary memoryfor storing and executing the software, as well
`as secondary storage for static storage of the software and
`data files required. Each workstation is in turn connected to
`a WAN using one of a number of available network inter-
`faces. The medium of communication may be any medium
`that supports logical identification of endpoints, automatic
`routing between endpoints, reliable point-to-point commu-
`nications, as well as non-reliable many-to-many communi-
`cations. In FIG. 1 only a single workstation is connected to
`the WAN (depicted by a cloud). The WAN consists of a
`potentially infinate collection of workstations some of which
`are endpoints and others are routers to different sub-net-
`works. The communication transports used between routers
`and workstations may range from high-speed LANs(local
`area networks typically employing an Ethernet) to POTS
`(plain old telephone systems) connections.
`
`[0047] Therefore data transfer between anypair of work-
`stations on the WAN mayoccur through numerousdifferent
`
`media each with its own characteristic transfer rate and data
`loss rate. In FIG. 2, workstation 1 and workstation 2 may
`communicate with each other but a network route mustfirst
`
`be established between the two workstations. Establishing
`the route involves determining the location, identification
`and identification of the network end-points, followed by the
`transfer of data. This functionality is intrinsic to most WAN
`protocols and falls outside the scope of our invention. In
`FIG.3, numerous workstations are intercommunicating on
`a many-to-manybasis across the same WAN.Onceagain the
`data is being “routed” between the workstations over a
`multicasting network of interconnections. (The term “mul-
`ticast” refers to the ability to transmit data onto the WAN and
`have it received by any multitude of workstations that are
`listening for the data.) This type of transfer is often referred
`to as “unreliable multicast transfer” and is generally an
`unreliable mechanism for communicating data, ie. data
`packets can be lost or may change packet ordering.
`
`It is however, possible to implement another level
`[0048]
`of protocol on top of an existing unreliable multicast imple-
`mentation to achieve a reliable (no data is lost or mis-
`ordered during transmission) multicast that guarantees no
`data loss and maintains packetordering. It is this mechanism
`that our invention uses for communicating amongthe ses-
`sion manager components on distributed workstations. An
`example of such a higher-level protocol is the well-known
`TCP protocol belonging to the Internet protocol suite.
`
`[0049] Software Environment
`
`[0050] FIG. 4 depicts a common execution environment
`for our invention. Application 10 interacts with the work-
`station user 9, and whenever any conference-specific data
`communication (data which is logically connected to a
`particular conference) needs to occur, the application com-
`municates with session manager component 13 that
`is
`execuling on the same workstauion. The communication is
`performed using a well-defined interface between session
`manager 13 and application 10. The session management
`component13 then conmmunicates changes madeby appli-
`cation 10 in the conference-specific data to other remotely
`executing session management components via the network
`as depicted in FIG. 2 and FIG. 3. Similarly, any changes in
`conference-specific data for application 10 that arrive from
`remote session management components via the network is
`received by session manager 13 and possibly transferred to
`application 10.
`
`{0051] FIG. 5 shows the same environment but with
`numerous applications: application 10, application 11, and
`application 12; all executing on the same workstation. Once
`again, only a single session management component
`is
`required, and all conference specific data communication is
`carried out by first communicating with session manager 13,
`and then session manager 13 in turn communicates with the
`remote session managers over the WAN asdepicted in FIG.
`2 and FIG. 3. Information arriving from the network at
`session manager 13 is then dispatched according to rel-
`evance to one or more of the applications: application 10,
`application 11, and application 12.
`
`[0052] The executing processes may therefore be divided
`into two categories: application or scssion manager. For the
`purposes of further discussion, however we will refine this
`categorization a little further in FIG. 6. Here process 20 is
`an application process, and process 21 is a session manager
`
`

`

`US 2003/0018717 Al
`
`Jan. 23, 2003
`
`process. As explained above they interact through a defined
`interface, which allows data objects to pass from the appli-
`cation to the session manager and vice-versa. The applica-
`tion process maybe divided into twosections: an application
`code section 20A, which consists of application-specific
`source code; and a framework-specific section 20B, which
`consists of network source code for communicating with the
`session manager. The application code 20A communicates
`with the framework code 20B and framework code 20B in
`
`turn communicates with the workstation’s session manage-
`ment component 21. The use of framework code 20B hides
`the details of communicating with the session manager from
`application code 20A.
`
`[0053] Similarly the session management component 21
`may also be divided into three parts: client interface 21A
`responsible for communicating with the applications on the
`same workstation; repository 21B for storing hierarchies of
`objects for the conferences in which the applications on the
`workstation are participating; and network interface 21C
`responsible for communicating with remote session man-
`agement components over the network.It should be pointed
`out here that an important aspect of the scalability of the
`distributed session management system disclosed herein is
`that each session manager contains only the state necessary
`for the conferences in which applications on that session
`manager’s are currently participating.
`
`[0054] Conferences and Session Objects
`
`In our discussion, “conference” refers to a logical
`[0055]
`grouping of end-points running on a possibly disparate
`collection of workstations as depicted in FIG. 3. An appli-
`cation process that currently belongs to a conference main-
`tains a hierarchy of objects that contain the conference’s
`state, as depicted in process 20 in FIG. 7. Here two
`conferences are established, conference 30 and conference
`30'. Then belonging to these conferences is object 30A,
`object 30B, and object 30C respectively where object 30B
`belongs to both conferences. Object 30D belongs to object
`30A. Object 30E belongs to object 30B, and object 30F
`belongs in turn to object 30E. Therefore this hierarchy
`represents a directed acyclic graph with many root nodes,
`each one a conference.
`
`In any software application that creates and man-
`[0056]
`ages the said objects, the complexity of the objects may be
`high and the storage scheme may be operating system-
`specific or hardware-specific. To alleviate this and to achieve
`platform independence,
`the session manager component
`builds an intermediate representation of the application
`objects called “info” objects in repository 21B. The inter-
`mediate representation is used in all of the session manager
`distributed session manager components andis also the form
`in which conference state is sent from one session manager
`to another across the network. Included among the info
`objects is a conference object that describes the conference
`participants and the security required to join the conference.
`Associated with the conference object are information
`objects that contain cxact reproductions of the information
`in the objects that the application process uses to represent
`the conference state. The session manager is thus able to
`maintain in its repository 21B a hicrarchy of info objects
`which mirrors the hierarchy of objects maintained by the
`application process. This is shown in FIG. 7 where appli-
`cation process 20 has created a hicrarchy of objects and the
`
`session manager 21 maintains a matching hierarchy of
`information objects. The conference objects are at 31 and
`31'. In a preferred embodiment, objects corresponding to the
`conference objects are included in the hierarchy maintained
`by the application process; in other embodiments, the con-
`ference objects may, be invisible to the application pro-
`cesses.
`
`[0057] As the application makes changes to its objects,
`these changesare reflected to the session manager, which in
`turn changes the corresponding info objects and sends
`copies of the changed info objects via the network to the
`session managers for other conference end points.
`
`If the session manager receives a changed object
`[0058]
`belonging to the conference state from another session
`manager, then the session manager changes the correspond-
`ing info object in its repository andreflects the changeto the
`application process. The manner in which changes made in
`the application process’s hierarchy of objects is reflected in
`the session manager’s
`info objects and vice-versa is
`expressed in FIG.8.
`
`[0059] The manner in which the session manager oulpuls
`changedinto objects to the network and receives them from
`the network is shown in FIG. 9. There, if info object 31C
`were to change (as a result of an object change at the
`application level) then all session managers on the network
`containing conference 31' would be notified of the nature of
`the change. If info object 31F were to changethen all session
`managers containing either conference 31 or conference 31'
`will be notified. At any time a session manager may also
`receive a description of a changed info object from the
`network (depicted as an arrow towards object 31A in FIG.
`9).
`
`[0060] Our discussion here centers on the changing of
`existing application objects or info objects, but similarly
`when objects are created and destroyed at the application
`level these facts are forwardedto the session manager, which
`modifies its own information objects and then communicates
`the creation or destruction to other session managers carry-
`ing the relevant conferences. The exact method by which
`changes are communicated across the network may be any
`of a number of prior art techniques for low-level network
`communication of data to multiple end-points.
`
`[0061] Representing the Object Hierarchy
`
`[0062] As presented in FIG.7, the application process 20
`and the session manager 21 maintai