throbber
IJ /
`
`1986 Summer
`Technical Conference & Exhibition
`Atlanta, Georgia
`
`Conference
`Proceedings
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`Page 1
`
`

`
`USENIX Association
`
`Summer Conference Proceedings
`
`Atlanta 1986
`
`June 9- 13, 1986
`Atlanta, Georgia USA
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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.
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`1
`
`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
`
`'·· I
`
`I I
`i
`I !
`
`l
`
`I ! I !
`t I I
`t !
`
`I
`f
`!
`' I
`I !
`~ I l
`' i
`I
`
`!
`i
`I
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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 Information 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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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:
`
`Where
`
`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
`
`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
`
`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
`
`l
`
`~
`~
`
`f
`~ I
`I
`I
`I
`I ' I
`I ;I
`
`!
`
`I
`I
`I I
`
`I l
`
`I
`
`J I
`1
`I
`I
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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 (or 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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`Page 12
`
`

`
`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 be 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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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
`
`PMC Exhibit 2071
`Apple v. PMC
`IPR2016-00755
`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 to 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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket