DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

New Productshigher-level langage and fairly strict codingstandards to shorten our development time. Wealso had to initiate a search for code fragmentsalready existing within Digital that were alsorequired in our product. We felt that incorporatingrelated code could also greatly reduce boththe development and debugging time.The MS-DOS environment is quite similar tothe UNIX environment. Many C compilers basedon MS-DOS machines offer libraries similar tothe one on the UNIX system. Therefore, it wasquite fortuitous that the DECnet-ULTRIX system,Digital's DECnet implementation for the ULTRIXsystem, had just been completed. It was writtenalmost entirely in the C programming language.We felt that some of the DECnet-ULTRIX codecould be used successfully in DECnet-DOS. Ourstrategy was to do the following tasks:• Write as much code as possible in C. Do notpreclude the use of assembler languageif required to access devices or servicesunavailable in C or to reduce execution timewhere necessary.• Use common coding and style practices forall code.• Adopt the DECnet-ULTRIX programminginterface. The programmer's access to networkservices is not part of the architecturebut is specific to the operating system andthe DECnet implementation.• Port code from the DECnet-ULTRIX softwarewhenever it is applicable and easier thanwriting original code.• Include trace facilities in the basic driverand all utilities as part of the design.Training IssuesAt the start of this project, few engineers inDigital's Network and Communications Grouphad extensive experience with MS-DOS internalsor C programming. To prevent a certain delay ofseveral months while people were trained, theproject team decided to pursue two avenues ofexternal assistance: temporary in-house consultants,and external engineering. Three consultantswith MS-DOS and C programming backgroundswere employed, being gradually replacedby Digital employees as they completedtheir training. An arrangement was made with theComputing Resources Department of the Univer-sity of Texas Health Science 1 Center, San Antonio,to implement the file transfer utility. They hadexpertise developing an in-house DECnet implementationon another small system.Background Task DesignThe MS-DOS system is a single-task operating system;no services are providd to support the concurrentexecution of two tasks. This fact raised aproblem because a number ! of the requirementsfor the DECnet-DOS system! demand the concurrentoperation of some network tasks with theuser's current application. Such tasks include the.transmission and reception of periodic routingand line confidence messages, and the concurrentoperation of multiple connections. Moreover,a particular constraint was that applicationprograms have to run as wrtten, without codingchanges, while the network! is active. We simplycould not require that the thousands of applica-1tions currently on the market for MS-DOS-basedsystems be changed.To solve this problem, we devised a schemethat would allow network tasks to run either atperiodic intervals or from an interrupt from acommunications controller. This design envisionedthat network tasks wre interruptable andcould run in the background completely transparentto the application prgram running in theforeground. This scheme I had to be designedquickly and work the first ! time for the projectteam to complete the product on schedule.Unfortunately, the design of task scheduling inthe DECnet-ULTRIX software was incompatiblewith our scheme. Therefore, that portion of theDECnet-ULTRIX code could not be ported tosolve this problem. However, the interrupt architectureof the PDP- 11 syst.em and those of theIntel processors in the target machines are verysimilar. Therefore, the intetrupt design from theDECnet-RSX software thatlruns on the PDP- 11system could be used for the , interrupt functionin DECnet-DOS.The DECnet-RSX CPU scheduler uses a set ofwork queues in which request packets calledcommunication control blocks (CCB) arequeued for processing. Any data buffers associatedwith the requests are pointed to by fieldswithin the CCBs. ;For example, if a messag is received from thecommunications controllet, a CCB will be createdby the device driver fr the controller. Thereceived data is placed in a. buffer pointed to byDigital TechnkalJournalNo. 3 September 1986109
The DECnet-DOS Systemthat CCB, which will be placed in the workqueue of the routing layer. This layer, when run,will process the buffer pointed to by the CCB. Iffurther processing is necessary, this layer willplace the CCB in the work queue of another networkprocess.This scheme would work perfectly well if theCPU scheduler were designed to scan the workqueues both at periodic intervals and after controllerinterrupts. Then the scheduler would dispatchthe network tasks to empty the workqueues. And all these actions must happen sothat they are transparent to the current foregroundapplication.To fulfill those requirements, we designed amemory-resident scheduler that performs allthose actions by using a technique called interruptshelling. To shell an interrupt, the schedulerfirst records the address of the currentinterrupt handler, then replaces it with thescheduler's own address. Thus when the interruptoccurs, the CPU state and the interruptreturn address are saved, and the scheduler,instead of the original interrupt handler, is calleddirectly.Upon entry for an interrupt, the schedulersaves the current context of the system and simulatesan interrupt to the original interrupt handler.When the interrupt processing completes,the interrupt handler will return to the scheduler- not the foreground task. Therefore, thescheduler now gains control. The interrupt processingis now complete and the time-criticalprocessing has finished. The scheduler can nowenable interrupts and examine all work queuesfor tasks that need to be run. After all tasks havebeen run, the scheduler finally returns to theinterrupted foreground task.Two examples will help to make this processmore clear.First, consider an interrupt from an Ethernetcontroller that signals the successful reception ofa message from some other node in the network.When the controller causes the interrupt, thescheduler gains control with interrupts disabled.The scheduler saves the return address and stateand dispatches to the "real" interrupt handler ofthe Ethernet controller. The interrupt handlerperforms the following series of actions:1. Analyzes the interrupt2. Determines that a message has beenreceived3. Allocates a receive buffer4. Copies the message from the Ethernetcontroller to the receive buffer5. Resets the controller to receive anothermessage6. Calls a subroutine to insert a CCB pointingto the message onto the work queue inthe background network processThe Ethernet interrupt controller then dismissesthe interrupt, and control returns to the scheduler.The scheduler now enables interrupts andscans the work queues for additional work.The CCB containing the received message isfound on the work queues and the routing layeris called to completely process the message.When all work queues with immediate work areempty, the scheduler finally returns to the originallyinterrupted code in the user's applicationprogram.The second example deals with handling aninterrupt from the clock. In this case exactly thesame code path as the one in the first example isfollowed. The clock interrupts and the schedulergains control with interrupts disabled. It savesthe return address and state and dispatches tothe "real" clock interrupt handler. This handlerwill update the date and time and dismiss theinterrupt. Control now returns to the scheduler,which enables the interrupts, scans the timerqueues, and dispatches any process whose timerhas expired. When all such processes havebeen completed, the scheduler returns to theoriginally interrupted code in the applicationprogram. ·Using the scheduler to handle interrupts andcontext switching allows network processing tobe performed in the background while an MSDOS application is running in the foreground.The interrupt shell ensures that a minimumamount of code runs with interrupts disabled.The background process scheduling ensuresthere is no network performance loss due to apause between message receipt and message processing.Overview of the DNA ArchitetureTable 1 lists the layers of the ISO model for datacommunications, along with the correspondingDNA layers and the appropriate DECnet-DOScomponents within each layer.110Digital TecbnicaiJournalNo. 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: 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: Peter 0. MierswaIDavid J. MittonMar
Page 113 and 114: The DECnet-DOS Systemdata link laye
Page 115 and 116: Tbe DECnet-DOS SystemNDU and the vi
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?