A Review Of Distributed Architectures For Networked Virtual Reality
Virtual Reality (1996) Vol. 2, No. 1,155-175155SOFTWAREA Review of Distributed Architectures for NetworkedVirtual RealityDave Snowdon, Chris Greenhalgh, Steve Benford, AdrianBullock and Chris BrownDepartment of Computer ScienceThe University of NottinghamNottinghamNG7 2RDUKKeywords: distributed VR systems,networked VR, large-scale VR systemsAbstract: The aims of this paper are twofold. First, it identifies the generalrequirements of future large-scale distributed virtual reality (VR) systemsbased on an analysis of current VR systems, of more general distributedsystems platforms and a consideration of the key issues of scale andheterogeneity. These requirements subsequently reform the development of ageneral VR reference architecture; and a framework which identifies the keysoftware components which will comprise future distributed VR systems.Second, it uses this reference architecture as a vehicle tbr conducting a broadreview of current distributed VR products and research prototypes. Thereview covers twelve well known VR systems and is intended as a generalresource for researchers entering the field. These systems are: AVIARY,BrickNet, DIVE, dVS, MASSIVE, the MR Toolkit, NPSNET, Superscape,VEOS, VUE, WAVES and WorldToolkit. The review also identifies relevantstandards in the areas of computer graphics and distributed systems. Thepaper finishes by drawing out a number of more general conclusions from thereview including the urgent need to conduct research into the subjects ofsecurity and resource discovery for distributed VR systems. 11 IntroductionDistributed Virtual Environments represent a rapidlyexpanding area of research. At the time of writing, mostcommercial VR systems provide some kind ofnetworking, albeit often only to a limited extent, and anincreasing number of VR research platforms areappearing which support more sophisticated andscaleable forms of distribution. Examples of the formerinclude dVS from DIVISION [Grimsdale91], theWorldToolkit from Sense 8 [Sense92], Elysium fromVirtuality and Superscape from Superscape Ltd. (see[Kalawsky931 and [Vince95] for general descriptions ofthese various commercial products). Examples of thelatter span systems for co-operative working such asDIVE [Carlsson93] and our own MASSIVE system[Greenhalgh95a]; large-scale military simulations suchas NPSNET [Macedonia94]; and general distributed VRplatforms such as the MR Toolkit [Shaw93] Bricknet[Singh941, VUE [Appino92], Waves [Kazman93] andAviary [Snowdon94]. There appear to have been twogeneral motivations for introducing distribution into VRsystems:This work has been sponsored by the EPSRC99Scale - - the issue of scale, in many guises, arguablyrepresents the greatest challenge for the futuredevelopment of VR technology. One approach toscaleability is to distribute responsibility forprocessing around the nodes on a computernetwork, perhaps by specialisation of fimction (e.g.identifying dedicatednodesfor rendering,communications, IJO and collision detection) or byuser (e.g. grouping a user' processes onto onemachine). This motivation has driven thedevelopment of both local multi-processor VRarchitectures (e.g. dVS) and wide area architectures(e.g. DIVE).Co-operation - - VR offers great potential as acommunication tool. Systems to support cooperative work, especially over wide-area networks,necessarily require distribution. There is also theneed to make virtual worlds and their associatedresources (e.g. libraries of objects) shareable overwide-area networks. Hence, we see a growinginterest in VR systems which are publicly accessibleusing personal computing platforms (e.g. the use ofthe emerging VRML standard to enable publicaccess to 3-D scene descriptions stored on theWorld Wide Web).9 Virtual Press
156Dave Snowdon, Chris Greenhalgh, Steve Benford, Adrian Bullock and Chris BrownWe begin by identifying general design requirements offuture distributed VR systems. These arise from ourexperiences of building our own distributed VR platforms(MASSIVE and AVIARY), from building applicationsusing other people's platforms (DIVE,dVS,WorldToolkit and Superscape) and from reviewing bothVR and general distributed systems literature. We groupthese requirements under the following headings:requirements of VR; requirements of distributed systems;and then, with an eye to the future, requirements forscaleable and heterogeneous VR systems.R e n d e r i n g - VR systems must be able to displayvirtual worlds in various media These always include thegraphical medium, often include the audio medium andmay sometimes include textual, tactile, haptic andthermal media.Low lag, high update rate - - in order for users to beable to comfortably interact with the environment, the lagbetween a user's action and the system's response mustbe low. In addition, the system must be capable ofhandling a reasonable number of updates to theenvironment per second in order to be able to presentconvincing animations of moving objects.Input handling - - there should be a variety of inputand navigation methods, including the use of various 3-Dsensors and trackers, 3-D mice, Spaceballs, gloves,wands and audio and video devices.Collision detection - - the ability to detect collisionsbetween rendered objects or more general regions ofspace is a central component of VR.Navigation and viewpoint control - - movement is abasic requirement of VR systems. Sophisticatednavigation might include the ability to use different'vehicles' (see the DIVE system) which might constrainand adapt movement. Viewpoint control might involvemultiple viewpoints, perhaps attached to other objectsand people (see MASSIVE).World construction facilities - - VR systems shouldprovide a range of facilities for constructing virtualworlds. These should include tools for geometricmodelling and for creating behaviours. Geometricmodelling might involve integrated design tools for rapidprototyping or the ability to import geometry from avariety of other systems (especially CAD systems).Support for behavioural modelling might range fromsystem libraries through to higher level specific scriptinglanguages.Persistence - - VR systems require a database forstoring world and object descriptions. A criticism ofcurrent systems is that is that the use of the filestore tostore world descriptions which are loaded into memorywhen a world is instantiated results in a lack ofpersistence (i.e. worlds are restarted from the same initialstate).Exported behavioural models - - .distributingdiscrete state changes for artifacts, such as reporting thecurrent position of a moving artifact, can require a largeamount of bandwidth. This may be reduced by exportingbehavioural models that allow some subset of anartffact's behaviour to be simulated on remote processors(see NPSNET).2. I Requirements of virtual reality2.2 Requirements arising from distributed systemsAn examination of current VR systems points towardsthe following general requirements. Most of these will beobvious to experienced VR practitioners and we brieflyinclude them here for completeness.Tile following requirements are common to genericdistributed systems platforms and would also seem to behighly relevant to distributed VR systems.Naming - - a distributed system requires mechanismsfor both users and the system itself to refer to objects.Of course, the distributed systems community hasbeen developing general distributed systems platforms formany years, and there are currently a number ofcontenders for distributed systems standards includingISO's Open Distributed Processing (ODP) [ISO90,Bence93], OMG's Object Management Architecture,including CORBA [DEC91] and OSF's DistributedComputing Environment (DCE) [OSF92]. Other researchplatforms are also of interest, especially the processgroup model of ISIS [Birman90] from Cornell Universitywhich has been used as the distribution layer for earlyreleases of DIVE.Given this general background, two interestingquestions arise:9 What is the relationship between currentapproaches to distribution in virtual environments?9 How might research into distributed VR beinformed by previous research into generaldistributed systems?This paper aims to address both of these questions. Inso doing, it aims to provide both a structured literaturereview for researchers in the field and also a moregeneral discussion of future directions for distributed VRresearch. Section 2 first proposes some generalrequirements for distributed VR systems. Section 3 thenuses these requirements to generate a distributed VRreference architecture. This architecture acts as ageneral framework which identifies the differentcomponents and associated functionalities which mightcomprise future distributed VR systems. Section 4 usesthis architecture to compare and contrast a variety ofcurrent distributed VR systems. Section 5 identifiesrelevant standards in the areas of computer graphics anddistributed computing. Finally, the discussion in Section6 draws out some general issues for the futuredevelopment of distributed VR.2 Requirements of distributed virtual reality systems
A Review of Distributed Architectures for Networked Virtual RealityThe former are generally known as names and the latteras identifiers. Large systems require some structured anddistributed name service which can map between the twoon a potentially global scale. A number of such servicesexist, typically based on some distributed hierarchicalscheme, and include the Internet Domain Name Server(DNS) [Mockapetris87] and the OSI X.500 DirectoryService [ISO88].Trading - - system components which wish to worktogether need to first locate one another. The concept oftrading, which has emerged from recent work on OpenDistributed Processing (ODP), defines a mechanismwhereby consumer objects which to use specific services(e.g. rendering, collision detection and I/O services inVR) can locate provider objects that offer these through awell known service called the trader [Van der Linden92].Thus, the trader is essentially a database of service offerswhich can be matched against service requests, perhapstaking account of additional factors such as quality ofservice, and trading itself provides a further layer ofabstraction above naming and well as support for latebinding between system components.Resource discovery - - in massive-scale distributedsystems such as the World Wide Web, the location ofobjects and services of interest needs to be a more activeprocess than trading as described above. Resourcediscovery refers to the problem of trawling large systemsto locate resources of interest [Neuman92]. In distributedVR, resource discovery might be required to locateinteresting worlds, users of perhaps libraries of objects(e.g. VRML sites on the Internet).Replicated distributed storage - - distributedsystems require sophisticated distributed databases. Twomajor related issues here are replication and concurrency.Replication involves the maintenance of multiple copiesof data at different nodes of a distributed system and istypically used to improve system performance by makingretrieval operation s local or to improve fault tolerance.The cost of maintaining replicated data is the complexityof ensuring consistency in the presence of multipleconcurrent updates and a number of concurrencytechniques have been developed to support this (e.g. see[Bernstein81, ansparency- current VR systems such as dVS, MRand DIVE that support distributed operation areconfigured, at least in part, by static configuration filesdescribing the layout of the worlds known to the systemand/or the workstations for which the system isconfigured. Mechanisms are required for more flexibleand dynamic configuration management. This relates tothe issue of location transparency, where users andapplications should be able to access worlds, people andobjects without knowing heir physical location in thesystem (this, in turn, relates to naming and trading).Dynamic load b a l a n c i n g - a feature of advanceddistributed systems is the ability to dynamically allocateprocessing to computational resources and to perform157load balancing so that an 'optimal' or 'fair' performanceis achieved.Security w security is an often neglected, butcritical, aspect of distributed systems which are to beused in the real world. The term security covers a host offurther issues including authentication (verifying theidentity of an individual) and authorisation (determiningwhether they have sufficient access rights to performrequested actions).Multi-cast communications - - the use of broadcastcommunication techniques may flood the network withmessages for even moderate sized dynamic systems.Hence, support for multi-cast, where a single messagecan be sent to several recipients as easily as to a singlerecipient, may be important. The exact mechanism usedto achieve this depends on the nature of 9] operates by using reserved 'multi-castaddresses' to which a process can send normal UDPdatagrams, several processes can then elect to readmessages directed to this address. Sensible use of multicast therefore has the ability to reduce bandwidthrequirements and thus increase the scaleability of a VRsystem (the best known example of this in VR isNPSNET [Macedonia94]).Continuousmediasupport - real-timecommunication between users requires support forcontinuous media such as audio and video. Support forsuch media requires different distributed interactionmechanisms than the shared database/attributestechniques that have been used by VR and the RemoteProcedure Call mechanisms that have been prevalent inother systems. More generally, there is a requirementthat distributed VR systems support a variety ofdistribution mechanisms including shared attributes,RPCs and also streams for continuous media.2.3 Requirements of scaleable and heterogeneous VRsystemsWe now turn our attention to the requirements of futuredistributed VR systems. The phenomenal growth of theInternet to its current size of a small nation state and therecent interest in VRML point towards future VRsystems which may span international boundaries andwhich may be populated by millions of people andapplications. We argue that the greatest challenge facingthe development of such systems is that of scale. Thereare several dimensions to the problem of scale:9 networkcan the network deliver informationabout many objects to many users given limitedbandwidth and unavoidable latencies?9 c o m p u t a t i o n a l - even if the network can deliver,can processors compute and render huge numbers ofcomplex objects?.perceptual - - e v e n if the network and processorscan deliver, can human users cope with perceiving
158Dave Snowdon, Chris Greenhalgh, Steve Benford, Adrian Bullock and Chris Brownall other users and objects at one time(cognitive/information overload)?9 geographical - - inter-continental communicationposes its own problems including increased latencyand problems of working across time zones.Global distributedVR stemswill also beheterogeneous; it will not be possible to assume that allusers will have access to the same level or even the sametype of facilities. There are also several dimensions toheterogeneity:9 processing - - people may use equipment withradically different processing/rendering capabilities(e.g. what happens when the u er of a 486 PC triesto interact with the user of an SC[ ONYX?);9 software - - machines will run different operatingsystems and VR environments and users will wishto access a variety of applications;9 modes of interaction - - a wide variety ofperipherals wilI ec. ble simultaneous immersive,desktop and projectic, modes of interaction;9 network - - networks will varj both in terms oftheir performance profile5 (t c zghput and latency)and also protocols used Again, what happens whena user sitting at the en6 f a 960 baud modem triesto interact with a user sitting at the end of a 155Mbps ATM connection?9 culture although n t directly the topic of thispaper, we should recognise that users Will comefrom different cultural backgrounds with all of theproblems and opportunities that this creates.Several requirements arise from these generalobservations:Multiple users clearly, future distributed VRsystems should support potentially huge numbers ofconcurrent users.Co-operation s u p p o r t there is an importantdistinction between systems that are multi-user and thosethat actively support co-operation. Many systems supportmulti-user access without being at all co-operative. Forexample, large relational databases enforce the concept ofaccess transparency via serialisability which deliberatelyaims to hide users' transactions from one another and .aretherefore deliberately anti-co-operative. Support for cooperation requires an awareness of other people'spresence and activity. In VR systems this may beachieved through direct embodiment (i.e. representation)of users to one another, combined with communicationfacilities (especially audio) and mechanisms forpromoting mutual awareness. We would argue that theseare key requirements of future VR systems.Multiple applications- future VR systems shouldprovide access to many simultaneous applications andshould allow them to be invoked dynamically.Multiple worlds - - several existing systems supportthe notion of multiple worlds connected via portals orgateways, where a world is a disjoint region of virtualspace (e.g. DIVE [Carlsson93]). Multiple worlds willprovide a way of structuring and managing a global scalevirtual environment in much the same way that theWorld Wide Web is structured as a set of inter-linkedpages.Typed worlds - - a further requirement might besome notion of typed worlds, where each type of worlddefines ' 'ts own local policies and rules (e.g. some typesof worlds may support gravity whereas other may not).We can also imagine some notion of a type inheritancehierarchy, making it possible to derive new typed worldsfrom existing ones (see AVIARY for an example[Snowdon94]).Subjectivity - - many current VR systems provide astrictly objective view of the virtual environment inwhich all users see the environment in the same way,albeit from different viewpoints. For many applications,however, it may be useful to allow each user to perceivethe virtual environment in a subjective manner. As atrivial example, consider the display of text labels. Suchlabels ought to face each user as they navigate thesystem, i m p y i n g a subjective placement. The weUknown VR concept of distancing also requires a degree ofsubjectivity in a virtual world. Even in a simple casewhere the degree of perceived detail only depends ondistance from the observer, it is clear that differentobservers will be at different distances and will thereforesee the same object in different ways.Negotiating capabilities --- heterogeneous systemsimply that users who meet in a virtual world may notpossess compatible capabilities (e.g. one may be able toprocess audio whereas the other may not) In such cases,the system needs to compare and match capabilitieswhere appropriate. This can be viewed as a form of activetrading (see above), or when combined with spatialproximity detection as in the MASSIVE s3'stem, could becalled spatial trading [Greenhalgh95b]. Similarly, somekind of active load balancing needs to be carried out ifthe user of a less powerful machine meets the user of amore powerful one (e.g. the more powerful user couldtake on more of the communications processing).This concludes our discussion of requirements fordistributed VR systems. The following section nowfocuses on a general reference architecture to meet them.3 A proposed reference architecturetn Figure 1 we propose a general reference architecturefor distributed VR. The overall goal of this architecture isto identify a generic set of system components andfunctions to support distributed VR. Later on in thispaper, we will use this architecture as a means ofcomparing VR systems and of uncovering key areaswhere research and development effort is required.In Figure 1, entities surrounded by ellipses representexecutable objects and entities surrounded by rectanglesrepresent supporting services or libraries. The shadedboxes represent categories which group the enclosedentities into more generic services. At the bottom of thediagram are supporting low-level services.
A Review of Distributed Architectures for Networked Virtual Reality159Figure 1 Referencearchitecturefor distributed VR3.1 Distributed systems servicesdata. An object manager may also provide supportfor persistent objects.9 Compute servers, which provide an executionenvironment for the 'lightweight' objects stored bythe object managers. Thus, compute serversrepresent software processing agents capable ofexecuting general objects.The separation between object managers and computeservers represents a distinction between persistentdistributed storage and general processing and objectexecution facilities.These comprise four specific services: the name service,which translates between simple, structured or useroriented names and the internal names used by thesystem; the trader, which matches service offers andservice requests between objects and supports latebinding of system components; the time service, whichprovides a global time reference frame for all nodes in adistributed system; and resource discovery agents,which find and track new and interesting sources ofinformation across global networks for subsequent use intrading.3.4 Core VR services3.2 Security servicesCore VR services comprise:Security services comprise: the authorisation service,which is responsible for verifying that requested actionsare permissible under specified access constraints and theauthentication service, which validates the identity ofboth human and non-human objects in the system.9collision detectors.9spatial traders, which match objects' capabilitiesand interests, scoped according to their proximity.Spatial traders extend more conventional tradingfacilities to take account of concepts such as aura asused in both the DIVE and MASSIVE systems.world servers, which handle world-specificinformation and Services and provide initialconnection points for entering a world. A worldserver may define the attributes possessed byartifacts in its world, the laws that bind a ffacts inthe world and the requirements for entry, to theworld.93.3Object support servicesObject support services comprise:9 Object managers, which act as general code andtype repositories, as in the CORBA distributedsystem architecture [DEC91]. i.e. they perform therole of a distributed storage system for object-related
160Dave Snowdon, Chris Greenhalgh, Steve Benford, Adrian Bullock and Chris Brownworld builders, which provide a unified interface toall editors defined for attributes in the worldincluding both geometry and behaviour editors.3.5 Non-core VR serv,.'cesNon-core VR services comprise application objects.A p p l i c a t i o n objects are objects which do not form partof the core system and have been coded by applicationdevelopers. Objects falling into this category willtypically include objects performing application-specificservices and external applications which have beencompiled using a wrapper library to allow them tointeract with other objects in the system. Depending onthe facilities provided by the system application objectsmay be implemented as host processes (heavyweightobjects) or as more lightweight entities, similar toSmalltalk objects which depend on another object toprovide them with an environment in which they canexecute. Most systems re,/ ewed here provide onlyheavyweight objects, some such as AVIARY provideboth heavy, and lightweight o ects and others such asSuperscape provide only lightweight objects.3.6 User interface servicesUser interface services comprise output drivers such asa u r a l i s e r s (audio output) znd textualisers(text output); input drivers for handling a wide variety ofperipheral input devices (immersive and desk-top) andu s e r d e m o n s . User demons cause an artifact to appearwhich represents the user (i.e. defines tSeir appearance)and are responsible for co-ordinating the various inputand output drivers attached to the user.3.7 Other supporting libraries and servicesA variety of other supporting libraries and services willbe required by the more specific services described above.These include services for:9 Event management - - supporting an event basedstyle of programming.9 Database supportproviding local databasemanagement.9Continuous media services -e.g. real-timeaudio/video support.9S y n c h r o n i s a t i o n - - support for inter-process/objectsynchronisation.93 - D G r a p h i c s - - libraries for rendering andmanipulating 3-D geometry.9Multicast-support for multicast networkprotocols.4 A review of existing systemsThe previous section proposed a reference architecturefor a general purpose VR system. This section will usethis architecture as a vehicle for comparing a number ofexisting VR systems. Our aim here is to present a largevolume of descriptive information in a structured wayand, later on, to identify key areas in which futureresearch is required.visualisers,4.1 AVIARYAVIARY [West93, Snowdon94] is a distributed objectoriented VR system that supports multiple users, worldsand applications. AVIARY was developed by DaveSnowdon from the Advanced Interfaces Group at theUniversity of Manchester. AVIARY is notable for thefollowing features:Figure 2 AVIARY components
A Review of Distributed Architectures for Networked Virtual Reality9Multiple users, applications and worlds with usersbeing defined independently of applications.9 Worlds have a type and define attributes possess byartifacts in the world and laws which constrain thebehaviour of those artifacts.9 An object-oriented implementation with multipleinheritance which allows new classes of artifact torefine the implementations of existing classes.9 A variant of spatial trading is used to determinewhich artifacts are displayed by the supportedoutput objects.Figure 2 shows the subset of distributed VR facilitiessupported by AVIARY. Users are implemented as objects(in the same way as ordinary artifacts) and will typicallycontrol one or more input and output devices. The userobject will therefore define both the embodiment of theuser and the actions that the user may perform.In order to reduce network traffic objects which are'aware' in a given medium use spatially-based brokeringservices provided by the collision detection object. Anobject (for example a visualiser) will inform the collisiondetection object that it is interested in a specific volumeof space in a given medium, the collision detection objectwill then inform it of any artifacts that enter or leave thatvolume.AVIARY is designed to allow computation to bedistributed across a network of heterogeneousworkstations. This is achieved by providing objects called'Object Servers'which provide an executionenvironment for lightweight objects and management thecode associated with objects and their classes (theytherefore integrate object management and computationserver functionality). There are two forms of AVIARYobject "heavyweight' objects and 'lightweight' objects.Heavyweight objects are implemented as processesrunning under the host operating system. Lightweight161objects contain only the data structures for the objectitself and the code for the object's methods (they aresimilar to objects in programming languages such asC ). Since lightweight objects are not capable ofindependent execution without additional support theymust be host by other heavyweight objects, such as ObjectServers, which provide them with facilities for messagepassing, memory management and scheduling.4.2 BrickNetBrickNet was developed by the Institute of SystemsScience at the National University of Singapore[Singh941. It is an object-oriented distributed VR systemwritten in C and Starship, a general-purpose objectoriented, frame-based interpreted language. It is based ona client/server architecture add runs on a network ofSilicon Graphics workstations.Figure 3 shows the subset of distributed VR facilitiessupported by BrickNet. Server processes in BrickNet actas object request brokers and obtain objects requested bythe clients, performing transparentinter-servercommunication if the requested object is not managed bythat server. Server processes may handle several clients.BrickNet clients may export objects which have beendefined locally and import objects defined elsewhere.BrickNet has a different model of a virtual world thanmost other multi-user environments. Each BrickNetclient defines its own virtual world and a local user inthat world, each client may populate its world withdifferent sets of objects which it obtains from theB r i c k N e t - so by default BrickNet implements manysingle-user worlds which may share some objects, ratherthan the model of a shared virtual world containing thesame objects which is used by most othei" multi-user VRsystems.Figure 3 BrickNet components
162Dave Snowdon, Chris Greenhalgh, Steve Benford, Adrian Bullock and Chris BrownFigure 4 DIVE components4.3 DIVE 3DIVE (Distributed Interactive Virtual Environment)[Carlsson93, Fahln93, Hagsand96] was developed by theSwedish Institute of Computer Science. DIVE is aloosely- coupled heterogeneous distributed system.Figure 4 shows the subset of distributed VR facilitiessupported by DIVE. DIVE can be viewed as a databaseshared over a network with a set of processes makingconcurrent updates to the memory and sending signals toeach other. Communication is peer-to-peer rather thanusing a client/server model. Whereas previous versions ofDIVE used ISIS [Birman90] to handle inter-processcommunication, the current DIVE 3 implementation usesa distributed programming system called SID (alsodeveloped at SICS). SID uses
Of course, the distributed systems community has been developing general distributed systems platforms for many years, and there are currently a number of contenders for distributed systems standards including ISO's Open Distributed Processing (ODP) [ISO90, Bence93], OMG's Object Management Architecture,
Microservice-based architectures. Using containerisation in hybrid cloud architectures: Docker, Kubernetes, OpenShift: Designing microservice architectures. Managing microservice architectures. Continuous integration and continuous delivery (CI/CD) in containerised architectures. Cloud-native microservice architectures: serverless.
Distributed Database Design Distributed Directory/Catalogue Mgmt Distributed Query Processing and Optimization Distributed Transaction Mgmt -Distributed Concurreny Control -Distributed Deadlock Mgmt -Distributed Recovery Mgmt influences query processing directory management distributed DB design reliability (log) concurrency control (lock)
8. Distributed leadership as a companion to continuous improvement, 29 a. Distributed leadership in problem diagnosis, 31 b. Distributed leadership in solution design and enactment, 34 c. Distributed leadership in action review, 38 9. Managing the risks of using distributed leadership for improvement, 38 a. The discomfort of public disagreement .
Distributed Control 20 Distributed control systems (DCSs) - Control units are distributed throughout the system; - Large, complex industrial processes, geographically distributed applications; - Utilize distributed resources for computation with information sharing; - Adapt to contingency scenarios and
the proposed distributed MPC framework, with distributed estimation, distributed target cal- culation and distributed regulation, achieves offset-free control at steady state are described. Finally, the distributed MPC algorithm is augmented to allow asynchronous optimization and
moved to a distributed architecture This white paper is intended for those individuals or organizations that are considering developing or transforming an application to a modern competitive architecture but have never been exposed to the design concepts relating to a distributed architecture 1. An InTROduCTIOn TO dISTRIbuTEd ARChITECT uRES 1.1.
Distributed DBMS Architecture . Principles of Distributed Database Systems, 3rd edition, 2011. Outline (today) Introduction (Ch. 1) Introduction to distributed processing . Transparency, data independence, access control
The dynamics of group size is an important component of group work. A small group is often considered to consist of three or more people (Beebe & Masterson, 2003). Groups of two are called dyads and are not encouraged for group work because there are not a sufficient number of individuals to generate creativity and a diversity of ideas (Csernica et al., 2002). In general, it is suggested that .
