On Wed, 2004-04-21 at 13:55, John Peacock wrote:
> > The ultimate output of a SRV resolution is the same as the output of an
> > A resolution: a list of IP addresses. (In the SRV case the order of
> > those addresses is well-defined, while in the A case it is not, but from
> > the application's point of view that doesn't matter.) It would be no
> > worse to try only the first address we see from the SRV lookup than it
> > is to try only the first address we see from the A lookup.
> With the proviso that SRV queries return multiple values (Priority, Weight,
> Port, and Target) in each answer, whereas A queries return only a list of
> addresses. A quick reading of RFC2782 seems to suggest that the client should
> perform the sorting by Priority/Weight (the server doesn't apparently have to
> return the records in any given order). This does complicate the client
> interface for (I would argue) very little benefit.
I said "the ultimate output of a SRV resolution." After you parse the
SRV records, you sort them according to priorities and randomize them
within identical priorities according to weights. Then you resolve the
resulting A records (or you do that lazily, but that might mean more
complexity from the application's point of view, and glue records mean
that you'll generally do just as well to resolve all the A records right
away) and you have a list of IP addresses, just like I said.
Just because the client has to take care of the work doesn't mean the
application has to. We certainly wouldn't want to have our own code to
parse the SRV record format, so there's no reason to believe we would
want to have our own code to worry about priorities and weights either.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 21 20:00:54 2004