Wow, this stuff feels way over my head, but if it mitigates some of the
java-security problems, allows for load-balancing, and makes for more
scalability and flexibility then I say, yummy! bring on the aglets! :-)
Where can I read more on these Mike?
Cheers,
- Miriam
At 11:02 AM 22/05/2001 +0100, Mike Reddy wrote:
>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.
---------=---------=---------=---------=---------=---------=------
Q. What is the similarity between an elephant and a grape?
A. They are both purple... except for the elephant.
---------=---------=---------=---------=---------=---------=------
http://werple.net.au/~miriam
http://members.optushome.com.au/miriame
Virtual Reality Association http://www.vr.org.au
