Philip Guenther | 6 Nov 23:15
Favicon

Re: Service vs. Port vs. SRV (following Eliot's presentation)

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


Gmane