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

Javier Ubillos <> Wed, 22 December 2010 12:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 326BE3A6B42 for <>; Wed, 22 Dec 2010 04:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LckHnL6IOqOW for <>; Wed, 22 Dec 2010 04:45:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 523503A69DB for <>; Wed, 22 Dec 2010 04:45:35 -0800 (PST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id BD7984011D; Wed, 22 Dec 2010 13:47:32 +0100 (CET)
From: Javier Ubillos <>
In-Reply-To: <>
References: <> <1292401029.4804.30.camel@bit> <> <1292500103.4804.1313.camel@bit> <> <1292949711.4804.8474.camel@bit> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Q1EovbPdTlY4OG0wqWyH"
Date: Wed, 22 Dec 2010 13:47:18 +0100
Message-ID: <1293022038.4804.9860.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Subject: Re: [nbs] (Was: Re: A suggestion for an "on-demand API".)
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: Wed, 22 Dec 2010 12:45:36 -0000

On Tue, 2010-12-21 at 15:58 -0500, wrote:
> On (12/21/10 17:41), Javier Ubillos wrote:
> > Good question!
> > 
> > I'm not sure, can one assume that UDP might not be _able_ to have a
> > two-way communication?
> UDP was just one example of a connectionless protocol that I suggested,
> but I think the more critical thing (which is what I thought was
> discussed in the meeting with Erik, perhaps he can clarify..) is that
> you shouldn't (can't?) try to enforce name exchange/authentication at
> the initial packet exchange, but rather let the application drive
> this..

I completely agree. This is only an issue _if_ either side does ask the
socket for more than just the basics.
Yes, it should be optional.
However, the original question was _if_ it was possible for "B" (the
recipient) to require authentication.

Perhaps a set of scenarios would be good as a basis for discussion.
I'll try to whip a few together, and perhaps we can build from there.
(I'll also try to take time to update the draft that as I promised I
would earlier :)

> > If so, then there would be a clear incompatibility between using UDP and
> > flow-requirements on the receiving host.
> > 
> > However, if that is the case, that we cannot send _any_ replies to the
> > UDP stream, then:
> > a. It becomes impossible to check for bi-lateral support (unless some
> > other channel is used).
> > b. It becomes impossible to exchange names and/or preferences.
> not impossible.. in the udp example, the application that consumes
> the udp packet can trigger (b) at its discretion (the actual mechanics
> of how it will be done are TBD, but hopefully it would not be ULP-specific).

I'm not sure the following assertion stands any more, but:
Initially, in name-based sockets, we decided that all connections should
use connection-oriented semantics (read TCP semantics).

I'm not sure if this still stands. But if it does, then providing an API
where the application may attempt to request more from the socket.
If a two-way connection is possible, those requests might succeed. If
not, then it'll just fail and the application will have to make some
decision about it.

In short.
Should the API-semantics be connection-oriented?
Let's provide an API, including functions that require bi-lateral
support. If the calls fail, let the application make a decision.

// Javier