DTJ Number 3 September 1987 - Digital Technical Journals

New Productschanges to the physical address of the hardwareinterface, enable and disable the reception ofmulticast messages, and control more extensivesupport for device counters than had previouslybeen present.Object SpawnerWe thought that one area could be greatlyimproved over the standard socket support in the4.2BSD standard: the invocation of server, or"daemon," processes. When a client programconnects to a server program, software on thespecified node has to decode the address andinform the correct target program that it has apending connection. Calls from the 4.2BSDsocket kernel support that software in a wayrequiring all possible destination processes to berunning and listening for connections. This supporthas several bad effects. First, each of thoseservers consumes memory and slots in the processtable. Second, writing a new server processis more difficult since each process has to issuemultiple system and library calls to receive andbind its address to a socket.To solve these problems on the DECnet­ULTRIX software, we implemented an "objectspawner," which creates a socket to which theprocess binds a special address. That addressinforms the DECnet code in the kernel thatthe spawner should be given the connectionrequests for which no other process has declaredan interest. With this mechanism the existingmodel of server process is still supported and canbe used as desired. A process may choose to createits own socket and listen for connections. Itdoes.that if it wants to handle multiple socketsper process or to decrease the connection processingtime by the time required to create a newprocess and execute a file.Using the DECnet object spawner greatly simplifiesthe writing of a new server and providesseveral useful services. A new .server has to bedefined in the DECnet object database by usingNCP. Defining a server involves specifying itsaddress and the file that should be executedwhen a connection for the server arrives. Additionalparameters indicate the type of socket thatshould be created for the server (stream orsequenced packet) and the default user accountto run under if no access control information issupplied by the '.client process. The spawnerauthenticates ever.y.:t:hing for the server and executesthe process in the context of the specifieduser account. Once the process is executing, theserver simply needs to read and write from standardinput and output, set ;up by the spawner tobe directed to the created ocket.Network ManagementThe user interface to network management isprovided via NCP, which on the ULTRIX systemaccepts the same command syntax as that on allother DECnet systems. NCP communicates withthe network management listener (NML) , bothon the local system and on remote systems, toexecute management commands. Local commandscause NCP to con;tmunicate with NMLusing a UNIX ''pipe''; remote ,commands are executedthrough DECnet sockets. NML controls themanagement databases, implemented mostly asfiles with some parameters stored in the kerneland accessed through a special DECnet socketinterface.The access methods and file organization forDECnet databases are quite different from thoseprovided by the 4.2BSD TCPfiP implementation.The TCP fiP databases are organized as a set offiles constructed and mo d ified using any standardtext editor. Those files contain the hostname-to-address mapping and the service nameto-addressmapping. Program access to thosefiles is supported only for read operations. Thislimitation was unacceptable for the DECnet databases,which require full read and write accessusing the NCPfNML programs. NCP supportscommands to add and modify entries for manyDECnet entities. Moreover; the DECnet databasesmust support networks cbntaining many thousandof nodes.We explored several alternative ways of structuringthe databases to provide such programaccess to support write operations. Eventuallywe chose a file format organized as a simplesequential binary file. Reading an element fromthe database involves first allocating enough virtualmemory for the entire file. Then the file isread into virtual memory,' and a linear search isperformed for the desired element. Writing anIelement into the file involves reading the entirefile into the allocated virtual memory. Then thefile is .searched for the :position of the newelement, which is written to the file. Finallythe remainder of the existing portion of thefile is written into its new position in the file.While this "brute force" method was not particularlyelegant, its performance and reliabilityDigital Tecbnlcal]ournalNo. 3 September 1986103