Subject: Re: [nbs] Scenarios

From: RJ Atkinson <[email-masked]>
Date: Thu, 3 Feb 2011 09:55:19 -0500

On 1st February 2011 at 11:13:29 +0100, Denis Martin wrote:
> A global service registry would be necessary in this case. 
> Or a namespace for user-defined services. So it probably 
> will result in the use of today's port numbers.

Later, on 2nd February 2011 at 18:20:06 +0100, Denis Martin wrote:
> A general service registry (à la DNS - which is already used
> as such if you look at MX records or SIP entries) could be an option. Or
> a standardized end-to-end signalling protocol for protocol and service
> negotiation. That's also something which needs to be solved, but is not
> directly bound to the socket interface as seen by the application, right?

Hmm.  We don't need to re-invent the wheel here.  

Instead, we can simply reuse long-standing on-the-shelf capabilities 
for this.  We definitely do NOT require the complexity created by 
any sort of "signalling protocol for protocol and service negotiation".

Well-defined Service Names have existed since the early 1980s,
at least since 4.2 BSD UNIX, along with well-defined UNIX APIs 
for using them in network-aware applications.

On a typical UNIX system, one might look at the file /etc/services,
which contains mappings between transport-protocol + transport-layer
port number and the sundry 'service name' strings.  Usually the
contents of that file come from the IANA Ports Registry (more below).

One also ought to look at the equally long-standing getservbyname() 
interface, which portable applications already use to resolve from 
a Service Name to the (transport-protocol + transport-layer port) 
combination.

I'll note that getservbyname() is mandatory in the BSD, UNIX 95,
UNIX 98, and POSIX interface specifications.  So this is long
since a portable and standardised interface.  Here is a pointer
to the canonical manual page (online) from The Single UNIX 
Specification:

  <http://pubs.opengroup.org/onlinepubs/7990989775/xns/getservbyname.html>

The existing IANA "Port Numbers" registries (one for System ports,
one for User ports) is normative and should be re-used here.
In the URL below, the "Keyword" field is the normative Service Name,
while the "Decimal" field indicates both transport-layer port
number and the transport-protocol that applies.

  <http://www.iana.org/assignments/port-numbers>

For more on the existing and future Service Name registry, 
and some very slight fine-tuning of existing entries in the 
Port Numbers registry please see this current I-D:

	'Internet Assigned Numbers Authority (IANA) Procedures 
	for the Management of the Service Name and 
	Transport Protocol Port Number Registry'

  	<http://tools.ietf.org/id/draft-ietf-tsvwg-iana-ports-09.txt>

Please let us recycle the existing Service Name schema, 
instead of re-inventing this particular wheel.

If one were implementing a prototype Name-oriented API as
a library, it would seem possible to implement that library
using standard APIs such as getservbyname() -- at least initially,
for proof-of-concept work.

Thanks,

Ran

---

From: Denis Martin <[email-masked]>
Date: Tue, 08 Feb 2011 15:56:48 +0100

On 03/02/11 15:55, RJ Atkinson wrote:
> [...]

Thanks for the pointers. IMO, those service names should definitely be
supported by a new interface by default. Protocol selection then becomes
obsolete, at least for those registered services (or should become
obsolete). Only the flat namespace for service names is maybe not that
good, but maybe irrelevant for the time being.

Specifying the service name to the API does not yet say anything about
how it is resolved into protocol + port number. Initially,
getservbyname() is probably just fine, extended maybe by a DNS SRV
query. Additionally, something like Bonjour could be used underneath.

One design goal of a new socket API should then be that it is able to
handle any transport protocol transparently to the application if
standard services are used.

But what to do with custom connections where no service has been
registered? Even in such cases, I'd like to push down protocol selection
underneath the socket interface.

Denis

- -- 
Dipl.-Inform. Denis Martin

Institut für Telematik,  KIT   Tel +49 721 608 46420
Zirkel 2,  D-76131 Karlsruhe   Fax +49 721 608 46789
http://telematics.tm.kit.edu   Geb. 20.20,  Raum 371