New Productsthat the cost of providing remote access to localnetwork management data was too high in termsof resident memory usage and design complexity.Therefore, the DNA architects granted anexception to the DNA requirement that remotenodes have access to counters and parameterslocal to PCs.Solving the problem of database access by thebackground network task, however, was essentialto the success of our project. Therefore, weadopted the following design. On its first run,the network software performs as a foregroundtask. As such the software first performs initialization,then shifts to the background. Duringinitialization, the network software, running inthe foreground, can safely perform disk 1/0. Atthis time it reads the permanent database, whichestablishes the parameters necessary for runningthe network, such as buffer counts and sizes. Thevolatile database is kept in memory in the backgroundnetwork task. The network control program(NCP) queries the background networktask when access to the volatile database isrequired. Similarly, NCP performs disk 1/0 tothe permanent database when its access isrequired.Node name-to-address translations, usuallyperformed by resident DECnet code, wereassigned to the application layer in the DECnetDOS software. This shift overcame the backgrounddisk 1/0 restriction. Also, even thoughremote nodes cannot access our local DECnetDOS databases, they can perform loopback teststo the DECnet-DOS node. For Ethernet configurations,remote nodes can query the data link Jayerfor identification information and data link errorand traffic counters.NCP and the network test utility (NTU) werewritten using the common parsing package andthe programming interface library. The aCtionroutines performing network management andtesting could not be ported from other implementationsbecause of the MS-DOS restrictions.As a result, creating the routines to perform networkmanagement consumed a large part of ourdevelopment effort.Network Programming ServicesAll DECnet implementations make the basicprogram-to-program communication servicesavailable to programmers through some sort ofsystem call or subroutine library. That allowsprogrammers to develop their own networkapplications and services. DECnet-DOS providesan assembler language interface, a C programmingsubroutine library, and transparent MS-DOSfile access services.An assembler languag programmer canperform basic task-to-task ervices by filling aIdata structure with control information, thenissuing a software interrupt that is serviced bythe DECnet process resident in memory. Suchservices include logical link creation anddestruction, message transmission and reception,and status and control .A C language programmer can access the sameservices through a subroutine library. We choseto make this interface c9mpatible with theDECnet-ULTRIX programmer interface. Thischoice decreased the development costs of anumber of our application modules by makingthe DECnet-ULTRIX applications more portable.It also allowed the project team to begin todevelop MS-DOS-specific applications under theULTRIX system. Our customers would benefitfrom the same advantages. iUsing these assembler laq.guage or C services,however, requires a good uhderstanding of logicallink management and networking concepts.Many applications need only one simple connection·to access a file or program on another system.Unfortunately, existing applications oftencannot be easily rewritten to take advantage of·network calls.To solve this problem, we designed servicesfor transparent network aJcess. These servicesmake network access possible for the thousandsof PC applications already written and make thedevelopment of new network applications easier.Two tasks, one for remote file access and onefor remote program communication, are firstloaded into memory. These tasks then take controlof the software interrupt used by all programsfor services offered by the MS-DOS system.Each interrupt made by !an applications programrequesting an MS-DOS service is examined.If the request is a file OPEN or CREATE, the filespecification is also examined. File specificationsthat begin with a double backslash are notvalid MS-DOS fi le names and instead signal arequest for network servics. All other MS-DOSservice requests are passed on to the operatingIsystem for processing. The '!'intercepted" servicerequests are processed by :the memory-residenttasks that mimic the actions of the MS-DOS system.Thus an application to display a file on the<strong>Digital</strong> Tecbnical]ournalNo. 3 <strong>September</strong> ·J986115
Th e DECnet-DOS Systemconsole can access either a local file with thespecification "local.fil" or a remote fi le atanother node.Although a wide range of programmer serviceswas offered to single application programs, thesingle-tasking nature of the MS-DOS system madeit difficult to run a PC offering multiple services.To solve this problem, we added a service to thesession layer . That service allows a single applicationto receive a request for any other service .Using this capability, we wrote a program calledthe job spawner, which receives all requests forservice. For each request, the job spawneraccesses a database for the name of the applicationthat must be run to service that particularrequest. Upon finding the application, the jobspawner runs it to completion and then waits forthe next request.SummaryThis implementation . of DECnet-DOS provides awide range of reliable communications servicesbetween personal computers and larger systems.The development of this software was successfu land completed close to schedule, made pos _siblebyGeneral ReferencesDECnet <strong>Digital</strong> Network Architecture (PhaseIV) General Description (Maynard: <strong>Digital</strong>Equipment Corporation, Order No. AA-N 149ATC, 1982).J. Forecast, J. Jackson, and J. Schriesheim,"The DECnet-ULTRIX Software," <strong>Digital</strong> <strong>Technical</strong>journal (<strong>September</strong> 1986, this issue):100-107.J. Forecast, J. Jackson, and J. Schriesheim, "CommunicationsExecutive Implements ComputerNetworks," Computer Design (November1980): 71-75.S. Leffler, W. Joy, and R. Fabry, "A 4.2BSD InterprocessCommunication Primer," University ofCalifornia <strong>Technical</strong> Report, Berkeley, California(1983) .S. Leffler, W. Joy, and R. Fabry, "4.2BSD NetworkingImplementation Notes ," University ofCalifornia <strong>Technical</strong> Report, Berkeley, California(1983) .• Strict adherence to a proven communicationsarchitecture• Porting existing designs, algorithms, and codefrom other software projects• Strict, independent certification and performancetest proceduresAn adherence to company-wide architecturesalso ensures that· future communication technologies,both hardware and software, can beeasily integrated with the existing DECnetarchitecture.116<strong>Digital</strong> TecbnicalJournalNo . 3 <strong>September</strong> 1986
Change language