: ~ r11;:
`
`1986 Summer
`Technical Conference & Exhibition
`Atlanta, Georgia
`
`Conference
`Proceedings
`
`
`
`APPLE EX. 1042
`Page 1
`
`

`
`USENIX Association
`
`Summer Conference Proceedings
`
`Atlanta 1986
`
`June 9- 13, 1986
`Atlanta, Georgia USA
`
`Page i
`
`
`
`APPLE EX. 1042
`Page 2
`
`

`
`For additional copies of these proceedings, write:
`
`USENIX Association
`
`P.O. Box 7
`
`El Cerrito, CA 94530 USA
`
`Price: $25.00 plus $25.00 for overseas mail
`
`© Copyright 1986 by The USENIX Association
`
`All rights reserved.
`
`This volume is published as a collective work.
`
`Rights to individual papers remain
`
`with the author or the author's employer.
`
`UNIX® is a registered trademark of AT&T.
`
`Other trademarks are noted in the text.
`
`Page ii
`
`
`
`APPLE EX. 1042
`Page 3
`
`

`
`VV I
`
`~..._;,
`
`ViQR L/41'-/-·-/
`
`ACKNOWLEDGEMENTS
`
`Sponsor:
`
`The USENIX Association
`P.O.Box7
`El Cerrito, CA 94350
`
`Program Chairperson:
`
`Mike O'Dell
`
`Program Committee:
`
`John Chambers
`Mike Hawley
`SamLeffier
`Jim McKie
`Dennis Ritchie
`Spencer Thomas
`
`MCC
`Lucasfilm, Ltd.
`Lucasfilm, Ltd.
`Bell Communications Research
`AT&T Bell Laboratories
`University of Utah, Computer
`Science Department
`
`Tutorial Coordinator:
`
`Michael Tilson
`
`Human Computing Resources Corp.
`
`USENIX Meeting Planner:
`
`Judith DesHarnais
`
`Vendor Exhibition Manager:
`
`John Donnelly
`
`Conference Hosts:
`
`Paul Manno
`Dan Forsyth
`
`Medical Systems Development Corp.
`
`Terry Countryman, Peter Wan, and Lillie Elliot of Medical Systems Development Corporation assisted in the
`production of these proceedings. Brent Laminack of In Touch Ministries graciously provided assistance in
`producing the table of contents. Ralph Amiel of Standard Press patiently answered many dumb questions on the
`production of a volume this size.
`
`To all of the authors: You deserve many thanks and much appreciation. You have made an otherwise
`impossible task relatively easy by providing the camera-readies in plenty of time to meet the printing deadlines.
`To those.authors who forgot to clean their laser printers before generating their copy: Yes, it does show. What
`you see is what the camera sees. Please remember next time.
`
`iii
`
`Page iii
`
`
`
`APPLE EX. 1042
`Page 4
`
`

`
`TABLE OF CONTENTS
`
`PLENARY SESSION
`
`Wednesday, June 11, 9:00- 10:30
`
`(Grand Ballroom)
`
`Opening Remarks:
`Conference Organizers and the USENIX Board
`Keynote Address: Pictures of Programs
`Jon Bentley, AT&T Bell Laboratories
`
`MUSIC
`
`Wednesday, June 11, 11:00- 12:30
`
`(Grand Ballroom)
`
`MIDI Music Software for UNIX
`........•...............................•............................
`Michael Hawley, The Droid Works
`(201) 644-2332 or Eedie & Eddie on the Wire: An Experiment in Music Generation
`PeterS. Langston, Bell Communications Research
`
`13
`
`Networks I.
`
`Wednesday, June 11,2:00- 3:30
`
`(Grand Ballroom)
`
`Secure Networking in the Sun Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
`Bradley Taylor, David Goldberg, Sun Microsystems, Inc.
`A Framework for Networking in System v
`...................................................... 38
`David J. Olander, Gilbert J. McGrath, Robert K. Israel, AT&T
`OSI and TCP/IP Protocols on a UNIX System v
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
`Jean Marc Fenart, Marc Fievet, Christian Huitema, Bernard Martin,
`Annie Remille, Guy Vaysseix, INRIA
`
`Performance
`
`Wednesday, June 11,2:00-3:30
`
`(Grand Salon)
`
`Managing Development of Performance-Constrained UNIX-Based Software System
`on Microcomputers L. Perkins, Martin Marietta
`A Multiuser Multiprocessor Benchmark to Compare UNIX Systems ........................... 59
`Philip M. Mills, NCR Corporation
`A System Call Tracer for UNIX • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . 72
`R. Rodriguez, Digital Equipment Corporation
`
`iv
`
`Pageiv
`
`f
`
`i
`i I
`I !
`! I
`~
`I l
`' i
`I
`l
`! i
`L_
`
`
`
`APPLE EX. 1042
`Page 5
`
`

