DTJ Number 3 September 1987 - Digital Technical Journals

The DECnet- ULTRIX Softwarehave proven to be very acceptable, even withextremely large databases. Other methods relyingon indexed and hashed file access proved tobe far more complicated than their marginal performancebenefits warranted.One idea we examined during the developmentof the DECnet-ULTRIX software was tobuild a new network management database thatcould include entries from TCPfiP, DECnet, andother protocols. This idea was abandoned for tworeasons. First, we found that existing calls to theTCP flP database routines did not contain all thenecessary parameters required to support networkaddresses of more than one format. Sinceone project goal was to leave the existing networkprogramming interfaces unchanged, thisidea made impossible the adding of new parametersto those function calls. Second, we felt thatcreating new routines that were to be linked intocustomers' programs would require a significantlydifferent database format, thus requiringthe relinking of existing TCP flP applications.We deemed this relinking to be unacceptable.What we did do, however, was to ensure thatthe DECnet and Internet database routines werecompatible in their naming and calling conventions.In that way a later release could changeboth sets of routines to be "stubs" that calledinto a common base of supporting routines. Weintend to explore this concept further when weadopt a name server-based mechanism for storingcertain network management information.File TransfersIn a DECnet system, file access operations areperformed using the data access protocol (DAP) .File access uses a clientjserver model in whichthe client program contacts a server program toaccomplish some task specified by a user. DAPsupports most of the common file system operations,such as reading, writing, deleting, and listingthe names of files. For the first release of theDECnet-ULTRIX software, we decided that DAPclient operations would be implemented using anew set of file operation commands called the d(for DECnet) commands. They are similar in conceptto the 4.2BSD rep command for remotecopy. The d commands are as follows:dcp - for DECnet copy files (as in the UNIX"cp" command)dis -for DECnet list file directory information(as in the UNIX "Is" command)drm - for DECnet remove files (as in theUNIX "rm" command)dcat - for DECnet type files (as in the UNIX"cat" command)We decided to provide only command-levelaccess to DAP file operations to shorten thedevelopment time for the DECnet-ULTRIX project.The d commands were implemented using aset of file access routines with a calling conven-­tion very similar to the normal C-standard 1/0routines (stdio). We decided not to make thed routines available to customers. We felt thatnetwork file access should be transparently availableto all programs, not just those using a specialset of 1/0 routines. Making the routinesavailable would require extensive changes to theULTRIX kernel, something not possible givenour tight development schedule.The server side of the DAP implementation is afile access listener (FAL) program that is invokedusing the standard DECnet object-spawningmechanism to handle user requests. FAL is astraightforward program that can sometimes fallshort of what users expect it to do. In fact thebiggest challenge we faced in implementing theDAP protocol on the UL TRIX system was to meetthe expectations of both UL TRIX and remoteoperating system users concerning what constitutesreasonable behavior. The DAP protocol hasmany options, but each DAP implementationincorporates a slightly different dialect. Theseslight differences exist because each operatingsystem's file operations are different. Each systemmust map its own way of performing thoseoperations into the DAP operations. Writing eachside, the client and the server, of a new DAPimplementation presents different problems.These problems are exacerbated when onerequires also that no .existing DAP implementationbe changed to work with the new implementation.The client side of DAP drives the fileoperations; the server side is passive, performingonly the operations requested. Most problemsoccur because the UL TRIX system has noenforced record structure within its files, whilemost of Digital's other operating systems performtheir file access using a record orientation. TheULTRIX client code, as implemented in thed commands, cannot simply request other DAPservers to supply data in ULTRIX record format(stream). Instead, the d commands must interpretthe record formats of those other operating104Digital Technical JournalNo. 3 September 1986