PATHWORKS: PC Integration Software

Digital Technical] ournal Digital Equipment Corporation

Volume 4 Number 1 Winter 1992 Editorial Jane C. Blake, Editor Kathleen M. Stetson, Associate Editor Helen L. Patterson, Associate Editor Circulation Catherine M. Phillips, Administrator Sherry L. Gonzalez Production Mildred R. Rosenzweig, Production Editor Margaret L. Burdine, Typographer Peter R. Woodbury, Illustrator Advisory Board Samuel H. Fuller, Chairman Robert M. Glorioso Richard]. Hollingsworth John W McCredie Alan G. Nemeth Mahendra R. Patel F. Grant Saviers Victor A. Vyssotsky Gayn B. Winters

The Digital Technicaljournal is published quarterly by Digital Equipment Corporation, 146 Main Street ML01-3/B68, Maynard, Massachusetts 01754-2571. Subscriptions to thejournal are $40.00 for four issues and must be prepaid in U.S. funds. University and college professors and Ph.D. students in the electrical engineering and computer science fields receive complimentary subscriptions upon request. Orders, inquiries, and address changes should be sent to the Digital Technicaljournal at the published-by address. Inquiries can also be sent electronically to DTJ®CRL.DEC.COM. Single copies and back issues are available for $16.00 each from Digital Press of Digital Equipment Corporation, 1 Burlington Woods Drive, Burlington, MA 01830-4597

Digital employees may send subscription orders on the ENET to ROVAX::JOURNAL or by interoffice mail to mailstop ML01-3/B68. Orders should include badge number, site location code, and address. All employees must advise of changes of address.

Comments on the content of any paper are welcomed and may be sent to the editor at the published-by or network address.

Copyright© 1992 Digital Equipment Corporation. Copying without fee is permitted provided that such copies are made for use in educational institutions by faculty members and are not distributed for commercial advantage. Abstracting with credit of Digital Equipment Corporation's authorship is permitted. All rights reserved.

The information in the journal is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in the journal.

!SSN 0898-901X Documentation Number EY-J825E-DP

The following are trademarks of Digital Equipment Corporation: ALL·lN-1, DEC, DEC EtherWorks, DECnet, DECperformance, DECquery, DECwindows, Digital, the Digital logo, DNA, eXcursion, LAT, PATHWORKS, ULTR!X, VAX, VAX C, VAX Performance Advisor, VAX 4000, VAX 6000, VAXcluster, VAXstation, and VAX.

3Com is a registered trademark of 3Com Corporation.

Apple, AppleShare, AppleTalk, LocaiTalk, and Macintosh are registered trademarks and QuickStart is a trademark of Apple Computer, Inc.

CodeView, Microsoft, MS, and MS-DOS are registered trademarks and Windows is a trademark of Microsoft Corporation.

CRAY is a registered trademark of Cray Research, lnc.

i386, i486, and Intel are trademarks of Intel Corporation.

IBM, Micro Channel, and OS/2 are registered trademarks of International Business Machines Corporation.

Motif is a registered trademark of Open Software Foundation, Inc.

Motorola and 68000 are registered trademarks of Motorola, Inc. CoverDesign NetWare and Novell are registered trademarks of Novell, Inc. The red and blue threads woven together in our cover design Network General and Sniffer are registered trademarks of represent the many PC clients and server systems that are inte­ Network General Corporation. grated in a network environment by the outstanding "thread" NFS and Sun are registered trademarks of Sun Microsystems, Inc. of PATHWORKS software. PATHWORKS software for the integration UNIX is a registered trademark of UNIX System Laboratories, Inc. of PCs over fANs and WANs is the featured topic in this issue. X/Open is a trademark of X/Open Company Limited.

The cover was designed by Kathryn Cimis of the Corporate Book production was done by Digital's Database Publishing Group Design Group. in Northboro, MA. I Contents

6 Foreword Joseph A. Carchidi

PATHWORKS: PC Integration Software

8 An Overview of the PAIHWORKSProduct Family Alan Abrahams and David A. Low

15 PAIHWORKS for VMS File Server Edward W Bresnahan and Siu Yin Cheng

24 The Development of an OptimizedPAIHWORKS Transport Interface Philip). Wells

31 Design of the PAIHWORKS for ULTRIXFile Server Anthony). Rizzolo, Elizabeth A. Brewer, and Martha A. Chandler

40 DECnet Transport Architecture Mitchell P Lichtenberg and jeffrey R. Curless

47 Microsoft WindowsNetwork Virtual DeviceDrivers in PATHWORKS for DOS Andrew W Nourse

56 eXcursion for Windows: Integrating Two Windowing Systems Dennis G. Giokas and Andrew T. Leskowitz

68 Capacity Modeling of PAIHWORKS Client-Server Workloads Christopher E. Methot I Editor:JsIntroduction

server system on a LAN. However, as Anthony Rizzolo, Beth Brewer, and Martha Chandler explain in their paper, a multiple process model was cho­ sen rather than the single process used in the VMS file server. The authors give their reasons for this different approach as part of a general discussion of the server design and implementation. The network is key to the exchange of data in the PATHWORKS environment, and as is the case for the server software, multivendor systems must be addressed to ensure smooth integration. Mitch Lichtenberg and Jeff Curless describe how Digital Jane C. Blake has extended Microsoft's LA.i\f Manager across a LAN Editor or a WAN by using the DECnet transport protocol as the transport layer. In addition, they present the The integration of personal computers in a net­ reasoning behind the design of the transport com­ work environment is the subject of this issue of the ponent for DOS and OS/2 products, and review Digital Te chnical jo urnal. The software products steps taken to reduce memory usage and improve that bring about this integration are known collec­ performance. tively as PATHWORKS and are derived from Digital's Further details on the integration of DECnet and Personal Computing Systems Architecture. The LAN environments are provided in the paper on two engineering challenge for developers was to inte­ network virtual device drivers for the Microsoft grate a variety of client (PC) and server systems­ Windows environment. As Andy Nourse explains, DOS, Windows, OS/2, Macintosh, VMS, and ULTIUX­ these drivers manage DECnet and NetBIOS opera­ and to ensure that the intricacies of the meshing tions and enable the Windows operating system of these systems remained transparent to PC users. to support peripheral devices, memory resources, In the opening paper, Alan Abrahams and David and software applications. Andy first gives readers Low provide background for the papers that follow background on the Windows operating modes, and by describing the technical aspects of the various then describes the development of the two virtual hardware and software platforms, physical net­ device drivers. works, and protocols that had to be addressed by A significant new application in the PATHW ORKS PATHWORKS developers. They also present an over­ family, called excursion, brings together the capabil­ view of the PATHWORKS components which allow ities of X Windows, DECnet, and the Microsoft envi­ PC users to access network resources. ronment, resulting in the display of both Windows Among the capabilities PATH\VORKS enables, PC and X Windows on the same screen. Dennis Giokas access to files on server systems is one of the most and Andy Leskowitz present the integration philos­ important for users. Two file servers, one for VMS ophy behind the display server and the implemen­ and another for ULTRIX, were developed for this tation of the server architecture. They also relate purpose. A paper on the development of the first of how designers approached the mapping of the win­ these, written by Eel Bresnahan and Siu Yin Cheng, dows in the X and Windows environments. contains an architectural overview of the VMS file The issue concludes with a paper by Chris server. The authors also detail the mapping done to Methot on capacity modeling of PATHWORKS bridge the differences between DOS, OS/2, and VMS client-server workloads. Chris describes a queuing operating systems. In a related paper, Phil Wells analytical model used to understand resource con­ describes performance improvements made in ver­ sumption on the server and the special modeling sion 4.0 of the file server which were achieved by process required in the client-server environment. optimizing the transport interface and the data The paper works through a specific example of the buffering algorithm. He discusses the analysis of model's identification of bottlenecks in the system. server performance for various interface models, The editors thank Star Dargin and Carne! Hoover the implementation of the algorithm in the VlVlS for their help in preparing this issue. server, and test results. Like the VMS file server, the PATHWORKS software for ULTRJX systems integrates PC clients with a

2 Biographies I

Alan Abrahams Alan Abrahams is a consultant engineer in the Personal Com­ puting Systems Group Technical Office. He develops management and security strategies for integrating PCs into enterprise-wide networks. Alan joined Digital in 1982 and designed and implemented the PRO/Communications package. Since 1985, he has been the architect responsible for integrating Microsoft's LAN Manager into Digital's PCSA and helped design Digital's NetBIOS emulation and remote boot of MS-DOS systems. Alan received B.S degrees in computational and statistical science and in mathematics from the University of Liverpool.

Edward W. Bresnahan Senior software engineer Edward Bresnahan has been developing the PATHWORKS for VMS software since joining Digital's PCSG Server Engineering Group in 1988. He is currently responsible for the design and devel­ opment of a high-performance data cache to be used in future PATHWORKS server products. Prior to this, he was a co-op student at General Electric Company and at Charles Stark Draper Laboratory. Ed holds a B.S.C.S. (1988, hon­ ors) from Northeastern University and is pursuing an M.S.C.S. part-time.

ElizabethA. Brewer Beth Brewer is a supervisor in the PCIE Server Develop­ ment Group-Open Systems. Beth served as project leader for the PATHWORKS for ULTRIX version 1.0 product as well as the principal architect and implemen­ tor of the PATHWORKS for ULTRIX administration process. She also worked for the PCIE Client Development Group-PC DECwindows. Beth joined Digital in 1987 after receiving a B.S. in mathematics with a minor in computer science from the University of Massachusetts at Lowell.

Martha A. Chandler A senior software engineer in the PCIE Server Develop­ ment Group-Open Systems, Martha Chandler was project leader for the PATHWORKS for ULTRIX version 1.1 product. She designed and implemented the management interface for the PATHWORKS for ULTRIX server. Prior to this work, Martha maintained M5-Windows terminal emulation for the PCIE Client Develop­ ment Group. Before joining Digital in 1988, she received a B.S. in mathematics with a minor in computer science from the University of Massachusetts at Lowell.

3 Biographies

Siu Yin Cheng Since joining Digital in 1987, Siu Yin Cheng has worked on server software in the Personal Computing Systems Group. As a senior software engineer, she is responsible for the design and development of the server config­ uration utility for future PATHWORKS products. Siu Yin designed and developed the server collector process to extract performance data from the file server; she also worked on server development. Prior to this, she led the system testing of PATHWORKS server V2.0-2.2. Siu Yin received a B.S.C.S (1987, honors) from Brown University.

jeffrey R. Curless As a principal software engineer in the Personal Com­ puting Systems Group, Jeff Curless worked on the OS/2 data link driver and on the PATHWORKS token ring implementation. He is currently developing a new configuration utility to support the future direction of the PATHWORKS product set. Since joining Digital in 1986, he has contributed to the development of PATHWORKS software under both the DOS and OS/2 operating systems. Jeff holds a B.S. in computer science from the University of New Hampshire.

Dennis G. Giokas Dennis Giokas is the group technical lead for PCSG's Net­ work Client Engineering and the engineering manager for its New User Interface Group. His primary responsibility is technical lead for the next generation of the PATHWORKS client. Prior to this work, Dennis contributed to PC DECwindows development. Before joining Digital in 1984, he was employed by Arco Oil & Gas and The Foxboro Company. Dennis holds a B.M. (1974) from the University of Massachusetts at Lowell, an M.M. (1976) from the New England Conservatory, and an M.S.C.S. (1989) from Boston University. He has two patents pending.

Andrew T. Leskowitz A principal software engineer in the PCSG X Server Development Group, Andy Leskowitz is the project leader for the eXcursion display server. Since coming to Digital in 1987, he has contributed to various X development projects and designed the PATI-IWORKS LANSESS component. Andy's prior experience includes engineering positions at Datatrol, The Foxboro Company, and Raytheon Company. He has a B.S. (1976) in biology from Swarthmore College. Andy has applied for a patent related to his X server devel­ opment work.

Mitchell P. Lichtenberg Mitch Lichtenberg is a principal software engineer in the Personal Computing Systems Group. He is responsible for the design and implementation of the PATHWORKS network client transport architecture and for various other aspects of Digital's PATHWORKS PC integration products. Before joining Digital in 1986. he was employed by the Xerox Palo Alto Research Cen­ ter as a software engineer in the Xerox Artificial Intelligence Systems Division. Mitch holds a B.S. (1986) from Worcester Polytechnic Institute.

4 I

David A. Low David Low is a consultant engineer in the Personal Computing Systems Group. Since joining PCSG in 1988, David has worked in a variety of advanced development tasks involving PC networking technology. He is cur­ rently concerned with assessing approaches for pen-based computing and wire­ less PC networking. David has an A.B. in mathematics and an M.A.S. in computer science from Boston University He is a member of AAAS, IEEE, and ACM.

Christopher E. Methot Chris Methot has been analyzing client-server per­ fo rmance since joining Digital in 1986. He has worked in performance charac­ terization of LAVe systems and has contributed to VAX Performance Summaries. Currently, he supervises capacity/performance engineering in the Personal Computing Systems Group. In addition to developing the PATHWORKS client­ server modeling process, his group is developing a standard performance test for Macintosh servers and has benchmarked many of Digital's hardware servers. Chris holds a B.S. (1967) in industrial design from the University of Cincinnati.

AndrewW. Nourse Principal software engineer Andrew Nourse has worked on network software for the PATHWORKS and DECnet-DOS products for the past six years. He developed Microsoft Windows and non-Windows networking applications, libraries, and drivers. Prior to this, he wrote network utilities for DECSYSTEM-20, DECsystem-10, and RSTS/E products. Andy received a B.S. in elec­ tric;il engineering and computer science from the Massachusetts Institute of Technology in 1974 and joined Digital in 1976.

AnthonyJ. Rizzolo A principal software engineer in the PCI E Server Develop­ ment Group-Open Systems, Anthony Rizzolo designed and implemented the PATHWORKS for ULTRIX file server process. He also designed the data link and port driver layers for the PATHWORK S fo r DOS product. Prior to this work, To ny was a member of the Internal Software Support Group and the TOP S-10 Engineer­ ing Group, where he designed and implemented the data link layer for the KLN! Ethernet adapter. To ny joined Digital in 1981. He received a BSE.E. from Stevens Institute of Te chnology.

Philip J. Wells Phil Wells is the PATHWORKS server architect and is responsi­ ble for coordinating the design and implementation of the PATHWORKS server products. In previous positions at Digital, Phil worked for Corporate Tele­ communications designing Digital's internal network, the EASYNET, and helped support data centers and networks while in the Internal Software Services Group. Phil joined Digital in 1976 as a computer operator in the Corporate Data Center.

5 I Foreword

In the 1990s, a major shift is occurring in personal computing, from isolated, individual work on desk­ tops to work in groups whose members are located throughout an enterprise. To support this impor­ tant change, Digital has developed a family of prod­ ucts, called PATHWORKS, that enables personal computer users to make the shift from the stand­ alone machine to the network environment and the resources of larger computer systems. The roots of PATHWORKS were in place as early as 1980. Digital's engineering management recog­ nized that a significant part of the growth in the Joseph A. Carchidi computer industry would be redirected from Group Engineering Manager, minicomputer to microcomputer products. As the PC Integration 80s progressed, we learned from our experience in personal computer hardware development and from the direction taken by the growing and highly competitive microcomputer market that industry standard-based products were more important than unique technologies; that is, open systems, comprising standard devices and interconnects, were what customers wanted, not more propri­ etary systems. Digital's VAXmate personal computer, intro­ duced in 1987, was built on the industry standard model. Moreover, it offered something no other PC offered at that time: the VAXmate had the net­ work built in. With fo resight, engineering manage­ ment determined that our microcomputer business would tie to our long-standing strength in building networks. Our strategy thus changed from a focus on hardware development to the development of microcomputer software. The critical question then asked-and the one that lead to PATH\V'ORKS development within Engi­ neering-was whether to provide customers with an upgrade path similar to those of competitors in the PC LAN business at that time, i.e., file and print services, or a network environment that embraced the primary technologies used by cus­ tomers, i.e., a complete set of networking appli­ cations that included file and print services, mail, X servers, and terminal emulators. The strategy that took hold was the latter; we would develop a broad set of products that recognized customers' invest­ ments in a range of personal computer and net­ work software. Unlike other single-product PC LAN offerings, this set of products would be engineered to couple large server systems based on CISC and RJSCtechnologies with the primary microcomputer systems and would support operation over a local or wide area network. Furthermore, the mapping

6 I between the disparate systems would have to be services on the larger VMS and ULTRJX server transparent to users, and without concessions on systems. Further, a PATHWORKS application, called performance. eXcursion, brings together the X Window System, This chosen strategy, of course, was not the eas­ the Windows environment, and the OECnet net­ ier of the two to implement. One of ourinit ial tasks work. The effect is to link X-so important to users was to select which operating systems to support of UNIX systems-with the PC DOS system environ­ among the many microcomputer operating sys­ ment. These combined efforts represent a hallmark tems available in the market. We decided to define in Digital's progress toward open, heterogeneous the scope of our early development work by sup­ computing. porting the most widely popular personal comput­ Our achievement in the Personal Computing Sys­ ers, which are those based on the DOS, OS/2, and tems Group has been our steady progress toward Macintosh operating systems. Another important providing customers the open computing environ­ decision was the choice of a network transport that ment they need. The breadth of our product offer­ would serve as the basis for the interconnection of ing has taken on clear definition within the last the systems selected. We selected Microsoft's LAN year, and we will now begin the work of adding Manager software as this transport. MS-NET, the depth to the PATHWORKS product set. The possibili­ predecessor to l.AJ'i Manager, had the advantage of ties for future developments are truly astounding. being network transport independent, thus allow­ Looking ahead five years from now, client work­ ing us to utilize the DECnet network to extend the stations will have the power of supercomputers, PC LAN software to a wide area network. and the dramatic progress in parallel computing In the papers in this issue, you will read about will bring additional opportunities for data sharing some of the extensive work that has been accom­ and application developments which are in embry­ plished since we firstembarked upon this software onic stages today. Our challenge in software engi­ effort. Engineers have designed and implemented neering will be to make all these systems work file servers and network transports that allow PCs together in a well-integrated, easy-to-use, well­ to access files, applications, storage, and print deployed computing environment.

7 Alan Abrahams DavidA. Low

An Overview of the PATHWORKS Product Family

As the number of personal co1nputers continues to grow, so does the demand for networking products and services to allow these PCs to share networked resources. Digital:� Personal Computing Systems Architecture enables tbe integration of PCs into Digital's entetprise-uJide network systems. The sojtware products devel­ op ed using this architecture are referred to as the PA1HWURKS product ftmzily P..4THWORKSproducts support a variety of PCplatforms and op erating systems, and accomnwdate different physical networks and transportand service protocols. This flexibilityallows PC users to access resources outside their PC erwironment; such as remoteJiles, printers, da tabases, and electronic mail.

When the IBM Corporation introduced its first of Digital's customers' needs and environments. personal computer in 1981, few could have fore­ PATH\VORKS software products support a variety of seen that by 1992 millions of res would have been PC platforms and operating systems, and accommo­ sold worldwide, radically changing the computer date differentphysical networks and transport and market in the process. The term PC usually implies service protocols. an Intel 80x86 family or a Motorola 68000 series 'Jb help the reader comprehend the scope of the processor, sized to fit under a desk or smaller PATH\VORKS offerings, we begin this paper with a and commonly priced under $5000. The low price basic discussion of PC hardware and software, fol­ has helped to fuel an explosive growth in the lowed by information about the various protocols number of hardware products and software appli­ used in PC networking. We then describe how cations available for PC platforms. PC s are now Digital's PATHWORKS product set allows integration ubiquitous and represent the largest class of net­ of PC s into network systems. worked computers. Even before the introduction of the PC, small PC Hardware computers were being networked together to This section describes the PATHWORKS Intel and share data and hardware resources. In 1990, as Macintosh cl ient platforms and introduces related many as 10 percent of the installed PC:s were net­ PATHWORKS services. worked.1 By 1994, an estimated 75 percent of the increasing number of PCs will be linkcd togcther with products from many networking vendors. Intel Platforms These vendors provide services that commonly The most popular operating systems in the world, include transparent access to remote files, printers, IBM's PC -DOS, Microsoft's \IS-DOS, and Microsoft databases, and electronic mail. Windows, are designed to take advantage of the fe a­ Digital Equipment Corporation is a worldwide tures of the family of Intel chips that includes the leader in networking services. Since 1986, we have 8086, 80286, i386, and i486 microprocessors. been developing the Personal Computing Systems The 80x86 memory architectures have evolved Architecture (PCSA) to meet the growing needs of from 16-bit addressing with implicitly referenced PC cl ient-server applications in local and wicle area 64-kilobyte segments in the 8086 processor, to network systems. Many technical obstaclcs were 32-bit addressing with a paged virtual memory in met and overcome in the design and development the i386 or higher processors. Recent Intel pro­ of PC integration products. The PATH\VORKS prod­ cessors have fe atures previously associated with uct fa mily, derived from PC:SA, reflects the diversity minicomputers. The i486 chip, for example, has

8 v'cJI. 4 No. I Winter 1992 Digital Te chnical journal An 01•en•ieu· of the J>ATfHVORKSProduct Family

an integrated floa ti ng-poin t processor. instruction Network interface cards (NICs) provide access and data caches, ;1nd hardware support for multi­ to local area network (LAN) systems. N1Cs that tasking. This range of processor capacity highlights adhere to ISA, MCA, and EISA standards arc avail­ a major concern of the designers of Digital's able from dozens of manufacturers for many net­ Pi\TJJWOI�KS products. i.e .. how to cfJicienth· accom­ working topologi<:s. Digital m;mufactures NICs mml;l te the range of differing functionality found in for thick, thin, and twisted-pair Ethernet connec­ the installed lntel-has<:d l'Cs. tions. I'ATHWOI{KS products support the Network Although this PC mark<:t has had little de jur<: Datalink Interface Specification (NDIS) and thus regulation, lll.Vt's market presence has shaped the accommodate Ethernet and token ring cards from NDIS de facto int<:rfac<: stamlards. The industry standard other vendors. also permits the use of parallel architecture (!SA) system hus and the video graph­ transport stacks in the PXllfWORKS for DOS and ics :1rray (VCiA) clisplay technologi<:sarc examples of PATHWORKS for OS/2 products. Digital also supplies such standards. NetWare drivers for its DEC: EtherWORKS cards for The most common system bus, the ISA bus, pro­ use on Novell . networks. vid<:s 1()-bit Jata access to a 24-hit (i.e.. 16-megabyte) address space. Physical ami electrical interface con­ Macintosh Platforms ventions have been cstabl ishcd and thousands of The Apple Macintosh l'C embodies an integrated interface boards arc available. m.vt introduced the hardware and software system architecture that has ISA bus and later dcvdopcd the JV!icro Channel not lwen cl oned by competitors and thus has fewer Architectur<: (:viC:t\) bus, which provides :)2-bit data variants than the lntcl-basnl PC:s. Macintosh PC:s use access to a :)2-bit (i.e . -f-gigabyte) address space, the Motorola 68000 series microprocessor. The automatic hus sizing, and accelerated data transkr later versions of these microprocessors proviJe mechanisms. IlK ,V\Ci\ bus is not compatible with :)2-bit operations on a 52-hit address bus, with the !SA bus. ( :onsequcnth', a number of manufactur­ virtual paged memory. Application programmers ers oth<:r than IB:Vl JOined forces and devised the are largely shielded from the underlying hardware extended lSi\ (EIS,\) bus, with features analogous by an extensive operating svstem application pro­ to those of the .w:,\ bus. Even though Digital's PC:s gramming interface (API). use either the JS,\ or EIS,\ bus, we support our cus­ All current Macintosh PC:s are equippeJ with bit­ tomers' ,'viC\ bus machines through software and mapped graphics, sound-generating hardware, a peripheraldcvic<: offerings. desktop bus for k<:yboard aml mouse connection, c;r:1phical us<:r interfaces (CL'Is) such as the one and an Applel�ilk network communications port. provided hy the Microsoft Wimlows software are Some Macintosh PC:s have system buses that permit becoming the rule ra thn than the exception. !liM's peripheral card extensions. All ,\1acintosh PC:s allow color graphics adapH::r (C:Gi\) display was an early communication by means of the AppkTalk family standard at :120 columns h\· 200 rows and a range of protocols over the Loc:1!'fa lk LAN.2 Ethernet/ of 4 colors. VCi\ is a more recent standard, with LocalTalk bridges and routers are available from variants that Gill gencrat<: a screen up to 1024 by several vendors. Digital's PATHWOI�KS product fam­ 76H in 2-)6 colors. There is no widely accepted dis­ ily includes V,VIS Apple'Eilk transport stacks and an play standard beyond VGA. and it ma,· be sufficient AppleTa I k/DEC:net gateway. for manufacturers of innovative displav technolo­ gies to provide device drivers for transparent usc PC Operating Sy stems bv Microsoft Windows applications. For example, Tile PATHWORKS product sct supports several thc l't\TIJW()I\KS eXcursion for Windows display client operating systems, namely .'vJS-DOS, Microsoft server, which implements the X Window System \XIindows, Apple ,VIacintosh, and OS/2, a joint effort protocol and operates in the Microsoft \Vindows of 11\M and Microsoft. environment, uses the display driv<:rs supplied with the \Xiindows software. The eXcur:-;ion s<:rver MS-DOS Operating ,�ystem thus leverages any new di:-;play technologies with Microsoft's ,VIS-DOS (and JBM·s PC-DOS) operating which Windows drivers arc supplied. However, the system evolved as a collection of services for a standalone DOS-bascd :X Window System servers single-tasking, lntel-based PC. In addition to file supplied with the 1',\THWORKS software must be and print services. DOS provides a simple frame­ modified to use a new display technology. work for 1/0, memory management. and other

Dil!,i/(1/ Tecbuic"l.fourual I(>!. 1 -"'· I Winter /'J'-)1 9 PATHWORKS: PC Integration Software

system services. A command line interpreter is used PC Networks to load an application, which may invoke DOS ser­ Even before IBM coined the term PC, microprocessor­ vices or take over various hardware functions on its based machines were using networks to share own. Although DOS is evolving in the direction of expensive hard disks. Sales of networks on which providing a protected virtual machine environ­ PCs act as both servers and clients have under­ ment, applications may bypass or subvert systems gone tremendous growth and have outpaced mini­ services provided by current DOS versions. This computer networks in the last several years. The complicates the design of DOS client systems ser­ most common service offered by PC networks is vices such as PATH\VORKS networking software. transparent access to remote files and printers, which permits PC applications to share resources Microsoft Windows Environment provided by a network server. Microsoft Windows software operates over the The popularity of PC networks has also spawned DOS operating system to provide a protected a variety of distributed applications such as data­ multitasking (nonpreemptive scheduling) virtual base, electronic mail, and group productivity prod­ machine operating environment and a graphical ucts. Most PC client-server applications are simply user interface. Unlike DOS, the Windows environ­ PC applications that simultaneously share files ment imposes severe constraints on application stored on a remote file server. These applications structure and interface design, and on the design of use a fileserver to achieve their distributed nature. system support software such as PATHWORKS net­ PC networks are implemented over more than work drivers. Although much of the success of a dozen underlying physical layers; Digital's the Windows software is due to its ability to mtllti­ PATHWORKS products support Ethernet, token ring task traditional DOS applications, there is a rapidly networks, and asynchronous lines. Al l mini­ growing number of Windows-specific applications computer and mainframe vendors have products that take advantage of the graphical environment, that permit PCs to obtain services from their such as the PATHWORKS eXcursion for Windows enterprise-wide networks. Digital's PATHWORKS server. for VMS and PATHWORKS for ULTRJX products pro­ vide transparent file and print services to DOS, Macintosh Client Software Windows, OS/2, and Macintosh PC clients. PC fi les The fi rst Macintosh client was an integrated multi­ stored on the VMS or ULTRJX operating system may tasking hardware and software system with a be accessed by other PCs or by users of the host well-defined application structure and interface operating system. In addition, PATHWORKS prod­ definition. Subsequent hardware and software ucts provide database access, X Window System development has refined and extended operating support, terminal emulation, electronic mail, and system services. The Macintosh Communications many other services familiar to those in a Digital To olbox, for instance, defines an API that is used environment. by the PATHWORKS Macintosh client to enable As noted above, PC networks use many physi­ Macintosh PCs to participate in a DECnet network. cal networking protocols. In the following sec­ tions, we describe PC transport protocols and the OS/2 Op erating Sy stem application-level service protocols used to encode the remote service primitives. OS/2 was conceived by Microsoft and IRM as a protected-mode operating system. OS/2 software features preemptive multitasking, process threads, Tr ansp ort Protocols interprocess communication, and an extensive Commercial PC networks use a wide variety of GUI. OS/2 provides only limited support for DOS transport and service protocols. Although mini­ applications, partly because of the constraints of computer transports are available to meet some the Intel 80286 microprocessor, and has yet to needs, most vendors have introduced their own to achieve its anticipated popularity. However, OS/2 address concerns such as performance and size, remains a powerful operating system and applica­ which are critical in competitive concerns such as tions development environment, and IBM is address­ performance and code size. ing perceived inadequacies. Digital's PATHWORKS The network basic I/O system (NetBIOS) soft­ fa mily includes OS/2 LAN Manager server and client ware, developed by IBM, defines an interface to a offerings. connection-oriented transport, a connectionless

10 Vo l. 4 No. I Winter JY92 Digital Te chnical jou-rn al An Or,en•ieu• of" the PA TJIW()NKS Fmduct Fa rn ily

datagram service. and a name service API.� In addi­ and provides a tile transfer protocol (FTl') utilitv, a tion to being the Microsoft LAN Manager transport TEl.NET terminal emulator, and a Berkeley Software interface, NetBJOS has become a widely accepted Distribution (BSD)-1 ike socket interface for appl ica­ standard for PC applications communicating tion developers. directly with transports. Many of Digital's customers have extensive Figure l shows that NetBIOS can be implemented DECnet networks. Digital's J>,\TH\XIOJ\KS product by I'C network vendors over a variety of underlying family provides PC clients with ful.l Phase TV end­ transports. J)igital's PATI IWORKS products have node functionality. including tile access listener NetfiiOS interfaces to the DECnet protocol and the (f'AI.), network tile transfer (NFl), command termi­ transmission control protocol/internet protocol nal (CTERM), and network utilities. l'AlHWORKS