`
`Operating Systems 1
`
`Wednesday, June 11, 4:00- 5:30
`
`(Grand Ballroom)
`
`A New Virtual Memory Implementation for UNIX .....•.. .. . ...•.... .••. .............. ... . .. ..... 81
`Edward W. Sznyter, Patrick Clancy, James Crossland, Tektronix, Inc.
`Mach: A New Kernel Foundation for UNIX Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
`Mike Accetta, Robert Baron, William Bolosky, David Golub ,Richard Rashid,
`Avadis Tevanian, Michael Young, Carnegie-Mellon Univeristy
`An Extensible I/0 System ........................................................................... 114
`Jim Rees, Paul H. Levine, Nathaniel Mishkin, Paul J. Leach, Apollo Computer
`
`Tools
`
`Wednesday, June 11, 4:00- 5:30
`
`(Grand Salon)
`
`PA1HALIAS or The Care and Feeding of Relative Addresses .................................... 126
`Peter Honeyman, Princeton University,
`Steven M. Bellovin, AT&T Bell Laboratories
`Pollster: A Document Annotation System for Distributed Environments
`Luis-Felipe Cabrera, IBM Almaden Research Center,
`Eric Mowat, University of California, Berkeley
`When Network File Systems Aren't Enough: Automatic Software Distribution Revisited ... 159
`Daniel Nachbar, Bell Communications Research
`
`..................... 142
`
`Networks 2
`
`Thursday, June 12,9:00 -10:30
`
`(Grand Ballroom)
`
`Experiences Implementing BIND, a Distributed Name Server for the DARPA Internet
`James M. Bloom, CSRG,University of California, Berkeley,
`Kevin J. Dunlap, Digital Equipment Corporation
`Network Performance and Management with 4.3BSD and IP/TCP ......••....•...........•..... 182
`Michael J. Karels, Marshall Kirk McKusick,
`CSRG, University of California, Berkeley
`A Real-Time Electronic Conferencing System: based on Distributed UNIX ..................... 189
`Tatsuo Suzuki, Hideo Taniguchi, Hisayasu Takada,
`NIT Electrical Communications Laboratories
`
`...... 172
`
`Real Work 1
`
`Thursday, June 12,9:00- 10:30
`
`(Grand Salon)
`
`How to Make Friends with Number-Crunchers ................................................... 200
`Gregory Dudek, Michael Jenkin, Howard Marcus, University of Toronto
`Kanji UNIX: Yunikkusu wa Nihongo o Hanasemasu (UNIX Speaks Japanese) ............... 209
`RobertS. lung, Joseph T. Kalash, Unisoft Systems
`Tools for the Maintenance and Installation of a Large Software Distribution .................. 223
`D. M. Tilbrook, P.R. H. Place, Imperial Software Technology
`
`v
`
`Pagev
`
`
`
`APPLE EX. 1042
`Page 6
`
`

`
`Distributed File Systems 1
`
`Thursday, June 12, 11:00- 12:30
`
`(Grand Ballroom)
`
`Vnodes: An Architecture for Multiple File System Types in Sun UNIX ..............•......... 238
`S. R. Kleiman, Sun Microsystems
`Remote File Sharing Architectural Overview ...................................................... 248
`· Andrew P. Rifkin, Michael P. Forbes, Richard L. Hamilton,
`Michael Sabrio, Suryakanta Shah, Kang Yueh, AT&T Informq.tion Systems
`..................... , ..................................................... 260
`The Generic File System
`R. Rodriguez, M. Koehler, R. Hyde, Digital Equipment Corporation
`
`Text Processing
`
`Thursday, June 12, 11:00- 12:30
`
`(Grand Salon)
`
`Modelling Text as a Hierarchical Object ............................................................ 270
`James Waldo, Apollo Computer Inc.
`SMSCRIPT: An Interpretor for the POSTSCRIPT Language Under UNIX ....•................... 284
`Bruno Borghi; Stephane Querel, Daniel de Rauglaudre, INRIA
`
`Distributed File Systems 2
`
`Thursday, June 12, 2:00- 3:30
`
`(Grand Ballroom)
`
`The Network File System Implemented on 4.3BSD
`Ed Gould, Mt. Xinu
`NFS Portability
`.......................................................................... · ............. 299
`Mordecai B. Rosen, Michael J. Wilde, Lachman Associates Inc.
`Bill Fraser-Campbell, The Instruction Set, Ltd.
`............................................................ 306
`The Transparent Remote File System
`Ronald P. Hughes, Integrated Solutions, Inc.
`
`..••••••........•...••......................• 294
`
`Language Technology
`
`Thursday, June 12, 2:00- 3:30
`
`(Grand Salon)
`
`A Global Optimizer for Sun FORTRAN, C & PASCAL
`.....•.............•...................... 318
`Vida Ghodssi, StevenS. Muchnick, Alex Wu, Sun Microsystems, Inc.
`................................................... 335
`Four Generations of the Portable C Compiler
`David M. Kristof, AT&T Information Systems
`The N otifier
`.......................................................................................... 344
`Steve Evans, Sun Microsystems, Inc.
`
`vi
`
`Page vi
`
`
`
`APPLE EX. 1042
`Page 7
`
`

