10.07.2015 Views

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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 DECnet­DOS software. This shift overcame the backgrounddisk 1/0 restriction. Also, even thoughremote nodes cannot access our local DECnet­DOS 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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!