(TCP/IP). •> Other popular com mercial transports products also support a NetBIOS implementation incorporating NcrBlOS interfaces are the internet that uses the DECnet protocol as a transport. The packet exchange (IPX). the Xerox Network System PATHWORKS DECnet implementation operates over (XNS), and the NetlliUS extended user interf:lce either an Ethernet or a token ring network and pro­ (NetBHII). Many of these transports also have a vides a llSD-Iike socket interface for application native transport API that allows the application to developers. make use of fe atures not available through the NetWare software from Novell Corporation is a NetBlOS interface. popu Jar family of I'C network services. The internet The TCP/IP protocol family is beginning to packet exchange protocol is Novell's derivative of achieve some visibility in the PC network market. the Xerox internet datagram protocol. JI'X is the At first largely :1ssociated with l!NlX and U!THIX net­ network transport that underlies SPX. a sequenced works and Sun Microsystems· Network File Service reliable protocol. lPX is also used by the NctWare (Nf'S) protocol, TCI�Il' has been lately offered as core protocol , NCI'. Novell also supplies an i mple­ an underlying transport for Nettl!OS in several ven­ mentation of the NetBIOS interface over the ll'X dors· products, including Digital's I'ATH\VORKS fam­ protocol. Digital supports the IPX/SPX protocol on ily. In addition to transparent file and print services, DOS clients through the l'ATHWORKS for NetWare l'C users of TC I'/11' require acc<:ss to a variety of coexistence product. and has announced plans to tools and utilities, such as mail and terminal emula­ integrate NetWare pro tocols into I'AT J-J WOIZKS prod­ tion, which may resemble UNIX or liiTI\lX tools anti ucts in a way that parallels current use of I.AN utilities. Digital's l'ATHWOHKS family has adopted Manager protocols. the approach of maintaining parallel TCP/lP and The AppleTalk fam ily of protocols employed by DECnet implementations, both of which have a Macintosh l'Cs accommodates three hardware lay­ l'C-centric rather than a host-centric orientation. ers: token ring, Ethernet, and J.ocaiTal k. AppleTalk The I'ATHWORKS TCI'/Il' implementation operates includes a datagram delivery protocol. routing and over either an Ethernet or a token ring nenvork, name binding protocols, and several session-level and service protocols. for efficiency, many PC network vendors have APPLICATION invented their own protocols. For example. both I I the IR:\1/Microsoft NetBE ll1 and the :)Com Corpora­ I tion NHI' transport protocols have been optimized N E T BIOS APPLICATION to work on ropologies .r' Digital's PATHWORKS PROGRAM INTERFACE LAN software provides the local area transport (I.Af) and loc:-�1 area system transport (LAST) protocols on several of its client platforms: these protocols are NATIVE TRANSPORT APPLICATION PROGRAM used to access terminal services and lnfoScrver INTERFACE. e.g . . SOCKETS disk services. I I I Service Protocols TRANSPORTS l_____[ I Service protocols encode high-level service requests at the appl icati on layer: these protocols Ngure J Nel/J/OS and Natiue AjJj;/icatio n are often vendor-specific.Ty pically. an appl ic1 tion .. Progmm fllterfa ces issues a standard l/0 request, such as "open file, to

Dif!,ilal Tec buical journal 11!1 . . J .Yo. I Hinter I'.)C)l 11 PATHWORKS: PC Integration Software

a systems interface to ohtain transparent access to a protocol (PAP), which permit transparent file and remote file or print service. The request may be printer redirection. either intercepted (e.g., in Novell's NetWare soft­ Sun's NFS system has widespread multivendor ware on DOS) or channeled through the operating support in UNIX and ULTRIX environments. There system (e.g. , in the Microsoft !.AN Manager or Apple arc a variety of PC products that work over the Macintosh software) to a redirector or shell soft­ IP protocol family to provide file ser\'ices from a ware module that encodes it into a service protocol standard l .. NIX or l JLI'JUX NFS server. packet. The redirector then sends the service request to the local transport. When the response PA THWO RKS Product Fa mily packet arrives from the service provider, the recti­ Commensurate with Digital's role as a network rector interprets the service protocol and provides integrator, the PATHWORKS product family is large the application with the appropriately formatted and diverse. In the following sections we character­ response. The redireetor may also provide an API ize the PATHWORKS family by its client platforms , for access to nontransparent services such as peer­ server pia tforms and services, and physical net­ to-peer communication and management of a works and network protocols. Table 1 shows the remote server. Figure 2 illustrates the role of ser­ history of the PATHWORKS product family. vice protocols in fulfi.Jiing a client request. Since its introduction in 1986, the PATHWORKS The Microsoft LAN Manager redirector software product family has continued to expand the list of (SMB) uses the server message block protocol to client platforms, servers, and transports it sup­ access remote file and print services.- This proto­ ports. The most popular client platforms are Intel­ col may run over multiple transports, each trans­ based and operate under DOS and/or Microsoft port accessed by means of a NetBIOS interface. The Windows. These clients can be serviced by VNJS, rcdirector also provides a client API over the SMU lii.TRJX, and OS/2 servers. The Macintosh clients protocol for many nontransparent services such as can be serviced by VMS servers. peer-to-peer communications via namecl pipes, a The PAT H WORKS product family offers transparent messaging service, and remote server management. file and print services through two technologies: Novell's NetWare software uses the NCP protocol the Microsoft L\N Manager is used for DOS, OS/2, to access remote file and print services. This popu­ and Windows client platforms; AppleS hare is used lar service protocol runs only on the IPX transport fo r �'lac intosh platforms. In add it ion, on DOS and stack. The NetWare shell provides client APis over Windows platforms a dual-service stack approach NCI' for many nontransparent services such as trans­ is used to allow these platforms to access native action tracking, semaphores, ami remote server NetWare services through the PA TH\VORKS for management. NetWare Coexistence product. Table 2 shows how Apple's AppleShare software uses the Applc'Eilk clients and servers can be connected by means of dif­ suite of protocols. These protocols include the fe rent transports. The first column is a list of the sup­ AppleTalk filing protocol (AFP) and printer access ported servers; each eel 1 shows the transports that can be used to com1ect the client and the server. The Macintosh client also supports the DECnet transport. However, tile and print services are only available through the Applt:'l\llk stack. Clients also have access to a number of transport gateways, including AppleTalk-DECnet, X.25, and the System Network Architecture (SNA), the latter two through LOCAL Digital network products. STORAGE The default PATIIWORKS network protocol is the DECnet protocol. TCI'/IP is available as an optional add-on to the base platform. The DECnet protocol allows the user to access the fo llowing services in addition to the transparent file and print services:

• A fu ll set of management tools (e.g., the DECnet network control program for managing the Figure 2 Seruice Protocols transport) .

12 Vo l. 4 No. 1 W'i11ler [<)<)2 Digital Te chnical journal All Ot•erl'ieu· o(the PA '/J-I WONKS /_)roductFa m'l�·

Ta ble 1 Product Histo ry

Area Supported 1986-89 1990 1991

File and Print Service LAN Manager LAN Manager LAN Manager AppleShare AppleShare Server VMS VMS VMS ULTRIX ULTRIX OS/2 OS/2

Transport DEC net DEC net DEC net AppleTalk AppleTalk TCP/I P TCP/IP NetBEUI

Network Ethernet Ethernet Ethernet LocaiTalk LocaiTalk To ken Ring Clients DOS DOS DOS OS/2 Macintosh Macintosh OS/2 Windows 3.0 NetWare Coexistence

Ta ble 2 Clie nt-Server Tra nsports

.------Client Platforms ------, Server Supported DOS Windows OS/2 Macintosh

VMS DEC net DEC net DEC net AppleTalk TCP/I P TCP/I P TCP/I P LAST LAST ULTRIX DEC net DEC net DEC net TCP/I P TCP/IP TCP/IP OS/2 DEC net DECnet DECnet TCP/IP TCP/I P TCP/I P NetBEUI NetBEUI NetBEUI

• The NFT uti I ity for tr:111sferring hies to S\'Stems • Development tools in the fo rm of programming

th:r t <.lo not han:server soft ware . libraries for access to peer-to-pen communica­ tion with remote applications. • A remote disk (as opposed to remote tile)mecha­

n ism on:r the LAST protocol. This mechanism The TU'l'll' protocol allows the user access to the :il lows access to Digita l 's InfoServer products fol lowi ng services in addition to those I is ted above: that support networked CD·HO:VIs. i.e .. read-only optical disks. • The FTI' utility fo r fi le transfer

• ability to use base terminal • DOS Mld \X Iindows terminal emulawrs operating The the emulator to TEI.NET over the I.AT or CTEICVl pmtocols . as well as asyn­ allow operation over

chronous I i nes . The I.AT protocol ma1· also be • The abilitl' to run the DOS-ba�cd X Window u sed to att;rch a local PC printer to a VMS print System server over TCI'/1P as we ll as over the queue. DECnet protocol

• A nos- based X Window System server that allows Every :VI acintosh l'C includes software to access the I'C to act as a display device for !Ylotif or basic file and print services over the AFP. The DI:Cwindow� applications. I'ATH\VORKS i\tlacintosh product family provides low-end • A electronic mail utilitY that provides a those services on server platforms. but also pro­ PC front end to the V,\·IS and l i iTRlX mail systems. vides a set of transport protocols and utilities on

J)ig,ilal Ti ><.·huicu!Joul"ua/ liJI. 1 .\"u. I \�i11ler I'J'J.! l'J PATHWORKS: PC Integration Software

the Macintosh client. In particular, PATHWORKS desktop applications with host system services products supply a DECnet stack with file transfer such as those available with the VMS, Ul:J"R!X, and and managt:ment utilities, a !.AT implementation OS/2 systems. I'Xn JWORKS network software makes and terminal emulator, and an X Window System it possible to develop front-end processors for server implementation that operates over the today's host-based applications and to design new OECnet or an optional TCP/IP stack. The PATHWORKS distributed applications. Hence, PATHWORKS pro<.J­ Macintosh client includes a programming tool for ucts allow the existing computing infrastructure to access to remote databases on Digital platforms. progressively evolve towards a distributed model. The PATi fWORKS OS/2 client provides a LAN Manager redirector and SMB access to basic file References and print services over the DECnet protocol or an 1. B. Baldwin, Local Area Communication Service, optional TCP/IP stack, and a collection of tools and Metric Note LAN 40 (Stamford, CT: Gartner utilities similar to thost: for the PATI IWORKS DOS Group, Inc., December 1991). clienr. Some fe amres, such as an X Window System server, are lacking. 2. G. Sidhu et al., Inside AppleTalk, 2nd eel. In addition to the applications included in tht: (Reading, MA: Addison-We sley, 1990). base PATHWORKS product, the fo llowing client 3. IBM NetBIOS Application Development Guide applications are availabk as layered products: (Armonk, NY: IBM Corporation, Document No.

• eXcursion for Windows, a Microsoft Windows/ S68X-2270-00, 1987). X Window System server application that allows 4. Protocol Standard fo r Ne tB/05 Service on a TCP/ X Window client applications to shan: the PC dis­ UDP Tra nsport: Concepts and Methods, Internet play device with native Windows :1pplications Engineering Task Force RFC 1001 (March 1987).

• x.400 mail, which provides PC front-end access 5. Protocol Standard fo r Ne tB/05 Service on a TCP/ to Digital's X.400 mail server products UDP Tra nsport: JJetailed Sp ecification, Internet • Conferencing, which provides a PC front end to Engineering Task Force RFC 1002 (March 1987) VAXNotes 6. Local Area Network-Te chnical Reference

• Videotex, which provides a PC front end to (Armonk, NY: IBM Corporation, Document No. Digital's Videotex servers SC30-3383-2, November 1988).

• DECquery software, which provilks a PC front 7. X/ Op en Developer's Sp ecification-Protocols fo r end to structural query language (SQL) services X/Open PC lnlerworking: 51'v!B (Reading, U. K.: X/Open Company Limited, Document No. Digital also provides development tools for XO/DEV/91/0lO, 1991). building distributed applications on the PATHWORKS base system. Tht:se ckvclopmcnt tools include database access to a host-based SQI. server by means of the SQL services and distributed trans­ action processing through the DECtp for AC.:VIS product.

Summary The PATHWORKS product fa mily provides direct access to the local and wide area enrerprise envi­ ronment from desktop devices. Clients can access multiple file and print servers, gateways, database servers, transaction processing systems, and elec­ tronic mail systems on a variety of server platforms in a consistent manner from multiple desktop platforms. The snvices provided by the PAT'HWORKS prod­ uct set are the foundation for the integration of

1 4 Vo l. 4 No. 1 Winler /'}')] Digital Te chnicaljounwl Edward W.Br esnahan Siu Yi n Cheng

PATHWORKS for VM S File Server

Tbe mTHI'HJRKS JiJr VIIS file serl'er inteJ.; rates industr;·-standard personal com­ puters zl'ith V,4 X VJJS .1ys tems ouer a communimtions netzmrk. It implements Microsoft 's ser!'er 111essage block (SMB) core protocol. u•hich jJ I'oz•ides resource shc/1'­ ing using a client-serl'er model. The seJ·t•erprot1ides transparent netu·ork access to V,4 X VJ !S Fn£.)� 11 jiles fr om a PCs rw tit'e operating system. The arcbitecture sup­ ports multiple transports to ensure interoperability among all PCs connected on mt op en netzmrk. Due to the jJeJfomumce constraints of JJZClllJ' PC applications, data caching and a I'Ciriet)' of other algorithms and heuristics were e11zplr�J'ed to decrease request response time. Thefile serl'er also implements a security model to prot'ide V:liS securit)' mechanisms to PC users.

Coupled with the PATHWORKS fo r DOS or This paper describes the design and implemen­ PATHWOKKS for OS/2 product, PATHWORKS fo r VMS tation of a nondedicated personal com puter file creates a distributed computing environment, server (PCrS) on a VA,\. VMS computer system. It based on a client-server model. This environment details the PATHWOR KS fo r VMS file system and allows personal computer (PC) users to access v;v1 s discusses its transport layer interface and perfor­ system resources transparently. l'C clients access mance considerations. including data caching the system server from their native operating sys­ effects and disk space allocation. The paper then tems, typically .VIS-DOS, as if it were local to the explains fi le sharing among server processes in a PC. The VAX VMS system resources to be shared, i.e., cluster environment and concludes with a discus­ Jiles or printers, are offered as services over the sion of the server configu ration and management network to PC clients. The computer systems interface. providing the shared resources are referred to as servers: and the PCs requesting the resources as File Server Architecture clients. The SMfl protocol from the Microsoft The file server is implemented as a single, multi­ Networks/OpenNET (1VI S-NET) Archi tecture was threaded, nonblocking detached process with an

chosen to provide fi le sharing from a VA'<.. V,VIS sys­ associated permanent DECnet object. This user­ tem to ;\•IS-DOS and OS/2 cl ients. 1 The SMflpr otocol mode process is privileged and has a high priority. is a command/response appl ication-layer protocol Figure I shows the architecture of the server. Only designed to provide file sharing in a PC network. one file server process exists on any one computer Since SMII is an appl ication-layer protocol, it is to hand le all client requests. An alternative choice transport independent and thus can be imple­ wo uld be to have multiple processes service the mented over heterogeneous networks. clients. 1'he use of a single process reduces system Central to this environment is the file server, the resource requirements and eliminates the latency component that processes the SMII requests to pro­ that is incurred from context switches among the vide file and print sharing along with management multiple server processes. Also eliminated is the functions. The fileserver maps SMllfile req uests to latency that results from process creation at the the appropriate calls for the VAX VMS FILES-1 1 file time a client connects. system interface and honors appl icable security A threads package with multiple independent mechanisms. ;\1S-DOS and VAX VMS systems have dif threads of execution within a single process sup­ ferent file systems ami security models. To integrate ports multiple clients and periodic operations these different environments, mapping policies, within the tile server. The file server creates a along with an architecture appropriate for the VMS thread fo r a cl ient when it requests establishment system, had to be developed ami implemented. of a virtual circuit to the file server. The thread is

So. Di?,ilal Te cbuical jo urua/ l(,f. ·i I lr'i111�1· /')').! l) PATHWORKS: PC Integration Software

� ::::! VMS LOCK VMS FIL MANAGER lSYSTEM �

USER PCFS SERVICE JOB MANAGEMENT AUTHORIZATION DATABASE CONTROLLER INTERFACE FILE DATABASE II I I I PERSONAL COMPUTER FILE SERVER I LAST TCP/IP I I DECNE T I I TOKEN ETHERNET RING

Figure 1 Seruer Architecture

deleted when the client terminates its connections. formed to address the diffe rence between the DOS A client's thread carries out the operation specified and VMS systems can be appliul to support trans­ in the request SMI1 without blocking the process. parent tileaccess from an OS/2 cl ient. With this scheme, processing SMH requests is sychro­ nous wi th respect to the client, yet asynchronous Fi le Na me Mapp ing with rt:spect to the tile server process. DOS and VMS FILES-11 support diffe rent naming syn­ Since a server process may be processing the taxes. DOS supports 8.3 naming fo rmat; that is, the requests of hundreds of clients simultaneously, the file name is composed of a maximum of eight char­ server operates in rea l-time. The threads packagt: acters with a maximum of three characters as the contributes to these go als by providing an envi­ extension. ln contrast, the V.\IS FILES-II file name ronment in which the process never enters a wa it supports 39.39 fo rmat and includes a third compo­ state and a cl ient thread is safe from CPU starvation. nent, the file generation nu mber. In addition, the Prevt:nting the process from blocking is accom­ legal character set fo r a file namt: is larger in DOS plished by performing all file 1/0 asynchronously than it is in the Vi'viSsy stem. and by call ing operating system routines asynchro­ The PAI'HWORKS tilL server does not include a nously when possible. Starvation is prevented by mapping algo rithm to convert a .W :W VMS file nam­ scheduling clients using a nonpreemptive first-in, ing syntax to be accessible to DOS. Any VMS file that first-out (FIFO) schedu ling algorithm. Wi th this pol­ DOS system users need to share must be created icy, a thread executes until it vo luntarily yields, usu­ with a hie name that conforms to DOS 8.3 fo rmat. ai.Iy clue to an 110 operation or an operating system Since the 8.3 naming fo rmat maps directly to the cal I. Csing a nonpreemptive scht:duling algori thm :W.:W fo rmat, no mapping algori thm is re quired to also eliminates the latency that would result from a guarantee a VMS system user access to fi les named thread switch in a pret:mptive environment. by a DOS system user. To overcome the difference in character sets, a PA THWORKS File Sy stem comprehensive mapping algorithm was written to A fileserver needs to provide transparent tile access ensure shareability and transparency. Since nei ther to a VMS fil e system and ensure tile accessibility operating system is case sensitive, the file server between DOS and VMS ust:rs. Since these operating changes the tile name to uppercase before any oper­ systems have different file systems, I'ATH\VO RKS for ation is performed on the file. The legal character VMS must store the files in Wv'X V,\1 S Fli.ES-1 1 fo rmat set for V!VIS FILES-1 1 tik names includes uppercase and provide a mapping algorithm to bridge the alphanumerics, dollar sign, hyphen, and under­ two opera ting systems. Because the OS/2 and DOS score. The character set in DOS inclmks al l noncon­ systems use the same file system, the mappings per- trol characters with the exception of a fe w special

16 11'J/. 4 No. I Winter !<)<).! Digital Te clmicaljournaf flAJH\l/(}NJ\Sjor V, \/S File Sen•er

signs. The J>,\TI IWORKS sern� r maps tile character of the record ma nage ment servict:s (Jni S) protec­ sets based on the fo llowing ru les: tion field for system, owner. and group.

• Al l al n r c ha ra s re ch an e to pha ume i c ctl:r a g d File 0JRtmization uppercase letters: an)· character that is valiu in A DOS tile is o rga n ized as a byte stream, hut a V:-.·IS a V.VlS ti le name is passed through u nch anged. tile is organi1ed as col lections of record s. Although

• All otbcr characters arc changed to t wo under­ t he VMS system supp orts a form of stream tile . most scores. fo llowed by two hex;tdecim;d d igi t s t h a t V,VlS ti les are stored in record for mat. furthermore. represent the ASU ! code of the character being a V.VlS tile wi th a stream record format does not mapp ctl . map directly to a ()OS s trea m fo rmat. This poses an i nteresting problem in integra ting VMS and DOS v,\•IS Fl i.ES- 1 1 allows m u l tipl e 1·e rsi ons of a tile to tilesystems. be gen e r:t t ed ant! stored in a director)·. These ti les Since I'ATIIWORKS soft ware prov ides transparent are id en tified h)· t h e numnic com po ne nt, which access to t he V.VlS host system. a oos c l ie n t views all rcpresenrs t he version number. of a ti le name. ti les on tile serv ices as strea ms of by tes, just as if There is no equ i val en t concept in the DOS system . these fileswere stored loca l 1\·. When t h e server cre­ The l'ATHWOHKS ser ver maps the highest version ates a til e on he half of a I'C, it specifics the tile orga­ (or most rece nt ge neration) ro be accessible to DOS. nization as sequential with st ream recoru fo rmat. Simi larly. the sen·L -r. when c reat in g a ti le on beh a l f Th us. t he by te stream ch arac teris tic of the DOS sys­ of a DOS c l i en t , ge nerates the tile with a Yersion tem is preservetl. I im it of I. ·1 (> p rescr\'e ant! honor the ,·ersi on I i m i t The more complex part of the problem is to inform;t tion for the V:VlS en v i ron m en t . the server resolve the sllarcahil i ty issues bctwc<.:n VMS and preserves the V,VlS tile attributes of pre vi ous ver­ DOS appl i ca tion s The l'AJ'HWORKS server is imple­ sions of t he tile.Conse quently, if the tile is created mented to prov ide the necessary conve rs ion by a V.VIS user. and is later u pd a ted by a DOS user. a between V.\·IS and DOS tile organization on stream new version of tl1C tile is genera ted . and the version tiles. The ti le server views a tile as sl re am if it can limit inform;t tiun is pre.�en'Cd. read and wri te the tile without rega rd to any rccor(i bounda ries. This includc::s any ti les with till' orga ni­ Directory Mapping zation as se q uenti a l ami recortl r·ormat as stream. V.VIS The system re quires a din:ct orv name to end stream cr. stream lt. and undehnnl. as wel l as DOS with "dir" as an extension. [)ut the system does tix<.:tl . If a seque ntial tilehas tixed record format, it l'ATHWORKS not post am· restriction in this area. must conform to record si1e ;md attributes as fol­ DOS maps d i rectory names in by in cl ud i ng the lows: cvc:: n with no record attribu te: 512 with no . . . ext" ch;�r;tctcrs as part of a d ircc to n· name. Since block_span : and power of 2 with no b lo ck_spa n . DOS the peri od is not a il'gal character fo r a tl i rcc­ Th us , an R.VI S overhead in reading allCI wri t i ng tiles<.: tory. i t is ma pped using the d ou ble underscore fol­ tiles is avoided. lowed by the hcxatkcimal d igi t ruk. Any directory Any tile that do cs nor meet the cri teria of the DOS V.VlS o na me in tha t conforms to the d irect ry s t rea m category is said to be nonstrea m. The naming synux is passed th rough u nt ou ched . l'ATHWORKS serve r provides read-only access to an y VMS n o ns t rea m tile. This is achieved by using a VAX DO"i File Attribu te Mapp ing C run-time librarY call that provides stream lile Both ti le systems associ a t e a set of at t r i but es to the semantics and a conversion algorithm to properly ti l es. but t ile tilea tt ri bu tes on a DOS tile do not have map any carriage re turn and I ine ked information. a one-to-one correspondence with those on a VMS The ti ll' server cannot su pport wri ting to these tiles tile. A DOS ti le h;ts four types of tile a t t ri butes: because t he SMU protocol does not pre serve record archi1·e. system. hi dde n . a nd rea d- on l y. The con­ boundan· information. Thus. th e protocol makes cepts of archive. system. and hidtlen arc not recog­ it imposs i bl e for the tile server to gua rant ee data nilul in th e V\·IS ti ll' system. [',\lHWORKS software i ntegrit y wh en upda t i ng a no n strca m tile. sto res the DOS ti l e attributes in an a ppl ica t io n access control entry when cre:a ing a ti le on be ha l f J�vte Ra nge locleing of a I'C worksta t io n . rurrhermore. the reatl-only The :VI S-I ET arch i tectu re allows for concurren t a t tri bute of a DOS lilc is mapped to the read-emil· hit access to se rver-based tiles by mul t ip le clients. PC

Di,f!, ilal JechuicaiJourual tf•l. 1 .\'u. I 1\"in./er /'.J'.Jl 17 PATHWORKS: PC Integration Software

applications acquire this fu nctionality through the By conforming to this specification, transports can MS-DOS byte range locking calls. These calls allow be added to a server platform without upgrading or PC applications to lock and unlock ranges of bytes changing the existing file server. in a file and to detect conflicts. Conflicts occur The performance goals of the file server had when part or all of a range specified to be locked an impact on the development of the transport has been locked from a previous call. In contrast, Layer interface. The fileserver utilizes an optimized the approach taken by RMSprovides locking on a transport layer interfa ce that reduces buffe r copies record basis. RMS uses the VMS distributed lock and eliminates some of the standard VMS 1!0 paths. manager to implement this fu nctionality. Unfortu­ This optimized interface is used with the LAST trans­ nately, the lock manager is not well suited to imple­ port and is described in detail in "The Development menting byte range locks because the byte range is of an Optimized PATHWOR.KS Transport Interface" represented in a form that allows the lock manager paper in this issue.2 to arbitrate access. Therefore, the file server imple­

ments its own lock database and arbitrates access Pe iformance Considerations to shared files. Internally, the server process main­ Achieving an acceptable level of performance from tains a list of locks for each file the server has open a nondedicated file server layered on a general­ and arbitrates access based on these Lock struc­ purpose operating system proved to be a chal leng­ tures. Files opened by the file server cannot be ing task. One of the performance goals for the file shared with other VMS processes because the file server was that it perform tasks within 10 to 20 per­ server has an exclusive mode lock on each file it has cent of the speed of a dedicated PC file server run­ open through the VMS lock manager. The exclusive ning on a similarly sized CPU performing the same mode lock guarantees protection from other VMS tasks. This goal was achieved by employing a variety processes. of caches, algorithms, and heuristics. Many of these heuristics were based on the analysis of the SMB Op en Mode Mapp ing messages passed between the server and the client The DOS file system defines open access modes to for typical PC applications. As discussed in this sec­ allow applications to synchronize shared access to tion, the response time of the server is improved if a file. The open modes are deny_none, deny_read, the memory contains the information necessary to deny_write, deny_read_ wri te, and compatibility. satisfy a request when it arrives. Each provides a different level of file sharing capa­ bility.Although these modes do not map directly to Data Ca ching the VMS file system, no mapping is needed to han­ An obvious approach to implementing the read and dle the diffe rences. write functions in the file server is to issue these The PATHWORKS server opens a file that is being operations to the FILES-11 file system, wait for their accessed by a client with exclusive access on the completion, and then send a response to the client. VMS system. It assumes the responsibility to arbi­ This method is simple and persistent, but does not trate shared access among multiple clients. The perform well due to the bottleneck formed at the server supports DOS open access modes by imple­ FILES-1 1 interface and disk. The file server imple­ menting the shared access resolution algori thm ments a software wrire-behind data cache to described in the SMB protocol specification. reduce this bottleneck and to eliminate waiting for disk writes to complete before returning a PAIHWORKS Tra nsport Layer response to the client. Caching is a technique used Inteiface to decrease access time to information by using a The PATHWORKS for VMS product supports multiple faster intermediate medium to store the most com­ transports through a common transport layer inter­ monly accessed pieces of information. The caching face. These include the local area system transport algorithm implemented by the server is a logical (LAST), the transmission control protocol/internet block cache. The cache is a region of memory that protocol (TCP/IP), and the DECnet transport proto­ is segmented into fixed-sized buffers. Each file col over Ethernet and token ring networks. This opened by the server has a dynamic set of buffe rs well-defined, uniform mechanism dynamically that increase and decrease based on a least recently adds support for network transports and protocols. used (LRU) algorithm.

18 Vo l. 4 No. I Winter1992 Digital Te chnical jo urnal PAT!-fWORKS j(J r VJ. HS Fi/e Sert1er

hJ/ects on Clie1zt Read Requests Altl10ugh this is interval; (2) when a .tile is closed: ()) when the an optimal environment for servicing read ratio of dirty to free cache buffers reaches a requests. reserving data in memory to satisfy a II user-contigurable threshold: ami (4) when cache reacl requests is not practical. A number of mecha­ buffers are not available to support the current nisms were implemented to approach the ideal. request. The data CJchc retains recently accessed data in On the V,VJS system, IZ.\'IS also employs a write­ memory with the expectation that it will be refer­ behind algorithm similar to the one used by the .tile enced again soon. This is based on the concept of server. !�:VIS is not used by the .tile server for disk locality of reference. both spatial and temporal. reads and disk writes for performance reasons. The Once the server receives a read request, it deter­ crossing of the VMS architectural boundary that mines if the buffers associated with the read occurs during RMS calls acids an unacceptable request arc in the cache by using a hashing algo­ amount of processing time to the read ami write rithm for the lookup fu nction. If the data to satisfy paths. The .tile server uses the VMS queued I/O the read rurucst is in memory, it is immediately (QIO)/cxtcnded QJO processor (XQP) interface, returned to t he client, and the ti le system access is which is below the R,VI S layer, to read and write data eliminated. lfsome of the data nccclc<.l to sa tisfy the to disk. request is not in the cache, then reads are started on each of the cache buffers needed to satisfy the Disk Sp ace Allocation request. Once all data is read into cache memory, a Sufficient disk space must be available for any response is fo rmed and returned to the cl ient. ·write operation that is performed as a background operation. To allow sufficient space, any disk allo­ T;jfects Client Write l?equests When the server on cation must be completed when the write request receives a client write request, three processes are is received. This restriction slows down write oper­ performed. The cache buffers needed for the ations which, in turn, resu lts in ti le expansion. specified write range arc located. the client data is Performance testing in this area shows that such copied to the cache buffers, and a response is sent expansion operations can reduce the server's to the cl ient. The data copied to the cache response time in the overall operating environ­ is written to the disk at a later time. This write­ ment. To al leviate this problem, the I'ATHWORKS behind scheme allows write requests to be ser­ server preallocates a tixed amount of disk space, viced quick!�· because the response is returned to often much greater than required, to complete the the client before the write to disk completes. By not current write request, in anticipation of further synchronizing on-disk write completions before file expansion. Th is mechanism greatly reduces returninga response, the turnaround time of client the system overhead incurred in disk allocation: write requests is grc-atly reduced. The cache is also thus it improves the overall response time to write optimized when a cl icnt write request is received operations. and a disk read opera tion is in progress for the ra nge. In this case, the data being written to the cache is copied into an intermediate buffer and Read Ahead merged with the data from disk after the read oper­ Another mechanism used by the ti le server to ation completes. These intermediate bufkrs are improve the turnaround time of read requests is known as ghost buffe rs. since they are not visible read ahead. As with data caching. the goal is to from the buffe r hash table. increase the probability that data referenced in the near fu ture will be in the cache. Retd ahead is the Wr iting Dolo to Dis/� Sinct: tht:ti le server acknowl­ process of prcfetclling previously unreterenccd edges write requests before performing the write (lata from the (i isk into the cache. Data is pre­ operation, a mechanism is needed to write the fetched into cache memory under several comli­ cache buffers to disk an(! ensure data integrity. tions. When a ti le is opened , the first two cache The .tile server implements a permanent thread, buffe rs of the data are read from the disk into the the tlush thread, dnlicatnl to this task. The tl ush cache. Data is also prefetched when the server thread starts disk wri te operations on buffers that detects that the tile is being accessed sequentially. contain modified data. fl ushing data to disk occurs The SM il protocol also supports re;l(i ahead. The (1) periodicallr, based on a user-con.tigurable protocol provides a field in the read request that

DiJ!,ilal Te e/mica/jo unwl ll1/. ·i .\'o. I H.. inler /')')2 19 PATHWORKS: PC Integration Software

specifies the amount of data that the client intends network traffic,es pecially for very fastcl ients. The to read in the fu ture. This advisory field is used server also has to spend a significant amount of by the server to initiate prefctches. time processing these numerous lock requests. The server attempts to regulate this lock traff-ic and Directory Search-ahead Cache reduce its lock processing time by deferring the A DOS directory operation can translate to multiple return of the response when a lock conflict is exchanges of request ami response operations detected. If a request to lock a range conflicts between the server and client. This behavior is with a previous lock. the server makes repeated inherent to the SMB protocol definition. The file attempts to access the range using a pseudorandom server initiates a search-ahead thread when the first exponential back-off algorithm to determine the request is received. While the PC is processing the retry interval. If the lock conflict is not resolved first response, the search-ahead thread accumu­ after a user-eonfi.gurable time period, the server lates din::·ctory information in a circular buffer. returns a response indicating a lock conflict. By Thus, this information is available in memory for deferring this response to the client, the server subsequent requests. exercises flow control over clients spinning on locked regions of the file. The implementation of Op en-file Ca che the pseudorandom exponential back-off algorithm Operations, such as create, open, and close, impact prevents the server from using an excessive performance in the V.\1S system. Benchmark tests amount of CPU time to determine if the locked byte show that these operations become blocking fa c­ range has been unlocked. tors for a fast performance server. This problem is compounded by the inherent behavior of many PC Security applications because they often use the result of The VMS operating system offe rs a well-defined an open operation as a deterministic tool on file security architecture, but DOS has no comparable accessibility. Frequently, files are opened and security scheme. Since the PATHWORKS file server is closed and reopened in consecutive requests. To implemented as a privileged process, it is necessary minimize the overhead incurred for these opera­ to control file access on the VMS host system from a tions, the PATHWORKS server implements a cache to DOS client. There is no one-to-one correspondence store opened file information. This open-file cache between a DOS user and a VMS user. That is, in the maintains the fi le header information after the file l'ATHWORKS environment, each network client, has been closed by the user for a short duralion. If a much like a terminal in this respect, can be multi­ user requests to open a file that is already cached, ple VMS users. The problem is to ensure maximum no request to VMS FILES-1 1 system is required. This shareabilitv among PC clients and maintain the greatly reduces the response time of the server on desired level of VMS security. the second open request. The PATHWORKS file server implements two Furthermore, many DOS database applications types of securities: share and user. It makes use of use index tiles to synchronize data access. These the PCFSSSERVICE_DATABASE to control access to a files are frequently accessed by many DOS users share area; and the VMS user authorization file (UAF) when working in an networked office environ­ database to control access to directories and files ment. Open-file caching is beneficial to this envi­ based on a VMS user account. A share, referred to ronment because it incurs a minimal amount of as file service, is a VMS directory that can be open requests to the V.\1S tile system. accessed by PATHWORKS clients. PATHWORKS soft­ ware defines three types of file services: system/ By te Range Locking Back-offAlgo rithm applicat ion, common, and personal. Access to fi le The file server implements an algorithm to improve services is based on VMS user account information. overall performance of the server and network A privileged system manager must explicitly grant when PC applications are sharing files and using user access to system/application and common ser­ byte range locking to arbitrate access. The analysis vices. The system manager must also specify the of many networked PC database applications types of access: read, write, or create. This infor­ revealed that a client typically entered a tight retry mation is stored in the PCFS$SERVICI'_DATABASE. loop when it detected a lock conflict. This spinning Access to personal service is implicit with the exis­ produces an exces�ive amount of lock-related tence of a user account.

20 V!J/. 4 No. I Winter I'J'J2 Digital Te cbnical jo urnal PA T!-fWORKS j(Jr VIIS File Serl'er

To provide maximum shareability among PC take place. When a break-in is tletectnl , tile server cl ients, P,\Tl-1\VOI\KS software includes a default takes the appropriate evasive action ami signals the user account. When accessing a fikserv ice that has condition in the sen·er log tile. been granted to the default account, each PC assumes the identity of the defau lt account. Thus Printing Support the access. though it might be issued by different PC The server process also implements the printing users, is viewed as the same user. This mechanism functionalitv specified in the S.\'l ll protocol. The file provides a "share level" of security. server implements the print-related commands A more restrictive environment is achieved by by using SSNDJBC ami Sc; LTQl ll system services to provkl ing access to a share area ])ased on individual communicate with the V:'I·IS job cont roller. Each user account. \V hen a PC client establishes access print service available to clients has a V:VIS print to a service, it presents a user account ami its corn:­ queue associated with it. sponding password . This information is authenti­ The V:VIS system has a much richer printing envi­ cated base<.l on information returned by the ronment than the one provitlctl to the PC: clients sysSgetuai svstcm service call. The PATI-1\VORKS through the S,\IB protocol. The !'AT! I WORKS server server then verifies that this user has been granted provides VMS printing re aturcs to the clients by access to the service. extending the SMB protocol to accommodate Access to a fileservice tlocs not necessarily imply l'Afi-IWOH.KS neccls. These protocol extensions access to any individual files. In order to preserve are described in the section Digital Protocol the desired level of V,VI S security, PATII\VORKS Extensions. honors ;1ccess control entries. The server ensures access to a share area as defined in the database File Sharing among Server Processes bv maJ)j)ing the access types to two identifiers: Each node on a VA-"'\cluster system em be a host for pcfsSrcad ami pcfsSupdatc. Thcse identitiers are the PATI-1\VORKS server process. One of the more added to the root directory of a share area, and to challenging problems in su pporting VA Xcluster any tiles that arc created. when appropriate. As the systems is the synchronization of tile access by server impersonates the user, the appropriate iden­ multiple server processes. As stated earlier. the tifier is associated when access privilege to tiles and PATI-1\VORKS filese rver requires exclusive access to director\· is checked. This security implementation tiles that are opened by PC:s in order to support byte is not applicable when servicing a personal area. range locking in DOS. Furthermore, in a cluster, Access to tiles stored in a persona l area is based on each server process needs the ability to provide ICVIS protections mask. identical access to the same resources. 'H> case system management tasks, l'ATHWORKS l'ATHWORKS software implements its own lock software implements "group" support. A group is management algorithm to resolve file access a collection of users. A PATHWOI�KS group has conllicts in a VAXcluster svstem. Although multiple no depemlcncv on user group identification code. server processes arc allowed in the nwi ronment, When a share is granted to a group, each member only one process can handle the requests to a tile of the group gains access. Note that authentication that is accessed by l'C clients. By using the VS'IS lock is st ill performed based on an individual user manager, the server process that services the tirst account. open request acquires an exclusive mode lock on Since a DOS client can gain access to the V1v!S the tile. It thus becomes the master of the fileand is environment. it is imperatiH' that the tile server responsible for svnchronizing access requests to support the V.VIS system's break-in evasion mecha­ the tile. When a server process is requested to ser­ nism . The server honors the login-related system vice a tile that has another l'ATI IWORK� server as its parameters. These parameters are read at the tile master, it makes a network connection to the mas­ server start-up, ami the values arc in effect for the ter process and forwards the requests. This process Juration of the server process. The server tall ies serves as the routing agent It communicates both any failed or unsuccessful login attempts. \V hen the requests and responses between the master server tile server receives a connection (login) request to process and the PC cl ient. The master releases own­ service, the Jile server extracts the re lated counter ership when no outstanding open tile hand lcs are information from the l :At ami adds it to its internal on the ftle. file mastering is cstabl ished on a per counter to determine whether evasive action is to ti le basis.

