Path: utzoo!attcan!uunet!longway!std-unix From: jsh@usenix.org Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.12: Inter-Process Communication Message-ID: <577@longway.TIC.COM> Date: 19 Mar 90 21:43:24 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Lines: 153 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: 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 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