Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.20/text0032.txt

Internet Message Format | 1990-08-02 | 5.7 KB

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.12: PII

Andy Nicholson <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Introduction

For starters, we've had some significant turnover.  [Editor:
Including, you'll note, Steve Head, our former, fine dot 12 snitch.
Thanks for diving in, Andy.] We are now down to five participants who
were present a year ago, are on our third AT&T representative, and an
HP representative has permanently left the working group.  Despite all
this, the group is beginning to make rapid advances on both the
Simplified (SNI) and Detailed (DNI) network interfaces.  This
meeting's progress is sketched below.

Overview of the Work We're Doing

The dot 12 committee is working on three projects: Simplified Network
interface (SNI), Detailed Network Interface (DNI), and Data
Representation Interface (DRI).  Work on DRI is being delayed until
SNI and DNI are well along.  DNI is a protocol-independent interface
to network services that allows access to protocol-dependent features
in a protocol-independent manner.  DNI is meant to provide a complete
interface to everything you might expect to be able to do with
networking services.  DNI is comparable to Berkeley Sockets or AT&T's
TLI, and we plan that anything that can be accomplished with those
interfaces will be subsumed by DNI.

The idea behind SNI is that many applications will not require
``detailed'' access to networking services.  SNI gives a ``stdio''
type of interface for networking that combines common groupings of
procedures, eliminates access protocol-dependent features, and is just
plain easier to use.  Applications that use SNI aren't necessarily
simple, they just don't need DNI's detailed access to networking
services.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

May 1990 Standards Update                            IEEE 1003.12: PII

                - 2 -

Simple Network Interface

We started the week discussing the SNI interface.  Norm Smith, from
Unisys, had intended to bring an alternate SNI proposal to this
meeting, but his group at Unisys decided to work with the current one.
Irene Hu, from DEC, says she may yet offer an alternate proposal.

I presented a paper, prepared from previous minutes, which gathered up
some deferred issues relating to SNI and we resolved some of them.
For example, we added some explicit goals for SNI that everyone seemed
to have accepted implicitly, but were never made official.

We also considered creating a formal definition of SNI functionality,
to help us determine whether any particular function should be
included, but decided it would be more efficient to keep deliberating
each case individually.  We'll record the rationale for each as part
of the standard document to help us avoid and respond to ballot
objections.

   + SNI functionality
     A paper by Tim Kirby (who works with me at Cray Research)
     prompted the group to redefine a function call.  Sni_recv(), was
     defined to discard excess data in a datagram when the buffer
     offered by an application isn't large enough.  The new version of
     Sni_recv(), allows an application either to discard excess data
     or to perform multiple sni_recv() calls to read it all.  It also
     allows applications to discard datagrams without reading them at
     all.  Here, I think the group has noticeably extended the power
     of the interface without sacrificing efficiency.

   + Kernel objects
     Because SNI endpoints may not be kernel objects, we need to
     define semantics and interfaces that will allow SNI endpoints to
     survive exec().  Unfortunately, we disagree on the semantics of
     the endpoint-preservation procedures.  Should multiple copies of
     the same endpoint exist in different processes' address spaces,
     as happens with fork() and exec()?  Implementing the protocol
     stack in a user library creates multiple copies of state
     information for the same endpoint, and it may be impossible to
     keep them synchronized.

     Some of us (Keith Sklower, from Berkeley, the author of the SNI
     document, and I) want to restrict endpoint semantics so that only
     one process may have a copy of an SNI endpoint; others (Irene and
     Norm) disagree and wish to allow multiple copies of SNI endpoints
     where the programmer wishes.

May 1990 Standards Update                            IEEE 1003.12: PII

                - 3 -

Detailed Network Interface

We discussed DNI procedures in detail for the first time and found
tentative agreement on most of the many issues raised.  Mike Karels,
from Berkeley's Computer Science Research Group, presented an outline
of required functionality.  After discussing it, we agreed to make DNI
endpoints POSIX file descriptors (as returned by open()) until we see
a compelling counter-argument.  I'll challenge you to offer one.

On Wednesday, Irene gave an overview of XTI.  During the presentation,
Torez Hiley, our new attendee from ATT, told us that XTI is being
revised: input from vendors using the Berkeley socket interface is
prompting the addition of many features.  Torez will report on the
upcoming revision at the July meeting.  Where sockets and XTI/TLI
differ, the best solution is not clear.  Moreover, some features are
absent or inadequately supported in both interfaces.  Here, we have a
lot of work to do and are just getting started.  We're eager to hear
whether the new XTI solves any of our problems.

May 1990 Standards Update                            IEEE 1003.12: PII


Volume-Number: Volume 20, Number 32