PRENTICE HALL SOFTWARE SERIES
`
`PROGRAMMING
`
`(sleeping)
`
`fork, exec
`
`!11!!111!!1||I|L
`
`b ' | t '
`
`W. RICHARD STEVENS
`
`1
`
`SAMSUNG 1034
`
`

`

`
`
`2
`
`

`

`
`
`3
`
`

`

`Section 2.4
`
`Signals
`
`43
`
`Manyof these features (asynchronousI/O,record locking, signals) are described in more
`detail in later chapters.
`
`ioctl System Call
`
`The ioct 1 system call is also used to change the behavior of an openfile.
`
`< s v =
`
`=
`
`int iocti({int filedes, unsigned long request,
`
`char *arg);
`
`twonotes are commonto both sys-
`
`This system call performs a variety of control functions on terminals, devices, sockets
`(BSD), and streams (System V). The BSD include file <sys/ioct1.h> contains the
`definitions for request for all possible operations. Under System V different header files
`are used depending on the type of operation being performed. For example,
`<termio.h> contains the request values for terminal operations. Historically,
`the
`greatest use for ioct 1 has been to change terminal characteristics:
`the baudrate, parity,
`number of bits per character, and so on.
`It is also used for a plethora of other device-
`specific operations.
`We'll return to this system call when we cover Berkeley sockets and System V
`streams in Chapters 6 and 7. Wealso use it in Chapter 15 to changethe characteristics of
`a terminal device.
`The main difference between fcnt1 and ioct1 is that the formeris intended for
`any open file, while the latter is intended for device-specific operations. This separation
`of function, however,is less than perfect.
`
`Signals
`
`A signal is a notification to a process that an event has occurred. Signals are sometimes
`called ‘software interrupts.’’ Signals usually occur asynchronously. By this we mean
`that the process doesn’t know ahead of time exactly whenasignal will occur. Signals
`Can be sent
`
`* by oneprocess to anotherprocess(ortoitself),
`* by the kernel to a process.
`Before describing the conditions under which signals are sent, let’s first give the names
`for all the signals. Every signal has a name,specified in the headerfile <signal.h>.
`Figure 2.4 summarizes the namesofall the signals along with their description and
`default action. The column labeled ‘‘Note’’specifies ifthe signalis specific to either
`a orSystemV. Rowswithout«
`
`4
`
`

`

`
`
`5
`
`

`

`
`
`6
`
`

`

`
`
`7
`
`

`

`
`
`8
`
`

`

`
`
`9
`
`

