The Virtual Institute Server, VIS, is a modification
of a standard IRC server, and, like IRCD, can connect to other
VIS servers to create an extended, highly flexible, global messaging
network system, the Virtual Institute Network, VIN. Just
like IRC, there can be many VINs (for instance, IRC has EFnet and
Undernet), and it should be possible for institutes to set up
their own VIN systems, and customize them to their needs. Presently,
We are developing new protocols for the network, and a client (named
VIN for lack of imagination!) to handle the new protocols.
idea of this network is that it provides a place for researchers
to meet, and then allows them to use whatever communication methods
they have available to communicate, providing a few basic services
of its own. The network does everything possible to avoid freezing
users into a specific technology. Future protocols will take
advantage of multicasting, CORBA object-oriented networking, ATM
networking, mobile computing, and more.
The VIS daemon handles all the protocols specified in
RFC1459, and thus can be used to create networks
with complicated topology, can vary that network in real time, on demand,
under the control of a human IRC/VI operator, and can pass messages from
user to user in a highly efficient way. Groups of users, connected
to any server on the network,
can join `channels', and then messages between those users are only transmited
within that channel. Messages are `relayed' from a source client to its
server, and then through the server network, and finally from a server back to
the destination client.
The secret of the VIN-VIS client-server pair is
that new types of messages have been added to the system. These messages
describe the Uniform Record Locators (URLs) of files on the WWW,
and actions associated with those locators. These actions are requested
by a channel member, using commands in the VIN client, and then transmitted
from VIS server to VIS server to the other channel members. Actions
can be things like `display this image', `draw on the image', `write
on the image', `run this animation
sequence', or `use the web browser to browse this document'. The
actions themselves are only encoded at the client level, not the
server level, so that new communication methods (ie MBONE phone
lines, real time video, etc) can easily be added. This will
make it ideal for communication between scientific researchers, collaborating
on common projects.
The VIN architecture is agent-based, supporting communicating
services that are brokered by mediating agents. This provides
flexibility, as well as providing extensive distributed computing
The first stage of VIN development was to produce a workable client-server
pair that could be used for channels of up to a few members. This
provided `virtual office' capability for researchers, and allowed them
to truly work together, using the full power of the web, and any
extensions to their web broswers that they have locally. The clients
needed to be able to use all the capabilities available, and not be
restricted to a few communication modes. It is important that
we do not restrict the development of virtual research institutes by freezing
them into a confined protocol. This latter constraint means that
the VIN protocol must be able to handle messages detailing URLs, and
specifying a `browse' action. However, the clients must also supply
a basic communication method between the scientists on the channel,
which must be wide enough to handle most comments. Thus the client/browser
must allow basic textual and graphical communication, and
the server must be able to distribute this communication efficiently.
Unlike IRC, where a rather fixed communication mode (ie, text) is used,
VIN must have the ability to handle new capabilities as they arise.
It is therefore important to place most of the power in the clients,
unlike IRC, where power is primarily concentrated in the servers.
With the latter in mind, It is hoped that almost all features
of a virtual institute network can be implemented at the client layer,
with most network protocol decisions being made at that level. An example
of the latter can be found in the cribbing mechanism used by the VIN clients.
The VIN system has been used for a range of applications and have proven
to be flexible, fast, and capable of working on a wide range of devices.
The client loads automatically and has a button-driven interface and automatic,
intelligent, behaviour where useful. This has made it easy to use by a wide range of
students in the K-12 age range.
Space-based communication links can often be narrowband, and also suffer from
serious delays that cause problems for many protocols. VIN is very resiliant in
these situations, and has performed well in much of our
A fully-powered demonstration client is available.
More advanced clients are in development for multiple platforms and uses.