Standards Update, IEEE 1003.12: Inter-Process Communication

[jsh at usenix.org]

From: <jsh at usenix.org>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.12: Inter-Process Communication Update

Steve Head <smh at hpda.HP.COM> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

OVERVIEW

P1003.12 is the IEEE POSIX Network Inter-Process Communication (IPC)
committee (formerly P1003.8/2).  The committee is currently working on
two potential interfaces, a detailed interface (DNI) and a simple
interface (SNI).

At this meeting, the group arrived at a high-level description of a
name-to-address translation facility, and decided the question of XTI
versus sockets versus ``something else'' in favor of ``something
else.'' The group began discussing connection setup, and continued
discussing SNI.  Finally, the POSIX steering committee (SEC) changed
the group's name to P1003.12.

There were about twelve attendees.

DETAIL

  1.  SNI reviewed

      A UC Berkeley SNI proposal is gradually taking shape.  The
      proposal describes both objects and functions that act on them.
      Some of these objects and functions have analogues in the socket
      world, while most of the others are composites.

      The most recent additions are sni_save() and sni_restore().
      sni_save() takes a snapshot of an endpoint and saves it in a
      string, suitable for passing to a child process through an
      argument or the environment.  sni_restore() restores the library
      state of an endpoint from that string.

__________

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

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


                                - 2 -

      The committee has had two goals for SNI.  For naive users, it
      should simplify the networking interface.  For vendors, it
      should allow implementation of interfaces over complex protocol
      stacks (such as ACSE--or something above ACSE--over OSI-7).

      One issue that came up was what the application programmer would
      target for.  If DNI and SNI retain distinct differences, SNI-
      based applications risk outgrowing SNI's capabilities.  One
      alternative would be to combine DNI and (the current) SNI to
      allow seamless expansion into protocol-specific hooks, without
      recoding of applications.

      Next meeting, UNISYS is expected to present an alternative SNI
      proposal.

  2.  Naming

      The group discussed name-to-address translation for DNI in
      detail, specified an interface at a high level, and intends to
      pass it to the naming group.  The specification is:

           given:
              hostname/``entity''
              service/``facility''
              type/``context''
              protocol or protocol family

           return:
              set of {
                 address
                 any input parameters that were
                    completely or partially wild-carded
              }

      SNI might need something similar, but without the
      protocol/protocol-family/address-family parameter.  (SNI is
      protocol-independent.)

      The interface lets applications defer deciding which protocol-
      or address-family to use until after the query.  It will also
      permit load-balancing, a technique to optimize data-transfer
      performance over slower interfaces (such as multiple, serial,
      point-to-point links).

      The group deferred discussing both performance (time and
      memory), and which input parameters could be wild-carded.

  3.  XTI versus sockets

      The XTI-versus-sockets issue came up briefly while discussing
      passive-endpoint functions.  The group resolved to incorporate

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


                                - 3 -

      the best of XTI, sockets, and possibly other extensions, into
      DNI.

      The group decided not to require full XTI-type functionality,
      and accepts the risk that porting XTI-based applications to DNI
      may require source-code changes.  A potential advantage of this
      decision is that the standard can leave out the mistakes of XTI
      and sockets.  Also, vendors remain free to supply the older
      interfaces on the side.

      A UCB representative will prepare a new DNI proposal between now
      and the next meeting.

  4.  P1003.8/2 -> P1003.12

      The SEC gave network IPC its own separate number: P1003.12.
      This change will be formally approved at the IEEE standards
      board meeting, a couple of months from now.

  5.  Potential overlaps with P1003.4

      For several meetings, both P1003.12 and P1003.4 have been aware
      of their potentially overlapping coverage of process-to-process
      communication on a single, local system.  Since there should be
      only one interface for common functions, and any characteristics
      peculiar to local IPC can be supported by protocol-specific
      options under DNI, P1003.12's position is that it should handle
      all IPC.  The group has asked the networking steering committee
      chair, Tim Baker, to relay this position to the SEC.

FUTURE MEETINGS AND SIGNIFICANT DATES:

The Spring 1990 meeting will address SNI/DNI connection setup/tear-
down and SNI/DNI data transfer.

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


Volume-Number: Volume 19, Number 8