.(l C/etc/connectd: Implementation NotesBill Jolitz.l).uh "Introduction".ppMany UNIX programs have duplicate mechanisms for obtaining serial portsfor use with modems and other devices. In addition, they have duplicateand frequently inconsistant facilities for operating devices like modemswhich are not very easy to debug, require program source to modify orconfigure, and generally are a nusance when new devices become availablein the market. Finally, UNIX has typically required that lines be dedicatedfor either outbound or inbound operation, and it would be convienent tobe able to use them for both in a sensible way..ppConnectd is a daemon that intend to improve this situation by managingoutbound and switchable outbound/inbound lines. It receives requests viaUNIX domain IPC and arranges for physical connections to be made on behalfof the requesting program, by in turn spawning another program to work thegiven device. These connection makeing programs, or "connectors", are mucheasier to write and debug than the special purpose subroutines that theydepricate that rely on the context of the program that they are writteninto. Since the connectors are seperate UNIX programs, they can be createdor modified without altering the programs that use them. Since they arecentralized, all user programs can equally take advantage of programimprovements without being specifically rewritten each time a new devicecomes on the market. Finally, connectd allows UNIX to sensibly manageoutbound/inbound devices to further enhance resource utilization..lpAn addtional advantage of organizing UNIX in this way is to improvethe security of the system interface to outbound devices, which are anecessary evil. Since both the facility program and connector programare isolated from access to the system resources hidden by connectd, weagain reduce the number of programs who need to be trusted with suchinformation to one relatively small program..lpTwo advantages to using IPC as the method of passing and recieving requestsare that we hide much of the implementation from those who desire to eithercreate programs needing outside access, or those wishing to create programsproviding more facilities for access. We also avoid the need to fork anapplication process, as would be the case if we chose to have connector progamsarranged as filters (e.g. popen("/etc/dialer/hayes"), which also have problemsin being easy to debug. Thus, we ease the burdenfor maintaining these facilities..lpWith the methodology we have chosen for connectd, we have modeled this serviceon the Berkeley 4.3BSD networking system, which it will be used with. Andwhile we use the socket abstraction which we prefer, there is no intimaterequirement for it in our model, streams would work just as well..uh "Assumptions:".ppUser program wants to connect to a tty line which will be connectedto another system via a modem or other equipment transparently, withoutregard to knowing what is done to make this happen..lpUser program supplies a name or a number to be dialed, plus anoption string or structure (primarily to allow a desired baud rate or rates)..lpUser program needs to recieve a file descriptor of a serial port which hasbeen connected to the entity associated with the number passed,or an explanation as to why the connection could not be made. .lpFor debugging purposes, the user of the user program should be able tooptionally recieve a running, real time account of the progress of theconnector program..uh "Implementation:".ppUser programs are modified to remove embedded dialing code, and thefollowing interface is added:.uh " User Program Interface".ppNames are mapped to absolute numbers by user program viagetphonenumberbyname(3C), which returns a structure that has phone number anddialing domain. This request is satisfied either by the domain nameserveror an phonenumber(5C) file as a last resort..lpThe connection request is made with serialconnect(3C).It takes a number structure and option buffer, and will eventually returneither a file descriptor or -1 (error in errno). If filedes 2 is connected toa "terminal", dial progress information, or error messages will be suppliedper whatever dialing process is called. The option buffer is value-result,it contains a bunch of null-terminated strings, in turn terminated by a NULL.These strings have the convention of being of the formats:.(l R	optionname#number	optionname=string	optionname.l)where optionname is some option name, and the formats encode numeric, string,and boolean information. A well - behaved program should return all optionstrings it is called with, and may return other information as well (such ascall termination sequence?). programs should look in the connector(5C) filefor generic modem configuration info..lpThe serialconnect(3C) request sends a request over the UNIX domain streamsocket bound to /dev/connect, containing the above info. Connectd(8C)recieves the request, and uses the file lines(5C) to decide on suitablelines to use, if none, sends back service unavailable error. If it findssuitable ones, and if unused by a getty, then it opens the line, forks, changesback to user uid of caller, dups to fd 0 & 1 & 2 closing others,  and execsappropriate program /etc/connectors/<modemtype> with fd0&1 opened to tty line,fd2 to users tty..lpThe modemtype is obtained from the file lines(5C), and theboth the options from the user's program and any added by lines(5C) are passedto the program as argv strings. The program can optionally return additionaloptions, and should return all (how). Connector programs.lp