Electrical computers and digital processing systems: multicomput – Computer conferencing – Cooperative computer processing
Reexamination Certificate
1999-12-30
2002-01-01
Sheikh, Ayaz (Department: 2155)
Electrical computers and digital processing systems: multicomput
Computer conferencing
Cooperative computer processing
C709S201000, C709S203000, C709S204000, C709S241000, C709S243000, C709S241000, C345S215000
Reexamination Certificate
active
06336134
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to collaboration systems implemented on networked computers and, more particularly, to a method for building a locking, migration, dynamic clients, and dynamic partitions capable distributed server for a real-time collaboration session.
2. Background Description
Software for collaborative work, i.e., work involving many users and/or agents falls into two categories of use. One is termed asynchronous collaboration and the other, synchronous collaboration. Examples of software for asynchronous collaboration are groupware such as Lotus Notes and Microsoft Exchange. These along with other examples, such as discussion groups where data is changed batchwise, have the characteristic that neither do they require, nor do they particularly cater to the concurrent presence of many users and agents in the work environment. Work environment can include all users and agents that use computers that are connected to each other by networks such as Internet or intranets.
In contrast to software for asynchronous collaboration, software for synchronous collaboration is designed to cater to concurrent users and agents. It includes collaboration tools such as chat, concurrent whiteboards and the more sophisticated SameTime environment. These tools provide for real-time interaction among groups using the same shared workspace. Whatever be the workspace—document, spreadsheet, Computer Assisted Design (CAD) drawing, etc.—it can be seen and modified by the collaborators, simultaneously. Modifications to the workspace are made available to all group members, immediately and synchronously.
Synchrony in multiple updates made by collaboration participants has to be ensured by the underlying synchronous collaboration implementation. One of the common ways by which this is done currently is by the inclusion of a centralized server. A centralized server is a software process running on one host machine(a hardware computer) that introduces a serialization order among multiple modifications. Thus multiple, simultaneous updates to a shared workspace are communicated to the server which converts them into a sequential stream of updates to the workspace. The stream of updates is then reflected back to all participants, each of whom is assumed to be running a software process, a client, in order to interact with the workspace. Each participant or client thus sees the shared workspace develop in an identical manner—starting from the same initial state and changing under the same stream of updates—as any other participant or client of the collaboration. This method of streaming updates has many parameters. Each parameter can lead to a different behavior of collaboration at the user level.
Examples of parameters are: What is a modification? Is it a sequence of user-level operations and/or some translation of the same? Is it the complete, changed workspace itself? Is it an object difference—changed workspace minus unchanged workspace? What is the role of history of serialization in serialization itself? Is there any role? Can users explicitly lock out other users while making changes to the shared workspace? Answers to each of these questions can affect what the collaboration implementation means to its users, or in other words be a different definition of synchronous collaboration. Yet what all of these implementations have in common is their dependence on one server process to make serialization decisions for them.
As collaboration needs scale up—number of clients changing the workspace and needing synchronous views of the workspace goes up—the single server process running on a single machine and the communication network bringing about communication between the server and the clients can become severely loaded with computation and communication requirements. Indeed since the architecture of the collaboration implementation is such that it focuses all communication to one point in the communication network, namely the server's machine, it leads to the development of an unbalanced load on the communication network. It is possible that the communication network cannot effectively service the “hot spot” of communication, viz., the server's machine, despite being relatively lightly loaded in other parts of network or on the average. The result can be unacceptable delays and degradation in performance from the perspective of collaboration participants.
The invention disclosed in application Ser. No. 09/241,991 addresses the above issue by breaking the notion of one, centralized, software, server process into multiple, independently-communicating, asynchronous, independent, distributed software processes. Multiple software processes make up a distributed server, as shown in
FIG. 2
of application Ser. No. 09/241,991. A distributed server is capable of being distributed and executed upon multiple heterogeneous hardware/software platforms that comprise the network and front ends participating in a collaboration session. The distributed server requires a partitioning of the shared workspace to be available in order to be applicable. The multiple software processes of the distributed server can be distributed to different machines and can be run simultaneously on the different machines. Thus, the distributed sever architecture can avoid focusing all communication to one point in the communication network, and diffuse away the “hot spot” of the centralized server into different parts of the network.
The distributed server in application Ser. No. 09/241,991 does not support migration of its processes, does not support locking of partitions by a client for exclusive use, and is limited to a static definition of workspace partitions and collaboration clients. In other words, in the distributed server of application Ser. No. 09/241,991, no new partitions can be created in an ongoing collaboration session, no old partitions can be deleted at run-time, no client can leave an ongoing collaboration session, and no client can join or rejoin an ongoing collaboration session. All of these limitations are addressed by this invention whereby the distributed server of application Ser. No. 09/241,991 is extended to become capable of fully handling dynamic clients, dynamic workspace partitions, locking and migration of distributed server processes while retaining the capability of fully handling static clients and static workspace partitions. As described in this disclosure, if the partitioning made available to a distributed server is dynamic, then processes corresponding to dynamic partitions can be started/ended/converted dynamically. In a collaboration session with dynamic clients, any client can leave or join the collaboration session at any time provided that the session has at least one client present at any time. The one client can be a different client at different times - in other words, one client can pass the “baton” to another; however, at any time, there has to be at least one client present in a collaboration session. This is a natural requirement for a collaboration session, since at least one person/client has to be present in order for even a rudimentary form of the session to take place.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide a method for building a locking, migration, dynamic clients, and dynamic partitions capable distributed server for a real-time collaboration session.
In order to take into account the changing nature of the communication network, wherein machines can be added, loaded, and removed dynamically, the processes of the distributed server can be migrated from machine to machine, dynamically. Indeed, the distributed server processes can avoid dedicated server hosting machines by residing and running solely on the machines hosting the client processes. In this case, the distributed server processes can migrate as and when new client machines are added or removed. The extended distributed server supports locking a parti
Jean Frantz B.
Kaufman Stephen C.
McGuireWoods LLP
Sheikh Ayaz
LandOfFree
Dynamic clients, dynamic partitions, locking, and migration... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic clients, dynamic partitions, locking, and migration..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic clients, dynamic partitions, locking, and migration... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2842241