![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to tutor.me CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 07.ipctut|
Return to tutor.me CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 07.ipctut |
1.1 ! root 1: .\" Copyright (c) 1986 The Regents of the University of California. ! 2: .\" All rights reserved. ! 3: .\" ! 4: .\" Redistribution and use in source and binary forms are permitted ! 5: .\" provided that the above copyright notice and this paragraph are ! 6: .\" duplicated in all such forms and that any documentation, ! 7: .\" advertising materials, and other materials related to such ! 8: .\" distribution and use acknowledge that the software was developed ! 9: .\" by the University of California, Berkeley. The name of the ! 10: .\" University may not be used to endorse or promote products derived ! 11: .\" from this software without specific prior written permission. ! 12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR ! 13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED ! 14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ! 15: .\" ! 16: .\" @(#)tutor.me 6.6 (Berkeley) 3/7/89 ! 17: .\" ! 18: .oh 'Introductory 4.3BSD IPC''PS1:7-%' ! 19: .eh 'PS1:7-%''Introductory 4.3BSD IPC' ! 20: .rs ! 21: .sp 2 ! 22: .sz 14 ! 23: .ft B ! 24: .ce 2 ! 25: An Introductory 4.3BSD ! 26: Interprocess Communication Tutorial ! 27: .sz 10 ! 28: .sp 2 ! 29: .ce ! 30: .i "Stuart Sechrest" ! 31: .ft ! 32: .sp ! 33: .ce 4 ! 34: Computer Science Research Group ! 35: Computer Science Division ! 36: Department of Electrical Engineering and Computer Science ! 37: University of California, Berkeley ! 38: .sp 2 ! 39: .ce ! 40: .i ABSTRACT ! 41: .sp ! 42: .(c ! 43: .pp ! 44: Berkeley UNIX\(dg 4.3BSD offers several choices for interprocess communication. ! 45: To aid the programmer in developing programs which are comprised of ! 46: cooperating ! 47: processes, the different choices are discussed and a series of example ! 48: programs are presented. These programs ! 49: demonstrate in a simple way the use of pipes, socketpairs, sockets ! 50: and the use of datagram and stream communication. The intent of this ! 51: document is to present a few simple example programs, not to describe the ! 52: networking system in full. ! 53: .)c ! 54: .sp 2 ! 55: .(f ! 56: \(dg\|UNIX is a trademark of AT&T Bell Laboratories. ! 57: .)f ! 58: .b ! 59: .sh 1 "Goals" ! 60: .r ! 61: .pp ! 62: Facilities for interprocess communication (IPC) and networking ! 63: were a major addition to UNIX in the Berkeley UNIX 4.2BSD release. ! 64: These facilities required major additions and some changes ! 65: to the system interface. ! 66: The basic idea of this interface is to make IPC similar to file I/O. ! 67: In UNIX a process has a set of I/O descriptors, from which one reads ! 68: and to which one writes. ! 69: Descriptors may refer to normal files, to devices (including terminals), ! 70: or to communication channels. ! 71: The use of a descriptor has three phases: its creation, ! 72: its use for reading and writing, and its destruction. By using descriptors ! 73: to write files, rather than simply naming the target file in the write ! 74: call, one gains a surprising amount of flexibility. Often, the program that ! 75: creates a descriptor will be different from the program that uses the ! 76: descriptor. For example the shell can create a descriptor for the output ! 77: of the `ls' ! 78: command that will cause the listing to appear in a file rather than ! 79: on a terminal. ! 80: Pipes are another form of descriptor that have been used in UNIX ! 81: for some time. ! 82: Pipes allow one-way data transmission from one process ! 83: to another; the two processes and the pipe must be set up by a common ! 84: ancestor. ! 85: .pp ! 86: The use of descriptors is not the only communication interface ! 87: provided by UNIX. ! 88: The signal mechanism sends a tiny amount of information from one ! 89: process to another. ! 90: The signaled process receives only the signal type, ! 91: not the identity of the sender, ! 92: and the number of possible signals is small. ! 93: The signal semantics limit the flexibility of the signaling mechanism ! 94: as a means of interprocess communication. ! 95: .pp ! 96: The identification of IPC with I/O is quite longstanding in UNIX and ! 97: has proved quite successful. At first, however, IPC was limited to ! 98: processes communicating within a single machine. With Berkeley UNIX ! 99: 4.2BSD this expanded to include IPC between machines. This expansion ! 100: has necessitated some change in the way that descriptors are created. ! 101: Additionally, new possibilities for the meaning of read and write have ! 102: been admitted. Originally the meanings, or semantics, of these terms ! 103: were fairly simple. When you wrote something it was delivered. When ! 104: you read something, you were blocked until the data arrived. ! 105: Other possibilities exist, ! 106: however. One can write without full assurance of delivery if one can ! 107: check later to catch occasional failures. Messages can be kept as ! 108: discrete units or merged into a stream. ! 109: One can ask to read, but insist on not waiting if nothing is immediately ! 110: available. These new possibilities are allowed in the Berkeley UNIX IPC ! 111: interface. ! 112: .pp ! 113: Thus Berkeley UNIX 4.3BSD offers several choices for IPC. ! 114: This paper presents simple examples that illustrate some of ! 115: the choices. ! 116: The reader is presumed to be familiar with the C programming language ! 117: [Kernighan & Ritchie 1978], ! 118: but not necessarily with the system calls of the UNIX system or with ! 119: processes and interprocess communication. ! 120: The paper reviews the notion of a process and the types of ! 121: communication that are supported by Berkeley UNIX 4.3BSD. ! 122: A series of examples are presented that create processes that communicate ! 123: with one another. The programs show different ways of establishing ! 124: channels of communication. ! 125: Finally, the calls that actually transfer data are reviewed. ! 126: To clearly present how communication can take place, ! 127: the example programs have been cleared of anything that ! 128: might be construed as useful work. ! 129: They can, therefore, serve as models ! 130: for the programmer trying to construct programs which are comprised of ! 131: cooperating processes. ! 132: .b ! 133: .sh 1 "Processes" ! 134: .pp ! 135: A \fIprogram\fP is both a sequence of statements and a rough way of referring ! 136: to the computation that occurs when the compiled statements are run. ! 137: A \fIprocess\fP can be thought of as a single line of control in a program. ! 138: Most programs execute some statements, go through a few loops, branch in ! 139: various directions and then end. These are single process programs. ! 140: Programs can also have a point where control splits into two independent lines, ! 141: an action called \fIforking.\fP ! 142: In UNIX these lines can never join again. A call to the system routine ! 143: \fIfork()\fP, causes a process to split in this way. ! 144: The result of this call is that two independent processes will be ! 145: running, executing exactly the same code. ! 146: Memory values will be the same for all values set before the fork, but, ! 147: subsequently, each version will be able to change only the ! 148: value of its own copy of each variable. ! 149: Initially, the only difference between the two will be the value returned by ! 150: \fIfork().\fP The parent will receive a process id for the child, ! 151: the child will receive a zero. ! 152: Calls to \fIfork(),\fP ! 153: therefore, typically precede, or are included in, an if-statement. ! 154: .pp ! 155: A process views the rest of the system through a private table of descriptors. ! 156: The descriptors can represent open files or sockets (sockets are communication ! 157: objects that will be discussed below). Descriptors are referred to ! 158: by their index numbers in the table. The first three descriptors are often ! 159: known by special names, \fI stdin, stdout\fP and \fIstderr\fP. ! 160: These are the standard input, output and error. ! 161: When a process forks, its descriptor table is copied to the child. ! 162: Thus, if the parent's standard input is being taken from a terminal ! 163: (devices are also treated as files in UNIX), the child's input will ! 164: be taken from the ! 165: same terminal. Whoever reads first will get the input. If, before forking, ! 166: the parent changes its standard input so that it is reading from a ! 167: new file, the child will take its input from the new file. It is ! 168: also possible to take input from a socket, rather than from a file. ! 169: .b ! 170: .sh 1 "Pipes" ! 171: .r ! 172: .pp ! 173: Most users of UNIX know that they can pipe the output of a ! 174: program ``prog1'' to the input of another, ``prog2,'' by typing the command ! 175: \fI``prog1 | prog2.''\fP ! 176: This is called ``piping'' the output of one program ! 177: to another because the mechanism used to transfer the output is called a ! 178: pipe. ! 179: When the user types a command, the command is read by the shell, which ! 180: decides how to execute it. If the command is simple, for example, ! 181: .i "``prog1,''" ! 182: the shell forks a process, which executes the program, prog1, and then dies. ! 183: The shell waits for this termination and then prompts for the next ! 184: command. ! 185: If the command is a compound command, ! 186: .i "``prog1 | prog2,''" ! 187: the shell creates two processes connected by a pipe. One process ! 188: runs the program, prog1, the other runs prog2. The pipe is an I/O ! 189: mechanism with two ends, or sockets. Data that is written into one socket ! 190: can be read from the other. ! 191: .(z ! 192: .ft CW ! 193: .so pipe.c ! 194: .ft ! 195: .ce 1 ! 196: Figure 1\ \ Use of a pipe ! 197: .)z ! 198: .pp ! 199: Since a program specifies its input and output only by the descriptor table ! 200: indices, which appear as variables or constants, ! 201: the input source and output destination can be changed without ! 202: changing the text of the program. ! 203: It is in this way that the shell is able to set up pipes. Before executing ! 204: prog1, the process can close whatever is at \fIstdout\fP ! 205: and replace it with one ! 206: end of a pipe. Similarly, the process that will execute prog2 can substitute ! 207: the opposite end of the pipe for ! 208: \fIstdin.\fP ! 209: .pp ! 210: Let us now examine a program that creates a pipe for communication between ! 211: its child and itself (Figure 1). ! 212: A pipe is created by a parent process, which then forks. ! 213: When a process forks, the parent's descriptor table is copied into ! 214: the child's. ! 215: .pp ! 216: In Figure 1, the parent process makes a call to the system routine ! 217: \fIpipe().\fP ! 218: This routine creates a pipe and places descriptors for the sockets ! 219: for the two ends of the pipe in the process's descriptor table. ! 220: \fIPipe()\fP ! 221: is passed an array into which it places the index numbers of the ! 222: sockets it created. ! 223: The two ends are not equivalent. The socket whose index is ! 224: returned in the low word of the array is opened for reading only, ! 225: while the socket in the high end is opened only for writing. ! 226: This corresponds to the fact that the standard input is the first ! 227: descriptor of a process's descriptor table and the standard output ! 228: is the second. After creating the pipe, the parent creates the child ! 229: with which it will share the pipe by calling \fIfork().\fP ! 230: Figure 2 illustrates the effect of a fork. ! 231: The parent process's descriptor table points to both ends of the pipe. ! 232: After the fork, both parent's and child's descriptor tables point to ! 233: the pipe. ! 234: The child can then use the pipe to send a message to the parent. ! 235: .(z ! 236: - ! 237: .bl 5.8i ! 238: - ! 239: .\" pipe.grn goes here ! 240: .sp ! 241: .ce 1 ! 242: Figure 2\ \ Sharing a pipe between parent and child ! 243: .)z ! 244: .pp ! 245: Just what is a pipe? ! 246: It is a one-way communication mechanism, with one end opened ! 247: for reading and the other end for writing. ! 248: Therefore, parent and child need to agree on which way to turn ! 249: the pipe, from parent to child or the other way around. ! 250: Using the same pipe for communication both from parent to child and ! 251: from child to parent would be possible (since both processes have ! 252: references to both ends), but very complicated. ! 253: If the parent and child are to have a two-way conversation, ! 254: the parent creates two pipes, one for use in each direction. ! 255: (In accordance with their plans, both parent and child in the example above ! 256: close the socket that they will not use. It is not required that unused ! 257: descriptors be closed, but it is good practice.) ! 258: A pipe is also a \fIstream\fP communication mechanism; that ! 259: is, all messages sent through the pipe are placed in order ! 260: and reliably delivered. When the reader asks for a certain ! 261: number of bytes from this ! 262: stream, he is given as many bytes as are available, up ! 263: to the amount of the request. Note that these bytes may have come from ! 264: the same call to \fIwrite()\fR or from several calls to \fIwrite()\fR ! 265: which were concatenated. ! 266: .b ! 267: .sh 1 "Socketpairs" ! 268: .r ! 269: .pp ! 270: Berkeley UNIX 4.3BSD provides a slight generalization of pipes. A pipe is a ! 271: pair of connected sockets for one-way stream communication. One may ! 272: obtain a pair of connected sockets for two-way stream communication ! 273: by calling the routine \fIsocketpair().\fP ! 274: The program in Figure 3 calls \fIsocketpair()\fP ! 275: to create such a connection. The program uses the link for ! 276: communication in both directions. Since socketpairs are ! 277: an extension of pipes, their use resembles that of pipes. ! 278: Figure 4 illustrates the result of a fork following a call to ! 279: \fIsocketpair().\fP ! 280: .pp ! 281: \fISocketpair()\fP ! 282: takes as ! 283: arguments a specification of a domain, a style of communication, and a ! 284: protocol. ! 285: These are the parameters shown in the example. ! 286: Domains and protocols will be discussed in the next section. ! 287: Briefly, ! 288: a domain is a space of names that may be bound ! 289: to sockets and implies certain other conventions. ! 290: Currently, socketpairs have only been implemented for one ! 291: domain, called the UNIX domain. ! 292: The UNIX domain uses UNIX path names for naming sockets. ! 293: It only allows communication ! 294: between sockets on the same machine. ! 295: .pp ! 296: Note that the header files ! 297: .i "<sys/socket.h>" ! 298: and ! 299: .i "<sys/types.h>." ! 300: are required in this program. ! 301: The constants AF_UNIX and SOCK_STREAM are defined in ! 302: .i "<sys/socket.h>," ! 303: which in turn requires the file ! 304: .i "<sys/types.h>" ! 305: for some of its definitions. ! 306: .(z ! 307: .ft CW ! 308: .so socketpair.c ! 309: .ft ! 310: .ce 1 ! 311: Figure 3\ \ Use of a socketpair ! 312: .)z ! 313: .(z ! 314: - ! 315: .bl 5.8i ! 316: - ! 317: .\" socketpair.grn goes here ! 318: .sp ! 319: .ce 1 ! 320: Figure 4\ \ Sharing a socketpair between parent and child ! 321: .)z ! 322: .b ! 323: .sh 1 "Domains and Protocols" ! 324: .r ! 325: .pp ! 326: Pipes and socketpairs are a simple solution for communicating between ! 327: a parent and child or between child processes. ! 328: What if we wanted to have processes that have no common ancestor ! 329: with whom to set up communication? ! 330: Neither standard UNIX pipes nor socketpairs are ! 331: the answer here, since both mechanisms require a common ancestor to ! 332: set up the communication. ! 333: We would like to have two processes separately create sockets ! 334: and then have messages sent between them. This is often the ! 335: case when providing or using a service in the system. This is ! 336: also the case when the communicating processes are on separate machines. ! 337: In Berkeley UNIX 4.3BSD one can create individual sockets, give them names and ! 338: send messages between them. ! 339: .pp ! 340: Sockets created by different programs use names to refer to one another; ! 341: names generally must be translated into addresses for use. ! 342: The space from which an address is drawn is referred to as a ! 343: .i domain. ! 344: There are several domains for sockets. ! 345: Two that will be used in the examples here are the UNIX domain (or AF_UNIX, ! 346: for Address Format UNIX) and the Internet domain (or AF_INET). ! 347: UNIX domain IPC is an experimental facility in 4.2BSD and 4.3BSD. ! 348: In the UNIX domain, a socket is given a path name within the file system ! 349: name space. ! 350: A file system node is created for the socket and other processes may ! 351: then refer to the socket by giving the proper pathname. ! 352: UNIX domain names, therefore, allow communication between any two processes ! 353: that work in the same file system. ! 354: The Internet domain is the UNIX implementation of the DARPA Internet ! 355: standard protocols IP/TCP/UDP. ! 356: Addresses in the Internet domain consist of a machine network address ! 357: and an identifying number, called a port. ! 358: Internet domain names allow communication between machines. ! 359: .pp ! 360: Communication follows some particular ``style.'' ! 361: Currently, communication is either through a \fIstream\fP ! 362: or by \fIdatagram.\fP ! 363: Stream communication implies several things. Communication takes ! 364: place across a connection between two sockets. The communication ! 365: is reliable, error-free, and, as in pipes, no message boundaries are ! 366: kept. Reading from a stream may result in reading the data sent from ! 367: one or several calls to \fIwrite()\fP ! 368: or only part of the data from a single call, if there is not enough room ! 369: for the entire message, or if not all the data from a large message ! 370: has been transferred. ! 371: The protocol implementing such a style will retransmit messages ! 372: received with errors. It will also return error messages if one tries to ! 373: send a message after the connection has been broken. ! 374: Datagram communication does not use connections. Each message is ! 375: addressed individually. If the address is correct, it will generally ! 376: be received, although this is not guaranteed. Often datagrams are ! 377: used for requests that require a response from the ! 378: recipient. If no response ! 379: arrives in a reasonable amount of time, the request is repeated. ! 380: The individual datagrams will be kept separate when they are read, that ! 381: is, message boundaries are preserved. ! 382: .pp ! 383: The difference in performance between the two styles of communication is ! 384: generally less important than the difference in semantics. The ! 385: performance gain that one might find in using datagrams must be weighed ! 386: against the increased complexity of the program, which must now concern ! 387: itself with lost or out of order messages. If lost messages may simply be ! 388: ignored, the quantity of traffic may be a consideration. The expense ! 389: of setting up a connection is best justified by frequent use of the connection. ! 390: Since the performance of a protocol changes as it is tuned for different ! 391: situations, it is best to seek the most up-to-date information when ! 392: making choices for a program in which performance is crucial. ! 393: .pp ! 394: A protocol is a set of rules, data formats and conventions that regulate the ! 395: transfer of data between participants in the communication. ! 396: In general, there is one protocol for each socket type (stream, ! 397: datagram, etc.) within each domain. ! 398: The code that implements a protocol ! 399: keeps track of the names that are bound to sockets, ! 400: sets up connections and transfers data between sockets, ! 401: perhaps sending the data across a network. ! 402: This code also keeps track of the names that are bound to sockets. ! 403: It is possible for several protocols, differing only in low level ! 404: details, to implement the same style of communication within ! 405: a particular domain. Although it is possible to select ! 406: which protocol should be used, for nearly all uses it is sufficient to ! 407: request the default protocol. This has been done in all of the example ! 408: programs. ! 409: .pp ! 410: One specifies the domain, style and protocol of a socket when ! 411: it is created. For example, in Figure 5a the call to \fIsocket()\fP ! 412: causes the creation of a datagram socket with the default protocol ! 413: in the UNIX domain. ! 414: .b ! 415: .sh 1 "Datagrams in the UNIX Domain" ! 416: .r ! 417: .(z ! 418: .ft CW ! 419: .so udgramread.c ! 420: .ft ! 421: .ce 1 ! 422: Figure 5a\ \ Reading UNIX domain datagrams ! 423: .)z ! 424: .pp ! 425: Let us now look at two programs that create sockets separately. ! 426: The programs in Figures 5a and 5b use datagram communication ! 427: rather than a stream. ! 428: The structure used to name UNIX domain sockets is defined ! 429: in the file \fI<sys/un.h>.\fP ! 430: The definition has also been included in the example for clarity. ! 431: .pp ! 432: Each program creates a socket with a call to \fIsocket().\fP ! 433: These sockets are in the UNIX domain. ! 434: Once a name has been decided upon it is attached to a socket by the ! 435: system call \fIbind().\fP ! 436: The program in Figure 5a uses the name ``socket'', ! 437: which it binds to its socket. ! 438: This name will appear in the working directory of the program. ! 439: The routines in Figure 5b use its ! 440: socket only for sending messages. It does not create a name for ! 441: the socket because no other process has to refer to it. ! 442: .(z ! 443: .ft CW ! 444: .so udgramsend.c ! 445: .ft ! 446: .ce 1 ! 447: Figure 5b\ \ Sending a UNIX domain datagrams ! 448: .)z ! 449: .pp ! 450: Names in the UNIX domain are path names. Like file path names they may ! 451: be either absolute (e.g. ``/dev/imaginary'') or relative (e.g. ``socket''). ! 452: Because these names are used to allow processes to rendezvous, relative ! 453: path names can pose difficulties and should be used with care. ! 454: When a name is bound into the name space, a file (inode) is allocated in the ! 455: file system. If ! 456: the inode is not deallocated, the name will continue to exist even after ! 457: the bound socket is closed. This can cause subsequent runs of a program ! 458: to find that a name is unavailable, and can cause ! 459: directories to fill up with these ! 460: objects. The names are removed by calling \fIunlink()\fP or using ! 461: the \fIrm\fP\|(1) command. ! 462: Names in the UNIX domain are only used for rendezvous. They are not used ! 463: for message delivery once a connection is established. Therefore, in ! 464: contrast with the Internet domain, unbound sockets need not be (and are ! 465: not) automatically given addresses when they are connected. ! 466: .pp ! 467: There is no established means of communicating names to interested ! 468: parties. In the example, the program in Figure 5b gets the ! 469: name of the socket to which it will send its message through its ! 470: command line arguments. Once a line of communication has been created, ! 471: one can send the names of additional, perhaps new, sockets over the link. ! 472: Facilities will have to be built that will make the distribution of ! 473: names less of a problem than it now is. ! 474: .b ! 475: .sh 1 "Datagrams in the Internet Domain" ! 476: .r ! 477: .(z ! 478: .ft CW ! 479: .so dgramread.c ! 480: .ft ! 481: .ce 1 ! 482: Figure 6a\ \ Reading Internet domain datagrams ! 483: .)z ! 484: .pp ! 485: The examples in Figure 6a and 6b are very close to the previous example ! 486: except that the socket is in the Internet domain. ! 487: The structure of Internet domain addresses is defined in the file ! 488: \fI<netinet/in.h>\fP. ! 489: Internet addresses specify a host address (a 32-bit number) ! 490: and a delivery slot, or port, on that ! 491: machine. These ports are managed by the system routines that implement ! 492: a particular protocol. ! 493: Unlike UNIX domain names, Internet socket names are not entered into ! 494: the file system and, therefore, ! 495: they do not have to be unlinked after the socket has been closed. ! 496: When a message must be sent between machines it is sent to ! 497: the protocol routine on the destination machine, which interprets the ! 498: address to determine to which socket the message should be delivered. ! 499: Several different protocols may be active on ! 500: the same machine, but, in general, they will not communicate with one another. ! 501: As a result, different protocols are allowed to use the same port numbers. ! 502: Thus, implicitly, an Internet address is a triple including a protocol as ! 503: well as the port and machine address. ! 504: An \fIassociation\fP is a temporary or permanent specification ! 505: of a pair of communicating sockets. ! 506: An association is thus identified by the tuple ! 507: <\fIprotocol, local machine address, local port, ! 508: remote machine address, remote port\fP>. ! 509: An association may be transient when using datagram sockets; ! 510: the association actually exists during a \fIsend\fP operation. ! 511: .(z ! 512: .ft CW ! 513: .so dgramsend.c ! 514: .ft ! 515: .ce 1 ! 516: Figure 6b\ \ Sending an Internet domain datagram ! 517: .)z ! 518: .pp ! 519: The protocol for a socket is chosen when the socket is created. The ! 520: local machine address for a socket can be any valid network address of the ! 521: machine, if it has more than one, or it can be the wildcard value ! 522: INADDR_ANY. ! 523: The wildcard value is used in the program in Figure 6a. ! 524: If a machine has several network addresses, it is likely ! 525: that messages sent to any of the addresses should be deliverable to ! 526: a socket. This will be the case if the wildcard value has been chosen. ! 527: Note that even if the wildcard value is chosen, a program sending messages ! 528: to the named socket must specify a valid network address. One can be willing ! 529: to receive from ``anywhere,'' but one cannot send a message ``anywhere.'' ! 530: The program in Figure 6b is given the destination host name as a command ! 531: line argument. ! 532: To determine a network address to which it can send the message, it looks ! 533: up ! 534: the host address by the call to \fIgethostbyname()\fP. ! 535: The returned structure includes the host's network address, ! 536: which is copied into the structure specifying the ! 537: destination of the message. ! 538: .pp ! 539: The port number can be thought of as the number of a mailbox, into ! 540: which the protocol places one's messages. Certain daemons, offering ! 541: certain advertised services, have reserved ! 542: or ``well-known'' port numbers. These fall in the range ! 543: from 1 to 1023. Higher numbers are available to general users. ! 544: Only servers need to ask for a particular number. ! 545: The system will assign an unused port number when an address ! 546: is bound to a socket. ! 547: This may happen when an explicit \fIbind\fP ! 548: call is made with a port number of 0, or ! 549: when a \fIconnect\fP or \fIsend\fP ! 550: is performed on an unbound socket. ! 551: Note that port numbers are not automatically reported back to the user. ! 552: After calling \fIbind(),\fP asking for port 0, one may call ! 553: \fIgetsockname()\fP to discover what port was actually assigned. ! 554: The routine \fIgetsockname()\fP ! 555: will not work for names in the UNIX domain. ! 556: .pp ! 557: The format of the socket address is specified in part by standards within the ! 558: Internet domain. The specification includes the order of the bytes in ! 559: the address. Because machines differ in the internal representation ! 560: they ordinarily use ! 561: to represent integers, printing out the port number as returned by ! 562: \fIgetsockname()\fP may result in a misinterpretation. To ! 563: print out the number, it is necessary to use the routine \fIntohs()\fP ! 564: (for \fInetwork to host: short\fP) to convert the number from the ! 565: network representation to the host's representation. On some machines, ! 566: such as 68000-based machines, this is a null operation. On others, ! 567: such as VAXes, this results in a swapping of bytes. Another routine ! 568: exists to convert a short integer from the host format to the network format, ! 569: called \fIhtons()\fP; similar routines exist for long integers. ! 570: For further information, refer to the ! 571: entry for \fIbyteorder\fP in section 3 of the manual. ! 572: .b ! 573: .sh 1 "Connections" ! 574: .r ! 575: .pp ! 576: To send data between stream sockets (having communication style SOCK_STREAM), ! 577: the sockets must be connected. ! 578: Figures 7a and 7b show two programs that create such a connection. ! 579: The program in 7a is relatively simple. ! 580: To initiate a connection, this program simply creates ! 581: a stream socket, then calls \fIconnect()\fP, ! 582: specifying the address of the socket to which ! 583: it wishes its socket connected. Provided that the target socket exists and ! 584: is prepared to handle a connection, connection will be complete, ! 585: and the program can begin to send ! 586: messages. Messages will be delivered in order without message ! 587: boundaries, as with pipes. The connection is destroyed when either ! 588: socket is closed (or soon thereafter). If a process persists ! 589: in sending messages after the connection is closed, a SIGPIPE signal ! 590: is sent to the process by the operating system. Unless explicit action ! 591: is taken to handle the signal (see the manual page for \fIsignal\fP ! 592: or \fIsigvec\fP), ! 593: the process will terminate and the shell ! 594: will print the message ``broken pipe.'' ! 595: .(z ! 596: .ft CW ! 597: .so streamwrite.c ! 598: .ft ! 599: .ce 1 ! 600: Figure 7a\ \ Initiating an Internet domain stream connection ! 601: .)z ! 602: .(z ! 603: .ft CW ! 604: .so streamread.c ! 605: .ft ! 606: .ce 1 ! 607: Figure 7b\ \ Accepting an Internet domain stream connection ! 608: .sp 2 ! 609: .ft CW ! 610: .so strchkread.c ! 611: .ft ! 612: .ce 1 ! 613: Figure 7c\ \ Using select() to check for pending connections ! 614: .)z ! 615: .(z ! 616: - ! 617: .bl 5.8i ! 618: - ! 619: .\" accept.grn goes here ! 620: .sp ! 621: .ce 1 ! 622: Figure 8\ \ Establishing a stream connection ! 623: .)z ! 624: .pp ! 625: Forming a connection is asymmetrical; one process, such as the ! 626: program in Figure 7a, requests a connection with a particular socket, ! 627: the other process accepts connection requests. ! 628: Before a connection can be accepted a socket must be created and an address ! 629: bound to it. This ! 630: situation is illustrated in the top half of Figure 8. Process 2 ! 631: has created a socket and bound a port number to it. Process 1 has created an ! 632: unnamed socket. ! 633: The address bound to process 2's socket is then made known to process 1 and, ! 634: perhaps to several other potential communicants as well. ! 635: If there are several possible communicants, ! 636: this one socket might receive several requests for connections. ! 637: As a result, a new socket is created for each connection. This new socket ! 638: is the endpoint for communication within this process for this connection. ! 639: A connection may be destroyed by closing the corresponding socket. ! 640: .pp ! 641: The program in Figure 7b is a rather trivial example of a server. It ! 642: creates a socket to which it binds a name, which it then advertises. ! 643: (In this case it prints out the socket number.) The program then calls ! 644: \fIlisten()\fP for this socket. ! 645: Since several clients may attempt to connect more or less ! 646: simultaneously, a queue of pending connections is maintained in the system ! 647: address space. \fIListen()\fP ! 648: marks the socket as willing to accept connections and initializes the queue. ! 649: When a connection is requested, it is listed in the queue. If the ! 650: queue is full, an error status may be returned to the requester. ! 651: The maximum length of this queue is specified by the second argument of ! 652: \fIlisten()\fP; the maximum length is limited by the system. ! 653: Once the listen call has been completed, the program enters ! 654: an infinite loop. On each pass through the loop, a new connection is ! 655: accepted and removed from the queue, and, hence, a new socket for the ! 656: connection is created. The bottom half of Figure 8 shows the result of ! 657: Process 1 connecting with the named socket of Process 2, and Process 2 ! 658: accepting the connection. After the connection is created, the ! 659: service, in this case printing out the messages, is performed and the ! 660: connection socket closed. The \fIaccept()\fP ! 661: call will take a pending connection ! 662: request from the queue if one is available, or block waiting for a request. ! 663: Messages are read from the connection socket. ! 664: Reads from an active connection will normally block until data is available. ! 665: The number of bytes read is returned. When a connection is destroyed, ! 666: the read call returns immediately. The number of bytes returned will ! 667: be zero. ! 668: .pp ! 669: The program in Figure 7c is a slight variation on the server in Figure 7b. ! 670: It avoids blocking when there are no pending connection requests by ! 671: calling \fIselect()\fP ! 672: to check for pending requests before calling \fIaccept().\fP ! 673: This strategy is useful when connections may be received ! 674: on more than one socket, or when data may arrive on other connected ! 675: sockets before another connection request. ! 676: .pp ! 677: The programs in Figures 9a and 9b show a program using stream communication ! 678: in the UNIX domain. Streams in the UNIX domain can be used for this sort ! 679: of program in exactly the same way as Internet domain streams, except for ! 680: the form of the names and the restriction of the connections to a single ! 681: file system. There are some differences, however, in the functionality of ! 682: streams in the two domains, notably in the handling of ! 683: \fIout-of-band\fP data (discussed briefly below). These differences ! 684: are beyond the scope of this paper. ! 685: .(z ! 686: .ft CW ! 687: .so ustreamwrite.c ! 688: .ft ! 689: .ce 1 ! 690: Figure 9a\ \ Initiating a UNIX domain stream connection ! 691: .sp 2 ! 692: .ft CW ! 693: .so ustreamread.c ! 694: .ft ! 695: .ce 1 ! 696: Figure 9b\ \ Accepting a UNIX domain stream connection ! 697: .)z ! 698: .b ! 699: .sh 1 "Reads, Writes, Recvs, etc." ! 700: .r ! 701: .pp ! 702: UNIX 4.3BSD has several system calls for reading and writing information. ! 703: The simplest calls are \fIread() \fP and \fIwrite().\fP \fIWrite()\fP ! 704: takes as arguments the index of a descriptor, a pointer to a buffer ! 705: containing the data and the size of the data. ! 706: The descriptor may indicate either a file or a connected socket. ! 707: ``Connected'' can mean either a connected stream socket (as described ! 708: in Section 8) or a datagram socket for which a \fIconnect()\fP ! 709: call has provided a default destination (see the \fIconnect()\fP manual page). ! 710: \fIRead()\fP also takes a descriptor that indicates either a file or a socket. ! 711: \fIWrite()\fP requires a connected socket since no destination is ! 712: specified in the parameters of the system call. ! 713: \fIRead()\fP can be used for either a connected or an unconnected socket. ! 714: These calls are, therefore, quite flexible and may be used to ! 715: write applications that require no assumptions about the source of ! 716: their input or the destination of their output. ! 717: There are variations on \fIread() \fP and \fIwrite()\fP ! 718: that allow the source and destination of the input and output to use ! 719: several separate buffers, while retaining the flexibility to handle ! 720: both files and sockets. These are \fIreadv()\fP and \fI writev(),\fP ! 721: for read and write \fIvector.\fP ! 722: .pp ! 723: It is sometimes necessary to send high priority data over a ! 724: connection that may have unread low priority data at the ! 725: other end. For example, a user interface process may be interpreting ! 726: commands and sending them on to another process through a stream connection. ! 727: The user interface may have filled the stream with as yet unprocessed ! 728: requests when the user types ! 729: a command to cancel all outstanding requests. ! 730: Rather than have the high priority data wait ! 731: to be processed after the low priority data, it is possible to ! 732: send it as \fIout-of-band\fP ! 733: (OOB) data. The notification of pending OOB data results in the generation of ! 734: a SIGURG signal, if this signal has been enabled (see the manual ! 735: page for \fIsignal\fP or \fIsigvec\fP). ! 736: See [Leffler 1986] for a more complete description of the OOB mechanism. ! 737: There are a pair of calls similar to \fIread\fP and \fIwrite\fP ! 738: that allow options, including sending ! 739: and receiving OOB information; these are \fI send()\fP ! 740: and \fIrecv().\fP ! 741: These calls are used only with sockets; specifying a descriptor for a file will ! 742: result in the return of an error status. These calls also allow ! 743: \fIpeeking\fP at data in a stream. ! 744: That is, they allow a process to read data without removing the data from ! 745: the stream. One use of this facility is to read ahead in a stream ! 746: to determine the size of the next item to be read. ! 747: When not using these options, these calls have the same functions as ! 748: \fIread()\fP and \fIwrite().\fP ! 749: .pp ! 750: To send datagrams, one must be allowed to specify the destination. ! 751: The call \fIsendto()\fP ! 752: takes a destination address as an argument and is therefore used for ! 753: sending datagrams. The call \fIrecvfrom()\fP ! 754: is often used to read datagrams, since this call returns the address ! 755: of the sender, if it is available, along with the data. ! 756: If the identity of the sender does not matter, one may use \fIread()\fP ! 757: or \fIrecv().\fP ! 758: .pp ! 759: Finally, there are a pair of calls that allow the sending and ! 760: receiving of messages from multiple buffers, when the address of the ! 761: recipient must be specified. These are \fIsendmsg()\fP and ! 762: \fIrecvmsg().\fP ! 763: These calls are actually quite general and have other uses, ! 764: including, in the UNIX domain, the transmission of a file descriptor from one ! 765: process to another. ! 766: .pp ! 767: The various options for reading and writing are shown in Figure 10, ! 768: together with their parameters. The parameters for each system call ! 769: reflect the differences in function of the different calls. ! 770: In the examples given in this paper, the calls \fIread()\fP and ! 771: \fIwrite()\fP have been used whenever possible. ! 772: .(z ! 773: .ft CW ! 774: /* ! 775: * The variable descriptor may be the descriptor of either a file ! 776: * or of a socket. ! 777: */ ! 778: cc = read(descriptor, buf, nbytes) ! 779: int cc, descriptor; char *buf; int nbytes; ! 780: ! 781: /* ! 782: * An iovec can include several source buffers. ! 783: */ ! 784: cc = readv(descriptor, iov, iovcnt) ! 785: int cc, descriptor; struct iovec *iov; int iovcnt; ! 786: ! 787: cc = write(descriptor, buf, nbytes) ! 788: int cc, descriptor; char *buf; int nbytes; ! 789: ! 790: cc = writev(descriptor, iovec, ioveclen) ! 791: int cc, descriptor; struct iovec *iovec; int ioveclen; ! 792: ! 793: /* ! 794: * The variable ``sock'' must be the descriptor of a socket. ! 795: * Flags may include MSG_OOB and MSG_PEEK. ! 796: */ ! 797: cc = send(sock, msg, len, flags) ! 798: int cc, sock; char *msg; int len, flags; ! 799: ! 800: cc = sendto(sock, msg, len, flags, to, tolen) ! 801: int cc, sock; char *msg; int len, flags; ! 802: struct sockaddr *to; int tolen; ! 803: ! 804: cc = sendmsg(sock, msg, flags) ! 805: int cc, sock; struct msghdr msg[]; int flags; ! 806: ! 807: cc = recv(sock, buf, len, flags) ! 808: int cc, sock; char *buf; int len, flags; ! 809: ! 810: cc = recvfrom(sock, buf, len, flags, from, fromlen) ! 811: int cc, sock; char *buf; int len, flags; ! 812: struct sockaddr *from; int *fromlen; ! 813: ! 814: cc = recvmsg(sock, msg, flags) ! 815: int cc, socket; struct msghdr msg[]; int flags; ! 816: .ft ! 817: .sp 1 ! 818: .ce 1 ! 819: Figure 10\ \ Varieties of read and write commands ! 820: .)z ! 821: .b ! 822: .sh 1 "Choices" ! 823: .r ! 824: .pp ! 825: This paper has presented examples of some of the forms ! 826: of communication supported by ! 827: Berkeley UNIX 4.3BSD. These have been presented in an order chosen for ! 828: ease of presentation. It is useful to review these options emphasizing the ! 829: factors that make each attractive. ! 830: .pp ! 831: Pipes have the advantage of portability, in that they are supported in all ! 832: UNIX systems. They also are relatively ! 833: simple to use. Socketpairs share this simplicity and have the additional ! 834: advantage of allowing bidirectional communication. The major shortcoming ! 835: of these mechanisms is that they require communicating processes to be ! 836: descendants of a common process. They do not allow intermachine communication. ! 837: .pp ! 838: The two communication domains, UNIX and Internet, allow processes with no common ! 839: ancestor to communicate. ! 840: Of the two, only the Internet domain allows ! 841: communication between machines. ! 842: This makes the Internet domain a necessary ! 843: choice for processes running on separate machines. ! 844: .pp ! 845: The choice between datagrams and stream communication is best made by ! 846: carefully considering the semantic and performance ! 847: requirements of the application. ! 848: Streams can be both advantageous and disadvantageous. One disadvantage ! 849: is that a process is only allowed a limited number of open streams, ! 850: as there are usually only 64 entries available in the open descriptor ! 851: table. This can cause problems if a single server must talk with a large ! 852: number of clients. ! 853: Another is that for delivering a short message the stream setup and ! 854: teardown time can be unnecessarily long. Weighed against this are ! 855: the reliability built into the streams. This will often be the ! 856: deciding factor in favor of streams. ! 857: .b ! 858: .sh 1 "What to do Next" ! 859: .r ! 860: .pp ! 861: Many of the examples presented here can serve as models for multiprocess ! 862: programs and for programs distributed across several machines. ! 863: In developing a new multiprocess program, it is often easiest to ! 864: first write the code to create the processes and communication paths. ! 865: After this code is debugged, the code specific to the application can ! 866: be added. ! 867: .pp ! 868: An introduction to the UNIX system and programming using UNIX system calls ! 869: can be found in [Kernighan and Pike 1984]. ! 870: Further documentation of the Berkeley UNIX 4.3BSD IPC mechanisms can be ! 871: found in [Leffler et al. 1986]. ! 872: More detailed information about particular calls and protocols ! 873: is provided in sections ! 874: 2, 3 and 4 of the ! 875: UNIX Programmer's Manual [CSRG 1986]. ! 876: In particular the following manual pages are relevant: ! 877: .(b ! 878: .TS ! 879: l l. ! 880: creating and naming sockets socket(2), bind(2) ! 881: establishing connections listen(2), accept(2), connect(2) ! 882: transferring data read(2), write(2), send(2), recv(2) ! 883: addresses inet(4F) ! 884: protocols tcp(4P), udp(4P). ! 885: .TE ! 886: .)b ! 887: .(b ! 888: .sp ! 889: .b ! 890: Acknowledgements ! 891: .pp ! 892: I would like to thank Sam Leffler and Mike Karels for their help in ! 893: understanding the IPC mechanisms and all the people whose comments ! 894: have helped in writing and improving this report. ! 895: .pp ! 896: This work was sponsored by the Defense Advanced Research Projects Agency ! 897: (DoD), ARPA Order No. 4031, monitored by the Naval Electronics Systems ! 898: Command under contract No. N00039-C-0235. ! 899: The views and conclusions contained in this document are those of the ! 900: author and should not be interpreted as representing official policies, ! 901: either expressed or implied, of the Defense Research Projects Agency ! 902: or of the US Government. ! 903: .)b ! 904: .(b ! 905: .sp ! 906: .b ! 907: References ! 908: .r ! 909: .sp ! 910: .ls 1 ! 911: B.W. Kernighan & R. Pike, 1984, ! 912: .i "The UNIX Programming Environment." ! 913: Englewood Cliffs, N.J.: Prentice-Hall. ! 914: .sp ! 915: .ls 1 ! 916: B.W. Kernighan & D.M. Ritchie, 1978, ! 917: .i "The C Programming Language," ! 918: Englewood Cliffs, N.J.: Prentice-Hall. ! 919: .sp ! 920: .ls 1 ! 921: S.J. Leffler, R.S. Fabry, W.N. Joy, P. Lapsley, S. Miller & C. Torek, 1986, ! 922: .i "An Advanced 4.3BSD Interprocess Communication Tutorial." ! 923: Computer Systems Research Group, ! 924: Department of Electrical Engineering and Computer Science, ! 925: University of California, Berkeley. ! 926: .sp ! 927: .ls 1 ! 928: Computer Systems Research Group, 1986, ! 929: .i "UNIX Programmer's Manual, 4.3 Berkeley Software Distribution." ! 930: Computer Systems Research Group, ! 931: Department of Electrical Engineering and Computer Science, ! 932: University of California, Berkeley. ! 933: .)b
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.