		Bolt "connections" start to finish

Bolt servers and handlers (clients) talk to a Bolt driver which provides a
reliable message system (couched in connection-oriented terms).  The
"connection"-orientation is necessary owing to distributed state information
which must be maintained (i.e. locks and psuedo-locks).  It is easy to
implement a Bolt driver even on top of an unreliable datagram service.

A "connection" is started only by a handler calling the driver function
SDNInitNode().  When SDNInitNode() is called, the driver sends an
ACTION_NETWORK_START packet to the server.  The server does not reply to
that packet.  The handler then sends (via SDNSend()) an ACTION_NETWORK_SNAME
packet to the server.  The server does not reply this packet.  From this
point forward, the handler sends packets and the server replies them normally
until there is a problem with the "connection."  When a "connection" is
broken, SDNSend() will return SDN_ERR (which is how the handler knows about
broken "connections") and SDNAccept() will return an ACTION_NETWORK_END
packet.

Looking at datagrams actually sent by a UDP driver makes things somewhat
more complex, but the jist of it is that for every packet sent or replied,
there is also an acknowledgement.

Here is a detailed description of the special Bolt packets:


ACTION_NETWORK_START
Phoney packet from the server's driver to the server (possibly also from the
handler's driver to the handler) to let it know that a session has been
initialized.

ACTION_NETWORK_END
Phoney packet from the server's driver to the server (possibly also from the
handler's driver to the handler but an SDN_ERR on a send does some of this) to
let it know that a session has been terminated.  The driver *must* always
initialize Arg2 to NULL.  (ACTION_NETWORK_TERM is an obsolete synonym for
ACTION_NETWORK_END.)

ACTION_NETWORK_SNAME
Packet sent by handler to tell server what name the handler calls the server
by.  ACTION_NETWORK_ESTABLISH must be immediately followed by
ACTION_NETWORK_SNAME (this must be done by the handler, but is not enforced).

ACTION_NIL
Packet sent by handler to server to determine whether the connection is still
good.  Server should immediately reply with an ACTION_NOT_KNOWN.

In practice, if a packet is unreplied after 10 seconds, ACTION_NIL is sent to
the server.  If that packet is unreplied after 10 seconds, a requester for
ABORT/RETRY.  10 seconds is extreme, this could probably be reduced to 1
second and used to trigger a "net: hd light."



	NOT YET IMPLEMENTED:

ACTION_NETWORK_LOGIN
If a handler desires other than default access to a server (or wants to change
back to the default from whatever), it sends this packet.  The packet's only
argument is a string naming the access list it desires.  If the access list is
not password protected, access will be granted.  If the access list is
password protected, the server will return a challenge to be used by the
handler to encrypt a password (SEE ACTION_NETWORK_PASSWD) and continue to use
the current access list until receipt of an ACTION_NETWORK_PASSWD containing a
valid password.

ACTION_NETWORK_PASSWD
If the result of an ACTION_NETWORK_LOGIN is a challenge, the handler must
either revert to default access or use the challenge to encrypt a password to
be sent to the server as the only argument of this packet.



	OBSOLETE, PRIVATE TO INET DRIVER PACKETS:

ACTION_NETWORK_ESTABLISH
Phoney packet to start a new session.  Servers and handlers never send this
packet.  Handler's drivers send it to a server's driver as the first packet
sent to the server.

ACTION_NETWORK_DISOLVE
Pseudo-packet sent only from the server's driver to the handler's driver in
response to a packet other than ACTION_NETWORK_ESTABLISH received outside of
an established session.  The packet really isn't even sent by the server's
driver -- the server's driver just changes the type of the
non-ACTION_NETWORK_ESTABLISH packet to ACTION_NETWORK_DISOLVE and then returns
it.  Drivers must check return packet types for ACTION_NETWORK_DISOLVE.
