DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

New Products• Listings of remote directories can also bedisplayed.• Remote files can be deleted.• Remote files can be queued to be printed orexecuted at the remote node.The files to be accessed can be specified usingwild cards and file lists.In addition to these services, NFf is responsiblefor reformatting data if it is copied to or froma remote system with a different file system format.To be a DECnet implementation, NFf had topass strict certification tests that ensured its compatibilitywith all other DECnet implementations.Passing those tests was our single biggesthurdle in this area.The project team again decided to use existingdesigns and code for NFT, the common parserand common message processer being used toparse NFf commands. We wrote the data formattingand protocol modules using DECnet-RSXNFf as a guide. Network 1/0 was done using theprogramming interface library, which providesprogrammers with network access.Using the NFf implementation in the DECnetRSX software proved to be a wise idea. Thatimplementation had been in use for manyyears; therefore, its algorithms and designwere well tested. The DECnet-DOS NFT implementationwas so successful that it was one ofthe first applications to run in house duringdevelopment.The file access listener (FAL) provides thesame services as NFf but runs on the PC to giveother network nodes access to the PC files. TheFAL utility was begun very late in the project. Asa result we were able to port the completed DECnet-ULTRIXFAL to the MS-DOS system, a taskcompleted in under two weeks. This gave theproject team enough time to add a number ofattractive optional features, such as supportingsimultaneous multiple connections.Virtual Terminal ServiceThe SETHOST utility allows the keyboard andscreen of a PC to emulate a Vfl 00 terminal connecteddirectly to a remote DECnet node. To dothat, this utility must provide not only emulationsupport for the keyboard and screen but also protocol-handlingsupport for the remote terminalprotocol used to communicate with the node.Two protocols are currently used on Digital'sproducts to provide remote terminal support:CTERM and LAT. CTERM is layered onto theDECnet software and provides remote terminalsupport to any node in a DECnet network. TheLAT protocol is independent of the DECnet softwareand provides remote trminal support onlyamong the nodes on a single Ethernet.IWe constructed the SETOST utility entirelyout of existing code, the common parser beingused to process SETHOST c'ommands. The softwareto emulate the VT l 00 terminal wasobtained from another engineering group withinDigital . The handling code for the CTERM protocolwas ported from the DECnet-ULTRIXsoftware with very few changes. The handlingcode for the LAT protocol was obtainedfrom still another engineering group. All network1/0 is done using the. programming interface·library.Virtual Disk and PrinterVirtual device services support disk and printerdevices that are located at remote nodes yetappear to be local to an application program.Our goal was to provide this:service in a transparentmanner so that no chanies had to be made toapplication programs or to the MS-DOS system.Our final design for these services was quitesimple. The services are provided by two components:the network device utility (NDU), and thevirtual device driver. The NDU accepts commandsfrom the user to establish either a virtualdisk volume or a virtual printer device at aremote node. The logical ;link is made to theremote system by NDU, and/the logical link ID ispassed to the virtual deviqe driver resident inmemory. This device driver s written to conformto the standards for MS-DOS device drivers. Itloads at system boot time by the standard MSDOS-loadable driver technique and accepts standarddevice 1/0 requests from the MS-DOS filesystem. The driver then executes these requestsby performing the equivale.nt data access protocolsequences on the logical link established byNDU.'!The data access protocol 'chosen was the sameone used for file transfer. This choice allowed usto use existing DECnet implementations onlarger systems for the virtual device support.Thus the need to design and implement a specializedprotocol for a numbr of different operatingsystems was eliminated.Digital TecbnicaljournalNo. 3 September 1986113
Tbe DECnet-DOS SystemNDU and the virtual device drivers were builtfrom three subcomponents:• A common parser and common message processor(described in the next section)• A small library of subroutines that createremote files and open them using the dataaccess protocol (These subroutines weretaken directly from NFT.)• The programming interface libraryNetwork MailDigital provides network-wide mail services for anumber of its systems. These utilities allow usersto compose messages directly within the mailutility or to use an editor or pre-existing text fileas the source . Text can be sent to one or moreusers on a multitude of systems, even using a distributionlist from another text file .The DECnet-DOS mail utility was completed ina short time by combining the common parserwith the mail utility from the DECnet-ULTRIXsoftware. The unique requirements of a smallsystem did present some problems. In a DECnetnetwork, node addressing is done by numericaddresses. However, users often prefer to usenames, which can be more easily remembered.To facilitate that use, each node maintains a databasethat maps names to addresses. Now, sucha database for a large network would be toolarge for a small PC to keep on disk or searchquickly. Yet the PC users may want to send mailto other users anywhere in such a network. Forexample, Digital has an in-house network withover 1 0, 000 nodes, any one of which can beaddressed by any other. To solve this problem weimplemented the mail-forwarding feature of themail protocol. That feature allows a PC user tosend a message to an unknown node by asking aknown node to forward the message. Thus the PCdatabase keeps a much smaller list of knownnodes, which is considerably more manageable.The project team originally had a requirementfor receipt and storage of network mail on thelocal disks of the PC. Our investigations showed;however, that the engineering cost of developinga background task that could record the receivedmail on disk was very high.Since 1/0 in the MS-DOS system is singlethreaded, the network software, running in thebackground, cannot perform 1/0 while an applicationprogram is performing it. To overcomethis restriction, our PC mail service automaticallytells the receiver of mail from the PC whichlarge system should be sent the replies.Application Layer ServicesApplication Program CommandParsingThe DECnet-DOS product would contain as manyas ten different application programs, includingone each for file access, virtual terminal support,virtual device support, and mail services; andtwo for network management. Our requirementscalled for common, easily translatable messagesand common command parsing, inCluding characterdelete, line and character recall, and abbreviation.These standards were important becauseit would be very costly to have ten differentengineers coding in ten different ways . Such anapproach, without standards, could have introduceddifferences in the applications, whichwould be difficult for the end user to learn andremember.To avoid this problem we designed and implementeda common parser and a common messageand help processor. The common parser isdriven by a parsing command file that supportsabbreviation, character delete, and line recall.The common message processor is also driven bya message fi le and performs fast look-ups of textstrings and blocks. This design greatly reducedthe time to code and debug the utility programsand made their translation to foreign languagesfairly straightforward.Network Ma nagementThe network management architecture in theDNA architecture re quires access to currentparameters, ·counters, and statistics, all kept inthe volatile database. It also needs the parameters,kept in the permanent database, that will bein effect the next time the network software isstarted. Data in both databases should be accessiblefrom either the local node or a remote node.However, the single-threaded restriction thatthe MS-DOS system imposes on file 1/0 makesaccess to the network management databasesvery difficult. This restriction not only affects themail service, as explained earlier, but preventsDECnet-DOS from providing remote access tolocal network management databases. It also preventsthe background network software fromaccessing disk files. Thus the project team felt114Digital TecbnicalJournal·No. 3 September 1986
Page 1 and 2:
Netwo;king ProductsDigital Technica
Page 3 and 4:
Editor's IntroductionRichard W. Bea
Page 5 and 6:
BiographiesRaj Jain Raj Jain gradua
Page 7:
BiographiesDavid R. Oran Dave Oran
Page 10 and 11:
increase the sizes of networks, we
Page 12:
New Productsmust be able to coexist
Page 15 and 16:
A Digital Network Architecture Over
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
---A Digital Network Architecture O
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Performance Analysis and Modeling o
Page 29 and 30:
---Performance Analysis and Modelin
Page 31 and 32:
Performance Analysis and Modeling o
Page 33 and 34:
---Performance Analysis and Modelin
Page 35 and 36:
--Performance Analysis and Modeling
Page 37 and 38:
The DECnet/SNA Gateway Product• H
Page 39 and 40:
The DECnetjSNA Gateway ProductFrom
Page 41 and 42:
The DECnetjSNA Gateway Productcommu
Page 43 and 44:
The DECnetjSNA Gateway ProductUSER
Page 45 and 46:
The DECnetjSNA Gateway ProductThe u
Page 47 and 48:
The DECnetjSNA Gateway ProductDECne
Page 49 and 50:
The DECnetjSNA Gateway Productopera
Page 51 and 52:
The DECnetjSNA Gateway ProductSegme
Page 53 and 54:
The DECnetjSNA Gateway Product• O
Page 55 and 56:
WiUiam R. HaweMark F. KempfAlanJ. K
Page 57 and 58:
The Extended Local Area Network Arc
Page 59 and 60:
Page 61 and 62:
Page 63 and 64: The Extended Local Area Network Arc
Page 75 and 76: Terminal Servers on Ethernet Local
Page 89 and 90: Paul R. Beckjames A. KryckaThe DECn
Page 91 and 92: The DEC net- VA X Product - An Inte
Page 93 and 94: The DECnet- VA X Product - An Integ
Page 95 and 96: The DECnet- VAX Product - An Integr
Page 97 and 98: The DEC net- VA X Product - An Inte
Page 99 and 100: The DECnet- VAX Product - An Integr
Page 101 and 102: john Forecastjames L. jacksonjeffre
Page 103 and 104: The DECnet,ULTRIX SoftwareComponent
Page 105 and 106: The DECnet- ULTRIX Softwarehave pro
Page 107 and 108: The DECnet- ULTRIX Softwaresystems.
Page 109 and 110: Peter 0. MierswaIDavid J. MittonMar
Page 111 and 112: The DECnet-DOS Systemthat CCB, whic
Page 113: The DECnet-DOS Systemdata link laye
Page 117 and 118: Th e DECnet-DOS Systemconsole can a
Page 119 and 120: The Evolution of Network Management
Page 131 and 132: The NMCCjDECnet Monitor Design5. Op
Page 133 and 134: Th e NMCCjDECnet Monitor DesignFigu
Page 135 and 136: The NMCCjDECnet Monitor DesignKERNE
Page 137 and 138: The NMCCjDECnet Monitor Designinto
Page 139 and 140: The NMCCj/JECnet Monitor DesignThe
Page 141 and 142: The NMCCjDECnet Monitor Designcan s
Page 143 and 144: Editorial StaffEditor - Richard W.
show all

DTJ Number 3 September 1987 - Digital Technical Journals

Create successful ePaper yourself

Delete template?

Save as template?