`

`rea
`gecuon
`
`{0 the
`
`263
`Unix Domain Protocols
`6a
`4,3BSD provides both aconnection“oriented interface and a connectionless interface
`Unix domain| E
`uae Bi
`n can beconsidered reliable, since theyexist only
`“hin the kernel andarenot transmittedacrossexternalfacil 1€8
`such as a communica-
`eis between systems. Checksum Ss and the like are not needed. As with other
`ne ction-orientedprotocols(TCPandSPP, ‘orexample), theconnection-oriented Unix
`eon providesflowcontrol, Ina similar fashion, as withotherconnectionless proto-
`aUDPand IDP, for example), the Unix domaindatagram facility‘does not provide
`AY control. Thishasimplicationsfor user programs, since it is possible fora datagram
`clos ata0shatblr starvation canoccursappear
`ust try to sendthedata repeatedly. For this reasonalone, it is recommended that you
`ii theconnection-oriented Unix domain protocol,
`i The Unix domain protocols provide a feature that is
`not currently provided by any
`other protocol family: thea ” ty topass Accessrights
`from oneprocess to another.
`We'll discussthisfeature in more detail in Section 6.10 w
`hen we describe the passing of
`file descriptors betweenprocesses,
`Unliketheother protocols we'vecovered, there is nothing like encapsulation per-
`formed on the Unix domain messages—theiractual implementation isa kernel detail that
`need not concern us, As it turns out, 4.3BSD implements Pipes usingthe connection-
`oriented Unix domainprotocol.
`|
`The name spaceused by the Unix domain
`Protocols consists of pathnames. A sam-
`ple association could be
`/dev/logfile)
`{unixstr, 0,
`/tmp/log.01528, 0,
`the connection-
`The protocol here is unixstr, which Stands for ‘Unix stream,’’
`oriented protocol, The local-process in this example is / tmp/log.01528 and the
`foreign-process is /dev/logfile. We showboth the local-addr and theforeign-addr
`as zero, since the pathnames on the local host are the only addresses used in this
`domain.? An association using the connectionless Unix protocol is similar, except that
`We use the term unixdg to Specify the datagram protocol,
`the first member of the
`S-tuple,
`The 4.3BSD implementation creates a file in the filesystem with the
`Specified path-
`hame, although there are comments in the 4.3BSD manuals indicating
`sions might not create these files. This is somewhat misleading, howeve
`that future ver-
`filesystem entries are not true ‘files.’
`t, because these
`” For example, we cannot Open these files with the
`pen system call. Thesefiles have 4 type of S_IFSOCK as reported by the stat or
`Estat system calls
`
`Soreign-addr to be the pathnames, with the local-process
`
`SeWe could define the local-addr and the
`and foreign-process both being zero, Our reason for specifying the association as we did is to
`reiterate that a host addressis not required since the associationis limited to processes on the local
`
`10
`
`

`

`
`
`11
`
`

`

`Sockaddrin and sockaddr_nsstructures were both identical in size (16 bytes) to
`
`(You may have noticed the discrepancies in the declarations of the first two bytes of
`these address structures, the XX_family members. The Internet and Unix domain
`members are declared as short
`integers, while the XNS member and the generic
`Sockaddr member are unsigned short integers. Fortunately the values stored in these
`Variables,
`the AF_xxx constants that we define in the next section, all have values
`between 1 and 20, so this discrepancyin the data types doesn’t matter.)
`Unlike most Unix system calls, the BSD network system calls don’t assume that the
`Unix pathnamein sun_pathis terminated with a null byte. Notice thatthis protocol-
`Specific
`structure
`is
`larger
`than the generic
`sockaddr Structure, while
`the
`
`i #
`
`sns_addr.xport
`snsport
`define
`Things are more complicated with XNS,as some ofthe network code wantsto get at the
`hostid and netid fields in different ways.
`For the Unix domain,the following structure is defined in <sys/un.h>:
`struct sockaddrun {
`Short
`sunfamily;
`char
`sunpath[{108];
`
`}F
`
`/* BFUNIX */
`/* pathname */
`
`gection 6:
`
`4
`
`Socket Addresses
`
`265
`
`{
`
`se host
`‘on ns_host
`ais char
`u_short
`rl
`
`he
`
`{
`
`union ns_net
`u char
`u_short
`Fe
`
`he
`
`|
`/* hostid addr as Six bytes */
`c_host(6];
`s_host{3]7 /* hostid addr as three 16-bit shorts */
`/* network byte ordered mf
`
`.
`c_net(4];
`sanetl2)7.
`
`|
`/* netid as four bytes */
`/* netid as two 16-bit shorts */
`/* network byte ordered */
`
`{
`
`/* here is the combined 12-byte xNS address +/
`struct ns_addr
`xnet;
`/* 4-byte netid */
`union ns_net
`union ns_host x_host;
`/* 6-byte hostid + /
`BCDOne
`xport;
` /* 2-byte port
`(XNS "socket") */
`
`iG
`
`struct sockaddrns {
`u short
`snsfamily;
`struct ns_addr
`snsaddr;
`char
`sns_zero[2];
`
`/* AFNS */
`/* the 12-byte XNS address *«/
`/* unused */
`
`12
`
`

`

`
`
`13
`
`

`

`Sectl
`
`ae
`
`Elementary Socket System Calls
`
`267
`
`ddr
`{
`Pouce eos SCA (|
`/* BFxxx value */
`eaRort
`safamily;
`:
`*
`union {
`struct sockaddrin sa in;
`/* Internet address */
`struct sockaddrns
`gans;
`/* XNS address eh
`struct sockaddr_un
`saun;
`/* Unix address */
`} sa_val;
`
`he
`
`The problem with this approachis that the size of the union is determined bythe size of
`the largest member, which is the Unix domain address. This would cause every
`sock addrstructure to be 110 bytes in size, even though Internet and XNS addresses
`need only 8 bytes and 14 bytes, respectively. (Note that in this case the 8 bytes of zero at
`sockaddr_ns are not needed.) One advantage of a unionis that the size of the struc-
`ture would not have to be an argument (and sometimes a result) to the system calls, as
`we'll see below. The actual
`interface design and the choice of a generic sockaddr
`structure along with the protocol-specific socket addressstructures, was a compromise.
`
`Elementary Socket System Calls
`Wenow describe the elementary system calls required to perform network programming.
`In the following section weuse these system calls to develop some networking examples.
`
`socket System Call
`
`XNS SPP,etc.).
`
`thefirst thing a process must do is call the socket system call,
`To do network I/O,
`specifying the type of communication protocol desired (Internet TCP, Internet UDP,
`#include <sys/types.h>
`#include <sys /socket .h>
`int socket (int family,
`int type,
`Thefamily is one of
`
`int protocol) ;
`
`AFUNIX
`Unix internal protocols
`AF_INET
`Internet protocols
`AF_NS
`Xerox NS protocols
`AF_IMPLINK
`IMPlink layer
`is
`The AF_ prefix stands for ‘address family.’’ There is another set of terms that
`metined, Starting with a PFprefix, which stands for “protocol family”’: PFUNIX,
`F_INET, pr NS, and PF_IMPLINK.Eitherterm for a given family can be used. as
`
`fY are equivalent.
`
`14
`
`

`

`
`
`15
`
`

`

`269
`Elementary Socket System Calls
`65
`©
`pPROTO_xxx constants are defined in the file Snetinet/in.h> and the
`sat To xxxconstants are defined inthe file <net ns/ns.h>. In Section11.2we’ll
`ae Internet ping program, which usesthe ICMPprotocol.
`a oe systemcall returns a small integer
`value,
`stall this a socketdescriptor, Ora sockfd. To obtain this socket descriptor,all we’ve
`vite” is anaddress family andthe socket type (stream, datagram, etc.). For an associ-
`(protocol,
`local-addr,
`local-process, foreign-addr. Soreign-process}
`the socket systemcallspecifies is one elementof this 5-tuple, the protocol. Before
`a socket descriptor is of any realuse, the remaining four elements of the association
`Da bespecified. To showwhata typical Process doesnext, we’ll differentiate between
`a client and server, and between a connection-oriented protocol and aconnectionless
`Piccol Figure6.8 showsthe typical system calls for each case.
`protocol
`local-addr, local-process
`foreign-addr,foreign-process
`connection-oriented server [socket ()
`bind()
`listen(), accept ()
`
`
`connection-oriented client|socket () __connect ()
`connectionless server
`socket() |
`_—sdbind()
`recvfrom ()
`connectionlessclient
`socket()
`bind()
`sendto ()
`Figure 6.8 Socket systemcalls and association elements.
`
`In Section 6,9.
`
`
`
`socketpair System Call
`
`This system call is implemented only for the Unix domain.
`#finclude <sys/types.h>
`#include <sys/socket .h>
`int sockvec[2]) ;
`int protocol,
`int type,
`int socketpair (int family,
`This returns two socket descriptors, sockvec[0] and sockvec[1], that are unnamed and
`connected. This system call
`is similar to the Pipe system call, but socketpair
`returns a pair of socket descriptors, not file descriptors. Additionally, the two socket
`i
`ocketpairarebidirectional, unlike pipes, which are unidirec-
`pe examples from Section 3.4, we had to execute the pipe sys-
`obtaining fourfile descriptors, to get a bidirectional flow of data between
`'Wo processes. With sockets
`this
`isn’t
`required. Well call
`these bidirectional,
`ronnection-oriented, Unix domain sockets stream pipes. We return to these stream pipes
`
`section
`
`s a
`
`tion
`
`16
`
`

`

`
`
`17
`
`17
`
`

`

`
`
`18
`
`18
`
`

`

`
`
`19
`
`19
`
`

`

`
`
`20
`
`

`

`
`
`21
`
`

`

`
`
`22
`
`22
`
`

`

`
`
`23
`
`23
`
`

`

`
`
`
`
`
`
`24
`
`

`

`
`
`25
`
`25
`
`

`

`
`
`
`
`
`
`26
`
`

`

`
`
`27
`
`27
`
`

`

`
`
`
`
`28
`
`

`

`
`
`
`
`
`
`29
`
`

`

`
`
`
`
`30
`
`

`

`
`
`31
`
`31
`
`

`

`
`
`32
`
`32
`
`

`

`
`
`33
`
`

`

`
`
`
`
`
`
`
`34
`
`

`

`
`
`35
`
`

`

`
`
`36
`
`

`

`
`
`37
`
`37
`
`

`

`
`
`38
`
`38
`
`

`

`
`
`
`
`39
`
`

`

`
`
`40
`
`

`

`
`
`41
`
`

`

`
`
`42
`
`

`

`
`
`
`
`
`
`
`
`43
`
`

`

`
`
`44
`
`44
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`45
`
`

`

`
`
`46
`
`

`

`
`
`47
`
`47
`
`

`

`48
`
`

`

`49
`
`

`

`
`
`50
`
`

`

`
`
`51
`
`

`

`
`
`52
`
`