COMMUNICATION PLATFORM FOR SYNCHRONOUS COLLABORATIVE VIRTUAL ENVIRONMENT

COMMUNICATION PLATFORM FOR SYNCHRONOUS COLLABORATIVEVIRTUAL ENVIRONMENTSt´e phane Louis Dit Picard,Samuel Degrande,Christophe Gransart,Christophe Chaillou (1)Gr´e gory Saugis (2)(1)Universit´e des Sciences et Technologies de LilleLaboratoire d’Informatique Fondamentale de Lille 59655Villeneuve d’Ascq cedex,FRANCE Tel:+(33)(0)320436557;Fax:+(33)(0)320436566louisdit,degrande,gransart,chaillou @lifl.fr(2)France T´e l´e com R&D -DIH/HDM/NEW2avenue Pierre-Marzin 22307Lannion cedex,FRANCETel:+(33)(0)296052741;Fax:+(33)(0)296051129gregory.saugis@rd.francetelecom.frABSTRACTThis paper describes our communication platform over which a 3D CVE (Collaborative Virtual Environment)called SPIN-3D is built.With our 3D interface,a small group of people operates simultaneously on 3D objects described with the VRML format.Multi-user is supported through a VRML ex-tension.We propose to share some data of the scene tree as well as an easy way to implement this solution:each shared data communicates with its remote copies through a multicast CORBA technology for discrete actions and through multicast real-time streams for animations.Keywords:CVE,CORBA,MIOP ,Reliable Multicast Protocol,multi-user world,VRML1INTRODUCTIONSPIN-3D [3]is a three-dimensional user interface for synchro-nous collaborative work.Our interface is designed for small group meetings such as distant learning or co-design situa-tions.We propose a new spatial organization [14]taking ad-vantage of the third dimension and a 3D interaction model using two devices [3],one for designation and the other to manipulate objects.To support collaboration awareness,each user is represented on remote SPIN-3D by a clone [3],a 3D representation of himself.We adopt a “conference table”me-taphor [14]:the users are located around a table in a single room.Figure 1is a screen shot of ourinterface.Figure 1:A learning situation in SPIN-3D2STATE-OF-THE-ARTAs we use the VRML (Virtual Reality Modelling Lan-guage)[2]format to describe 3D objects on which users ope-rate,we need to improve it with a multi-user support.Living Worlds multi-user extension [8]allows standard VRML brow-sers,such as Cosmoplayer or Blaxxun Contact,to support multi-user Virtual Communities but they lack several capabili-ties to support CVE.Classical multi-user virtual environments use a “world replication”mechanism.From a technical point of view,the world is described with a scene tree in which some nodes are shared.So,the “world replication”means that the scene tree is the same for all users.A client-server architec-ture is an easy way to implement this solution:a server ma-nages the scene tree.To achieve acceptable frame rates,each connected user must have a local copy of the scene tree:modi-fications on shared objects are sent to the server which notifies each client with scene tree updates.The needs of a CVE are more specific than the “world replica-tion”mechanism.First,a CVE needs specific information to support collaboration,such as telepresence,telepointers,de-signation gestures,a private point of view on the objects,etc.Each user organizes his own interface as he wants and without remote influence.So,each shared object is not necessarily at the same place in a CVE:only the object content is shared.To support collaboration,a CVE needs to share objects,more accurately characteristic values of objects (e.g.a position,an orientation,etc),which are not only 3D values but also text va-lues,management services (e.g.lock manager or session ma-nager)and “special”events (e.g.enter or quit session events).For example,in SPIN-3D we have the notion of pointer and telepointer which is the remote representation of a pointer:for such an object,its color is shared,but its position is shared only when user points at an object,moreover a pointer does not have the same 3D representation as a telepointer.The new MPEG-4standard [5],which uses VRML concepts,does not currently offer capabilities to support CVE.As we want real-time interactions on local computer for local manipulations in order not to disturb the user during collabo-rative actions,a client/server architecture is unsuitable:such architecture involves network lag during interaction.3COMMUNICATION PLATFORM REQUIRE-MENTSFirst,we need a way to declare shared data and then a mecha-nism to support data sharing and CVE’s specific needs.Currently the SPIN-3D platform distinguishes two types of communication on shared data:–discrete actions for interface control(e.g.button click,etc)and core management(e.g.lock manager,sessionmanager,etc)–continuous actions for object animations,streamingdata such as audio or video,etc.4MULTI-USER SUPPORTOur approach,inspired by the work of the Living Worlds group[8],is a way to describe the sharing of a set of data from an existing VRML content.We have discarded a few no-tions,like Zones,which are useless in CVE’s like SPIN-3D.A few requirements lead us to build our proposal:–respect the VRML syntax:browsers which do not sup-port our proposal should parse and display a VRMLfilewhich contains a sharing description;–keep unchanged VRML description of existing objectswhen adding sharing functionality;–a hierarchical structure of shared data;–multiple sharing modes regarding our different ways ofcommunication.4.1Shared typesWe define a new node type(as an EXTERNPROTO)for each field type existing in VRML.For example,the“SharedSF-Bool”node matches the“SFBool”field type: EXTERNPROTO SharedSFBool[exposeField SFBool valueexposeField SFString aliasexposeField SFString mode"public"exposeField SFString flow"action"]The“value”field contained in a shared node is pointing to afield of the object tree whose name is given by thefield “alias”(seefigure2).Thefield“value”is shared according to the“mode”field.Modes of sharing can be“public”(seen and used by everybody)or“private”(only available locally). The“flow”field gives information on how updates must be sent.We have identified three possibilities:–“action”indicates an update that must be transportedreliably.It corresponds to a discrete action.–“flow”is for infinite,real-time,continuous dataflowssuch as video,voice,etc.–“animation”is for aflow followed by a reliable stateinformation.It is useful when an object is moved andonly itsfinal position is really important.4.2SharedSet nodeA new SharedSet node(defined as an EXTERNPROTO)will contain a list of shared nodes such as SharedSFBool,etc.This list can also contain other SharedSet nodes to create a hierar-chy.DEF mySharedAttributes SharedSet{children[DEF lightning SharedSFBool{alias"myLight.on"mode"public"}]}DEF myLight SpotLight{}Figure2:An example of a SharedSet nodeIn the example given infigure2,the“on”field of the Spot-Light“myLight”is declared to be shared.Modifications of ei-ther myLight.on or lightning.value will turn the light on/off accordingly and will reflect this state to the other users.4.3Architecture proposalFields of the scene tree are duplicated on several computers. When a change occurs on a sharedfield,we must notify its re-mote copies to keep the consistency between interfaces.There are many mechanisms for remote notification:Remote Proce-dure Call(RPC)[1],or remote method invocation(to com-pare to the RPC in an object context)such as Java RMI(Re-mote Method Invocation)[15],Microsoft DCOM(Distributed Component Object Model),or CORBA(Common Object Re-quest Broker Architecture)[11].With a remote method invocation mechanism,each shared field is seen as an object and the notification is made through a method invocation:when a change occurs,we ask the object to change the value of its attributes using a method call.For this,we must be able to designate each remote object(i.e. sharedfield copy)in order to notify it.A solution is to use references,which can be defined in two ways:–each object has its own reference:we must know allremote references in order to notify updates.Such a so-lution is hard to implement and to manage–an easier solution is to have only one reference for agroup of objects(i.e.objects representing the same sha-redfield).Even with group references,if we use a unicast transfer pro-tocol,one notification per remote copy must be sent.However with a multicast transfer protocol,the notification requests are sent to several connected users at once.All the users send and receive messages on the same multicast address.For those reasons we have chosen a multicast CORBA tech-nology[4]for data sharing:it is an easy and fast approach and an open standard.CORBA through a“multicast corbaloc”is able to create and manage the reference of a group of objects (i.e.“same objects”having the same reference),and multicast technology allows to transport and deliver method calls to re-mote objects using a group reference.5OUR COMMUNICATION PLATFORMThe CORBA standard[11]proposed by the OMG(Object Management Group)specifies a protocol,called GIOP(Gene-ral Inter-ORB Protocol),to describe messages such as method invocation.It defines:–a Common Data Representation(CDR)to map IDLtypes to network representation–an Interoperable Object Reference(IOR)to point to anobject–a message format(request,reply,etc).CORBA needs a transport layer to carry GIOP messages.So the OMG also specifies a unicast transport layer called IIOP (Internet Inter-ORB Protocol)which uses TCP/IP.In IIOP, each method invocation request is sent to exactly one ser-ver:an IIOP reference(aka IIOP IOR)points to only one ob-ject.CORBA,through a multicast transport layer called MIOP (Multicast Inter-ORB Protocol)[4,12],allows to call methods on several“identical”objects in one go:all objects have the same multicast reference(aka MIOP IOR).Each method call on a multicast reference is executed on each computer which has in memory an object with that reference.Currently,as it uses UDP/IP,the MIOP communication layer(as specified by the OMG in its RFP[12])is designed for unreliable commu-nications.At the transport level,a method invocation is one GIOP mes-sage of any size which must be sent to objects using the mul-ticast reference.The idea is to split each message into several fragments,to send each fragment in order to reconstruct the original message andfinally to execute the method call.If the transport layer is unreliable,sometimes it can be impossible to reconstruct a message because one or more packets are mis-sing.So the message is rejected and we lost consistency bet-ween the interfaces.Therefore,we need to provide a reliable protocol over UDP/IP which ensures that all connected users receive all messages,namely,all packets of all messages. 5.1Reliable message transportAfirst approach for reliable multicast is“for each sent pa-cket,the sender waits for acknowledgement messages from all receivers”:this is an ACK(Acknowledgement)based proto-col[7].Such protocols can be a solution to our problem but they create significant network traffic.A second approach is“the sender numbers each sent packet with a unique number(incremental number),receivers detect packets lost using the current received packet number and the last received packet number,if numbers differ from more than one then packets are missing,a message is sent to the sender in order to re-emit missing packets”:this is a NACK(Non Acknowledgement)based protocol[6].Such protocols need an infiniteflow of packets which is not our case:GIOP mes-sages are of limited size,thus we have afinished number of packets for each GIOP message.So as we prefer NACK based protocols to ACK based pro-tocols for network traffic reasons,we adjust a NACK proto-col to support a limited number of packets.Each connected computer must know the number of packets of each message: this number is sent in one of the packets,and this special pa-cket uses an ACK policy in order to ensure its reception.The other remaining packets are sent using a NACK policy.So our proposal is:“if a message is divided into n packets,thefirst n-1packets are sent using NACK policy,and the last one is sent using ACK policy”.Of course as it uses ACK policy for the last packet,we need to know all connected users,using a group manager:such a mechanism is implemented using a distributed algorithm.This work is not presented in this paper.5.2ImplementationThe implementation of CORBA MIOP layer is done using C++language and the ORBacus[13]ORB middleware.This middleware offers to developers a notion of communication plug-in through a framework called OCI(Open Communica-tion Interface).Using this framework we can develop new pro-tocols such as MIOP.The reliable multicast protocol is implemented using C++lan-guage over UDP/IP and was integrated into the MIOP plug-in as an extension which we call RMIOP(Reliable-MIOP):it is possible to switch dynamically between transfer policies,re-liable(RMIOP)or not(MIOP).5.3PerformancesTo benchmark our RMIOP layer,we have made some experi-ments:–afile transfer between two computers using differentnetwork bandwidths.It emphasizes that our multicasttransport layer over UDP/IP is as fast as TCP/IP for oneserver and one client.Multicast is more adapted to sca-lability:when the number of clients is multiplied by n,the global receipt time(of the sender point of view)ofthe TCP/IP transport layer is multiplied by n whereasthe global receipt time of reliable multicast transportlayer is the same.–a simple application where the users could interactivelychange the orientation of a3D object over network.Itemphasizes the limitations of CORBA for animation:each orientation modification corresponds to one re-mote method call,so it creates traffic network.Moreo-ver,in CORBA,there are a lot of layers between net-work layer and application layer(i.e.implementationobject),so it creates problems for real-time interaction.5.4AnimationsAs we have just said,CORBA is unsuitable for remote real-time animations.Our idea is to use multicast real-time streams between duplicated objects and CORBA is used to establish streams.Our proposal is based on Audio/Video Streaming ser-vice[10],an OMG standard using a centralized mechanism. We adjust it to our distributed architecture.When,due to a user interaction,the application on one com-puter decides to start aflow communication,it asks the shared field to create aflow endpoint.As the sharedfield is referen-ced by a multicast reference,the method call is done on each remote copy.This way,aflow endpoint is created and connec-ted to each object representing the sharedfield.At this time, animation can start:each modification is sent to remote co-pies using theflow endpoint(seefigure4).For management offlow endpoints(start,stop,destroy,etc),we use a distribu-ted stream controller:this work is not presented in this paper.5.5COMMUNICATION EXAMPLESSPIN-3D c oremy_float :S haredSFFloat+set_value(v :F loat)-value :F loatmy_float_refSPIN-3D c oremy_float :S haredSFFloat +set_value(v :F loat)-value :F loatmy_float_refORBMIOP/Reliable M ulticast P rotocolset_value(2.0)deliver r equestlocal u pdate new r equest 2compute request313GIOP my_float_ref set_value(2.0)update4Figure 3:Discrete action using multicast CORBA technologySPIN-3D c oremy_fep :F lowEndPointmy_float :S haredSFFloat +set_value(v :F loat)-value :F loatmy_float_refSPIN-3D c oremy_fep :F lowEndPointmy_float :S haredSFFloat +set_value(v :F loat)-value :F loatmy_float_refmulticast real-time streams1set_value(2.0)new r equest 2local u pdate 3445consume d atavalue=2.0produce d ata......6updateFigure 4:Animation using multicast real-time streams Figure 3shows how SPIN-3D communicates for a discrete action,while figure 4shows how it works during an anima-tion.In figure 4,we suppose that animation is already started,so flow endpoints were already created and configured:the distributed stream setting mechanism is not presented in this paper.When the animation ends,the stream is destroyed.Flow endpoints can use different protocols over UDP/IP to transport animation data:RTP (Real-Time Protocol)[9],SFP (Simple Frame Protocol)[10]an OMG standard which can be compared to RTP.They can also use codecs (MPEG-4codecs for example)to encode and decode data.6CONCLUSION AND FUTURE WORKSThis paper presents the design and implementation of our 3D CVE communication platform:all the propositions presented in this paper are implemented.Multicast CORBA technology provides an efficient solution to many of the technical issues of our VRML multi-user extension and of duplicated objects management.Distributed Audio/Video streams service is a so-lution to provide remote real-time animations.This work is still in progress.The aim is to offer a full distributed platform including distributed management services such as lock mana-ger.Through CORBA,an external application can have access to shared objects within SPIN-3D:it can be easily interfaced with SPIN-3D.With our platform it will be easy to develop synchronous collaborative applications.ACKNOWLEDGMENTSThe research project reported here is supported by France T´e l´e com R&D and the regional council of Nord-Pas de Calais (FRANCE).REFERENCES[1]A.D.Birrell and B.J.Nelson,“Implementing RemoteProcedure Calls”,ACM Transactions on Computer Sys-tems,V ol.2,No.1,February 1984,pp.39-59.[2]R.Carey,G.Bell and C.Marrin,“ISO/IEC 14772-1:1997Virtual Reality Modeling Language (VRML97)”,see /Specifications/VRML97/.[3]C.Dumas,S.Degrande,G.Saugis,C.Chaillou,M.-L.Viaud and P.Pl´e nacoste,“SpIn:a 3D interface for co-operative work”,Virtual Reality Society Journal,edition Spinger-Verlag,1999.[4]C.Gransart and J.M.Geib,“Using an ORB with MulticastIP”,Proceedings of the PCS’99Parallel Computing Sys-tems Conference,Ensenada,B.C.,Mexico,16-20August 1999.[5]ISO/IEC JTC1/SC29/WG11WorkingGroup,“The MPEG Home Page”,see http://www.cselt.it/mpeg/.[6]T.Liao,“Light-weight Reliable Multi-cast Protocol Specification”,Internet-Draft,draft-liao-lrmp-00.txt,October 1998,see http://webcanal.inria.fr/lrmp/index.html .[7]J. C.Lin and S.Paul,“RMTP:a reliable multicasttransport protocol”,Proceedings of IEEE INFOCOM’96,March 1996,pp.1414-1424.[8]Living Worlds Working Group,“Making VRML 97applications interpersonal and interoperable”,see/WorkingGroups/living-worlds/.[9]Network Working Group,“RTP:A Transport Protocol forReal-Time Applications”,RFC 1889,January 1996,see /rfc/rfc1889.txt .[10]Object Management Group,“Control and Managementof Audio/Video Streams specification”,OMG Document formal/00-01-03,January 2000.[11]Object Management Group,“The Common Object Re-quest Broker:Architecture and Specification”,OMG Do-cument revision 2.3,1999.[12]Object Management Group,“Initial Submission for Un-reliable Multicast”,OMG RFP,ORBOS OMG meeting about Unreliable Multicast,Denver,Colorado,USA -March 5-10,2000.[13]Object Oriented Concepts Inc,“The ORBacus Home Pa-ge”,see /ob/.[14]G.Saugis,C.Dumas and C.Chaillou,“A new mo-del of interface for synchronous CSCW”,XIV Imeko World Congress,ISMCR’97Topical Workshop on Virtual Reality and Advanced Man-Machine Interfaces,Tampere,Finland,01-06June 1997,pp.221-226.[15]Sun Microsystems Inc,”Java Remote Me-thod Invocation (RMI)Home Page”,see /products/jdk/rmi/.。