Papers in PDF format

trigger components by two new nodes: BlockSharedTrigger nodes and MultiSharedTrigger nodes.
BlockSharedTrigger nodes as used to give a user an exclusive right to execute a certain behavior for a certain time. This
mechanism provides a kind of lock which is automatically released, when the user deactivates the behavior or events
from the locking site have not arrived for a certain time period. Only further events of the same sender (activator) lead to
further executions of the behavior.
MultiSharedTrigger nodes are used to detect multi-user execution of a certain behavior. This node is used to trigger
several events created by different users at their local browsers (located on different sites). It keeps track of all events
with a time stamp within the specified time out interval. All received events are removed after the behavior has been
executed. Nevertheless, this trigger component is be able to store further incoming events even before the execution of
the behavior, since this execution might require more time than the specified time out value.
3 Our Server Extensions
In the second part of this paper we want introduce the necessary network and communication infrastructure in order to
support large scale virtual environments on the Web.
In our prototype [Broll and England 95] we use a standard HTTPD server for the initial distribution of VRML files.
However, these files are frequently updated by a second server daemon [Fig. 3]. This second server daemon (the
multi-user daemon) is used for three purposes:
adding and removing avatars of current users to the virtual world file
updating, adding and removing virtual world entities of the VRML file
supervising locks of virtual world entities and preventing clients (browsers) from unauthorized access
Since the original world file is modified by the multi-user daemon, even users of browsers which are not multi-user
capable, can get a vague impression on the current state (including the current positions of avatars) of the virtual world.
Multicasting Avatars of joining users, updates of virtual world entities as well as locking requests have to be distributed
to the multi-user server daemon as well as to all clients. Realizing this by ordinary host-to-host network connections
[Honda et al. 95], as used by HTTP, would exceed the capabilities and cause network overload. For that reason we use
multicast groups to distribute the data. Multicasting [Kumar 95] provides a very flexible and powerful mechanism to
distribute messages to a large number of hosts with minimal network load and distribution effort. Multicast packages are
sent over a special part of the Internet -the Multicast backbone (MBone)- which connects multicast routers running a
special multicast routing daemon (mrouted). Additional subnets can be connected to the MBone by tunnels (host to host
connections). This structure allows the reduction of unnecessary message distribution on a very low level, which makes
multicasting very effective for wide area communications of a large number of host, joining and leaving dynamically.
Multicasting has already proven to be very suitable for this kind of application in existing distributed virtual
environments [Carlsson and Christer 93] [Macedonia et al. 95].
In our approach a multicast group address and a port number identify a single world. This allows the daemon as well as
the participating host, to receive messages from this group and port only. Future extensions might even use several
groups or ports for update messages of a single world, in order to support the subdivision of large virtual worlds
[Brutzman et al. 95]. The multicast address as well as the port number are transmitted to the clients (browsers) as part of
the initial world distribution.