[252] in Zephyr_Comments
Zephyr inter-realm proposal (please comment)
jtkohl@ATHENA.MIT.EDU (jtkohl@ATHENA.MIT.EDU)
Tue May 16 12:12:14 1989
This is a bit out of order, but I didn't put zephyr-comments on the
initial to: or cc: list...
Date: Tue, 16 May 89 11:58:07 EDT
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: sysdev@ATHENA.MIT.EDU
Cc: zephyr-team@ATHENA.MIT.EDU, zephyr-dev@ATHENA.MIT.EDU
Subject: Zephyr inter-realm proposal (please comment)
Reply-To: zephyr-comments@ATHENA.MIT.EDU
Last month the Zephyr team met and discussed ways of making inter-realm
zephyr work.
Following is a description of what we came up with. Please
read and comment.
John
-------------------snip snip-------------------------
Sending notices to a foreign realm:
----------------------------------
When a client sends a notice with a recipient field naming a recipient
in some other realm, the local zephyr server forwards the notice to the
server for the foreign realm [all notices are initially sent to the
local server by the HostManager].
If authentication is desired, then a ticket & authenticator for the
realm of the foreign server should be included in the notice (the local
server will forward this ticket with the notice).
It is permissible to specify a recipient of "*"@foreign.realm, to
indicate a remote multicast. The notice is transmitted to the remote
realm server, and then treated as a multicast, using the subscription
info maintained by the foreign Zephyr server.
Acknowledgments of delivery or non-delivery will be sent by the foreign
server directly to the sending client (in the same way acknowledgments
are sent by the local servers to clients).
Sending to a local realm will work as before.
Subscriptions between realms:
----------------------------
If a client sends a subscription message to the server with a recipient
field denoting something in a foreign realm, the subscription request is
forwarded by the local server to the foreign server for that realm.
Authentication information may be included if necessary to establish
authorization.
NOTE: Because of the operation of the proposed inter-realm transmission
mechanism, it only makes sense to subscribe to foreign broadcasts, i.e.
recipient "*"@foreign.realm (unless we introduce some conventions or
access control policies/mechanisms about subscribing to messages sent to
other principals; this is something we do not want to address or allow).
As an optimization to help eradicate stale subscription data in foreign
realm servers, the HostManager may keep a list of realms which have been
named in subscriptions since last initialization, and send flush notices
to these realms upon reinitialization (e.g. deactivate time).
When a server is transmitting a notice, and finds a foreign-realm
recipient on its multicast list (e.g. testuser@ATHENA.MIT.EDU subscribes to
message,consult,"*"@LCS.MIT.EDU), the notice is sent directly to the
foreign client (e.g. the LCS server sends the notice directly to
testuser's workstation).
Timeout values may be adjusted to account for non-local delays.
Host flushing of foreign hosts (when a server notices an unresponsive
client, and attempts to verify that the software on the host is still
operational) will operate as before, but may be made more tolerant of
network delays or faults. For example, testuser kills his zwgc, without
flushing subscriptions in the LCS realm, and someone later sends a
notice which is sent to testuser by the LCS server, and the LCS server
eventually notices the lack of acknowledgment from the dead zwgc, and
polls testuser's workstation to see if it is just a dead client, or a
dead host.
Location Information:
--------------------
A user's locations will only be maintained by the server for his realm.
[The zephyr server stores user locations separately from subscriptions.]
If a client attempts to locate a user in some other realm, the location
request is forwarded to the server for that realm, and appropriate
visibility level controls are applied. The foreign realm's server will
send replies to the local client.
