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

[Javier Ubillos <[e-mail]>]

On Tue, 2010-12-21 at 15:58 -0500, [e-mail] 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