Di;;; ital Ti>e lm ica/.fourua/ ! iJ/. i \o. I !linter I'J'J.! 21 PAT HWO R.KS: PC Integration Software

The rerouting mechanism uses the DECnet trans­ interface or a command line interface. The port because its existence on the remote server PCSA_MA!'\JAGER utility allows system administra­ host is guaranteed in a cluster environment. To min­ tors to manage the following objects: users, ser­ imize the number of required DECnet sessions, the vices, print queues, logical user groups, the event routing agent fu nnels all forwarding SMBs through logger, and the server process. The file server uses an existing session. The forwarding packets include interfaces supported by VMS to manipulate VMS information that the master process can use to dif­ specific databases, private interfaces to access ferentiate among the clients' access requests. PATHWORKS specific databases, and SMB protocol extensions to interact with a server process. PATHWORKS Server Configuration The multithreaded PATHWORKS file server can be Digital Protocol Extensions considered a small operating system in which each Management of a running server requires a method PC is a process (or a thread). In addition to the basic to send and receive well-definedmessages between resource requirement that the server be activated, the server and other processes. The PCSA_MANAGER the server requires a set of process resources to utility sends a management request to the server; support each client thread. These resources can be the server processes it, and sends an appropriate mapped to VMS process parameters which, in turn, response back to the PCSA_MANAGER. The commu­ translate into system parameters. nication channel used for server management is a The amount of VMS system resources which the DECnet logical link. The PCSA_MANAGER issues a fileserver consumes is a function of the number of connection request to the DECnet object associated clients and the workload generated by the individ­ with the fileserver process. The file server receives ual PC. Mapping the PC resource requirement to the this request and creates a virtual circuit with a cor­ appropriate VMS process and system parameters responding thread to process requests for this man­ proves to be a complex problem. Since the PC work­ agement session. This is similar to a client session. load profile is unknown at the time of server initial­ Since the SMB protocol does not provide com­ ization, the amount of required system resources mands sufficient to manage a PATHWORKS server, a for the server process can only be estimated. Digital proprietary protocol was developed to pro­ PATHWORKS system managers include users with vide this functionality This protocol is merely an little VMS system management experience. The extension of the SMB core protocol; that is, the mes­ level of VMS system expertise required to configure sages developed for server management have valid (or set up) a PATHWORKS server is minimized by SMB headers with command codes that are mean­ the addition of a "configurator." This part of the ingful only to a PATHWORKS server. This implemen­ management functionality is implemented to gen­ tation allows remote management of the file server. erate information on required system and process To manage a server, a management utility only has resources when the desired configuration is sup­ to establish a virtual circuit and exchange these plied. During the server start-up phase, the extended SMBs. Protocol extensions are also used to configurator checks for availability of necessary integrate the VMS print system with PATHWORKS resources and provides appropriate run-time clients, along with other PATHWORKS specific parameters for the launching of the server process. utilities.

Management Inteiface Event Logging To provide integration between different file sys­ The PATH\VORKS server includes an event logging tems, the file server utilizes PATH\VORKS specific mechanism to provide an error and event reporting databases (such as the service database), standard facility to assist system management. Events are cat­ VMS databases (such as the UAF and DECnet data­ egorized based on server operations, including bases), and VMS security mechanisms. These enti­ errors, protocols, security, management, and file­ ties must work in harmony and be consistent with related functions (open/close, read/write). The each other to provide the desired integration. The server uses an event code to determine whether a PCSA_!VIANAGER utility was designed to manage given event is to be recorded. A Digital extended this environment. It allows users to perform all SMB command toggles these event codes dynami­ management tasks related to PATH\'VO RKS software cally. The event messages are logged to the file through one utility from a menu-driven user server log file. The overhead is minimized by each-

22 Vo l. 4 No. I Winter 1992 Digital Te clmicaljournal PA l J-1WONKS jor VJIIJS tile Sen •er

ing the event messages in a clara buffer, which is PATHWORKS for VNlS file server. We specifically periodically written out to the log tik. A thread is acknowledge Robert Praetorius for his contribu­ created at server start -up to handle the log lile tion in the design and implemenration of the cache update fu nction. The scheduling of this thread component, Phil Wells for his design and imple­ is based on a time interval, with a default value of mentation of the netwod: interface and transport ()() seconds. support, and Jon Campbell for his design and implement ation of the network interface. We also Summary acknowledge Frank Caccavale for his work on per­ fo rmance analysis, AJ an Abrahams for his direction The l'AlliWORKS for Vt'v!S ti le server integra tes the as architect, ami Mark Olson for his leadership of DOS, OS/2, and V.viS opera ting system environ­ the PATH WORKS for VMS proj ect. ments on a network. The server architecture ach ieves transparent integration of PCs connected References on an open network over multiple transports. Data caching, algorithms, and heuristics were used to 1. X/Open Det,elojJer�\- �jn!C ification-Protocols increase performance. The PATHWORKS for VMS fo r X/Open PC fnlertl'Orking: S, l/n (Heading, l!K.: fi le server provides PC users with access to the VMS X/Open Company Limited, Document No. XO/DEV/91/010. 1991 ) system's resources and security environment.

2. P J We lls, "The Development of an Optimized Acknowledgments PATHWORKS Transport Interface," Digital We thank the people, past and present, who con­ Te c!J nica!Joumal, vol. 4, no. 1 (Winter 1992, this tributed to the design and development of the issue): 24-;)0.

Di[!.ilalTe chnical jounwl I 'o f. ci .Vo. I V. inter !')')] 2:) Philip J. Wells I

The Development of an Op timized PATHWORKS Tr ansport In terface

Digital's Personal Computing Systems Group developed an op timized transport interface to improve tbe pe1jimmmce of the PA THWORKS for VIIS oersion /i. O senJeJ: Th e development process involl!ed selecting a transport protocol, desiguing appro­ priate intei.face test scenarios, and measuring server perfomwnce for each trans­ port interj'ace model. The engineering team then implemented the optimized design in the server and performed benchmark testing for sp ecified server workloads. Us ing an optimized transport inlelfa ce improved server performance by decreasing the time required to complete the test while maintaining or decreasing the percent CPli utilization.

The PATHWORKS fa mily of network integration soft­ SERVER ware products incl udes fi le servers tb;tt provide KERNEL PROCESS SERVICE CONTEXT file and print services to personal computers in INTERFACE � local area networks (LANs). Developed by the Personal Computing Systems Group (PCSG), the PAT HWORKS for VMS version 4.0 server supports the SYSTEM CONTEXT Microsoft LANMa nager network operating system. This server allows PC clients transparent access TRANSPORT to remote ViYIS tiles. With each new release of the PATH WORKS for \'�IS product, the PCSG engineer­ ing team improved server performance and thus Figure 1 Data Copy witiJa Bttjfe red 1/0 accommodated an increasing number of time­ Intetfa ce critical PC applications. In version 2.0, we intro­ duced disk services as an alternative to file services for read-only tiles. We included data caching in ver­ Prior analysis of PATHWORKS server performance sion 3.0 of our J'ile server. over the DECnet transport protocol revealed that For version 4.0, our goal was to increas<.: file when the file server request sizes were large, i.e., server perfo rmance by optimizing the transport 4 to 8 kilobytes (KH), file server performance mer interface and the data buffering algorithm. To or exceeded the performance of other vendors' achieve this goal, we evaluated several transport transports. However, when the transfer sizes were interface designs and measured server perfor­ small, i.e., Jess than 256 bytes, file server perfor­ mance for various server workloads. \Ve started mance degraded significantly. Also with small with the premise that using the standard buffered request sizes, our server did not ramp well when interface results in incn.:ased overhead for each many clients were supported in this environment. transaction and thus decreases overall CPU avail­ As illustrated in Figure 2, incremental increases in ability. Figure I illustrates this interface design. server workload cause dramatic increases in CPU The server copies a user data buffe r in process con­ utilization once a certain workload is reached, i.e., text across the kernel service intnface to a system at the knees of the curves, denoted by points A and buffe r in system context, before transferring the B. We wanted our server performance to approach data to the network layer. that represented by the curve containing point B.

24 VrJ/. 4 1\o. 1 V? illl£!1' J'}').l Digital Te cbuical jo unwl 7/Je Det'elopment of' an Op tintized PA TJJW()}(KS lmnsj}()rt Interface

BUFFER DESCRIPTORS

z Q f-­ <( N :::; f= :::J :::J M o_ u

DATA BUFFERS A B SERVER WORKLOAD

Figure :) L4STDRJ VflR Buffering Model

F(f!,llre ..! CJ>U l !tilizafir)// as a Function o(Ser!'er \Jl!iJk/oad passed to LASTDRIVER as a single message. The second buffer descriptor contains a zero in the

In this wa\', we could suppon more cl ients at the next butler descriptor pointer word . This value same or less C:l'l l utiliza tion. indicates the end of the data stream.

Server Per:formance Analysis Te st Scenarios After selecting the LAST transport protocol, we cre­ We based our analysis of i'J\T!-1\VOI{KS server perfor­ ated four tcst scenarios to measure server per­ mance on two initial hypotheses: fo rmance. The first scenario. thc kernel model, • The C:PI r 0\ erhead associ a ted with a buffe red required dcvel.oping a VMS device driver that was interface signiticantlv llegrades the performance layered on top of LASTDRIVER. In this model, when of the server. thc clrivcr receives request data. the data is immedi­ ately transmitted hack to the cl ient. The driver does • The variable transaction response times inher­ ent in using the standard queuell r;o (QIO) inter­ not copy buffe rs and does not schedule a process. face resu lts in inefticient �erver performance. This model represents the optimum in pcrfor­ mancc. bccause absolutely no work is performed in Protocol Selection relation to the request. The second test scenario required that we 'l(l begin our performance analysis. we needed to develop a user-mode tcst program. This model per­ choose a transport protocol \Ve considered the fo rms similarly to the kernel model in that it loops DEC:net and the local area system transport (LAST) receive data directly back to the clienr withou t per­ protocols ami selected the LAST protocol for the forming any copy operations. This modcl differs fo llowing reasons: from the first model in that the driver schedules a

• An advanced development effort on the DOS VMS process to loop the data back to the clicnt. We client software showed that tile and print ser­ then developed the fo llowing variations on this test vices over the LAST protocol decrease the client scenario to accommodate three transport inter­ memory usage by one-third . faccs to the VMS process. Thc second and third sce­ narios represent optimized transport interfaccs • The 1',\TH\VOI{KS engineering team maintains the with regards to two aspects of a request: the initial­ L\.ST protocol ami thus. can make.: any rcquircd ization and the completion. modilicat ions.

• A standanl V.VIS QIO interface model. This model • The V.VJ S opera ting system implementation of uses the standard interface provided with the the L\ST transport protocol is cl!lcd LASTDI{IVER. VMS operating system. L\STDIUVER serves our purpose because it pre­

sents a buffering model that permits the passing • A model that incorporates the standard V.VIS QIO of multiple.: noncontiguous data buffc rs as a sin­ interface with a process wake-up completion gle. logically contiguous buffe r. figure :\ shows notification. This QIO/WAKE model uses the stan­ two pll\ sical data buffers. of sizes Nand M. being dard QIO intcrfacc to initiate a transport request.

Digital Te cbuical Jo urnal I (,f. i .\u I \1 iuter /'}').2 2') PATHWORKS: PC Integration Software

However, the transport queues I/O completion notification directly to the receiving process by means of a sharecl queue and a process wake-up b-----d request. The purpose of this optimization was to ��:�: ] avoid the standard postprocessing routines of OFFSET the VMS operating system. SYSTEM • A model that includes kernel mode initializa­ VIRTUAL ADDRESS �----� tion and wake-up completion notification. This CMKRNL/WA KE model uses the transport com­ pletion technique of the previously described model. However, we created an entry point into Figure 5 Vi rtual Address Sp ace the driver for the test program to call, thereby initiating transport requests. The test program Peiformance Measurements uses the change-mode-to-kernel (CMKR:\IL) sys­ Our hardware platform was a VAX.station 3100 work­ tem service to call the driver entry point. This station. We measured server performance as the optimization was made to avoid the standard diffe rence between the request arrival time and QIO interfaces. the response departure time, as observed on the To support the optimized transport interfaces. Ethernet. Times were measured in milliseconds the test program allocates a buffer in process con­ using a Network General Sniffe r. Ta ble 1 presents text and divides it into two sections: the first con­ the test results. tains shared queues for moving data between As Ta ble l shows, we decreased server response process context and system context; the second time by using an optimized transport interface. The contains the test program's shared data buffe rs. The kernel model yields the best possible performance driver issues a call to the system to double map results. As we move from the standard VMS QIO the shared buffer into system context. Figure 4 interface to more optimized interfaces, there is a shows this double-mapped buffer. Since the buffe r decrease in transaction response time which repre­ is contiguous, the diffe rence between the start of sents improved server performance. the shared data region in process context and the Data collected during initial performance testing start of the shared region in system context is a con­ supported our decision to optimize the transport stant, and is used as an offset. The test program interface. Occasionally while testing the interfaces, accesses the shared region by using a process vir­ server throughput dropped dramatically, i.e., 30 to 50 percent, for a short time interval, i.e., one to tual address (PYA); device drivers access the region two seconds, and then resumed at its prior rate. by adding the offset to the PYA to compute a system virtual address (SVA), as shown in Figure 5. To Initially, we thought there was a problem with our accomplish completion notification, the driver code. However, the anomaly persisted throughout inserts the data into the shared queue and issues a the development period, so we decided to investi­ process wake-up request for the test program. gate the cause of the clip in performance. The VA.""Xstation 3100 system that we used to per­ form the testing had a graphics controller card PROCESS SYSTEM CONTEXT CONTEXT installed, but did not include the graphics monitor. BUFFER BUFFER

SHARE[) Ta ble 1 Server Performance over QUEUES Va rious Interfaces

SHARED DATA Server Performance BUFFERS Interface (milliseconds)

Kernel Model 0.8 Standard VMS QlO Model 2.2 QlO/WAKE Model 1.7 CMKRNUWAKE Model 1.6 Figure 4 Double-mapp ed Buffer

Vo l. 4 No. 26 I Wi nter 1992 Digital Te chnical jo w

BUFFER Since the syst em included a grap hics card . the DESCRIPTORS DECwindows login process frequent ly tried to d isplay the i n i t ia l DECwindows login screen. This attempt fa iled because there was no monitor. Therefore, the process was deleted and restarted a few minutes later. We concluded that the tempo­ D rary drop in server performance we had observed was the effect of the DECwindows start - up p rocess. RECEIVE The significance of this observation became apparent when we op timized the transport inter­ face, and the effect. of this backgrou nd process activ ity decreased to less t ha n 10 percent . We con­ cluded that the optimized interface was less suscep­ tible to concurrent l/0 than was th e stamlard QIO DATA BUFFERS interface .

Figure 6 Wo rl� Element Data Structure Implementation fo ro Tm nsceit 'e OjJemtion Once the ini t ial test i ng of prototypes was com­

the b - plete , we decided to implement do u le m apped As devdopment of the cl i en t ami server software bufkring algori thm with shared queues. The VAX modules continued, we encountered some i n ter­ architecture provides inherent queuing instruc­ est i ng problems. The foJ!owing three sections tions that al low the sharing of data across dissimilar describe scver;ll of these problems and how we address spaces. It accompli sh es this by storing the addressed them. otfset to the uata, ra ther than the address of the data, in the queue header. Th is tech nique permits Microsoft LANMa nager Redirector

us to inser t a syst e m virtual a(ldress into a queue in 1/ 0 Behauior system context and Ia ter remove the audress in pro­ \V hen the Microsoft LAN Manager redirector. i.e .. cess context as a process virtual address. A second the DOS client p rotoco l equivaknt oJ the VMS fi le fu nction that th ese instructions perform is to inter­ server, generates a read request. it tirst vv rites the lock the queue structure while modifying it. Th is request for servi ce to the network. The recl irector proced ure precludes concurrent access hy other then issues a reau request and uses a sh ort buffer to code and thus allows the interface to support sym­ receive only the protocol header of the response metrical multiprocessing. message. After verifying that the response was suc­

We m od i fi ed the li l e server to support this new cessfu l, the red irector issues a second read request optim i zed tra nsport interface. T<> ease the imple­ to receive th e data associated wi t h the respo nse

mentation. the QIO interface emulates the DECnet message . interface in all aspec ts except one. Since the cl ien t ­ This behavior requires lower protocol layers to sen'<:r model is esscntiaiJy a request/response buffe r the response data until the redirector issues

model, \.V C dcvc l oped a tr;msm i t/receive (trans­ a read request to receive the data. In order to buffer ccive) ope ra tion that allows the server to issue the response data for the cJ ient. the transport l ayer read bulle r and wri te buffe r requests at the same needs to al loca te an 8KB buffer. An alternat ive time. This variation reduces the number of system approach to maintaining a dedicated transport boundary crossings. When the server transmits buffe r is to use the i nherent bufferi ng ca pacity of buffers, these bu l'tc rs re turnto the server process the Ethernet ua ta link software and the Ethernet by way of a transmit compl ete queue. \V hen the controller card. which maintain a cache of receive server receives a new request message, the associ­ bu ffers. This tech n ique requires the t ranspor t layer

ated buffer is transferred to the server process via a to retain data link recei ve buffers while the redirec­ recei ve comp lete queue. 'I(> facil i tate a transceive tor verities the response message pro tocol header operation, we defined a work clement data struc­ and posts the actual receive buffer. Once the redi­ ture. As shown in hgure 6, a work e lement perm i ts rector issues the second read request. the remain­ the passi ng of two distinct data streams: one for ing data is copied and the E th ernet buffe rs are transmit and one for receive. re leased .

Digital Ii!clmical jo urua/ l'iJ/ ..j So. I U"'iu ler /')<).! 27 PATHWORKS: PCInte gration Software

One problem with this approach is that each ven­ CLIENT SERVER dor's Ethernet card has diffe rent buffering capaci­ T1 READ BLOCK 1 ties. In some cases, the capacity is less than the SUCCESSFUL READ. size of the maximum read request. To support T2 ------UNSUCCESSFUL RESPONSE- such inadequate buffering capability, we inserted a ---- PACKET LOST

butkr management protocol (BMP) layer between T3 READ BLOCK 1 the file server and the redirector. The resu lting pro­ cess is as fo llows: T4 SUCCESSFUL READ, SUCCESSFUL RESPONSE The client module com municates its data link buffering capacity to the server module in the ses­ sion connect message. When the application gener­ Fig ure 7 Idempotent Request ates data requests, the DOS redirector packages a server message block (SMU) protocol message and passes it to the BMP layer. This layer adds a small CLIENT SERVER buffer management header to the message and pass T1 DELETE 1 it to the transport layer to transmit to the server. FILE ------• To complete the operat ion, the file server pro­ SUCCESSFUL DELETE. T2 ------UNSUCCESSFUL RESPONSE- cesses the request, formats an S:VIB response mes­ ---- PACKET LOST sage, and passes it to the fl,VI P layer. At this interface, T3 DELETE FILE 1 ------• the size of the response message is indicated by the transmit buffer d es criptors , and a protocol T4 ------UNSUCCESSFUL DELETE, header that describes the response packet is cre­ SUCCESSFUL RESPONSE (EVEN THOUGH THE FILE ated. If the response message is larger than the WAS DELETED) client's data link buffering capacity, the driver soft­ ware segments the response packet into smaller Figure 8 No nidempotent Request messages and passes these messages to the server transport to transmit to the client. The client mod­ can be repeated without changing the result, the ule copies the header to the red irector's short operation completes successful ly. buffer and completes the rcdirector's read request . In the case depicted in Figure 8, we changed the The BM P l ayer then waits for the second read to operation from a disk read to a delete file.Here, the copy the re maining data to the recl irector's buffe r client makes the delete request at time Tl, and and releases the data link buffers. At this point, the the server successfully deletes the file at time T2. client can request more data from the server. The response message is again lost. When the client reissues the dekte file request at time T3, the server Response Buffering fa ils in its attempt to perform the operation The LAST protocol docs not acknowledge the because the file no longer ex ists. The delete opera­ receipt of messages because it relics on the tion is not idempotent; thus, repeating the opera­ integrity of the underlying LA� to deliver data­ tion yields a different outcome. grams without error. Consequently, the BMP layer \X'e cannot determine in advance the actual idem­ must buffer all response data transmitted to the potency of any given request. Therefore, the BMP cl ient to protect against packets that are lost or layer must cache all response buffers. If a response discarded. In such a case, the BIVIP layer transmits message is lost, the server transmits the original the original response message back to the client response message instead of retrying the entire without sending the message to the server process. operation. If, as in the second example, the server is For instance, consider the two cases shown in able, at time T4, to transmit the actual buffe r used

Figures 7 and 8. In Figure 7, a client generates a read at time T2 to store the response message, the oper­ request at time Tl. The server processes the request ation can complete successfully. and generates a response at t ime T 2. The response To fac ilitate the buffe ring of response data, the is lost due to congestion, so the cl ient requests the transport provides a transaction identilier for same data again. as indicated at time T.). The server request and response messages. This identifieris set rereads the file and generates a new response. Since by the cl ient BMP layer whenever a new request is the read operation is naturally idempotent, i.e., it received from the redirector. The server stores this

28 Vol. 4 No. I Wi nter /'}').! Digilal Te e/mica/ Jo urnal Th e Uet •e!opment of mt Op tinti.zwl PA TI-J WONKS hon.,j }()r/ lnteJface

