Re: [nbs] Scenarios

RJ Atkinson <> Thu, 03 February 2011 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C38663A699E for <>; Thu, 3 Feb 2011 06:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dJqDLjIx9yuP for <>; Thu, 3 Feb 2011 06:52:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 58D7C3A692F for <>; Thu, 3 Feb 2011 06:51:59 -0800 (PST)
Received: by vws7 with SMTP id 7so742084vws.31 for <>; Thu, 03 Feb 2011 06:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Pk/XowpQ4y4MEL4HseGsMeOWG08fDlchDgB/chDMvho=; b=xAExTmxf4rpqg6Z1nWJOX9ylkJEZ5oiZVlEx7O3Qdv0iDyxtdK7Lf+D777FYc+QHiy h+iM+r363JM84Ny+irWnVNMKKRAsTUUXmACw9aUN9szXqeUtoVrWRObMGCkWj9J09Vhr Irx99VuNIXtTJLDajIgbnBqC326AUQlz/y8QU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=W4wTdqTcjOKrCnuSC2m2U1zdpbuxKeKkjha6DPIgk27WXZVTVtUNGZDW+oQgVOvqnR oqPMxGYUnCENB9A7Ry0IMNZF8UOD31B5maFERbA2QuYlcMmYK+iqz6orBkrhHa8ZCjag krYewIxPCEgjf3AjP9vHRXjPmCMmYifT2270w=
Received: by with SMTP id v12mr2677299vcn.166.1296744921623; Thu, 03 Feb 2011 06:55:21 -0800 (PST)
Received: from ([]) by with ESMTPS id bq5sm344105vcb.32.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 06:55:20 -0800 (PST)
From: RJ Atkinson <>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 3 Feb 2011 09:55:19 -0500
Message-Id: <>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: Re: [nbs] Scenarios
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Feb 2011 14:52:02 -0000

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) 

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 


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.


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'


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.