Since its initial release, the PATHWORKS product family has implemented the DECnet transport pro tocol to provide access to basic file services and printer sharing, terminal emulation, and applica tion services. This network software implementa tion is called the DECnet Network Process (DNP) transport component. Figure 1 illustrates the rela tionship between the DNP transport component and the other memory-resident PATHWORKS cl ient software components.
Dt:Cnet TrmtSj)()rt A rchitecture DOS APPLICATIONS APP LICATION PROGRAMS NETB IOS APPLICATIONS D EC N ET APPLICATIONS ( IOCB INTE R FACE)
- -- - - - -- - - -- -- - -- - - -- -
SYSTEM PROGRAMS
DOS O P ERATING MIC ROSOFT LAN
SYSTEM MANAGER DECNET N ETWORK PROCESS ( D N P ) PC T I M E R A N D I N T E R R U PT SCHEDULER
HARDWARE (SCH) DATA LINK LAYE R ( DLL)
LAN HARDWARE
h�!{llre I PA Tii WORKS Client Components Goals for PATHlVORKS Client Softtuare
PC network soft ware p rod ucts are j udged pri marily on t wo cri teria: perform ance, usua l ly measure d w i t h popu l a r bench mark programs. and resident memory usage. a I i m i red resource rha r may restriu
orhcr appl ications. Increasing performance and
decreasing nw mory usage are major goa ls for a l l nnv releases of t h e PAn I WOR KS cl ient soft ware. I n t h e J>,\TJ I WORKS vers ion ..f. l c l i e n t software. D igital sought to double the performa nce of the DNP t ransport com ponenr for s ma l l data transfers, wh i le decreasi ng the size of the code by 'iO perce n t . Another goal w a s t o signi ficantly red uce m a i n te nance costs in order to free enginee ring resources for fu ture projecl tl<:velopment.
Befon: describi ng how we went about ach iev i ng t h ese performance. mem ory. and development cost go:t ls in I'ATI I WOH KS wrsion i . J . we rev iew the func tiona l i t y of tile DLCner DN I' i mplemen t a t i o n . \XIe also d iscuss the component i n rel a t i o n to other l'Al l l \\IO H K S c l i e n t components to give tile context i n which our design decisions were made.
The DNP
Component Functionality
Appl ication p rogra ms can use ONP t ra nsport ser vices t h rough one of t wo software i n t e rfaces: the network basic l/0 system ( N e l i i i OS) i n terface and the 1/0 con t ro l block ( IOCil) i n terface. The widely accepted Net r i i OS in ter face is used by app l ications
D iy,ita/ 7i-clmical journal I r>i. -i Xu. I \l" i111er /'}'}}
a n d drivers that comply ·wi t h ind ust ry- stanclard spcci.tica tions to prov ide peer- to-peer transport serv ices o n a I .AN. The JOCB interface is specitic to D igi t a l 's DECnet t ransport implementa tion of tile DEC:net protocols. lOCB provides a socket i n terface
similar to the one used by the l l t:m r x oper a t i ng system . Th is IOCB i n te rface is used by DECnet spec i tic appl ication programs.
To com m u nicate w i t h the network, the DNI'
transport component ca l i s the data I ink layer (D LL) software i n terface. The DJ.l. com ponenr is used by all l'ATHWORKS client components to send and receive packets on tile !.AN. This component dem u l t i plexes incoming packets based on their protocol type (e.g., local a rea tra nsport [I .ATJ, local area system transport 1 LAST]. or DECnet t ra nsport) and del i vcrs these p ackets to the corresponding
PAI'HWOR KS cl ient component. The Dl.l. compo
n e n t a l so trans m i ts packets on the LAN, either d i rectly or i n d irectly by c1ll ing standards-based network d rivers. To red uce mem ory consumption, the DU. component provides a global buffer pool t h a t the DNI' and other transport compo nents can use for b u i l d i ng network packets or for storing u nacknowledged data.
To p rovide tim i ng and backgro u n d process ser v ices, the DNI' component ca l l s the I'ATJ l WORKS
rea l-rime Schedu le r (SCH) component. The SCH com m u n ica tes d i rect l y wi t h the DOS operat i n g
PATHWORKS: PC Integration Software
system and the PC's timer and i nterrupt hardware to create a simple cooperative process environment. This env i ronment includes sleep and wake cal:ls, and periodic interval timers. The fu nct ions of th<.: SCH compon<.:nt ar<.: simil:.ir to those pnform<.:d by true multitasking operating syst<.:ms, such as the OS/2 system, which use preemptive schedu l ing. Considerations for a New DNP
Component Design
In previous PATHWORKS cl ient software, separate teams implemented and mai ntained th<.: DOS and OS/2 versions of the DNP transport component. We decid<.:cl to use the same base source code for both versions and thus reduc<.: development and mai nte
nance costs. We then proceeded to consid<.:r our
design options.
Original ly, the DNP component was wri t ten in the C programming language. The internal archi tec ture remained basica l ly unchanged d u ring the five years fol lowing its release. This stable code should have been easy to port between operating systems. Howe,·er, the internal archi tecture of the OS/2 sys tem was n<.:v<.:r considered in the original design b<.:cause this syst<.:m was not available until 1988. Retrofitting the DOS version of the DNP component for the OS/2 operating system was d ifficu lt, and we were not able to maintain a common source code base.
To achieve the performance, memory, and devel opment cost goals described earl ier in this section, we considered the fol l owing three approaches:
1 . Rewrite the current DNP transport component 2. Write a new DNP transport component i n C 3. Write a new DNP transport component in assem
bly language
Rewri ting tl1e current DNP component wou ld not have produced a desirable amount of code com mon to the DOS ancl OS/2 versions. In addition, this approach wou ld have resulted in only minimal ly improving the m a intainabi l i t y of the code. Wri ti ng a new transport component in C wou ld have yielded a more portable code, but the performance and memory usage would not have compared favor ably with other vendors' transports. We decided to write the new transport component i n assem bly language to make optimal use of the l i m i ted mem ory available on today's personal computers.