identifierand vnities it again st rhe ilkntitie r of the requests of va riou s buffer sizes ranging from 16KB. next request If a recei,·ed request has a duplicate 128 bytes to Tl' represe n t s a transaction pro­ identifier. the request must be a retransmission and cessing test that measures ra ndom read ami write the serV<:r transmits the message in the cached requests of small units of data. Th is test emulates a response bu ffer. If the identifier is unique. the typical database application. The workload value cached bufferis returned to tile server b\· mean s of indicates the n u m be r of cl i en t s\·srems used in the k the shared queues. and a new request is crea ted. test to produce a ba c grou nd workload . As one The client's single- threaded nature ensu res that m igh t expect. as the work l oads increase. the per­ the transaction identifier method is successful in form a n ce of the measured c l ien t degrades. d etecting a ret ra nsm issi on. The entries in each row of the table are t he el apsed time and pe rcen t CJ>l l u t i liza ti o n for the Ne tB/0-)' h' mulatirm given test. \Xfe measu red se1Te r pe rform a nce over The PATH WORKS tr:li1Sj)Ort interface impleme n ta­ the L\ST protocol using our opt im ized interface tion rei it·s on the requ es t/response behavior of the and ove r the DECnet protocol using tlw stan(ianl DOS rcd i rector Howc\'cr. the rcdireetor uses the V,\'I S Q!O interface. For tile ALL J/0 rests, t he resu l­ st andard DOS net work basic 1/0 system (NetBI OS) ta nt e l apsed time is tile actual time i t rook to com­ i n te rface to communicate vv itil t ra n s ports. and this plete the test. for the Tl' tests. the perfo rm a nce interface docs not exh ibit t-l'(JUest/response behav­ numbers are the average of all the I'Cs tested . ior. Therefore . our imp lement a tion is not a true As Table 2 shows, we were abl e to decre:tse the NctlHOS cn1ul;1tion and c1n p reve n t common elapsed time for each benchmark while maintain­

Net iiiOS appl i ctt io ns from o perati ng correctly. ing the same or decreased CI'LI utilization. To resolve this problem, we den:l opcd a com­ The two graphs in Figures 9 and 10 il lustra te mon NetliiOS i nter fa ce between the DECnet and these results. In t he ALl. 1/0 test. CPU u tili zat io n

L,\ST transports. After receiving a requ est. the client using the opt imized i nterf:tce i n creas es s teadi l y as fi rst t ries to connect over the LAST t ra nsport . If the the workload increases. llsing t he standard QJO connection attempt hils. the request passes to the interface . Cl'll u t ilization increases at a faster rare DfC<:net tr:tnS[)Ort Tln1s. standard NetBIOS appl ica­ once a specified workload is reached. Al th ough the tion requests ope ra t e m·er t he DECnet transport: Tl' graph i n Figure 10 contains onl y t wo (la ta point s, only rnl i t·ector req u ests are [Jroccssed over the it is evid ent that Cl'lJ u t i l i za t io n is proportionally LAST transport h igh er for t1ve workloads than it is for one. \\leper­ fo rmed multiple tests to verify tha t the results

Final Benchmarks could be reproduced consisten t ! \·. r\t the compktion of the project. we performed The final benchmark test pe rfor med was a direc­ benchmark tests to measure senTr performance tory tree copy using tbe DOS XCOL'Y utility. ln this for varied workloads and for a directory t ree copv. test. the utilitY copies the d i recto rY tree Ji rst from 'E1hlc 2 shows rile results for \'aried workloads. The the server to the client and then fro m the cl i en t to fi rst column of t he table descri bes the test p er­ the snve r. The bottleneck in t his test i s k nown to formed . ,\ LL 110 represents a raw disk 1/0 test in be the tile crea t i on rime on the serve r. Therefore. which the measured cl ient issues read and write we expected a m ore efficienttransp ort interface ro

Ta ble 2 Final Benchmark Te st Results for Va ried Wo rkloads

LAST Protocol DECnet Protocol r--- Elapsed CPU Elapsed CPU Ti me Utilization Ti me Util ization Te st Description (seconds) (percent) (seconds) (percent)

All i/O 0 Workloads 840 4 961 4 All l/0 2 Workloads 943 69 1074 75 All i/O 4 Workloads 1091 100 1434 100 TP 1 Workload 59 39 79 50 TP 5 Workloads 163 83 21 2 93

ni?,ila/ Te cbuical Journal I id. t .\fl. I Wiuler !')').! PAT HWORKS: PC Integration Software

(j) 1600 (j) 400 a _ ... a z 1400 z 8 1200 8 300 w w ------·- � 1000 - - - - - � w w ::2 800 ::2 200 f= f= 0 600 w 400 a (/) � 100 (l_ 200 (l_ :5 w w:5 O L_------� 0 2 4 1 5 NUMBER OF WORKLOADS NUMBER OF WORKLOADS

KEY: KEY:

...... ___... LAST PROTOCOL WITH OPTIMIZED INTERFACE ...... ___... LAST PROTOCOL WITH OPTIMIZED INTERFACE

.. - _. DECNET PROTOCOL WITH STANDARD 010 INTERFACE .. - _. DECNET PROTOCOL WITH STANDARD 010 INTERFACE

Figure 9 ALL 1/ 0 Te st Results Figure 10 TP Te st Results

Ta ble 3 Final Benchmark Te st Results for a Directory Tree Copy

LASTProtocol DECnet Protocol Test Elapsed Ti me 1/0 Rate Elapsed Ti me 1/0 Rate Description (seconds) (KB/sec) (seconds) (KB/sec)

X COPY to Client 115 39 15 39 X COPY to Server 119 38 121 37 have no effect on server performance. The test Acknowledgments results in Table 3 support our theory. The 1/0 rate I wish to thank jon Campbell for incorporating the and the elapsed time over both the DECnet protocol interface design modifications into the file server, (using the standard transport interface) and the Alpo Kallio for developing the client software, and LAST protocol (using the optimized transport inter­ Alan Abrahams for designing the combined DECnet/ face) are nearly the same. LAST NetBlOS interface and for his encouragement and support.

30 Vo l. 4 No. I Winter 1992 Digital Te clmicaljournal Anthony j Rizzolo Elizabeth A. Brewer Martha A. Chandler

Design of the PATHWORKS fo r ULTRIX File Server

Th e PA TH WORKSjiJr Ul.TRJXproduct integ rates personal computers t.l'ith the l !LTRIX op erating S)'Sie/JI on a locctl area nettl'Ork. Th e sojtlmre supports both the TCP/IP protocol wzd the JJFCnet transport stacks. Th e design and implementation r�t t/.Je PATHWORKSj(; r ULTR!Xfileserl'er is based on a client-sen•er model. Th e seruerpro­ t•ides file,print , mail. and time serl'ices to client PCs on the netzmrk. Ne tu ·orkjileser­ t•ice 11/mwgenzent is accessed through a PC-style menu inteJface. Th efile sen·er's pe1ji;mw11ce um optimized to a/lou• parallelism to occur Ll'IJen the client is gener­ ating data at the same time the serl'er is u·riting the data to disk.

The PAIHWOHKS fo r lll:mlX tile server connects design of a management interface and our selection industry-standard personal computers running of a network interface. Finally, the paper describes PATH WORKS Microsoft's snvcr message block (s:viB) protocol the ti le system, printing, performance to Digi tal computers running the t:rnox operat­ considerations, and the server configuration. ing system. The server provides a network operat­ ing system for I'C integration among users of the Process Model UIJ'RIX, DOS, and OS/2 operating systems. The process model selected for the PAJ 'HWORKS The l'ATHWOHKS for liiTI{ IX server provides tile, for l !LTHIX server cl iffered substantially from the print, mail, and time services to client PCs on the process model chosen for the I'ATHWORK� for VMS network. The software is layered on VAX systems product. Thc PATH WORKS for V;'v\S server uses a sin­ and on reduced instruction set computer (HISC) gle process model in which all client requests are hardware. It supports both the transmission con­ processed by a single process, the VMS server. The trol protocol/internet protocol (TCI'/11') and the l'ATHWOHKS for lli.THIX server, in contrast, uses a DE<:net transport stacks. The base product also multiple process model, in which one client is ser­ provides centralized server-based management viced by one server process. accessed through a PC-style menu interface. Certain characteristics of the lllTI{JX operating In addition. the I'ATHWORKS for lJ!.TRIX server system environment determined the choice of a implements a network basic 1/0 system (NetHIOS) multiple server process model. First. the lii..TRIX naming se-rvice that allows cl icnts on the network operating system constrains a process to 64 simul­ to obtain the DEC:net node address of the server in taneously open files.Ther efore, with multiple server the DECnet environment or the TCI'/1 1' address of processes, each client connection is allowed access the server in the TCP/IP environment. The DECnet to 64 open ti les. In a single process model, a pool of NetBIOS naming service conforms to Digital's speci­ 64 fi le descriptors is provided which limits access tication for a J)J:Cnet NetlliOS interface. The TCI)/Il' to 64 open ti les, regarcl less of how many cl ients NetiiiOS implementation conforms to the requests connect. In addition. the multiple server process for com nH:n t spccitica tions, I{ I'C I 00 I and RFC model has the advantage of' being able to run in a 1002.1.2 multiprocessor environment. This paper discusses the considera tions for Wi thin the context of the multiple process model, designing and implementing a PC local area network we required a central administrat ive entity-the (I.AN) server in an lii.THIX system environment. It adminisn-a tion process-that would coordinate describes the multiple process model and its com­ management activities and server requests. The ponent processes that coordinate management administration process communicates with both activities and server requests. lt then presents our the server and management processes through

Digital Te chnical jounwl IIJI. i .Yo. I ll inli'l' !')<).! :' d PATHWORKS: PC.: Integration Software

message queues. This process model is depicted in vides for sending datagram and broadcast messages Figure 1 and is described in the fo l.lowing sections. on the LAN. These two tasks are initiated by the user through the management interface by means Administration Process of the Send and Broadcast Message fu nctions. All The administration process is known as pcsaaclmd. management requests are processed through the As the central administrative entity, this process is administration process. Request handling is dis­ responsible for initialization and start-up of the cussed in more detail later in this section. server, and for data management while the server is The administration process parses the Ianman. ini running. Starting the PATHWORKS for l1JTRIX server file to obtain server configuration parameters such is accomplished through execution of the adminis­ as maximum number of sessions, connections, and tration process from within the rc.local file when open files. The administration process uses these the ULTRlX system is booted, or from the manage­ parameters to establish the size of the shared mem­ ment menu when the management interface is run. ory segment it creates. The shared memory segment Initialization of the servt.:r environment is neces­ includes a session database, a connection database, a sary before any server management or connections file database, common variables. and a locking data­ can be established. base. Once shared memory is created, the adminis­ [nitialization involves starting the NetlHOS pro­ tration process initializes it to a known state that cess (pcsanbud), parsing the configuration file includes clearing and date stamping the server (lanman.ini), creating and initializing a shared statistics portion of the segment. The administration memory segment, creating semaphores and a mes­ process creates semaphores to attain data integrity sage queue, parsing the services database, clearing in the shared memory segment, since multiple file statistics, defining objects on the DEC.:nct objects, server processt.:sread and write to memory. and establishing signals. The main task of the The services database tracks file and print ser­ administration process is processing requests from vice creation from one execution of the server to the management interface (pcsamgr) and file server another. This database is read at initialization, and processes (pcsafs). The initialization procedure the directories offe red by the file service defined, occurs in the following sequence. as well as printer information, are verified. To simplify server start-up, the NetBIOS process The last step required at initialization is the cre­ is startecl from the administration process. At start­ ation of a message queue to process incoming up, the NetBIOS process claims the server name and requests from the management interface and file responds to name queries from clients during server processes. As said earl icr, request process­ establishment of a session connection. It also pro- ing is the main task of the administration process.

MANAGEMENT INTERFACE

MESSAGE QUEUES I MESSAGE ONE PROCESS QUEUES FILE PER CLIENT FILE ADMINISTRATION ------SERVER SERVER PROCESS I PROCESS PROCESS

ULTRIX SEMAPHORES system() I SOCKET I llockl() I TCP/IP AND DECNET SHARED LOCK LINE PRINTER NET BIOS MEMORY FACILITY IMPlEMENTATION DAEMON I DECNET

TCP/IP

Figure I PA TH WORKSfor ULTRIX Process Model

32 Vo l. 4 No. 1 Winter /')<)2 Digital Te cbuica/ ]o ur11al JJes

.Vkssagc queues arc used as the interproccss com­ sharecl memory as we ll as message queues for munication mechanism. Earl\· in the proccss devel­ communication. opme n t , \VC in vcs tiga tcd other options: namecl Since multiple processes can simultaneously pipes, sockets, a mi packet passing through shared u pdate and access shared memory, a method was memory. Only message qucucs offered administra­ needed to guaran tee clara integritY. The metlwus tive control. I nit ially, we used one response mes­ chosen varied among the databases, depending on sage queue for each ti l e scrn:T process and one the type and speed of the access requ ired to the queue for the management interface. This was database. Olwiously, the easiest and also the slow­ unacceptable because the dclault number of n1Cs­ est way was single-process management of access sagc queues on the l l ll'!UX svstem is 40 w ithou t to shared memorv This wo rked wel l in the case of rccontiguring the kernel. Therefore , we chose to allocating connection data blocks, since the admin­ combine tllC messages on one response queue from istra tion process had to be notified of connections. all the ti l e sen cr p rocesses and retain a separate The open ami read-write p a ths for the tile and response queue for the management interface. locking (i atabase, however, wou\(1 he significantly Since the nu mber of req uests from tile server pro­ affected lw an incorrect decision. for this reason, we cesses is smalL this mcthocl was :1cceptable. The decided to protect these cl atabases with an I IT :II{ IX administration process reads requests on one mes­ sem aphore. In effect we single threaded all the sage queue and rep I ies to a message queue de tined paths through the open path as wel l as the locking in the mes.sage. The request queue is established update path. Use of this semaphore caused little or with an II) known bv all processes so they can no (iegrada tion in performance. With our system attach to the queue at start-up. The administration p rocesses and mechanisms establishnl, we now had process 11aml lcs requests for session establishment to eonsicler tile nenls of tile sYstem administrator. and connection from tileser ver processes as well as requests for svstcm manage ment/admin i strat ion Management Interfa ce

from the manageme n t interface Our primary goal in (i csigni ng a management inter­ face for the l'i\TI-lWORKS for \JLTRTX server was to File Sen1er Process provicle an appl ication that cou lll run unaltcrccl The PXIHWO!\KS for \;r:nux ti le serwr is started on any type of terminal. The management inter­ through one of two mechanisms, clcpcncli ng on face also had to be consistent in presen tati on ami

which transport is used. The dnet_spawner process manipulation of screens: and most i mportantly, it starts the ti le server process in a DLC:nct environ­ had to be easy to use when m a naging ti le and print

ment, anu the inct_SJ)awncr starts t he server in a services, workstation registration, and l!ITIUX s ys­ TU�l l' environment. The server process is initial !)' tem users ami groups. Other clesign considerations started as a root process, since it may need to run included performance, the abilitv to extend the on behalf of severa l users. \V hen a cl i ent issues a fu nctionality p roviclcLI , ami tile ability to port the connection request, a server process is initiated. appl ication to future platforms.

The scrHT tlll"n semis a message to the adminis tra­ The management interface was u csignul to tion process message q ue ue requesting a session incorporate X/Opcn Curses software, which is a set connection. After the session connection is grantee! of C library ro utines. X/Open Curses is provided by the administration process, t he file server com­ by the ULUUX operating sYstem ami is useu to opti­ pletes its initialization h\· connecting to sha re(! mize screen management. X/Open Curses code mcmon· ami waiting for incoming client requests. uses the term info database. a col lection of terminal During the design phase of the m u l t i p l l' server definitions ami characteristics that enables the process mode l, it became clear that using a slow application vvritcr to perform termin al-dependent interproccs.s communication mechanism has a fu nctions in a terminal-independent manner d et ri mcnt :il illlJ!;Ict on the mcra ll pcrfornLincc of Through X/Open Curses software and its usc of the server. for this reason, we deciuc(l to usc shared t he terminfo database, the l'ATHWOJ\KS fo r OLTRIX memory fo r all time-critical shared data. Because man agemen t interface can support an\- type of the amount of sl1arecl mcmor)' is somewhat limitnl, terminaL' all data that is not time critical is communicated The next step was to design an cas\·- to-use a ppli­ across message queues. As can he seen in F igure 1, cation that requ ires minimal k nowledge of l'ITIUX the file senTI' ami administration processes usc system management. \Vc chose a l'C-stvlc format

D(!!,ila(Ji·c huicaf ]O III'IWI I rd. I Xu. I 1\iulcr !')')J PAT HWORKS: PC Integration Software

that uses pulldown menus, input forms, scroll The second network interface in the UTRIX sys­ regions for displaying information. and screen­ tem is the X/Open transport interface (XTI). This sensi tivc help. Default input information is dis­ transport service interface is not restricted to played whenever possible to provide sample data either the DEener or the TCI:YIP transport. A com­ and to minimize the amount of input required. mon interface to the network allows either trans­ The design of the management interface was port to be accessed transparently. With XT! the structured into three layers: screen manipulation, communication endpoint is identified by a local file data validation ami presentation, and application descriptor. On the ULTRJX system, the XTI interface programming interface (API). is provided through a library that converts the XTI calls into socket calls. Since performance was one Screen Ma nipulation of our primary concerns, we decided to use the The first layer of the management interface is the socket interface because it connects directly to the X/Open Curses software. All screen manipula­ ULTRL'\ operating system. tion routines reside at this level. X/Open Curses encompasses the implementation of reverse video Multiple Tra nsport Support attributes for highlighted text, cursor movement, In order to support both the TCJ:YIP and the DECnet window updates, ami the creation of menus, forms, transports, we needed to overcome the diffe rences and scrolling regions. Any type of screen inter­ between a message-based protocol (DECnet) and action is performed and managed by this layer of a stream-based protocol (TCP/11'). With a message­ code. As a result, the screen manipulation layer is based protocol, data received from the network portable to any environment in which X/Open arrives in compact packets. With a stream-based Curses is supported. protocol, message boundaries are not preserved; the data flows in a stream. Since Microsoft's SMB Data Va lidation and Presentation protocol is a message-based protocol, the server At the data validation and presentation layer, data needs to re-create these message boundaries. As a obtained from the screen interface is validated. The result, the server must identify the transport clata is then packaged and processed by the API provider. This information is provided by the layer. Information returned by the API layer is socket layer when the server process is started. The unpacked and formatted fo r screen presentation. server can re-create the message boundaries by combining this information with message size Application Programming Interfa ce information provided in the TCP/11' NetBIUS header. Wi th the message boundary information, the server The API layer is responsible for all communication can re-create the message. The C pseudocode frag­ with the administration process. The management ment in Figure shows the instructions to re-create interface does not store or manipulate server man­ 2 message boundaries. agement data directly. Instead it makes requests of the administration process in the form of APls through message queues. Each request requires a PAIHWORKS File Sy stem response and docs not complete until a response is The PATHWORKS file system provides an application received. layer that attempts to emulate the DOS filesystem . Several trade-ofls and restrictions were required in Network Interfa ce order to implement this file system on the ULTRIX When designing an application that must commu­ filesystem. This section describes these trade-ot"fs nicate on a network, one of the important deci­ and restrictions and explains our design choices. sions is how to control access to the network. The Berkeley Software Development version 4.3 of the File Na me Mapp ing UNIX kernel, upon which the ULTRIX operating sys­ The file name space in the Ul.TRJX system is not tem is based, provides two network interfaces. restricted to the 8.3 naming format supported by The firstnetwork interface is known as the socket DOS. DOS limits file names to eight characters fol­ interface. It uses a socket structure to identify the lowed by an optional period and an optional three­ endpoint of an liLTRIX network connection. Under character extension. This is referred to as DOS 8.3 the LTR IX system, the socket interface is the pri­ filename fo rmat. DOS filenames are uppercase char­ mary interface to the network. acters and are case insensitive. Umler the ULTRIX

34 Vu l. 4 Nn. I Will fer 1992 Digital Te cbuicaf jo urnal Design o{the PA TH WORKS fiJr WIN/X File Sen•er

I* SMBptr - Pointer to SMB netbios header */ /* rdlen - Number bytes read from net�ork */ I* BytesRcvd - Bytes already received */ /* By tesleft - Bytes Left in current message */

rd len=read(net�ork,SMBptrl; BytesRcvd=rd len; Bytesleft=sizeof (netbi os header); BytesLef t+=ntohs(EXT1 6CSMBptr->nb . Length)-bytes_r cvd;

I* We �i ll wait un ti l �e receive all the data in the msg */ /* before �e terminate th is loop . This loop �i LL only be */ /* entered if we are running TCP/ IP. */

whiLe (Bytesle ft1= 0) { rd len=read(net�ork,&SMBp tr(BytesRcvdJ);

/* If �e don't get any data it means the client must have */ /* torn do�n the session so abort */ I* our session. Note AbortSession() must exi t and*/ I* not return here.*/

if (rdlen<=O) AbortSession();

I* Update the counters to account for what we just read */

BytesRcvd+=rd len; Bytesleft-=rd len;

I* If this is a SESSION_ REQUEST message, then send the ACK*/

if CSMBptr->nb .type == SESSION_ REQUEST) SendSessionAckC l;

I* If this is a SESSION_MESSAGE, then handle the SMB *I

if (SMBpt r->nb .type == SESSION MESSAGE) Di spa tchSMB();

Figure .2 Necei1•ing Stream Data Code Fmgm ent

system. the til<: namc is a 32-character string in only uppercase file names that fo llow the DOS 8.:) which the period () is a l<:gal character. The l!J:I'RIX fo rmat. fi le system is case sensi rive ami supports hoth upper­ case and lowercase characters in the tile name. DOS Attribute Mapp ing 'I(J resolve this incompatibility between operat­ The DOS file system provides tile attributes that ing systems. we mapped the DOS filename space into do not necessarily map to lJUIUX tile attributes. the liiTRIX filename space. DOS, being case insensi­ The challenge was to preserve these DOS attributes tive. views the world of Ji le names in uppercase, within the liLJ'lUX file system without impacting but liJTIUX file names are typically lowercase char­ the host system user who might also be sharing the acters. We chose to map all DOS file names to the file.The nos attributes consist of read-only, hidden, equ ivalent lowercase name. Any tile on the host archive, and system. LiiTHIX operating system that meets om criteria, The DOS read-only attribute maps directly to i.e .. lowercase names and H.:)fo rmat is visible to the the lJLTRIX directory attributes mask. If the write DOS client. attribute is turned off under the !IITRIX system, the This approach was sui table in all environments files change to read-only status. except International Standards Organization (ISO) The DOS hidden attribute specifies that a file ')(l(lO CD-HO.VI file systems. These file names con­ should not be displayed on a normal directory form to the DOS uppercase, 8.:\ ti le naming fo rmat. search/lookup. We mapped this bit to the ULTRIX When the file server determines that one of the set user ID hit. services is on an ISO 96(l0 CD-I{OM file system . the The DOS archive attribute specities that a file

file-name mapping algori th m is changed to allow has been changed since the last time the archive

Di�ilol Ti! chnical jo urnal llJi. -1 .\'o. I \!'illll!r I'J').! PATHWORKS: PC Integration Software

attribute was set. It is generally used by the backup I'ATHWORKS for ULTRJX server. We provided a high­ program to determine which files have changed performance lock manager that could lock byte since the last backup. We mapped the archive ranges used by DOS applications. In other words, attribute to the ULTIUX set group 10 bit. the server 'lock manager would treat the lock range The DOS system attribute specifiesa special sys­ as an unsigned number instead of a signed number. tem file that is normally not displayed on a direc­ We also provided the option of passing the Jock tory listing, and in some cases is not backed up. We information to the UTRIX lock manager for those mapped the DOS system attribute to the Owner applications that needed this functionali ty. eXecute bit. If this bit is set, the server cannot include these files on a norma� directory search, Op en File Mode Locking unless requested. The DOS client provides a mechanism for control­ ling access to opened files. Itallo ws the client who By te Range Locking initially opens a file to control access to the file The most noticeable difference in byte range lock­ by other clients. The DOS client allows files to be ing between the U!TRJX operating system and the opened in one of four modes: DOS operating system is that byte ranges under the • DF:\'Y _NONE mode allows all types of files to be ULTRIX system are purely advisory. Advisory lock­ opened by all users. ing works as a mechanism to signal that a byte range is currently in use. The ULTJUX system, however, • DENY_READ mode allows other users to open does not enforce the locks; therefore it is possible the file for writing but not reading. to read/write a byte range that is locked simply by • DENY_WRITE mode allows other users to open ignoring the lock. tht: filefor reading but not writing. On the other hand, DOS has mandatory locking. • DENY_READ_ WRIT E mode does not allow other If a byte range is locked, the user can neither read users to open the file. nor write a locked byte range. We needed to con­ vert the ULTRIX lock manager into a mandatory lock The ULTRIX operating system, on the other hancl, man::�ger from the DOS clients' point of view. To do has only two modes for a shareable file lock. The this, the ULTRIX lock manager has to check for a firstis SHARED_ACCF.SS mode, which allows multi­ lock on a byte range on every read or write from the ple readers ancl writers ami is therefore equiva­ file server. Ifany portion of the byte range is locked, lent to the DENY_'K>NE mode. The other mode is the client receives a lock fa ilure message. EXCU 'SIVE_ACCESS mode, which does not allow In the initial release of the server, we bel iewd multiple accesses to the same filean d therefore is that the standard ULTIUX lock manager would equivalent to DEl\'Y_READ_ WRlTE mode under DOS. provide enough performance and granularity to Because of these differences, we attempted to allow DOS client software to function correctly and map the two modes not covered by the ULTIUX file quickly. We learned that this was not always the lock manager, the DE:VY_READ and DE�ry _WIUTE case. For example, in a network file system (NfS) modes. After some investigation, we decided map­ environment, additional time for granting or deny­ ping was not necessary. If a file was opened in ing the lock request was needed to resolve a lock on one of these two modes, we specified that the the net work. In addition, the UITR!X lock manager ULTRIX server should open the file in ULTRIX viewed the byte range as a signed integer, but the SHARED_ACCESS mode. We reasoned that an ULTRIX nos lock manager viewed the byte range to he application that was cooperating with a DOS appli­ locked as an unsigned integer. This disparity led to cation would not use these two modes to open the problems with applications that used byte range tile since they are not available under the ULTRIX locks with the sign bit set to provide synchronizJ­ system. Obviously these two modes need to be sup­ tion for database upd:1tes. We found that the ULTRIX ported among DOS-based res on the server. Each lock manager was cldicient in the DOS client envi­ time a user opens a file, the I ist of currently opened ronments. For these rc:1sons, we decided to write a files is scanned to enforce the open mocle and to be private lock manager for applications that could sure that the UlTRIX operating system conforms to not use the ULTRJX lock manager. the DOS interpretations of these modes. Therefore, To resolve locking problems among these appli­ only the half deny modes being passed through to cations, we designed a private lock manager for the the operating system are not enforced. This design

36 Vo l. 4 No. I Willler I'J'J2 Digital Te chuicalJournal Design of the PA TH WORKSfor UU NIX hie .'\erl'er

decision should pose no danger to applications printing SMBs, a batch job is run at the time speci­ sharing data. Jieu in the print request. The l!LTIUX print spooler provilles spooling for Directmy Search Implementation all types of printers, e.g.. those attached locally

The DOS file search algorithm and the SMB mes­ as well as network printers anu reverse Local Area I'Cs. sages that provide support fo r directory searches Transport (LAT) printers connected to Reverse !.AT were difficult to implement on the liLTRIX file pri nting is very important in our environment server. The core S:VIB protocol prov ides only two because most PCs have printers attached and most states tor a search context. begin new search and installa tions have a need to slure those printers cominue a previous search. However. the server among several PC:s. li!TRfX needs to be informed that the cl ient has completed The print spooler provides print hirers a director\· search context. Then the server would vv hich translate Jiles to various printers. Print fi lters be able to fn:e local data associated wi th the search conceptually sit between the !.PI) and the actual tile !.I'D context. The impit'mentation of this s.vtB posed two to be printed. During printing, the reads a " rintc p " file challenges : how to control the amount of memory p a to determine if a print filter is associ­ required and how to map a search continuation ated with this queue. The print filter is started in a identifier. forked process with its standard output uevice (std­ To minimize the amount of memory required to out) pointing to the printer and its standard input maintain search contexts, we designed a table of device (stuin) pointing to the input filestr eam. The search context structu res that contains a local print filter is responsible for converting the file timing va.lue. Jf the table becomes fu ll and a block from the input stream (stdin) into a device-specific (structure and time va lue) needs to be reused, the output that is usable by the printer (stdout) This l'ATHWO!{KS li!TRIX oldest block is lk:<.:med reusable. This approach effi­ fe ature allows the for server to ciently m;1nages th<.: unpr<.: dictable m<.:mory require­ support printing on a will<.: variety of third-party m<.:nts of an SM!l search. printers. The s<.:arch contin u:ltion provides a directory The uesign of the li!TJUX printing subsystem LI.TRIX information structur<.: which contains a fo ur-hyte enabled the PATHWORKS for server to pro­ field that determin<.:s the point at which the search vide an interface to many diffe rent printers and is to continue. This fo ur-byte field is well suiteu to printer configurations easily and etliciently the l r:mrx fi le system. The gnode ti eld, a longwonl , can be useu for the fo ur-byte fi eld's search continu­ Pe1:[ormance Considerations ation lD. (;iven this ID, th<.: server has the ability to As part of the design process. we obs<:rved the per­ parse the contents of th<.: uirectory until. it finds a formance of the hie server during interactions with fi le with a marching gnode: it th<.:n continues the the client. We needeu to com par<.: various contlict­ search from that point. ing alternatives ancl their effects on the overaU per­ fo rmance of the server. Som<.: of the alternatives we PAT HWORKSfo r UL TRJX Printing studied were the advantages of using the lJLTRIX sys­ In add i tion to fi le services for DOS anu OS/2 system­ tem cache versus implementing ou r own cache. We based clients, P,\THWORKS for lJU'HIX prov iues print also studied the issue of persistent lock requests on services for these PC client s. Our design objecti ve the network anu the server. These alternatives arc was to allow the PC clients access to all the fu nction­ uiscusseu in this sec tion . ality on the native ll!TRlX print queue in a transpar­ ent manner. A second objective was to implement File 1/ 0 the fu nctionality provided by NET !'!{INT. the client Since the I I ITRIX operating system provides a utility for printing, on the native li!TRIX line printer kernel-based, uisk cache mechanism, we designeu uaemon (LI'D). the operating system's cache manager to perform Although the l.I'D provided all the basic printing all caching globally. The cache manager updates capabilities, it dill not proville timed schedu I ing of the cache buffe rs, performs read ahead on data print jobs. 'l(J enable timed scheduling, we added streams. and f·lushes the cache buffers from uata the /AFTER switch to the server through a mecha­ written to uisk. nism \V i thin the tir:J'RIX operating system. When a The tile server performs disk writes as write /AFTUZ switch is cletected in one of the extemled behinds. \XIhen a request to write data is received

Digital Tt! cbnical journal I r!/. i .\o. I Wiuter t')')l :'>7 PATHWORKS: PC Integration Software

from a client, the server responds by acknowledg­ ruse architectures. We expected that code written ing success before the write is attempted (assuming for an ULTruXsystem in a ruse environment would the client has proper write access to the file). This be recompiled on a VAX system. For the most part, optimization allows parallelism to occur between our assumptions were correct, except in the areas the client and the server because the client is gener­ of memory allocation. ating more data at the same time the server is writ­ On the VA.,'( system, shared memory maps ing the data to disk. If the write fails, however, the directly aft er the data segment in memory. This server notes that the last write failed and returns implementation prohibits the allocation of mem­ the error on any subsequent access to the file. ory above a shared memory segment. In the ruse implementation, shared memory is allocated at the He uristics very top of the memory image; therefore a great We fo und that certain applications would continu­

continually requesting locks which are failing. Disconnect from shared memory ma lloc() When the server detects continuous lock requests, Reconnect to shared memory it delays the lock request for a random period of Since this code is required only in a VAX environ­ time and then checks if the lock has become avail­ ment, it is compiled when the server is built. able. The server then either grants access ifthe lock is available, or returns the error at that time. This PATHWORKS Server Configuration procedure reduces lock request traffic, since most PATHWORKS LTruX locks are of short duration. The for file server allows the system manager to configure the server environ­ Security ment to make the most efficientuse of shared mem­ ory. The following parameters included in the Connection requests between client and server lanman.ini file are the determining factors that require a security check. Since PATHWORKS for enable shared memory to be scaled. ULTRIX was designed to be layered on the ULTRIX

operating system, we were able to take advantage • maxsessions: The maximum number of PC work­ of its security features. \X'hen a client attempts to stations that can be simultaneously connected connect to the server, a username and password to the PATHWORKS for ULTruXse rver. can be passed as part of the connect message. If • maxconnections: The maximum number of con­ these are supplied, the user is validated through nections PC workstations can make to the ser­ system calls to obtain the password file entry for vices offered. that user. If the user is not found in the /etc/passwd file or if the password is invalid, the user is denied connection. If the ULTruX system is running in TOP OF MEMORY SHARED MEMORY enhanced security mode, further checks are made to ensure the account has not been disabled or the password expired. In either of these cases, the con­ nection would be denied. If a username is not sup­ plied, a default guest account may be used to SHARED MEMORY TOP OF CODE -1------1 establish privileges. 1------11-DATA, CODE, AND DATA DATA, CODE, STACK STACK

VAX versus RISC Considerations (a) VA X Sy stem (b) RISC Sy stem During the development of the PATHWORKS for ULTR!X file server, we did not anticipate that our code would have to differentiate between VAX and FiguTe 3 Image Memory Layout

38 Vo l. 4 No. 1 Wi nter 19')2 Digital Te chnical journal Design of" the PA T!-I WORKSjor l!UN.IX Nle Serl 'er

• maxopu1s: The maximum number of tiles the Ackrwwledgments servc:r c1n have open simultaneous!\·. Many people were involved in the design ami build­ ing of the PATHWOHKS for L: ITRIX tile server from its • uniqucopentilcs: The maximum number of inception to its shipment. We wish to thank all unique open ti ks the Sl:rver can have open those people: Paul Messier and Jim f

Swnmary Th<.: J',\TIJ\VOH KS for llf:f'I{IX ti le server, together with th<.: I'ATi l\VORKS for DOS and PXI HWOHKS for OS/2 prollucts, pro,·itil:S a distribu ted computing envi ro n ment. The tile server is based on a client­ server model that offers transparent access to llLI'lUX system resourc<:s from PC clil:nts. It pro­ vides rile necessary tools to integrate these two diverse computing environments in a manner that is both l'fticicnt ami easy to manage.

Di�ila/ Te ciJ uical jon rna/ 1(,/ ..; Xu. I \\" inter I'J'Jl Mitchell P. Lichtenberg Jeffr eyR. Curless

DECnet Tr ansport Architecture

The PA THWORKS family of software products includes an implementation of the DECnet transport protocol to allow In tel-based personal computers access to net­ work resources. This implementation, the DECnet Network Process (DNP) trans­ port component, provides basic file and print services, terminal emulation, and application services. The new DNP component for the version 4. 1 release of the PA THWORKS for DOS client software is written in assembly language to improve performance and reduce memory usage. The DOS and OS/2 versions of the compo­ nent contain the same base source code, thus decreasing the development and maintenance costs.

Digital's PATJ TWORKS fa mily of software products popular vendor software applications or hardware. provides the means to integrate personal com­ For example, Microsoft's LAN Manager software puters into the Digital network environment. product influenced the acceptance of the industry­ The PATHWORKS for DOS client software includes standard server message block (SMB) protocol. This device drivers, network transports, utility pro­ session layer protocol, implemented over a variety grams, and applications that allow PCs full access of transports, is used in the LAN lVlanagerredirector to the resources available in local and wide area net­ for transparent file sharing and peripheral emula­ works (LANs and WA Ns). Transparent file sharing, tion. Digital licenses the LAN Manager software in electronic mail, and terminal emul.ation are exam­ order to provide these services as features of the ples of services supported by PATHWORKS client PATH\VORKS product family. Digital extended the software. LAl'\1 Manager across a LAN or a WAN system by using The DECnet protocol suite is implemented in the DECnet transport protocol as the transport layer Digital's standard set of software for interconnect­ in its PATHWORKS products. ing VAX and reduced instruction set computer In this paper we first present our rationale (RISC) systems. DECnet software, which is included behind the design of the DECnet transport compo­ in the PATHWORKS client software, enables PC inte­ nent in PATH\.VORKSfor DOS version 4. 1, as well as in gration. The DECnet protocols allow PATHWORKS PATHWOHKS for OS/2 version 2.0. We then describe products to use the infrastructure of existing the new component's internal structure, follow a Digital networks and to provide common utility typical network operation through the compo­ programs and network management capabilities. nent, and compare this version of the software However, integrating res into a network sys­ component with previous versions. tem presents many design challenges to software developers. They must provide network access PATHWORKS Client Softwareand the without limiting the fu nctionality of the PCs and DNP Component without compromising the compatibility of the Since its initial release, the PATHWORKS product existing PC software and peripherals. Since the PC family has implemented the DECnet transport pro­ architecture has limited memory resources and few tocol to provide access to basic file services and built-in features for networking, PC network soft­ printer sharing, terminal emulation, and applica­ ware architectures must be as transparent as pos­ tion services. This network software implementa­ sible, reducing memory usage and emulating local tion is called the DECnet Network Process (DNP) peripherals and software interfaces. transport component. Figure 1 illustrates the rela­ To implement this transparent architecture, the tionship between the DNP transport component PATHWORKS products comply with PC-related and the other memory-resident PATHWORKS client industry standards. Most such standards result from software components.

40 MJ/. 4 No. 1 Wi nter l'J92 Digital Te chnical journal Dt:Cnet Trm tSj)()rt Architecture

DOS APPLICATIONS I I I DEC NET NETBIOS APPLICATIONS APPLICATIONS (IOCB INTERFACE) APPLICATION PROGRAMS ------,___ ------SYSTEM PROGRAMS DOS OPERATING MICROSOFT LAN f-- SYSTEM MANAGER rt DECNET NETWORK PROCESS (DNP) I PC TIMER AND SCHEDULER l INTERRUPT I-- (SCH) DATA LINK HARDWARE I--- LAYER (DLL) 1

LAN HARDWARE

h�!{llre I PATiiWORKS Client Co mponents

Goals fo r PA TH lVORKS Cl ient Softtuare and drivers that comply ·with industry-stanclard PC network soft ware products are judged primarily spcci.tications to provide peer -to-peer transport on two criteria: performance, usually measured services on a I.AN. The JOCB interface is specitic to with popular benchmark programs. and resident Digital's DECnet transport implementation of tile memory usage. a I i mired resource rha r may restriu­ DEC:net protocols. lOCB provides a socket interface llt:mrx orhcr applications. Increasing performance and similar to the one used by the operating decreasing nw mory usage are major goals for all system. This IOCB interface is used by DECnet­ nnv releases of the PAn I WORKS client soft ware. In specitic application programs. the J>,\TJ IWORKS version ..f.l client software. Digital To com municate with the network, the DNI' sought to double the performance of the DNP transport component ca lis the data I ink layer (DLL) transport componenr for small data transfers, software interface. The DJ.l. com ponenr is used wh ile decreasing the size of the code by 'iOper cent. by all l'ATHWORKS cl ient components to send and Another goal was to significantly reduce mainte­ receive packets on tile !.AN. This component nance costs in order to free engineering resources demultiplexes incoming packets based on their for fu ture projecl tl<:velopment. protocol type (e.g., local area transport [ I.ATJ , local Befon:desc ribi ng how we went about achieving area system transport 1 LAST] . or DECnet transport) these performance. memory. and development cost and del ivcrs these packets to the corresponding go:t ls in I'ATI IWOH KS wrsion i.J . we re view the func­ PA I'HWORKS client component. The Dl.l. compo­ tionality of tile DLCner DNI' implementation. \XIe nent also transmits packets on the LAN, either also discuss the component in relation to other directly or indirectly by c1lling standards-based l'Alll\\IOHKSclient components to give tile context network drivers. To reduce memory consumption, in which our design decisions were made. the DU. component provides a global buffer pool that the DNI' and other transport components can Th e DNP ComponentFu nctionality use for building network packets or for storing Appl ication programs can use ONP transport ser­ unacknowledged data . vices through one of two software interfaces: the To provide timing and background process ser­ network basic l/0 system (NeliiiOS) interface and vices, the DNI' component calls the I'ATJ lWORKS the 1/0 control block (IOCil) interface. The widely rea l-rime Scheduler (SCH) component. The SCH accepted NetriiOS interface is used by applications communicates directly with the DOS operating

Diy,ita/ 7i-clmical jo urnal I r>i. - i Xu. I \l" i111er /'}'}} 41 PAT HWORKS: PC Integration Software

system and the PC's timer and interrupt hardware to To achieve the performance, memory, and devel­ create a simple cooperative process environment. opment cost goals described earlier in this section, This environment includes sleep and wake cal:ls, we considered the following three approaches: and periodic interval timers. The fu nctions of th<.: 1. Rewrite the current DNP transport component SCH compon<.:nt ar<.: simil:.irto those pnform<.:d by true multitasking operating syst<.:ms, such as the 2. Write a new DNP transport component inC OS/2 system, which use preemptive scheduling. 3. Write a new DNP transport component in assem­ bly language Co nsiderations fo r a New DNP Rewriting tl1e current DNP component would Component Design not have produced a desirable amount of code com­ In previous PATHWORKS client software, separate mon to the DOS anclOS/2 versions. In addition, this teams implemented and maintained th<.: DOS and approach would have resulted in only minimally OS/2 versions of the DNP transport component. We improving the maintainability of the code. Writing decid<.:cl to use the same base source code for both a new transport component in C would have versions and thus reduc<.:dev elopment and mainte­ yielded a more portable code, but the performance nance costs. We then proceeded to consid<.:r our and memory usage would not have compared favor­ design options. ably with other vendors' transports. We decided to Originally, the DNP component was written in write the new transport component in assembly the C programming language. The internal architec­ language to make optimal use of the limited mem­ ture remained basically unchanged during the five ory available on today's personal computers. years following its release. This stable code should have been easy to port between operating systems. PATHWORKS Ve rsion 4. 1 DNP Howe,·er, the internal architecture of the OS/2 sys­ Transport Component Design tem was n<.:v<.:r considered in the original design Internally, the DNP transport component com­ b<.:cause this syst<.:m was not available until 1988. prises various moduks that correspond approxi­ Retrofitting the DOS version of the DNP component mately to the layers of the DECnet protocol suite, for the OS/2 operating system was difficult, and we as shown in Figure 2. Later in this section, we were not able to maintain a common source code describe the major DNP modules and how thqr base. cooperate.

APPLICATIONS USER REQUESTS

• NETBIOS IOCB• 1 INTERFACE INTERFACE � I J I I SCHEDULER NETWORK SERVICES PROTOCOL NETWORK ... EXECUTIVE I � TIMER TICKS DISPATCHER MANAGEMENT I I DECNET PHASE IV ROUTING � l --4 DATA LINK CONTROL � t I DATA LINK LAYER RECEIVED DATA PACKETS

Figure 2 Internal Architecture of tbe DL'Cnet 1\'etwork Process Componentfo r PA THWORKS Ve rsion 4. 1

42 Vo l. 4 No. I Winter /')')2 Digital Te chnical jo urnal OCCu c/ 7mmporl Arc/?ilccturc

Three t)'IKS of events can c:t u se tlK DNI' co m po­ link status block (LSB) <.la ta structure. and t he large nent to tT spond or to "wake up" user requests . <.lata buffe r (LDB) data structure received p ackets. ami timer ti cks. All of these events To queue events for p rocessi ng. the RFQ data are asynchronous. since thl:y arc generated by h;ml­ structure is a l l oca ted fro m a global i)OOI. Poi nters ware in te rrupts or u ser actions that arc not man­ to a user request or to netwo rk clara arc stored in aged by the op era t i ng wstem. Fach time tile DNP the RFQ structure and then placed on tile execut i ve com ponent pron:sses an event. \':triables and data d isp a t che r queue. The RE() structure is also usn! to structures i n ternal to the compont:nt change . ln describe unacknowledged da ta and to store events design i ng the component. \Ve h ad to e nsu re that in th e event log. t Ising the same pool for different the events wo ulcl not i n terru pt one another. purposes saved menHllT and d -creas -d tile m·erall To protect the data structures in a gener ic way, compiL· ity of the component. Figure :) i l l ust r:t tes a

all versio ns of the l'AT! !WORKS DNP component use t yp ical request queue to the c:\ecuriYc dispatcher.

a que u in g system called the executive. Asynch ro­ The execu t ive module reach each C\ 'l'llt, i c . col­ nous events arc q u e ued to the execu t ive mod ule. lection of messages or user requests. from the where a semapho re guards the dispatching and pro­ req u est q ueue and dispatch es the e,·cnt to the

cessi ng ro utines. The queue ami the s emaphore appropria t e hand ler mutinc. accord ing to cn·nt guara ntee t h e fo llowi ng: the receip t of a new event t1·pe The ro u tine then fu rther d ispat ches the lTC nl

do cs no t i nterrupt ongoing processing, ancl events to sp ecitic subroutines to handlc the indi,·idual

an: processed in the order in which t hev arrive. messages or requ ests. The lowest-level mutinc:-. Under the DOS operating system, the main loop keep netwo r k links ac ti ve ami transfer data to and of the executive module uses th e I'ATHWORKS from the remote system . SCI I co mpo nen t to "sleep," p rocess peml ing events. In prev i o us ,·ersions of t he DNP component. the and sleep again. Events that a rri ve while the m a i n REQ da ta structure consu med -!Hbytes d memory loop is executing arc simply placed on the queue. We red uced its si;e to 22 bytes lw c rt: a ting variant

Oper;tt i ng under tile DOS sYstem . on wh ich no records that contained only those data fields neces­

[)aekgmuml processing se n · ices exist, the DNI' sary to idc11lily the ti'J1t: of request

componen t uses the I'All i\VO!�KS SCI I componcm. The lSI\ data structure main t a in s the current st:t­

Since the OS/2 o pera t i ng system does prov ide a tus of a logical link In addition to t h e network s<:r­

bac kgrou nd processing env i ronmen t. the corrc­ vices protocol ( :\1Sl') nriablcs. the LSB st ru ct u re spo ml i ng \T rs ion of the DNP compo nent uses the stores o t her dat:t, i ncludi ng the queue of unac­ native background processi ng and sched u ling func­ knowledged data and the qu eue of outstanding tions of the OS/2 operating sYstem to perform the transmit :mel rece ive requests. Figure 4 i l lust rates same tasks. the conten is of t!JC I.SII ami associated data stru c­ tures for an active logi cal link. Data Structures The usn t·equests are :ttt:tched to queues on The DN!' transport component uses three pri m ary the logical link. For storage of unsent or unacknowl­ data structures to m a nage network links anu to edged data, thl: DNI' compo n e n t uses a 1\ FQ da ta transfer data: the request (1\LQ) data structure, the structure to point to an LDB datast ructure The JDB

REQUEST Q UEUE EVENT-HANDLER ROUTINES

P R OCESS IOC B REQUESTS DATA ..___ _..... PR OC E SS NETBIOS REQUESTS H EXECUTIVE D ISPATCHER PROCESS RECEIVED DATA PACKETS

PROCESS TIMER TICKS

PROCESS CONTROL MESSAGES

F(r.; u re 3 /)!\ P Fxecu tit •e Di.lj)Cf tcher Jiodule and lucom ing Request Queue

nip,ital'Ji• cf.mical]ournal I {,f. i .\'o. I 1\ 'iutcr !')').l 4:) PATHWORKS: PC Integration Software

APPLICATION MEMORY

SYSTEM MEMORY LINK STATUS BLOCK (LSB)

'

TRANSMIT TRANSMIT QUEUE I I TRANSMI T REQUEST (REO) I I REQU EST (REO) RECEIVE QUEUE -1

UNACKNOWLEDGED I DATA REQUEST DATA REQUEST DATA I (REO) (REO) RECEIVED DATA ·I I

NETWORK SERVICES LARGE DATA LARGE DATA i PROTOCOL STATE BUFFER (LOB) BUFFER (LDB) VA RIABLES I I

Figure 4 Link Stallts fllock and Associated Data Structures structun:s belong to the Ethernet or token ring data ware interface allowed us to use common code for link component and arc shared by other protocols. all of the modules that do not directly access the Before transmitting data, the DNP component allo­ data link. cates first an LDB data structure and then a RE<.>data The NSP module manages the transport protocol., structure that points to the LOR. The REQ structure including the buffering, flow control, and error is placed on the outgoing message queue of the I.SR recovery mechanisms. In PATHWO RKS version 4.1, structure, and the NSP layer eventually transmits we changed the buffering and flow control algo­ the REQ data. rithms to match more closely the types of traffic that PC network applications are likely to generate. In ternalDNP Mo dules .\'l ost users of the ;\;etB!OSint erface post receive The DNP transport component consists of various requests hcforctrans mitting a request for data from modules. We now describe the data link control a server. Some implementations of the NetRIOS (DLC) module, the NSP module, and the NetUIOS interface do not buffer rcccivecl or transmitted data and IOCB modules. inside the transport component, so applications The DLC module is responsible for communica­ must prepare to receive before requesting data tion with the Ethernetor token ring data link com­ from the server. To best manage the incoming data, ponent. Only the DLC module calls the data link, the DNP component of I'ATH\VORKSvers ion 4.1 uses and the differences between the DOS and OS/2 ver­ XON/XOI'F flow control for NetBIOS logical I inks sions are hidden in the DLC module to present a and segment flow control for logical links that usc consistent software interface to the rest of the DNP the IOCB interface. The previous version used seg­ component ment tlow control for both the NetBIOS and IOCB lb make the NSP and DECnet Phase IV routing interfaces. XON/XOff flow contro.l causes fe wer modules as operating-system independent as possi­ messages to be transmitted on the wire, especially ble, we developed a simplified software interface to in request/response session layer protocols, and is communicate with the Ethernet or token ring DLC most successful when the receiving node has a module. The Dl.C module calls the data link that is hufi'Cr ready to accommodate the incoming data. specific to the operating system. Providing the soft- Segment flow control is more robust ancl allows

44 IN. 4 •iJ. I IVilller 1992 Digital Te e/mica/ jo urnal /JI:'CJu:t 'lrampnrtAr c!Jitecture

the DNP component to better regu late the rate of tiaJJy points to the user's 1'\J C:B ami the beginning of incoming daL1. This method of tlow control can the user's data buffe r. be especial lv useful for non-request/response The NSP mml ule copies data into the !.DB data protocols such as those used in the DECwindows structures and queues these l.DBs onto the unac­ software. knowledged data queue. The amount of data The NctBIOS ami IOCB modules form the session copied derends on the size of the transmit pipe­ layers for the DNP component. In previous versions line, which is a network management parameter. of the D:"-il' component, the NctBIOS module was Each time data is copied into an !.DB data structure. layered on top of the IOCB interface. However, as the pointer advances in the transmit request queue. we mentio ned earlier in the paper. most popular When all of the data is copied into the LDBs, the network appl ications use the Neti\!OS interface. We user's transmit request is completed, allowing the decided to increase the performance of those appli­ application to continue execution while the DN!' cations hy designing the new DNP component in component transmits the queued data. such a way that the Neti\IOS module directly cal ls It the tlow control mechanism permits sending the NSP module data, the NSP module calls the routing layer to add We recognized another clement of the DNI' design rou ting heatlers. The data link control module then that could be improved Earl ier D1'\JPversions copied transmits the packets on the LAN. The remote net­ the user's NetBJOS request into a loca l data struc­ work system responds with acknowledgment mes­ ture for easy access. The ex tra resources required sages, which are placed on the request queue and to store ami copy the user requests tl iminished processed when the DNP component returns to the the overa ll performance of the DNP component. 'lb main loop. An acknowledgment message causes the improve performance, the DNJ' component now LDBs to be returned to the data link control module stores a pointer to the original user's req uest and ami makes space available on the transmit ripeline. manipul atl's tl1e re<..Juest directly. The NSI' module can then refill the transmit pipe­ Neti\JOS compatibility is one problem that many line by copying more user data into the LJ)B data vl'ndors face when writing network transport com­ structu res ami restart the transmit process. ponents The Nctl\JOS software interface is defined in several different specifications, ami many appli­ Results cations dq)Cnd on quirks and bugs in the design. We achieved ou r project goals for the DNJ> transport The 1',\TH\VORKS Net!\!OS interface must emu Ia te component in PATH\VORKS version -4.1 cl.icnt soft­ thesl' hugs com pleteh for certain applications to ware. The new design allowed us to reduce mem­ work properly. We paiLI carefu l attention to the bug ory usage, improve performance, and reduce reports from customns in previous versions of the maintenance cost. l'AT I J\VOI(KS software when rl'wri ting the NetJJIOS laye r to pn>vidc complete compatibility. il1emmJl Usage A Ty pical Networll Op eration \Ve reduced the resident size of the DNP compo­ nent from 'i:)KBto :):)KB. The reduction in the size To illustra te the sequencl' of events through the of the internal data structures frcetl up enough DNI' component for a typical network operation, memory resources to allow the ONP component considn the transmission ol (J 4 kilobytes (KB) of to handk over 200 concurrent network I inks. data through the NetlliOS interface. The application Previously, the DNP component was limited to that wishes to semi the data constructs a Neti\JOS 64 links. control block (1'\JCB) data structure and submits it to the Ncti\IOS soft\.varc intnface. The DN!' com­ ponent receives controL creates a queue entry for PeJformcm.ce the NCB structure, and then wakes the SUI compo­ Dy coding in assembly language , and optlmlzlng ncn t. Wa king the SCJ I component causes the main the path for sending data messages to the network, loop of the DNI' componl'nt to begin execution. perfo rmance was nearly doubled for small data TlK executive moduk checks the request t\'j)eand transfers. Small data transfers account for the dispatclws tl1e entn to the Netl\IOS module where majority of transfers in database applications. the transm it request is placnl on the logical link·s The graph shown in Figure ::; represents DEC:net transmit request queue. The transmit request ini- performance, measured in messages transferred

Dig,ita/ Ji>chnical ]o unwl I i1/ 1 .\u I I!. infer !'J'Jl PATHWORKS: PC Integration Software

per second, as a function of message size, ranging Debugging features were aclcled to the DNP com­ from 64 to 65,500 bytes. We include data for ver­ ponent in PATHWORKS version 4.1 that allow cus­ sions 4.0 and 4.1 of the DNP component. As the mes­ tomers to adjust their DECnet configuration easily sage size increases, the curves converge because and precisely. The DNP component now collects the Ethernet adapter's performance becomes the statistics on the maximum number of REQ, LSB, and limiting factor for throughput. Smaller message LDB structures allocated, and on the size of each sizes are typical in many industry-standard PC pool. Using this feature, we found that the ver­ benchmark programs and applications. sion 4.0 DNP component allocated nearly twice as The benchmark program used to calculate many REQ data structures as it needed under DECnet performance transfers data from one PC normal client workloads. As a result, we lowered to another as fast as possible, using fixed message the default allocations to fu rther reduce memory sizes. The hardware used in these tests consisted consumption. of 20-megahertz Intel 80386 microprocessors with 16-bit DEC Ether\VOH.KS Turbo (D£200) adapters Conclusion running on a private Ethernet segment. The DECnet transport component project fo r the version 4.1 release of the PATH\VORKS client soft­ Ma intenance Costs ware was a success; we came very close to our orig­ Debugging the common source code base for the inal goals for memory, performance, and software DOS ancl OS/2 versions is much simpler than for the development costs. In addition, many of the tech­ previous version of the DNP component. Since the niques, algorithms, and data structures used for this OS/2 version uses the memory protection features effort can be applied to fu ture network transport of the PC's Intel microprocessor, invalid memory development. references under the OS/2 version cause system traps that would not have been detected under the Genera/Refe rences DOS version. Nearly 90 percent of the code is com­ IBM NetB!OS Application Development Guide mon to the DOS and OS/2 versions of the DNP com­ (Armonk, l\TY : International Business Machines Cor­ ponent. The number of source lines was reduced poration, 1987). from 73,000 (the DOS version only) in PATHWORKS version 4.0 to 53,000 (the DOS and OS/2 versions i'vlicrosoft/3 Com Network Driver Interfa ce Sp ecifi­ combined) in PATHWORKS version 4.1. Rewriting cation, version 2.0.1 (Redmond, WA : Microsoft Cor­ the component also improved its compatibility poration, 1990). with third-party NetBIOS applications. PA THWORKS Programmer's Reference, version 4.1 (Maynard, i\'lA: Digital Equipment Corporation, 600 1991).

0 z 500 DECnet Phase IV General Description (Maynard, 0 () i\'lA: Digital Equipment Corporation, Order No. 400 a:� AA-Nl49A-TC, 1983). w a_ 300 (jJ Microsoft MS-DOS Programmer's Reference (Red­ w WA : � 200 mond, Microsoft Corporation, 1990). (jJ (jJ � 100 Microsoft 05/2 Device Driver Reference (Redmond, \VA : Microsoft Corporation, 1989). � 0 ��, �2 s�,_�5�1 2���2�.o�4�S r-�s . 1;92���32q,7�6�s� 64 256 1 ,024 4,096 16,384 65,500 MESSAGE SIZE (BYTES) KEY

• DNP COMPONENT IN PATHWORKS VERSION 4.1

0 DNP COMPONENT IN PATHWORKS VERSION 4.0

Figure 5 DECnet Network Process Component Th roughput

4 No. J 46 V!J! Winter 1992 Digital Te chnical jo urnal Andret.t' W. No urse I

Microsoft Wi ndows Ne twork Vi rtual Device Drivers in PA TH WOR KSfor DOS

Oigita (.; l� tll!lr'OI?K\ j(iJ· I)()S r·ersion 4. 1 personal conljJtrter illtC'g mtion sojiu ·are incl11des !u•u nefll'orl< l'irl!lctl der•ice drir•ers jiJr the .1/icrosoji H'ind(Jlt'S ellt 'iJ'IJII· nre11/. fbese drir•crs al/ou· Wi11dou·s ajJjJ /ical iu11s ojJemfing ill a fJrnlecledjmJCes sor nrode aJl(/ slalldrml I)()S ({jJjJiimlions ill cr t•ir/1/a/ nwcbine to mnunTen!I)'({ Ccess sen•ices desr�f!,nedto ru11 in real mode under the I)()S ojJemti11g S)'Sielll fi le 11eltmrk i•irliwl dei 'ice dril'ers. amila!Jie o/1/J ' i11 ,\licrosofi \Vi11dou•s enhanced mode. 11/(///· age OI:'C llef mal Sell!/().\ opemlious enid jJI!m lil thejitl/ /lSI! o{llwse inteJfaces.

\l icrosoft \Vindo\\ S ' irt ual de\ icc· drin·rs :tre loall­ Microsoft Wi ndaws Environment

' \ · :tbk· so l t \-:trt nwdu lc� th:lt c·\tcml the \V indcm s Thc Microsoft Wi ndows environment is a graphical. operat i ng S\ stem :tnt! enable it to su pport pniph­ multiapplic:t tion s\·stem for p e rsona l computers s eral de,· ices. llll'l1lon· reso u rce . and so ft \\ :11-c that use the Intel H02H() or h igher microprocessor. : appl icl l i o ns. Some ol' these modu les allow tpplica­ Fo r 8028()-basnl S\ stem s. the Windows s,·stem rions that opnate i n dift(:rent processor mo des opera tes in its standard mode. usi ng the real a mi s w i th co rre po nding ditk:rc nccs in memorY access protected processor modes. On thc 80:)8(> or h ighe r :1 to con1 munio tc with vne another in network sys­ m ic roproccsso r. the \V inclows svstcm on :tlso opn­ tl'lll . : D igi t t l s 1'.\TI J\\C>l\KS p ro duct:;make it possi bl e are in irs enhanced mode. usi ng both protcctccl and c to integra te pe rso na l computers into !o t ! or wide virt ual processor modes. Enhanced mode allows s,·stelll.s. :trca nu" ork The 1'.\TI I\\ORKS tor DOS soft ­ the \Vindm vs system to fu ll\' ut il izc processor t<:a­ \\ :t rc· incl ullcs two net \\·ork \' irtual du i ce dri,·crs. tures such as Yirtual memory and multiple virt ual which m a nage· D!Cnct and n e t \\'ork basic 1/0 S\ s­ m:tchines. Vi rtual deYice tlri, crs arc a\ :t il:tble onl\· till' s tem (Net I \lOS) ope rat i ons in ,'vlicro o lt Windows in th is cnh:lll ced mode. environ ment lor J>Cs. This paper begins with a discussion of the Basic Processor Op erating 1Vlodes s c :\ I icrosolt \V i nd ow em· i ron m n t fo r which the Al l mc mbns of the HOxH(> fam i h . including the J>AJll\\OJU..:s lor DOS produu proYidcs nctwurk H0:)8() microprocessor. ca leu Ia re add rcsses in mem­ crs. Yirtu:tl de\ icc dri\ The basic proccssor operat­ ory \w using a segment reg ister and :tn offs et. ing modes :tnd the ,\l icrosoft Wi ndows opcrating llowe,·er. the method for calculating the pll \ si ca l s modes :trc dc cri bnl . prepar:tton· to an <.: :-.:plana­ acldrcss varies, de p en d ing on the pro cessor lllOLic. ,V\ icrosolt 1 tion of \X i ndow.s en hanced modc. Th is The basic processor operating modes arc real mode. t cx pl:llla ion i.s e.ssen ti:tl hec:t usc ,·i rtual dcTice pro tected mod e. and ' i rtua I mode. dri\LTS opera t e onlv in enh:lllced modc. Next. the paper det ails the c:t pabil i t ics ol virtual Ne{J/ Jlodl' Thi s mode is usn! lw rllc DOS oper:tr­ dc,· i cc dri,·cT.s. such :ts pro,·iding tllc mc:tns for ing system exclusive!\ and 11\' most DOS a ppl i c:t­ \Vindm\ s :l lld DOS : t p pl icatio ns ro co mmu nica te. tions. The processo r calculates physical aLklressc.:s lhc lo cus then tllrns m t he cnYironmcnl for til'n:l­ hy shifting t he u>ntc·nts ot a l()·hit segmem register oping \l i cmsolt \Vimlm' s ,- irrual de,· ice driHTS and left by -1 hit s and adding a \()-bit o ffset . Therefore.

concludes with a descri pt io n of the· srntcture ami onh· the.:ti rst \ mega\)\'te (.\Ill) p l u s ()').')I'-) bytes of a I'Cs c fu nct ionalit\ of the two ill'l\\'\)J"k dn icc: d ri vers pJl,·sical mcmorY :tr<.: diru:tl\ a cessible in this included in t he l'AJ'!J\VO J{KS for DOS software. mode.

DiJ.;ilal kciJIIicul jourual I rd. -i .\'u. I II illl<'l' I'J').! PATHWORKS: PC Integration Software

The basic layout of PC memory is shown in the offs et to the linear address obtained from the

Figure 1. The first megabyte of physical memory is appropriate descriptor table. The 803H6 implemen­ known as conventional memory. This area may tation diffe rs from that of the 80286 because the

include the PATHWORKS impkmentation of the 80386 processor offers both 16- and 32- bit general

DECnet tra nsport protocol , namely the DECnet registers and offsets, whereas the 80286 processor

Network Process component, as wel l as other mem­ has 16-bir general registers and offsets.

ory- resident software. In addition, conventional In protected mode, if paging is disabled, the lin­ memory may contain the DOS opera ting system and ear address is the physi cal address. If paging is DOS applications. The next 65,519 bytes are cal led enabled, the linear address is decoded into a page the high memory area. Bank-switched memory, directory entry, a page table entry, and an offset. known as expanded memory, may also be available. The page d irectory entry identifies a page table, and In real mode, memory protection ami virtual mem­ the page table entry provides a physical address. ory are not available, i l lega l instructions are gener­ Protected mode is used by applications that use ally ignored, and 1/0 instructions are always DOS extenders to access memory beyond that allowed . which is accessible from real mode. 80386 proces­ sors operating in protected mode may use virtual Protected Mode In this mode, a segment register memory. In this mode, an illegal instruction causes contains a selector. Part of the selector is an index a processor trap, and 1/0 instructions may be selec­ into a descriptor tabk maintained by the hardware. tively allowed or trapped. A flag in the selector indicates which of two descriptor tables to use, the local descrip tor table Vi rtual Mode This mode i mplements a virtual or the global descriptor table. The processor adds machine that em ulates the behavior of an 8086

microprocessor. Address calculation in this mode is similar to that in real mode, except that in vir­

tual mode the result of the sh ift -a nd-add opera­ tion is a linear address. The processor converts

this address to a p hysical address, as in protected mode. Processors operating in virtual mode may usc virtual memory. Also, each virtual machine can

have a separate page directory, an illegal instruc­ EXTENDED MEMORY tion causes a processor trap, and l/0 instructions

may be allowed or trapped .

Micrusujt Wi ndows Op erating Modes The Microsoft Windows environment supports sev­ eral operating modes.

1 088KB HIGH MEMORY AREA \flindows Real Mode Similar to previous ve rsions 1024KB VIDEO MEMORY of the Windows system, Windows 3.0 can opera te in EXPANDED MEMORY PAGE FRAME rcal modc, i.e., use conventional memory, expanded ADAPTER MEMORY memory, and the high memory area. This mode is 640KB AVAILABLE not s upported in Wimlm.vs:). 1.

CONVENTIONAL DOS APPLICATION MEMORY Windows Standard Mode Windows 3.0 and 3.1 can operate in standard mode on the 80286 or higher OTHER RESIDENT SOFTWARE microprocessor. This mode uses the p rotected DECNET NETWORK PROCESS processor mode, but does not take advan tage of the 32 -bit fe atures of the 80386 processor. The DOS OPERATING SYSTEM Windows system and Windows applica ti ons are located outside conven tional memory, except for code necessary to provide the communication Figure 1 Basic PC Me mory Layo ut links wi th DOS and other resident software.

48 Vo l. 4 Nu. I Winter 1992 Digital Te cbnical]ournnl Microsoft Windows Network Vi rtual Device Drivers in PA TH WORKS fo r DOS

Standard DOS applications run in real mode and cations run in protected mode, whereas virtual occupy the fuII screen, as if the Windows system mode provides support for the DOS applications, were not present. Switching between Windows which need not even be aware that the Windows and non-Windows applications is accomplished by environment exists. performing a sequence of keystrokes in exactly the same manner as under the MS-DOS version 5.0 task VirtualDevice Driver Capabilities switcher. Virtual device drivers are not used in stan­ Virtual device drivers provide the means for dan! mode. Windows and DOS applications to communicate, support asynchronous operations, virtual ize hard­ Wi ndows Enhanced Mode In enhanced mode, the ware ports and interrupts, and directly handle hard­ Microsoft Windows system provides each non­ ware and software interrupts. These capabilities Windows appl ication a virtual machine in which to are described in the following section. operate. These machines are preemptively multi­ tasked, so even compute-bound, non-Windows Communication between Protected-mode arplications can run in the background. The and Real-mode Software Applications Windows system and aU Windows applications A virtual device driver provides a bridge between share a single virtual machine so they can commu­ Windows applications running in protected mode nicate with each other. and DOS terminate and stay resident (rSR)appl ica­ The Microsoft Windows system uses the pro­ tions written to run in real mode with no knowl­ tected and virtual modes of the 80386 processor. edge of protected mode. A Windows application Paging is always enabled. The first plus 65,519 1MB that calls an application programming interface bytes of the linear address space is mapped to the (API) passes it a valid protected-mode address. first plus 65,519 bytes of memory belonging to lMB Without virtual device drivers, the real-mode soft­ the virtual machine currently executing. This map­ ware would interpret this address as a real-mode ping allows each DOS application its own block of address, usually pointing to a location within the memory in which to run. DOS operating system. A virtual device driver can Some data must be shared among the virtual map the memory into conventional memory and machines. Whenever all or most of the data in a change the addresses so that the real-mode soft­ page is shared, a global page is used. Most resident ware correctly accesses the caller's data. The vir­ software that was loaded before the Windows sys­ tual device driver should enter a critical section to tem start-up is stored in global pages. Selected data avoid task switching while calling real-mode soft­ within these global pages may be maintained sepa­ ware that is not reentrant. rately for each virtual machine. This practice is called instancing and may be requested by the resi­ dent software. Co mmunication between Tra nsient DOS To support operations requested by vinual Application Software and Global Resident machines, virtual device drivers extend the DOS Software Microsoft Windows kernel. The drivers are loaded Most DOS application software ami DOS TSR soft­ at Windows initialization and effectively become ware is not designed to run in the Microsoft part of the kernel. Windows environment. While executing, a DOS The Microsoft Windows enhanced mode kernel application is mapped into conventional memory. uses 32-bit registers and offsets.The segment regis­ If the application calls resident software, and a task ters are loaded with selectors that allow access to switch occurs while an operation is in progress, all of memory when the kernel is operating and data would be delivered to the wrong application. eliminate the need to break code and data into There are two ways to hand le this situation. The 64-kilobyte (KB) segments of memory. This mem­ virtual device driver can enter a critical section to ory model is known as the flat model. disable task switching until the operation is com­ Although the Windows enhanced mode kernel is plete. This approach works well for synchronous written to use 32-bit registers and offsets, most of operations that never take a perceptibly long time the remaining libraries supplied with the Windows to complete. system ami nearly all applications are written to However, the system does not respond to most use 1<)-bit registers and offsets. The Windows appli- user input while the virtual device driver is in a

Digital Te cbuical ]o urual VrJ/. 4 No. I Winter 1992 49 PATHWORKS: PC Integration Software

critical section. Consequently, for long synchro­ advanrage. If the resident software is removed, nous operations, the end user of the application more memory is then available to DOS applications may believe that the system is hung. If the rea l­ running in the Windows environment. mode software supports asynchronous operations, the virtual device driver can convert the operation Development Environment to an asynchronous call. Handling the situation in The Microsoft Windows system includes virtual this manner requires that a critical section be device drivers. Microsoft also has a device driver entered only for the time it takes to queue the development kit specificallyfor ueveloping virtual call, and then only ifth e real-mode software is not device drivers. 1 This section uescribes the envi­ reentrant. ronment for developing and debugging this driver software. Supportfo r Asynchronous Op erations Asynchronous operations, whether in real or pro­ Development To ols tected mode, require that the virtual device driver Currently, virtual device drivers are written in be able to buffer data in a memory pool that is assembly language because higher-level language mapped into every virtual machine. In addition, the compilers generally lack the ability to generate driver must set up a completion callback routine to code with _32-bit offsets and registers. A special wake up the virtual machine that made the request, 32-bit assembler and linker are provided with the deliver the data to that virtual machine, and trans­ Microsoft Windows device driver development kit. fer control to a caller-specified callback routine, if necessary. Debugging To ols Virtual device drivers are debugged using the Vi rtualization of Ha rdware Po rts WDEB386 software module. This debug tool and Interrupts requires that a terminal or equivalent be connected Another function of virtual device drivers is to vir­ to one of the communication ports on the PC; the tualize hardware ports and interrupts so that the debugger performs its I/O to that communications Windows system can successfully emulate several port. Symbols are available in the debugger, but 8086-based machines at once. Each virtual machine source-level debugging is not provided. runs a DOS application that assumes it has sole use To take fu ll advantage of the WDEB386 capabili­ of a machine. DOS is a minimal operating system ties, the debug version of the Microsoft Windows and does not provide much of the functionality WlN386.EXE module should be used. This version required by applications. Therefore, most DOS appli­ contains many featu res essential for investigating cations bypass the operating system except to the behavior of the Windows system and, in par­ access the fi le system. It is common for an appl ica­ ticular, for debugging virtual device drivers. The tion to set up its own interrupt handlers and to read features include commands to display the registers, and write hardware ports. If several applications the stack, and the control blocks for each virtual in separate virtual machines were to attempt these machine. Many of the virtual device drivers operations at the same time, the applications wou ld included with the Windows system, and the two interfere with one other. A virtual device driver can included in the PATHWORKS for OOS product, have a trap access to hardware l/0 ports and regulate debug entry point that may be invoked by entering access to the actual hardware. the period keyboard character, followed by the name of the virtual device driver. Two particularly Direct Ha ndling of Ha rdware or Software useful debug entry points are .YMM and .V86MMGR, Interrupts which provide detailed information about memory The virtual device driver can provide the fu nction­ usage for each virtual machine, including the use of ality of real-mode software. If the user has no need expanded memory and the high memory area. to run this software outside the \V indows environ­ WDEfl)86 can be used successfully in the Windows ment, the software can be removed from memory. environment to debug virtual device drivers and to Removing the real-mode software reduces the need diagnose bugs in the read-only memory basic l/0 for context and mode switching, mapping, and copy­ system (ROM BIOS) and other resident real-mode ing, and thus offers a considerable performance software.

50 Vo l. 4 No. I Winter /')'Jl Digital Te chnical Jo urnal \lfcmsujl \\ iudoii'S .\eltmrk 1/'r/t((f/ Oe/'ice /)rit·ers in FITIH\ ONK.\jin· nos

The CodeVinv lor Windows lkhug tool is tical onh· ror those users who access the net­ intcndnl for debuggi ng applications and lh·n:tmic work exclus iYeiY 11 hilc operat ing in a .\·l icrosoft link libraries. not for de hugging 1 irt u:tl dn ice \X findo11·s cn\·ironmcnt. dri1 crs. l lowenT, the CotlcVicw ami WDEII.-)H(J to ols ctn he used simultaneously to diagnose problems Initializa tion th:tt occur wlll'n applic:tt ions c:tuse tile \V inllows Vi rtual d c1· iet: dri,·ers :tre cal it'd sc1 eral times dur­

SYstem to fa il. ing \V i llLim1·s ini ti:tl i 1.:1t ion. \X ;h i lc the \Vi ndoll s s1 s­ tem i.s st ill operating in real mode. the \'D,'\I·T ami The Ne twork Virtual Device Drivers VNt:TIIIOS moduks check to SLT il the resident

The I 'At ! JWt lt\h:S lor nos sort ware prm·ides two network soft ware is loadnl. If it is not. there is no .\l'l.'i fo r t:tsk-to-L:t.�k nl'l 11·ork com nwnic:ttions. reason to load these dri,·ers. A Y:tlue is returned that One is :1 DlcCill'l socket-based interface. which uses abOrtS the loading of tile uril'l'rS but direc ts the :111 argument block called :tn 1/0 control block Windows S\'Stem to continue lo:td ing. (lOCI I). Tile othn is the i nd u�t r1·-st and;trd PC : nct­ After the \V indows system L· nters protected \\·orking interface. �l'tiiiOS. 11· ith some c.\tcnsions moclc, tile dri1-ers arc cal led ag:t in tl uring e:tcll suc­ prm· i dctl b1· l)igit:tl to support 11· ide :tre:t lll'tii'(Jrks. cessilc phase of initialil.a tion. L:tch ,- irrual de1 icc

The ,'..JctiiiOS interLtcc tt.scs :111 argument block dri1·cr takes COntrol or the sort \\ :liT interrupts USetl c:t l lnl tile Nc·t iiiOS control block (NCB). !loth intcr­ for its tTSJ KUivc i\ 1'1, reserves space in the control LttTS :tre fu ll\ supj)Ort nl in \V indmYs enhanced block of each ,·irtual machine. olllains par:tmcters SYSTDII:\'1 Ill otic. from the file and :tllocatcs a pool of l)igital's 1',\l l i\\OHKS lor DOS n: rsion ·t.l includes global mc mon for l'\Jilllllunicttion with till' real­ 1 wo l'irtual dev ice drivers to support net working: mode resident net working sort w:tre. hgurc 2 illus­ \' D\!LT. :)H(J, wh ich hand ks I li:Cnct socket ca l ls. tra tes a s1·srem 1·irr ual mach ine and a 'irtual :tnd \ '\E'I IIIOS 5H(J. IY hich ll:111d les NctiiiOS ca lls. machine running a DOS appl ic:ttion. The figure ,\ ltlwugll the\· support d i llc rcn t ,\Pis. t11L'sc two ,·ir­ ShOll'S tile pOOl of Uln\·cnt ion:tl nll'!llOr\' tll:tt the tual tk,·ice dri1Trs arc simil:tr in structure. The dis­ virtual device ll ri ,·cr allocate:- as global memory. cussion in this section :tpjll ies to both drinTs Tile liri,·crs pcrforn1 a "sanitl check" to l'lTi f�· unlc.ss other11 i.sL· notell Thc.se dri,·ers arc included that the 1 irtual dc1· ice driYer c:t n distinguish global 11 ith the cmre nt 1'.\TI I\\tll{h:S n: rs ion i.l j)rod­ lll Cnl

Digit:tl Equipment Corporation :ts the dcvcloptT perform this clH:ck cttl !'ail when running on some ol the drin:rs . .\1 icrosoft tTq ucsted tlut the modu il' common unsupportl'll soft \\·;trL· contigurations. nalllL'S \ 1)'\ \T .-) H(l and \''\J:T\1\0S.)H(l he ch;tngcd At this point, if the sa nit\' ciKck ra ils. till' dri\Tr to DI·:< ::'\ET.-)1-)() :tnd DEC.'\11 ',H(l, respccti,·c iY. in dispJ:t,·s a message to ath·isc the u�c'l' to e.\ it the \V inliows system Windows version :). !. In this paper, the nomencla­ turL' \'DNET and \';'!FTIIIOS is used to rein to these t 11 0 moduks. Virtt /{/fi.?:cttion of' Ihe Netl/'ork A Pis

TilL' Llri,·crs inn>ke the rL·:tl-motle net11·ork soft­ \Vhu1an applica tion i.s.sucs a soft ware intnrupt for vv:t l'l' in the 'ir tual machine that t't'lJ U<.:stcd the a OECnct or NeliiiOS calL tile appropriate 'irtual operation Ct'l':tting a "net work 1· irtual machine" deYin: driver gains control. If the ;tpplic:t tion mak­ to 11 ilich the dri1 cr IH>uld route all net 11 ork actil·­ ing the c:tll is in protected mode. tile Yirtual dc1·icc i\1 11·oulu h:ll c allo11·cd most of the nct ii'Ork sot't· drin:r ahv:tl's maps the c:tll in llll'lllOI'I'. OthtT\\ isc, wa rL· to be loaded into a sing[(: l'irtual maclline the dri\'lT software checks tile control block (i.e.. aJHI thus !'reed up conH·n tional memory ror non­ the IOCB or the NU l) and the bttrkr :tddresses to \Vimlo11·s applications. I lo11 ·cn:r. u�i ng this design determine iJ the' arc st ored in glob;tl memon. i.e.. \\'< >uld ha1·c incurrul thL· mcrhL·ad of .s \1·itcl1ing on mapped identically in t·,·erl' ,· irtu:tl macilinc. JJ so. 1irtu:tl 11l:tchilll'S ror l'\ t' f\' lll't WOrk :tl'l'l'SS. timer tile \'i rt u:tl de1·ice dri,·er does 110t map tilL' cal l, tick. ami net work hanlw;tJT interrupt. In addition, because it will cxLTutc properly without mapping crc:tting a net 11·ork ,· irt u:tl machine wo uld ila1·c rcquirnl tll:tt tltc tiara link Ja,·er :tllll tile DECoct API .lhtjJf!in,r:. If the control block ;tnd tile hufkr '-Cilnluil'r he c:q):t[)[e o( pcr t'orming the 1· irrual addresses :tJT not stored itl global mcnHJ n·. map­ nl:tcilinc sw itch. l'inal ly, this design wo uld he prac- ping is ncccssaJ'\'. The \'i rt u:tl dc1·icc dril'cr

l)igilal li't'/)llical /IJIII'IIlll Itt!. I . \11. I 1\ ill/('/' I'J')J ')J PAT HWORKS: PC Integration Software

SYSTEM VIRTUAL MACHINE VIRTUAL MACHINE I RUNNING A I DOS APPLICATION I I I I I I I I

I I EXTENDED WINDOWS APPLICATION I I MEMORY I I I I I

VDNET.386 VIRTUAL DEVICE DRIVER

1088KB HIGH MEMORY AREA HIGH MEMORY AREA 1024KB VIDEO MEMORY VIDEO MEMORY EXPANDED MEMORY PAGE EXPANDED MEMORY PAGE FRAME FRAME ADAPTER MEMORY ADAPTER MEMORY 640KB AVAILABLE AVAILABLE

DOS APPLICATION DOS APPLICATION

TOP OF CONVENTIONAL GLOBAL MEMORY MEMORY AVAILABLE HOOK � CONTROL BLOCKS MAPPING AREA I OTHER RESIDENT SOFTWARE

DECNET NETWORK PROCESS

DOS OPERATING SYSTEM

Figure 2 Microsoft Windows Initialization allocates a hook control block to the operation. tion is complete. All other virtual machines con­ This control block resides in global memory and tinue to run while the network I/0 is in progress. IOCB includes an or NCB, which the virtual device This design prevents the operation from monopo­ driver passes to the resident networking software. lizing the entire system. The driver globally maps the caller's buffe rs in the mapping-space pool allocated at initialization. Asynchronous Calls If the call is asynchronous or The IOCR or NCB embedded in the hook control has been converted to an asynchronous call, the vir­ block contains addresses changed to point to the tual device driver must establish a callback in order remapped address in the mapping-space pool. The to be notifiedwhen the call completes. Because the call back (post) address is set to the callback routine virtual device driver runs in protected mode and in the virtual device driver, so the driver is called the resident network runs in virtual mode, a spe­ when the operation is complete. cial type of callback is required. The virtual device Optionally, if the operation is a blocking call that driver uses the Windows Allocate_V86_Ca llback takes a long time to complete, the virtual device service to obtain a real-mode pointer to an instruc­ driver may convert the operation to an asynchro­ tion in global memory that causes a trap when exe­ nous call. In this case, the driver sets an internal cuted in virtual mode. The Windows system flag, HF_Suspend_Until_POST. and does not return handles this trap and transfers control to the virtual control to the calling application until the opera- device driver in protected mode.

'52 Vo l. 4 No. I Winter I'J'Jl Digital Te clmicaljournal Jficrosojt Windou ·s Net ll'ork Virtuo/ /)el'ice /)ril•ers in fJAJ'IIW()!

bll·o!.'inl!, t/Je .Vet/l'ork Process The ' irtual de,·ice drin:r com-erred to ;J n as\'11Chronous call. If so. dri,-cr i:; no'' prep;trnl to pass the c;ill ro the real­ control must not ru urn to the calling applicat ion mode networking software. The drin:r elll<:rs a until the opera tion is compl<:te. Normal ly. th<: call­ critical �<:nion to anlid rt-cntrance prohlcms and b;tch: routin<: in the dri,·cr is c;illnl at this time. ca lls the Simulat<:_Hct l-.\-lmlc_lnterrupt sen ice to Howe,·er. certain i\: <:tii!OS nror conditions cause invoke the net work process as if il were b<:ing the operation to return immcdiatdy without call­ innlknl in ret I mode The 'irtual de,· ice drin-r ing tiH: Gtllhack routine. Therefore. tilt Net iiiOS \ir­ lea,·c.� the critical sel"l ion when the simulatnl inter­ tual dt·,·ice dri,-cr checks ti1L· status of the c:tll. rupt returns If the operation is not as\·nchronous. If' the call is still in progrt·ss. the requesting vir­ the caller's IOC!l or .'\ Cll i:; updated . bu ftns arc tu;tl machine relinquishes its allocated time and unmapped. and the hook control block is freed. retries when the process wakes up. This design pro­ Figure _J., shows a :v l icrosofr Windows call to the tects the process from being awakened prema­ net \\ ork. intcrccpll'll hy the Yirtual de,· icc drin.: r ture!\· b\· another ' irtual de,· ice dri ,·cr. Also. some ami p;tssed to the network proc<:ss. NetBIOS req uest errors cause the NctlltOS software interrupt to ret urn immediate!\· and do not transfer (;o/1/)(fck l

SYS EM VI R TUAL MACHINE VIR UAL MACH I N E I R U NNING A I DOS APPLICATION I I I I I I I I WINDOWS APPLICATION ------� - ,. ---� CALL TO I I TH CAL LBACK O I I I I NETW R K I CO TROL I N B UFFE R I I I 11BL0OC K I I I ARGUMENT - I I I I BLOCK \.\. PASSED ' ------�� ------i-----: I I CALLBACK I 86 VIRTUAL D VICE DRIVER 088K B � f HIGH MEMORY AREA HIGH MEMORY A EA 0 2 4KB R VIDEO MEMORY VIDEQ MEMORY E XPANDE D MEMORY PAGE � AN D D MEMORY PAGI . rRAM R A� ADAPTE R MEMORY �AP1 ER MEMORY 640KB AVAILABLE '\\! AVAILABL E

DOS APPLICATION � LIGAT ION TOP OF I GLOBAL I M Y O M E OR AVAILABI_E HOOK ALLOCATED HO K I \_J � CONTROL BLOCKSll CONTR OL BLOCK BUFFI .I l I · I I I I MAPPING AR EA L ___,. ___ 1

OT HER RESIDENT SOFTWARE'

DECNET NETWORK PROCESSY DOS OPE RATING SYSTEM

f-igure 3 !Ju•okiug tbe Nctn·ork J'rocess

Di!!,ilnl Te clmicnl jounwl I;,/. 1 .\'u. I l\"illll'r /')1!l PATHWORKS: PC Integration Software

The Suspend_VM service can be used to block a process restores the caller's context before updat­ virtual machine during such a call. However, sus­ ing the caller's data. pending a virtual machine requires that the system As shown in Figure 'i . the event routine updates call every Windows virtual device driver to notify the user's argument block and calls the user's call­ it of the suspension. The notificationprocess con­ back routine. Finally, the virtual device driver stitutes a high-overhead operation and is therefore unmaps the buffers, frees up the hook control block, unsuitable for this use. and returnscontrol to the calling application. If the operation is asynchronous, the system transfers control to the virtual device driver call­ VirtualMa chine Te rmination back routine when the operation is complete, as When a virtual machine terminates, all virtual shown in Figure ·t This routine calls the Windows device drivers are called to perform cleanup. The scheduler to wake up the virtual machine that network virtual device drivers check for outstand­ requested the operation. The \V indows event ser­ ing network operations to the virtual machine that vices are also calkd to invoke the event-handler is being terminated. All such operations are can­ routine in the virtual device driver when the celed, ami a warning message is displayed to the requesting virtual machine is scheduled. In this user. Windows applications execute in the system way, the virtual device driver regains control. This virtual machine, so their outstanding network

SYSTEM VIRTUAL MACHINE VIRTUAL MACHINE I RUNNING A I I DOS APPLICATION I I I I I I I WINDOWS APPLICATION I I ,-1 CALLBACK I I I CONTROL -� I 11BLOCK/0 1- BUFFER I : I I I I I ! I ALLBACK I � 1- VDNET.386 VIRTUAL DEVICE DRIVER • 1 088KB HIGH MEMORY AREA HIGH MEMORY AREA 1 024KB VIDEO MEMORY I VIDEO MEMORY I EXPANDED MEMORY PAGE EXPANDED MEMORY PAGE FRAME I FRAME ADAPTER MEMORY I ADAPTER MEMORY I 640KB AVAILABLE I AVAILABLE • I DOS APPLICATION1 DOS APPLICATION I TOP OF I GLOBAL I I MEMORY AVAILABLE HOOK ALLOCATED HOOK [ BUFFER CONTROL BLOCK �- CONTROL BLOCKS '·: --- I I I I I MAPPING AREA I OTHER RESIDENT SOFTWARE

DECNET NETWORK PROCESS

DOS OPERATING SYSTEM

Figure 4 Callback Routine

'i4 lit)/. ·i No. I Winter !(J'J.! Digital Te chnical jo urnal .�!icrosojt Hiudnu·s Netu·ork Vir/11({/ /)et •ice /)ril 'ers ill n� lli \H}NI\S jrll' !)()S

o[wrations. il' :un·. arc canceled \d1l'n tile ti.snc:-o: its net\\·ork sLT\ ices a\ ailable to the \V imlo\\·s kernel. l'mm tile \V imlo\\ S s\ stcnl . \ict\HJrk O[WLltions b\ to \Vindo\\ s :tnd non-\\ .indo\\ s applications. ami

resident solt \\·arl· :tiT not canceled " hen :1 'irtual to other ' irtu:tl Lie' icc Llri, ers. IlK 'irtual Lin·ice m:tchinc terminates. dri\ crs inclulicli in the J',\Tl l\\01\KS lor DOS soft­ ware product permit fu ll usc or tile lli·C:nct :tl1li Oef)l[gginp, b!IJT Po ints NetBlOS ,\ l'ls, including Digital-specific ntcnsions Tile VDNFT ami V'\111\IOS network 'irtual de\ icc to the i'ktBIOS interlace, in the !Yl icrosoft \V imlows li ri\ ers prm ide debugging cntn point� for usc h\ enhanced mode en\' ironment. tile \\ imlo\\ s knncl llch uggcr. These entn [)()ints

gi\ C :1 fu rnLLltni li ispl;t\ o( tile hook COJ1lroJ hJock Reference tor each hooked Ill'l \\ ork call in progress. Tile l. Jliuosojl \.\inrlnu·s !)e cice /)et ·elnjlliiCJtl 1\it­ dispLt\ includes tile requested fu nction. huller l 'ir/ tto/ nct·icc .!doptotiou (lt t ide (l�nlmoml. :tLklress. the !Jand iL· ol tile 'irtual machine from \XX :V\icrosoJt Coq)oration. 19l)( )) which tile ca ll was IT qucstnl. the ,·irtua!-JJLtcllitK­

specilic aLill t-css ol.ti le ca ller's argument block. and

llags The lbgs included in the debugging d i spl a\· General Refereuces inLl icatc till' sLtte ot till' operation. as slHl\\'n in hilef 80.)8(, 1/{fJdtt·orc Ncfc'rcncc .\htttttlll (Santa T: thlc l Clara. C\ : lnll'l Corporation. 19H-)

.vH:ciol API I:'illl)'Po int Intel 80_ )8(! flrup,iWJttJier�,- Nefc'i'CI/Cc .\liutttrtf (Santa Clara. C\ Intel Corporation. l9H- ). Tile \ D:\FT Ill'! \\ ork ' irtual deYice drin-r prm iLks ;\ l'l an entn point that allmYs application .s olt\\'are lnte/ 80_ )86 .'lystctJt 1\'r iler'sGu ide (Santa Cl:tra. CA: to determine what ,-n.sion of the VD1N I:T driYc t· is IntelCorpo ration, l9H'). lo:tLlnl This !unction is a\ ailahle to bot h protected­ mode and rc:tl-nwL!c :t[Jplications.

Su mmaiJ! 1'.\1 11\\(H\KS nu \\ ork 'irtual dn·icc Li t·i\ ers c:-o:teml

till.. \lin osolt \\ inLlo\\ s cnl1anceLI nwLic L' n\ iron-

11ll'llt to support most hardware that can he inst:illcd in a personal computer These dri, ers also support all �olt ware that can run under the I lOS O[WLt ting S\ Stctn. including soft w:ttT that [ ),passes the opl·r:tting .s \ stcm to access the hard­

'' arc Ll i rcct h ..\let " ork ' i rt ua I lin icc Ll ri nTs ma kc

Ta ble 1 Flags Included in the Debugging Display

Flag Indication

HF_ Wait For _! RET Cleared when the DECnet Network Process component returns to the virtual device driver.

HF Wait__For POST Set if the virtual device driver callback is required; cleared when the virtual device driver callback is called.

HF Wait_For Sim_POST Set if the caller requested callback; cleared when the caller's callback retu rns.

HF_POST_Crit Set while in a critical section.

HF_ From_ PM Set if the caller was in protected mode.

HF_Canceled Set if the operation was canceled.

HF_Ca nceling Set if the operation is being canceled.

HF_Sus pend_Until_POST Set if the operation is a blocking call that is being simulated using an asynchronous call. Do not return to caller until the operation is complete.

Dif.!,ilal Jeclmict1/ Jourua/ I i1/. 1 \n. I ll u!ler !')').} Dennis G. Giokas Andrew T. Leskowitz eXcursion fo r Windows: In tegrating Tw o Windowing Sy stems

Digital's eXcursion fo r Windows display serwr is (/II applicutirm fo r Microsoft Windows. The eXcursion )in· Windows product is based on the X Window Sy stem and allows X client applications to displc(J' output, receiue input; and exchange data in tbe Jlicrosoft Windows enuirull/1/elll. 1be eXcursion sr!ftu·are visually

integrates the X and Microsr�ji Windows enuironments-app lications fr om both environments display on a single screen and haue tbe same appmmnce. A key com­ ponent of Ne twork App!icnfions SujJport (\�1.)) and Digitals PC integration pro­ gram, the eXcursion fo r Windows display sert>er enables information exchange among PC users and n011-PC users linked throughout a net work.

The excursion for Windows softwJre is a display and 2. This architecture is hardware and software server hast:d on the X Window System version 11, system independent. It allows X applications, or release 4 protocol and implemented as an appl i­ clients, to execute on any processor and display on cation for Microsoft Windows software. eXcursion any device in a distributed network. allows Xll client applications based on any Xll X applications are linked with toolkits and toolkit to display output and receive input in the libraries that include windowing controls, user inter­ Microsoft Windows environment. The t�vo window face objects, and graphics capabilities. The X tool­ environments are seamlessly integrated. Microsoft kits also include interprocess communications Windows software provides the window managt:­ capabilities that proYide data interchange between ment for X Window System applications. The the application clients. Figure 2 presents some of eXcursion display server smoothly handles the dis-­ the libraries in the DECwindows environment. play and user input for the X applications along These applications communicate with an X Win­ with data exchange between the applications. dow System display server over a network through This paper first establishes the relationship of the the X protocol. The X protocol is independent of eXcursion display server to the X Window System and Microsoft Windows environments. It then pre­ sents the personal computing integration philoso­ phy behind the development of the excursion product. This paper then relates the design philoso­ phy and implementation architecture of the snver. NETWORK It concludes with a discussion of resource usage.

Overview The DECwindows architecture integrates the user and graphical interfaces of the Vi\·1S, U!TR!X, and DOS operating system and desktop environments. The X Window System client-server architecture, on which the DECwindows system is based, provides the means to achieve this integration. The X architecture, as implemented by Digital's Figure 1 X Applications Running on Remote

DECwindows Motif program, is shown in Figures 1 Nodes and Displayed on a PC

Vr)/. 1 Nu. I \'ililtler 1')').2 Digital Te cbnical jo urnal eXcu rsionJiJ r Windrnt ·s: ill tep,mling Tl l'o Windoll 'ing .\) •stems

API'LICATION eXcursion-A Componellt of PC I Integration OTHER One of the goa ls of Digital's l'C in tcgra tion program GRAP HICS AND � E I is to integrate l'Cs throughout a network so they WOC KIT UBRAmES EXT NS ON LIBRARIES may share resources. In a local area nl'twork (T.AN) O F M TI TOOLKIT I • PEX CLIENT • POSTSCRIPT or a wide area network (WAN). l'Cs share hies ami I X T (IN T RINSI CS ) l ·IMAGING printers through a filesen-c r. Traditionally, Digital X LIB has provided terminal emulation software for I i n teraction with a time-sharing system on the net­ TRANSPORT MECHANISM work . The X Window Svstem distributes another resource load t hro ughout the net\vo rk, namely X11 PROTOCOL appl ication services. X appl ications can be run on a � special-purpose host. such as a CJ(r\Y system. or on MECHANISM TRANSPORT a genera l-purpose host such as a VA X system. The I applications share the CPU, Jll(:'ll10ry. disk. and print EXTENS IONS resources of t.hat host. Tlws, the optimal or appro­ • p X X SERVER K ER NEL S RV ·POSTSCRIPT E ER priat<:: device can prov ide the application services. ·IMAGING The eXcursion product is an X display serv<::r through which the J'C user can access the X Win­ dow System class of application. h�!!,llre l X Cfieni-Sr!l'l'f!J'Arcbitecture Recause it enables information exchange among PC users and non-PC users throughout a network, the excursion software is a key component of operating system, nct1vork transporr . and network Digi tal's Network Applications Support (NAS) and wiring technolog1· ami topology. The display server Digital's I'C integration program in the Personal provicles basic \v imlow ing, graphics re mlering. and user input services ror X applica tions. Computing Systems Group. eXcursion Implementation Design Ph ilosophy

The eXcursion ;t pplication implements the X Win­ As in any software development project. a number llow S1·stem ll isplay setTer on Microsoft Win(lows of very important design go als and decisions were The eXcursion software allows the windows of the establ ished for the excursion for Windows product X appl ications, running on a remote host. to dis­ which affecte(l the implementation. The excursion play on a personal computer. The rwo environ­ application had to be extremelY compatible with ments arc visuall.y intcgra tnl-applications from the Microsoft \V indows etwironment. There were both ctwironments displa1· on a single screen and important reasons for this decision. have the same 1 isuaJ appearance The two environ­ first. it was critical that eXcursion run on any I'C, ments usc the sanll' mechanisms to manage win­ with any combination of devices that the standard dows ami thus present a consistent user interf·ace. ;\tl icrosoft Windows environment supports. Typi· In addition. eXcursion uses metaphors and mecha­ cally. the manufacturer that builds the hardware is nisms famiJ iar to the user of Windows. A control responsible fo r ·writing the Winclows-compatible panel is employed to handle configuration and drivers. The devices that most affe ct eXcursion are cusromization of the eXcursion appl ication. The keyboard, pointing device, and dispJav. Windows Program ;\tl anagcr is em ployed to trans­ Second. a tremendous amount of developmen t parent ly invoke appl icati ons on remote !Josts. effort has been invested in tile fu nctionality a nd f-igure :) shows the eXcursion control paneL the performance of the WindO"ws product \XIe wanted Windows calendar. and the DEC>vindows Motif cal­ to apply that fu nctionalitY and nor duplicat(:' it' in endar as viewed on a desktop device. The \Xl i ndows the X server. For exa mple. Windows softw:tre has a Program M;tnagcr is also displayed ro show the bit block transfer (llitfllt) routi ne that can more eXcursion program group with icons installed. effectively handle that opera t ion than eXcursion. Users can si mply douhle click the icons in the pro­ It is one of the operations that iVJ icrosoft has opt i­ gram group to start applications on a remote host. mized. In addition, it is one of the operations that

Digital kdmiutl.fourua/ li1/. 'I .\n. I 1\ iull!r /')'Jl PATHWORKS: PC Integration Software

Meeting wllh )oe

0 " Sun (lod --.. � 1!J

Meetilltl withJoe II:00 12:00 PM I :00 2:00 3:00 4:00 5:00 &:00

Figure 3 Windoli'S Display witiJ eXcursion

can be customized and optimized for the PC's graph­ network with another windowing system and its ics adapter. If the graphics adapter can handle applications. The nrst five resources were all owned BitBit operations with built-in hardware, it is more and managed by Microsoft Windows. We had to usc likely that the operation can be performed faster its appl ication programming interfaces (AP!s) to with that hardware than with the CPU. Therefore. correctly share those resources. The network excursion is completely insulatl'd from the hard­ n.:source was shared among many networked appli­ ware and benefits from fu nctions that have been cations through its A Pis as wel l. optimized for specialized hardware. The third reason for developing eXcursion as a Us e of Wi ndows Resources well-behaved Windows application is imlepen­ A substantial portion of the design debate centered dence from the internalsof the underlying window­ on the way excursion would use the Microsoft ing system. We might have been able to do a slightly Windows resources. \Ve needed to determine how better job of integration of the :\1icrosoft Windows to rnap the windows, graphics contexts, fonts, and and X \V indow System environments if we had color maps of the X environment to the windows, obtained a source code license from Microsoft and device contexts, fonts, and color maps of the truly blended the two environments into one. How­ Microsoft Windows environment. ever, the cost, development resources. and time The major dilemma was: Should each X window needed to implement this type of integration were be created as a Microsoft Windows window and prohibitive. thus be known to both environments' Or should Fourth, the excursion application had to share only the top-level X windows-those which were the PC system resources of display. pointing device parented by the Windows desktop or root win­ (mouse), keyboard, sound subsvstcm. memory, and dow-be created as windows in the Microsoft

'58 Vo l. 4 No. I Wiuter /'J'.J2 Digital Te chnical journal eXc ursion fo r Windou·s.· fnlegrating Tu ·o Windoll'ing Srstems

Windows etl\'imnmenc with al l other windows way of d rawing text was through \Vi ndows. There­ cre:ltnl s t ri ct ly :ts X w in Li ows anLI known only to fo re , the X scn ·e r's font resources were compil ed t: Xcu rsion ' into Windows-compatible fo nt ti le res ou rces so

The first p roposa l was ce rtainl y ca.'y to i mp le­ Windows could do all the text drawing. ror each ment and it Jed to consistcnc\ t h mughou r t h e X fo nt resou rce . we i n cluded a second ti le for thl'

X s en LT The \V i n d ows en,·i ronmcnt had an API fo nt and glyph merrics that did n ot map to the rich en ough to make this p la n kasiblc In addition, \X Iindows fo nt ti l e resource. Some of the <:Xcursion \Vi ndo'' s wo ulll hand lc all the wimlow stacking fo nt tile re sou rces were modif'i cd to resolve incon­ and cl ippi ng for e Xcursion fairly transparently. �istcncics bctwn·n the two cm- i ronmc nrs ami l)e;,pite these r ·asons. the :t l rnn ari,· e p l an was make eXcursion compatible with Windows. ror pron:n more workable d u rin g our protot ,.ptng example, unl i ke X, \V imlows docs not al low tex t phase. drawing out side the char:lctcrs· bou nd ing box_

Th · X W indow �� stem ,,. a, designed to emplo,· Color ma ps arc :m other reso urce \V'i ndows m:ttw vv i mlows since t he y an: consi l le red to be share:- with eXcursion. ;Vl icrosoft Windows version i nexp ·nsi \'t' resources. ' SuTer;, use I itt lc memory :)0with standard video graphics arrav (VCiA) bani­ for each window. X wi ndo\\ s arc C:t;,l to crea te , ware (a 6Hl bY -tHOre solution (lev ice with 16 colors map, ut map. and destroy: and th ey c:tn n av iga te su ppo rted ) pre-a llocates :tll l6 colors in t h e color quickh· through the window tree. Thus, X- based tablefo r the Windows enYironmcnt. For eXcurs ion, toolki ts, such as ,\·lotif. em ploy many windows. this is cffcctiwlv the X Window SY stem static color \\fhen we tcstnl our initi:tl pro po saL we discovered visual. wllcre tl1e color map is read-only. \V ith that both vv in dowin g s\·stems m ain tai n ed \vindow cnhanc<:d vc;,\ urds that su pport 2"i(l sim ult aneous trees, which resu l ted in a pe rfor ma nce problem. colors. Windows pre-a lloc:ltes 20 ent ries in the

Fo r ex am p le. when certain op e ra t ions such :1s color table. ro r eXcursion. the X Window System 's graphic-; were pe rform ed, some of the c l ipping pseudocolor ,· isua l can be supported with only was done t wicc , on ce hv eXcursion :111d once 2:)6 entries for allocation in the color table. Again, by .Yi icrosof'r Windows. In addition . Nl icrosoft it was important tha t cXcu J-s i on was wel l behaved \V i mhi\\'S l i mi ted the nu m be r of wi ndows th a t with re spect to color-ma p allocation and usc could be crea ted. hy the 6-t k ilobyte (Kll) memory it within Lhe Windows em·ironment. rcscnnl fo r tltl·se ami other S\·stem resources. Fu nctional h. the :\ Window Svstcm graphics con­ Pe 1j'onmtnce Co nsiderations texts (C< :s) mappcd fa irly wel l to t he Microsoft Performance of the eXcursion p ro d u ct is a con tinu­

Windows dc,·icc co nt ex ts (DCs) T l owever, the way ing a rea of concern , in vesti gation . and develop­ X appl ic:ttions l'J11 1)loy ccs is s igniticant l y differ­ ment. M:11w perfor m an ce concerns were re medied en t fmm the way tv licrosoft Wind

to the X display server have to be encoded into the environment to the greatest extent possible. Two X protocol and transmitted to the server through an important areas to integrate were window manage­ interprocess com munication mechanism. For the ment ancl claraexchange. eXc ursion product, this mechanism is a network

because the client and server are always on diffe r­ Wi ndow Ma nagement We bel ieved that Micro­ ent systems. Operations in X, e.g., menu sweeping soft Windows should provide window management. and resizing of objects, always involve both the To p-level windows in the two environments are cl ient and the server. These operations in particu­ peers and should be visual ly and fu nctionally iden­ lar have to be fast because theyaffect the user's per­ ticaL With this capabi lity the user does nor have ro ception of the windowing system's performance. run a remote window manager or learn and remem­ Thus these code pa ths had to he efficient. ber a second user interface. Third, X has strict pixelization rules. These rules We wanted the ou ter frame of the windows in determine which pixels must be included in the X to look like the windows in Microsoft Windows. rendering of a graphics object. In general, all the Furthermore, we wanted Windows to provide all interior points of an object are n:ndered, bu t only of the encl-user window management functional­ certain points on the outer boundary of the object ity-move, resize, iconify, deiconify, stacking, and are rendered. If the area of the pixel below and to fo cus. The windows for these operations had to con­ the right of the center point is touched, then the tain the same user interface objects found in the pixel is included ; otherwise it is not.2 Thus, a rect­ Microsoft Windows environment. We clicl violate angle has its top and left edges included, hut not its this design principle in one case. In place of the stan­ right and bottom edges. The pixclization rules for clarcl Microsoft Windows system menu icon in the the X protocol were strictly specified to satisfy the upper left corner of the window frame, we placed technical market's graphics requirements. such as an "X" (see Figure 3). This object visually cued the CAD/CAM. If one were to tessellate polygons in the user that the window represented an X Window X environmt:nt, one wo uld bt: guarantt:t:d that each System application ru nning remotely but di splay­ pixel is included once ami only once. ing within the Microsoft Windows environment. The Microsoft Windows environment was On the other hand, X servers are not aware if the designt:d with a busint:ss graphics presentation graphics object being rendered is a component of model. Thepix clization rules are not widely known a scrol l bar, command button, rad io button, check and may change. box, text entry fielcl, etc. For this reason, eXcursion Based on these fa cts, we chose to adhere to the cannot make gr:.tphics objects look like ancl fi.ll1c­ X protocol and its pixelization ru les. We believt:d tion as the equivalent objects in the Microsoft most users would run office productivity applica­ Windows environment. Unfortunately, the user bas tions. For these applications, pixelization rules do to cleat with these inconsistencies between the two not affect the operation or functionality of the windowing environments. application. In a majority of c:tses, the user is never The exc ursion prod uct had to conform to able to see the subtle differences in the rendering the X Consortium's Inter-Client Communications of a graphics object As part of eXcursion's cus­ Conventions Manual (ICCCM) specification fo r win­ tomization, we allow the user to select the way dow management within the Windows environ­ graphicsare rendered-optimized for performance ment \X Iindow properties such as name, icon or optimized for correctness. This choice is ;lllalo­ name, size. and position on a to p-level window gous to printing draft (fast) mode for proof copies must be recognized by excursion and must be set or letter-quality, high-resolution mode (h igh qual­ using the appropriate Microsoft Windows APis 5 ity but slow speed) for final copy. The user can change this parameter at any time in excursion Data Ex change We believed users should be able ancl force a redraw by the X application, e.g., to seamlessly exchange text and hit-map data through an iconify/deiconify procedure, to render between the Microsoft Windows and X Window the graphics in the other mode. System environments. For ex ample, the user shou ld be able to use the standard application mechan­ Seamless Integration isms to select data ancl cut or copy it from one One of our design goals \.vas the seamless integra­ environment, move to an application in the other tion of eXcu rsion into the Mi crosoft Windows environment, ancl use the standard application

60 Vo l. 4 So. 1 Winter 19<).! Digital Te chnical jo urnal eXcursion f'or IVindolt 's: lntegmting lit'O WindOII'ing ::,ystems

mechanisms to paste the data. No specia l user inter­ Figu re :)), provid es access to al l the u ser preference vention between these two o pera tions would he features an d con figura t i o n parameters. Anot her acce ptable . i mportan t design p rinc iple was the i mmed iate acti­ 'I(J enhance the data i n tegra t i on capabili t ies of vation of co nJig ura tio n parameters or user prefer­ eXcursio n , we did i mplemen t a special fea ture to ence features whenever it was tech n ica l l y fe asible. capture any part of an X wind ow as bit-map data We

