Check for SYS/GL during library init. Reason is that
[AROS.git] / workbench / network / stacks / AROSTCP / bsdsocket / api / auto_protocols.c
blob2649f8543cc95e42cbcfd846e9d8d5b7c8096d6b
2 /****** protocols/arp *******************************************************
4 * NAME
5 * arp - Address Resolution Protocol
7 * CONFIG
8 * Any SANA-II device driver using ARP
10 * SYNOPSIS
11 * #include <sys/socket.h>
12 * #include <net/if_arp.h>
13 * #include <netinet/in.h>
15 * s = socket(AF_INET, SOCK_DGRAM, 0);
17 * DESCRIPTION
18 * ARP is a protocol used to dynamically map between Internet
19 * Protocol (IP) and hardware addresses. It can be used by most
20 * the SANA-II network interface drivers. The current
21 * implementation supports only Internet Protocol (and is tested
22 * only with Ethernet). However, ARP is not limited to only that
23 * combination.
25 * ARP caches IP-to-hardware address mappings. When an interface
26 * requests a mapping for an address not in the cache, ARP queues
27 * the message which requires the mapping and broadcasts a
28 * message on the associated network requesting the address
29 * mapping. If a response is provided, the new mapping is cached
30 * and any pending message is transmitted. ARP will queue at most
31 * one packet while waiting for a mapping request to be responded
32 * to; only the most recently transmitted packet is kept.
34 * The address mapping caches are separate for each interface. The
35 * amount of mappings in the cache may be specified with an
36 * IoctlSocket() request.
38 * To facilitate communications with systems which do not use ARP,
39 * IoctlSocket() requests are provided to enter and delete entries
40 * in the IP-to-Ethernet tables.
42 * USAGE
43 * #include <sys/ioctl.h>
44 * #include <sys/socket.h>
45 * #include <net/if.h>
46 * #include <net/if_arp.h>
48 * struct arpreq arpreq;
50 * IoctlSocket(s, SIOCSARP, (caddr_t)&arpreq);
51 * IoctlSocket(s, SIOCGARP, (caddr_t)&arpreq);
52 * IoctlSocket(s, SIOCDARP, (caddr_t)&arpreq);
54 * These three IoctlSocket()s take the same structure as an argument.
55 * SIOCSARP sets an ARP entry, SIOCGARP gets an ARP entry, and SIOCDARP
56 * deletes an ARP entry. These IoctlSocket() requests may be applied to
57 * any socket descriptor (s). The arpreq structure contains:
59 * \* Maximum number of octets in protocol/hw address *\
60 * #define MAXADDRARP 16
62 * \*
63 * * ARP ioctl request.
64 * *\
65 * struct arpreq {
66 * struct sockaddr arp_pa; \* protocol address *\
67 * struct { \* hardware address *\
68 * u_char sa_len; \* actual length + 2 *\
69 * u_char sa_family;
70 * char sa_data[MAXADDRARP];
71 * } arp_ha;
72 * int arp_flags; \* flags *\
73 * };
75 * \* arp_flags and at_flags field values *\
76 * #define ATF_INUSE 0x01 \* entry in use *\
77 * #define ATF_COM 0x02 \* completed entry *\
78 * #define ATF_PERM 0x04 \* permanent entry *\
79 * #define ATF_PUBL 0x08 \* publish entry *\
82 * The interface whose ARP table is manipulated is specified by
83 * arp_pa sockaddr. The address family for the arp_pa sockaddr
84 * must be AF_INET; for the arp_ha sockaddr it must be AF_UNSPEC.
85 * The length of arp_ha must match the length of used hardware
86 * address. Maximum length for the hardware address is MAXADDRARP
87 * bytes. The only flag bits which may be written are ATF_PERM
88 * and ATF_PUBL. ATF_PERM makes the entry permanent if the
89 * IoctlSocket() call succeeds. ATF_PUBL specifies that the ARP
90 * code should respond to ARP requests for the indicated host
91 * coming from other machines. This allows a host to act as an
92 * ARP server which may be useful in convincing an ARP-only
93 * machine to talk to a non-ARP machine.
95 * UNSUPPORTED IN AmiTCP/IP
97 * AmiTCP/IP EXTENSIONS
98 * There is an extension to the standard BSD4.4 ARP ioctl interface to
99 * access the contents of the whole ARP mapping cache. (In the BSD4.4
100 * the static ARP table is accessed via the /dev/kmem.) The SIOCGARPT
101 * ioctl takes the following arptabreq structure as an argument:
103 * \*
104 * * An AmiTCP/IP specific ARP table ioctl request
105 * *\
106 * struct arptabreq {
107 * struct arpreq atr_arpreq; \* To identify the interface *\
108 * long atr_size; \* # of elements in atr_table *\
109 * long atr_inuse; \* # of elements in use *\
110 * struct arpreq *atr_table;
111 * };
113 * The atr_arpreq specifies the used interface. The hardware address
114 * for the interface is returned in the arp_ha field of atr_arpreq
115 * structure.
117 * The SIOCGARPT ioctl reads at most atr_size entries from the cache
118 * into the user supplied buffer atr_table, if it is not NULL. Actual
119 * amount of returned entries is returned in atr_size. The current
120 * amount of cached mappings is returned in the atr_inuse.
122 * The SIOCGARPT ioctl has following usage:
124 * struct arpreq cache[N];
125 * struct arptabreq arptab = { N, 0, cache };
127 * IoctlSocket(s, SIOCGARPT, (caddr_t)&arptabreq);
129 * DIAGNOSTICS
130 * ARP watches passively for hosts impersonating the local host
131 * (that is, a host which responds to an ARP mapping request
132 * for the local host's address).
134 * "duplicate IP address a.b.c.d!!"
135 * "sent from hardware address: %x:%x:...:%x:%x"
137 * ARP has discovered another host on the local network
138 * which responds to mapping requests for its own Internet
139 * address.
141 * BUGS
142 * The ARP is tested only with Ethernet. Other network hardware may
143 * require special ifconfig configuration.
145 * SEE ALSO
146 * inet, netutil/arp, netutil/ifconfig, <net/if_arp.h>
148 * Plummer, Dave, ``An Ethernet Address Resolution Protocol
149 * -or- Converting Network Protocol Addresses to 48.bit Ether-
150 * net Addresses for Transmission on Ethernet Hardware,'' RFC
151 * 826, Network Information Center, SRI International, Menlo
152 * Park, Calif., November 1982. (Sun 800-1059-10)
154 *****************************************************************************
158 /****** protocols/icmp ******************************************************
160 * NAME
161 * icmp - Internet Control Message Protocol
163 * SYNOPSIS
164 * #include <sys/socket.h>
165 * #include <netinet/in.h>
167 * int
168 * socket(AF_INET, SOCK_RAW, proto)
170 * DESCRIPTION
171 * ICMP is the error and control message protocol used by IP and the
172 * Internet protocol family. It may be accessed through a ``raw
173 * socket'' for network monitoring and diagnostic functions. The proto
174 * parameter to the socket call to create an ICMP socket is obtained
175 * from getprotobyname(). ICMP sockets are connectionless, and are
176 * normally used with the sendto() and recvfrom() calls, though the
177 * connect() call may also be used to fix the destination for future
178 * packets (in which case the recv() and send() socket library calls
179 * may be used).
181 * Outgoing packets automatically have an IP header prepended to them
182 * (based on the destination address). Incoming packets are received
183 * with the IP header and options intact.
185 * DIAGNOSTICS
186 * A socket operation may fail with one of the following errors
187 * returned:
189 * [EISCONN] when trying to establish a connection on a socket
190 * which already has one, or when trying to send a
191 * datagram with the destination address specified and
192 * the socket is already connected;
194 * [ENOTCONN] when trying to send a datagram, but no destination
195 * address is specified, and the socket hasn't been
196 * connected;
198 * [ENOBUFS] when the system runs out of memory for an internal
199 * data structure;
201 * [EADDRNOTAVAIL] when an attempt is made to create a socket with a
202 * network address for which no network interface
203 * exists.
205 * SEE ALSO
206 * bsdsocket.library/send(), bsdsocket.library/recv(), inet, ip
208 * HISTORY
209 * The icmp protocol is originally from 4.3BSD.
211 *****************************************************************************
215 /****** protocols/if ********************************************************
217 * NAME
218 * if - Network Interface to SANA-II devices
220 * DESCRIPTION
221 * Each network interface in the AmiTCP/IP corresponds to a path
222 * through which messages may be sent and received. A network
223 * interface usually has a SANA-II device driver associated with it,
224 * though the loopback interface, "lo", do not. The network interface
225 * in the AmiTCP/IP (sana_softc) is superset of the BSD Unix network
226 * interface.
228 * When the network interface is first time referenced, AmiTCP/IP tries
229 * to open the corresponding SANA-II device driver. If successful, a
230 * software interface to the SANA-II device is created. The "network/"
231 * prefix is added to the SANA-II device name, if needed. Once the
232 * interface has acquired its address, it is expected to install a
233 * routing table entry so that messages can be routed through it.
235 * The SANA-II interfaces must be configured before they will allow
236 * traffic to flow through them. It is done after the interface is
237 * assigned a protocol address with a SIOCSIFADDR ioctl. Some
238 * interfaces may use the protocol address or a part of it as their
239 * hardware address. On interfaces where the network-link layer address
240 * mapping is static, only the network number is taken from the ioctl;
241 * the remainder is found in a hardware specific manner. On interfaces
242 * which provide dynamic network-link layer address mapping facilities
243 * (for example, Ethernets or Arcnets using ARP), the entire address
244 * specified in the ioctl is used.
246 * The following ioctl calls may be used to manipulate network
247 * interfaces. Unless specified otherwise, the request takes an ifreq
248 * structure as its parameter. This structure has the form
250 * struct ifreq {
251 * char ifr_name[IFNAMSIZ]; \* interface name (eg. "slip.device/0")*\
252 * union {
253 * struct sockaddr ifru_addr;
254 * struct sockaddr ifru_dstaddr;
255 * short ifru_flags;
256 * } ifr_ifru;
257 * #define ifr_addr ifr_ifru.ifru_addr \* address *\
258 * #define ifr_dstaddr ifr_ifru.ifru_dstaddr \* end of p-to-p link *\
259 * #define ifr_flags ifr_ifru.ifru_flags \* flags *\
260 * };
262 * SIOCSIFADDR Set interface address. Following the address
263 * assignment, the ``initialization'' routine for
264 * the interface is called.
266 * SIOCGIFADDR Get interface address.
268 * SIOCSIFDSTADDR Set point to point address for interface.
270 * SIOCGIFDSTADDR Get point to point address for interface.
272 * SIOCSIFFLAGS Set interface flags field. If the interface is
273 * marked down, any processes currently routing
274 * packets through the interface are notified.
276 * SIOCGIFFLAGS Get interface flags.
278 * SIOCGIFCONF Get interface configuration list. This request
279 * takes an ifconf structure (see below) as a
280 * value-result parameter. The ifc_len field should be
281 * initially set to the size of the buffer pointed to
282 * by ifc_buf. On return it will contain the length,
283 * in bytes, of the configuration list.
285 * \*
286 * * Structure used in SIOCGIFCONF request.
287 * * Used to retrieve interface configuration
288 * * for machine (useful for programs which
289 * * must know all networks accessible).
290 * *\
291 * struct ifconf {
292 * int ifc_len; \* size of associated buffer *\
293 * union {
294 * caddr_t ifcu_buf;
295 * struct ifreq *ifcu_req;
296 * } ifc_ifcu;
297 * #define ifc_buf ifc_ifcu.ifcu_buf \* buffer address *\
298 * #define ifc_req ifc_ifcu.ifcu_req \* array of structures returned *\
299 * };
302 * UNSUPPORTED IN AmiTCP/IP
303 * These standard BSD ioctl codes are not currently supported:
305 * SIOCADDMULTI Enable a multicast address for the interface.
307 * SIOCDELMULTI Disable a previously set multicast address.
309 * SIOCSPROMISC Toggle promiscuous mode.
311 * AmiTCP/IP EXTENSIONS
312 * The following ioctls are used to configure protocol and hardware
313 * specific properties of a sana_softc interface. They are used in the
314 * AmiTCP/IP only.
316 * SIOCSSANATAGS Set SANA-II specific properties with a tag list.
318 * SIOCGSANATAGS Get SANA-II specific properties into a
319 * wiretype_parameters structure and a user tag list.
321 * struct wiretype_parameters
323 * ULONG wiretype; \* the wiretype of the interface *\
324 * WORD flags; \* iff_flags *\
325 * struct TagItem *tags; \* tag list user provides *\
326 * };
328 * SEE ALSO
329 * arp, lo, netutil/arp, netutil/ifconfig, <sys/ioctl.h>, <net/if.h>,
330 * <net/sana2tags.h>
332 *****************************************************************************
336 /****** protocols/inet ******************************************************
338 * NAME
339 * inet - Internet protocol family
341 * SYNOPSIS
342 * #include <sys/types.h>
343 * #include <netinet/in.h>
345 * DESCRIPTION
346 * The Internet protocol family implements a collection of protocols
347 * which are centered around the Internet Protocol (IP) and which share
348 * a common address format. The Internet family provides protocol
349 * support for the SOCK_STREAM, SOCK_DGRAM, and SOCK_RAW socket types.
351 * PROTOCOLS
352 * The Internet protocol family is comprised of the Internet Protocol
353 * (IP), the Address Resolution Protocol (ARP), the Internet Control
354 * Message Protocol (ICMP), the Transmission Control Protocol (TCP),
355 * and the User Datagram Protocol (UDP).
357 * TCP is used to support the SOCK_STREAM abstraction while UDP is used
358 * to support the SOCK_DGRAM abstraction; (SEE ALSO tcp, SEE ALSO udp).
359 * A raw interface to IP is available by creating an Internet socket of
360 * type SOCK_RAW; (SEE ALSO ip). ICMP is used by the kernel to handle
361 * and report errors in protocol processing. It is also accessible to
362 * user programs; (SEE ALSO icmp). ARP is used to translate 32-bit IP
363 * addresses into varying length hardware addresses; (SEE ALSO arp).
365 * The 32-bit IP address is divided into network number and host number
366 * parts. It is frequency-encoded; the most significant bit is zero in
367 * Class A addresses, in which the high-order 8 bits are the network
368 * number. Class B addresses have their high order two bits set to 10
369 * and use the highorder 16 bits as the network number field. Class C
370 * addresses have a 24-bit network number part of which the high order
371 * three bits are 110. Sites with a cluster of local networks may
372 * chose to use a single network number for the cluster; this is done
373 * by using subnet addressing. The local (host) portion of the address
374 * is further subdivided into subnet number and host number parts.
375 * Within a subnet, each subnet appears to be an individual network;
376 * externally, the entire cluster appears to be a single, uniform
377 * network requiring only a single routing entry. Subnet addressing is
378 * enabled and examined by the following ioctl commands on a datagram
379 * socket in the Internet domain; they have the same form as the
380 * SIOCIFADDR (SEE ALSO if) command.
382 * SIOCSIFNETMASK Set interface network mask. The network mask
383 * defines the network part of the address; if it
384 * contains more of the address than the address
385 * type would indicate, then subnets are in use.
387 * SIOCGIFNETMASK Get interface network mask.
389 * ADDRESSING
390 * IP addresses are four byte quantities, stored in network byte order
391 * (the native Amiga byte order)
393 * Sockets in the Internet protocol family use the following
394 * addressing structure:
395 * struct sockaddr_in {
396 * short sin_family;
397 * u_short sin_port;
398 * struct in_addr sin_addr;
399 * char sin_zero[8];
400 * };
402 * Functions in bsdsocket.library are provided to manipulate structures
403 * of this form.
405 * The sin_addr field of the sockaddr_in structure specifies a local or
406 * remote IP address. Each network interface has its own unique IP
407 * address. The special value INADDR_ANY may be used in this field to
408 * effect "wildcard" matching. Given in a bind() call, this value
409 * leaves the local IP address of the socket unspecified, so that the
410 * socket will receive connections or messages directed at any of the
411 * valid IP addresses of the system. This can prove useful when a
412 * process neither knows nor cares what the local IP address is or when
413 * a process wishes to receive requests using all of its network
414 * interfaces. The sockaddr_in structure given in the bind() call must
415 * specify an in_addr value of either IPADDR_ANY or one of the system's
416 * valid IP addresses. Requests to bind any other address will elicit
417 * the error EADDRNOTAVAIL. When a connect() call is made for a socket
418 * that has a wildcard local address, the system sets the sin_addr
419 * field of the socket to the IP address of the network interface that
420 * the packets for that connection are routed via.
422 * The sin_port field of the sockaddr_in structure specifies a port
423 * number used by TCP or UDP. The local port address specified in a
424 * bind() call is restricted to be greater than IPPORT_RESERVED
425 * (defined in <netinet/in.h>) unless the creating process is running
426 * as the super-user, providing a space of protected port numbers. In
427 * addition, the local port address must not be in use by any socket of
428 * same address family and type. Requests to bind sockets to port
429 * numbers being used by other sockets return the error EADDRINUSE. If
430 * the local port address is specified as 0, then the system picks a
431 * unique port address greater than IPPORT_RESERVED. A unique local
432 * port address is also picked when a socket which is not bound is used
433 * in a connect() or send() call. This allows programs which do not
434 * care which local port number is used to set up TCP connections by
435 * sim- ply calling socket() and then connect(), and to send UDP
436 * datagrams with a socket() call followed by a send() call.
438 * Although this implementation restricts sockets to unique local port
439 * numbers, TCP allows multiple simultaneous connections involving the
440 * same local port number so long as the remote IP addresses or port
441 * numbers are different for each connection. Programs may explicitly
442 * override the socket restriction by setting the SO_REUSEADDR socket
443 * option with setsockopt (see getsockopt()).
445 * SEE ALSO
446 * bsdsocket.library/bind(), bsdsocket.library/connect(),
447 * bsdsocket.library/getsockopt(), bsdsocket.library/IoctlSocket(),
448 * bsdsocket.library/send(), bsdsocket.library/socket(),
449 * bsdsocket.library/gethostent(), bsdsocket.library/getnetent(),
450 * bsdsocket.library/getprotoent(), bsdsocket.library/getservent(),
451 * bsdsocket.library/inet_addr(), arp, icmp, ip, tcp, udp
453 * Network Information Center, DDN Protocol Handbook (3 vols.),
454 * Network Information Center, SRI International, Menlo Park,
455 * Calif., 1985.
456 * A AmiTCP/IP Interprocess Communication Primer
458 * WARNING
459 * The Internet protocol support is subject to change as the Internet
460 * protocols develop. Users should not depend on details of the
461 * current implementation, but rather the services exported.
463 *****************************************************************************
467 /****** protocols/ip ********************************************************
469 * NAME
470 * ip - Internet Protocol
472 * SYNOPSIS
473 * #include <sys/socket.h>
474 * #include <netinet/in.h>
476 * int
477 * socket(AF_INET, SOCK_RAW, proto)
479 * DESCRIPTION
480 * IP is the transport layer protocol used by the Internet protocol
481 * family. Options may be set at the IP level when using higher-level
482 * protocols that are based on IP (such as TCP and UDP). It may also be
483 * accessed through a ``raw socket'' when developing new protocols, or
484 * special purpose applica- tions.
486 * A single generic option is supported at the IP level, IP_OPTIONS,
487 * that may be used to provide IP options to be transmitted in the IP
488 * header of each outgoing packet. Options are set with setsockopt()
489 * and examined with getsockopt(). The format of IP options to be sent
490 * is that specified by the IP protocol specification, with one
491 * exception: the list of addresses for Source Route options must
492 * include the first-hop gateway at the beginning of the list of
493 * gateways. The first-hop gateway address will be extracted from the
494 * option list and the size adjusted accordingly before use. IP
495 * options may be used with any socket type in the Internet family.
497 * Raw IP sockets are connectionless, and are normally used with the
498 * sendto and recvfrom calls, though the connect() call may also be
499 * used to fix the destination for future packets (in which case the
500 * recv() and send() system calls may be used).
502 * If proto is 0, the default protocol IPPROTO_RAW is used for outgoing
503 * packets, and only incoming packets destined for that protocol are
504 * received. If proto is non-zero, that protocol number will be used
505 * on outgoing packets and to filter incoming packets.
507 * Outgoing packets automatically have an IP header prepended to them
508 * (based on the destination address and the protocol number the socket
509 * is created with). Incoming packets are received with IP header and
510 * options intact.
512 * DIAGNOSTICS
513 * A socket operation may fail with one of the following errors
514 * returned:
516 * [EISCONN] when trying to establish a connection on a socket
517 * which already has one, or when trying to send a
518 * datagram with the destination address specified and
519 * the socket is already connected;
521 * [ENOTCONN] when trying to send a datagram, but no destination
522 * address is specified, and the socket hasn't been
523 * connected;
525 * [ENOBUFS] when the system runs out of memory for an internal
526 * data structure;
528 * [EADDRNOTAVAIL] when an attempt is made to create a socket with a
529 * network address for which no network interface
530 * exists.
532 * The following errors specific to IP may occur when setting or
533 * getting IP options:
535 * [EINVAL] An unknown socket option name was given.
537 * [EINVAL] The IP option field was improperly formed; an
538 * option field was shorter than the minimum value or
539 * longer than the option buffer provided.
541 * SEE ALSO
542 * bsdsocket.library/getsockopt(), bsdsocket.library/send(),
543 * bsdsocket.library/recv(), icmp, inet
545 * HISTORY
546 * The ip protocol appeared in 4.2BSD.
548 *****************************************************************************
552 /****** protocols/lo ********************************************************
554 * NAME
555 * lo - Software Loopback Network Interface
557 * SYNOPSIS
558 * pseudo-device
559 * loop
561 * DESCRIPTION
562 * The loop interface is a software loopback mechanism which may be
563 * used for performance analysis, software testing, and/or local
564 * communication. There is no SANA-II interface associated with lo.
565 * As with other network interfaces, the loopback interface must have
566 * network addresses assigned for each address family with which it is
567 * to be used. These addresses may be set or changed with the
568 * SIOCSIFADDR ioctl. The loopback interface should be the last
569 * interface configured, as protocols may use the order of
570 * configuration as an indication of priority. The loopback should
571 * never be configured first unless no hardware interfaces exist.
573 * DIAGNOSTICS
574 * "lo%d: can't handle af%d."
575 * The interface was handed a message with ad- dresses formatted in an
576 * unsuitable address family; the packet was dropped.
578 * SEE ALSO
579 * inet, if, netutil/ifconfig
581 * BUGS
582 * Older BSD Unix systems enabled the loopback interface
583 * automatically, using a nonstandard Internet address (127.1). Use
584 * of that address is now discouraged; a reserved host address for the
585 * local network should be used instead.
587 *****************************************************************************
591 /****** protocols/routing ***************************************************
593 * NAME
594 * routing - system supporting for local network packet routing
596 * DESCRIPTION
597 * The network facilities provided general packet routing,
598 * leaving routing table maintenance to applications processes.
600 * A simple set of data structures comprise a ``routing table''
601 * used in selecting the appropriate network interface when
602 * transmitting packets. This table contains a single entry for
603 * each route to a specific network or host. A user process, the
604 * routing daemon, maintains this data base with the aid of two
605 * socket specific ioctl commands, SIOCADDRT and SIOCDELRT.
606 * The commands allow the addition and deletion of a single
607 * routing table entry, respectively. Routing table
608 * manipulations may only be carried out by super-user.
610 * A routing table entry has the following form, as defined in
611 * <net/route.h>:
612 * struct rtentry {
613 * u_long rt_hash;
614 * struct sockaddr rt_dst;
615 * struct sockaddr rt_gateway;
616 * short rt_flags;
617 * short rt_refcnt;
618 * u_long rt_use;
619 * struct ifnet *rt_ifp;
620 * };
621 * with rt_flags defined from:
622 * #define RTF_UP 0x1 \* route usable *\
623 * #define RTF_GATEWAY 0x2 \* destination is a gateway *\
624 * #define RTF_HOST 0x4 \* host entry (net otherwise) *\
626 * Routing table entries come in three flavors: for a specific
627 * host, for all hosts on a specific network, for any destination
628 * not matched by entries of the first two types (a wildcard
629 * route). When the system is booted, each network interface
630 * autoconfigured installs a routing table entry when it wishes
631 * to have packets sent through it. Normally the interface
632 * specifies the route through it is a ``direct'' connection to
633 * the destination host or network. If the route is direct, the
634 * transport layer of a protocol family usually requests the
635 * packet be sent to the same host specified in the packet.
636 * Otherwise, the interface may be requested to address the
637 * packet to an entity different from the eventual recipient
638 * (that is, the packet is forwarded).
640 * Routing table entries installed by a user process may not
641 * specify the hash, reference count, use, or interface fields;
642 * these are filled in by the routing routines. If a route is in
643 * use when it is deleted (rt_refcnt is non-zero), the resources
644 * associated with it will not be reclaimed until all references
645 * to it are removed.
647 * The routing code returns EEXIST if requested to duplicate an
648 * existing entry, ESRCH if requested to delete a non-existent
649 * entry, or ENOBUFS if insufficient resources were available to
650 * install a new route.
652 * The rt_use field contains the number of packets sent along the
653 * route. This value is used to select among multiple routes to
654 * the same destination. When multiple routes to the same
655 * destination exist, the least used route is selected.
657 * A wildcard routing entry is specified with a zero destination
658 * address value. Wildcard routes are used only when the system
659 * fails to find a route to the destination host and network.
660 * The combination of wildcard routes and routing redirects can
661 * provide an economical mechanism for routing traffic.
663 * SEE ALSO
664 * bsdsocket.library/IoctlSocket(), netutil/route
666 *****************************************************************************
670 /****** protocols/tcp *******************************************************
672 * NAME
673 * tcp - Internet Transmission Control Protocol
675 * SYNOPSIS
676 * #include <sys/socket.h>
677 * #include <netinet/in.h>
679 * int
680 * socket(AF_INET, SOCK_STREAM, 0)
682 * DESCRIPTION
683 * The TCP protocol provides reliable, flow-controlled, two-way
684 * transmission of data. It is a byte-stream protocol used to support
685 * the SOCK_STREAM abstraction. TCP uses the standard Internet address
686 * format and, in addition, provides a per-host collection of ``port
687 * addresses''. Thus, each address is composed of an Internet address
688 * specifying the host and network, with a specific TCP port on the
689 * host identifying the peer entity.
691 * Sockets utilizing the tcp protocol are either ``active'' or
692 * ``passive''. Active sockets initiate connections to passive
693 * sockets. By default TCP sockets are created active; to create a
694 * passive socket the listen() bsdsocket.library function call must be
695 * used after binding the socket with the bind() bsdsocket.library
696 * function call. Only passive sockets may use the accept() call to
697 * accept incoming connections. Only active sockets may use the
698 * connect() call to initiate connections.
700 * Passive sockets may ``underspecify'' their location to match
701 * incoming connection requests from multiple networks. This
702 * technique, termed ``wildcard addressing'', allows a single server to
703 * provide service to clients on multiple networks. To create a socket
704 * which listens on all networks, the Internet address INADDR_ANY must
705 * be bound. The TCP port may still be specified at this time; if the
706 * port is not specified the bsdsocket.library function will assign
707 * one. Once a connection has been established the socket's address is
708 * fixed by the peer entity's location. The address assigned the
709 * socket is the address associated with the network interface through
710 * which packets are being transmitted and received. Normally this
711 * address corresponds to the peer entity's network.
713 * TCP supports one socket option which is set with setsockopt() and
714 * tested with getsockopt(). Under most circumstances, TCP sends data
715 * when it is presented; when outstanding data has not yet been
716 * acknowledged, it gathers small amounts of output to be sent in a
717 * single packet once an acknowledgement is received. For a small
718 * number of clients, such as X Window System functions that
719 * send a stream of mouse events which receive no replies, this
720 * packetization may cause significant delays. Therefore, TCP provides
721 * a boolean option, TCP_NODELAY (from <netinet/tcp.h>, to defeat this
722 * algorithm. The option level for the setsockopt call is the protocol
723 * number for TCP, available from getprotobyname().
725 * Options at the IP transport level may be used with TCP; SEE ALSO ip.
726 * Incoming connection requests that are source-routed are noted, and
727 * the reverse source route is used in responding.
729 * DIAGNOSTICS
730 * A socket operation may fail with one of the following errors
731 * returned:
733 * [EISCONN] when trying to establish a connection on a socket
734 * which already has one;
736 * [ENOBUFS] when the AmiTCP/IP runs out of memory for an internal
737 * data structure;
739 * [ETIMEDOUT] when a connection was dropped due to excessive
740 * retransmissions;
742 * [ECONNRESET] when the remote peer forces the connection to be
743 * closed;
745 * [ECONNREFUSED] when the remote peer actively refuses connection
746 * establishment (usually because no process is
747 * listening to the port);
749 * [EADDRINUSE] when an attempt is made to create a socket with a
750 * port which has already been allocated;
752 * [EADDRNOTAVAIL] when an attempt is made to create a socket with a
753 * network address for which no network interface
754 * exists.
756 * SEE ALSO
757 * bsdsocket.library/getsockopt(), bsdsocket.library/socket(),
758 * bsdsocket.library/bind(), bsdsocket.library/listen(),
759 * bsdsocket.library/accept(), bsdsocket.library/connect(), inet,
760 * ip, <sys/socket.h>, <netinet/tcp.h>, <netinet/in.h>
762 * HISTORY
763 * The tcp protocol stack appeared in 4.2BSD.
765 *****************************************************************************
769 /****** protocols/udp *******************************************************
771 * NAME
772 * udp - Internet User Datagram Protocol
774 * SYNOPSIS
775 * #include <sys/socket.h>
776 * #include <netinet/in.h>
778 * int
779 * socket(AF_INET, SOCK_DGRAM, 0)
781 * DESCRIPTION
782 * UDP is a simple, unreliable datagram protocol which is used to
783 * support the SOCK_DGRAM abstraction for the Internet protocol family.
784 * UDP sockets are connectionless, and are normally used with the
785 * sendto() and recvfrom() calls, though the connect() call may also be
786 * used to fix the destination for future packets (in which case the
787 * recv() and send() function calls may be used).
789 * UDP address formats are identical to those used by TCP. In
790 * particular UDP provides a port identifier in addition to the normal
791 * Internet address format. Note that the UDP port space is separate
792 * from the TCP port space (i.e. a UDP port may not be ``connected'' to
793 * a TCP port). In addition broadcast packets may be sent (assuming the
794 * underlying network supports this) by using a reserved ``broadcast
795 * address''; this address is network interface dependent.
797 * Options at the IP transport level may be used with UDP; SEE ALSO ip.
799 * DIAGNOSTICS
800 * A socket operation may fail with one of the following errors
801 * returned:
803 * [EISCONN] when trying to establish a connection on a socket
804 * which already has one, or when trying to send a
805 * datagram with the destination address specified and
806 * the socket is already connected;
808 * [ENOTCONN] when trying to send a datagram, but no destination
809 * address is specified, and the socket hasn't been
810 * connected;
812 * [ENOBUFS] when the system runs out of memory for an
813 * internal data structure;
815 * [EADDRINUSE] when an attempt is made to create a socket with a
816 * port which has already been allocated;
818 * [EADDRNOTAVAIL] when an attempt is made to create a socket with a
819 * network address for which no network interface
820 * exists.
822 * SEE ALSO
823 * bsdsocket.library/getsockopt(), bsdsocket.library/recv(),
824 * bsdsocket.library/send(), bsdsocket.library/socket(), inet, ip
826 * HISTORY
827 * The udp protocol appeared in 4.2BSD.
829 *****************************************************************************