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

[Denis Martin <[e-mail]>]

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 [phone]
Zirkel 2,  D-76131 Karlsruhe   Fax [phone]
http://telematics.tm.kit.edu   Geb. 20.20,  Raum 371