![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ipcpaper.rf CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / ipc|
Return to ipcpaper.rf CVS log | Up to [Research Unix] / researchv10dc / vol2 / ipc |
1.1 root 1: .lf 1 ipcpaper
2: .ND
3: .TL
4: Interprocess Communication
5: .br
6: in the Ninth Edition Unix System
7: .AU
8: D. L. Presotto
9: D. M. Ritchie
10: .AI
11: AT&T Bell Laboratories
12: Murray Hill, New Jersey 07974
13: .AB
14: When processes wish to communicate, they must first establish communication,
15: and then decide what to say.
16: The stream mechanisms introduced in the Eighth Edition Unix system\*(<,\*([.1\*(.]\*(>,
17: .FS
18: Unix is a trademark of AT&T.
19: .FE
20: which have now become part of AT&T's Unix System V\*(<,\*([.2\*(.]\*(>,
21: provide a flexible way for processes
22: to speak with devices and with
23: each other:
24: an existing stream connection is named by a file descriptor,
25: and the usual read, write, and I/O control requests apply.
26: Processing modules may be inserted dynamically
27: into a stream connection, so
28: network protocols, terminal processing, and device drivers separate
29: cleanly.
30: .PP
31: Simple extensions provide new ways of establishing communication.
32: In our system, the traditional Unix IPC mechanism, the pipe, is
33: a cross-connected stream.
34: .PP
35: A new request associates a stream with a named file.
36: When the file is opened,
37: operations on the file are operations on the
38: stream.
39: .PP
40: Open files may be passed from
41: one process to another over a stream.
42: .PP
43: These low-level mechanisms allow
44: construction of flexible and general
45: routines for connecting local and remote processes.
46: .AE
47: .LP
48: .SH
49: Introduction
50: .PP
51: The Ninth Edition version of Unix\(rg operating system
52: is used in the Information Sciences
53: Research Division of AT&T Bell Laboratories, and at a few sites elsewhere.
54: It is named, by our custom,
55: after its manual.
56: .PP
57: The work reported here provides convenient ways
58: for programs to establish communication with unrelated
59: processes, on the same or different machines.
60: The communication we are interested in is conducted by
61: ordinary read and write calls, occasionally supplemented
62: by I/O control requests, so that it resembles\(emand, where possible,
63: is indistinguishable from\(emI/O to files.
64: Moreover, we wish to commence communication in ways that resemble
65: the opening of ordinary files, or at least takes advantage of
66: the properties of the file system name space.
67: .PP
68: In particular, we study how to
69: .IP 1)
70: provide objects nameable as files that invoke useful services,
71: such as connecting to other machines over various media,
72: .IP 2)
73: make it easy to write the programs that provide the services.
74: .PP
75: .SH
76: Recapitulation
77: .PP
78: The Eighth Edition system introduced a new way of communicating with
79: terminal and network devices\*(<,\*([.1\*(.]\*(>,
80: and a generalization of the internal interface to the file system\*(<.\*([.3,\|4\*(.]\*(>.
81: Because the new mechanisms build on these ideas, we
82: review the nomenclature and mechanisms
83: of our I/O and file systems.
84: .SH
85: .I "Streams
86: .PP
87: A
88: .I "stream
89: is a full-duplex connection between a process and a device
90: or another process.
91: It consists of several linearly connected processing modules,
92: and is analogous to a Shell pipeline, except that
93: data flows in both directions.
94: The modules in a stream communicate
95: by passing messages to their neighbors.
96: A module provides only one entry point to each neighbor, namely
97: a routine that accepts messages.
98: .PP
99: At the end of the stream closest to the process
100: is a set of routines that provide the interface to the rest of the system.
101: A user's
102: .I "write
103: and
104: I/O control requests are turned into messages sent along the stream,
105: and
106: .I "read
107: requests take data from the stream and pass it to the user.
108: At the other end of the stream is either a
109: device driver module, or another process.
110: Data arriving from the stream at a driver module
111: is transmitted to the device, and
112: data and state transitions detected by the device are
113: composed into messages and sent into the stream towards the user process.
114: Pipes, which are streams connecting processes,
115: are bidirectional;
116: a writer at either end generates stream messages that are picked up by the reader
117: at the other.
118: .PP
119: Intermediate modules process messages in various ways.
120: They come in pairs, for handling messages
121: in each of the two directions, and each pair is symmetrical;
122: their read and write interfaces are identical.
123: .PP
124: The end modules in a device stream become connected automatically when
125: the process opens the device;
126: streams between processes are created by a
127: .I pipe
128: call.
129: Intermediate modules are attached dynamically by request of the user's program.
130: They are addressed like a stack with its top close to the process,
131: so installing one is called `pushing' a new module.
132: .PP
133: For example,
134: Figure 1 shows a stream device that has just
135: been opened.
136: The top-level routines, drawn as a pair of half-open rectangles
137: on the left, are invoked by users'
138: .I read
139: and
140: .I write
141: calls.
142: The
143: writer
144: routine sends messages to the device driver shown on the right.
145: Data arriving from the device becomes
146: messages sent to the top-level
147: reader
148: routine, which returns the data to the user process
149: when it executes
150: .I read .
151: .so pfig1
152: .PP
153: Figure 2 shows a stream with intermediate modules.
154: This arrangement might be used when a terminal is connected to the computer
155: through a network.
156: The leftmost intermediate module carries out processing
157: (such as character-erase and line-kill) needed for terminals, while
158: the rightmost intermediate module does the
159: flow- and error-control
160: protocol needed to interface to the network.
161: .so pfig2
162: .PP
163: Finally, Figure 3
164: shows the connections for a pipe.
165: .so pfig3
166: .SH
167: .I "File Systems
168: .PP
169: Weinberger\*([.3\*(.]
170: generalized the file system
171: by identifying a small set of primitive operations on files
172: (read, write, look up name, truncate, get status, etc.: a total of 11)
173: and modifying the
174: .I mount
175: request so that it specifies a file system type and, where appropriate,
176: a stream.
177: When file operations are requested, the calls to the underlying
178: primitives are routed through a switch table indexed by the
179: type.
180: Where the standard file system type performs operations directly
181: on a disk,
182: a second type generates remote procedure calls
183: across the associated stream.
184: At the other end of the stream, which usually goes over
185: a network to another machine, is a server process
186: that answers the calls to read and write data and perform the other operations.
187: This scheme thus provides a remote file system.
188: In general structure, this arrangement is analogous
189: to that used by AT&T's RFS
190: and Sun Microsystems' NFS.
191: .PP
192: Pike's `face server'\*([.5\*(.]
193: appears to be an ordinary remote file system,
194: but his server simulates a hierarchy containing images classified by
195: machine, person name, and resolution.
196: The apparent structure of the hierarchy as viewed by
197: a client differs considerably from
198: its actual layout on the server's machine.
199: .PP
200: Killian\*([.4\*(.]
201: added a file system type that
202: appears to be a directory containing the names (process ID numbers)
203: of currently running processes.
204: Once a process file is opened, its memory may be read or written,
205: and control operations can start it or stop it.
206: This simplifies the construction of sophisticated debuggers,
207: for example Cargill's process-inspector
208: .I pi \*(<.\*([.6\*(.]\*(>.
209: .SH
210: Establishing Communication
211: .PP
212: Traditional Unix systems provide few ways for a process
213: to establish communication with another.
214: The oldest one, the pipe, has proved astonishingly valuable
215: despite its limitations, and indeed remains central in the design
216: we shall describe.
217: Its cardinal limitation is, of course, that it is anonymous,
218: and cannot be used to create a channel between unrelated processes.
219: .PP
220: More recently,
221: AT&T's System V has offered a variety of communication mechanisms including
222: semaphores, messages, and shared memory.
223: They are all useful in certain circumstances, but programs that
224: use them are all special-purpose; they know that they are communicating
225: over a certain kind of channel, and must use special calls and techniques.
226: System V also provides named pipes (FIFOs).
227: They reside in the file system, and ordinary I/O operations
228: apply to them.
229: They can provide a convenient place for processes to meet.
230: However, because the messages of all writers are intermingled,
231: writers must observe a carefully designed, application-specific protocol
232: when using them.
233: Moreover, FIFOs supply only one-way communication;
234: to receive a reply from a process reached through
235: a FIFO, a return channel must be constructed somehow.
236: .PP
237: Berkeley's 4.2 BSD system introduced
238: .I sockets
239: (communication connection points)
240: that exist in domains (naming spaces).
241: The design is powerful enough to provide most of the needed facilities,
242: but is uncomfortable in various ways.
243: For example, unless extensive libraries are used, creating a new
244: domain implies additions to the kernel.
245: Consider the problem of adding a `phone' domain, in which the addresses
246: are telephone numbers.
247: Should complicated negotiations with various kinds of
248: automatic dialers be added to the kernel?
249: If not, how can the required code be invoked in user mode
250: when a program calls
251: 4.2 BSD's
252: .I connect
253: primitive?
254: .PP
255: Another problem with the socket interface is that it exposes
256: peculiarities of the domain;
257: various domains support very different kinds of name
258: (for example, 32-bit Internet address versus character string), and it is difficult
259: to deal with the names in a general way.
260: Similarly, the details of option processing and other aspects of
261: each domain's protocols complicate an interface that attempts generality.
262: .SH
263: New System Mechanisms
264: .PP
265: Two small additions to the operating system allowed us to build
266: a variety of communication mechanisms, which will be
267: described below.
268: .SH
269: .I "Generalized Mounting
270: .PP
271: Traditionally, the
272: .I mount
273: request attaches a disk containing
274: a new piece of the file system tree at a leaf of the existing structure.
275: In the Ninth Edition, it takes the form
276: .DS
277: .ft CW
278: mount(type, fd, name, flag);
279: .ft
280: .DE
281: in which
282: .I type
283: identifies the kind of file system,
284: .I fd
285: is a file descriptor,
286: .I name
287: is a string identifying a file, and
288: .I flag
289: may specify a few options.
290: Like its original version, this call attaches a new file system structure
291: atop the file
292: .I name
293: in the existing file hierarchy.
294: The operating system gains access to the contents of newly-attached file tree
295: by communicating over the descriptor
296: .I fd,
297: according to a protocol appropriate for the new file system
298: .I type.
299: For example, ordinary disk volumes have type
300: .I ordinary,
301: and the file descriptor is the special file for
302: the disk, while
303: remote file systems use type
304: .I remote,
305: and the descriptor
306: refers to a stream connection to a server that understands
307: the appropriate RPC messages.
308: Some types are handled entirely internally;
309: for example, the `proc' type ignores the file descriptor.
310: .PP
311: We added a new, very simple, file system type.
312: Its
313: .I mount
314: request merely attaches the file descriptor (which must be a stream) to
315: the file.
316: Subsequently, when processes open and do I/O on that file,
317: their requests refer to the stream mounted on the file.
318: Often, the stream is one end of a pipe created by a server
319: process, but it can equally well be a connection to a device,
320: or a network connection to a process on another machine.
321: The effect is similar to a System V FIFO that has already been opened
322: by a server, but more general: communication is full-duplex,
323: the server can be on another machine, and (because the connection is a stream),
324: intermediate processing modules may be installed.
325: .SH
326: .I "Passing Files
327: .PP
328: By itself, a mounted stream shares an important difficulty
329: of the FIFO;
330: several processes attempting to use it simultaneously must
331: somehow cooperate.
332: Another addition facilitates this cooperation:
333: an open file may be passed
334: from one process to another across a pipe connection.
335: The primitives may be written
336: .DS
337: .ft CW
338: sendfile(wpipefd, fd);
339: .ft
340: .DE
341: in the sender process, and
342: .DS
343: .ft CW
344: (fd1, info) = recvfile(rpipefd);
345: .ft
346: .DE
347: in the receiver.
348: By using
349: .I sendfile,
350: the sender transmits a copy of its file descriptor
351: .I fd
352: over the pipe to the receiver;
353: when the receiver accepts it by
354: .I recvfile,
355: it gains a new open file denoted by
356: .I fd1.
357: (Other information, such as the user- and group-id of the sender,
358: is also passed.)
359: The facility may be used only locally, over a pipe;
360: we do not attempt to extend it to remote systems.
361: .PP
362: A similar facility is available in the 4.3 BSD system\*(<,\*([.7\*(.]\*(>,
363: but is little-used, possibly because in earlier versions
364: the related socket facilities were buggy.
365: It will appear in future versions of Unix System V.
366: .SH
367: Simple Examples
368: .PP
369: A graded set of examples will illustrate how these mechanisms
370: can solve problems that vex other systems.
371: .SH
372: .I "Talking to Users
373: .PP
374: When a user logs in to traditional Unix systems, an entry is made in the
375: .I /etc/utmp
376: file, recording the login name and the terminal or network channel
377: being used.
378: Although this file is often used merely to show who is where,
379: it is also used to establish communication with the user.
380: For example, the
381: .I write
382: command and the mail-notification service look up
383: a user's name, and send a message
384: to the corresponding terminal.
385: This simple scheme does not work well with windowing terminals,
386: because the messages disturb the protocol between
387: the host and the terminal, and because there is no obvious way
388: to relate the terminal's special file to a particular window.
389: Even without windows, there are security problems and other difficulties
390: that follow from letting users write on each other's terminals.
391: .PP
392: We use stream-mounting to interpose a program
393: between a terminal special file and the terminal itself.
394: The program, called
395: .I vismon ,
396: mounts one end of a pipe on the user's terminal.
397: Normally it occupies an inconspicuous window, displaying system
398: activity and announcing arriving mail.
399: When some other process opens and writes on the special file
400: for the terminal, the mounted stream receives the data;
401: .I vismon
402: creates a new window, and copies this data to it.
403: The new window has a shell, so that if the message was
404: from a
405: .I write
406: command, the recipient can write back.
407: .PP
408: Communication between the terminal and the windowing
409: multiplexor on the host is not disturbed;
410: it continues to flow to the terminal itself, not to
411: .I vismon,
412: because the
413: .I mount
414: operation affects only the interpretation of file names,
415: not existing file descriptors.
416: .SH
417: .I "Network Calling: Simple Form
418: .PP
419: Making a network connection is a complicated activity.
420: There is often name translation of various kinds,
421: and sometimes negotiations with various entities.
422: With the Datakit\(rg VCS network\*(<,\*([.8\*(.]\*(>,
423: for example, a call is placed
424: by negotiating with a node controller.
425: When dialing over the switched telephone system, one must talk
426: to any of several kinds of automatic dialers.
427: Setting up a connection on an Internet
428: under any of the extant protocols requires translation of
429: a symbolic name to a net address, and then special communication
430: with the remote host.
431: These setup protocols should certainly not be in kernel code, so
432: most systems package them in user-callable libraries.
433: .PP
434: With our primitives, it is straightforward to encapsulate a
435: network-connection algorithm to a single executable program.
436: A application desiring to make an outward connection calls a simple routine
437: that creates a pipe, forks, and in the child process executes the
438: network dialer program.
439: The dialer passes back either an error code, or a file descriptor
440: referring to an open connection to the other machine.
441: The pseudo-code for this library routine,
442: neglecting error-checking and closing down the pipe, is:
443: .DS
444: .ft CW
445: netcall(address)
446: { int p[2];
447: .sp .25
448: pipe(p);
449: if (fork()!=0)
450: execute("/etc/netcaller", address, p[0]);
451: status = wait();
452: if (bad(status))
453: return(errcode);
454: passedinfo = recvfile(p[1]);
455: return(passedinfo.fd);
456: }
457: .ft
458: .DE
459: The
460: .ft CW
461: /etc/netcaller
462: .ft
463: program can be arbitrarily complicated, but does not occupy the
464: same address space as its caller.
465: In this way, if something in the network interface changes,
466: only one program needs to be fixed and reinstalled.
467: Its job is to create the connection, and pass its descriptor
468: for the open connection; it then terminates, and is no
469: longer involved in the connection.
470: Along the way, it may negotiate permissions and provide the caller's
471: identity reliably, because it can be a privileged (set-uid) program.
472: Thus, the segregation of the program that does the actual call setup
473: from its client is important.
474: When connections are made by library routines,
475: the operating system must know enough about
476: the call setup protocols to authenticate the caller to the target system.
477: In the method described above, this task need not be done in kernel code.
478: Even shared libraries, which do reduce the bulk of
479: code included with each program that makes network connections,
480: run in the protection domain of the person who
481: executes them.
482: .SH
483: .I "Process Connections
484: .PP
485: Suppose you are writing a multi-player game,
486: in which several people interact with each other.
487: One design uses a pair of programs:
488: a controller process that runs throughout the game and
489: coordinates
490: the play, and a player program, with one instance for each player,
491: that communicates with the controller.
492: .PP
493: When the controller starts,
494: it creates a conventionally-located file, stream-mounts
495: one end of a pipe on this file,
496: and waits for connection messages to arrive from players.
497: When the player program is run, it opens
498: the communication file, and creates its own pipe.
499: It starts communication by sending one end of this pipe to the
500: game controller over the communication file.
501: .PP
502: As each passed pipe appears on the controller's connection stream,
503: it accepts the connection with
504: .I recvfile.
505: Thereafter, each player transmits moves and receives replies
506: over its end of the pipe;
507: the controller reads players' moves and transmits replies
508: over the end it received.
509: It maintains the global state of the game, and uses the
510: .I select (2)
511: mechanism
512: to multiplex connection requests and the communication with the
513: player programs.
514: .SH
515: The Connection Server
516: .PP
517: The final example illustrates a general
518: connection server.
519: It combines ideas used by the initial network-calling
520: scheme and the game design, described above,
521: to create a flexible switchboard
522: through which programs can connect to remote or local services.
523: .PP
524: Two things are necessary for handling server-client relationships:
525: first, some program must establish itself as a server,
526: and wait for requests for the service;
527: and second, programs must make requests.
528: We will first describe the external appearance of the scheme (the
529: library entry points), then the addressing and naming, and then the implementation.
530: .PP
531: A program that desires to make a connection calls the routine
532: .I ipcopen,
533: passing a string
534: of characters that specifies the address and the desired service at
535: that address.
536: .DS
537: .ft CW
538: fd = ipcopen(service);
539: .ft
540: .DE
541: The
542: .I ipcopen
543: routine returns a file descriptor connected to the requested server.
544: If it fails, a string describing the error is available.
545: .PP
546: In order to announce a service,
547: .I ipccreat
548: is used;
549: its argument is a string that names the service.
550: The return value is a file descriptor
551: .I fd
552: that is a channel on which connection requests will be sent.
553: .DS
554: .ft CW
555: fd = ipccreat(service);
556: .ft
557: .DE
558: To wait for requests, the server uses the
559: .I ipclisten
560: routine. Its argument is the same
561: .I fd
562: returned by
563: .I ipccreat:
564: .DS
565: .ft CW
566: ip = ipclisten(fd);
567: .ft
568: .DE
569: .I Ipclisten
570: returns when some program calls
571: .I ipcopen
572: with an argument corresponding to the service, in a way discussed below.
573: The return value
574: is a structure containing
575: information about the caller, such as the user name, and,
576: where relevant, the name of the machine from which the call was placed.
577: This new connection may be rejected:
578: .DS
579: .ft CW
580: ipcreject(ip, errcode);
581: .ft
582: .DE
583: or it may be accepted:
584: .DS
585: .ft CW
586: fd = ipcaccept(ip, cfd);
587: .ft
588: .DE
589: If the server itself is capable of handling all communication with
590: its client, it passes a null file descriptor as
591: .I cfd,
592: and uses the return value of
593: .I ipcaccept
594: as a file descriptor to communicate with its client.
595: Depending on the locations of the server and the client,
596: this may be either a pipe, or a stream connection to a remote machine.
597: .PP
598: Sometimes, the purpose of a server is not to communicate directly,
599: but to set up another connection on behalf of its client.
600: A network dialing server, for example, receives the desired address
601: in the
602: .I ip
603: structure returned by
604: .I ipclisten,
605: and connects to this address with network-specific primitives.
606: If the connection succeeds, the server sends the descriptor
607: for the connection to the client using the
608: .I cfd
609: argument of
610: .I ipcaccept.
611: .PP
612: The various file descriptors in these calls all work properly
613: with the
614: .I select
615: system call, so a single program may issue several
616: .I ipccreat
617: calls, and wait a connection to appear before committing
618: itself to using
619: .I ipclisten
620: on any one of them.
621: .SH
622: .I Addresses
623: .PP
624: The arguments supplied to
625: .I ipcopen
626: and
627: .I ipccreat
628: are strings with several components
629: separated by exclamation mark `!' characters.
630: The first part is interpreted as a file name.
631: If it is absolute, it is used as is; otherwise, it is interpreted as
632: a file in the directory
633: .I /cs,
634: which we use, conventionally, to collect rendezvous points.
635: For example, a game controller like that discussed
636: in a previous section might announce itself with
637: .DS
638: .ft CW
639: ipccreat("mazewar");
640: .ft
641: .DE
642: The player program could then connect to the controller with
643: .DS
644: .ft CW
645: ipcopen("mazewar");
646: .ft
647: .DE
648: In this simple case, the IPC routines merely accomplish a convenient
649: packaging of the scheme discussed above.
650: .PP
651: When a multi-component argument is given to
652: .I ipcopen,
653: the server selected by the first component receives the remaining
654: components
655: as part of the
656: .I ip
657: structure returned by its
658: .I ipclisten,
659: and interprets them according to its own conventions.
660: For example, there is a dialing server for each kind of network.
661: If the first component of an
662: .I ipcopen
663: specifies a network server,
664: the remaining components conventionally supply an address
665: within that network, and possibly a service obtainable at that address.
666: We have three kinds of networks:
667: .I tcp
668: (TCP/IP connection),
669: .I dk
670: (Datakit connection), and
671: .I phone
672: (dial-up telephone).
673: Each network server adopts the convention that a missing service name
674: means a connection to an end-point that allows one to log in by hand.
675: Therefore, calling
676: .I ipcopen
677: with the strings
678: .DS
679: .ft CW
680: tcp!research.att.com
681: dk!nj/astro/research
682: phone!201-582-5940
683: .ft
684: .DE
685: gets connections over which one will receive a `login:' greeting,
686: each over a different kind of network.
687: The servers are responsible for the details of name translation,
688: performing the appropriate connection protocol, and so forth.
689: Some examples of named services at particular locations are
690: .DS
691: .ft CW
692: tcp!dutoit.att.com!whoami
693: dk!research!smtp
694: .ft
695: .DE
696: The first is a debugging service that echoes facts about the
697: connection and the user ID of the person who requests it.
698: The second illustrates how remote mail is sent:
699: by connecting to the
700: .I smtp
701: server (mail receiver) on the appropriate machine.
702: .SH
703: .I "IPC Implementation
704: .PP
705: For a simple service, the
706: .I ipccreat
707: routine works just like the
708: game-manager program described above; it first creates a file in the
709: .I /cs
710: directory corresponding to the name of the service, then makes
711: a pipe and stream-mounts one end of the pipe on this file.
712: For complex services, which have a `!' in their names, the
713: simple service named to the left of the `!' must be created first;
714: when
715: .I ipccreat
716: is handed the name of such a service, it uses
717: a version of
718: .I ipcopen
719: referring to the simple, underlying server, and passes it the remainder
720: of the name.
721: In either case,
722: .I ipccreat
723: returns its own end of its pipe, ready to receive requests.
724: .PP
725: The
726: .I ipcopen
727: routine uses a technique that resembles that used by the
728: simple network calling routine described above, but differs
729: in detail.
730: It opens the file in
731: .I /cs
732: corresponding to the desired service, makes a pipe, and hands
733: one end of the pipe to the server. It then sends the actual contents
734: of the request (the full address) to its end of the pipe,
735: and waits for an acceptance or rejection message to appear on
736: this pipe.
737: .PP
738: The server
739: .I ipclisten
740: call waits for a stream (passed by someone's
741: .I ipcopen )
742: to appear on the file descriptor mounted on its
743: .I /cs
744: communication file; as each appears,
745: it reads the request block from the passed stream,
746: and returns it to the server.
747: .PP
748: After analyzing the request, the server calls either
749: .I ipcaccept
750: or
751: .I ipcreject;
752: each sends an appropriate message back to the client over the passed
753: stream.
754: .I Ipcaccept
755: has two cases:
756: when its
757: .I cfd
758: argument is empty, the same pipe sent to
759: the server by the client is used for communication; when
760: .I cfd
761: is non-empty,
762: that file descriptor is sent back to the client.
763: .I Ipcopen
764: returns the appropriate descriptor.
765: .PP
766: .SH
767: .I "Network Managers"
768: .PP
769: The IPC routines discussed above handle both clients and servers
770: that are local to a single system, and are also sufficient to accomplish
771: outgoing network connections.
772: One missing piece is how to write the programs
773: that accept connections from a network, and arrange to invoke
774: the appropriate local services.
775: We call such programs
776: .I managers.
777: .PP
778: The networking part of a manager is specific to its
779: network, and usually must conduct dialogues both with the
780: operating system and with its remote client.
781: For example, the manager for TCP/IP must arrange
782: to receive IP packets sent to certain port numbers,
783: and analyze the packets to determine what service is being
784: requested;
785: then it must select a port number for
786: the conversation, communicate it to the peer, and arrange to collect
787: packets on this port number.
788: Finally, the manager must supply the selected local service.
789: Each network manager could have
790: .I "ad hoc"
791: code for this part of the job;
792: instead, they depend on a more general program called the
793: .I "service manager.
794: .SH
795: .I "The Service Manager
796: .PP
797: By using
798: .I ipccreat,
799: a process establishes itself as a server and prepares to receive requests.
800: While it is serving, it must remain in existence.
801: For some servers, like the multi-player game controller that
802: continues to run as users enter and leave the game,
803: the longevity of the server is appropriate.
804: However, many, or even most, useful services do not necessarily
805: need individual long-lived servers, because the service merely involves
806: execution of a particular program.
807: For example, services like
808: .I rlogin,
809: .I telnet,
810: .I smtp
811: and
812: .I ftp,
813: as well as simpler ones that merely provide the
814: date, or send a file to a line printer, can all
815: be accomplished merely by running the appropriate program
816: with input and output connected to the right place.
817: Even when the characteristics of such services differ
818: in detail, there are general patterns.
819: Some, for example, require no authentication, some require checking
820: of authentication according to an automatic scheme, and others
821: always insist on a password.
822: .PP
823: The observation that many services share a common structure
824: suggested a common solution: the Service Manager.
825: It is started when the operating system is booted, and is
826: driven by a specification file;
827: each entry in the file
828: contains the name of the service, and a list of actions
829: to be performed when that service is requested.
830: The service manager issues
831: .I ipccreat
832: for the name given in each entry; when another process uses
833: .I ipcopen
834: to request the service, the service manager carries out each
835: encoded action.
836: .PP
837: The most important action specifies a command to be executed;
838: for example, the line
839: .DS
840: .ft CW
841: date cmd(date)
842: .ft
843: .DE
844: means that connecting to the service
845: .I date
846: would run the `date' command.
847: Other actions may specify the user ID under which the program
848: is run:
849: .DS
850: .ft CW
851: uucp user(uucp)+cmd(/usr/lib/uucp/uucico)
852: .ft
853: .DE
854: This service specifies a passwordless connection to the
855: .I uucp
856: file-transfer program;
857: a locally-conventional TCP/IP port
858: number is used for such connections, and a corresponding convention
859: is used on our Datakit network.
860: There are other built-in actions:
861: .DS
862: .ft CW
863: login ttyld+password
864: .ft
865: .DE
866: means that the
867: .I login
868: service needs to install the line discipline module for terminal
869: processing, and also to execute the
870: .I login
871: command;
872: .DS
873: .ft CW
874: oklogin auth+ttyld+login
875: .ft
876: .DE
877: is similar, but allows passwordless login.
878: Authorization is checked by the
879: .I auth
880: specification, which determines whether the call came from a
881: trusted host on a trusted network, so that the passed user ID
882: can be believed.
883: .SH
884: Uses
885: .PP
886: The techniques described in this paper permit a general approach
887: to network and local connections in which most of the work
888: is done in a few user-mode programs.
889: As an example of the benefits of the scheme, we have unified
890: various commands that do remote login over two kinds of networks
891: (TCP/IP and Datakit).
892: A single command,
893: .I con,
894: tries various networks and uses the first over which a connection
895: can be made.
896: The traditional names (like
897: .I rlogin )
898: are retained as links, but the only effect of using them is to
899: influence the order in which networks are tried.
900: The stream implementation makes the transport layers of the networks
901: sufficiently similar
902: that the same code can be used once the connection is established;
903: the techniques described here make even the connection interface uniform.
904: .PP
905: These same techniques extend well to inter-network connectivity.
906: For example, all our machines have a
907: Datakit interface, but only a few have Ethernet connections.
908: Nevertheless, from a Datakit-only machine,
909: it is easy to connect to another machine that
910: has only Ethernet, even one that does not run the
911: Ninth Edition system.
912: There are two schemes.
913: In the first,
914: the local operating system contains the TCP/IP protocol
915: code, and below the TCP/IP level, the `device' interface is
916: actually a Datakit connection to another local machine on both networks.
917: Because Datakit channels and the network layer expected by
918: TCP/IP have stream interfaces, they are easily connected;
919: on the gateway machine,
920: the IP packets are routed appropriately.
921: This approach transparently handles other services, like UDP,
922: that use the IP protocol.
923: .PP
924: The other scheme uses the methods described in this paper.
925: On the Datakit-only machine,
926: the TCP network dialout program does not
927: use TCP/IP at all, and indeed TCP/IP code need not be configured into
928: the operating system;
929: instead, it creates a Datakit transport-level connection
930: to a protocol-conversion server on a gateway machine.
931: A complementary server on the gateway accepts TCP/IP
932: connections on behalf of the Datakit-only machine, and forwards them.
933: The difference between the two schemes is invisible to
934: users of connection-oriented protocols, although it does not support
935: connectionless protocols like UDP.
936: .SH
937: Conclusion
938: .PP
939: Unix has always had a rich file system structure,
940: both in its naming scheme (hierarchical directories)
941: and in the properties of open files (disk files, devices, pipes).
942: The Eighth Edition exploited the file system even more insistently
943: than its predecessors
944: or contemporaries of the same genus.
945: Remote file systems, process files, and the face server
946: all create objects with names that can
947: be handed as usefully to an existing tool
948: as to a new one designed to take advantage of the object's special
949: properties.
950: Similarly, the stream I/O system
951: provides a framework for making file descriptors
952: act in the standard way most programs already expect,
953: while providing a richer underlying behavior,
954: for handling network protocols, or processing appropriate
955: for terminals.
956: .PP
957: The developments described here follow the same path;
958: they encourage use of the file name space
959: to establish communication between processes.
960: In the best of cases,
961: merely opening a named file is enough.
962: More complicated situations require more involved negotiations,
963: but the file system still supplies the point of contact.
964: Moreover, the necessary negotiations
965: may be encapsulated in a common form that hides the differences between
966: local and any of a variety of remote connections.
967: .SH
968: References
969: .PP
970: .]<
971: .ds [F 1
972: .]-
973: .ds [A D. M. Ritchie
974: .ds [K bltj
975: .ds [T A Stream Input-Output System
976: .ds [J AT&T Bell Laboratories Technical Journal
977: .ds [D October 1984
978: .ds [V 63
979: .ds [N 8
980: .nr [T 0
981: .nr [A 0
982: .nr [O 0
983: .][ 1 journal-article
984: .ds [F 2
985: .]-
986: .ds [A AT&T
987: .ds [T UNIX System V Release 3 STREAMS Programmer's Guide
988: .ds [K systemv streams
989: .ds [D 1986
990: .ds [V 307-227
991: .nr [T 0
992: .nr [A 0
993: .nr [O 0
994: .][ 0 other
995: .ds [F 3
996: .]-
997: .ds [A P. J. Weinberger
998: .ds [K remote
999: .ds [T The Version 8 Network File System
1000: .ds [J USENIX Summer Conference Proceedings
1001: .ds [D June 1984
1002: .ds [C Salt Lake City, UT
1003: .nr [T 0
1004: .nr [A 0
1005: .nr [O 0
1006: .][ 1 journal-article
1007: .ds [F 4
1008: .]-
1009: .ds [A T. J. Killian
1010: .ds [T Processes as Files
1011: .ds [J USENIX Summer Conference Proceedings
1012: .ds [D June 1984
1013: .ds [C Salt Lake City, UT
1014: .nr [T 0
1015: .nr [A 0
1016: .nr [O 0
1017: .][ 1 journal-article
1018: .ds [F 5
1019: .]-
1020: .ds [A R. Pike
1021: .as [A " and D. L. Presotto
1022: .ds [T Face the Nation
1023: .ds [J USENIX Summer Conference Proceedings
1024: .ds [D June 1985
1025: .ds [C Portland, OR
1026: .nr [T 0
1027: .nr [A 0
1028: .nr [O 0
1029: .][ 1 journal-article
1030: .ds [F 6
1031: .]-
1032: .ds [A T. A. Cargill
1033: .ds [T The Blit Debugger
1034: .ds [J Journal of Systems and Software
1035: .ds [V 3
1036: .ds [N 4
1037: .ds [D December 1983
1038: .ds [P 277-284
1039: .nr [P 1
1040: .ds [K pi
1041: .nr [T 0
1042: .nr [A 0
1043: .nr [O 0
1044: .][ 1 journal-article
1045: .ds [F 7
1046: .]-
1047: .ds [A Computer Systems Research Group, U.C. Berkeley
1048: .ds [T Unix Programmer's Reference Manual: 4.3 Berkeley Software Distribution
1049: .ds [K fourthree bsd
1050: .ds [D April, 1986
1051: .ds [C Berkeley, California
1052: .nr [T 0
1053: .nr [A 0
1054: .nr [O 0
1055: .][ 0 other
1056: .ds [F 8
1057: .]-
1058: .ds [A A. G. Fraser
1059: .ds [T Datakit\-A Modular Network for Synchronous and Asynchronous Traffic
1060: .ds [J Proc. Int. Conf. on Commun.
1061: .ds [D June 1980
1062: .ds [C Boston, MA
1063: .nr [T 0
1064: .nr [A 0
1065: .nr [O 0
1066: .][ 1 journal-article
1067: .nr [W \w'1'
1068: .]>
1069: .nr [W \w'1'
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.