28.06.2013 Views

Papers in PDF format

Papers in PDF format

Papers in PDF format

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Avatar Distribution<br />

Figure 3: Avatar and update message distribution us<strong>in</strong>g multicast groups<br />

As already mentioned, avatars of users participat<strong>in</strong>g at a shared virtual world are added to the world file and distributed<br />

by the HTTPD server. However, usually each user will def<strong>in</strong>e his or her own <strong>in</strong>dividual avatar, or even several avatars of<br />

different types. These avatars are located at the host of the user (browser). When a user jo<strong>in</strong>s a virtual world, the<br />

appropriate avatar has to be transferred to all other participants as well as the multi-user daemon of the server. This is<br />

done via the multicast-group. If the user does not have an <strong>in</strong>dividual avatar or an avatar of the type required by the<br />

virtual world (this might be specified by the author), the multi-user server will distribute a default avatar via the<br />

multicast group.<br />

Entity Updates and Lock<strong>in</strong>g<br />

All updates on entities are sent to all other participants as well as the multi-user daemon via the multicast group address.<br />

Interactions on shared entities require a appropriate synchronization to guarantee the persistency of the virtual world.<br />

This can be achieved by appropriate behaviors to detect such <strong>in</strong>teractions, as <strong>in</strong>troduced <strong>in</strong> the first part of this paper,<br />

comb<strong>in</strong>ed with an access control mechanism.<br />

In our prototype this is realized by a very simple lock<strong>in</strong>g scheme, which requires very few network messages, s<strong>in</strong>ce it<br />

does not require any acknowledge. Each participant can set a lock on an entity or behavior (shared trigger) by send<strong>in</strong>g<br />

an appropriate message via the multicast group. S<strong>in</strong>ce multicast<strong>in</strong>g is not order-preserv<strong>in</strong>g, concurrent locks may occur<br />

and lead to <strong>in</strong>consistencies. To resolve these conflicts, the multi-user daemon acts as a watchdog, which determ<strong>in</strong>es the<br />

lock<strong>in</strong>g site. It then also sends a message to the multicast address, which allows all participat<strong>in</strong>g hosts to resolve the<br />

conflict and to restore persistency. S<strong>in</strong>ce such conflicts tend to be very sporadic, these additional messages are not<br />

significant for the total network traffic on the multicast group.<br />

4 Conclusions and Future Work<br />

In this paper we have <strong>in</strong>troduced extensions to the emerg<strong>in</strong>g VRML standard <strong>in</strong> order to support large scale shared<br />

virtual environments. These virtual worlds are potentially populated by hundreds or even thousands of participants at the<br />

same time. By pay<strong>in</strong>g attention to the required communication <strong>in</strong>frastructure, we showed how VRML might be<br />

extended <strong>in</strong> the near future <strong>in</strong> order to support such virtual worlds. Our paper <strong>in</strong>cluded solutions for <strong>in</strong>dividual user<br />

representations as well as for distributed behaviors and shared applications. In our future work, we will extend our<br />

current prototype implementation by additional features to support collaboration of multiple users <strong>in</strong> a more <strong>in</strong>tuitive<br />

way.<br />

5 References

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!