> >  > Yes. Multiplexing the data streams/error stream/index stream
 > >  > over one connection is a good idea.  Kevin Till has done some
 > >  > investigation in this area. I hope he will comment on this.
 > >
 > > The Kerberos 5 implementation in 2.5.0 actually does all this over
 > > one tcp connection right now.
 >
 > Is it possible to make the multiplexing change over one TCP
 > connection work without Kerberos 5?

Anything's possible. :) It should be relatively easy to merge
bsd-security.c and krb5-security.c into tcp-security.c or some such.

However, what I'd really like to see is a tcp port that allowed you
to negotiate session information so that multiple security mechanisms
could go over the same port.  That is, the server can say, "switch to
krb" or "switch to bsd" and then the session would switch to a different
security mechanism, and we could get away from this different port for
different authentication methods.  Clients would obviously reject what
they didn't support, and this could also allow for the server to easily
try different varities with one client.

The original motivation for using a split udp/tcp setup like this
was because workstations of that era couldn't sustain so many tcp
connections, but that's pretty silly in this day and age.  The amanda
server at UMD was initially a Sun IPC if I remember correctly, and was
limited by the capabilities of that box.

 > > There is a minor protocol issue that needs to be corrected (that
 > > causes amandad to timeout at the end, rather than properly end a
 > > session, but it's also there under udp-based connections today, so
 > > less of a big deal).
 >
 > Can you provide more information about this problem? Do you get
 > "connection reset by peer" error from amrecover after the files have
 > been extracted?

no, this is a protocol level issue that you'd probably never notice
unless you were debugging the protocol, particularly a tcp driver where
you multiplex connections.  :-)

If I remember the details, a "FINISH" packet in the protocol doesn't
actually mean FINISH anymore (since the addition of the capabilities
being passed over during the session negotiation the protocol has gotten
more complicated).  I think what needs to happen is a REALLY_FINISHED
state in the state machine that actually exits, which will require
changes to the security api, most likely.  This currently occurs as a
result of a timeout, which means that amandad lingers 30 or so seconds
longer than it needs to.  It obviously needs to be done in a backwards
compatible sort of way.

If doing a tcp implementation of the protocol, you'll end up with
periods where there's no open connections in between messages, which
causes amandad to die down (I think this is right before or after the
capabilities get sent), which given the old protocol would mean it's
time to shut down, but now is not an exit state.

If you look at krb5-security.c, at references to refcnt, you'll see the
hack I put in to work around this and make krb5-security behave like
bsd-security and rsh-security and basically timeout to end.  It would be
better to split this out into it's own routine and part of the protocol,
I think.

This is my initial thought, I haven't dug that deeply into it, either.

-Todd