Up |
Home |
Protocol |
Agents |
Development |
Applications |
Clients |
 |
Virtual Institute Network |
About |
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. The 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. |
Protocol |
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. |
Agents | 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 capability. |
Development | 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. |
Applications |
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.
Uses:
|
Clients | A fully-powered demonstration client is available. More advanced clients are in development for multiple platforms and uses. |