Lines Matching +full:send +full:- +full:flush +full:- +full:out +full:- +full:sequence
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
49 of band\*(rq data. Out of band data is a logically independent
51 stream sockets. Out of band data is delivered to the user
53 The abstraction defines that the out of band data facilities
58 support only in-band signaling (i.e. the urgent data is
59 delivered in sequence with the normal data), the system normally extracts
62 in order and receiving it out of sequence without having to
64 to ``peek'' (via MSG_PEEK) at out of band data.
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
85 To send an out of band message the MSG_OOB flag is supplied to
86 a \fIsend\fP or \fIsendto\fP calls,
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;
112 /* flush local terminal output */
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
141 With such protocols, the out-of-band byte may not yet have arrived
144 Worse, there may be enough in-band data in the input buffer
153 This treatment is available as a socket-level option, SO_OOBINLINE;
159 but no out-of-band data are lost.
161 Non-Blocking 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.
190 In particular, \fIaccept\fP, \fIconnect\fP, \fIsend\fP, \fIrecv\fP,
194 If an operation such as a \fIsend\fP cannot be done in its entirety,
311 the network do so through a \fIpseudo-terminal\fP. A pseudo-
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
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.
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
364 pseudo-terminals is given in Figure 8; this code assumes
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';
433 lower-level protocols or hardware interfaces,
449 s = socket(AF_INET, SOCK_STREAM, pp->p_proto);
473 allocated out of separate spaces, one for each system and one
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;
609 In addition, there are protocol-specific options for IP and TCP,
637 a value-result parameter, initially set to the size of
667 By using a datagram socket, it is possible to send broadcast
673 the ability to send broadcast packets has been limited
684 To send a broadcast message, a datagram socket
722 be obtained in a host-independent fashion and may be impossible
762 #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
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)
819 done via the SIOCGIFBRDADDR \fIioctl\fP, while for point-to-point networks
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));
846 broadcast or point-to-point addressing.
847 If a process only wished to send broadcast
854 a message is allowed to go out.
861 members of its destination host group with the same "best-efforts"
870 of a group to send datagrams to it.
873 well-known, administratively assigned IP address. It is the address,
884 higher-level identifiers or authentication tokens. Information
893 The next subsections describe how to send and receive multicast datagrams.
897 To send a multicast datagram, specify an IP multicast address in the range
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,
920 to the first-hop subnet. To provide meaningful scope control, the multicast
943 For example, an application might perform an "expanding-ring search" for a
946 the TTL sequence 0, 1, 2, 4, 8, 16, 32.
953 reserved for the use of routing protocols and other low-level topology
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
1033 host's local addresses to choose a particular (multicast-capable) interface.
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
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.
1129 if (argc > 1) { /* Send */
1133 sprintf(message, "time is %-24.24s", ctime(&t));
1172 .\"----------------------------------------------------------------------
1194 #define SP_SA 0x40 /* send acknowledgement */
1195 #define SP_OB 0x20 /* attention (out of band data) */
1200 u_short sp_seq; /* sequence number */
1212 set or clear the end-of-message bit to indicate
1215 indicate that a packet should be sent out-of-band.
1237 buf.proto_spp.sp_cc = SP_EM; /* end-of-message */
1268 The header of an IDP-level packet looks like:
1321 must be filled in correctly in order for the socket to send and
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
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
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
1416 write(s, buf, 0); /* send the end request */
1422 * that the other side will send the
1423 * ENDREPLY, so we'll just send our final ENDREPLY
1434 reliable and datagram-oriented. This protocol is known as
1447 * The packet-exchange header shown here is not defined
1460 fact that it is an idempotent (``I send a packet to you, you
1461 send a packet to me'') protocol. Processes on each side of
1469 must be able to generate unique ids -- something that is hard to
1480 /* get id from the kernel -- only on IDP sockets */
1490 so called ``internet super-server.''
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.
1532 any operations such as \fIread\fP, \fIwrite\fP, \fIsend\fP,
1561 services are assigned unique well-known port numbers in the range of
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 ("\-")
1623 /* Send service request */
1649 case '-':