VRML+

Frequently Asked Questions

Where is Avatar Description Kept (VRML)

A brief version is kept on the ID Server, typically this contains a pointer to the URL of the geometry, which could be on the user's client or any other HTTP server.

How to handle multiple spaces per server

Run multiple copies of the server on seperate UDP ports.

We need to allow for neighbours being in other Spaces (see Portals)

How to handle multiple servers per space

Lets assume that the space has been partitioned between two Motion servers A and B, and that the client is in the area being managed by Motion Server B. Note that both these motion servers share an ID server, so IDs are unique across all the servers.

Client registers with ID Server
Client sends Location Update to ID Server
ID Server sends Redirect packet for Motion Server B
Client sends Location Update to Motion Server B
Client receives Location Updates from Motion Server B

It is more complex when the user is close to the area serviced by Motion Server A so that users in that space need to know about this user.

As above, then..
Motion Server B batches up the update of anyone in the border region
Periodically Server B sends a packet of updates, using the Location-Update-from-Server-to-Client to Server A
Server A keeps track of these users marked as forwarded
Server A tells users in it's border area about these users.

How to handle Portals

A portal is a place where we view into another space,

Lets assume users in the Room are looking into the Street.

There is no extra VRML required
The Clients dont know anything about the Portal.
The Portal behaves like a clever client
It registers with the Movement servers on both sides
Both Movement servers send it updates of users near the portal
If the two rooms have seperate ID servers, then the Portal registers IDs and keeps a translation table
The Portal sends Movement updates for users in the Street to the Room
Users in the Room see the messages from the Portal just like regular messages
When they see an Id they dont recognise, they ask their ID server
NOTE: This doesn't address viewing through Portals of the VRML which is a seperate topic.
Two way portals are identical with messages forwarded both ways
Clever portals could figure out who on which side of the Portal can probably see the other, by knowing something of the geometry.

How to handle Doors

A door is something you can move through, there may also be a Portal co-located. Add a node to the Door activated by proximity (very close), and with the URL of the destination. On leaving one space, you sign-off that server, the destination space hopefully has its own motion server which you'll find when you parse the VRML for it.

What happens when the ID Server crashes

All ID's are lost, requests for IDs are unanswerable, so users will show up as "default" actors until they leave and re-enter the space, aquiring a new ID.

What happens when the Motion Server crashes

The next update has an unrecognised ID, but the Motion Server registers it automatically

What happens when the Client goes away

The motion server eventually times out the ID, and tells the ID Server.

What happens when the client goes away and comes back

It won't know an ID, so it will re-register with the ID Server,
The old ID is treated as for "client goes away"

How does this work with firewalls

It is simple to put a forwarding proxy on the firewall, nothing in this protocol should preclude it. The client's can use either UDP or a single TCP stream to talk to the firewall, only one port is required for the protocol.

Worlds Inc VRML+ Team
Alan Steremberg <alans@core.worlds.net>
Jeff Close <close@halcyon.com>
Kyle Hayes <kyle@core.worlds.net>
Mitra <mitra@mitra.biz>

All contents Copyright © 1995 Worlds Inc. Reproduction for personal use is permitted. All other uses are prohibited without the formal authorization of Worlds Inc., Worlds, Worlds Chat, AlphaWorld, VRML+, Internet Worlds Fair, LifeForms, Worlds Class Builder and It's Your World are all trademarks of Worlds Inc.
Web Problems?