Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API".

Denis Martin <martin@kit.edu> Tue, 01 February 2011 10:10 UTC

Return-Path: <martin@kit.edu>
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 D42B53A6C40 for <nbs@core3.amsl.com>; Tue, 1 Feb 2011 02:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 e+XtX0Ie6IEx for <nbs@core3.amsl.com>; Tue, 1 Feb 2011 02:10:21 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 1B1803A6C3C for <nbs@ietf.org>; Tue, 1 Feb 2011 02:10:19 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PkDEn-0008R1-IX; Tue, 01 Feb 2011 11:13:35 +0100
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PkDEn-0000Nd-D7; Tue, 01 Feb 2011 11:13:29 +0100
Received: from [IPv6:2001:638:204:6:21f:16ff:fe28:b05c] (unknown [IPv6:2001:638:204:6:21f:16ff:fe28:b05c]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTPSA id 532A62FC024; Tue, 1 Feb 2011 11:13:29 +0100 (CET)
Message-ID: <4D47DCC9.8030601@kit.edu>
Date: Tue, 01 Feb 2011 11:13:29 +0100
From: Denis Martin <martin@kit.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
References: <1294943649.3346.104.camel@bit>
In-Reply-To: <1294943649.3346.104.camel@bit>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1296555215.621364000
Cc: Name-based Sockets List nbs <nbs@ietf.org>
Subject: Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API".
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: Tue, 01 Feb 2011 10:10:22 -0000

Hi,

On 13/01/11 19:34, Javier Ubillos wrote:
> I've attempted to define some scenarios (two so far) test some API ideas
> against.
> 
> [...]
> 
> We're still trying to define an abstract API, please overlook if I slip
> into C'ish syntax :)

Looks pretty straight forward, i.e. one is still able to match it to
today's socket API using bind/connect etc.

> [...]
> +----------------------------------------------------------------------+
> | * One to one                                                         |
> | * Bi-directional (e.g. TCP)                                          |
> | * Bi-lateral support (Name-based sockets on both ends)               |
> | * Requiring authentication of name->locator binding                  |
> +----------------------------------------------------------------------+
> |
> |    -- Initiator:
> |        CONNECTION *my_conn = ALLOC_SOCKET();
> |
> |        /* LOCAL_NAME() binds a local name. Unless some name-type is
> |           chosen it defaults to FQDN */
> |        LOCAL_NAME( my_conn, "initiator.name" ); 
> |
> |        DESTINATION_NAME( my_conn, "recipient.name" ); 
> |        TRANSPORT( my_conn, TCP );
> |        SERVICE( my_conn, HTTP ); // equivalent to htons(80)

Why mentioning the transport protocol explicitly? Isn't that a step
backwards compared to, e.g., SOCK_STREAM where I just state that I want
a reliable, stream-based transport? In the end, it should not matter to
the application if it is TCP or SCTP or any future transport protocol as
long as connectivity is provided.

> [...]
> |        // equivalent to htons(12333), my imaginary service :)
> |        SERVICE( my_conn, MY_VIDEO ); 

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. In this case, the interface should allow
more than 65k for future extensibility.

A general thought about a new socket interface: We have to modify
applications anyway, so we could even more augment that interface. We
not only should get rid of addresses, but also of a concrete protocol
selection done by the application. Regarding the scenarios, it could
even be worth looking at new paradigms such as CCN. Admittedly, it might
be a bit more distant in the future, but if we change that interface
now, there might be the necessity of changing it again in a couple of
years ;)

Regards,
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