DTJ Number 3 September 1987 - Digital Technical Journals

The DECnet- ULTRIX Softwaresystems. Supporting the mail- 11 protocol was asimple matter of writing a mailer program adheringto the sendmail interface and speaking themail- 11 protocol . Once this program was written,we modified the sendmail configuration fileto handle DECnet mail addresses properly so thatthe DECnet mailer would be invoked- when necessary.Only a few minor problems were encountereddealing with different ways to parse mailaddresses and different comments contained inmail addresses between VMS systems and theULTRIX sendmail program.With this new capability, ULTRIX systems cannow act as mail gateways between DECnet networksand any other type of mail network supportedby UNIX systems.DEC net- UL TRIX PerformanceOne original goal for the DECnet-ULTRIX softwarewas to provide a level of performance similarto that of the TCP jiP domain. In general, wemet this goal. Both rep and dcp transfer files atapproximately the same rate, and while rep isslightly faster,. it requires a larger percentage ofthe available CPU time.The following measurements were takenbetween two VAX- 11/780 systems on a privatenetwork:dcp average filetranfer raterep average filetransfer rateftp average filetransfer rateDECnet maximumdata transfer rateProject Management51 kilobytes (KB)per second51KBper second27KBper second1200 kilobits (Kb)per secondThe DECnet-ULTRIX project began in early1984. The Berkeley 4.2 version of the UNIXsoftware had just been selected as the basis forDigital's UNIX software for the VAX system. Version1.0 of the ULTRIX system was well on itsway to completion. Our task was to define theDECnet-ULTRIX project, build a project team,and deliver a Phase IV implementation for theULTRIX system in the shortest possible time.At the start, each team member had a lot ofDECnet and software development experience,but very little UNIX expertise. As we learned theintricacies of the UNIX software, we discussedmany of our development ideas with peoplefrom Digital's UNIX Engineering Group. Wedecided our first project should be to implementan Ethernet end node using the DNA Phase IVprotocols. This implementation would includesupport for a programmable user interface, mail,and file transfer. Our decision to add a remoteterminal capability was made later. Experiencewith other DECnet implementations had shownus that these functions would be both necessaryand sufficient to satisfy the majority of mostusers' needs.We built prototypes whenever possible to getfunctions working quickly. These prototypestested the viability of the interfaces and variousimplementation approaches. Often we exploredseveral different designs before choosing onethat worked best as a prototype.These shortcuts can be very valuable, providedthey are followed by a thorough review of thework done. On this project this method workedvery well. The ULTRIX system ran as a DECnetend node in late summer 1984, after which timeseveral UNIX utilities were quickly converted touse the DECnet software.Our past experience helped us to gauge theamount of work required in each developmentarea. That experience allowed us to start workearly on network management since previousimplementations had shown that area to be oneof the largest bodies of work. Throughout theproject we succeeded in keeping work on eachcomponent from being blocked by dependencieson other components. With tight project managementwe put the DECnet-ULTRIX softwareinto field test less than one year after the projectbegan.The entire product was written in the C programminglanguage; a large amount of codewas later transported to other projects, notably toDECnet-DOS. Our experience transporting theimplementation improved the quality ofthe code since many components were testedusing additional interfaces and different codereviewers.SummaryThe DECnet-ULTRIX project provided manychallenges. The most constant one was how tobuild a product that appeared similar to otherDigital products, yet acted like a natural extensionto the UNIX base upon which the productwas built. The compromises required to meet106Digital TecbnicalJournalNo. 3 September 1986