`
`Distributed File Systems 3
`
`Thursday, June 12,4:00-5:30
`
`(Grand Ballroom)
`
`Error Recovery in a Stateful Remote Filesystem
`Alan Atlas, Perry Flinn, MASSCOMP
`Distributed File Systems Panel
`
`................................................ 355
`
`Electronic Mail
`
`Thursday, June 12, 4:00- 5:30
`
`(Grand Salon)
`
`............................................................... 366
`Mail Routing using Domain Names
`Craig Partridge, CSNET Coordination and Information Center
`AT&TMail
`.......................................................................................... 377
`DaleS. DeJager, AT&T Information Systems
`A Mail File System for Eighth Edition UNIX
`.....•............................................. 391
`David Ritz, Peter Honeyman, Princeton University
`
`Operating Systems 2
`
`Friday, June 13,9:00-10:30
`
`(Grand Ballroom)
`
`Shared Libraries on UNIX System v ............................................................... 395
`James Q. Arnold, AT&T
`Decreasing Realtime Process Dispatch Latency through Kernel Preemption .................. 405
`David C. Lennert, Hewlett-Packard
`MOS- Scaling Up UNIX .............................................................................. 414
`AmnonBarak, On G. Paradise, Hebrew University of Jerusalem
`
`Friday, June 13, ?:00- 10:30
`
`(Grand Salon)
`
`USENETBOF
`
`Windows
`
`Friday, June 13, 11:00- 12:30
`
`(Grand Ballrpom)
`
`A Data-Flow Manager for an Interactive Programming Environment
`Paul E. Haeberli, Silicon Graphics, Inc.
`UWM: A User Interface for X Windows ............................................................ 429
`Michael Gcmcarz, Digital Equipment Corporation
`Programming with Windows on the Major Workstations ....................................... 441
`Stephen Daniel, C. Durward Rogers, Microelectronics Center of North Carolina
`
`........................ 419
`
`vii
`
`Page vii
`
`
`
`APPLE EX. 1042
`Page 8
`
`

`
`Operating Systems 3
`
`Friday, June 13, 11:00 • 12:30
`
`(Grand Salon)
`
`The Influence of Workload on Load Balancing Strategies ....................................... 446
`Luis-Felipe Cabrera, IBM Almaden Research Center
`A System V Compatible Implementation of 4.2BSD Job Control
`David C. Lennert, Hewlett-Packard
`UNIX as a Virtual Machine Environment.
`. ........................................................ 475
`Robert E. Genter, BBN Laboratories Inc.
`
`.............................. 459
`
`Real Work 2
`
`Friday, June 13, 2:00- 3:30
`
`(Grand Ballroom)
`
`......................................................... 486
`Porting to a Network of Diskless Micros
`W. Appelbe, D. Coleman, A. Fratkin, J. Hutchison, W. Savitch,
`University of California, San Diego
`A State-wide Distributed Computing System ...................................................... 499
`Tom Truscott, Bob Warren, Ken Moat, Research Triangle Institute
`UNIX-based Distributed Printing in a Diverse Environment
`.................................... 514
`William E. Johnston, Dennis E. Hall, Lawrence Berkeley Laboratory
`
`Friday, June 13, 2:00 • 3:30
`
`(Grand Salon)
`
`Wizard's Panel
`
`viii
`
`Page viii
`
`
`
`APPLE EX. 1042
`Page 9
`
`

