[e-cvs] cvs commit: e/doc/elib/distrib/vattp VLS.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Tue, 16 Oct 2001 05:12:39 -0400
markm 01/10/16 05:12:39
Modified: doc/elib/distrib/vattp VLS.html
Log:
Bill's VLS writeup
Revision Changes Path
1.6 +106 -1 e/doc/elib/distrib/vattp/VLS.html
Index: VLS.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/vattp/VLS.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- VLS.html 2001/09/30 23:43:24 1.5
+++ VLS.html 2001/10/16 09:12:38 1.6
@@ -47,7 +47,112 @@
</TABLE>
<hr>
<!-- #BeginEditable "LongBody" -->
- <P ALIGN="left">Coming soon...
+ <p><b>Last updated:</b><i> </i>[2001/10/03 Bill]<br>
+ <p>Author: <a href="mailto:frantz@pwpconsult.com">Bill Frantz</a> </p>
+ <h2>Introduction</h2>
+ <p>The Vat Location Service (VLS) maintains an association between the vat
+ IDs of client vats, and the IP address and port by which they may be reached.
+ (A vat is the part of the E implementation that has a unique network identity.)</p>
+ <h4>Related Documents</h4>
+ <p>See <a href="CommSystemOverview.html">Comm System Overview</a> for information
+ about the VatTP communicaton system.</p>
+ <p>See <a href="DataCommThruFirewalls.html">E Data Comm System Through Firewalls</a>
+ for some thoughts on working through firewalls.</p>
+ <h2>Requirements</h2>
+ <p>The basic requirements of the VLS are: address association, entry aging,
+ DOS protection, and firewall traversal</p>
+ <ul>
+ <li>Address association: For each vat which has recently registered with
+ the VLS, the VLS will maintain the netword address(es) at which that
+ vat may be located.</li>
+ <li>Entry aging: The VLS will conserve storage by eliminating associations
+ which have not been refreshed within a timeout interval.</li>
+ <li>DOS protection: The VLS will protect against certain kinds of denial
+ or service (DOS) attacks. Specifically, it will require all registrations
+ to have a serial number, and be digitally signed by the VAT's private
+ key. (Note that the digital signatures do not always have to be checked.</li>
+ <li>Firewall traversal: The VLS will aid in operating across firewalls
+ by performing certain IP Address translations.</li>
+ </ul>
+ <h2>Architecture</h2>
+ <p>The VLS will be a stand-alone Java program. Detailed architecture TBD...</p>
+ <p>Basic registration logic flow</p>
+ <ol type=1 start="1">
+ <li>A vat wishing to register with the VLS builds a connection to it and
+ and sends a registration message.</li>
+ <li>The VLS reads the registration message and checks if it already has
+ a registration for the vat. If it does not, the VLS builds a new registration
+ which includes the VatID, the time of registration, the message serial
+ number, the IP Address, and sufficient information to check the
+ signature, completing processing of the message.</li>
+ <li>If there is already a registration for the vat, and the IP Address
+ in the message is the same as in the registraton, and the serial number
+ in the message is bigger, but not too much bigger than that in the registration,
+ then the VLS updates the time of registration, the serial number, and
+ the signature information, completing processing of the message.</li>
+ <li>The VLS checks serial number in the message. If it is less than that
+ in the registration, the VLS returns an error indication including the
+ current serial number, completing processing of the message.</li>
+ <li>The VLS checks the signature on the message. If it verifies, then
+ the VLS creates removes the old registration and creates a new registration
+ based on the data in the message, completing processing of the message.</li>
+ </ol>
+ <p>Basic lookup logic flow</p>
+ <ol type=1 start="1">
+ <li>A vat wishing to locate another vat uses the standard <a href="DataComm_startup.html">VatTP
+ startup protocol</a> to build a connection to the VLS.</li>
+ <li>After receiving the desired VatID, the VLS checks if it is registered.
+ If it is not registered, the VLS returns TOK_NOT_ME to the connecting
+ vat.</li>
+ If it is registered, the VLS returns TOK_TRY with the registered address(es)
+ to the connecting vat.
+ </ol>
+ <h4>Off the shelf alternatives</h4>
+ <p>I don't know of any off the shelf alternatives that are available.</p>
+ <h4>Other Design Objectives, Constraints and Assumptions</h4>
+ <p>TBD</p>
+ <h2>Current implementation</h2>
+ <p>TBD</p>
+ <p><b>Startup, Shutdown, and Steady State</b></p>
+ <p>The object of startup is to create the objects needed for the steady
+ state. The object of shutdown is to clean up the steady state. Because
+ of these objectives, I will describe the steady state first.</p>
+ <p>Steady State</p>
+ <p>TBD</p>
+ <p>Startup Protocol</p>
+ <p>TBD</p>
+ <p>Shutdown</p>
+ <p>TBD</p>
+ <p>
+ <hr width="100%">
+ <p></p>
+ <h4>Which directories on our tree does this subsystem cover?</h4>
+ <p>TBD</p>
+ <h4>Is it JavaDoc'ed?</h4>
+ <p>TBD</p>
+ <h4>Examples</h4>
+ <p>TBD</p>
+ <h4>Testing and Debugging</h4>
+ <p>TBD</p>
+ <h2>Design Issues</h2>
+ <h4>Resolved Issues</h4>
+ <p><i>History of issues raised and resolved during initial design, or during
+ design inspections. Can also include alternative designs, with the reasons
+ why they were rejected</i> </p>
+ <h4>Open Issues</h4>
+ <ul>
+ <li>In 1.1.3, Java appears to get the IP address of the machine once at
+ startup. In the case of someone running Microcosm who is dropped by
+ their ISP, they get a new IP address when they re-dial. We need
+ to deal with this problem one way or another.</li>
+ <li>Sidney suggests having a way to configure the "listen" address
+ (IP + port number) during VLS registration to handle certain proxying
+ firewalls.</li>
+ <li>Does LDAP (Lightweight Directory Access Protocol) have any application
+ to our VLS requirements
+
+ </li>
+ </ul>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>