[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Moving towards a new set of Networking APIs
- To: IRTF Routing RG <rrg@psg.com>
- Subject: Re: [RRG] Moving towards a new set of Networking APIs
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Mon, 18 Aug 2008 09:32:02 +1200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=clIPWHKOiKf0w8e6wLtXRV99Pwqc2Fqc8TPYZ4zuDSON6p7F9gTkqNO5mqjHgAsjNH 4hOfcGknyYAr2Stdchp3y5CdJIF9ZBbRJjF8bzQxGRRuBEt2fiyrdT6Cw87QW78YZWjH +nwt6Yr0BgrnHBuekI/FHe+BkjVpUAmzsYecA=
- In-reply-to: <EBE953FE-AAC8-434B-A865-B70C2BE8F066@extremenetworks.com>
- Organization: University of Auckland
- References: <EBE953FE-AAC8-434B-A865-B70C2BE8F066@extremenetworks.com>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
Front-posting since this is a very slight change of tack.
I agree with Ran, and with the points made by Christian
undre the "On identifiers..." thread. But I think we should
think of this as something slightly more proactive than an
API; it's almost what is sometimes called a convergence
sublayer (and in Java, it's a run-time system). In any case,
with the correct abstraction, it could free up the discussion
of the routing layer from the current requirement to deliver
handles that look like IP addresses to the upper layers.
So I think it should be pursued but probably not on this
list.
Brian
On 2008-08-15 00:59, RJ Atkinson wrote:
> Folks,
>
> For some long while it has seemed to me that the C/C++ programming
> community needs a widely available, openly specified, abstracted
> networking API. I've been advocating this for years now in
> various talks various places.
>
> Such an API ought to be a functional replacement for the BSD
> Sockets API. Historically, BSD Sockets shipped before the DNS
> existed, so that API was forced to be much less abstract than
> it ought to have been. A new API would replace IP addresses
> with FQDNs, transport protocol and port with Service Names,
> and so forth.
>
> Java has long had just such an API. Nearly all Java programmers
> use that abstracted API in preference to the lower-level
> networking APIs also available in some Java implementations.
> This has meant that nearly all Java programs are oblivious
> to the differences between IPv4 and IPv6 (and a range of other
> low-level details irrelevant to nearly all applications).
>
> If such an API were designed properly, it would be entirely
> oblivious to (and agnostic towards) IPv4, IPv6, and any of
> the proposals here that I am familiar with. So this notion
> of adding such an openly specified API is entirely neutral
> with respect to any specific proposal forward.
>
> I am told that Stuart Cheshire advocated adding such an
> openly specified API during the IAB Plenary in Dublin.
> If that report is accurate, one could do worse than to talk
> with him about Apple's experience with their abstracted API.
>
> One imagines this could be implemented either as an OS interface
> or as a library, whichever way an implementer chose to use.
>
> So I'm fully in agreement with tli. We ought to move to a new
> networking API for C/C++ programs. Once such an abstract API is
> specified, then the existing Sockets API ought to be marked as
> deprecated, although obviously implementers could (and very likely
> would) continue to support the BSD Sockets API as well. [1]
>
> I'm not familiar with Apple's C/C++ abstracted networking API,
> but that might be one candidate for putting together an openly
> specified networking API in an RFC.
>
> I'm not sure whether this topic is in/out of charter for the
> Routing RG. The IAB's Internet Architecture list might be
> an alternative venue for this thread if it doesn't belong here.
>
> Yours,
>
> Ran Atkinson
> rja@extremenetworks.com
>
>
> PS: ILNP can work fine with the BSD Sockets API, so I really
> don't think that any "legacy" applications need to change to
> work properly over ILNP. I do think that most applications
> would benefit from using a more abstracted API, whether one
> is using IPv4, IPv6, both, or something else.
>
> [1] IETF documents, even standards-track documents, aren't laws.
> On a good day they are just strong recommendations. No implementer
> is forced to follow any RFC, although many implementers choose to
> follow most RFCs most of the time -- out of enlightened self-interest.
>
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg