Jeff Said:
> Martin Reddy wrote:
I wish... I know of Martin's reputation. An easy mistake to make. I am the
lesser known (lesser spotted?) Mike Reddy; not quite so famous in VR
circles. I thought it important to make the distinction 8-)
Christopher K. St. John said:
> Maybe the ability for participants to create ad-hoc
> mini-worlds, like irc channels? Server maintains a list,
> you can jump from topic-world to topic-world? Exact same
> geometry, different participants? Stuff like that sounds
> interesting, and relatively practical, since IRC has
> turned it into fairly well-trodden technical ground.
Take a look at the Deep Matrix stuff, which allows cloned worlds with
pre-set limits on participant numbers.
Jeff Said:
> the problem I have with peer-to-peer in a VNet context
> is that the VRML viewers are all plugins
> which means that [coupled with the VNet client being an Applet]
> there is a security model problem
> if the VNet client HTML page were loaded from local disk-store
> this might be something we can beat
OK. To elaborate on an earlier post...
I, and others, have been working on mobile Java applications, using Aglets
(one of several competing technologies for self-transportable code. Details
from <http://aglets.sourceforge.net/>) and recently have been looking at a
scenario like this:
1) Clients run a small application - the Aglet server - and create user
Aglets for the services that they want to use/offer. They, therefore, can
choose to be temporary servers for a range of services; HTTP, FTP, RTP, in
fact, anything that can be written in serializable code! If more than one
CPU is available, they can be 'chained' together as "trusted" peers, to
allow for distributed processing. Ideally, these would need to have good to
excellent comms with each other.
2) Clients offering worlds would then need one of these aglets as a VNet
server to handle the traffic for movement inside a world; one to be a chat
handler; and, one to be a HTTP handler allowing remote access to the
services. If services will be public, the server can declare itself to a
central database of available servers. This is like the free iVisit video
conferencing software service, <http://www.ivisit.com/> which allows private
group and 'room' membership options as well.
3) Clients merely wishing to use standard services in a normal way, just
request a URL: the HTTP server renders the HTML file. The VNet Aglet handles
the VRML updates from the Java client. The Chat Aglet handles the chat. This
level of service is really not much better than the current state of play.
In fact, all the overheads of code mobility and distribution actually add to
the computational costs. However, once we have bitten the bullet, we have
several interesting possibilities:
Roving Worlds:
It should, in principle, be possible to package up client details into a
Client Aglet, including all relevant information. This could then be
transported between servers to:
a) load-balance within a distributed single world (potentially).
There is only so far that you can go with this, if the Client aglets are
'active' as the comms overheads are exponential. However, a relatively
passive client aglet could just sit there asleep until needed, consuming
relatively few resources.
b) ease transition between multiple worlds without (really) logging off.
Clearly, the applet security would not allow a server to be relocated, as
the original web source dictates acceptable traffic. If the server is a
local one, it need not change. The VNet Aglet just starts talking to new
co-servers. The alternative is to move the target and reload the web page
from the new server. Normally, this would mean logging on again, but a
Client Aglet could do all the pre-configuration and the client browser could
be pointed at a web page and applet that has already been set up with
relevant login stuff already done, Neat eh!
c) allow for bomb-proofing due to aglet handshaking.
On this last point, Aglet servers shutdown gracefully, giving the current
running Aglets a chance to migrate to other servers before shutting down. I
particularly like this feature, as it allows for a much more robust
approach.
Peer-to-Peer:
a) when two (or more) clients want to collaborate, the system chooses the
most effective server site from amongst them to provide hosting; the others
then only need to be using the standard approach.
b) Alternatively, if desired, or the VNet server is heavily loaded, a clone
(or clones, up to the total number of clients) can be created and
distributed to handle the traffic. Clients then access their nearest server
automatically, to reduce the client bandwidth problem, using the standard
web browser and plug-ins.
Reducing overheads:
a) Message Aglets can be created to batch chat style messages, which can
then be transported in bulk, depending on network performance. This
principally addresses the issue of guaranteed delivery, which Christopher
raised. Furthermore, it should be possible to package up other media as
one-shot transmissions, including sounds and pictures, etc. A bit CB
radio-ish, but it might be nice for CSCW apps.
b) Inter-server messages could be handled using message aglets if there was
a pay-off from batching up the updates. This would need to be much more
adaptive, as the issue is a real-time problem, whereas messages are more
asynchronous and work outside the VRML timeline.
This is what we are doing at Glamorgan, anyway.
