6 Nov 23:15
Re: Service vs. Port vs. SRV (following Eliot's presentation)
Philip Guenther <guenther+ietf <at> sendmail.com>
2006-11-06 22:15:26 GMT
2006-11-06 22:15:26 GMT
On Mon, 6 Nov 2006, Ned Freed wrote:
>> This is in response to Eliot's presentation this morning, in the
>> AppsArea and it is merely intended to solicit comment:
>
>> I have always understood the construct of Well-Known Ports as being a
>> means of standardizing an efficient rendezvous mechanism, for clients
>> to find servers. -- without quibbling about the terminology that might
>> better cover use in peer-to-peer scenarios.
>
> I think you're talking past each other here. You're referring to our
> practice of saying things like "SMTP servers listen on port 25 by
> default" or "HTTP servers normally listen on port 80". Eliot is talking
> about ports with numeric values less than 1024 being handled distinctly
> from those above 1024.
Elliot was talking about both in his presentation. The first bit was this
whole thing involving ports 0 to 1023 (which the registry calls "Well
Known Ports"). The second bit was the recommendation that new protocols
should consider using SRV instead of having a particular port number.
> I am complete agree with Eliot that the "below 1024 are special"
> notion's time has long since past. It made sense back in the mainframe
> era, but it was over the minute we started putting machines directly
> under the control of random users.
I agree.
> I certainly don't want to abandon the practice of defining ports
> associated with specific services and I don't think Eliot is saying that
> either.
He didn't suggest that, as it's impossible for protocols below DNS or that
cannot afford to depend on DNS.
> I wasn't entirely clear on what Eliot was trying to say about SRV records.
> Perhaps someone could recap that here?
SRV records good:
- provides fallback/load-balance location mechanism
- avoids tight port # binding
- namespace of assignments is strings (that can be a DNS label) instead
of 16bit numbers
SRV records bad:
- add dependency on DNS
- add latency on first connect, maybe later
- complexity
Philip Guenther
RSS Feed