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

[Javier Ubillos <[e-mail]>]

On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote:
<snip>
> > +----------------------------------------------------------------------+
> > | * 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.

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

> > [...]
> > |        // 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 ;)

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