std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (10/21/89)
[ I can't seem to find a copy of this in my archives, which probably
means that I neglected to post it with the others in August.
If not, and you've already seen it, please ignore this one. -mod ]
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.8 Networking Update
Steve Head (smh@hpda.hp.com) reports on the April 1989 meeting:
OVERVIEW
P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX. The committee is
divided into several subcommittees, including transparent file access,
remote procedure call, network IPC, and MAP. There were about 30
attendees at P1003.8 altogether. This is a report on the network IPC
subcommittee, which is creating both a "sophisticated" interface and a
"naive" interface for interprocess communications. Because it is not
yet known whether the group's work will all go into a single standard,
the word "standard" should probably be "standard(s)".
At the April meeting, the group redefined the goals of the two
interfaces, and adopted a top-down methodology to avoid factional
deadlock. It went on to set initial milestones for the end-product
standards, complete a first pass of functionality and objects of
interest, and initiate discussion and cooperation with other
organizations and committees working in related areas.
DETAIL
At this meeting, the main topics of discussion were:
1. Goals
2. Methodology
3. Milestones
4. Functionality and Objects
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 2 - IEEE 1003.8 Networking
5. Relationships to Other Organizations, Standards, and Evolving
Standards
6. Naming
7. Async Events
8. XTI versus sockets
9. e-mail distribution list
10. Future Agenda
Note: in this report, "XTI" refers to X/Open's Transport Interface, a
networking interface definition for UN*X based primarily on AT&T's TLI
(Transport Library Interface). "CNI" refers to the Chemical Abstracts
Company Network Interface, an independently developed transport level
interface which is designed run not only on UN*X but other operating
systems as well. "Sockets" refers to the popular, 4.3-BSD-based
networking interface.
1. Goals
Several new goals were added over the week to the list of existing
goals that had been developed for the sophisticated interface at the
previous meetings.
o+ timeliness of getting the standard to the industry
o+ usability -- the standard must be fully usable, without dangling
dependencies
o+ quality -- not repeat the "mistakes" of predecessors (XTI,
sockets, and CNI)
o+ compatibility -- preserve user investment in existing interfaces
(XTI, sockets, etc.)
In review, the two interfaces share the following goals:
o+ ability to provide client-server support
o+ virtual-circuit- or datagram-level service
o+ accommodate POSIX to non-POSIX datacomm
o+ support for multiple protocol suites and multiple networks in 1
machine
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 3 - IEEE 1003.8 Networking
o+ few "system calls" per logical operation, though the naive
interface will probably be less efficient than the sophisticated
interface
In addition, the sophisticated interface wants:
o+ protocol-independent access to protocol-specific features
o+ sophisticated (POSIX real-time) event management of protocol
interface
o+ provision for support of [existing] protocol-specific features
o+ "clean" feature availability
o+ integration with POSIX I/O routines (read()/write())
o+ easy extensibility to future protocols
o+ access to network management functions, such as statistics
o+ access to network debugging functions, such as tracing
In contrast, the naive interface will have:
o+ no access to protocol specific features
o+ no provision for sophisticated event management
o+ potential support for known, existing protocols, but will not
support user access to all protocol features
o+ less coupling to the POSIX I/O routines
Many of the new goals are relevant to both and may be formally adopted
as time permits, but the committee did not discuss how many of the new
goals were also goals for the naive interface. Basically, there wasn't
time.
This is an issue in its own right. Part of the reason for the lack of
time is the need to divide attention between the two interfaces; this
halves the time one would otherwise have for any given topic. The
committee hopes to overcome this problem in time by merging the two
interfaces into one or by dividing the committee into subgroups to
work on the two interfaces in parallel. It is too early to decide
which (if either) tack to take yet; neither interface is well-enough
defined.
2. Methodology
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 4 - IEEE 1003.8 Networking
Someone suggested a top-down approach, for these advantages:
o+ form and order in the production of the standard
o+ avoidance of deadlocks, such as sockets versus XTI
o+ cleaner final design
Favorably disposed to the suggestion, the group informally adopted it.
3. Milestones
Several official milestones were set.
starting the draft 1989
o+ finishing the first draft 1990
o+ mock ballot 1991
o+ full ballot 1992
Earlier dates are possible if more working members can be found to
share the expected workload. (Readers, wake up: this is your chance
to pitch in and help the committee make progress!)
4. Functionality and Objects
The group spent much time presenting and discussing the functionality
and objects for the "naive" and "sophisticated" standards. The lists
generated were rough supersets of the functionality and objects in
XTI, sockets, CNI, and UNI, and are available from Steve Head
(smh@hpda.hp.com) on request. (This has progressed to a skeleton
outline Draft, as of the San Jose meeting!)
The discussions laid a framework for the next tasks before the group:
to separate out specific "sophisticated" from "naive" features, and to
group the functionality and objects in a quasi-language-independent
way. Only after this is done will the group generate C bindings to
the standard.
5. Relationships to Other Organizations
The Chair of P1003.8 made contact with the ISO committees on ISO
protocols. Apparently the rumor that ISO would object to a
transport-level interface on the basis that it is not entering the top
of the ISO stack is unfounded; the chair found no objections among
those he contacted on this issue.
Several parallel efforts at a transport standard were discussed:
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 5 - IEEE 1003.8 Networking
o+ OSF
o+ UI
o+ X/Open XNET's XTI
o+ P1003.4 (real-time) Messages
Steve Head, acting chair of the OSF SIG on Base Communication Services
/ Transport Interfaces Subgroup, sketched OSF status in this area.
Petr Janocek, X/Open XNET chair, described XNET status, and Kathy
Bohrer, leader of the P1003.4 messages working group, gave an overview
of its effort.
Holes in each of these efforts currently prevent the adoption of any
of them as a standard by the group. 1003.8/IPC will address major
networking-specific interface issues left unresolved by other groups,
and will continue to work work on an interprocess communication
standard that is usable, protocol-independent, and well-integrated
with the rest of POSIX.
P1003.4 (real-time) messages were especially controversial. It came
as a surprise to many group members (and, frankly, many other POSIX
members) that 1003.4's charter includes "system extensions". There
seems to be a general feeling that "real-time" is a misleading name,
and 1003.4 may not receive adequate coverage in the balloting
procedure. The group's concern is that this could be a real problem
for extensions that are intended to solve problems involving multiple
nodes in a network. For example, though the message interface is
primarily for real time and generic, messaging-application needs on a
single node, it can also include operation over networks that share
file systems, and enable rendezvousing using the 1003.1 file system
(assuming messages are supported by POSIX Transparent File Access --
which is not at all clear at this time). A file-system name space is
generally inadequate for general network rendezvous purposes,
requiring, as it does, mounts for every possible node, special files
or clone files for every possible endpoint, potentially performance-
and reliability-impacting extensions to the internal file name
resolution routine (e.g., namei() or its equivalent), the adoption of
new, complex protocols to handle requests, and other considerations.
Just as you're unlikely to go into a shoe store if you're looking for
a book, you're unlikely to look in the real-time draft for generic
extensions. Some parts may not have received enough exposure to ensure
functionality and consistency for either typical or special user
application needs. (In any case, the situation will be helped
somewhat by the decision, made in San Jose, that P1003.4 real-time
functions will be balloted as additions to the 1003.1 standard rather
than as a separate standard.)
The committee also worried that several aspects of the 1003.4
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 6 - IEEE 1003.8 Networking
messaging interface seemed redundant or inefficient.
The 1003.4 messages subgroup scheduled a joint meeting with 1003.8 in
July to discuss these problems. In addition, all actively attending
1003.8 working group members were to be placed on the balloting list
for the May, real-time mock ballot.
6. Naming
P1003.8 is forming a "naming" subgroup. The first full meeting of
this group will be at the July meeting.
This group isn't likely to solve the name resolution problem from
scratch (lack of time, not inspiration) so the group may continue to
address it until the naming subcommittee takes over. The group may
decide to meet with them jointly and include them on its balloting
rather than give them a problem they can't ramp up to in time for a
solution. Incidentally there are many name resolution issues, not
just a single problem or single interface likely to solve all
problems.
7. Asynchronous Events
John Barr, the leader of the asynchronous events subgroup, presented
their model of asynchronous event handling to the group. This was
mostly a formality; group members had already been exposed to POSIX
real-time async events handling.
Some concern was raised about select(). Members pointed out that the
real-time draft for async events implied more syscall overhead than
occurs in select() in BSD or poll() in V.3; the real-time group will
resolve the issue, in possible conjunction with the supercomputing
group, which gave us an interesting presentation the "listio()"
routine, which can be used to fire off multiple I/O transfers
operating on a list of file descriptors.
8. XTI versus sockets
The "XTI versus sockets" issue is so important to users and vendors
that it couldn't be left unaddressed. Here is the official committee
consensus:
We make no decision right now on the sophisticated interface's
actual relationship to the existing socket and XTI interfaces,
but it will have a flavor and functionality and granularity
similar to that provided by the socket and XTI interfaces.
In other words, the group feels that there are advantages to both XTI
and sockets, and that POSIX will adopt features from both, but has not
yet addressed whether there will be a straightforward adoption or
direct extension of either, or will take some new form. (One hopes
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 7 - IEEE 1003.8 Networking
that a new form would be a functional superset of the other two.)
The group is quite aware that there are several camps and many
potentially conficting goals in this highly sensitive area. Getting
XTI and socket advocates to agree on a common interface will probably
be a monumental task, fraught with potential dangers and traps. Any
new interface would be likely to need a clear migration path from XTI
and/or sockets to minimize code changes needed for existing
applications: for example, sets of macro routines or public domain
layer routines published in appendices. The group is aware of the
possible precedent set by POSIX 1003.1 with regard to System V and 4.2
BSD (the termios section in particular). The group will study the
potential benefits and drawbacks of all identifiable options before
making any decisions.
The adage that "everyone wants things to get better, but no one wants
anything to change" applies here. The sophisticated interface will
require some compromises. The various camps must realize the benefits
of joining forces and agreeing on a common standard if the working
group is to be successful in this endeavor.
9. e-mail distribution list
The group will use E-mail distribution lists to expedite work and
communication between meetings. The U.C. Berkeley representatives
volunteered to organize this effort and maintain the lists on their
machines.
Anybody may join (or leave) the list by mailing to posix-net-ptp-
request @ucbvax.Berkeley.EDU.
10. Future Agenda
At the San Jose meeting, P1003.8/IPC will:
o+ separate the functionality and objects list into lists for the
"naive" and "sophisticated" interfaces;
o+ obtain (from action items between meetings) a more detailed list
of objects, and a first cut at grouping the functionality and
objects into functions for the two interfaces, and continue work
from that point;
o+ continue to work with P1003.4 on the issues of message interface
and async events
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 36