tig ur:tt i o n was for a wi n dow i ng cm·ironment, we a mi device-tlepenllent X (DDX) The DlX layer is pri­

d ecided to usc the con t ro l pa nel metaphor that marily concernedw i th h igh- lc,·cJ decision m a king. is common to other windowing env i ronments, The OS layer connec ts the X server to its u nd erlyi ng such as the Macintosh and M icrosoft \V' indows. network transport. The DDX layer translates a Tl1c eXcursion control panel (partial !\· s hown in client's request into a p ixe l disp lay. To conform to

WINDOWS MESSAGE PROCESSING

X S RVER ------�--DEVICE-INDEPENDENT X OPER------ATING ------SYSTEM APPLICATION : ------I D������D�;���EN� X � DEC NET X WINDOWS USER. GRAPHICS MS-DOS (TO DEVICE INTERFACE. AND KERNEL CLIENT)

MS-WINDOWS DEVICE DRIVERS

Figure "1 eXcursion X Sen•er Interned Architecture

Oi,�ila/ Te clmical]ourual Iii/. i .\". I 1\'iutcr t()'JJ PATHWORKS: PC Integration Software

the Windows application model, our implemen­ Op erating Sy stem tation adds a fourth layer, the Windows message Data transferred on the X wire is arbitrated in processing layer. the OS layer. When an X client application makes a server request, the underlying network code Device-independent X receives it, packages it, and makes it available to the The DJX layer consists of modules that provide OS layer. The excursion product runs layered above high-level server data structure manipulation, one of two entirely distinct network transports X request vectoring, and server task scheduling. (either the DECnet or the TCP/IP protocol) and must Every attempt was made during the development provide some mechanism for passing data back and process to change as little as possible in this layer, forth between the real mode of the network inter­ and to maintain the firewall between the DIX layer face and the protected mode of a Windows applica­ and the underlying DDX layer. The DIX layer's most tion. For this reason, we chose to interface the important task is the dispatch loop, the scheduler server to the network by means of a generic OS fo r excursion processing of all asynchronous cJient module. Since all server-generated calls are now requests. Requests fall into three categories: network-independent, the server is freed from any network-specilic decisions. Edits to internaldata structures such as the cur­ 1. Data conversions from real mode to protected rent procedure vector for drawing wide, dashed mode are provided by a group of Windows dynamic lines link libraries (DLLs). Functions in DLLs are called 2. Queries on internal resources such as available directly from a Windows application (in this fonts and their metrics case, eXcursion). The DU.s in turn use Windows' extended memory manager to make DOS protected 3. Drawing requests such as rendering of text and mode interface (DPMI) calls to pass the data to the lines network stack which runs in real mode. For exam­ The DJX layer maintains the current state of the ple, assume excursion is running the TCP/IP proto­ window tree and all its comvonents, as well as the col, and the user presses a mouse button in an graphics contexts and all of their associated data. eXcursion window. The data comprising the DIX code dynamically alters the processing paths X event is assembled, packaged, and presented to chosen for X request completion based on the the os layer for shipment to the remote X client. current states of these data structures. For exam­ The server makes its "send data" call into the ple, suppose that a GC is being used to draw a series generic OS module. This module makes a call into of single-width, solid lines in a window. Now the a common, shared DLL, and passes the data X client wishes to begin drawing with 10-pixel­ unchanged. The generic DLL acts as the network wide, tile-filled lines. DIX then reads the client arbitrator. It knows about the underlying net­ requests dealing with the GC state changes, and work transport and vendor since it performed updates its data to reflect the new drawing condi­ a network installation check at start-up. There­ tions for lines. DIX changes the drawing vector and fore, the generic DLL calls into the vendor-specific updates the GC data structure. (Device-specific excursion DLL to modify the data, pack it into the drawing operations are performed in the DDX layer.) format required by the network stack, and ship it to the real mode stack. Wi ndows Message Processing This implementation strategy requires several The Windows message processing layer is the inter­ DLLs, but it completely shields the server, and more face to the user's input devices, the mouse and key­ importantly the user, from the underlying network. board. Actions taken by a user result in Windows The DLLs are simply copied once into the excursion messages containing information on the message execution path and forgotten. There is no need to type, conditions, and parameters being sent to the reconfigure eXcursion if the underlying network application's Windows message procedure. Here changes. the data must be modilied and translated into some­ thing that an X client can understancl , an X event. Device-dependent X Event processing is done by the DIX layer, and the All the visually recognizable work takes place in the event data is then shipped to the client by the OS DDX layer. DDX translates a client's X request into layer. pixel manipulation on the screen. The sample

