[RRG] Moving towards a new set of Networking APIs

[RJ Atkinson <rja@extremenetworks.com>]

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