Re: [nbs] NBS and TCP connection identification

Javier Ubillos <jav@sics.se> Thu, 14 October 2010 16:07 UTC

Return-Path: <jav@sics.se>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E673A698D for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 09:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.841
X-Spam-Level:
X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anHG9wEx003e for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 09:07:19 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 45C903A693D for <nbs@ietf.org>; Thu, 14 Oct 2010 09:07:19 -0700 (PDT)
Received: from [193.10.66.63] (bit.sics.se [193.10.66.63]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 33050400E2; Thu, 14 Oct 2010 18:08:35 +0200 (CEST)
From: Javier Ubillos <jav@sics.se>
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <87E974EA-A815-4844-9DC5-196FDEB72914@free.fr>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com> <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@free.fr> <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com> <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr> <C0F28CE9-B47D-416A-907D-394AC2FAF487@ericsson.com> <0631EE7A-FC0D-4130-AC87-397299CA4594@free.fr> <1287070476.2253.97.camel@bit> <87E974EA-A815-4844-9DC5-196FDEB72914@free.fr>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Z8oTB6ZrABzsnCHCj6uK"
Date: Thu, 14 Oct 2010 18:08:34 +0200
Message-ID: <1287072514.2253.124.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: Christian Vogt <christian.vogt@ericsson.com>, "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] NBS and TCP connection identification
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 16:07:20 -0000

On Thu, 2010-10-14 at 17:40 +0200, Rémi Després wrote:
> Le 14 oct. 2010 à 17:34, Javier Ubillos a écrit :
> 
> > On Thu, 2010-10-14 at 09:12 +0200, Rémi Després wrote:
> >> The semantics of the IP address at the socket API can, and IMHO should, remain unchanged during the connection.
> > 
> > I agree, and the issue of synthesize names is not directly associated to
> > this. Synthesized names can very be hidden from the application if one
> > wants that. If a literal IP is provided, this data structure can very
> > well become the anchor point of the application.
> > However, it would be a little bit awkward, if you open a socket, with
> > address family AF_NAME, and then encode a literal IP into name field.
> > But it wouldn't be a major technical hurdle.
> 
> The idea is rather to keep the address field as is with previous AFs, and leave the name field empty if none is available?
> It is the up to the application to decide whether it accepts connections with blank names.
> 
> Does that make sense?

I think it does.
I would very much like to get rid of sockaddr at all, but there is no
reason to why we wouldn't be able to have a thin layer which accepts a
traditional INET/INET6 type of sockaddr to a AF_NAME socket and then
simply "under the hood" convert it to something more 

From the user perspective, it would be a completely ordinary socket call
with a different address family.

The current API suggestion (which will most likely be heavily modified)
allows the responder to accept from any name, which I think would be
fine for the "blank name" scenario.

Conceptually, it would be as you describe it: legacy-sockaddr (IP) + an
ignored (empty?) name.

// Javier