directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject [ApacheDS] Configuration of protocols
Date Tue, 09 Oct 2007 19:10:36 GMT
Hi all,

Again I wanted to summarize some very important IRC conversations I just had
with David Jencks. As you
know we're still in the phase (I) where we're removing configuration beans
to directly configure the protocol
components themselves.  We are however running into interesting problems
which require some decisions
that are not necessarily write or wrong but a matter of a trade off.

I will use the NTP protocol as the example for this discussion however the
problem applies to all
protocols which run on both TCP and UDP.

NtpServer represents a protocol service that responds to NTP protocol
requests.  Each NtpServer has its
own port and uses either UDP or TCP but not both since the NtpServer is a
single endpoint.  Presently
ApacheDS will launch two of these servers: one for UDP and one for TCP on
the same port.  There is a
single NtpConfiguration bean which is used to configure both NtpServers.

Our present dilemma is whether or not to expose the configuration of two
NtpServer components in the
server.xml that are wired directly by Spring or to just expose a single
NtpConfiguration object that is configured
and used to launch these two servers.

Dave makes a good point that if we wire the NtpConfiguration instead of two
NtpServers then the configuration
is simpler and more succinct.  Although I don't see why someone would run
the NTP provider for UDP on a different
port than the one for TCP the users will still be required to make the ports
match since the same configuration
bean is used for both servers.  Also both UDP and TCP will be required to
run together where the user does not
have a choice.

In most cases if NTP or any other UDP/TCP capable IP protocol is to run,
both servers often run on the same port
if not being absolutely required to do so.  I think most clients presume
that the UDP or TCP service automatically
runs on the same port by default.  It might be more common for users to
enable only TCP or UDP but still this will
not be that common.

IMO I agree with David's points however I have the following thoughts:

(1) The additional configuration of two NtpServers independently is not much
at all especially when smart defaults
     are used in which case it's just one extra tag without properties.
(2) We give users the flexibility if they want to run just a UDP server or
just a TCP server instead of requiring
(3) We give users the option of running both UDP and TCP on different ports
if they desire for whatever odd
(4) We stay true to our goal with the removal of configuration beans in
preference for wiring the components
     directly themselves.
(5) There's full transparency that two separate components for handling a
protocol are being used with different
     transmission protocols.
(6) We're not delegating life-cycle management of the protocol to a
composite object that must start and stop
     the pair of protocol servers together.  I find this troubling because
it may create issues for us down the line
     with other container frameworks where we just want to ask for a
protocol service with specific properties and
     get a handle on it.

With these considerations I feel we aught to stick to the original plan and
require the configuration of two servers
if that's what the user wants.  If one server is desired then that's fine
too. We have more flixibility with the per
server configuration than grouping both together within an NtpConfiguration
object which manages both their
life-cycles in unison.

I think we're going to continue this conversation some more however if
anyone else has an opinion or thoughts on
the matter that we're not thinking about please do comment.


View raw message