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

[Denis Martin <[e-mail]>]

On 02/02/11 17:24, Javier Ubillos wrote:
> On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote:
> <snip>
>>> |        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?

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?

> 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?

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?

> Why not check the official IANA list if we hit an unknown service name?
> And of course, also accept "raw" port-numbers.

Agree.

> 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");

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

-- 
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