`
`AUTHOR INDEX
`
`Accetta, Mike
`Appelbe, W.
`Arnold, James Q.
`Atlas, Alan
`Barak, Amnon
`Baron, Robert
`Bellovin, Steven M.
`Bloom, James M.
`Bolosky, William
`Borghi, Bruno
`Cabrera, Luis-Felipe
`Clancy, Patrick
`Coleman, D.
`Crossland, James
`Daniel, Stephen
`DeJager, DaleS.
`Dudek, Gregory
`Dunlap, Kevin J.
`Evans, Steve
`Fenart, Jean Marc
`Fievet, Marc
`Flinn, Perry
`Forbes, Michael P.
`Fraser-Campbell, Bill
`Fratkin, A.
`Gancarz, Michael
`Genter, Robert E.
`Ghodssi, Vida
`Goldberg, David
`Golub, David
`Gould, Ed
`Haeberli, Paul E.
`Hall, Dennis E.
`Hamilton, Richard L.
`Hawley, Michael
`Ritz, David
`Honeyman, Peter
`Hughes, Ronald P.
`Huitema, Christian
`Hutchison, J.
`Hyde,R.
`Israel, Robert K.
`Jenkin, Michael
`Johnston, William E.
`Jung, RobertS.
`Kalash, Joseph T.
`Karels, Michael J.
`
`93
`486
`395
`355
`414
`93
`126
`172
`93
`284
`142,446
`81
`486
`81
`441
`377
`200
`172
`344
`46
`46
`355
`248
`299
`486
`429
`475
`318
`28
`93
`294
`419
`514
`248
`1
`391
`126,391
`306
`46
`486
`260
`38
`200
`514
`209
`209
`182
`
`Kleiman, S. R.
`Koehler,M.
`Kristol, David M.
`Langston._Peter S.
`Leach, Paul J.
`Lennert, David C.
`Levine, Paul H.
`Marcus, Howard
`Martin, Bernard
`McGrath, Gilbert J.
`McKusick, Marshall Kirk
`Mills, Philip M.
`Mishkin, Nathaniel
`Moat, Ken
`Mowat, Eric
`Muchnick, StevenS.
`Nachbar, Daniel
`Olander, David J.
`Paradise, On G.
`Partridge, Craig
`Place, P. R. H.
`Querel, Stephane
`Rashid, Richard
`Rauglaudre, Daniel de
`Rees, Jim
`Remille, Annie
`Rifkin, Andrew P.
`Rodriguez, R.
`Rogers, C. Durward
`Rosen, Mordecai B.
`Sabrio, Michael
`Savitch, W.
`Shah, Suryakanta
`Suzuki, Tatsuo
`Sznyter, Edward W.
`Takada, Hisayasu
`Taniguchi, Hideo
`Taylor, Bradley
`Tevanian, A vadis
`Tilbrook, D. M.
`Truscott, Tom
`V aysseix, Guy
`Waldo, James
`Warren, Bob
`Wilde, Michael J.
`Wu,Alex
`Young, Michael
`Yueh, Kang
`
`238
`260
`335
`13
`114
`405,459
`114
`200
`46
`38
`182
`59
`114
`499
`142
`318
`159
`38
`414
`366
`223
`284
`93
`284
`114
`46
`248
`72,260
`441
`299
`248
`486
`248
`189
`81
`189
`189
`28
`93
`223
`499
`46
`270
`499
`299
`318
`93
`248
`
`ix
`
`Pageix
`
`
`
`APPLE EX. 1042
`Page 10
`
`

`
`PREFACE TO THE ATLANTA CONFERENCE
`
`This conference marks the Eleventh Anniversary of Unix User's meetings. What began
`as informal gatherings among a handful of people with a common interest has grown into a
`semiannual event of major proportions. Gone are the days when individuals would raise their
`hands at the beginning of the meeting to indicate they had something of interest to share with
`the other attendees; our group is just too large for that to be practical any more. Informal
`presentations have been replaced by a formal review process complete with conference
`proceedings available to attendees when they register at the conference. Our meetings of less
`than 100 people have grown to fifteen to twenty times that size, requiring careful organization
`and coordination among many people, with plans often beginning more than two years before
`the actual conference date.
`
`Clearly we have come a long way since those early days. If you're wondering where
`and when all those past conferences were held and who helped make them happen, here's a
`list:
`
`11-13 Jun 86
`15-17 Jan 86
`10-14 Jun 85
`23-25 Jan 85
`13-15 Jun 84
`16-20 Jan 84
`13-15 Jul83
`26-28 Jan 83
`6-9 Jul82
`27-29 Jan 82
`24-26Jun 81
`21-23 Jan 81
`17-20 Jun 80
`29 Jan-1 Feb 80
`30Nov79
`20-23Jun 79
`25-27 Jan 79
`2 Oct 78
`24-28 May 78
`12-13 Sep 77
`19-21 May77
`1~3 Oct 76
`1-2 Apr76
`27-28 Feb 76
`31 Oct 75
`27 Oct 75
`18 Jun 75
`
`Atlanta, GA
`Denver, CO
`Portland, OR
`Dallas, TX
`Salt Lake City, UT
`Washington, DC
`Toronto, ON
`San Diego, CA
`Boston, MA
`Santa Monica, CA
`Austin, TX
`San Francisco, CA
`Newark, DE
`Boulder, CO
`Menlo Park, CA
`Toronto, ON
`Santa Monica, CA
`Menlo Park, CA
`New York, NY
`Menlo Park, CA
`Urbana, IL
`Cambridge, MA
`Cambridge, MA
`Berkeley, CA
`Monterey, CA
`New York, NY.
`New York, NY
`
`Medical Systems Dev Corp (Dan Forsyth & Paul Manno)
`University of Colorado (Evi Nemeth)
`Tektronix (Steve Glaser)
`(Charisse Castagnoli & Rob Kolstad)
`University of Utah (Randy Frank)
`* (Reidar Bornholdt)
`HCR (Mike Tilson)
`University of California at San Diego* (Tom Uter)
`BBN (Alan Nemeth)
`ISC (Mike O'Brien) ·
`University of Texas (Wally Wedel)
`University of California at San Francisco (Tom Ferrin)
`University of Delaware (Dan Grim)
`National Center for Atmospheric Research (John Donnelly)
`SRI (John Bass)
`University of Toronto (Ron Baecker)
`ISC (Steve Holmgren)
`SRI (John Bass)
`Columbia University (Lou Katz)
`SRI (Oliver Whitby & John Bass)
`University of Illinois (Steve Holmgren)
`Harvard University (Lewis Law)
`Harvard University (Lewis Law)
`University of California at Berkeley (Bob Fabry)
`Naval Postgraduate School (Belton Allen)
`City University of New York (Mel Ferentz)
`City University of New York (Mel Ferentz)
`
`?
`1,157
`1,730
`1,200
`1,500
`8,000
`1,500
`1,850
`1,300
`1,000
`500
`1,000
`
`450
`
`400
`350
`75
`-350
`-100
`-250
`-120
`-60
`
`40
`
`*Indicates joint conference with /usr/group.
`
`(This preface and table were shamelessly stolen from the USENIX Conference Proceedings, Summer 1985.)
`
`X
`
`Pagex
`
`l
`
`f
`~ I
`I
`I
`I
`I
`I
`I
`I ;I
`
`I
`I
`I I
`
`I l
`
`I
`
`J
`
`I
`1
`I
`I
`L
`
`
`
`APPLE EX. 1042
`Page 11
`
`

`
`When Network File Systems Aren't Enough:
`Automatic Software Distribution Revisited
`
`Daniel Nachbar
`
`@ Bell Communications Research
`Morristown, New Jersey
`
`ABSTRACT
`
`The system described, named track, addresses the problem of maintaining
`software and data on multiple machines running the UNIX operating system.
`Under track, updates are made from a central librarian machine (~r machines).
`All updates are initiated by the receiving machine. Local initiation of updates
`allows system administrators to take advantage of centrally maintained software
`without relinquishing control of when and how updates are made. Track can
`also map file names when making copies and execute an arbitrary shell script after
`a copy is made. Given these features, track can automate common system
`administration tasks (e.g. installing new releases of software) as well as difficult
`tasks (e.g. booting a new UNIX kernel).
`
`System Administration in a Changing World
`Only a few years ago, most computer research facilities consisted of one or a few CPU's. In
`the recent past, this has changed drastically. For instance, in our laboratory at BELLCORE, the
`computer center now contains approximately 40 CPU's of 4 different architectures running 3
`different flavors of UNIX. This growth in the number and variety of machines threatens to
`increase greatly the amount of human effort needed to handle even the simplest tasks of system
`administration.
`Adding to system administration problems is the fact that UNIX itself has grow:n. A "com(cid:173)
`plete" 4.2BSD system consists of about 6,000 administration files. (This includes all the binary,
`library, and data files but does not include source code files.) Regularly used software packages,
`contribute an additional 4,000 files.
`However, the large number of files that make up UNIX does not in itself create a problem.
`Clearly, if the contents of these files never changed, one could simply initialize them when the sys(cid:173)
`tem is set up and forget about them. Unfortunately, at least in a research environment, these files
`change constantly. Some files change frequently (/etcjpasswd changes almost hourly on our sys(cid:173)
`tems.) It is relatively easy to deal with these few, frequently changing files; of greater difficulty is
`the much larger mass of less frequently changing files. In our computer center, roughly 200 of·
`these 10,000 files are modified each month. Other complexities arise because some files are shared
`by machines of differing architecture, while others are not. Tracking a moving target consisting of
`some 10,000 sporadically changing files on several machines is far too complicated a task to be
`done by hand.
`If some sort of network files system or other information server is available, the situation is
`greatly eased. However, practical considerations often preclude the use of such systems for
`administration files. First of all, communications overhead becomes prohibitive for all but the
`smallest CPU's operating on a relatively fast communications channel. Second, political con(cid:173)
`siderations make it highly unlikely that the administrator of one computer center would be willing
`to rely totally upon some other computer center for all his administra~ion files. Today one finds
`
`159
`
`Page 159
`
`
`
`APPLE EX. 1042
`Page 12
`
`

`
`1
`'I)
`!
`I
`
`single-user workstations that are part of the same computing facility sharing administration files
`via an ethernet. However, it will be a long time before we see a supercomputer that is owned by a
`private company in New Jersey access its "/bin" directly from disks in Berkeley.
`Thus, given that there will probably always be multiple instances of administration files, the
`problem is to make sure that all such instances contain the same data. To make the problem
`more manageable, one instance is usually designated as the master version of which all other
`machines have copies. While this restriction may not be acceptable for distributed data in gen(cid:173)
`eral, it is reasonable for most system administration problems. The question then becomes one of
`deciding when to update the copies given that the master version of a file has been changed.
`
`Previous Systems
`Programs that address the problem of maintaining multiple instances of files on different
`machines have generally been referred to as "automatic software distribution systems". Several
`such systems have been written (we refer in particular to the asd system by Koenig[l] and the
`rdist system distributed with 4.3BSD.) However, one finds that these existing systems are usually
`operated only within a computer center. In particular, they require a central administrator (or
`process) to specify that a given file should be broadcast or "shipped out" to other machines. Cen(cid:173)
`tral administration has several drawbacks. First of all there are some pradical problems. There
`must be a tight coupling between the changing of the master version and its broadcast to other
`machines. If a master version is changed but accidentally not broadcast or if the update is lost in
`transmission, the copies will diverge from the master. Such divergence is difficult to detect.
`Furthermore, once divergence has appeared, it will remain until the master version is broadcast
`again.
`The problem of possible accidental divergence caused by centralized administration can be
`overcome by periodically inspecting the master and copies of each file and making updates if
`differences are found (the rdist system uses this approach.) However, periodic checking for diver(cid:173)
`gence does not overcome another, potentially more serious problem with centralized administra(cid:173)
`tion of updates: the loss of control by local administrators as to how and when updates are made
`on their machines. For whatever reasons, local administrators (in particular people who adminis(cid:173)
`ter their own workstations) usually wish to intervene in the updating process. For example, if a
`machine is being used for data collection over an extended period of time, the administrator may
`wish to defer updates until after the study is complete. Such intervention varies from person to
`person, file to file, and even from time to time. Local administrators are often reluctant to allow
`oth~r people to change administration files on their machines.
`There is a huge range in the amount of control that local administrators wish to have. In
`some cases, no intervention is needed. Updates can be fully automated. This is usually the case
`when one person or group is administering both the source and destination machines. In other
`cases, a local administrator may wish to have an update take place automatically and be notified
`of the updat~ after the fact. This allows the administrator to localize problems that may occur
`from the installation of new versions. Other administrators may wish to have new versions of files
`arrive in some innocuous place where they can be inspected before installation. In still other cases,
`an administrator may wish to be merely notified that a new version of some file is available. Cen(cid:173)
`tral administration does not lend itself to such local customizations. Thus, while there is much
`general interest in sharing code between computer facilities as well as within them, automatic
`software distribution systems that do not allow for local control will most likely never be used
`when the source and destination machines are administered by different people.
`An obvious alternative to central administration is to have receiving machines poll for new
`versions of files. Under such a scheme, the receiving machine would periodically check the status
`of each master file of interest and initiate updates when necessary. The problem with this
`approach is that unless checking file status and initiating updates are very easy, local administni(cid:173)
`tors ma.y often fa.il to do them. Furt.h.erm.ore, there must he very litt,le overh~ad involved in
`checking the status of master versions since this check must be done once for every copy of the file
`during each polling period. However, it is interesting to note that while systems with distributed
`
`160
`
`Page 160
`
`
`
`APPLE EX. 1042
`Page 13
`
`

`
`initiation of updates can "simulate" a system with centralized control (assuming that the source
`machine can somehow execute a command on the destination machine,) the opposite is not true.
`Another design assumption made in some automatic software distribution systems is the
`requirement that processes on both the source and destination machines operate in a synchronous
`manner. The rdist system makes this assumption; asd does not.
`
`The Librarian/Subscriber Model of Updates
`The system described in this paper, called track, was designed using distributed administra(cid:173)
`tion with periodic checking of file status and asynchronous communication. Track views the mas(cid:173)
`ter versions of files as a passive repository. We describe this view as a librarian/subscriber model.
`The machine containing the master versions of files is called the librarian machine. (There can be
`more than one librarian. For ease of description we shall talk about only one.) Machines that
`make copies of files from the librarian are called the subscriber machines.
`Clearly this is a server/client model. The different terminology is used to emphasize the
`functional similarity between our electronic librarian and its human counterpart. Typically,
`human librarians provide listings of available information and copies of information upon request.
`If human librarians followed the example of automatic software distribution systems with central(cid:173)
`ized control, they would march into one's offices without warning and insist that that a certain
`book is to be read immediately. We believe that such behavior on the part of either humans or
`machines is intolerable.
`In keeping with our metaphor, our electronic librarian has two tasks : 1) to provide a listing
`of its files that are available to subscribers, as well as some information about the currentness of
`each file. Track uses
`the time of last modification as its measure of currentness.
`(Clearly,
`modification date is not the proper measure of currentness for things such as symbolic links and
`directories. For the time being, we shall only be discussing how track handles ordinary files. Spe(cid:173)
`cial files as well as alternative measures of currentness will be discussed later in the section entitled
`"Nitty Gritty".) And 2) to give out copies of files to authorized subscribers upon request. Given
`such a cooperative librarian, a subscriber machine need' only inspect the librarian's listing of
`available files and request new copies of files that are more current than its own.
`At the core of track's operation is the subscription list. On the librarian, the subscription
`list describes the set of files to be made available to Qther machines. On the subscriber machine,
`the subscription list describes the set of files to be considered for potential update from the
`librarian. Often, the subscription lists are identical on librarian and subscriber machines. How(cid:173)
`ever, this is not always the case. As we shall see later, by editing local {subscriber) copies of the
`subscription list, local administrators can control updates on their machines.
`
`A Simple Example
`We will now step through an example of how updates take place. In order for an update to
`take place, the program named track must be run at some point on both the librarian and sub(cid:173)
`scriber. While it is possible to invoke track by hand, it is more common for it to be invoked at
`regular intervals by the UNIX clock daemon (/etc/cron).
`
`Figure 1 -- contents of the subscription list named "hourly"
`
`#
`#
`#
`blob
`
`files to be updated frequently
`
`....
`: /etc/hosts
`:/etc/networks : : : :
`: /etc/services : : : :
`
`161
`
`Page 161
`
`
`
`APPLE EX. 1042
`Page 14
`
`

