[e-cvs] cvs commit: e/doc/to-be-sorted ObjectTransport.html ProxyManager.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Mon, 1 Oct 2001 22:39:02 -0400
markm 01/10/01 22:39:02
Modified: doc/e ECDAFStart.html
doc/elib/distrib/vattp CommSystemOverview.html
DataCommThruFirewalls.html DataComm_startup.html
index.html
doc/to-be-sorted ObjectTransport.html ProxyManager.html
Log:
applied recent renamings to web pages
Revision Changes Path
1.11 +2 -2 e/doc/e/ECDAFStart.html
Index: ECDAFStart.html
===================================================================
RCS file: /cvs/e/doc/e/ECDAFStart.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ECDAFStart.html 2001/09/30 23:43:16 1.10
+++ ECDAFStart.html 2001/10/02 02:39:01 1.11
@@ -472,7 +472,7 @@
available from the <font face="Courier">EEnvironment</font>. The methods:
<pre>
DirectoryRootMaker directoryRootMaker();
- ProxyManager proxyManager();
+ CapTPMgr proxyManager();
Registrar registrar();
UIFramework uiFramework();
</pre>
@@ -480,7 +480,7 @@
root, the proxy manager (which is actually the main capability to the
communications subsystem), the Registrar and the user interface framework.
Consult the Javadoc for the various classes (<font face="Courier">org.erights.e.extern.file.DirectoryRootMaker</font>,
- <font face="Courier">org.erights.e.net.proxy.ProxyManager</font>, <font face="Courier">org.erights.e.net.proxy.Registrar</font>,
+ <font face="Courier">org.erights.e.net.proxy.CapTPMgr</font>, <font face="Courier">org.erights.e.net.proxy.Registrar</font>,
and <font face="Courier">org.erights.e.boot.UIFramework</font>) for more
detail on these capabilities and their use.<br>
<P ALIGN="left">
1.7 +2 -2 e/doc/elib/distrib/vattp/CommSystemOverview.html
Index: CommSystemOverview.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/vattp/CommSystemOverview.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CommSystemOverview.html 2001/09/30 23:43:24 1.6
+++ CommSystemOverview.html 2001/10/02 02:39:01 1.7
@@ -123,8 +123,8 @@
following SturdyRefs to remote objects, and exporting transitory references
to local objects.</li>
</ul>
- <p><b>ConnectionsManager</b> </p>
- <p>Each vat has one instance of the ConnectionsManager (ConnectionsManager.java)
+ <p><b>VatTPMgr</b> </p>
+ <p>Each vat has one instance of the VatTPMgr (VatTPMgr.java)
which performs the following functions: </p>
<ul>
<li>Maintains lists of active and suspended/suspending connections.</li>
1.7 +5 -5 e/doc/elib/distrib/vattp/DataCommThruFirewalls.html
Index: DataCommThruFirewalls.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/vattp/DataCommThruFirewalls.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DataCommThruFirewalls.html 2001/09/30 23:43:24 1.6
+++ DataCommThruFirewalls.html 2001/10/02 02:39:01 1.7
@@ -508,15 +508,15 @@
vat (to preserve the E message ordering rules).</li>
</ul>
<p><a name="Tunnel Only"></a><b>Tunnel Only</b></p>
- <p>Extend the VatIdentity class to have a getConnectionsManager(URL url)
+ <p>Extend the VatIdentity class to have a getVatTPMgr(URL url)
method. The url specifies the HTTP Tunnel server.</p>
<p>Change DataComm to use a SocketFactory to get its Sockets. For direct
connections, this factory returns standard system Sockets. For Tunnel
connections, a different factory returns Sockets which use the HTTP Tunnel
classes for communication. For incoming connections, the HTTP Tunnel classes
- can call ConnectionsManager.newInboundSocket directly or through a Thunk.
+ can call VatTPMgr.newInboundSocket directly or through a Thunk.
The Tunnel classes can directly return the address the server is listening
- at to the ConnectionsManager using the listeningAt(String) method.</p>
+ at to the VatTPMgr using the listeningAt(String) method.</p>
<p>The TunnelSocket will respond to as follows to the standard Socket methods:</p>
<ul>
<li>close() Closes this socket. Sends a <tt><a href="#HTTP_Close">HTTP_Close</a></tt>
@@ -553,7 +553,7 @@
<p>With the above <a href="#Tunnel Only">Tunnel Only</a> architecture and
some additional changes, there are simple answers to the Tunnel and Direct
questions. The changes are to allow more than one socketFactory to be
- active in the objects under a particular ConnectionsManager. The use of
+ active in the objects under a particular VatTPMgr. The use of
multiple factories also allows the vat to listen on more than one interface:port.</p>
<ul>
<li>Which path should it try to connect to a particular vat?</li>
@@ -565,7 +565,7 @@
there is a vat with the desired private key listening there.</p>
<li>How can it assure that it only has one connection to a particular
vat (to preserve the E message ordering rules).</li>
- <p>By running under one ConnectionsManager, duplicate DataConnections
+ <p>By running under one VatTPMgr, duplicate VatTPConnections
will be prevented.</p>
</ul>
<p>
1.8 +8 -8 e/doc/elib/distrib/vattp/DataComm_startup.html
Index: DataComm_startup.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/vattp/DataComm_startup.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DataComm_startup.html 2001/09/30 23:43:24 1.7
+++ DataComm_startup.html 2001/10/02 02:39:01 1.8
@@ -97,29 +97,29 @@
<pre><hr width="100%"></pre>
<p><b><font size=+1>Connection Establishment</font></b></p>
<p>There are three layers of code responsible for connections in the data
- comm system. The top level is ConnectionsManager. It is responsible for
+ comm system. The top level is VatTPMgr. It is responsible for
all the connections between a E vat and other vats. It includes methods
- such as "DataConnection getConnection(remoteVatID , searchPath)" and "connectToVatAt(IP:port)"
+ such as "VatTPConnection getConnection(remoteVatID , searchPath)" and "connectToVatAt(IP:port)"
which either create a connection and returns it, or return an existing
connection.</p>
- <p>The connection to a specific other vat is handled by the DataConnection
+ <p>The connection to a specific other vat is handled by the VatTPConnection
object. It is responsible for building new connections and resuming suspended
connections.</p>
<p>The connection to a specific machine is handled by the DataPath object.
It, along with its SendThread and RecvThread, handles one TCP connection.</p>
<p>The normal connection build process starts with the connection call to
- the ConnectionsManager described above. The remoteVatID parameter specifies
+ the VatTPMgr described above. The remoteVatID parameter specifies
which specific vat is wanted, and the searchPath parameter specifies places
to look for it. The search path is normally a set of Process Location
Servers to query. There is a specific VatID ("0") which is recognized
as "any vat listening at the IP:port passed in the connectToVatAt() call
- on the ConnectionsManager.</p>
+ on the VatTPMgr.</p>
<p>The search for a vat starts by building a DataPath to the first address
on the search path, normally a PLS. If that PLS knows where the vat is,
it returns the IP address and port number which is inserted into the search
path. The currently active instance of DataPath has then completed its
- job, so it closes the TCP connection, and notifies the DataConnection
- that it has shutdown. The DataConnection then builds a new DataPath to
+ job, so it closes the TCP connection, and notifies the VatTPConnection
+ that it has shutdown. The VatTPConnection then builds a new DataPath to
try the next address in the search path.</p>
<p>The connection startup protocol (Alice is connecting to Bob) used by
the DataPath is as follows. Note that there are two interleaved protocol
@@ -158,7 +158,7 @@
<p>If Alice receives TRY, as she would from the PLS, she adds the <possibleAlternatePath>
to her search path and shuts down the DataPath. If she receives NOTME
(NotMe) she just shuts down the DataPath without adding to the path. The
- DataConnection will build a new DataPath to try the next entry in the
+ VatTPConnection will build a new DataPath to try the next entry in the
path (if any).</p>
<p>If Alice receives Bob's IAM:</p>
<pre> Alice: GIVEINFO <UTF aliceVatID> <UTF alicesPathToAlice>
1.12 +56 -56 e/doc/elib/distrib/vattp/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/vattp/index.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- index.html 2001/09/30 23:43:24 1.11
+++ index.html 2001/10/02 02:39:01 1.12
@@ -110,56 +110,56 @@
<p>Conceptual objects</p>
<ul>
<li><tt>VatIdentity </tt>the serializable class which holds the public/private
- keys that define the identity of the vat. It's <tt>getConnectionsManager
- </tt>method is how the <tt>ConnectionsManager </tt>is created.<font size=-1>
+ keys that define the identity of the vat. It's <tt>getVatTPMgr
+ </tt>method is how the <tt>VatTPMgr </tt>is created.<font size=-1>
(Thanks to Arturo Bejar for the suggestion of separating the infrequently
changing vat identity code, which must be saved, from the more frequently
changing communications code which can be recreated after every restart
of the application.)</font></li>
- <li><tt>ConnectionsManager </tt>which manages all the connections.</li>
- <li><tt>DataConnection </tt>which implements a single (TCP) connection.</li>
+ <li><tt>VatTPMgr </tt>which manages all the connections.</li>
+ <li><tt>VatTPConnection </tt>which implements a single (TCP) connection.</li>
<li><tt>ListenThread </tt>which listens for new incoming connections.</li>
</ul>
<p>Connection establishment and tear down</p>
<ul>
- <p><a name="getConnection"></a>The <tt>ConnectionsManager </tt>implements
- a method: <tt>public DataConnection getConnection(String registrarID,
- String[] plsList)</tt> which either returns an existing DataConnection,
+ <p><a name="getConnection"></a>The <tt>VatTPMgr </tt>implements
+ a method: <tt>public VatTPConnection getConnection(String registrarID,
+ String[] plsList)</tt> which either returns an existing VatTPConnection,
or creates a new one and starts it building a network connection. <tt>registrarID
</tt>is the hash of the public key of the desired vat, and <tt>plsList
</tt>is an array of PLS locations to try in attempting to locate that
vat. The PLS locations are <IP address:port number> e.g. <tt>"george.communities.com:1670"</tt>.</p>
<p>Because of the need to build an authenticated connection to the vat
- at an arbitrary IP address, the <tt>ConnectionsManager </tt>also implements
+ at an arbitrary IP address, the <tt>VatTPMgr </tt>also implements
<tt>Promise connectToVatAt(String ipPort)</tt>. <tt>ipPort </tt>is <IP
address:port number> as above. If a remote vat is listening at that
IP:port address, then the <tt>Promise </tt>will be forwarded to the
- <tt>DataConnection </tt>when the remote vat has been identified. If
+ <tt>VatTPConnection </tt>when the remote vat has been identified. If
a connection error occurs before the remote vat is identified, then
the Promise will be "smashed". Since this connection is a
full fledged E-vat to E-vat connection, the <tt>NewConnectionNoticer
</tt>registered with <tt><a href="#registerNewConnectionNoticer">registerNewConnectionNoticer()</a></tt>
will be called to hook up the normal E connection services.</p>
- <p>The <tt>ConnectionsManager</tt> implements a registration method <tt>public
+ <p>The <tt>VatTPMgr</tt> implements a registration method <tt>public
void <a name="registerNewConnectionNoticer"></a>registerNewConnectionNoticer(NewConnectionNoticer
- noticer)</tt>. It will call the object registered for each new DataConnection
- with public <tt>void noticeNewConnection(DataConnection connection)</tt>.
+ noticer)</tt>. It will call the object registered for each new VatTPConnection
+ with public <tt>void noticeNewConnection(VatTPConnection connection)</tt>.
This call is designed to allow higher levels to register their <a href="#Receiving">message
handlers</a> on new inbound connections.</p>
<p>To allow all the necessary "plumbing" to be connected when
- a connection is established, the DataConnection object will not send
+ a connection is established, the VatTPConnection object will not send
or receive any high level data until the <tt>noticeNewConnection </tt>method
of the registered <tt><a href="#registerNewConnectionNoticer">NewConnectionNoticer
</a></tt>has returned. This method should ensure that all the necessary
<a href="#Receiving">message handlers</a> have been registered.</p>
- <p>Each <tt>DataConnection </tt>implements a method: <tt>public void shutDownConnection()</tt>
- which closes the connection. After this call the <tt>DataConnection
+ <p>Each <tt>VatTPConnection </tt>implements a method: <tt>public void shutDownConnection()</tt>
+ which closes the connection. After this call the <tt>VatTPConnection
</tt>object is no longer usable and should be discarded so it can be
garbage collected.</p>
</ul>
<p>Sending Data</p>
<ul>
- <p>Each <tt>DataConnection </tt>implements two methods: <tt>public void
+ <p>Each <tt>VatTPConnection </tt>implements two methods: <tt>public void
sendMsg(byte[] message) throws IOException </tt>and <tt>public void
sendMsg(byte[] message, Runnable notification, Runner placeToRun) throws
IOException</tt>.</p>
@@ -205,28 +205,28 @@
</ul>
<p><a name="Receiving"></a>Receiving Data</p>
<ul>
- <p>Each <tt>DataConnection </tt>implements a method: <tt>public void registerMsgHandler(int
+ <p>Each <tt>VatTPConnection </tt>implements a method: <tt>public void registerMsgHandler(int
msgType, MsgHandler handler) throws IOException</tt>. The parameter
<tt>msgType </tt>is the message type to be handled (from <tt>MsgTypes</tt>).
An attempt to register more than one handler for a message type, or
to register for an invalid message type will throw an exception. The
parameter <tt>handler </tt>is an object which will handle the message
data. It will be called with: <tt>void processMessage(byte[] message,
- DataConnection connection)</tt>where <tt>message </tt>is the only reference
- to the byte array, and connection is the DataConnection object which
+ VatTPConnection connection)</tt>where <tt>message </tt>is the only reference
+ to the byte array, and connection is the VatTPConnection object which
received the message. Note that one handler can process more than one
message type by selecting on the first byte of the message. One handler
- can process more than one connection by selecting based on the DataConnection
+ can process more than one connection by selecting based on the VatTPConnection
object passed.</p>
</ul>
<p><a name="Failure"></a>Failure Notification</p>
<ul>
- <p>There are at least two queues between the <tt>DataConnection </tt>and
- the network hardware. One is maintained as part of the <tt>DataConnection
+ <p>There are at least two queues between the <tt>VatTPConnection </tt>and
+ the network hardware. One is maintained as part of the <tt>VatTPConnection
</tt>and allows <tt>sendMessage </tt>to be non-blocking. The other is
maintained as part of the JavaVM/Platform TCP implementation. Senders
are only notified of problems known before the message is placed in
- the <tt>DataConnection </tt>output queue. If a problem occurs when a
+ the <tt>VatTPConnection </tt>output queue. If a problem occurs when a
message is in either of the output queues, the message is silently discarded.
However, any failure to deliver an outbound message will cause the connection
to be terminated. This termination will notify the input message handlers.</p>
@@ -261,13 +261,13 @@
<ul>
<li><tt>VatIdentity </tt>- Owns the public/private keys which define the
identity of the vat.</li>
- <li><tt>ConnectionsManager </tt>- Manages the connections from this vat
+ <li><tt>VatTPMgr </tt>- Manages the connections from this vat
to other vats.</li>
- <li><tt>DataConnection </tt>- Manages one logical connection from this
+ <li><tt>VatTPConnection </tt>- Manages one logical connection from this
vat to a single other vat.</li>
<li><tt>DataPath </tt>- Manages a single (TCP) connection. DataPaths can
come and go with suspend/resume events and crossed connections while
- the <tt>DataConnection </tt>persists.</li>
+ the <tt>VatTPConnection </tt>persists.</li>
<li><tt>SendThread </tt>- A separate thread which sends data to the TCP
socket. It is a separate thread to allow sends to be non-blocking.</li>
<li><tt>RecvThread </tt>- A spearate thread to listen to the socket for
@@ -280,17 +280,17 @@
<p><b>Startup, Shutdown, and Steady State</b></p>
<p>The construction starts with a <tt>VatIdentity </tt>object which has
either been instantiated or restored from a checkpoint. We further assume
- that it has been called for the instance of its <tt>ConnectionsManager
+ that it has been called for the instance of its <tt>VatTPMgr
</tt>so the connections manager has been built. As part of building the
connections manager, the <tt>ListenThread </tt>has been created and started.</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>There is a <tt>DataConnection </tt>object which is connected to the higher-level
- things. That <tt>DataConnection </tt>object is connected to a <tt>DataPath
+ <p>There is a <tt>VatTPConnection </tt>object which is connected to the higher-level
+ things. That <tt>VatTPConnection </tt>object is connected to a <tt>DataPath
</tt>object which is connected to a <tt>SendThread </tt>and a <tt>RecvThread</tt>.
- The <tt>ConnectionsManager </tt>has the <tt>DataConnection </tt>object
+ The <tt>VatTPMgr </tt>has the <tt>VatTPConnection </tt>object
registered in its list of running connections.</p>
<p>Startup Protocol</p>
<p>The startup protocol is handled by <tt>StartUpProtocol</tt>. It identifies
@@ -330,9 +330,9 @@
the E comm protocol/encryption technique, and the attempt will fail. In
this last case, the other addresses in the list will be tried.</p>
<p><a name="OutboundStartup"></a>Outbound Startup</p>
- <p>The <tt>ConnectionsManager </tt>has been called for a connection to a
+ <p>The <tt>VatTPMgr </tt>has been called for a connection to a
remote vat. It has determined that no existing connection exists. It creates
- a new <tt>DataConnection </tt>object which in turn creates a <tt>DataPath
+ a new <tt>VatTPConnection </tt>object which in turn creates a <tt>DataPath
</tt>object and a <tt>StartUpProtocol </tt>object. The <tt>DataPath </tt>object
creates a <tt>SendThread </tt>which builds a TCP connection to the first
address in the search path and then creates a <tt>RecvThread</tt>. The
@@ -343,30 +343,30 @@
for the next address in the search list.</p>
<p>Inbound Startup</p>
<p>The <tt>ListenThread </tt>receives the incoming socket and passes it
- to the <tt>ConnectionsManager</tt>. The <tt>ConnectionsManager </tt>creates
+ to the <tt>VatTPMgr</tt>. The <tt>VatTPMgr </tt>creates
a <tt>DataPath </tt>object to perform the startup protocol with this socket.
When the startup protocol has proceeded far enough to identify the remote
- vat, the <tt>ConnectionsManager </tt>is used to either connect it to an
- existing <tt>DataConnection </tt>object or to create a new one. If it
- is connected to an existing <tt>DataConnection </tt>object, there may
+ vat, the <tt>VatTPMgr </tt>is used to either connect it to an
+ existing <tt>VatTPConnection </tt>object or to create a new one. If it
+ is connected to an existing <tt>VatTPConnection </tt>object, there may
be a crossed connection to contend with. If there is a crossed connection,
the two <tt>StartUpProtocol </tt>objects work through the two <tt>DataPath
- </tt>objects and the single <tt>DataConnection </tt>object to resolve
+ </tt>objects and the single <tt>VatTPConnection </tt>object to resolve
the connection down to only one <tt>DataPath </tt>object.</p>
<p>Shutdown</p>
- <p>When a request to shutdown the connection is received by the <tt>DataConnection</tt>,
+ <p>When a request to shutdown the connection is received by the <tt>VatTPConnection</tt>,
it sends a shutdown message to the other end. It will not send any new
messages after it has sent the shutdown message. When the other end receives
the shutdown message, it notifies its registered <tt>MsgHandler </tt>objects
that the connection has shut down and echos the shut down message. It
then closes the socket, destroys the <tt>SendThread</tt>, and <tt>RecvThread</tt>,
- and notifies its <tt>DataConnection </tt>that it is dead. When the connection
+ and notifies its <tt>VatTPConnection </tt>that it is dead. When the connection
that originated the shutdown receives the shutdown message, it performs
the same cleanup.</p>
<p>Suspend </p>
- <p>Suspend is similar to shutdown except that the <tt>DataConnection </tt>remains
+ <p>Suspend is similar to shutdown except that the <tt>VatTPConnection </tt>remains
in suspended state instead of becoming dead. Any attempt to send a message
- on a suspended <tt>DataConnection </tt>object will initiate a new connection
+ on a suspended <tt>VatTPConnection </tt>object will initiate a new connection
attempt as in <a href="#OutboundStartup">Outbound Startup</a>.</p>
<p>Resume</p>
<p>Resume is very much like startup. Part way thru the startup protocol,
@@ -386,13 +386,13 @@
file missing) explain how to use JavaDoc effectively.</i> </p>
<h4>Examples</h4>
<p>All of these examples assume that a VatIdentity object, called <tt>vi</tt>,
- has been build and a ConnectionsManager object has been collected by <tt>ConnectionsManager
- cm = vi.getConnectionsManager(...)</tt>. Furthermore, a permanent NewConnectionNoticer
- object, called <tt>ncn</tt>, has been registered with the ConnectionsManager.</p>
+ has been build and a VatTPMgr object has been collected by <tt>VatTPMgr
+ cm = vi.getVatTPMgr(...)</tt>. Furthermore, a permanent NewConnectionNoticer
+ object, called <tt>ncn</tt>, has been registered with the VatTPMgr.</p>
<ul>
<li>Building a connection to connect a proxy to a remote object</li>
<ol>
- <li><tt>DataConnection dc = cm.getConnection(...);</tt></li>
+ <li><tt>VatTPConnection dc = cm.getConnection(...);</tt></li>
<li><tt>MsgHandler mh = new RelayMsgHandler(...);</tt></li>
<li><tt>dc.registerMsgHandler(Msg.E_MSG, mh);</tt></li>
<li><tt>dc.sendMsg(</tt>first proxy protocol message<tt>);</tt></li>
@@ -422,11 +422,11 @@
<ol>
<li><tt>if (myPromise.state == "BROKEN")</tt> //bitch and
moan, we didn't find the PLS. <tt>return;</tt></li>
- <li><tt>DataConnection dc = (DataConnection)o; </tt>// Kept, object
- is the DataConnection</li>
+ <li><tt>VatTPConnection dc = (VatTPConnection)o; </tt>// Kept, object
+ is the VatTPConnection</li>
<li><tt>String rid = dc.getRemoteRegistrarID();</tt></li>
<li><tt>rn </tt>then creates a sturdy ref for the well known PLS registration
- swiss number, <tt>sn, </tt>and calls the <tt>ProxyManager </tt>to
+ swiss number, <tt>sn, </tt>and calls the <tt>CapTPMgr </tt>to
resolve it: <tt>Proxy rp = proxyManager.resolveReference(rid, null,
sn);</tt></li>
<li>It can then engage in the registration protocol using the standard
@@ -455,8 +455,8 @@
<ol>
<li><tt>if (myPromise.state == "BROKEN")</tt> //bitch and
moan, we didn't find the PLS. <tt>return;</tt></li>
- <li><tt>DataConnection dc = (DataConnection)o; </tt>// Kept, object
- is the DataConnection</li>
+ <li><tt>VatTPConnection dc = (VatTPConnection)o; </tt>// Kept, object
+ is the VatTPConnection</li>
<li><tt>RegistrationMsgHandler rmh = new RegistrationMsgHandler(...);</tt></li>
<li><tt>dc.registerMsgHandler(Msg.PLS_PROTOCOL, rmh);</tt></li>
<li><tt>dc.sendMsg(</tt>first message in PLS registration protocol<tt>)</tt></li>
@@ -489,12 +489,12 @@
where the startup protocol can complete before the higher levels have
registered their listeners. If this occurs, incoming messages may be
dropped (with error spam). This issue is resolved with the introduction
- of the enable() method on the DataConnection. [7/7/98]Upon reflection,
- the enable method is unnecessary. The ConnectionsManager is notified
+ of the enable() method on the VatTPConnection. [7/7/98]Upon reflection,
+ the enable method is unnecessary. The VatTPMgr is notified
that the connection is RUNNING when the last start up protocol message
is processed. It calls the registered NewConnectionNoticer as a result
of that notification. It can register the MsgHandlers before it returns
- which is before the RecvThread can introduce new messages into the DataPath/DataConnection
+ which is before the RecvThread can introduce new messages into the DataPath/VatTPConnection
(since the RecvThread is busy while the last start up message finishes
being processed.)</li>
</ul>
@@ -527,7 +527,7 @@
to our PLS requirements?</li>
<li>[as of 6/15/98] The reconnection of suspend connections is messy.
A connection which is being resumed needs to be connected to the old
- DataConnection object so that object's clients are unaware of the suspend/resume.
+ VatTPConnection object so that object's clients are unaware of the suspend/resume.
In R167 this was handled with two objects, but it would be nice to avoid
the overhead of the extra method invocations multiple objects require.</li>
</ul>
@@ -565,8 +565,8 @@
in object creation and extra classes?</p>
<p>The version as of 6/16/98 uses a single thunk with the messy switch statement
for communication from the <tt>SendThread </tt>and <tt>RecvThread </tt>to
- the <tt>DataConnection</tt>. The CRAPI interface is used to notify the
- <tt>ConnectionsManager </tt>of newly arrived <tt>Sockets</tt>.</p>
+ the <tt>VatTPConnection</tt>. The CRAPI interface is used to notify the
+ <tt>VatTPMgr </tt>of newly arrived <tt>Sockets</tt>.</p>
<P ALIGN="left">
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
1.6 +2 -2 e/doc/to-be-sorted/ObjectTransport.html
Index: ObjectTransport.html
===================================================================
RCS file: /cvs/e/doc/to-be-sorted/ObjectTransport.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ObjectTransport.html 1999/06/23 18:34:22 1.5
+++ ObjectTransport.html 2001/10/02 02:39:02 1.6
@@ -103,7 +103,7 @@
<P>myObjectConnection.send(myRemoteObjectID, envelope).
-<P>The ObjectConnection has as part of its state the DataConnection which
+<P>The ObjectConnection has as part of its state the VatTPConnection which
leads to the remote object. (It also implements a message handler
for incoming envelopes.) The ObjectConnection does:
@@ -112,7 +112,7 @@
<BR><TT> = new CommObjectOutputStream(myByteArrayOutputStream);</TT>
<BR><TT>coos.write...(remoteObjectID);</TT>
<BR><TT>coos.writeObject(envelope);</TT>
-<BR><TT>myDataConnection.sendMsg(myByteArrayOutputStream.toByteArray());</TT>
+<BR><TT>myVatTPConnection.sendMsg(myByteArrayOutputStream.toByteArray());</TT>
<P>* We may be able to move the allocation of new CommObjectOutputStream
out
1.8 +1 -1 e/doc/to-be-sorted/ProxyManager.html
Index: ProxyManager.html
===================================================================
RCS file: /cvs/e/doc/to-be-sorted/ProxyManager.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ProxyManager.html 2001/04/14 19:56:57 1.7
+++ ProxyManager.html 2001/10/02 02:39:02 1.8
@@ -55,7 +55,7 @@
remote object (a table index, perhaps?)</LI> <LI>The proxy constructor
finishes, and the proxy is now ready to accept 'E.Send' requests</LI>
</OL>
-<IMG SRC="ProxyManagerArch.gif" WIDTH="544" HEIGHT="391" HSPACE="0" VSPACE="0">
+<IMG SRC="CapTPMgrArch.gif" WIDTH="544" HEIGHT="391" HSPACE="0" VSPACE="0">
<P>The life cycle of a proxy, and how they are created and destroyed can be found in the <A HREF="ProxyLifeCycle.html">Proxy Life Cycle</A> document.
<H4>
Which directories on our tree does this subsystem cover?</H4>