62 Vo l. 4 Nu. 1 Wi nter 1992 Digital Te cbnical jou rnal eXcursion fo r W'indou ·s: Integrating lti'O Wi ndoll 'iug ,))'stems

server i mpkmentation that provi ded our �tarting Vs i11g Wi ndows AP/s

point came with a DDX l:t\'cr tlesign<:d for mono­ \V e designed a set of \V i mlows-sp<:cific mmlu les (.\·I l l\) chrome frame bu ffer device:-. We r<: pJaced that tilled the h ard wa re-dep endent space provided

the :\·JfB de v ice-spe cific code in the DDX layer with by :\·I f H. These fun ctions are cal lnl by the DIX l aycr 's implemenLttion-specitic code for Windows. request d ispatche r through tbc request vectors set Our baseline sample s<:rvcr implementation also up in the server's main data structurcs (screen. win­ p rov ided a mach ine-independent DDX mechanism dow. GC sce Figure .::; for examples). All X re lative \II (:\•11). The modu les manipuLtte the vicl eo termi­ 'lr:twing re quests arc t ranslatecl here into Windows nal as a virtual device: vicko lll l'l110rv is emulated operations, and Windows Al'ls arc calil'd to satisfy and all drawing operations take p lace into this vir­ them. tual spacc until the final output renders the bits As des cribed previous!\·, we decided to match onto the screen. The .\ ol f manip ula tes bi ts anti per­ wi ndow trees by crea ti ng a \Vindows window tor fo rms logical operations until it achicn:s a final rep­ each top-level X window on!�·. X child windows arc resentation of' the n.:questcli operation. Th is fin al hand led as if they arc rcctangular areas of their drawing requires two distinct funcrions: fillsp ans parents. thereby saving room in the linite (6-fKB anti push pixels. Tile ti ll spans fu nction rcmlcrs total size) pool of \V indows resources :tvailable fo r drawing output in s ingle scan lines. making other objec t s . This decision led to :1 difficult prob­ re peated calls to Wi ndows l$itBlt. The push pixels lem that nel'ded a solution: How do we handle win­ fu nction docs much the s;tme thing. but at a more dow cl ipping' complex le,·d-it pushes hits through a mask or fil ter before theY :t i)IK'ar on the screen. These Wi ndou· •:.Jipp inK mechanisms :trc rcqu ireli for propt:r text rendition Cl i pping is accompl ished in X [),· maintaining a list. when tile or stippled filled text characters arc fo r each window in the system. of the rccrangks req uested with u nalte n.: d character outlines and into which drawing is allowe d. Clipping in Windows backgrounds. These mechanisms are. h)' definition. is accomp lished essentially the same w;ty, but clumsY and incfhcicnt, hut they provide pixel per­ it requires allocation of another resource, a region fect renditions. eXcursion uses these .\ol l fu nctions \Ve implemented clipping by a<.l llcring to the when an' or the fo llowing cond i tions must he met. X model. letting the server code do as much of the

