Interest Management Objectives – –Understand what is meant by the term interest management. –Realise how interest management schemes may be deployed. –Understand the difficulties encountered when trying to deploy interest management.

Interest Management What is interest management? –A mechanism by which the amount of information required by a host to successfully enable their local objects to participate in a virtual environment may be determined. Why use interest management? –When a virtual world may consist of many entities and many networked hosts are used in the deployment of the virtual environment, interest management may considerably reduce the amount of message passing over a network. Is interest management primarily used in networked virtual environments? –Yes, but its origins stem from determining a user’s view of a virtual environment (e.g., no need to animate entities beyond a user’s view).

The aura-nimbus model

Aura-nimbus Entity state information, say of E1, that may influence an entity, say E2, should be made available to E2. Entity state information, say of E1, that does not influence an entity, say E3, should not be propagated to E3. An entity, say E1, may influence another entity, say E2, when the aura’s of E1 and E2 overlap. –Or it may be that E2 itself must be within the aura of E1. An entity, say E1, does not influence another entity, say E3, when the aura of E1 does not overlap with E3. –Or E3 itself does not fall within the aura of E1. Complications: –The aura describes the sending entity’s perceived range of influence. –The nimbus describes the receiving entity’s perceived range of interest.

Message oriented approach What we are actually seeing is a variation of the publisher subscriber paradigm. –An entity may register and un-register their interest in the activities of other entities throughout the lifetime of the networked virtual environment. –This is considered an asynchronous approach to message passing (unlike synchronous RPC). There is a requirement that an entity may express their interest and so reduce further the need for message passing. –This may be accomplished via a subscription interest language. This level of filtering is a restricted version of the aura-nimbus model. –Increased scalability is derived with further application level knowledge. –For example, even if entity E2 is in the aura of entity E1, E1 knows only to send movement related information to E2.

Benefits of filtering Reduces processing requirements. Unwanted state update messages are not processed by receivers. When IP level services (such as multicast and/or broadcast) are unavailable point-to-point communications are kept to a minimum. When client subscriptions change rapidly and underlying group communication protocols cannot ensure group dynamics (changes in group membership) in a timely fashion.

Drawback of filtering Can be computationally expensive maintaining interest groups. –Application may inspect each message to determine appropriate interest group (intrinsic filtering). –Application does not inspect message content but destination determined based on network properties (e.g., packet’s destination address) (extrinsic filtering). When many entities are interested in the same information the use of IP level multicast routing is more desirable. –Reduces the multiple sending of the same state update message. –Can’t really use IP level multicasting with filtering due to the need to have many multicast groups (one for each filter).

Multicasting Multicasting is a mechanism by which a sender may send a message to more than one receiver. –Different to broadcast as a broadcast requires a sender to send to all available receivers. –Multicasting may be achieved at the IP routing level (IP multicast exists in theory but is not widely available in practise). Multicasting is less expensive (in terms of network usage) as it removes many duplicated message sends associated to multiple unicast. The difficulty arises in networked virtual environments when trying to map multicast groups to the interests of entities. –The worst case scenario is an entity interested in small amounts of information from many interest groups.

Mapping multicast groups to entities Assign a multicast group to each entity. –Allows each entity to receive information about all hosts that lie within its nimbus. –Entities subscribe to multicast groups of other entities that are of interest. –Subscription occurs on a per entity basis (not per message). –Entities cannot specify their aura and have no influence over which hosts will receive information. Assign multiple multicast groups to each entity. –Allows each entity to send specific information to different entities. –This is expensive as there is only a finite number of multicast groups available.

Mapping multicast groups to regions Each region of a virtual environment is assigned a multicast group. –Entities send state update messages to groups associated to current location. –Entities subscribe to groups corresponding to the regions it has interest (usually the regions that are immediately adjacent to an entity). Entities have control over their aura by permitting information dissemination to be restricted to particular regions on the virtual environment. –Subscribers have limited control over their nimbi because they can only filter based on a sender’s location.

Groups per region In the groups per entity approach an entity sends update messages within the same group for the lifetime of the entity. In the groups per region approach an entity may join and leave different groups as it travels through the virtual environment. –When crossing into different regions an entity must realise the multicast group associated to each region. –These regions are usually static and defined at deployment time.

Appropriate regions Rectangle or hexagons are commonly used to divide the virtual world into regions. Hexagons appear better as they present intersections between 3 regions whereas rectangles present intersection between 4 regions.