DTJ Number 3 September 1987 - Digital Technical Journals

-Those functions that occur more infrequentlyhave been implemented in NETACP, which providesthe necessary process context. These functionsinclude state changes and others thatrequire a process context to allow access to alarge pageable database or system service. Theseinclude logical link creation and deletion, networkmanagement functions operating on thevolatile database, and routing table maintenance.Network Server ProcessesTransferring large files across a network oraccessing many remote files can consume considerableresources on a remote system. Thus theprovision of accurate accounting information forremote file access operations is quite desirable.This need led to the implementation of FAL as asingle-threaded server. That server runs in thecontext of a process logged in to the remote systemon an account that is accessible to the initiatorof the file access request.RMS, being procedure based, does not knowwhether or not an application program intendsto access additional files via the same account onthe remote system. Originally, the DAP implementationin RMS was designed to terminate thelogical link with FAL upon closing a file or finishinga file search sequence. Consequently, forexample, a wild-card operation transferring nfiles using the COPY command results in theinvocation of a total of n + 1 FAL processes.One process performs the RMS search sequence,each of the others transfers in serial fashion eachfile that is found. Unfortunately, this approachsignificantly reduced overall throughput, especiallywhen a large number of small files werebeing transferred.The primary disadvantage of using separateprocesses for individual network tasks lies in theoverhead required to create the process. Theincreasing complexity of authorization and protectionmechanisms within the VMS system hasincreased the start-up time during process creation.This increase is experienced by usersactivating network tasks on other nodes as anincrease in response time.Support for network server processes wasintroduced in 1983 to solve the overhead problem.A NETSERVER process can handle seriallymany logical links that require the same accounton the server node. NETACP maintains a list ofthose NETSERVER processes that have beenstarted for particular accounts but are now cur-IIIrently idle. When a new 'ogical link requestspecifying the same account is received, NETACPwill forward the request to an appropriate idleNETSERVER process instead of creating a newprocess to handle the request. On a busy system,this action can trim seconds off the start-up timefor the logical link. To pr¢vent the problem ofthe local system filling up with NETSERVERprocesses that no one nees to talk to, an idleNETSERVER will time out ahd delete itself after acertain amount of time.In 1986, FAL was extended to include thecapability to serially prodess multiple logicallinks (and as a result, multiple files) . This additionyielded a significant improvement in overallthroughput for file transfer activity, especiallyfor wild-card operations.Window-based Congestion ControlIn a large network, data packets must be routedthrough several nodes befre reaching their destinations.Congestion in ani intervening node canseverely decrease the thro 1ughput of all logicallinks using that path. Coninuing to send moredata through a congested nde only makes thingsworse. The systems at the ends of the logical linkhave no knowledge of which path is being used;therefore, they have no direct way of knowingwhere congestion may be occurring in the network.This problem was addressed through theimplementation of a winow-based "back-off"scheme designed to detect the presence of congestionsomewhere along lthe path. The rate atwhich data is sent will be reduced until theeffects of the congestion ate no longer seen.IiNode Database StructureDigital Equipment Corporation has a very largeinternal communications network. As that networkgrew in size, its volatile node databasebecame a performance bottleneck. Searchesthrough the database to locate a particular entryby name were causing exessive paging. Notingthat the node database isi frequently accessedusing either the node name or the address as asearch key, it was decide that the speed of alook-up should be the sae for either type ofsearch. To accomplish tht, the node databasewas augmented by two balanced binary searchtrees, one keying off the node address, the otheroff the node name. 3 Each entry in each tree containsa pointer to the node database entry referencedby that entry. It also has a separate pointerINew ProductsDigital Tecbnical]ournalNo. 3 September 198697