1. Drawings :trc co mplex fil led areas. work :ts possi ble. The L)[X code manipulates and maintains a "clip 2. Tile and stipples used are not H by H pixels in I ist'' for each X window. When :1 Win d ows window size. (W indows is opt imizcd to han(l [c this one is c reated and used. \X' indows expects this clirping case. ami breaks down casil\' tor all other sizes.) information to reside in the window 's DC if some­ :'\. Al l opera tions rcquirc pixel perfection. such as thing is to be drawn in the window To get the X clip displ:!y of a CAD :tppl ication. list into the \Vinclows DC. we a l l ocated a small pool

if Cgc. lineWidth == OJ { s w itch (gc.lineStyle) { { case Solid: 9 c. Line GPXZero Li neSol id; brea k; case OnOffDash: 9 c. line GPXZeroLi neDashed; break;

else swi tch (gc.lineStyle) { case Sol id: g c . Line GPXWi deli neSolid; break; case OnOffDash : gc. line GPXWi deLi 11r·Dashed; break;

l'(r:, ure 5 ,lJodi(J 'ill,l!, Data Stru ctures to Change IJutu·ing A�l!,orithnts

Digital Ti•chnicof]ounwf I i>i. -i Xu. I 1\" iu./er /'J'JJ PAT HWORKS: PC Integration Software

of cached Windows regions. A DC (and X parallel GC) since a wide, solid, horizontal line is rectangular, used fo r a drawing operation must be validated to eXcursion calls the Windows FillRect AI'! to draw it. ensure that all components are up-to-date. If rhe Only rarely is the MI code path required. DC does not have a copy of the clip list, a Windows region is built from the rectangles in the X clip I ist Pixmap Mampulation and installed as the clipping region of the DC. When The X pixmap presented us with a major challenge. the drawing takes place, the clip list is installed. Since it is a bitwise representation of a visual

is t , As long as the window no moved, resized, or object its bit values must be maintained regardless obscured, the region remains unchanged and fur­ of its use. Pixmaps can be used in a variety of ways ther region validation is unnecessary. When the by complex X client applications. Pixmaps can hold number of visible windows exceeds the cache lim­ off-screen copies of window contents, or they its, the least recently used DC is "thrown our· of the can hold a patternfo r a window background. They cache, and must he revalidated if it is used again. can provide a mask through which a color or pat­ This mechanism allows smooth, efficient output tern can be squeezed to give a stencil-like tilling to multiple windows without extensive use of effect. They can also contain text characters prior Windows precious region resources. to output. Windows places a fu rther restriction on resource The real challenge. however, lies in how pixmaps usage. In addition to being created, a resource must are manipulated. There are monochrome pixmaps, be selected into a DC before it can be used. color pixmaps, pixmaps presented as an array of Deselected, olcl resources are deleted to save space. bits one color plane at a time, or packed to present If a request asks fo r one of the deleted resources, it each color plane for one pixel in succession. For must be re-created and again. h selected T e caching these myriad fo rms and presentations we created a and updating of DC:s in Windows is hand led by the set of pixmap manipulation routines that translate same fu nction that validates and refreshes GCs in X. back and fo rth between X and Windows. Since When an X request results in a GC change, it may Windows provides a set of AP!s for manipulating also result in a DC change. For example, if the line device-independent bit maps (DlBs), we stored the drawing mode changes from single-p ixel-wide, bit map internally in one, generic form regard less solid fill to multiple-pixel-wide, tile fill, the GC is of its X representation. eXcursion extracts the bits, updatcd with new procedure vectors and data modifies them, and sends them to the client when it fields. At the same time, the DC must be updated so requests them in another format. One of the biggest the ne..xt line drawing request results in a wide, tile­ performance bottlenecks in eXcursion lies in the filled line. A Windmvs bit map is created for the pixmap fo rmat con\'ersions which are constantly X rile, and it is selected into the DC as the pattern. taking place under the surface. Since we have Any line then drawn Hsing the DC results in a wide, stored all pixmaps in device-independent format, tile fill.This methoLI is used to update the DC when­ the performance penalty is low. ever any GC object with a parallel Windows object is changed. The cache ensures that Windows Fo nt Co mpiler objects can be allocated. The X and Windows environments include a sec­ tion dedicated to information about the fo nt met­ Drawing AP!s rics and a section for the character bit maps. The Windows environment contains a rich collec­ However, their fo nt storage methods are diffe rent. tion of AP!s designed to accomplish many types of Furthermore, since eXcursion is a compatible drawing. The eXcursion application takes fu ll Windows application, it uses Windows fo nts to advantage of these drawing APis. Wherever X and draw text. Windows share drawing rules and conditions, the We designed a fo nt compiler to create Windows­ appropriate Windows API is called quickly to maxi­ usable fo nts from an X font fileinput. The fo nt com­ mize performance. This mechanism is utilized piler takes a bit-map distribution fo rmat (.BDF) when the user selects the ·'optimized fo r perfor­ (X Window System font files are supplied in this mance" drawing mode. When the rules between ASCII readable fo rmat) and produces two output X and Windows differ, excursion calls the most files. One, called the X fo nt file (. XFN), contains the appropriate API for the more common variants, X metrics readable by the server without having to again, to maximize performance. For example, load the character bit maps themselves. The other,

64 VrJ/. -1 No. 1 Winter 1')92 Dig ita( Te cbnicaf jo urnal l'Xcursion fo r Windou·s· /ntl'p,mting [u ·o Windmcing S) 'Sil'/JlS

a Windows font fi le (FOi'l), contains the character allows eXcursion to scan the X wimlow tree and glyphs usn I I)) the \V i ndows Al'ls. eXc urs ion's uetermine which child window holds th e pointer. X-specitic code uses the .XI '-. ti le to match avail­ \V hen a user presses a mouse button, the same ahle fonts witl1 those rcqu este(L and to calcu late kind of activity is used to determ inc which wind ow string silTS. posit ions. character offs t:ts, ascents, contains the pointer. The X event tiara structure is

dt:sccnts, and a n Yth i ng else re late(! to tht: location filledin and shipped to the client for further action. and posit ion of t ht: cll;lr;tetcrs. The .FOi\1 hlc is \Vhen a user presses a keY on the keyboa rd , l oaded as a \V indows resourct:. selected into a DC much t h e same processing t akes place Windows as described abm·c. ami used for any drawing oper­ sends excursion all the information needed to :t tions since it contains the actual character repre­ build an event dat:t structure containing the key sentations The font compikr can ge n era te custom state, the scan code of the ke\', and the key modifier

fo nts: :llw fo nt compilnl with it pro(i uces a state (whether Alt. Ct rl, or Shift is depressed). Windows font tile suitable for usc in any other. non­ eXcursion then packages an d sh ips the data struc­

X, Wimlows a pp.l ica t ion. For example. any of the ture to the cl ient a ppl i ca t ion. suppl ied eXcursion fo nts could be used with \Vo nJ eXcursion l oads a key sym fileat start-up. The hie for Windows. contains the kt'\'hoard mapping of h a rdware scan codes to keysym d efi n itio ns for the usn's keyboard. Handling Input Devices It permi ts custom conligurarion for a user's key­

ln t he section Seamless Integration. we descrihc.:d board. The k eysym compiler in eXcursion takes an key boa rd mapping fi le as its input, and our design stra tegy for eXcursion to hand le draw­ ASC!T texr. s ing requests from X clients. In this st:ction we dis­ 1)rod u ce a binarv keysym tile as its output. As long cuss requests fn>m tht: ust:r. as t he user foJiows th e layo u t of the input ASCII hie. \V hen a user clicks a m ouse button. or mo,·es the an y key can be remap[Kd in am· way desired. mouse. or types on the b;eyboanl \V indows gener­ ates messages which arc sl1ippeu t o eXcursio n's Ma nipulating Application Windou•s \V indow message processing fu nction. In tcrru pt As stated previously, eXcursion uses the Microsoft rrocessing is not needed since \V ill(lows shields \V indows window manager to manage and manipu­

eXcursion from the unclerh·ing h ardware . In fact, late windmvs. Whenever the usl'r moves, resizes, eXcursion has generic input handlers rhat work icon ihes. maximizes. or closes a window, ei rher by with any hardware con figuration supported by the \X Iindows system menu or the mouse. \V indows Windows. sends the eXcursion window procedure a message Tile message processor translates the data into with specific parameters. For example. a message a format untlnstoml bv X. then packages ami trans­ sent when a window is re sized contains the old and mits it over the X wire as an X even t . Since these new sizes ami origins of the window eXcursion user-initi:tte(i actions are asvnchronous events. transJa tes even· \V indows input message into an eXcursion calls tilt: Win dows Pce kMessage() fu nc­ X event and send:;ir to t he X client. tion when it h:ts hnislll'u processing an X request. lndiYi(lual messages from Wiml ows gencral. ly

or when it is in the idle loop. correspond to X e\·ent types that prov ide data \V indows and X share the same coordinate to cJients. However. complications arise w hen m apping cotwentions. \V hen eX c ursion receives Windows gen erates m u l t i ple messages for a si ngle

a mouse mm t· mess;tge. it docs not perform trans­ action. for exam ple, when a user presses a button

lations on the .\' and _)' coordinates: it men:ly to select an item from a menu. a new window is cre­ reports in which window the pointer resides. atetl , m appetl , sized. place([ on the screen. acti­ Furt hermore. when eXcursion creates a window in vated, and given the input fo cus-aU as a result of

\XI i ml ow.s, it stores 1 h e correspontl ing X win­ the single user action. \Vintlows messages arc gcn­

dow's handle in t lw t: xtra data area of the Windows crateu fo r c:K h of these operations, yet the user has wimlow structure Tt can retrieve the han(l le of a proviclnl no further action. matching X window at an\' t i me with the \V indows To handle this extn.: mely complex web. we API Cer\Xlintlow l.ong( ). Since eXcursion always benetitt:u from our initial design decision to create matches a \X Iindows window to a top -level X win­ only top-level Windows. We eliminated litcralJy dow, the combination of the t o p-le vel window hundreds of \XI indows messages fo r l'ach child 'Win­

ILtndlt: a n d the .\· a ndy coordinatt's of tile po i nter dow, simply by not creating them. :vlcssages are

Digilaf li!clmica/ Jo tfl'uol I (1/ 1 . \!1. I lliuler l')')l PATHWORKS: PC Integration Software

sent only to the top-level window, and eXcursion remote application launcher. XREMOTE sencls can quickly determine which child (ifany ) needs out a Windows message, with an identification attention. On the other hand, we had to observe known only to excursion. If excursion responds, and study window stacking, configuration, repar­ XREMOTE passes it the command line for appli­ enting, activation, and window focus before we cation start-up. If eXcursion does not respond arrived at the final implementation. Only through within a short timeout period, XREMOTE issues extensive prototyping and empirical testing were a WinExec call, requesting start-up of excursion we able to eliminate poor design choices and arrive itself. Windows starts up eXcursion, passing it the at the best ones. As a result, every possible window command line string for the selected application manipulation action, whether initiated by the user start-up sequence. XREMOTE then terminates until or directed by a client, requires a translation from the next start-up request. Windows to X and a careful selection of Windows Obviously, security is a major concern for any function calls to keep the delicate balance between system that requires and handles account pass­ X and Windows. words; eXcursion application activation is no exception. Users log into their accounts by activat­ Cutting and Pasting Data ing an X application such as DECterm. Two distinct To cut and paste data between X and Windows passwords are required: (1) the eXcursion global, applications, we merged the Windows clipboard session password and (2) individual, application mechanism with the X selection mechanism by account password. incorporating the cut/paste "pseudo-client" into The eXcursion session password is optionally eXcursion. This module watches for data cut­ selected and set by the user from a control panel and-paste requests from X clients, as well as those dialog box. It is stored as an encrypted string in the from any Windows applications running on the PC. initialization file,and is used as the decryption key \Vhen it notices an X client gaining control of a for the individual application account passwords, selection, it asks the controlling client for the also stored in the initialization file. This design pre­ selected data, which it then puts into the Windows vents an unauthorized person from using some­ clipboard. The data thus becomes available to any one's .IN! file to obtain access to an account. The Windows application with access to the clipboard. user is prompted for the session password when When a Windows application cuts or copies data excursion starts up. If an incorrect value is entered, into the Windows clipboard, the pseudo-client is the server terminates and application activation is notified,at which point it informs all X clients that impossible. A fu rther level of security is provided it now owns the clipboard selection. X clients can by the "Prompt for Password" option, which the then request the data from the pseudo-client by user can select for any application start-up. selecting paste from their edit mem1s. Summary Accessing Remote Applications The eXcursion for Windows display server seam­ The user initiates remote X client applications lessly integrates the Microsoft Windows and through an application lau nching mechanism that X Window System environments. It provides a provides several starting options. desktop integration tool that allows the user to dis­ play and interact with applications designed for 1. Selection of an application from the excursion control panel's application pull-down menu both windowing systems at the same time. Data can be exchanged between them and desktop 2. Selection from a dialog box of defined appli­ resources shared. A user is no longer required to cations work with two incompatible desktop devices in 3. Selection of the "Start X Application" dialog box order to complete work assignments. 4. Double clicking on an icon installed for the appli­ Acknowledgments cation in the Windows ProgramManag er The authors would like to thank everyone who The most interesting option, double clicking on worked on the product during its development. In an installed icon in the Windows Program Manager, particular we would like to thank the other fu ll- or allows the user to start up an X application without part-time members of the software development any knowledge of the current state of eXcursion. team: Ray Shapiro, John Freitas, Mike Pfeffer, Lee The double click activates XREMOTE.EXE, the Karge, Alice Chen, Mary VanLeeuwen, and Andy

Vo l. 4 No. 1 66 Wi nter /'}92 Digital Te cfJilicaljournal eX cursion {or Winctou •s: Jntep,ra ting llt'O Windoll'ing S)•stems

Nourse. Two other memhers of the PC DECwinc.lows 2,. D. Rosenthal, Inter-Client Communicotion Om­ Group who work on the DOS-baseli X server, John uentions Mcm1wl (Cambridge: ;VI IT Laboratory \V asser a ml .Jim Peterson, provided some vaI u ablc for Computer Science, 1989): JH-;,(1 assistance. We arc also indebted to the fo llowing for their support and contributions: Emilie Schmidt, General References Camel Hoover, Kathy Maxham, Andre Fontaine, Digitol Te dmicol.fournal, vol. 2. no. ) (DECwindows Alice Chen, ami Tracey Wemett. This great group Program, Summer 1990). of people malic this project a joy to work on and a success. R. Scheiflcr, J Gettys, ancl It Newman, X Wi ndoU' S) •sten1 C Ubrmy and Pmtocol Reference (Bedford, References ,\1.A: Digital Press, 1988)

R. Schei.tlcr, J Gettys, and R. Newman, X Win­ J\1/icrosojt Windou•s SojiLmre /)e!•elojJIIIelll Kit dmt · S)'sfelll C LiiHmy a11d Protocol Ne{erence Reference, vols. I and 2 (H.edmond, \VA : Microsoft (Bnlfortl. ,YL\ Digital Press, l9H8) xvii. Corporation, 1990)

2. It Schcitlcr, X Windoll' SJ•stent Protocol (Cam­ Micro.w�jt Windou •s Sojtu •ore !Jei•elopment Kit bridge MIT !.a bora tory for Computer Science, Guide to Programming (Redmond. \VA : Microsoft 1989) 2,7. Corporation, 1990).

Digital 7i>chuical.fouruaf 11!1. -i \'u. I V."inler I'J'Jl 67 Christopher E. Methot I

Capacity Modeling of PATHWORKS Qient-Server Wo rklo ads

PA TH WORKS network operating system software runs on the remote server com­ puter that accesses files on bebalfof clients connected to a network. Th e PA THWONKS .file semer provides clients with centralized backup, printing, and security Popular desktop applications can be used in a manner that consumes large or small amounts of server resources. Capacity planning seeks to determine which network filingsystem is app ropriate to wrrent workloads and to predict capacity needs as the PA THWORKS client-server e1wironment changes. Th e desktop industry lacks standardized performance tests. Digital has developed a general process that can be applied to any workload, including those in which the number of users caus­ ing the server process's resource consumption are unknown to a data collector. DEGperformance Solution software was the primary tool used in the modeling process. Its analytical queuing model was used to predict pe1Jormance and help definecon figuration alternatiues.

The PATHWORKS network operating system soft­ tion, simplistic rules of estimating the consump­ ware provides remote fileservice to desktop com­ tion of server resources, such as number of users puting devices across a local area network (LAN). per V1JP (V�X-11/780 unit of performance), can be Integration of personal computers (PCs) on a net­ very misleading. The use of applications in ways work allows users to share applications, files, and that increase individual productivity can slow printers. Ylost applications available on the desktop server response time for the user community. can be used in a manner that consumes widely vary­ These issues should be considered when selecting ing amounts of that single-point resource known as a file server system. Because the number of active the filese rver. users is often unknown in client-server environ­ Some of this variation is due to the intentional ments and the user application technique may vary, part-time nature of the server's resource utiliza­ capacity planning uses a model of the actual work­ tion, and some is caused by innocent changes in load to predict server performance and help define the user community's work techniques. Since desk­ configuration al tcrnatives. top applications are used by novices and experts This paper describes a queuing analytical model alike, small changes in the levels of skill, experi­ that was used to gain knowledge about resource ence, and thus technique can significantly affe ct the consumption on the PATHWORKS server computer. performance of the server. The paper discusses the special modeling process Capacity planning is a method of estimating required for the client-server environment. It the changing hardware needs for a computer sys­ describes data capture and workload classification tem due to changes in workload. It can also be using DECperformance Solution software. Finally, usee! to explore "what-if" alternatives for existing the paper presents the results of a performance workloads. analysis of a PATHWORKS server with response-time Changes in user work habits such as running constraints. macros can increase a server computer's response Some of the terms found in this paper have spe­ time by as much as an order of magnitude. In addi- cific definitions. Many of the "correct" terms for

68 Vo l. 4 No. I Winter 1992 Digital Te chnical journal Capacity Modeliug nf PATHWONI\S Uieut-Sen•er \v!nldoads

net work tile sen ing :trc not the terms usnl b1· users is the one we seck to answer when \\'l' moclel ol thcsc systems. Network lilc serving Ius acquired I'ATlfWOI\KS client-server workloads. the name "net worked." Server computers arc often rclciTccl to as "the network.. . and getting access to Data Collection one's Iiies on the scncr is u.sualh called logging Data can he collected 11·ith tile \X\ Performance into "the net work." In this paper. we· refer to Advisor (VI'A) version .2.1 or tile Dl·:cperformance �·IS-DOS-based I'Cs and ,vL!cintosh computers gcncr­ Solution version 1.0 or later. IWCpcrformance icall\ as desktop computing dn ices. In addition. Solution software is an integrated procluct sl'l that the word ..,,· orkload" rdc rs to the cause of the prm ides J K-rfortll:lllcc :tllll cap:tci t' managemcm resource consumption, whiciJ is the comhination capabilities for com puting svstcms. This l:n ercd of cl ient application and user technique within that software product runs on the VA\ V,\IS operating application. The term "worklo:tcl class" l1as a spe­ s1·stem and uses a queuing an:th tical model to cilic definition in DFCpcrlormance Solution soft­ answer questions. This process req uires col lect ion ware . It rckrs to a group of \'.\IS processes that of two kinds of information the modeler wants to manipulate ditlcrcntly from L A cletailnl record ol the cause ol resource con­ other processes. Sll lllj)tion. incl uding \\"hich j)roccss is causing Defining the Question c:tcil disk or Cl'l :1cti1 it1 !'rocesses sll

Ana(Jilical Models of users lor whom tile 1'.. \TH\\OI( KS sciTl'I' process is I'ATI IWOI( KS sort ware takc.s advantage of the consuming resources. Furthermore. the col lector expanded computational power o( the clicnt­ cannot detect tilL· response time seen h1 the users scn er architecture. ,,- JJich requires special moclcl­ of the Llcsktop clc1 ices. ing techniques. Two of Digi tal's anal\ tical modeling We ha1 e deYelopnl a gener:li process that can l<><>is can be usnl in ou r c:tpacitl model ing process. he appl inl Lo all cl ient-sen cr workloads. Tl1cse hown-cr. DI·:Cpcrform:lllcc Solution wa.s the pri­ include applic:ttions such as VT\ or VAX Notes. in man tool_ Tile model \\ :Is u.scd to ans\\ cr questions whicl1 tile number ol users initiating tile scn er :thout the need to cnh:tncc Jile sen cr eomputer process' resource consumption arc unkiJO\\ n to a rc.source requiiTments as a result of changes in data collector. hardware or workload J'igure I illustrates a simplified closed queuing J'crl orm<�ncc modch c:111 :lllS\\-cr :tt least two model of a l'ArL J\\01\K� transaction. The usn initi­ questions. ' !'irst. "Ho\\ is performance affected ates the transaction through a kL'\ hoard or pointing if we change either tile number or users or tile cln ice. The appl ica tion running on the dc·sktop amount of IJanlwarer Second. "How can we m:tin­ computn perfo rms the initial local process ing and tain performance ir· we adcl users cloing the same issues a c:tll to the ser1 cr request ing 1/0. Till' sciTer . l!O kinds of l:lsks'' Of the t \\-o. the second question perfo rms some rclllotc computing. ami till'

J)ig,ita/ Ti'C/mica/Joii/'1/U/ I r1/. I .\u. / II itt let· I'J'/! PATHWORKS: PC Integration Software

request is satisfied when the server transmits and if the server's response time improves, the either the data or acknowledgment that the data user's will improve as wel l, as shown in Figure 1. has been written. This travels back to the use r's A model that is built from a data collector wh ich desktop device and some further computing leads has only a partial definition of the whole loop (i.e., to a graphic ind ication to the user to proceed to the the server computer portion as shown in Figure 1) next step. is cal led an open modef.2 The models described in If these three sequential queues-client, network, this paper are open models. Since the most likely and server compmer-were equal in response time, bottleneck is the shared resource known as the the server would have only a one in three influence server, this is a useful way to model client-server on the responsiveness the desktop user sees. Of workloads. course in reality the three queues are never equal, and the two local queues are highly dependent on Un iform Service Level the local desktop computer's capabil ities. Each Model analysis of a PAT H WORKS client-server com­ queue can have a request backlog ifthe service time puter workload cannot predict the increase or is not fa ster than the arrival rate. The response time decrease in response time seen by the user . A of any queue is the queue wait time plus the actual model can determine the effect of any change in time to be serviced. The total response time of the hardware configuration or arrival rate (number of workload class, as modeled on the server, is the ana­ users). Capacity planners can use this method to lytic sum of all its queues' response times. add more users by incrementing arrival rates. Then In rea lity, the analytical model of the PATI -£\VORKS hardware can be upgraded until an equal or fa ster environment is more complex than the one server response time is rea ched . Th is method can shown in Figure 1 and involves disk, memory, and be used to increase the number of users at the same CPU queues. The response time calculated for a perfo rmance or split users into smaller groups PAT HWO RKS server comp uter workload class is the with the same or be tter performance.' calculated sum of the response times of all server Not all desktop transactions require server inter­ process queues for that workload class. As stated vention. In fact, the success of the client-server earlier, this is only an indicator of a desktop user architecture depends on infrequent access to response time. servers. Obviously, file servers are requ ired when a file is saved. However, many applications per­ Cause and Effe ct fo rm disk 1/0 without any obvious or expl icit user A data col lector, running on the server computer is action. For example, \XfordPerfect software pro­ not aware of the response time perceived by the vides a temporary file that is a type of journal file. user at the desktop device, nor can the server's data Periodically, the application upda tes this file with collector procc:ssknow how many users are gener­ data stored in memory. When a user's input reaches ating the current workload. Server response time is a predefined buffe r limit, the next keystroke causes a subset of the response time as seen at the desktop; the file to be written. The capabili ties of this appli­ cation, and many others, must be considered when planning the capacity of a PATHWORKS file server / . / / / '/, installation. In this example, the load per client on / / the server can be significantly reduced by placing RETURN [-11 / the temporary file on a local hard disk. I KEY Performance of a file server computer can also be affected when expert users employ macro tech­

/ / / 1 / / niques or when users generate automated output. / // / Macros read each instruction from the macro file DESKTOP / . ,· / / I I COMPUTER I . / . one record at a time, thereby continuously doing 110. Most expert users provide a save as the last instruction in the macro, which allows them to be absent when the work is being accomplished and CLIENT NETWORK SERVER then saved. This increases server 1/0 as well. Most desktop applications permit automated output. Figure 1 Simple PA TH WO RKS Queuing Model For example, some allow fo rm letter generation;

70 Vo l. 4 No. 1 Wiuter I'J'J2 Digital Te clmical jo urnal Coj)(fcflJ' Jlodeliup, o/ m7'/tWOR.KS Uieni-Ser! 'er Worldoads

ONE :;nnw com)HIIL'hlidcJ de�ign (C:.\J>) appl ic:ttion.� JOB REQUE ST IDLE prm·itk Hi I h of \Ia tena Is. This capabil it,. ;!1-,o incrc;tses seT\ u· 1/t l.

The usc· ol· ei iller m aero tech n iqucs or autom a ted output can illl j)act S(TI"LT computtT uriliZ:IIion

,\ '>UTcr that 11 :1s inrendnl to he a p:trt -tinle ti ll' scr1n c111 hu:ome ;1 l'ull-timc· J;o de1·ice 1Yh1eh can TWO JOB THREE JO rapicl l� e�cTnl its cap

..\TI I\\.< li\KS intcn·:l ls 11·itllin the hour·,· Tile rclll:lining !]') WiLTS onII 1' "·orh:Jo;ld ch�scs. can han· non­ l'Xll 1\VO J( I(S work loacl classes atltlnl for :1 more continued working as before. In this case the possi­ complex cnvironmenr . bi litl inuTasul to 28 percent tllat a joh rt'qucst \\·o ukl ile on the queue. 2 i percent that t\VO joh • The SLT\'LT can he upgr:1ded to maintain the per­ 1·equests "nc w;liting.

• Local site· management can he made aw:1re of the Modeling Process m:tgnituck of dai!1 1vorkloatl l':triation: under­ The nwckl ing process \\T describe in this p:t pcr standing this ' ariation is :t lso part of the modd ,,.:1.' clc H· Iopnl o1 er :t t\\ o-\ e;lr period. Before dis- process.

Limi ta lions

IDLE • The model c1nnor pred ict response time changes at the cl ient. due to ch a ngL·s in �n' cr loading. THREE JOB RE Q UES TS • Information about tile number of users generat­ T WO JOB ing the :1pplied \Y o rk lo:td must be col lcctul REQ UEST S b1 mL·t iJmls other than using DECpcrformancc

ONE J OB Sol ution soli ware Thest· mulloch arc detailed in REQU EST tht' st-et ion Ca pturing Wo rk lo:tds.

• Although memon c1 n he· modeled. the model cannot :lnticipatt' the increased PXI "l l\\

Dig,itol liYim icoiJournol I(,J. 1 .\u. I Wiuter /'J'Jl PATHWOUKS: PC Integration Software

read or record management services (R�1S) cache these utilities with a brief DCL command string. requirements. When adding users to a For example, ADMIN/PC SHOW FILE COl ::\TERS dis­ PATHWORKS server computer, adequate spare plays the current cache misses and request rates, memory must be allowed to provide the same or and ADMIN/PC SHOW Fll.E SESSIOI\S shows the better cache hit rates. The RMS cache hit rates client device lD,client connections. and open Jiles. can be determined, without software tools, by The size of the server process cache configuration executing a program at the Digital command can be gathered using the ADMIN/PC SHOW FILE language (DCL) prompt: @SYS$UPDATE:AUTOGEN CHARACTERISTICS command. If analysis is per­ SAVPA RA.\15 TESTFILES FEEDBACK, and then read­ formed offsite, a DCL procedure can gather infor­ ing SYS$SYSTEM:AGENSPARAiV!S.HEPORT. mation about volumes and system logical names, which allows user disk assignments to be clelinecJ. • Available modeling tools only allow PATI-IWOHKS Finally, user amhorization resource limits on the workloads to be modeleu onto VAX VMS servers. server process can be extracted from the system.

• Prior to data collection, the server must he The ;\1acintosh server software has similar com­ checked to see ifit is tuned fo r use today and for mands using the ADM!'i/Vl�.\ SHOW COI\'JECT!ON the future, or the recommended server system command.

may he incorrectly sized. 1 When the size of the user community is unknown, the above data must be used to charac­ Capturing Wo rkloads terize the number of users being modeled. Specific DECperformance Solution software requires VAX custom<:rs with large installations or many remote Performance .\dvisor version 2.1 or later collector sites need quantitative user characterization. In all filesn: uncd nodcname_clate.CPD.In addition, either cases the cause of the observed performance char­ a VI'ASSCl-1 LJ)l LL OAT or a PSlX:SSCIIEDljLE. DAT Jile acteristics must be determined at some quantita­ is required to define the cluster configuration and tive level. collection schedule. Either a VA,'\ Performance The data gathered by using the ADMIN/PC SHOW Advisor version 2.1 or DEC:performance Solution FILE COliNTERS and ADMIN/PC SHOW FILE SESSIONS version 1. 0 Data Collector, or the DECperformance commands can be invalidated if desktop devices Solution Service Delivery Software kit may be used include automated procedures to attach to file ser­ to col lect data. Al l three require a license and prod­ vices when the desktop device is booted. The sim­ uct authorization kit. ple act of activating the client power switch should Enough data must be collected to represent the not count that user as explicitly intending to use range of a typical workload. The sum of the subjec­ the server computer. On the other hand, explicitly tive user opinion of performance must be collected connecting to file services and being interrupted as well as the tasks the users wen: performing. for an unexpected event should not exclude that If this data is not collected, the planner may mis­ user from the total active user count. Ultimately, a takenly model equal levels of user dissatisfaction combination of the total possible and the total rather than equal levels of user satisfaction. Sub­ active connections is needed. jective performance evaluation is always gathered by interviewing or monitoring users. Defining Wo rkload Classes Collections should be made over a series of nor­ With the DECperformance Solution uata collector, mal workdays to avoid gathering misleading data. workload classes are defined prior to starting the We have observed two normal workdays with only modeling process. They are defined either by speci­ a 5 percent difkrence in the number of desktop fying the anticipated logical divisions or by deter­ users logged into the server, yet five times more mining them from the observed performance data. server resources were used. DECperformance Solution software provides many Additional data on user activity that is con­ ways to group processes, e.g .. user identification suming resources must be col lected by methods code (liiC), resource usage, image name.' other than the DEC:performance Solution collector. The DFCwincJows interface to the performance Both the i\Iacintosh and .\ lS-OOS server products tool DECperformance Solution provides an excel­ have interactive DCL soft ware uti! i lies that provide lent way to review the data. ' The graphic display of some information about the condition of the cur­ the server process by day along with the subjective rent server process. Command procedures can call user characterization can help select the day or

72 vh f. 4 Nu. I Wi11/er l'J'J.2 Digital Te e/mica/ jo urunl Capa cit)' Modeling of PA TH WO RKS Client-Sen•er Wo rkloads

days ro be moddcd. The same method can he used users can the PATHWORKS server computer .su p­ to determine peak usage ho urs. rinally, this tech­ port'" This determination req uires defi ning another niq ue can ll elp ca tegorize wo rkload classes by workload class by li!C for the Al.l.-IN-1 system users. applicable processes. Table I I ists the workload The workload class could be moved by lJIC to the class grou pings we used. FILESVS workload class. This method assumes the Wo rkload families arc groups of work load cl asses current col lection of Fl LESVS work load classes that the data collector can expect to see. The reflects the mix of the remaining i\ 1.1.-IN-1 system I'W _DOS workload fa mily characterizes a system as users. a PAri I WO RKS ti le service environment. It includes Even before the model build i ng step takes place. I'AlHWOHKS server proccss<::s. required system the PSDCSDATABASE logica l must be pointing to overhead fu nctions, and p rocesses needn.l to col­ the location of the VJ>ASSCHEDU!.E.DAT and the lect data that an: not normally part of the system . VI'A$PARA.VI S.DAT tiles. The mod el building step

All other 1) ro cesses arc automatically placed in a ge nerates a model with the workload class group­ category called "other:· This su its the needs of our ings given in Ta ble 1. The workload cl ass and fa m ily general-case, single-function PAIHWORKS s er ve r dciinitions arc made using the DCI. com mand computer. hut any server can be used for tasks ADVISE PI.AN EDIT in the VPA/ViVl £ (V.r\.,'\ Perform ance unrelated t o the I'Ai li\VO RKS print and file service. Advisor/VA.,'\clusrer Mo deling En vi ron ment) uti! i ty If the tasks in the default (other) category need to and are wri tten to a tile named VPA$PARAMS.Dt\T. be subdivided for separate scaling, the workload (If the DECperformance Solution tool is used , class detinitions have to be added to a fa mily which the fi les are named l'SDCSSU I EDl ii.E.DAT and calls each workload class explicitly. as indicated for I'SDdPAJV\MS.DAT.) the I'W _L\D wo rkload class family in -l ;l blc l. If this logical is uetincd while using the ror example. consider th e question "As groups of DEC:performance So lution DECwindows interface AI.I.-IN-1 system users change to PCs. bow many invoked from the .session m anage r. the logical may not take effect in the DCL session in which the

model is to he built. The c om maml to generate a Ta ble 1 Wo rkload Class Groupings model can include the time selected ro be represen­ Workload tative and the workload class fa mily d etinition Name Image Name Selection Criteria name. A report can be genera ted which describes the newly built model. The co mmand useu is: FILESVS NETBIOS, PC FS_*, PCSA$* ADVISE PL\ N lllill.D/CI.ASS=(l ISEH=P\V_DOS)/HE< dN= OVERHEAD AU DIT_SERVER, NETA CP, EVL, 9-DEC-1991 : HH0-/ END=9-DEC-1991 : 11 30/REPORT/ ERRFMT, OPCOM, JOBCTL, REMACP, CONFIGURE, IPCACP, OUTPl IT=:.·JY ;V!ODEL. RI'T ;V lY.Vl()I)EJ. :V I[)I..I TPSERVER, FI LESERV, CSP, At this point the model must be valida ted by typ­ SMISERVER ing ADVI SE PLAN REPORT MYMODEL.MDL VALIDATION/ ABNORMAL PSDC*, VPA$DC_V5, DECC*, SPM, OLJTPLIT=.V!YMODEL_ VA LID.RPT at the DCL prompt . MONITOR AJl pred icted values should be within 10 p erce nt

MAC_FILESVS AT K*, MSAP*, MSAD*, MSAF* of the calculated va lues. n A CPU validation report LAD LAD$KERNEL for a collected workload includes data on through­

OTHER (All Else) put. qu eue length , average service time, average response time, and percent of utilization. For tbe Workload FILESVS workload. the measured utilization was Family Workload Member(s) 677 percent as compa re d to 64-.7 p e rcent for the PW_DOS FILESVS, OVERHEAD, ABNORMAL model. This :) percent difference is 4.4 percent of PW_MAC MAC_FILESVS, OVERHEAD, the measured value and thus we ll within the 10 per­ ABNORMAL cent range. PW_BOTH FILESVS, MAC_FILESVS, OVERHEAD, ABNORMAL No rmalizing the En uirunment PW_LAD LAD, FILESVS, OVERHEAD, ABNORMAL The next step is to return the system to the normal environment. Even though data col lectors are t ypi­ PW_THREE LAD, FI LESVS, MAC_FILESVS, OVERHEAD, ABNORMAL Gl ll)' designed to utilize a small amount of sys ­ tem resources. they are not normally part of the

Dig,ita/ Jeclmical jo urnal IIJ/. 1 Xu. I Wiuler !')<)l 73 PATHWORKS: PC Integration Software

server workload. Grouping abnormal processes If the bottleneck is not on a single path, its capac­ into a workload makes it easier to remove them dur­ ity can be increased by spreading the load across ing the DECperformance Solution model process. another similar device. This can be achieved with Access to the DECperformance Solution model multiple disks. interface is achieved through the command ADVISE In the ALL-IN-1 system case discussed earlier, PLAN MODEL MYMODEL.MDL.:I 100 percent of the \Vorkload class from the first UIC group of ALL-IN-1 system users can be removed Recording Response Times from the modeJ.:IIf the model is solved at this point, The next step is to solve the model and view the cal­ all the workload class's response times should culated response times for the remaining workload diminish. If the FILESVS workload class throughput classes. These are FILESVS, OVERHEAD, OTHER, and is incremented in proportion to the additional any custom-defined classes. The OTHER workload PATI-IWORKS users and the model is solved again, class can be used as a defined workload class pro­ the response times of all workload classes increase. vided it contains no unexpected processes that The question is: "Has the removal of the ALL-IN-1 are using significant resources. The calculated system users decreased critical resource usage response times for the remaining workload classes sufficiently that their addition to the PATJ-IWORKS should be considered maximum times, and model FILESVS workload class does not increase any of the manipulations should always seek to attain these remaining workload class's response times beyond numbers or less. their target?" The answer depends on the per capita If the intention is to capture the PATI-IWORKS usage of the critical resource of each workload workload class for use elsewhere and if the same class. The nature of each workload class may be system had significant OTHER workload classes, different. For example, PATHWORKS workloads do these classes should be removed (turning the not scale well over SMP processors. The workload server computer into a single-function PAlHWORKS class being removed may use more CPU time per server).' This reduces the response times of the user than the PATHWORKS FILESVS workload class. remaining workload classes and requires increasing the PATHWORKS workload class until the response Findings time returns to the observed value. The increase in We analyzed a large PATI-IWORKS workload class throughput is proportional to the increase in from a V�'( 6000 model 510 system whose CPU uti­ PATI-IWORKS users accommodated at the same per­ lization averaged 72 percent. The subjective user formance, without the competition of the OTHER evaluation was that this system was very near workload class. performance capacity limits, and a fair amount of dissatisfaction was associated with the level of per­ Mo del Manipulation formance. The question was asked "Could this com­ Basically, the response time can be manipulated munity be split in half across two VA}\:4000 model (1) by decreasing the usage of a significantresource 300 systems with the same or better performance'" (model resource utilization percentages help We immediately agreed this would work, but went locate the bottlenecks) or (2) by increasing the about proving it with a model. After the workload capacity of that resource. class was normalized and the response times were There are two ways of decreasing the resource uti­ noted, the workload class arrival rate was reduced lization. If the resource is single-threaded on the crit­ by 50 percent and the CPU and disk systems were ical path, as a CPU would be in a non-symmetrical changed to the V�'(4000 model 300. The new model multiprocessor (SMP) machine, the method is to was solved, and the response times were signifi­ reduce the number of users by decrementing their cantly worse than with the V�'( 6000 model 510 sys­ arrival rate (called throughput or transactions per tem. The workload class was halved again, and the second [TPS] in various menus) or by increasing the resulting response time was still slightly over the speed of the bottlenecked device. target. The model allows for workload class manipula­ This findingwas difficult to understand since the tion to remove arrival rates of the workload class. VAX 4000 model 300 system CPU was now down to As this is being done, the original arrival rate must 36 percent utilized, and only one quarter of the be noted so the same changes can be applied to the users remained. The reason for the inadequate number of users that caused the workload. response time was found by studying the queuing

74 Vo l. 4 No. I Winter 1992 Digital Te chnical jo urnal c c model. hgurc cj is a simplilinl !110lld showing t\\0 mmlel file tl1:1t i.s Lil'l oicl ol uscr-sp e ili infor­ Cl'l ·s :1ml their lJ Ueue� li h[lLI\ nl on a time scale. mation Other 11011-I'AI 11\\ ()J� r.;� \\ Orkloalis can he [ Tile lirst i.-, a sl

Anot her sur[lrising result hcc:lllll' n ident in the mapping ol t!Je CJuantit:ltil e· \\ urk!oacl class cilarac­ lial -to-li:l\. ,·ariation :l t :1 custome-r's inst:ill:1tion. teri;:a tion. \\l' clo not k110\\ tile units ol.. soine ol tlw

The .-, :lmc t11·o 11 orklo:�ll ci:tSSl'S \\ l' i'e :mail;ed kn mctrics u .sed ThndoiT, entering a 11·orkload :1cmss Sl'\ er:il li:l\ s to ex:1mine t1 pic:il '' orkd:i\ 'ari­ class c1pturnl in one nwllel to :111other mmle/ is not :ll ions in 1vo rkload class resource utili;ation Two recommenlinl nonn:i l workdays were sclcctul ill till' customer. TilL· most intense hours of tllc·sl· two d:11 s \\'cre ll if­ SUIIIIIUII:J' k' rent h1 :1 ;;ignilicant fa ctor. On one \\ oi·kda\, tlliTe The 1' \i'f l\\()J(r.;� ll l" t \\·ork operating S\ stun soft­ to liH· times as lll:lll\ usl'rs :1pplinl tlll" .s :une \\·ork­ watT pn>,·ilk-s remote lile SLT\ icl' to clcsktop com­ lo:ill cl:1ss as on tile other Ll:11. 1et :il l CXJKTiencnl puting lie\ ices :ILToss :1 local arc:� net 11·ork. the s:lllll" i·esponse times. This \\ ide 1 :tri:ltion is tlp­ Cap:t · i t\ pl:tillliilg ol clit:lll-..,lT\ LT U11· ironml'nts ical ofclient-sen n \\ orklo:Jlis. requires t he· usc ol SJKci:il nwdel ing t cTilllilJliC.'.

DECpcrforlll:lilll" s , >I u tit n1 so ft \\ . ItT pn" ilks per­

Librm]' (if Wo rkload Classes fornl:lll ce :IIlli c·:q1; t ci t' lll:lll:tgc l )lL't1l L.IJl:thil it ies

Alter \\T hall c:1pturecl a series ol liat:L \\ e Ci'C:Itnl a for computing s� s t e m s : it use s :1 queu ing �mah 1 ic:il rcst>tii"Cl' um:-umption qul.'":-lif rea l wo rklo:�ds tl1:1t rc [!ITsentnl l:lr­ mock·! to :lll S\\ LT iou.-, cone[ it ions. Tile :let ua I wurklo:!lls consist of a The modeling pron:�.� dl"[Kllll.' U!l the collect ion or ellOUgh d:tl:t tO rL· p rl'Sl"i ll the Ll ngc or :1 !\ pic:Ji

worklu:td. Add it ion:il data on u�cract i 1 it 1 t I ut con­ SERVICE l iME - · .,.. sumes scrn:r resou rces must also be collcctnl . A.nal1 sis of 11·orkload models rcTeals the reasons ro r I IJ--- :111([ Sl lll ptonl., ol bot t ll'lll'Cks. CapacitY planning de[!Clllls Oil the rc.sults of thc.-,e an:tJ \·scs to p redict -1 I I scrH:r rcspon.se t imL·s. RESPONSF Ti E ... Acknou ·letlg me 111 s

[ \Y ou ill like to til:mk !'r:1shant llhabh:tlia. 11 ho ----1 111 1 11111111111I}- lll"lpeLI llll' ensure tl1:1t tile modeling process i;; corrccc :t ill/ Dick Dunnington. \\ ho checked my

queuing thc·or1 Also, I 11 ould like to lhank SERVICE TIMF ·"" Frank C:ICC:I\':ill'. who helped llll' unclcrsl:ind

the !';\'1'1 1\VO I(r.;S S<..T I'LT architect ure . ,\k lur 1-"

/)(f!,ilnl7l.·chuica/ Jo urnal \ i1/. 1 \n. I \\ iuh'l" /(F)...! PAT HWORKS: PC Integration Software

Ann Bousquet, and Lindsey Stephens helped me transition to DECperformance Solution software. Finally, I would like to thank Pete Stoddard for applying his technical reviewer skills to this paper.

References

1. Guide to DECcp Methodology (Maynard: Digital Equipment Corporation, Order No. AA-NA34A-TE, 1989).

2. R. Jain, Th e Art of Co mputer Sy stems Peifor­ mance Analysis (New Yo rk: John Wiley & Sons, 1991).

3. DECpeiformance Solution Capacity Planner Us er's Guide (Maynard: Digital Equipment Cor­ poration, Order No. AA-PH6LA-TK, August 1991).

4. DECpeiformance Solution Peiformance Advisor Us er's Guide (Maynard: Digital Equipment Cor­ poration, Order No. AA-PH6SA-TK, August 1991).

5. F. Hiller and G. Lieberman, Op erationsResearch (San Francisco: Holden Day, 1967).

76 Vo l. 4 No. 1 Winter 1992 Digital Te e/mica/ journal I Fu rther Readings

'llw l ) igi r al 'l'echnic:tl.Journ:tl VAXc luster Systems

jml;lisl.wsjHIJH.:rs !/.Jote.\j Jiorl! Vu l. I, ,Vo. 5. Sej;leiii!Jer 1')8- I l.w techlllilli,� icol fiill JzdatiliiiS VAX 8800 Family uf f)fgitol :\ lll(fior jJroducts. f:'o ch Vo l. I. ,\io. Fei i. HIIOI:J' /'),')- .Jo urnal jiicllses u11 at least 1111e jJruducl oreo ond fJresents o Networking Products CUJiljJilotiull of jmj;ers UTillell Vo l. I. No. .). SejJiemiJer I'J8(J /; J· t/.Je e11gi11eers /1'/.Jo det ·l!lojJ ed MicroVAX II System 1/.lejJroducl. '!be co llie/Itji1r Vo l. I. No . .2, Moreb I'JH6 1/.Je Journal is selected {J )' the jo11 nwl .- ldt ·isor)' Hom d. VAX 8600 Processor

Of.�itolell ,�illl!ers ll'ho II'UIIId I 'o l. /. , Yo / . .rlII ,� II S I 1')85 li�e to con trilmte a j){ljH!r to t/.leJournal sho11ld umtocl Sub�cript ions to the !Jigitol h'c/.micol jnllnwl are tlw editor of J

'lilpics cm cred in pre ' ious issues of the O

Image Processi ng, Vi deo Terminals, d ollars. ami checks should he mack p;tnble to and Printer Technologies Digital Fquipmcnl Corporation I Iii.. ). No. i. Po ll I'J'JI Single copies ami past issues of the 01��1/al

Availability in VAXcluster Systems/ Te clmicoljourl/ol can be orclercd from Digi tal Netwo•·k Performance and Adaptt:rs Press at a cosr of S16.00 pn cop,·. Vo l. . :L No . . i. S11 111111er I

DECwindows Program I' An ick. "Lexicon Assisted I n forma l ion Retricv:tl \Iii. .2 . . Vo ..i. Sti ll/liter J<)'JO for the l k l p -Desk ... l:'!�ftiJI/.1 /U:F Confi.'rei/ CI! u11 VAX 6000 Model 400 System , I r/ ijiciol J 11 tellig e 11ce .-l.fJ!ilim I ions ( .\Ltrc h 1 ')')2) Vo l. .l. No. l, .\j;ri11g 1')<)0 N. Arora ami ;\1 . S harma . "Model ing the Anomalous Compound Docu ment A1·c hitecture Threshold Vo ltage lkha\ ior of Submicrometcr I l1/. l. ,Vo. I. \.f'inft'r 1')<)0 .\IOSFFTs." 1/:L/: Ueclnm /Jel'ice /.elfers (Februan· 1 ')')2) Distributed Systems If1/. I. ,\o 'J . ./1111<' 1')8<) S. Baznlol:l. "An Fxperimenl al .Jn, e�t igat iun or· :1 Suggcred Array of I katsink� in the l lyd rmh namic Storage Technology ;tnd Th crm :t l Ent ranee lkgions of:t l)uct ... IIi/. I ..Vo. 8. h:l; mmy /')8') 1- 71/LN. IJ Ill (Februan· 1')')2) CVA..'X-based Systems D. Bhavsar. "An Arch itec tliiT for Extending the 1·1>1. I, Nu. "'. August I'JHH IEEE Su ndard 1 1-i'). l Test Access Port to SYst em . Software Prod uctivity Tools Backpl;tn<:s .. 1/:F/: fnterno/i()IIOI Te st Con(ere11ce I r1l. I, ,VI1 (J. l'el;mmy !<)88 (OctolKT l')')l).

77 /)i,�ila/ 1i'cbuicai Jourua/ li1/. ·I .\'u. I ll'i)f/er I; . I'J'Jl Purtber Readings

