|
|
This patch is intended for use on a CVW 3.x or higher server.
[A]----[B]-+ [H]----[I]----[J]
| \_____ | __|
| \ | |
| [C]----[D]---[E]---[G]
| |
+-------------------[F]------+
With such a setup, we have 10 network nodes that can each talk to each other. However we do not need to have 45 links (one from each node to each other node) criscrossing all over the network in order for this to work. We also do not need to have every node connect to a central hub, either. We *could* set up that many links, but it's not necessary.
A can talk to E by taking one of several routes:
A > B > C > D > E A > C > D > E A > F > G > E
SunNET chooses the path by timing the connection between the nodes and chooses the best (fastest) route. Therefore, if A has a fast link to B, and B has a fast link to C, but A has a very slow link to C, then SunNET will automatically route all traffic from A to C through B, even though A and C have a direct link.
Also, in this setup, if D suddenly drops off of the network, then the rest of the servers can talk to each other still. For instance, C is still able to talk to E by routing all the way around through the other nodes. However if the link between I and E broke down, then the federation would be split in two. The H, I, and J servers would be able to talk only to each other, and A, B, C, D, E, F, and G would be able to talk to each other, but the two groups would no longer be able to communicate with each other until a link between the two groups was reestablished.
A link in SunNET is actually a player which connects to a remote server in the same way that a normal user connects to a server. Information is passed via the SunNET architecture through the player to the remote server. This setup overcomes some of the difficulties of Multi-port-listening, the other major method of connecting MOOs to each other, such as having connections time out.
Links communicate between servers using protocols. Each protocol is a one-way communication mechanism which passes a set of native MOO values (strings, lists, objects, etc)
Remote detail request
@rdetail #obj@server[, #obj@server[, ...]]
An example display (for an object and a user):
@rdetail #22@oneserver, #1176@oneserver
Remote Detail request for oneserver:
-------------------------------------------------
Verb Help DB (#22)
A `help database' that knows about all of the documented verbs.
-------------------------------------------------
Bob (#1176)
I'm a lumberjack, and I'm O.K.
Full name: Robert Q. Public
Office: 7B
Phone: x1337
Email: bob@whatabob.com
Badge: 42
-------------------------------------------------
Note that information could be requested from multiple servers in one line by simply specifying a different server after the @ symbol.
Remote information request
@rinfo #obj@server[, #obj@server[, ...]]
For example:
@rinfo #22@oneserver
Remote Info request for oneserver:
-------------------------------------------------
Verb Help DB (#22)
Non-Sessile
Owner (remote #): #35
Icon: unknown
Type: Unknown
Location (rem #): #-1
Modified: Tue Mar 2 15:47:37 1999 EST
Modified by (rem #): #2
Created: Tue Mar 2 15:47:37 1999 EST
-------------------------------------------------
The argument list for @rinfo follows the same rules as @rdetail, above.
@page user@server[,user@server[, ...]] [with] message
Bob (on Oneserver) enters:
@page joe@otherserver Hey, have you seen my llama lately?
Joe (on Otherserver) sees:
Bob@oneserver is requesting your attention.
Bob pages, "Hey, have you seen my llama lately?"
Bob (on Oneserver) then sees:
Your message has been sent. (to Joe)
Remote pasting
@paste user@server
The user enters the command as above, followed by lines of text to send. These lines are concluded by a single period (".") alone on a line. The user then recieves a single-line response from the remote server, signifying the outcome of the paste attempt.
Remote user list
@who [user]@server [[user]@server ...]
To see if a particular user on a particular server is online, or idle, enter name@server. To get a list of all users on a particular server, simply request @server. For example, to see if Bob on Oneserver is around, enter:
@who bob@oneserver
Which would return something like:
You have requested @who information from 1 federated server. This may take a while.
Player Name Idle Location Idle State
-------------------- ---- ---------- ----------
Bob@oneserver 2m The Lobby
To get a list of everyone who's online over at Otherserver, enter:
@who @oneserver
Which would return something like:
You have requested @who information from 1 federated server. This may take a while.
Player Name Idle Location Idle State
-------------------- ---- ---------- ----------
SunNET_Otherserver@o 0s SunNET Box
SunNET_server3@onese 10m SunNET Box
Bob@oneserver 2m The Lobby
The following objects/verbs have been added to the CVW core:
$sunnet => main SunNET system
$sunnet_utils => additional SunNET utilities
$sunnet_pc => player class with command line interface verbs
$sunnet_protocols => the base level SunNET protocols
$sunnet_link => player class for links between servers
$sunnet_fo, $sunnet_db,
$sunnet_scheduler => various other SunNET things
$login:REGISTER => connection verb for SunNET links
$cvw_sunnet => CVW specific SunNET extensions
$sunnet_box => room to house the SunNET links
The main change to the core of CVW is the suite of SunNET objects, which enable all of the basic SunNET functionality within a system. Several features (remote verb calling specifically) have been disabled to improve security, but most of it is the standard SunNET system.
In addition to the core (slightly modified) SunNET package, there is an object with the definitions for the protocols and additional programs specific to this CVW implementation of SunNET. Protocols include:
RDETAIL, RDETAIL-R => remote detail information request
RINFO, RINFO-R => remote information request
RWHO, RWHO-R => remote user listing
RPAGE, RPAGE-R => remote paging
RPASTE, RPASTE-R => remote pasting
Other features implemented on the $cvw_sunnet object are a task reaper, for servers that don't respond; an information filtering mechanism, which allows for greater privacy and security for site; and a cache database system (which creates children of $generic_db as needed), to ease some of the extra strain placed on the network by detail and info requests.
The CVW extensions to SunNET are powered by a set of newly defined protocols (mentioned above) which have the following formats. Note that SunNET protocols send and receive information using native MOO data types. The protocols are designed to operate in pairs; below the outgoing protocol (a request for information, an outgoing page, etc) is denoted by -> while an incoming protocol (the response issued by the remote server, <NAME>-R) is denoted by <- with notes for which case the information is returned.
RWHO
-> id, ({OBJ || STR user1 ... userN} | "online" | /* "all" */ )
RWHO-R
<- id, [ {OBJ user, STR username, STR full name, OBJ location, NUM busy,
NUM idle, NUM idle state, STR message} [, ...] ]
------------------------------------------------------------
RDETAIL
-> id, {obj#, ...}
RDETAIL-R
object:
<- id, {{OBJ object, STR name, {STR description}, {OBJ owner1, ... , OBJ ownerN},
[path/""], [info only/""]}, ...}
user:
<- id, {{OBJ object, STR name, {STR description}, {OBJ owner1, ..., OBJ ownerN},
STR full_name, STR office, STR phone, STR email_address, STR badge,
STR gender, OBJ location}, ...}
error:
<- id, msg
------------------------------------------------------------
RINFO
-> id, {OBJ object[, ...]}
RINFO-R
object:
<- id, {{OBJ object, STR name, NUM sessile?, {OBJ owner}, STR group, STR type,
OBJ location, NUM last modified date, OBJ last modified by,
NUM creation date}[, ...]}
error:
<- id, {{OBJ $failed_match, STR error message}[, ...]}
------------------------------------------------------------
RPAGE
-> id, OBJ sender, NUM time, STR level, STR type, OBJ {to, ...}, {msg},
STR {all recipients, ...}
RPAGE-R
object (error or success):
<- id, sender, {{STR to, STR response, OBJ to} .. }
no object error:
<- id, sender, {{STR to, STR response, STR error} .. }
------------------------------------------------------------
RPASTE
-> id, OBJ from, OBJ to, {STR msg}
RPASTE-R
<- id, err?
------------------------------------------------------------
RPHONE
-> id, from#, to#, ip###.###.###.###, port#, when
RPHONE-R
<- id, [0/1/2/3/4/5/6/7/8/9/10]
------------------------------------------------------------
RNODE
-> id
RNODE-R
<- id, {"CVW Server", STR servername, STR address, NUM port,
{OBJ adminstaff[, ...]}, NUM uptime}
<- id, {"CVW DocServer", STR servername, STR url}
Last update: 21 September 2001
This work, including the source code, documentation and
related data, is placed into the public domain.
The original author is
The MITRE Corporation.
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, AS TO THIS
SOFTWARE, OR TO THE ACCURACY, CAPABILITY, EFFICIENCY,
OR FUNCTIONING OF THIS SOFTWARE OR ANY DERIVATIVE WORK
OR OTHER ITEM MADE, USED, OR SOLD THAT INCORPORATES
THIS SOFTWARE. THE AUTHOR OF THIS SOFTWARE ASSUMES NO
RESPONSIBILITY FOR ANY CONSEQUENCE RESULTING FROM THE
USE, MODIFICATION, OR REDISTRIBUTION OF THIS SOFTWARE.
Information in this document is subject to change without notice.
Other products and companies referred to herein are trademarks or registered
trademarks of their respective companies or mark holders.