Lines Matching +full:out +full:- +full:of +full:- +full:band
2 .\" The Regents of the University of California. All rights reserved.
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
10 .\" notice, this list of conditions and the following disclaimer in the
12 .\" 3. Neither the name of the University nor the names of its contributors
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
40 A number of facilities have yet to be discussed. For most users
46 Out of band data
48 The stream socket abstraction includes the notion of \*(lqout
49 of band\*(rq data. Out of band data is a logically independent
50 transmission channel associated with each pair of connected
51 stream sockets. Out of band data is delivered to the user
52 independently of normal data.
53 The abstraction defines that the out of band data facilities
54 must support the reliable delivery of at least one
55 out of band message at a time. This message may contain at least one
56 byte of data, and at least one message may be pending delivery
58 support only in-band signaling (i.e. the urgent data is
62 in order and receiving it out of sequence without having to
64 to ``peek'' (via MSG_PEEK) at out of band data.
66 when the protocol is notified of its existence.
71 If multiple sockets may have out of band data awaiting
75 of the out-of-band data, but only notification that it is pending.
78 the data stream to indicate the point at which the out
79 of band data was sent. The remote login and remote shell
85 To send an out of band message the MSG_OOB flag is supplied to
87 while to receive out of band data MSG_OOB should be indicated
89 To find out if the read pointer is currently pointing at
95 after the mark. Otherwise (assuming out of band data has arrived),
97 to transmission of the out of band signal. The routine used
98 in the remote login process to flush output on receipt of an
101 then reads the out-of-band byte.
109 int out = FWRITE, mark;
113 ioctl(1, TIOCFLUSH, (char *)&out);
131 Figure 5. Flushing terminal I/O on receipt of out of band data.
135 A process may also read or peek at the out-of-band data
138 the urgent data in-band with the normal data, and only sends
139 notification of its presence ahead of time (e.g., the TCP protocol
141 With such protocols, the out-of-band byte may not yet have arrived
143 In that case, the call will return an error of EWOULDBLOCK.
144 Worse, there may be enough in-band data in the input buffer
147 The process must then read enough of the queued data
150 Certain programs that use multiple bytes of urgent data and must
152 need to retain the position of urgent data within the stream.
153 This treatment is available as a socket-level option, SO_OOBINLINE;
155 With this option, the position of urgent data (the \*(lqmark\*(rq)
158 Reception of multiple urgent indications causes the mark to move,
159 but no out-of-band data are lost.
161 Non-Blocking Sockets
163 It is occasionally convenient to make use of sockets
169 the \fIsocket\fP call, it may be marked as non-blocking
185 When performing non-blocking I/O on sockets, one must be
189 was performed on is marked as non-blocking.
203 descriptor) has data waiting to be read. Use of
206 by use of the \fIsignal\fP or \fIsigvec\fP calls. Second,
208 notification of pending input to its own process id,
209 or the process group id of its process group (note that
210 the default process group of a socket is group zero).
211 This is accomplished by use of an \fIfcntl\fP call.
212 Third, it must enable asynchronous notification of pending I/O requests
216 is given in Figure 6. With the addition of a handler for SIGURG,
217 this code can also be used to prepare for receipt of SIGURG signals.
233 /* Allow receipt of asynchronous I/O signals */
241 Figure 6. Use of asynchronous notification of I/O requests.
247 Due to the existence of the SIGURG and SIGIO signals each socket has an
259 current process number of a socket.
298 Figure 7. Use of the SIGCHLD signal.
303 a large number of \*(lqzombie\*(rq processes may be created.
309 the semantics of terminals,
311 the network do so through a \fIpseudo-terminal\fP. A pseudo-
312 terminal is actually a pair of devices, master and slave,
315 of a pseudo-terminal is supplied as input to a process reading
319 the master side of the pseudo-terminal has control over the
323 The purpose of this abstraction is to
329 login server uses pseudo-terminals for remote login sessions.
331 a shell with a slave pseudo-terminal as standard input, output,
337 the pseudo-terminal generates a control message for the server process.
338 The server then sends an out of band message
339 to the client process to signal a flush of data at the real terminal
342 Under 4.4BSD, the name of the slave side of a pseudo-terminal is of the form
347 The master side of a pseudo-terminal is \fI/dev/ptyxy\fP,
349 slave side of the pseudo-terminal.
351 In general, the method of obtaining a pair of master and
352 slave pseudo-terminals is to
353 find a pseudo-terminal which
355 The master half of a pseudo-terminal is a single-open device;
357 The slave side of the pseudo-terminal is then opened,
360 the master side of the pseudo-terminal, and \fIexec\fPs the
362 slave side of the pseudo-terminal and begins reading and
363 writing from the master side. Sample code making use of
364 pseudo-terminals is given in Figure 8; this code assumes
366 to a peer who wants a service of some kind, and that the
373 line[sizeof("/dev/pty")-1] = c;
374 line[sizeof("/dev/ptyp")-1] = '0';
378 line[sizeof("/dev/ptyp")-1] = "0123456789abcdef"[i];
391 line[sizeof("/dev/")-1] = 't';
421 Figure 8. Creation and use of a pseudo terminal
429 the returned socket of the type requested.
433 lower-level protocols or hardware interfaces,
440 domain one may use one of the library routines
449 s = socket(AF_INET, SOCK_STREAM, pp->p_proto);
452 based connection, but with protocol type of ``newtcp''
453 instead of the default ``tcp.''
471 are composed of local and foreign
473 allocated out of separate spaces, one for each system and one
476 process may specify half of an association, the
487 the set of allocated port numbers is not directly accessible
490 To simplify local address binding in the Internet domain the notion of a
518 the address of the host on the appropriate network.
531 bcopy(hp->h_addr, (char *) sin.sin_addr, hp->h_length);
541 for non-privileged servers. The second is
547 int lport = IPPORT_RESERVED \- 1;
564 First, the name of the system the user
571 logging. The port number and network address of the
573 by the \fIfrom\fP result of the \fIaccept\fP call, or
605 It is possible to set and get a number of options on sockets
609 In addition, there are protocol-specific options for IP and TCP,
615 The general forms of the calls are:
632 \fIOptval\fP and \fIOptlen\fP point to the value of the
634 on or off), and the length of the value of the option,
637 a value-result parameter, initially set to the size of
639 upon return to indicate the actual amount of storage used.
660 to the value of the socket type, as defined in
670 provides no simulation of broadcast in software.
675 Broadcast is typically used for one of two reasons:
677 knowledge of its address,
714 The destination address of the message to be broadcast
719 To determine the list of addresses for all reachable neighbors
720 requires knowledge of the networks to which the host is connected.
722 be obtained in a host-independent fashion and may be impossible
723 to derive, 4.4BSD provides a method of
726 configuration of a host in the form of a
728 a ``data area'' which is made up of an array of
737 int ifc_len; /* size of associated buffer */
745 #define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
762 #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
785 there exists a set of ``interface flags'' which tell
796 for (n = ifc.ifc_len / sizeof (struct ifreq); --n >= 0; ifr++) {
803 if (ifr->ifr_addr.sa_family != AF_INET)
811 if ((ifr->ifr_flags & IFF_UP) == 0 ||
812 (ifr->ifr_flags & IFF_LOOPBACK) ||
813 (ifr->ifr_flags & (IFF_BROADCAST | IFF_POINTTOPOINT)) == 0)
818 must be obtained. In the case of broadcast networks this is
819 done via the SIOCGIFBRDADDR \fIioctl\fP, while for point-to-point networks
820 the address of the destination host is obtained with SIOCGIFDSTADDR.
824 if (ifr->ifr_flags & IFF_POINTTOPOINT) {
828 bcopy((char *) ifr->ifr_dstaddr, (char *) &dst, sizeof (ifr->ifr_dstaddr));
829 } else if (ifr->ifr_flags & IFF_BROADCAST) {
833 bcopy((char *) ifr->ifr_broadaddr, (char *) &dst, sizeof (ifr->ifr_broadaddr));
845 interface to which the host is connected that supports the notion of
846 broadcast or point-to-point addressing.
854 a message is allowed to go out.
858 IP multicasting is the transmission of an IP datagram to a "host
859 group", a set of zero or more hosts identified by a single IP
861 members of its destination host group with the same "best-efforts"
863 not guaranteed to arrive intact at all members of the destination
866 The membership of a host group is dynamic; that is, hosts may join
868 location or number of members in a host group. A host may be a
869 member of more than one group at a time. A host need not be a member
873 well-known, administratively assigned IP address. It is the address,
874 not the membership of the group, that is permanent; at any time a
875 permanent group may have any number of members, even zero. Those IP
882 received as a member of a transient host group are intended for the
884 higher-level identifiers or authentication tokens. Information
889 IP multicasting is currently supported only on AF_INET sockets of type
903 The definitions required for the multicast-related socket options are
905 All IP addresses are passed in network byte-order.
907 By default, IP multicast datagrams are sent with a time-to-live (TTL) of 1,
910 any value from 0 to 255, in order to control the scope of the multicasts:
915 Multicast datagrams with a TTL of 0 will not be transmitted on any subnet,
920 to the first-hop subnet. To provide meaningful scope control, the multicast
921 routers support the notion of TTL "thresholds", which prevent datagrams with
943 For example, an application might perform an "expanding-ring search" for a
944 network resource by sending a multicast query, first with a TTL of 0, and
952 224.0.0.255, inclusive, regardless of its TTL. This range of addresses is
953 reserved for the use of routing protocols and other low-level topology
959 to the permanent group of all IP hosts (including gateways). This is
962 all hosts on the total Internet. The addresses of other well-known,
967 the host has more than one multicast-capable interface. (If the host is
980 where "addr" is the local IP address of the desired outgoing interface.
981 An address of INADDR_ANY may be used to revert to the default interface.
982 The local IP address of an interface can be obtained via the SIOCGIFCONF
991 belongs (on the outgoing interface), a copy of the datagram is, by default,
1004 the overhead of receiving their own transmissions. It should generally not
1032 be INADDR_ANY to choose the default multicast interface, or one of the
1033 host's local addresses to choose a particular (multicast-capable) interface.
1046 will remain a member of that group until the last claim is dropped.
1051 destination group of the datagram; however, delivery of a multicast datagram
1075 datagrams are never delivered to more than one socket, regardless of
1078 A final multicast-related extension is independent of IP: two new ioctls,
1079 SIOCADDMULTI and SIOCDELMULTI, are available to add or delete link-level
1081 The address to be added or deleted is passed as a sockaddr structure of
1085 for the use of protocols other than IP, and require superuser privileges.
1086 A link-level multicast address added via SIOCADDMULTI is not automatically
1088 deleted. It is inadvisable to delete a link-level address that may be
1095 time to an arbitrarily-chosen multicast group and UDP port.
1133 sprintf(message, "time is %-24.24s", ctime(&t));
1172 .\"----------------------------------------------------------------------
1176 The semantics of NS connections demand that
1179 in certain fields of an outgoing packet.
1188 The contents of a SPP header (minus the IDP header) are:
1195 #define SP_OB 0x20 /* attention (out of band data) */
1196 #define SP_EM 0x10 /* end of message */
1205 Here, the items of interest are the \fIdatastream type\fP and
1206 the \fIconnection control\fP fields. The semantics of the
1208 the value of this field is, by default, zero, but it can be
1211 field is a mask of the flags defined just below it. The user may
1212 set or clear the end-of-message bit to indicate
1213 that a given message is the last of a given substream type,
1215 indicate that a packet should be sent out-of-band.
1237 buf.proto_spp.sp_cc = SP_EM; /* end-of-message */
1245 the kernel will treat the first few bytes of the data as the
1268 The header of an IDP-level packet looks like:
1280 The primary field of interest in an IDP header is the \fIpacket type\fP
1291 For SPP connections, the contents of this field are
1295 Setting the value of that field with SO_DEFAULT_HEADERS is
1319 case, all the fields of the prototype header (except the
1323 source address must be set to that of the host sending the
1324 data; the destination address must be set to that of the
1330 is used, in spite of the fact that it is the destination
1332 given in either of those calls. For almost
1336 Three-way Handshake
1338 The semantics of SPP connections indicates that a three-way
1342 ``well-behaved'' in this manner; when communicating with
1343 any process, it is best to assume that the three-way handshake
1345 required. In a three-way close, the closing process
1347 a zero-length packet with end-of-message set and with
1348 datastream type 254. The other side of the connection
1349 indicates that it is OK to close by sending a zero-length
1350 packet with end-of-message set and datastream type 255. Finally,
1351 the closing process replies with a zero-length packet with
1354 of how one might handle this three-way handshake at the user
1355 level; in the future, support for this type of close will
1356 probably be provided as part of the C library or as part of
1358 might handle three-way handshake if it sees that the process it
1374 if (((struct sphdr *)buf)->sp_dt == SPPSST_END) {
1385 * Write a zero-length packet with datastream type = SPPSST_ENDREPLY
1388 * from the other side of the connection, with SPPSST_ENDREPLY
1434 reliable and datagram-oriented. This protocol is known as
1436 of IDP. PEX is important for a number of things: Courier
1440 implementation of PEX in the kernel,
1442 and the use of one peculiar \fIgetsockopt\fP. A PEX packet
1447 * The packet-exchange header shown here is not defined
1448 * as part of any of the system include files.
1461 send a packet to me'') protocol. Processes on each side of
1467 amount of time, the packet is retransmitted until it is decided
1469 must be able to generate unique ids -- something that is hard to
1480 /* get id from the kernel -- only on IDP sockets */
1489 One of the daemons provided with 4.4BSD is \fIinetd\fP, the
1490 so called ``internet super-server.''
1492 instead of having each daemon listen for its own requests
1493 reduces the number of idle daemons and simplies their implementation.
1496 two types of services: standard and TCPMUX.
1497 A standard service has a well-known port assigned to it and
1502 BSD-specific service.
1504 well-known port assigned to them.
1507 when a program connects to the "tcpmux" well-known port and specifies
1509 This is useful for adding locally-developed servers.
1527 Servers making use of \fIinetd\fP are considerably simplified,
1528 as \fIinetd\fP takes care of the majority of the IPC work
1537 One call which may be of interest to individuals writing
1539 which returns the address of the peer (process) connected
1540 on the other end of the socket. For example, to log the
1561 services are assigned unique well-known port numbers in the range of
1564 The limited number of ports in this range are
1567 locally-developed protocols without needing an official TCP port assignment.
1568 The TCPMUX protocol described in RFC-1078 is simple:
1571 service name followed by a carriage-return line-feed <CRLF>.
1574 single character indicating positive ("+") or negative ("\-")
1575 acknowledgment, immediately followed by an optional message of
1586 describes the format of TCPMUX entries for \f2inetd.conf\f1.
1610 Here's the portion of the client code that handles the TCPMUX handshake:
1649 case '-':
1657 /* Get rest of data from the server */