E. Braginsky, "The X/Open DTP Effort," Fourth M. Lefebvre, "Test Generation: A l3ounclaryScan Internatinnal lf/orkshop on Higb Perfnnnance Implementation for Moclule Interconnect Testing," Tra nsaction Sy sterns (September 1991). IEEE International Test Co nference (December 1991). X. Cao, "An Introduction to Ensemble-Average Importance Sampling of Markov Chains," R. Jain, "The Art of Computer Systems Performance Proceedings of the Th irtieth IH'L' Co nference Analysis," Co mputer ;VJeasurement Croup Confe r­ on Decision and Co ntrol (December 1991). ence (December 1991).

R. Cembrola, "Analytical Chemistry in Support ). McGrath and). Derosa, "3-D Solid Modeling for IC of Microelectronics Te chnology," Boston Section Assembly," IEL'l:' Advanced Semiconductor L'vi anu­ l'vieeting of the American Cbernical Socie�y fttcturing Conference Proceedings (October 1991). (November 1991). J McPhee, T. O'Toole, and M. Ye dvabny, "Cooling Z. Cvetanovic and E. Freedman, "Efficient the VAX 9000," Electro/90 Conference Record Decomposition and Performance of Parallel (May 1990). PDE, FFT, Monte Carlo Simulations, Simplex, and J McWha and P Kouklamanis, "A Product Infonna­ Sparse Solvers," The jo urnal of Supercomputing, tion Access System fo r Ve rification, Te st, Diagnosis vol. 5 (1991). and Repair of Electronic Assemblies," IEFE Inter­ S. Denker, "A Common Sense Approach to Improv­ national Te st Conference (October 1991). ing the Design and .\Ianagementof Electronics B. Mirman, "A \Vay to Avoid Stress Singularities Manufacturing Processes,'' I11ternational Co nfe r­ in Multimaterial Elastic Boclil·s.·· Tra nsactions ence on Automated Ma terials fkmdling (1990). of Annual ;V/eeting of the Anzerican Society of B. Doyle, R. O'Connor, K. Mistry, and G. Grula, Me chanical Engineers (December 1991). "Comparison of Trench and LOCOS Isolation fo r T. Moore, "A Workstation Environment for Bound­ Hot -Carrier Resistance," WFE Electron Device ary Scan Interconnect Te sting," IEEE International Letters (December 1991). Te st Co nference (October 1991). B. Fishbein, D. Krakauer, and B. Doyle, "Measure­ C. Pietras, "Cognitive Models of Planning in the ment of Very Low Tunneling Current Density in Design of Project Management Systems," Proceed­ Si02 l sing the Floating-Gate Te chnique:· IL'I:'f:' ings of the Human Fa ctors Society Th irty-jijlh Electron Device Letters (December 1991). Annual Me eting (September 1991). W Harris, H. Smith, and A. Pelillo, "SHv !S Test K. Ramakrishnan, "Dynamics of Congestion Con­ Structures for Analyses of Semiconductor Product trol and Avoidance of Two-Way Traffic in an OS! Wa fers," American Vt:tcuum Socie�y Th irty-eighth Testbed," AC!VI Computer Co mmunications Review Na tional Sy mposium (November 1991). (April 1991). D. Heimann ancl W Clark, "Process-Related S. Rcgc, R. Kalkunte, R. Edgar, and A. Russo, Reliability-Growth Modeling-How & Why," "A High Performance FDDI Adapter for VAX IEEE Reliabili�y and ;lJaintainability .�j ·mposiwn Systems," T!J irty-seuent!J IE/:'1:' Co mputer Society (January 1992). International ConfereJzce (February 1992). S. Heng, H. Pei, anc! J Wa tson, "Closed-Loop Cool­ M. Register, A. Rewari, and M. Swartwout, ing for Computers-Opportunities for the 90s," "The CANASTA Experience: Key Management and Na tional Electronic Pa ck.aging Production and Te chnical Decisions in a Hybrid Expert System Conference (June1991 ). Project," IEEE ACLHIn ternational Conference S. Knecht, "Integrated Matrix Creep: Application on Deuelop ing and Managing Expert Sy stem to Lifetime Prediction of Eutectic PbSn Solder Programs (September-October 1991 ). Joints," Ma terials Reseorch Societp Sy mposium K. Symonds, M. Bahrami, and P Skerry, "Functional Proceedings (November 1990). Failure Analysis Using Photoemission Microscopy," L. Lee and B. Mirman, "Bonding Quality and Proceedings of the Seventeenth International Bending Stiffness," InternationalElectr onics Sy mposium fo r Te sting and Fa ilure Analysis Pa ckaging Societ)' Co nference (September 1991). (November 1991).

78 Vo l. �1 No. 1 Winter f<./').2 Digital Te chnical journal Oigi tal Press DIGITAl. .r\.T WORK: Snapshots fr·o m tht.: Fi rst Th irt ·-f1vc Years l>igi t:ll l'ress is till" [)<)(Jk puhlishing gmup of [d itl·d j),·_l:tmie l'arkn l' c:t rso ll. 1')')2. sof'thounLI . Digi tal Equ ip111ent <:orpor:1tion. The l'ress is an 22') pagL'S, Ol·dcr No. n-_r:-;2()L-l)I'-1TI\ ( � I')')')) i ntnnat ion a! p ui) J i�IKr of com p utn ht Hl ks :tillI JOllmah on nL·w technologil·s and products fo r TlHJugil not :1 l'mm:tl hisron. IJ(!.!,ilol til H iill<. users. Sl .�tem and nct11 ork nunagcrs. progr:lnl­ t<:l h till' ..,!On ot tile lirst thirtl-11 \·e IL':trs ot' mcrs. :1nd othn pmkssion:l ls. l'rr>JlO.�ab :1ml ideas l)igit:ll Lquipmcnt C:orpm:t tion :tnd illulllill:ltcs · l'or [)ooks in these :mtl rd.atnl arc:1s :liT welcomnl. tl1l' origins ul its unique culturc l:irst -pcr son :ICC< llllll S froill p:tsl :tlld prc.;L'Jl{ 111Clllbcrs oj' l he Tl ll' Jo llm1·ing hnok descriptions represent :1 Digital conllllunitl. ind ustn associates. ho:1nl sam ple or the hooks :1\':lilahle from Digir:il l'rL'SS. members. ami tr icnch tr:tcL· the COlllJl:ltl\ ·s C\·oiu­ tiotl !ro m the l')'iOs to the I()')Os Designed tor BITNET fOR \'�IS USERS hro•vsing :u1d sdccti1·e rctliing. tili.� houk prm ide� \lich:lel r\ . .\ ltlOrl' :IIlli Honald .\1. :-:1\\ l'\, I')'J2. rc:1l stories in till' \\·orlh ol 1·eal people. l'lwtu­ 1�(> . .s ofl houml. Jlages ( >1·dcr No. LY-L-1 () ti:-t>P-ITll gr:q)hs from Digital� :1rchin·s 1nakc the stories ( S2'i '.J'i) more \·i, id.

I ksignnl to l1l'lp people ,,·ho lla1 c Ill'\ cr used ALt-IN-1: A Tec hnical Odyssey a n:1t ional co ntj)lltLT nl'l work. this hook al.�o 'l(ln\· fklimond. 1()')2.sot thound. 'i'iO p:tgl· s. pn>' ide' an i m·a lu:ii)J.e rdnuKe !'or tl10se:dn ·:1dY Order o t:Y-f!9'i2F-Dl' ( 5 1 tlJ'il Li mil i:11· \\ ith :ICCDStllg 1\IT'\IT !'rom the \ \IS I OJ)l' Liting s\ �tcm of Jigi Lt l Lqu ipnKitl Corpora- This ex tcn�i\e trL·a tllll'tlt of [)igital Eq uiplllcnt \1 l ion. This lirst c:-.;clusi' c em n:lgl· or Ill ! l ll l'lails Cot-poration\ ol!'tLT :lutonution tool addresses the lll :un :tspeus !'rom ck-n ronic mail to scarching needs of s,·stu11 11 lail:tgers. :1pplicat ion pmgr:lill· 1\1'1.. \Y ITnwto: datah:t.scs to ctrrying on com·e rs:l­ lllcrs. aml tccilnictll\· uricntnl usus w!HJ work tions \Yitll peopk ILIII'\1 :1\ :1round the \\'t lrill .\ lure \\ it il .-\Il-l '\-1 B:1snl on r IK :tul hor s tul 'ears of l'X[K'ricncnl com pu tc1· usns will apprecia tc tlte t'\.jKricnu: in dn·eloping ,\ 11.-1.'!-1 suiJs\·stenls :111d appendi_:-.;l·s \\·h icli co ntain more dctailcd infor­ in customi;,ingits applicat ion to specific cusromn mation. S Kc ii'1c j)rogr:1111s :lml li...,ti ng.� of more 1 sites. the pt-csu1 Lltioll l':\.tcnd.� IK'\ pk- ge t the most corners of till· pwduct . Till' \\'L·:tl tll ot' c:-.;amplcs ol !liT'< out of IT. actu:tl inst:tl lation :111d customi1:1tion t" :\j)l'ricllcl·s help CO I11 nHIIliCale ilm\· [0 hcsl llSl' ,\ l.l.-1'-l-! Oil lntcrfac<.· FDDI: Fihe1· Distributed Data ,.,\.\. [)(IS J'C. :tnll ,\ppk .\ Ltcint

\\ l-nlh II \lich:icl. \\ 'illiam.J Cronin.Jr., The Third Ed ition of X y· IN DOW SYSTEM: ami Karl J· Picpcr. l')l)2 ..�o lthouml. 1 :--;o p:1ge.�. The Complete Rcfct·ence to Xlib, X ProtocoL ()rdn ,'! <> I'.Y�I:-; -I OI: I JI'-ITll (S t-<)'i). ICCCM, Xl.FO X Ve rsion 11, lklease 5

Hohert \\ . SchciJkr aml .f;lll1l'S Cctt1 �- I')'J2. ll;tSl'li llj)Oll tile prilll<.:r oi' till' S:illll' ll:II11C l il:lt softbound. llHitl page-.. Order No. LY-.1002F-Dl'-EEll rcn·i\·ed :1 I'.J') I 1\\\ :trll !'or L\.ccl lcncc l'rom till' (S I'J')'i) Socil'l 1 o! Tccil nical ( :o mmunications (STC). this i.� tltl· lirst hook dcH>lnl to this Ill'\\' sL111llard. \\'rit ten hy tile Llcsignns ol tlw \ \\ i mlm\ S1 stem. .\ e<>ncisl· aml tl1orougl.1 tccl mical int mduction to tl1is m:qor rL·,·ision brings darit,· to horh Ill'\\. and the .s ullicn . this hook co1 crs :tll :1spech ol thc l'DJ)I ret:tinnl nu tcrial and intvgr:ltl·s llt'\\ dcscript 1ons st:tnd:trd rron\ its protocols to its implcllll'lllation oi' thc li..-:trures oJ' \nsion II. lklcasL· 'i. into one i 11 IT:tl w<>l 'id I< >c:1 l a1T:1 net \\'orb. Writ ten ami COll\l'llicnt-to-usl· \'Olumc Th is single 1·ol umc tlcsignnl forrapid com prciH'il�iun . tl1is Cu ll\· is in essence a fu lh integr:1tul ami indc:-.;cd fo ur­ illust ratnl tc:-.;t prcsults 1-J)!)I tedlnolog\· :mel hook f\'ll'ITilCe lihr:tn of the \Ill '\ Consort ium's :t [) pi ietl ions wi ![lO llt 111Cll l io11 oi Digi l al 's 1'1)1) I st:1ndard Sjll'Citlcttions fo r the \ \\I indow S\'stnn. pruduct s llril·l' cil:tptcr sum maries pmmotc lkkase "i :1Lids four major c<>11lpss:1n· inllepcndent color support. int nnat ion:t l i1:1t ion dclines kc1 net \\'orking. f.,\ ,'\ . aml i'Dlll tcrms. SliJlj)Orl. Ill'\\ I'CSOLI I'Cl' 11LIILI)2.LT illllCl i< lllS, :IIlli

l)i_�ilal Ji·cllllicai.Jollrllfli I;,/_ 1 .\u I ll illl<·r f'J'J.! () Further Readings

scalable fo nts. Two appendixes on Bitmap Distri­ bution Format and Compound Tt: xt Encod ing extend tht: usefulness of this vo lumt:.

MOTIF PROGRAMMING: The Essentials ...and More Marshall Hrain, 1992, softbound, 6:)2 pagt:s, Order No. EY-j816E-DP-EEB ($29.95).

A straightforward and easy- to-understand intro­ duction to Motif application development, this book wi ll t:ase you into Motif programming as smoothly and quickly as possible. lt starts with an introduction to event-driven programming and procet:ds to discuss thret: concepts essential to Motif programming: resources, cal l backs, and containers. Advanced topics will expose the reader to all of the Motifwidgets, the capabilities of tbe X and Xt layers, the X drawing model, and the process of applica tion dt:sign in Motif.

To receive a copy of our latest catalog or further information on these or other publ ications from Digital Press, please write:

Digital Prt:ss Department EEB 1 Burlington \Voods Drive Burlington, MA 01803-4597

Or, you can order a D igital Pn:ss book by call ing DECdirect at 800 -DIGITAL (B00-544-482')). When ordering be sure to refer to Catalog Code EEB.

80 Vo l. 4 No. I Winter 19Y2 Digital Te clmicaljournal -J825E-DP/92 05 02 18.0 DBP/NRO Copyright © Digital Equipment Corporation. AllRights Reserved.