`
`At some point in time (as controlled by .fetcjcron), the librarian machine ("blob") exec11tes
`the command track -w hourly. Upon invocation with the-w flag ( -w stands for "write") track:
`1) reads the appropriate subscription list, ("hourly" -- see Figure 1). The subscription list
`specifies that the files named "/etc/hosts," "jete/networks," and "/etc/services" are to be
`made available to subscriber machines. And,
`2) collects the modification date of each file listed and creates a statfile. * By convention, the
`name of the statfile is created by combining the subscription list's file name and the
`librarian's machine name. In this case, the statfile is called "hourly .blob" (see Figure 2.)
`Statfiles have one line for each object. Each line contains three pieces of information: 1) a single
`character describing the type of object being handled (in Figure 2, this is always "f" for "file"), 2)
`the name of the object, and 3) some measure of the currentness of the object (in Figure 2, this is
`always the modification date of the file expressed in seconds). For a complete description of the
`format of statfiles see the manual page statfile(5) in the appendix.
`
`Figure 2 --contents of the statfile named "hourly.blob"
`
`f/etc/hosts 488058628
`f/etcjnetworks 487994526
`f/etcjservices 482463012
`
`At some later time(also determined by /etc/cron), the subscriber machine will execute the com(cid:173)
`mand track hourly. Upon invocation without the-w flag track will:
`1) obtain a copy of the librarian's statfile.
`2) for each file in the statfile:
`A) see if the file is included in its own subscription list
`B) examine the modification date of its own version of the file.
`3) request from the librarian, those files that are included in the subscription list and have
`newer modification dates. During the copying process, the subscriber must be careful to
`reset the date of last modification on the riew local copies.-:-
`It should be noted that we have not described how subscribers and librarians actually communi(cid:173)
`cate with one another. It is our intention that track be able to work over many different com(cid:173)
`munications media.
`
`Some More Complicated Cases
`Having described the basic case, we will now describe the layout of the subscription list in
`more detail. A more complete and formal desc~iption can be found in the manual page for sub(cid:173)
`scriptionlist(5).
`The principal function of the subscription list is to define a set of files. In addition, the sub(cid:173)
`scription list describes where master versions are to be found, and how they are to be copied. In
`other words, the subscription list defines what and how files are to be tracked.
`A subscription list consists of a series of entries. Each entry consists of 6 fields. All fields,
`except the last, are terminated by a colon. The last field is terminated by a newline.
`As in Figure 1, the first field contains the name of the librarian machine. The second field
`contains the name of the file to be tracked. To be more precise, the second field contains the file
`name t~ be used on the librarian. (more on this later.) In the previous example, the second field
`always contained the name of an ordinary file. If the second field contains the name of a direc(cid:173)
`tory, that directory is handled as the root of a file subtree, i.e. all files in the subtree will be
`
`* Statfiles are named after the UNIX system call, stat(), that is used to collect file status and the modification
`date.
`7 If the modification date is not properly reset, then the next time that the subscriber examines the librarian's
`stalfi