ChatLink was designed to connect Generic Group Interface Players (GGIP) from
different sites together. The basic transport was a constant connection through
the GGIP itself. It listened to calls on its :broadcast verb and sent the
text across the link to a centralized HUB which would distribute the text to all
links except the broadcasting link.
MOOLink was an extended version of the ChatLink which could perform more functions.
The basic connection was still a GGIP character, but the network could be extended
to other GGIPs and other functions. Interpage, which was a special player, was the
interface to page someone on other sites. MOOLink could also perform remote
@who-like requests on the GGIPs as well as the remote MOO, however, specific players
could not be specified. MOOLink was also a HUB-oriented networking scheme.
SunNET 1.0 was the first network program in SunNETís history that moved away from
the HUB connections. It was designed to be able to execute remote snippets of MOO
code and return the results to the caller. Like the current SunNET version, it had
two ways of of using it: Remote evaluation and Message Broadcasting. It contained
somewhat primitive routing code. The basic scheme was to pass on all messages to all
sites with the exeptions, a) the packet had already been seen by the receiving site,
or b) the non-GENERAL destination of the packet was the site itself. This scheme
became problematic as more sites were added to the network as it caused exponential
growth in the number of packets received by a site at any given time and was the
reason SunNET 2.0 was written.
The link strategy was to have connection player objects, and have the moo listen on
special ports (Multi-Port listening) and connect to special ports. MPL was rarely used
as it tended to timeout after five minutes of no activity. Almost all functionality
resided in the $sunnet, as $sunnet_utils did not exist. The transport
commands had to be parsed by the site in MOO code, causing more lag in times of high
SunNET 2.0 changed the transport commands, making it completely incompatible with
SunNET 1. The packets contained the DATA transport command followed by a
argstr which could be passed to the eval() builtin to obtain the
Routing in SunNET 2 was determined by a set of path tables. The table for any
given site was sorted in increasing order by the number of sites the packet needed
to go through to get to the destination. Each one was tried until a success packet
(ACK) was returned from the destination. GENERAL destination packets
do not return ACK, instead they are broadcast to all directly connected links
and assumed to succeed.
Version 2.1 was the first version to be dependent on MOO server 1.8.0 or better
for the speedups involved with suspend() and resume(), as well as
using the scattering assignment for faster interpretation of the message values..
SunNET 3.0 remained compatible with SunNET 2 in its transport format and can
communicate with SunNET 2.0. Some protocols that 2 relied on have been deprecated
in 3, such as QUERY, which asked a site if it was on the network.
QUERY had a tendency to cause many response packets to be generated
unneccessarily by all sites receiving it.
SunNET 3 also adds functions to allow users to easily install and update the
source code on various MOOs and is outlined in the installation section of this
manual. It allows a site to determine if it has $ansi_utils installed.
Routing has been changed to be based on time, rather than path length. This means
that it now takes a few minutes before SunNET figures the best path it can find and
uses it. GENERAL destination and ACK packets no longer enter the
outbound message queue of SunNET. Each message is also handled in its own task
making the time overhead for prcessing messages smaller. This has the added advantage
on MOOs where task quota is enforced by preventing SunNET packets from growing out of
control. A new protocol, RWHO, was added in this release, which will make
@rwho friendlier to the system in the next release (this tries to make sure all nodes
are running the RWHO protocol before it is used).
SunNET 3 is still evolving and is considered alpha software as the features are not
all implemented. The following list of changes are expected for SunNET 3:
- Routing tables will be based on time rather than path length.
- Logical connection objects (ports) will be created and destroyed as needed,
but will be able to be made persistent (remaining across connections) to permit
special filtering, such as removing ansi codes for a message destined for a
non-ansi-compatible site, and possibly allowing some blocking functions. All
input and output to SunNET will pass through these objects.
- Use of the RWHO protocol. This is to be done one release later so that
all nodes are using the updated SunNET version.