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

From: Denis Martin <[email-masked]>
Date: Tue, 01 Feb 2011 11:13:29 +0100

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

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 02 Feb 2011 17:24:04 +0100

On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote:
<snip>
> long as connectivity is provided.

Good point!
Any suggestions on how that choice should be made?
Perhaps happy-eyeballs style?

> now, there might be the necessity of changing it again in a couple of

About service/ports:
I'm having a hard time marrying ports and service-names.
I don't know where to turn, in particular if we are not defining the
transport. If we use regular TCP, we need to reach a numeric port at
some point. If we are using some cool futuristic protocol, we might use
strings. But how do we get both?
I think the only way is to distribute a list somehow. Do you have any
suggestions on alternatives?
Why not check the official IANA list if we hit an unknown service name?
And of course, also accept "raw" port-numbers.

CCN:
I think this is a natural evolution, where we go down the path to
address in "higher resolution". Where we either address a serivce on a
specific host, or "just" the service/content. 
It makes sense to "open" an identifier which is some content and e.g.
get a file descriptor to it.

e.g. fd = open("/mystuff.org/things/somefile.txt/_v3/_s1");

// Javier

---

From: Denis Martin <[email-masked]>
Date: Wed, 02 Feb 2011 18:20:06 +0100

> Perhaps happy-eyeballs style?

Could be an option, though I wasn't thinking about how to actually
select the "right" transport protocol. These might be two different
problems:

 1) Specifying the transport requirements, eg.:
      stream-based, datagram-based, unreliable, reliable,
      with flow-control, without flow-control,
      authenticated, encrypted, etc.
    The application could select any combination, eg.
    "datagram-based with flow-control but not necessarily with ARQ".
    This could even be augmented with QoS requirements such as minimum
    guaranteed bandwidth.

 2) Selection of an actual (combination) of protocols.
    The hardest part ;) In case there is only UDP and TCP, it could be
    hard-coded, of course. If there is a huge number of protocols to
    choose from, happy-eyeballs probably won't scale.

With a new socket interface, maybe 1) can be considered. 2) adds too
much complexity - but it might also not be necessary to solve it right
now, is it?

> suggestions on alternatives?

Not really. 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?

> And of course, also accept "raw" port-numbers.

Agree.

> e.g. fd = open("/mystuff.org/things/somefile.txt/_v3/_s1");

So, you mean that such application interfaces would be on a higher level
anyway?

And if we introduced namespaces? Eg.

  DESTINATION_NAME( fd, "ccn:/mystuff.org/things/somefile.txt" );

Regards,
Denis