DataComm directions

Bill Frantz frantz@communities.com
Mon, 26 Oct 1998 12:44:21 -0800


I have two reasons in writing this.  One is to test Tyler's contention that
a large number of methods imply bad design.  (I think the design is OK,
others may differ, but at least they can read the code.)  The other is to
describe some future directions I see for the DataComm layer (i.e. the
...elib.net.data package).

The DataComm package makes heavy use of the Java visibility controls,
public, private, and /*package*/.  These controls reduce a very hairy
internal design to a much simpler public interface.  One of the design
goals of the DataComm package was to reduce the number of classes and
interfaces, because each class has a significant runtime cost.  (Instances
are considerably cheaper.)

The major classes and methods in the public interface are:

VatIdentity - Which holds the private key which defines the identity
   getConnectionsManager (3 versions)
   calculateVatID - publicKey -> String via secure hash
   getVatID - Return the vatID of this vat.
   + 2 non-public methods for serialization

ConnectionsManager - Which gets and manages connections
   connectToVatAt (2 versions) - Connects to IP and finds out vatID
   getConnection - Connects to a vatID
   getListenAddress - Returns address where this vat is listening
   registerNewConnectionNoticer - for notification of new connections
   setProcessLocationLookup - register process location service
   + 21 non-public methods for internal package/class use

DataConnection - Which manages a particular connection
   getLocalNetAddr - get's the local net IP:port
   getLocalVatID - the name says it all
   getRemoteSearchPath - gets the search path (why public?)
   getRemoteVatID - the name says it all
   getRemoteNetAddr - get's the other end's IP:port as we know it
   registerMsgHandler - register to receive messages
   sendMsg (2 versions) - send a message
   shutDownConnection - shut down this connection
   suspend - suspend this connection
   + 21 non-public methods for internal package/class use

In addition, there are 12 non-public classes.


I submit that this is not simple.  Nor is it currently adequate for all
uses.  Here are the major (as I see it) unfinished pieces.

(1) Error reporting:  The current system says that an error has occurred,
but it doesn't say what the error was.  This problem is particularly acute
when a connection fails to build.  With the search path logic, there may be
more than one reason why a connection couldn't be built.  Currently the
DataConnection object has an internal data structure which lists for each
address tried the reason it gave up.  It lists the reasons as strings, and
doesn't always remember the IP:port it was trying.  It should probably be a
list of throwables and IP:port addresses.

Reporting can go two ways.  The MsgHandler interface includes a
connectionDead method which is the official notification that a connection
has died.  We could expand that to include the reason vector, breaking
every class implementing that interface, or we could add a call on the
DataConnection to return that vector.  (N.B. vector, not Vector.)

(2) Closing connections:  Currently the DataConnection has the
shutDownConnection method.  This solution works well if there is only one
client of DataComm (e.g. ProxyComm  ...elib.net.proxy), because the
protocol of, "are we both ready to shutdown" can be handled at the higher
level.  If there is more than one user (e.g. add a stream data transfer
protocol), then all users on both ends should agree to allow the connection
to be shut down.

Currently there isn't even a design for such a protocol, much less an
implementation plan.  I can't see doing anything without adding some
methods somewhere however.

(3) Status reporting:  All production systems need status reporting, e.g.
what connections exist, how much data is moving on them etc. for operations
monitoring and performance tuning.  The previous version of the DataComm
code had a method on the ConnectionsManager which returned a list of the
existing connections, and some statistics about their use.  That was a
whole lot better than nothing, and a whole lot less than a general
facility.  More design is needed in this area, but I see at least one more
ConnectionsManager method.