|
|
|
| AIG Home | Divipro Home | Introduction | Architecture | Prototype | Screenshots | |
| Divipro Prototype | |
|
|
|
| |
Divipro Prototype ImplementationThe Divipro prototype system contains two possible constraint validation systems. The first is a simple geometric constraint engine, implemented by Labein and incorporated into their DATum geometric modeller. Another more advanced assembly and constraint manager, from the University of Salford, permits multiple, more complex constraints on the motion of an object, and maintains assembly relationships between the parts, such as the fact that two objects have been assembled together. Labein's geometric modeller is used as a kernel: it provides services to other parts of the system, such as the flexible object simulator, the renderer, and the assembly manager.Divipro has a common API for both constraint subsystems, so the choice of constraint service can be determined by either the complexity of the task being carried out or the available computing resources. The simple geometric constraint engine is relatively lightweight, computationally, but is only able to satisfy a single constraint at a time, which limits its ability to handle complex assemblies. The advanced assembly manager addresses these limitations, but is computationally more expensive. In its current configuration it also uses some proprietary software, so that the advanced constraint server can only be used on an SGI platform. However, individual client viewers can connect to the advanced constraint service from any UNIX, Irix or Linux platform. One of the main problems with a pure client-server mechanism is that object manipulation on a client involves a round trip to the server, to validate the motion of an object subject to constraints. On wide area networks, this round trip may be too large to allow users to meaningfully participate in a collaborative design process. In Divipro, this is addressed by the underlying Deva system. Although logically a client-server design, Deva allows the server to be a collection of distributed processes which are physically distributed across a network. To the clients there appears to be only one logical server, where in practice it is comprised of a number of distributed processes. Message routing is managed by a name layer which can locate and send messages to any server object, wherever it exists on the network. So while at one level the Divipro system can be viewed as a client server system, it can and does exploit Deva's mechanism for building applications with a hybrid client server, or peer to peer architecture. While developing the Divipro system, we were interested in strategies to minimise the round-trip delay experienced by users. In order to experiment with a variety of different network configurations, the inherent flexibility of the Deva distribution framework was used to move the location of constraint computation. The following list of network configurations were tested: 
Local constraint computation with no synchronisation
Local constraint computation with server-enforced turn taking
Centralised constraint computation
A roaming serverWe discuss each of these strategies below. No SynchronisationEach viewer is paired with a local constraint service that validates input from the user. Un-validated updates are sent across the network to other users where their constraint service applies the input. This has a low overhead, but without any synchronisation there is nothing to prevent users manipulating objects simultaneously. Due to the fact that updates takes a finite time to be transmitted, each constraint service could contain different, conflicting states. Consequently, each user may have diverging views of the environment and this is unsatisfactory for users sharing the same interactive environment. We found that this approach breaks down very quickly, even on local networks, and soon becomes unusable.Turn TakingThis network configuration is similar to that described above with the exception that a user requests a lock from the server when an object is selected. If the lock is granted then the user is free to manipulate the object. Updates from the constraint service associated with the user possessing the lock are forwarded to other viewers (via the server)where they are applied on each associated constraint service without being checked. Single ServerThe single server approach relies on one centralised constraint service applying updates from all the users. There is a single locus of control, so all viewers see a consistent world. The disadvantage of this is that all viewers suffer the round trip through the server before receiving validated updates and this reduces responsiveness. This is un-noticeable on a local network; the application actually runs faster than if it were running on a single processor, as the computation is distributed over two processors.However this is not suitable for operating across the Internet, where the increased round-trip delays can soon degrade performance. Roaming ServerA roaming server involves creating local constraint services for each co-operating site. These can sensibly be shared within each LAN. Upon startup, the viewer component pings each constraint service to determine the round trip time. The constraint service with the lowest ping time becomes the preferred one for that viewer.The system logically has at most one constraint service active at any one time. When a user initiates an interaction, the system is asked to use the local user's preferred constraint service. If the environment does not currently have an active constraint service, then this is set to be that preferred by the user. If there is already an active constraint service (because someone else is already in the process of manipulating an entity) then the environment returns its name. Updates are now sent via this constraint service for validation in a similar way to the single server technique. When the active constraint service reverts to its listening state, the complete state of the constraint server is broadcast to each of the other constraint services listening on the network. The result is that all constraint services in the system are maintained in the same consistent state so that any one of them can be chosen to manage the next interaction. 
In the general case this technique works well, when people spend most of their time naturally taking turns to interact, as is usual in the real world. This is because the system will naturally use a constraint server which is local to the user manipulating the model. Where multiple users interact simultaneously it may result in some lag being experienced for round-trip requests. For the Divipro system, the single server configuration was found to perform well on a local area network, while the roaming server configuration was found to be the best approach on a wide area network. The roaming server configuration exploits Deva's hybrid client-server/peer-to-peer configurability; the technique is transparent to the users, but gives them local control of objects. |
Divipro Project | Divipro Consortium | Email: divipro@cs.man.ac.uk