═══ 1. About This Information ═══ This IBM TCP/IP for OS/2 Warp Programming Reference describes the routines for application programming in the TCP/IP for OS/2 Warp environment on a workstation. This section describes:  Primary users of this information  Content of each major information division  Conventions used in this information  New functions in this information  Where to find more information ═══ 1.1. Who Should Use This Information ═══ This information is intended for application and system programmers with experience in writing application programs on a workstation. You should also be familiar with the OS/2 operating system and know multitasking operating system concepts. It is important that you also know the C programming language. If you are not familiar with TCP/IP concepts, see Internetworking With TCP/IP Volume I: Principles, Protocols, and Architecture , and Internetworking With TCP/IP Volume II: Implementation and Internals. ═══ 1.2. What This Information Describes ═══ This document contains guidance and reference information about the following topics. Guidance Information  Sockets General Programming Information Describes the TCP/IP socket interface and how to use the socket routines in a user-written application.  Sockets in the Internet Domain Describes TCP/IP network protocols, getting started with sockets in the Internet domain, Internet address formats, and TCP/IP-specific network utility routines.  Sockets over Local IPC Describes how programmers can communicate on the same machine using the sockets API, and the local IPC address format.  Sockets over NetBIOS Describes how programmers can communicate with NetBIOS using the sockets API, and the NetBIOS address format.  Windows Sockets Version 1.1 for OS/2 Presents information for implementing the Winsock 1.1 API for OS/2 applications.  Remote Procedure Calls Describes the remote procedure calls and how to use them in a user-written application.  File Transfer Protocol Describes the file transfer protocol routines and how to use them in a user-written application.  Resource ReSerVation Protocol Describes the resource reservation protocol routines and how to use them in a user-written application. Reference Information  Protocol-Independent C Sockets API Describes the protocol-independent socket calls supported by networking services. This information includes call syntax, usage, and related information.  TCP/IP Network Utility Routines API Describes the sockets utility and Sockets Secure Support (SOCKS) function calls supported by networking services. This information includes call syntax, usage, and related information.  Remote Procedure and eXternal Data Representation API Describes the remote procedure and XDR function calls along with their syntax, usage, and related information.  File Transfer Protocol API Describes the file transfer protocol function calls along with their syntax, usage, and related information.  Resource ReSerVation Protocol API Describes the resource reservation protocol function calls along with their syntax, usage, and related information. Appendixes  NETWORKS File Structure Provides examples of network names contained in the TCPIP\ETC\NETWORKS file.  Socket Error Constants Provides the socket error codes and descriptions.  Well-Known Port Assignments Provides a list of the well-known ports supported by TCP/IP.  Notices Contains copyright notices, disclaimers, and trademarks relating to TCP/IP for OS/2 Warp. This information also includes index and search functions, which are available using the push buttons at the bottom of the information window. ═══ 1.3. Conventions Used in This Information ═══ How the Term "Internet" Is Used An internet is a logical collection of networks supported by gateways, routers, bridges, hosts, and various layers of protocols that permit the network to function as a large, virtual network. The term internet is used as a generic term for a TCP/IP network and should not be confused with the Internet (note capital I), which consists of large national backbone networks (such as MILNET, NSFNet, and CREN) and myriad regional and local campus networks all over the world. ═══ 1.4. What Is New in This Information ═══ Changes have been made for two versions of TCP/IP for OS/2  If you have upgraded from TCP/IP for OS/2 Warp Server or OS/2 Warp Server SMP, read Changes in Version 4 (Merlin) plus Changes in Version 4.1.  If you have upgraded from TCP/IP for OS/2 Version 4 (Merlin), read Changes in Version 4.1. ═══ 1.4.1. Changes in Version 4 (Merlin) ═══ This edition reorganizes the information from the previous edition into guidance and reference sections, adds substantially to the sockets guidance material in Sockets General Programming Information and Sockets in the Internet Domain, and also adds the following function calls. In Protocol-Independent C Sockets API: addsockettolist() removesocketfromlist() In TCP/IP Network Utility Routines API: dn_find() dn_skipname() _getlong() _getshort() h_errno putlong() putshort() Raccept() Rbind() Rconnect() res_query() res_querydomain() res_search() rexec() Rgethostbyname() Rgetsockname() Rlisten() In addition, the os2_connect() and os2_gethostbyname() calls have been removed; see connect() and gethostbyname() instead. ═══ 1.4.2. Changes in Version 4.1 ═══ The Resource ReSerVation Protocol (RSVP) is added. See Resource ReSerVation Protocol Resource ReSerVation Protocol API Support for Berkley Software Distribution (BSD) Version 4.4 is added. In Protocol-Independent C Sockets API, changes were made to getsockopt(), ioctl(), and setsockopt(). os2_ioctl() and sysctl() were added. The select() call was split into os2_select() for OS/2 and select() for BSD. sock_init() was deleted. In TCP/IP Network Utility Routines API, bswap(), lswap() and tcp_h_errno() were deleted. In File Transfer Protocol API, additions were made to the host parameter to allow you to specify the port number used by the FTP server. ═══ 1.5. For More Information ═══ You may purchase this information in printed form by ordering IBM publication number SC31-8407. U.S. customers can order by calling IBM Software Manufacturing Solutions at 1-800-879-2755. Outside the U.S., customers should contact the IBM branch office serving their locality. Book files for printing or online viewing are available on the World Wide Web at http://www.raleigh.ibm.com/tcp/tcpprod.html. ═══ 2. Guidance Information ═══ This section describes:  Sockets General Programming Information Describes the TCP/IP socket interface and how to use the socket routines in a user-written application.  Sockets in the Internet Domain Describes TCP/IP network protocols, getting started with sockets in the Internet domain, Internet address formats, and TCP/IP-specific network utility routines.  Sockets over Local IPC Describes how programmers can communicate on the same machine using the sockets API, and the local IPC address format.  Sockets over NetBIOS Describes how programmers can communicate with NetBIOS using the sockets API, and the NetBIOS address format.  Windows Sockets Version 1.1 for OS/2 Presents information for implementing the Winsock 1.1 API for OS/2 applications.  Remote Procedure Calls Describes the remote procedure calls and how to use them in a user-written application.  File Transfer Protocol Describes the file transfer protocol routines and how to use them in a user-written application.  Resource ReSerVation Protocol Describes the resource reservation protocol routines and how to use them to ensure that some quality of service can be reserved for sending and receiving on the network. ═══ 3. Sockets General Programming Information ═══ This section contains technical information for planning, designing, and writing application programs that use the sockets application programming interface (API) in a TCP/IP Version 4.1 for OS/2 Warp environment. Topics Introduction to Networking Services Sockets Overview Socket Protocol Families Socket Addresses Socket Types Socket Creation Binding Names to Sockets Socket Connections Obtaining Socket Addresses Server Connections Connectionless Datagram Services Socket Options Socket Data Transfer Socket Shutdown Typical Socket Session Diagrams TCP Extensions for Transactions (T/TCP) TCP Extensions for High Performance (RFC 1323) High Performance Send Passing Sockets Between Processes Multithreading Considerations Accessing a TCP/IP API DLL from an Intermediate DLL Differences between OS/2 and Standard BSD Sockets Compiling and Linking a Sockets API Application Example Programs ═══ 3.1. Introduction to Networking Services ═══ OS/2 Warp has integrated networking services that provide a 32-bit sockets API for the:  Internet (TCP/IP) domain  NetBIOS communication domain  Local interprocess communication (Local IPC) domain The sockets API lets you write distributed or client/server applications using TCP/IP or NetBIOS to communicate across networks. The API also allows interprocess communication within a single workstation. OS/2 Warp's sockets API is based on the Berkeley Software Distribution (BSD) Version 4.4 sockets implementation. The OS/2 Warp operating system's networking services consists of three layers:  The sockets layer  The protocol layer  The device layer The sockets layer supplies the interface between the calls and lower layers, the protocol layer contains the protocol stacks used for communication, and the device layer contains the device drivers that control the network devices. The following figure illustrates the relationship between the layers: Client/Server Model Processes communicate using the client/server model. In this model, a server process acting as one endpoint of a two-way communication path listens to a socket. At the other end a client process communicates to the server process through another socket. The client process can be on the same machine or on a different machine from the server process. The protocol stack(s) on the machine(s) maintains internal connections, and routes data between the client and server. The following figure describes the OS/2 Warp kernel and internal structure of TCP/IP Version 4.1 for OS/2 Warp. Internal Structure of TCP/IP The major components of the OS/2 TCP/IP stack are: Control Program CNTRL.EXE provides threads to run the TCP/IP stack. It provides a thread for each of the following:  IP input processing  TCP slow timeout processing  Debug thread for IP  ARP timeout processing  NDIS debug thread  Watchdog thread for the adapter status  Loopback IP packets processing CNTRL.EXE is normally started from CONFIG.SYS with a RUN=statement. It should be the first program to begin executing when TCP/IP is started. Sockets Layer The sockets layer comprises the dynamic link libraries for the different categories of applications, and the device drivers.  DLLs: TCPIP32.DLL exports the 32-bit BSD Version 4.4 sockets API to applications. TCP32DLL.DLL and SO32DLL.DLL export the 32-bit BSD Version 4.3 sockets API to applications. All three of these DLLs are thread-reentrant. TCPIPDLL.DLL provides the sockets APIs for 16-bit applications.  Device driver: SOCKETS.SYS provides the common sockets layer for the protocol stacks. Calls written to the sockets API first pass through SOCKETS.SYS, which routes the call to the correct protocol stack. The socket address families supported are AF_OS2 (or equivalently, AF_UNIX), AF_INET, and AF_NETBIOS (or equivalently, AF_NB). Protocol Layer The protocol layer holds the device drivers. AFOS2.SYS is the Local Interprocess Communication (LIPC) device driver. This driver supports AF_OS2 and AF_UNIX socket types. These socket types can be used by applications within one OS/2 machine to communicate with each other. AFNB.SYS device driver provides support for sockets over NetBIOS. This driver supports applications written using the AF_NETBIOS or AF_NB socket type. AFINET.SYS is the transport protocol device driver for the AF_INET socket type. AFINET.SYS is essentially TCP/IP code. It is compliant with NDIS version 2.0.1; any MAC driver written to that specification should work with the stack. SLIP, PPP, X25, and SNAlink use a special interface in this driver to their respective hardware. ═══ 3.2. Sockets Overview ═══ This section provides some background information about the OS/2 Warp sockets API, defines it in more detail, and describes its basic functions. Topics Sockets Background What Is a Socket? Socket Facilities ═══ 3.2.1. Sockets Background ═══ The sockets API was developed in response to the need for sophisticated interprocess communication facilities to meet the following goals:  Provide access to communications networks such as an internet  Enable communication between unrelated processes, which can either reside locally on the same host computer or on multiple host machines The sockets API provides a generic interface that allows networking applications to use any protocol stack. After you pick the protocol stack, you can choose the type of socket that you want, based on the communication characteristics that you desire. For example, stream sockets offer a reliable method of data transmission without message boundaries, whereas datagram sockets offer message boundaries but do not guarantee reliability. ═══ 3.2.2. What Is a Socket? ═══ A socket is a communication channel that enables unrelated processes to exchange data locally and across networks. A single socket is one endpoint of a full-duplex (two-way) communication channel. This means that data can be transmitted and received simultaneously. From an application program perspective, a socket is a resource allocated by the operating system, similar to a file handle. It is represented by an unsigned integer called a socket descriptor. A pair of sockets is used to communicate between processes on a single workstation or different workstations. Each socket of the pair is used by its own process to send and receive data with the other socket. When a socket is created, it is associated with a particular protocol stack (called the protocol family) and socket type within that family. Communication can occur only between sockets that use the same socket type within the same protocol family. ═══ 3.2.3. Socket Facilities ═══ Socket calls and network library calls provide the building blocks for IPC. An application program must perform the basic functions, described in the following sections, to conduct IPC through the sockets layer. Topics Creating and Binding Sockets Accepting and Initiating Socket Connections Sending and Receiving Data Shutting Down Socket Operations Translating Network Addresses ═══ 3.2.3.1. Creating and Binding Sockets ═══ A socket is created with the socket() call. This call creates a socket of a specified:  protocol family  socket type  protocol Sockets have different qualities depending on these specifications. The protocol family specifies the protocol stack to be used with the created socket. The socket type defines its communication properties such as reliability, ordering, and prevention of duplication of messages (see Socket Types). The protocol specifies which network protocol to use within the domain. The protocol must support the characteristics requested by the socket type. An application can use the bind() call to associate a local name (usually a network address) with a socket. The form and meaning of socket addresses are dependent on the protocol family in which the socket is created. The socket name is specified by a sockaddr structure. The bind() call is optional under some circumstances: the connect() call and any of the data transmission calls (for example, send()) will automatically associate the local name to the socket if bind() hasn't been called. ═══ 3.2.3.2. Accepting and Initiating Socket Connections ═══ Sockets can be connected or unconnected. Unconnected sockets are produced by the socket() call. An unconnected socket can become a connected socket by:  Client application: Actively connecting to another socket, using the connect() call  Server application: Binding a name to the socket, and then listening for and accepting a connection from another socket, using the listen() and accept() calls. Stream sockets require a connection before you can transfer data. Other types of sockets, such as datagram sockets, need not establish connections before use. ═══ 3.2.3.3. Sending and Receiving Data ═══ The sockets API includes a variety of calls for transferring data. They all operate similarly, but take different parameters to support different levels of functionality. Some socket calls support scatter-gather communication. Some support only connected sockets while others will work on any socket. Some calls support additional flags to control how data is sent or received. See Data Transfer Calls for a summary of which calls support which options. ═══ 3.2.3.4. Shutting Down Socket Operations ═══ Once sockets are no longer of use they can be shut down or closed using the shutdown() or soclose() call. Typically, the shutdown() call is used if you want to shut down data transfer in one direction while keeping the other direction open. The soclose() call shuts down data transfer in both directions and then releases the resources associated with the socket. ═══ 3.2.3.5. Translating Network Addresses ═══ Application programs need to translate human-readable addresses into the low-level form used by the protocol. The sockets API includes calls to:  Map host names to IP addresses and back  Map network names to numbers and back  Map service and protocol names to numbers and back  Convert numbers from network-byte order (big-endian) to host-byte order (which is little-endian on OS/2 machines) and back ═══ 3.3. Socket Protocol Families ═══ Sockets that share common communication properties, such as naming conventions and address formats, are grouped into protocol families. A protocol family includes the following:  Rules for manipulating and interpreting network addresses  A collection of related address formats that comprise an address family  A set of network protocols Topics Supported Protocol Families Local IPC Properties TCP/IP Properties NetBIOS Domain Properties ═══ 3.3.1. Supported Protocol Families ═══ The supported domains' protocol families are defined in the header file and are listed in the following table: Protocol Families Supported ┌───────────────────────────────────────────────────────────────────┐ │Protocol #define in Supported Supported Socket│ │Family Protocols Types │ ├───────────────────────────────────────────────────────────────────┤ │TCP/IP PF_INET ICMP, IP, TCP, Datagram, raw, │ │ UDP stream │ ├───────────────────────────────────────────────────────────────────┤ │Local IPC PF_OS2 or PF_UNIX Local IPC Datagram, stream│ ├───────────────────────────────────────────────────────────────────┤ │NetBIOS PF_NETBIOS or NetBIOS Datagram, │ │ PF_NB sequenced packet│ └───────────────────────────────────────────────────────────────────┘ As the table indicates, some socket types can be used in more than one protocol family. ═══ 3.3.2. TCP/IP Properties ═══ Provides socket communication between a local process and a process running on a remote host. The SOCK_STREAM socket type is supported by TCP (Transmission Control Protocol); the SOCK_DGRAM socket type is supported by UDP (User Datagram Protocol). Each is layered on top of the transport-level Internet Protocol (IP). ICMP (Internet Control Message Protocol) is implemented on top of IP and is accessible through a raw socket. The raw socket interface, SOCK_RAW sockets, allows access to the raw facilities of IP. Each raw socket is associated with one IP protocol number and receives all traffic for that protocol. This allows administrative and debugging functions to occur and enables user-level implementations of special-purpose protocols such as inter-gateway routing protocols. ═══ 3.3.3. Local IPC Properties ═══ Provides socket communication between processes running on the same machine. The SOCK_STREAM socket type provides pipe-like facilities, while the SOCK_DGRAM socket type provides reliable message-style communications. ═══ 3.3.4. NetBIOS Domain Properties ═══ Provides connection-oriented, reliable , full-duplex service to an application. SOCK_SEQPACKET provides reliable message-style communications, while SOCK_DGRAM provides a connectionless mode of communications. ═══ 3.4. Socket Addresses ═══ Sockets can be named with an address so that processes can connect to them. The sockets layer treats an address as an opaque object. Applications supply and receive addresses as tagged, variable-length byte strings. A sockaddr data structure can be used as a template for referring to the identifying tag of each socket address. Topics Socket Address Data Structures Socket Addresses in TCP/IP Connection Modes ═══ 3.4.1. Socket Address Data Structures ═══ The sockaddr data structure is used to provide a generic name for a socket. The following figure illustrates this data structure: sockaddr Structure The file contains this data structure. The sa_len field specifies how long the address is; this field is only used with routing sockets. The family (sa_family) identifies which protocol family this address corresponds to. The contents of the socket address data (sa_data) field depend on the protocol in use. Additional data structures are defined that correspond to a particular protocol family and overlay the sockaddr structure. The types of socket address data structures are as follows: Socket Address Data Structures ┌────────────────────────────────────────────────────────────────────┐ │Data Structure sa_family Value Protocol Header File │ ├────────────────────────────────────────────────────────────────────┤ │struct sockaddr_in AF_INET TCP/IP │ ├────────────────────────────────────────────────────────────────────┤ │struct sockaddr_un AF_OS2 or Local IPC │ │ AF_UNIX │ ├────────────────────────────────────────────────────────────────────┤ │struct sockaddr_nb AF_NETBIOS or NetBIOS │ │ AF_NB │ └────────────────────────────────────────────────────────────────────┘ The contents of the various socket addresses are as follows: Internet A socket name in the internet domain is an internet address, made up of a 32-bit IP address and a 16-bit port number. The 32-bit address is composed of network and host parts; the network part is variable in size. The host part can be interpreted optionally as a subnet field plus the host on a subnet; this is enabled by setting a network address mask. OS/2 or UNIX A socket name in the OS/2 or UNIX domain is a unique listing of ASCII characters of up to 108 bytes. NetBIOS A socket name in the NetBIOS domain is made up of a 16-byte NetBIOS name and is used as is. ═══ 3.4.2. Socket Addresses in TCP/IP ═══ TCP/IP provides a set of 16-bit port numbers within each host. Because each host assigns port numbers independently, it is possible for sockets on different hosts to have the same port number. To ensure that socket addresses are unique within a network, TCP/IP concatenates the internet address of the LAN interface with the port number to devise the internet socket address. Since a host's internet address is always unique within a network, the socket address for a particular socket on a particular host is unique. Additionally, since each connection is fully specified by the pair of sockets it joins, every connection between internet hosts is also uniquely identified. The port numbers from 0 to 1023 are reserved for official internet services. Port numbers in the range of 1024-49151 are reserved for other registered services that are common on internet networks. These port numbers are listed in the ETC\SERVICES file. When a client process needs one of these well-known services at a particular host, the client process sends a service request to the socket address for the well-known port at the server. The port numbers from 49152 to 65535 are generally used by client processes which need a port, but don't care which one they get. These port numbers are usually assigned by the TCP/IP stack when a connect() or sendto() is performed without having done a previous bind(). ═══ 3.4.3. Connection Modes ═══ A connection mode refers to an established logical channel for the transmission of data between two application programs. The sockets API supports two connection modes:  Connection-oriented  Connectionless In the connectionless mode, sockets are not tied to a destination address. Applications sending messages can specify a different destination address for each datagram, if necessary, or they can tie the socket to a specific destination address for the duration of the connection. The connection-oriented mode requires a logical connection to be established between two applications before data transfer or communication can occur. Applications encounter some overhead during the connection establishment phase as the applications negotiate the connection request. This mode is useful for applications that use long datastream transmissions or require reliable transmissions of data. The connectionless mode does not require a logical connection to allow communication between applications. Rather, individual messages are transmitted independently from one application to another application. Each message must contain the data and all information required for delivery of the message to its destination. Normally, datagram and raw socket types use the connectionless mode. The term connected refers to two endpoints that have an established logical connection between them. Stream and sequenced packet socket types use the connection-oriented mode. For information on how datagram and raw socket types can be connected, see Datagram or Raw Sockets. ═══ 3.5. Socket Types ═══ Sockets are classified according to communication properties. Processes usually communicate between sockets of the same type. However, if the underlying communication protocols support the communication, sockets of different types can communicate. Each socket has an associated type, which describes the semantics of communications using that socket. The socket type determines the socket communication properties such as reliability, ordering, and prevention of duplication of messages. The basic set of socket types is defined in the file: /*Standard socket types */ #define SOCK_STREAM 1 /*virtual circuit*/ #define SOCK_DGRAM 2 /*datagram*/ #define SOCK_RAW 3 /*raw socket*/ #define SOCK_SEQPACKET 5 /*sequenced packet stream*/ Other socket types can be defined. OS/2 supports the basic set of sockets: SOCK_DGRAM Provides datagrams, which are connectionless messages of a fixed maximum length. This type of socket is generally used for short messages, such as a name server or time server, since the order and reliability of message delivery is not guaranteed. A datagram socket supports the bidirectional flow of data which is not sequenced, reliable, or unduplicated. A process receiving messages on a datagram socket may find messages duplicated or in an order different from the order sent. Record boundaries in data are, however, preserved. Datagram sockets closely model the facilities found in many contemporary packet-switched networks. An application can use the sendto() and recvfrom() calls or the sendmsg() and recvmsg() calls to exchange data over a datagram socket. If an application is using datagram sockets and calls connect() fully specifying the destination address, the socket will be considered connected. The application program can then use the other data transfer calls send() and recv() or writev() and readv(). The connected or unconnected method of data transfer stays in effect until connect() is called again with a different destination address. Datagram sockets may be used to send broadcast messages over TCP/IP and NetBIOS. For TCP/IP, the constant INADDR_BROADCAST, defined in , can be used to send a broadcast datagram. For NetBIOS, the address format has a type field that specifies whether the address is unique, multicast, or broadcast. SOCK_STREAM Provides sequenced, two-way byte streams with a transmission mechanism for stream data. This socket type transmits data reliably (in order, not duplicated, and retransmitted if necessary) without record boundaries, and with out-of-band capabilities. There is no guarantee for a one-to-one correspondence of send and receive calls. It is possible for data sent by one send() call to be received by more than one different receive call, or the other way around. Stream sockets are either active or passive. Active sockets are used by clients who actively initiate connection requests with connect(). Passive sockets are used by servers topassively wait for and accept connection requests with the listen() and accept() calls. A passive socket that has indicated its willingness to accept connections with the listen() call cannot be used to initiate connection requests. After a connection has been established between stream sockets, any of the data transfer calls can be used:  send() and recv()  sendto() and recvfrom()  sendmsg() and recvmsg()  writev() and readv() Usually, a send()-recv() pair is used for sending data on stream sockets. SOCK_RAW Provides access to internal network protocols and interfaces. A raw socket allows an application direct access to lower-level communication protocols, such as IP and ICMP. Raw sockets are intended for advanced users who wish to take advantage of some protocol feature not directly accessible through a normal interface, or who wish to build new protocols atop existing low-level protocols. Raw sockets are normally datagram-oriented, though their exact characteristics are dependent upon the interface provided by the protocol. However, raw sockets can be connected if connect() is called to specify the destination address. SOCK_SEQPACKET Provides sequenced, reliable, and unduplicated flow of information. Every sequenced packet is sent and received as a complete record. After a connection has been established between sequenced packet sockets, any of the data transfer calls can be used:  send() and recv()  sendto() and recvfrom()  sendmsg() and recvmsg()  writev() and readv() Usually, a send()-recv() pair is used for sending data on sequenced packet sockets. ═══ 3.5.1. Socket Types Summary ═══ The following table summarizes many of the attributes and features of supported socket types: Socket Types ┌─────────────────────────────────────────────────────────────────────┐ │Socket Type #define in Protocols Connection Primary Socket│ │ Oriented? Calls │ ├─────────────────────────────────────────────────────────────────────┤ │Stream SOCK_STREAM TCP/IP, Local yes send() or │ │ IPC recv() │ ├─────────────────────────────────────────────────────────────────────┤ │Sequenced SOCK_SEQPACKET NetBIOS yes send() or │ │packet recv() │ ├─────────────────────────────────────────────────────────────────────┤ │Datagram SOCK_DGRAM TCP/IP, Local no* sendto() or │ │ IPC, NetBIOS recvfrom()* │ ├─────────────────────────────────────────────────────────────────────┤ │Raw SOCK_RAW TCP/IP no* sendto() or │ │ recvfrom()* │ └─────────────────────────────────────────────────────────────────────┘ Table Note (*) Datagram sockets and raw sockets are connectionless, unless the application has called connect() for the socket. In this case, the socket is connected. Refer to Connection Modes for additional information. ═══ 3.5.2. Guidelines for Using Socket Types ═══ If you are communicating with an existing application, you must use the same socket type and the same protocol as the existing application. Raw sockets have a special purpose of interfacing directly to the underlying protocol layer. If you are writing a new protocol on top of Internet Protocol (IP) or wish to use the Internet Control Message Protocol (ICMP), then you must use raw sockets. You should consider the following factors in choosing a socket type for new applications:  Reliability: Stream and sequenced packet sockets provide the most reliable connection. Connectionless datagram and raw sockets are unreliable because packets can be discarded, duplicated, or received out of order. This may be acceptable if the application does not require reliability, or if the application implements the reliability on top of the sockets API.  Performance: The overhead associated with reliability, flow control, packet reassembly, and connection maintenance degrades the performance of stream and sequenced packet sockets so that these socket types do not perform as well as datagram sockets acting in a connectionless mode.  Amount of data to be transferred: Datagram and sequenced packet sockets impose a limit on the amount of data transferred in each packet. ═══ 3.6. Socket Creation ═══ The basis for communication between processes centers on the socket mechanism. A socket is comparable to an OS/2 file handle. Application programs request the operating system to create a socket through the use of the socket() call. When an application program requests the creation of a new socket, the operating system returns an integer that the application program uses to reference the newly created socket. To create a socket with the socket() call, the application program must include a protocol family and a socket type. It can also include a specific communication protocol within the specified protocol family. An example of an application using the socket() call is: An Application Using the socket() Call int s; ... s = socket(PF_INET, SOCK_STREAM, 0); In this example, the socket() call allocates a socket descriptor s in the internet protocol family (PF_INET). The type parameter is a constant that specifies the type of socket. For the internet communication domain, this can be SOCK_STREAM, SOCK_DGRAM, or SOCK_RAW. The protocol parameter is a constant that specifies which protocol to use. Passing 0 chooses the default protocol for the specified socket type. Supported Protocol Families includes information on default protocols. If successful, socket() returns a non-negative integer socket descriptor. For additional information about creating sockets, see:  Socket Connections ═══ 3.7. Binding Names to Sockets ═══ The socket() call creates a socket without a name. An unnamed socket is one without any association to a local address. Until a name is bound to a socket, no messages can be received on it. Communicating processes are bound by an association. The bind() call allows a process to specify half of an association: local address and local port (TCP/IP), or local path name (NetBIOS and local IPC). The connect() and accept() calls are used to complete a socket's association. An application program may not care about the local address it uses and may allow the protocol software to select one. This is not true for server processes. Server processes that operate at a well-known port need to be able to specify that port to the system. In most domains, associations must be unique. Internet domain associations must never include duplicate protocol, local address, local port, foreign address, or foreign port tuples. Wildcard addressing is provided to aid local address binding in the Internet domain. When an address is specified as INADDR_ANY (a constant defined in the file), the system interprets the address as any valid address. Sockets with wildcard local addresses may receive messages directed to the specified port number and sent to any of the possible addresses assigned to a host. If a server process wished to connect only hosts on a given network, it would bind the address of the hosts on the appropriate network. A local port can be specified or left unspecified (denoted by 0), in which case the system selects an appropriate port number for it. The bind() call accepts the s, name, and namelen parameters. The s parameter is the integer descriptor of the socket to be bound. The name parameter specifies the local address, and the namelen parameter indicates the length of address in bytes. The local address is defined by a data structure termed sockaddr. In the internet domain, a process does not have to bind an address and port number to a socket, because the connect() and send() calls automatically bind an appropriate address if they are used with an unbound socket. The bound name is a variable-length byte string that is interpreted by the supporting protocols. Its interpretation can vary from protocol family to protocol family (this is one of the properties of the protocol family). An example of an application using the bind() call is: An Application Using the bind() Call int rc; int s; struct sockaddr_in myname; /* clear the structure */ memset(&myname, 0, sizeof(myname)); myname.sin_family = AF_INET; myname.sin_addr.s_addr = inet_addr("129.5.24.1"); /* specific interface */ myname.sin_port = htons(1024); ... rc = bind(s, (struct sockaddr *) &myname, sizeof(myname)); For a server in the internet domain to be able to listen for connections on a stream socket or issue recvfrom() on a datagram socket, the server must first bind the socket to a specific address family and port. This example binds myname to socket s. Note that the sockaddr_in structure should be cleared before calling bind(). For a more detailed description, see bind(). For information on the sockaddr_in structure, see Internet Address Formats. The unique name myname specifies that the application uses an internet address family (AF_INET) at internet address 129.5.24.1, and is bound to port 1024. The preceding example shows two useful network utility routines.  inet_addr() takes an internet address in dotted-decimal form and returns it in network-byte order. For a more detailed description, see inet_addr().  htons() takes a port number in host-byte order and returns the port in network-byte order. For a more detailed description, see htons(). The next figure shows how the bind() call on the server side uses the network utility routine getservbyname() to find a well-known port number for a specified service from the ETC\SERVICES file (for more information on well-known ports, see Ports). The figure also shows the use of the internet address wildcard value INADDR_ANY. This is the value generally used on a socket bind() call. It binds the socket to all internet addresses available on the local machine, without requiring the program to know the local internet address. (The code fragment in the preceding figure will run successfully only on the machine with internet address 192.5.24.1.) If a host has more than one internet address (that is, if it is multihomed host), messages sent to any of the addresses will be deliverable to a socket bound to INADDR_ANY. A bind() Call Using the getservbyname() Call int rc; int s; struct sockaddr_in myname; struct servent *sp; ... sp = getservbyname("login","tcp"); /* get application specific */ /* well-known port */ ... /* clear the structure */ memset(&myname,0,sizeof(myname)); myname.sin_family = AF_INET; myname.sin_addr.s_addr = INADDR_ANY; /* any interface */ myname.sin_port = sp->s_port; ... rc = bind(s,(struct sockaddr *)&myname,sizeof(myname)); See bind() for more on this call. ═══ 3.8. Socket Connections ═══ Initially, a socket is created in the unconnected state, meaning the socket is not associated with any foreign destination. The connect() call binds a permanent destination to a socket, placing it in the connected state. An application program must call connect() to establish a connection before it can transfer data through a reliable stream socket. Sockets used with connectionless datagram services need not be connected before they are used, but connecting sockets makes it possible to transfer data without specifying the destination each time. The semantics of the connect() call depend on the underlying protocols. In the case of TCP, the connect() call builds a TCP connection with the destination, or returns an error if it cannot. In the case of connectionless services, the connect() call does nothing more than store the destination address locally. Connections are established between a client process and a server process. In a connection-oriented network environment, a client process initiates a connection and a server process receives, or responds to, a connection. The client and server interactions occur as follows:  The server, when willing to offer its advertised services, binds a socket to a well-known address associated with the service.  The server process socket is then marked to indicate incoming connections are to be accepted on it. It is then possible for an unrelated process to rendezvous with the server.  The client requests services from the server by initiating a connection to the server's socket. The client process uses a connect() call to initiate a socket connection.  If the client process' socket is unbound at the time of the connect() call, the system automatically selects and binds a name to the socket if necessary. This is the usual way that local addresses are bound to a socket.  If the connection to the server fails, the client's connect() call fails (any name automatically bound by the system, however, remains). Otherwise, the socket is associated with the server and data transfer can begin. An example of a client application using the connect() call to request a connection is: An Application Using the connect() Call int s; struct sockaddr_in servername; int rc; ... memset(&servername, 0,sizeof(servername)); servername.sin_family = AF_INET; servername.sin_addr.s_addr = inet_addr("129.5.24.1"); servername.sin_port = htons(1024); ... rc = connect(s, (struct sockaddr *) &servername, sizeof(servername)); The connect() call attempts to connect socket s to the server with name supplied in servername. This could be the server that was used in the previous bind() example. With TCP stream sockets the caller blocks until the connection is accepted by the server. On successful return from connect(), the socket s is associated with the connection to the server. See ioctl() for additional information about determining blocking and nonblocking behavior. Note that the sockaddr_in structure should be cleared before calling connect(). For a more detailed description, see connect(). The following figure shows an example of using the gethostbyname() network utility routine to find out the internet address of serverhost from the name server or the ETC\HOSTS file: An Application Using the gethostbyname() Call int s; struct sockaddr_in servername; char *hostname = "serverhost"; int rc; int connect(int s, struct sockaddr *name, int namelen); /* extracted from sys\socket.h */ struct hostent *hp; ... hp = gethostbyname(hostname); /* clear the structure */ memset(&servername,0,sizeof(servername)); servername.sin_family = AF_INET; servername.sin_addr.s_addr = *((u_long *)hp->h_addr); servername.sin_port = htons(1024); ... rc = connect(s,(struct sockaddr *)&servername,sizeof(servername)); ═══ 3.9. Obtaining Socket Addresses ═══ The sockets API includes calls that allow an application to obtain the address of the destination to which a socket connects and the local address of a socket. The socket calls that allow a program to retrieve socket addresses are:  getsockname()  getpeername() For additional information that you may need before binding or obtaining socket addresses, see:  Socket Addresses  Socket Connections ═══ 3.10. Server Connections ═══ In the internet domain, the server process creates a socket, binds it to a well-known protocol port, and waits for requests. The listen() call allows server processes to prepare a socket for incoming connections. In terms of underlying protocols, the listen() call puts the socket in a passive mode ready to accept connections. When the server process starts the listen() call, it also informs the operating system that the protocol software should queue multiple simultaneous connection requests that arrive at a socket. The listen() call includes a parameter that allows a process to specify the length of the connection queue for that socket. If the queue is full when a connection request arrives, the operating system refuses the connection. The listen() call applies only to sockets that have selected reliable stream delivery or connection-oriented datagram service. An example of a server application using the listen() call is: An Application Using the listen() Call int s; int backlog; int rc; ... rc = listen(s, 5); The listen() call is used to indicate that the server is ready to begin accepting connections. In this example, a maximum of five connection requests can be queued for the server. Additional requests are ignored. For a more detailed description, see listen(). Once a socket has been set up, the server process needs to wait for a connection. The server process waits for a connection by using the accept() call. A call to the accept() call blocks until a connection request arrives. When a request arrives, the operating system returns the address of the client process that has placed the request. The operating system also creates a new socket that has its destination connected to the requesting client process and returns the new socket descriptor to the calling server process. The original socket still has a wildcard foreign destination which remains open. When a connection arrives, the call to accept() returns. The server process can either handle requests interactively or concurrently. In the interactive approach, the thread that did the accept() handles the request itself, closes the new socket, and then starts the accept() call to obtain the next connection request. In the concurrent approach, after the call to accept() returns, the server process creates a new thread to handle the request. The new thread proceeds to service the request, and then exits. The original thread invokes the accept() call to obtain the next connection request. An example of a server application for accepting a connection request by using the accept() call is: An Application Using the accept() Call int clientsocket; int s; struct sockaddr clientaddress; int addrlen; ... addrlen = sizeof(clientaddress); ... clientsocket = accept(s, &clientaddress, &addrlen); ═══ 3.11. Handling Multiple Sockets ═══ Applications can handle multiple sockets. In such situations, you can use the select() call to determine the sockets that have data to be read, those that are ready for data to be written, and the sockets that have pending exception conditions. If the timeout parameter is positive, select() waits up to the amount of time indicated for at least one socket to become ready on the indicated conditions. This is useful for applications servicing multiple connections that cannot afford to block waiting for data on one connection. There are two versions of the select() call: a TCP/IP Version 4.1 for OS/2 Warp version and a version modeled after the BSD select() call. An example of how the TCP/IP Version 4.1 for OS/2 Warp select() call is used is shown in the next figure. For information on using the BSD version of the select() call, see select(). An Application Using the select() Call ... int socks[3]; /* array of sockets */ long timeout = MAX_TIMEOUT; int s1, s2, s3; int number_ready; ... /* put sockets to check in socks[] */ socks[0] = s1; /* read socket number */ socks[1] = s2; /* write socket number */ socks[2] = s3; /* second write socket number */ /* check for READ on s1, WRITE on s2 and s3 */ number_ready = os2_select(socks, 1, 2, 0, timeout); In this example, the application indicates the sockets to be checked for readability or readiness for writing. ═══ 3.12. Connectionless Datagram Services ═══ The operating system provides support for connectionless interactions typical of the datagram facilities found in packet-switched networks. A datagram socket provides a symmetric interface for data exchange. While processes are still likely to be client and server, there is no requirement for connection establishment. Instead, each message includes the destination address. An application program can create datagram sockets using the socket() call. In the internet domain, if a particular local address is needed, a bind() call must precede the first data transmission. Otherwise, the operating system sets the local address or port when data is first sent. The application program uses the sendto() and recvfrom() calls to transmit data; these calls include parameters that allow the client process to specify the address of the intended recipient of the data. In addition to the sendto() and recvfrom() calls, datagram sockets can also use the connect() call to associate a socket with a specific destination address. In this case, any data sent on the socket is automatically addressed to the connected peer socket, and only data received from that peer is delivered to the client process. Only one connected address is permitted for each socket at one time; a second connect() call changes the destination address. A connect() call request on a datagram socket results in the operating system recording the peer socket's address (as compared to a stream socket, where a connect request initiates establishment of an end-to-end connection). The accept() and listen() calls are not used with datagram sockets. While a datagram socket is connected, errors from recent send() calls can be returned asynchronously. These errors can be reported on subsequent operations on the socket, or a special socket option, SO_ERROR. This option, when used with the getsockopt() call, can be used to interrogate the error status. A select() call for reading or writing returns true when a process receives an error indication. The next operation returns the error, and the error status is cleared. Read Socket Types for more information that you may need before connecting sockets. ═══ 3.13. Socket Options ═══ In addition to binding a socket to a local address or connecting it to a destination address, application programs need a method to control the socket. For example, when using protocols that use timeout and retransmission, the application program may want to obtain or set the timeout parameters. An application program may also want to control the allocation of buffer space, determine if the socket allows transmission of broadcast, or control processing of out-of-band data. The ioctl-style getsockopt() and setsockopt() calls provide the means to control socket operations. The getsockopt() call allows an application program to request information about socket options. The setsockopt() call allows an application program to set a socket option using the same set of values obtained with the getsockopt() call. Not all socket options apply to all sockets. The options that can be set depend on the current state of the socket and the underlying protocol being used. ═══ 3.14. Socket Data Transfer ═══ Most of the work performed by the sockets layer is in sending and receiving data. The sockets layer itself does not impose any structure on data transmitted or received through sockets. Any data interpretation or structuring is logically isolated in the implementation of the protocol family. Once a connection is established between sockets, an application program can send and receive data. Topics Sending and Receiving Data Out-of-Band Data Socket I/O Modes ═══ 3.14.1. Sending and Receiving Data ═══ Sending and receiving data can be done with any one of several calls. The calls vary according to the amount of information to be transmitted and received and the state of the socket being used to perform the operation.  The writev() call can be used with a socket that is in a connected state, as the destination of the data is implicitly specified by the connection.  The sendto() and sendmsg() calls allow the process to specify the destination for a message explicitly.  The recv() call allows a process to receive data on a connected socket without receiving the sender's address.  The recvfrom() and recvmsg() calls allow the process to retrieve the incoming message and the sender's address. While the send() and recv() calls are virtually identical to the readv() and writev() calls, the extra flags argument in the send() and recv() calls is important. The flags, defined in the file, can be defined as a nonzero value if the application program requires one or more of the following: MSG_OOB Sends or receives out-of-band data. MSG_PEEK Looks at data without reading. MSG_DONTROUTE Sends data without routing packets. Out-of-band data is specific to stream sockets. The option to have data sent without routing applied to the outgoing packets is currently used only by the routing table management process, and is unlikely to be of interest to the casual user. The ability to preview data is, however, of general interest. When the MSG_PEEK flag is specified with a recv() call, any data present is returned to the user, but treated as still unread. That is, the next readv() or recv() call applied to the socket returns the data previously previewed. The following example shows an application sending data on a connected socket and receiving data in response. The flags field can be used to specify additional options to send() or recv(), such as sending out-of-band data. For additional information, see send() and recv(). An Application Using the send() and recv() Calls int bytes_sent; int bytes_received; char data_sent[256] = "data to be sent on connected socket"; char data_received[256]; int s; ... bytes_sent = send(s, data_sent, sizeof(data_sent), 0); ... bytes_received = recv(s, data_received, sizeof(data_received), 0); An example of an application sending from a connected socket and receiving data in response is: An Application Using the sendto() and recvfrom() Call int bytes_sent; int bytes_received; char data_sent[256] = "data to be sent using sendto()"; char data_received[256]; struct sockaddr_in to; struct sockaddr from; int addrlen; int s; ... memset(&to, 0, sizeof(to)); to.sin_family = AF_INET; to.sin_addr.s_addr = inet_addr("129.5.24.1"); to.sin_port = htons(1024); ... bytes_sent = sendto(s, data_sent, sizeof(data_sent), 0, (struct sockaddr *) &to, sizeof(to)); ... addrlen = sizeof(from); /* must be initialized */ bytes_received = recvfrom(s, data_received, sizeof(data_received), 0, &from, &addrlen); The sendto() and recvfrom() calls take additional parameters that allow the caller to specify the recipient of the data or to be notified of the sender of the data. See recvfrom(), and sendto(), for more information about these additional parameters. A list of the data transfer calls and a summary of some of their characteristics follows: Data Transfer Calls ┌────────────────────────────────────────────────────────────────────┐ │Data Transfer Buffers Option Flags? Sockets Used Server │ │Call With Address │ │ Required? │ ├────────────────────────────────────────────────────────────────────┤ │send() Single Yes Connected No │ │ only │ ├────────────────────────────────────────────────────────────────────┤ │recv() Single Yes Connected No │ │ only │ ├────────────────────────────────────────────────────────────────────┤ │sendto() Single Yes Any socket Yes │ ├────────────────────────────────────────────────────────────────────┤ │recvfrom() Single Yes Any socket Yes │ ├────────────────────────────────────────────────────────────────────┤ │writev() Multiple No Connected No │ │ only │ ├────────────────────────────────────────────────────────────────────┤ │readv() Multiple No Connected No │ │ only │ ├────────────────────────────────────────────────────────────────────┤ │sendmsg() Multiple Yes Any socket Yes │ ├────────────────────────────────────────────────────────────────────┤ │recvmsg() Multiple Yes Any socket Yes │ └────────────────────────────────────────────────────────────────────┘ For additional information that you may need when obtaining or setting socket options, see:  Socket Types  Out-of-Band Data  IP Multicasting ═══ 3.14.2. Out-of-Band Data ═══ The stream socket abstraction includes the concept of out-of-band data. Out-of-band data is a logically independent transmission channel associated with each pair of connected stream sockets. Out-of-band data can be delivered to the socket independently of the normal receive queue or within the receive queue depending upon the status of the SO_OOBINLINE socket-level option. The abstraction defines that the out-of-band data facilities must support the reliable delivery of at least one out-of-band message at a time. This message must contain at least one byte of data, and at least one message can be pending delivery to the user at any one time. For communication protocols that support only in-band signaling (that is, the urgent data is delivered in sequence with the normal data), the operating system normally extracts the data from the normal data stream and stores it separately. This allows users to choose between receiving the urgent data in order and receiving it out of sequence without having to buffer all the intervening data. If multiple sockets have out-of-band data awaiting delivery, an application program can use a select() call for exceptional conditions to determine those sockets with such data pending. The select() call does not indicate the actual arrival of the out-of-band data, but only notification that it is pending. In addition to the information passed, a logical mark is placed in the data stream to indicate the point at which the out-of-band data was sent. When a signal flushes any pending output, all data up to the mark in the data stream is discarded. To send an out-of-band message, the MSG_OOB flag is supplied to a send() or sendto() call. To receive out-of-band data, an application program must set the MSG_OOB flag when performing a recvfrom() or recv() call. An application program can determine if the read pointer is currently pointing at the logical mark in the data stream, by using the SIOCATMARK ioctl() call. A process can also read or peek at the out-of-band data without first reading up to the logical mark. This is more difficult when the underlying protocol delivers the urgent data in-band with the normal data, and only sends notification of its presence ahead of time (that is, the TCP protocol used to implement streams in the internet domain). With such protocols, the out-of-band byte may not have arrived when a recv() call is performed with the MSG_OOB flag. In that case, the call will return an SOCEWOULDBLOCK error code. There may be enough in-band data in the input buffer for normal flow control to prevent the peer from sending the urgent data until the buffer is cleared. The process must then read enough of the queued data so that the urgent data can be delivered. Certain programs that use multiple bytes of urgent data, and that must handle multiple urgent signals, need to retain the position of urgent data within the stream. The socket-level option, SO_OOBINLINE provides the capability. With this option, the position of the urgent data (the logical mark) is retained. The urgent data immediately follows the mark within the normal data stream that is returned without the MSG_OOB flag. Reception of multiple urgent indications causes the mark to move, but no out-of-band data is lost. ═══ 3.14.3. Socket I/O Modes ═══ Sockets can be set to either blocking or nonblocking I/O mode. The FIONBIO ioctl operation is used to determine this mode. When the FIONBIO ioctl is set, the socket is marked nonblocking. If a read is tried and the desired data is not available, the socket does not wait for the data to become available, but returns immediately with the SOCEWOULDBLOCK error code. When the FIONBIO ioctl is not set, the socket is in blocking mode. In this mode, if a read is tried and the desired data is not available, the calling process waits for the data. Similarly, when writing, if FIONBIO is set and the output queue is full, an attempt to write causes the process to return immediately with an error code of SOCEWOULDBLOCK. An example of using the ioctl() call to help perform asynchronous (nonblocking) socket operations is: An Application Using the ioctl() Call int s; int bytes_received; int dontblock; char buf[256]; int rc; ... dontblock = 1; ... rc = ioctl(s, FIONBIO, (char *) &dontblock); ... bytes_received = recv(s, buf, sizeof(buf), 0); if (bytes_received == -1) { if (sock_errno() == SOCEWOULDBLOCK) /* data is not present */ else /* error occurred */ } else /* bytes_ received indicates amount of data received in buf */ This example causes the socket s to be placed in nonblocking mode. When this socket is passed as a parameter to calls that would block, such as recv() when data is not present, it causes the call to return with an error code, and sets the error value to SOCEWOULDBLOCK. Setting the mode of the socket to be nonblocking allows an application to continue processing without becoming blocked. For a more detailed description, see ioctl(). When performing nonblocking I/O on sockets, a program must check for the SOCEWOULDBLOCK error code. This occurs when an operation would normally block, but the socket it was performed on is marked as nonblocking. The following socket calls return a SOCEWOULDBLOCK error code:  accept()  send()  recv()  readv()  writev() Processes using these calls should be prepared to deal with the SOCEWOULDBLOCK error code. For a nonblocking socket, the connect() call returns an SOCEINPROGRESS error code. If an operation such as a send operation cannot be done completely, but partial writes are permissible (for example when using a stream socket), the data that can be sent immediately is processed, and the return value indicates the amount actually sent. ═══ 3.15. Socket Shutdown ═══ Once a socket is no longer required, the calling program can discard the socket by applying a soclose() call to the socket descriptor. If a reliable delivery socket has data associated with it when a close takes place, the system continues to attempt data transfer. However, if the data is still not delivered, the system discards the data. Should the application program have no use for any pending data, it can use the shutdown() call on the socket prior to closing it. Topics Closing Sockets ═══ 3.15.1. Closing Sockets ═══ Closing a socket and reclaiming its resources is not always a straightforward operation. In certain situations, such as when a process exits, a soclose() call is expected to be successful. However, when a socket promising reliable delivery of data is closed with data still queued for transmission or awaiting acknowledgment of reception, the socket must attempt to transmit the data. If the socket discards the queued data to allow the soclose() call to complete successfully, it violates its promise to deliver data reliably. Discarding data can cause naive processes, which depend upon the implicit semantics of the soclose() call, to work unreliably in a network environment. However, if sockets block until all data has been transmitted successfully, in some communication domains a soclose() call may never complete. The sockets layer compromises in an effort to address this problem and maintain the semantics of the soclose() call. In normal operation, closing a socket causes any queued but unaccepted connections to be discarded. If the socket is in a connected state, a disconnect is initiated. When the disconnect request completes, the network support notifies the sockets layer, and the socket resources are reclaimed. The network layer may then attempt to transmit any data queued in the socket's send buffer, although this is not guaranteed. Alternatively, a socket may be marked explicitly to force the application program to linger when closing until pending data are flushed and the connection has shut down. This option is marked in the socket data structure using the setsockopt() call with the SO_LINGER option. The setsockopt() call, using the linger option, takes a linger structure. When an application program indicates that a socket is to linger, it also specifies a duration for the lingering period. If the lingering period expires before the disconnect is completed, the socket layer forcibly shuts down the socket, discarding any data still pending. An example of deallocating the socket descriptor s using the soclose() call is: An Application Using the soclose() Call ... /* close the socket */ soclose(s); ... ═══ 3.16. Typical Socket Session Diagrams ═══ The following figures show a graphical representation for the general sequence of socket calls needed to provide communication between applications for supported socket types. For stream or sequenced packet socket types, and for datagram socket types, see the following figures. This basic sequence is the same for each supported protocol family for all supported socket types. This means that a programmer can modify the protocol family selection and the networking addressing parameters of an existing sockets program, recompile and relink, and the program can be run with another protocol. This also allows programs that use sockets with multiple protocols to be easily constructed. A Typical Stream or Sequenced Packet Socket Session ═══ 3.17. TCP Extensions for Transactions (T/TCP) ═══ TCP Extensions for Transactions (T/TCP) is an extension to TCP designed to make client-server transactions (that is, a client requests to a server followed by the server's reply) more efficient. For typical transaction processing, a reliable delivery of data with no explicit connection setup or tear down, and with minimal idle state (Time Wait) on both ends is needed. UDP is faster but not reliable. Standard TCP provides the reliability but with the overhead of connection setup and Time Wait delay. T/TCP has been introduced to address this issue. T/TCP can match UDP performance with reliability achieved. The goal of T/TCP is to allow each transaction (request and response sequence) to be efficiently performed as a single incarnation of a TCP connection. Standard TCP imposes two performance problems for transaction oriented communication. First, a TCP connection is opened with a three way handshake which must complete successfully before any data can be transferred. This handshake adds an extra round trip time to transaction latency. Second, closing a TCP connection leaves one or both ends in Time Wait state (2 Maximum Segment Lifetime periods (2MSL)), which limits the rate of successive transactions between the same host-port pair, since a new incarnation cannot be reopened until the Time Wait delay expires. (The default value for the Time Wait delay can be checked by using the inetcfg.exe utility.) T/TCP addresses the handshake issue by using TCP Accelerated Open (TAO) which is based on using a new incarnation number called 'Connection Count (CC)'. T/TCP uses the monotonic property of CC values to bypass the handshake. A T/TCP server host keeps a cache containing the last valid CC value that it has received from each different client host. If an initial SYN segment (connection request) from a particular client host carries a CC value larger than the cached value then the incoming segment is ensured to be new and the connection can be accepted immediately. The use of CC also truncates the Time Wait delay. Apart from rate of transactions, reduction in the Time Wait also saves locked-up resources from the hosts. T/TCP introduces three new TCP options namely CC, CCnew and CCecho, and seven new states to the existing ten finite TCP states. To invoke T/TCP, both client and server ends must support T/TCP. The CC value is sent by the client in the SYN segment (for active open) indicating a willingness to use T/TCP. The server sends back CCecho in the SYN-ACK declaring that it understands T/TCP. The client can still optionally disable T/TCP and force a handshake by sending a CCNew. If any of the ends do not support T/TCP, then it resumes back to the normal TCP connection setup procedure. To take advantage of T/TCP, the socket calls sequence on a typical T/TCP client application is different from the client shown in A Typical Stream or Sequenced Packet Socket Session. On a typical T/TCP client application, after opening a Stream socket, the client does not call connect(). Instead, it calls sendto() with the flag of MSG_EOF. This will send the request to the server, establish the connection, and cause a FIN to be sent from the client to the server. This single sendto() call combines the functionality of connect(), write(), and shutdown() of a normal TCP session. The typical T/TCP transaction server application is the same as a typical TCP server, except the MSG_EOF flag can be indicated on the send() call to cause a FIN to be sent at the end of the transaction data. T/TCP can be turned on for a system-wide effect through the INET configuration utility command 'inetcfg -set CC 1'. You can use getsockopt() and setsockopt() for each socket through the TCP_CC socket option. By default the T/TCP option is turned off. To assure that T/TCP is being invoked, IP tracing function can be turned on through 'iptrace -i', and the trace file iptrace.dmp can be formatted with the 'ipformat' utility which can explicitly show the three CC option values in the formatted dump. For more details on T/TCP functional specification, refer to RFC 1644 T/TCP -TCP Extensions for Transactions Functional Specification. ═══ 3.18. TCP Extensions for High Performance (RFC 1323) ═══ Request For Comments 1323 suggested some TCP extensions for performance improvement over very high speed links. Two TCP options are introduced by RFC 1323: Window Scale and TCP Timestamps. The Window Scale option allows the TCP receive window size to be larger than the present limit of 64K bytes, by defining an implicit scale factor, which is used to multiply the window size value found in the TCP header to obtain the true window size. The Window Scale option is carried in SYN segments during the connection setup phase. If TCP Timestamp is enabled, the sender places a timestamp in every TCP segment, and then the receiver sends the timestamp back in the acknowledgment, allowing the sender to calculate the Round Trip Time (RTT) for each acknowledgment. This RTT estimation helps TCP to discard received duplicate segments, to calculate the retransmission timer, and to decide whether to start the slow start process. The presence of the TCP timestamp option also allows TCP to perform Protection Against Wrapped Sequences (PAWS). PAWS assumes that every received TCP segment contains a TCP Timestamp whose values are monotone non-decreasing in time. A segment can be discarded as an old duplicate if it is received with a timestamp less than a timestamp recently received on this connection. The TCP Timestamp function can be turned on for a system-wide effect through the INET configuration utility 'inetcfg -set timestmp 1'. It can also be retrieved and set for each socket through the TCP_TIMESTMP socket option. Similarly Window Scale function can be turned on system-wide through 'inetcfg -set winscale 1' and can also be retrieved and set for each socket through the TCP_WINSCALE socket option. By default, the system-wide Window Scaling option is turned ON and systemwide TCP Time Stamp option is turned OFF. Both options, if set, can be traced through the iptrace utility and can be displayed in the ipformat dump. For more details on these two TCP extensions, refer to RFC 1323 TCP Extensions for High Performance. ═══ 3.19. High Performance Send ═══ High Performance Send is a new feature of TCP/IP 4.1 that allows sending data over sockets without incurring a memory copy. To use it, special memory is first allocated from the TCP/IP stack with the sysctl() call, and then send(), sendto(), or sendmsg() is called with the MSG_MAPIO flag. The user must then wait for the stack to notify him that it is finished using the memory passed on the previous send call before reusing it to send more data. A complete example of using HPS appears in the samples directory of the toolkit. ═══ 3.19.1. Allocating HPS Memory ═══ To allocate HPS memory, the user calls sysctl() as follows: int mib[4]; unsigned long ptrs[15]; size_t ptrslen; int ret; mib[0] = CTL_OS2; mib[1] = PF_INET; mib[2] = IPPROTO_IP; mib[3] = OS2_MEMMAPIO; memset(ptr, 0, sizeof(ptrs)); ptrslen = sizeof(ptrs); ret = sysctl(mib, sizeof(mib) / sizeof(mib[0]), ptrs, &ptrslen, NULL, 0); The TCP/IP stack will allocate 60K of memory and return 15 pointers to 4K blocks. These must be passed on subsequent send calls with the MSG_MAPIO flag. To allocate memory and attach a shared event semaphore to each block as well, the user should initialize the ptrs array with the shared event semaphore handles before calling sysctl(): int mib[4]; unsigned long ptrs[15]; size_t ptrslen; int i; APIRET rc; int ret; mib[0] = CTL_OS2; mib[1] = PF_INET; mib[2] = IPPROTO_IP; mib[3] = OS2_MEMMAPIO; for (i = 0; i < sizeof(ptrs) / sizeof(ptrs[0]); i++) { rc = DosCreateEventSemaphore(NULL, &ptrs[i], DC_SEM_SHARED, FALSE); if (rc != NO_ERROR) exit(1); } ptrslen = sizeof(ptrs); ret = sysctl(mib, sizeof(mib) / sizeof(mib[0]), ptrs, &ptrslen, NULL, 0) ; ═══ 3.19.2. Using HPS Memory with Send Calls ═══ To send data using HPS, the user passes one or more of the pointers received from an HPS allocation call to one of the send calls along with the MSG_MAPIO flag: int ret, sock; unsigned long ptrs[15]; struct msghdr hdr; struct iovec iovec[2]; ret = send(sock, ptrs[0], 4096, MSG_MAPIO); hdr.msg_name = NULL; hdr.msg_namelen = 0; hdr.msg_iov = iovec; hdr.msg_iovlen = 2; iovec[0].iov_base = ptrs[0]; iovec[0].iov_len = 4096; iovec[1].iov_base = ptrs[1]; iovec[1].iov_len = 96; hdr.msg_control = NULL; hdr.msg_controllen = 0; hdr.msg_flags = 0; ret = sendmsg(sock, &hdr, MSG_MAPIO); Notes: 1. On the send() and sendto() calls, only one pointer and up to 4096 bytes may be sent per call. 2. The pointers passed to the any of the send calls must be exactly as returned from the allocation call; they may not be altered in any way. ═══ 3.19.3. Determining if HPS Memory is Available for Reuse ═══ After a successful send call using HPS memory, the user must wait until the stack is finished with it before reusing it. There are two ways to determine if HPS memory is available for reuse: event semaphores and polling. To use the event semaphores method, the user must allocate 15 shared event sempahores and pass them on the sysctl() used to allocate the HPS memory (see the 2nd example under Allocating HPS Memory). When the stack is finished using the HPS memory, it will post the event semaphore(s) corresponding to the 4K blocks that are now free. To use the polling method, the user calls sysctl() with an array of pointers. The stack will check each pointer, and if the block is in use, zero the pointer in the array. The polling method may be used even if event semaphores were also allocated for the memory. Following is an example of the polling method: long arrayofptrs[15]; int mib[4]; unsigned int needed; mib[0] = CTL_OS2; mib[1] = AF_INET; mib[2] = 0; mib[3] = OS2_QUERY_MEMMAPIO; needed = sizeof(arrayofptrs); if (sysctl(mib, sizeof(mib) / sizeof(mib[0]), arrayofptrs, &needed, NULL, 0) < 0) { psock_errno("sysctl(QUERY_MEMMAPIO)"); exit(1); } for (i = 0; i < 15; i++) { if (arrayofptrs[i] == 0) { /* pointer is in use */ } } ═══ 3.19.4. Freeing HPS Memory ═══ To free HPS memory, the user calls sysctl() as follows: int mib[4]; unsigned long ptrs[15]; int ret; mib[0] = CTL_OS2; mib[1] = PF_INET; mib[2] = IPPROTO_IP; mib[3] = OS2_MEMMAPIO; ret = sysctl(mib, sizeof(mib) / sizeof(mib[0]), NULL, 0, ptrs, sizeof(ptrs)); Where ptrs<\i> is the list of array of pointers returned on the allocation call. ═══ 3.20. Passing Sockets Between Processes ═══ Because sockets are not file handles on OS/2, sockets are not automatically passed from a parent process to a child process. Instead, sockets are global to the system and unsecure, so that any process may access any valid socket. To ensure sockets are always properly closed when a process terminates, TCPIP32.DLL installs an exit list handler (with an order code of 0x99) that closes all remaining sockets that were opened by that process. If a process attempts to pass a socket to a child process, both the parent and child need to notify TCPIP32.DLL that a change in ownership occurred so that the exit list handler for the two processes close the correct sockets when the processes terminate. To pass ownership from parent to child, the parent process needs to issue removesocketfromlist() with the socket number that is being transferred to the child. The child process needs to issue addsockettolist() with the same socket number to assume ownership of it. After these two calls are completed, the child process's exit list handler will automatically close the socket that was passed once the child terminates (unless the child application closes the socket itself before it terminates.) See addsockettolist() and removesocketfromlist() for additional details. ═══ 3.21. Multithreading Considerations ═══ The sockets and network utility routines are completely re-entrant. Multiple threads of an application can perform any socket call. Note: Each thread that makes sockets calls has memory automatically allocated for it by TCPIP32.DLL to store per-thread information (such as the error code for the last sockets call made on that thread). If a thread only makes protocol-independent calls, the amount of memory allocated will be small (on the order of 100 bytes). If a thread issues any of the TCP/IP network utility calls, however, a 4K block will also be allocated for that thread. None of the memory that is allocated will be deallocated until the process terminates. It will be reused however, if a thread terminates and another thread is created. ═══ 3.22. Accessing a TCP/IP API DLL from an Intermediate DLL ═══ A TCP/IP API DLL can be accessed both directly from an application and through an intermediate DLL. An example of an intermediate DLL is a virtual network API layer that supports generalized network functionality for applications and uses the TCP/IP API. The OS/2 Warp Toolkit contains a sample program to build a DLL. You can find the program in the SAMPLES\TCPIPTK\SAMPDLL directory. For more information about DLLs, refer to the OS/2 Warp Technical Library, Control Programming Guide ═══ 3.23. Differences between OS/2 and Standard BSD Sockets ═══ Networking services sockets is based on the Berkeley Software Distribution version 4.4 sockets implementation. The IBM OS/2 socket implementation differs from the Berkeley socket implementation as follows:  Sockets are not OS/2 files or devices. Socket numbers have no relationship to OS/2 file handles. Therefore, read(), write(), and close() do not work for sockets. Using read(), write(), or close() gives incorrect results. Use the recv(), send(), and soclose() functions instead.  Error codes set by the OS/2 TCP/IP sockets implementation are not made available via the global errno variable. Instead, error codes are accessed by using the sock_errno() function (see sock_errno()). Use psock_errno(), instead of perror(), to write a short error message to the standard error device describing the last error encountered during a call to a socket library function. To access system return values, use the errno.h include statement supplied with the compiler. This is intended to obtain per-thread error codes in a multithreaded application environment and to avoid conflict with standard ANSI C error constants. BSD-style error checking is as follows: - rt = recv(s, buf, sizeof(buf), 0); if (rt == -1 && errno == EWOULDBLOCK) {...} - if (recv(s, buf, sizeof(buf), 0) < 0) { perror("Recv()"); exit(1); } The preferred OS/2-style error checking is as follows: - rt = recv(s, buf, sizeof(buf), 0); if (rt == -1 && sock_errno() == SOCEWOULDBLOCK) {...} - if (recv(s, buf, sizeof(buf), 0) < 0) { psock_errno("Recv()"); exit(1); } Error constants consistent with BSD sockets are provided for compatibility purposes; your application can use the error constant EWOULDBLOCK, instead of SOCEWOULDBLOCK. See Socket Error Constants, or the file for definitions of error constants.  Unlike the Berkeley select() call, you cannot use the OS/2 select() call to wait for activity on devices other than sockets. See select() for more information.  The ioctl(), getsockopt(), and setsockopt() calls don't support all of the options supported by BSD and add some options not supported by BSD. See ioctl(), getsockopt(), and setsockopt() for more information. ═══ 3.24. Compiling and Linking a Sockets API Application ═══ Follow these steps to compile and link a sockets API application using the IBM VisualAge C++ compiler: 1. To compile your program, enter: icc /Gm /c myprog.c 2. To create an executable program, you can enter: For VisualAge C++ ilink /NOFREEFORMAT myprog,myprog.exe /STACK:0x4000 Note: For more information about the compile and link options, multithreaded libraries, and dynamic link libraries, refer to the User's Guide provided with your compiler. ═══ 3.25. Example Programs ═══ The following sample programs are included in the TCP/IP toolkit: SOCKET These samples consist of several C socket client/server programs. SAMPDLL These samples demonstrate building and using a DLL that uses TCP/IP. HPS These samples demonstrate using High Performance Send. RPC These samples provide examples of Remote Procedure Call (RPC) client, server, and raw data stream programs. RPCGEN The samples define remote procedure characteristics and demonstrate an RPC client and server program. ═══ 4. Sockets in the Internet Domain ═══ This section describes the use of sockets in the internet domain. Topics Protocols Used in the Internet Domain Getting Started with Sockets in the Internet Domain Network-Byte Order Internet Address Formats TCP/IP-Specific Network Utility Routines The _res Data Structure Name Resolution Ports IP Multicasting Socket Secure Support ═══ 4.1. Protocols Used in the Internet Domain ═══ This section describes the network protocols in TCP/IP. The internet domain is supported only by the TCP/IP protocol suite. Networking protocols like TCP/IP are layered as shown in the following figure. For more information on the internet domain and the TCP/IP protocol suite, refer to TCP/IP Illustrated, Volume 1: The Protocols, W. Richard Stevens, Addison-Wesley Publishing Co., 1994. The Internet Layered Architecture Topics Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Internet Protocol (IP) Internet Control Message Protocol (ICMP) Address Resolution Protocol (ARP) Internet Group Management Protocol (IGMP) ═══ 4.1.1. Transmission Control Protocol (TCP) ═══ TCP is a transport protocol that provides a reliable mechanism for delivering packets between hosts on an internet. TCP takes a stream of data, breaks it into datagrams, sends each one individually using Internet Protocol (IP), and reassembles the datagrams at the destination node. If any datagrams are lost or damaged during transmission, TCP detects this and resends the missing datagrams. The received data stream is a reliable copy of the transmitted data stream. Note: The PUSH flag is a notification from the sender to the receiver for the receiver to pass all the data that it has to the receiving process. This data consists of whatever is in the segment with the PUSH flag, along with any other data the receiving TCP has collected for the receiving process. Our TCP implementation automatically sets the PUSH flag if the data in the segment being sent empties the send buffer. In addition, our implementation ignores a received PUSH flag because we don't delay the delivery of the received data to the application. You can use TCP sockets for both passive (server) and active (client) applications. While some calls are necessary for both types, some are role-specific. TCP is the default protocol for stream sockets in the internet domain. For sample C socket communication client and server programs, see the TCP/IP samples included in the OS/2 Warp Toolkit. TCP is a connection-oriented protocol. It is used to communicate between pairs of applications. After you make a connection, it exists until you close the socket. During the connection, data is either delivered or an error code is returned by networking services. ═══ 4.1.2. User Datagram Protocol (UDP) ═══ UDP is a transport-layer datagram protocol that sends and receives whole packets across the network. UDP is used for application-to-application programs between TCP/IP hosts. UDP does not offer a guarantee of datagram delivery or duplication protection. UDP does provide checksums for both the header and data portions of a datagram. However, applications that require reliable delivery of streams of data should use TCP. UDP is the default protocol for datagram sockets in the internet domain. Unlike applications using TCP, UDP applications are usually connectionless. A UDP socket application can become connected by calling the connect() API. An unconnected socket can be used to communicate with many hosts; but a connected socket, because it has a dedicated destination, can exchange data with only one host at a time. UDP is considered an unreliable protocol because it sends its data over the network without verification. Consequently, after a packet has been accepted by the UDP interface, neither the arrival of the packet nor the arrival order of the packet at the destination can be guaranteed. ═══ 4.1.3. Internet Protocol (IP) ═══ The IP network layer provides the interface from the transport layer (host-to-host) protocols to the link-level protocols. IP is the basic transport mechanism for routing IP packets to the next gateway, router, or destination host. IP provides the means to transmit packets of data from sources to destinations. Sources and destinations are hosts identified by 32-bit IP addresses, which are assigned independent of the underlying physical network. Outgoing packets automatically have an IP header prepended to them, and incoming packets have their IP header removed before being passed to the higher-level protocols. This protocol ensures the unique addressing of hosts in an internet network. IP does not ensure a reliable communication, because it does not require acknowledgments from the sending host, the receiving host, or intermediate hosts. IP does not provide error control for data; it provides only a header checksum. IP treats each packet as an independent entity, unrelated to any other packet. IP does not perform retransmissions or flow control. A higher-level protocol like TCP (Transmission Control Protocol) that uses IP must implement its own reliability procedures. Applications do not typically access IP directly, but rather use TCP or UDP which, in turn, use IP. Raw sockets can use IP. ═══ 4.1.4. Internet Control Message Protocol (ICMP) ═══ ICMP is used to pass control information between hosts. For example, the information can be sent in any of the following situations:  When a host checks to see if another host is available (PING)  When a packet cannot reach its destination  When a gateway or router can direct a host to send traffic on a shorter route  When a gateway or router does not have the buffering capacity to forward a packet ICMP provides feedback about problems in the communication environment; it does not make IP reliable. The use of ICMP does not guarantee that an IP packet will be delivered reliably or that an ICMP message will be returned to the source host when an IP packet is not delivered or is incorrectly delivered. Raw sockets can use ICMP and, like IP, ICMP is not typically used by application programs directly. ═══ 4.1.5. Address Resolution Protocol (ARP) ═══ ARP maps IP addresses to hardware addresses. TCP/IP uses ARP to collect and distribute the information for mapping tables. ARP is not directly available to users or applications. When an application sends an internet packet, IP requests the appropriate address mapping. If the mapping is not in the mapping table, an ARP broadcast packet is sent to all the hosts on the local network requesting the physical hardware address for the host. ═══ 4.1.6. Internet Group Management Protocol (IGMP) ═══ RFC 1112 defines IGMP, which describes interactions between IP multicast hosts and multicast routers. A multicast router needs to know the current membership of host groups in all attached local networks in order to forward multicast datagrams to hosts on local networks. IP multicast datagrams will not be forwarded to local networks if there are no members of the destination host group. There are two types of IGMP messages transmitted on local networks. Both types of messages are transmitted by multicasting to reduce network load. A multicast router periodically sends IGMP membership queries to hosts on the same network. An IGMP membership query is sent to the all-hosts group (224.0.0.1). Upon receiving a membership query from a multicast router, a multicast host starts a random timer for each host group joined on the interface that receives IGMP membership queries. A host sends IGMP membership reports when timers expire. Membership reports are sent to the host group being reported. If other hosts on the same network are to receive an IGMP membership report on the same host group, these hosts should cancel the timer before it expires. This prevents duplicated IGMP membership reports from flooding a local network. An IGMP membership report is also sent when a host joins a new host group. When a multicast router receives an IGMP membership report of one host group, the router updates its knowledge of the current membership on a particular network. If no reports are received on a particular host group after several queries, a multicast router assumes that there are no local members on that host group and stops forwarding any multicast datagrams with that destination host group. ═══ 4.2. Getting Started with Sockets in the Internet Domain ═══ This section provides some basic information for getting started with sockets in the internet domain:  Use the socket() call to create a socket in the internet domain specifying PF_INET for the domain parameter.  Use AF_INET for the address family.  The following socket types are supported for the internet domain: - Datagram (SOCK_DGRAM) - Raw (SOCK_RAW) - Stream (SOCK_STREAM) The socket type is passed as a parameter to the socket() call. For additional information, see Socket Types and general socket programming concepts in Sockets General Programming Information.  Datagram sockets use the UDP protocol, stream sockets use the TCP protocol, and raw sockets can use the raw, ICMP, or IGMP protocols.  Use the network utility routines to get addresses with a given name (see TCP/IP-Specific Network Utility Routines for additional information). ═══ 4.3. Network-Byte Order ═══ Ports and addresses are specified to sockets API calls by using the network-byte ordering convention. Network-byte order is also known as big endian byte ordering, which has the high-order byte at the starting address. By contrast, little endian has the low-order byte at the starting address. Using network-byte ordering for data exchanged between hosts allows hosts using different underlying byte ordering conventions to exchange address information. There is a set of network utility functions for translating addresses from host-byte to network-byte order and from network-byte to host-byte order. For more information about network-byte order and address translation, see:  bind()  htonl()  htons()  ntohl()  ntohs() Note: The socket interface does not handle application data byte ordering differences. Application writers must handle data buffer byte order differences themselves. ═══ 4.4. Internet Address Formats ═══ This section describes the address formats used in the internet domain. internet addresses (IP) are 32-bit values that represent a network interface. Every internet address within an administered internet (AF_INET) communication domain must be unique. A host can have as many internet addresses as it has network interfaces. For more information about internet address formats, see Internetworking with TCP/IP Volume I: Principles, Protocols, and Architectures , and Volume II: Implementation and Internals , Douglas E. Comer, Prentice Hall, 1991. Each internet host is assigned at least one unique internet address. This address is used by IP and other higher-level protocols. When a host is a gateway, it has more than one IP address. Gateway hosts connect two or more physical networks and have one IP address per connected physical network. Addresses within an internet consist of a network number and a local address. All physical host IP addresses share the same network number and are logically part of the same network even if that network is connected with various physical media. Hosts on disjoint physical networks might also have the same network number, but are not part of the same internet network. Hosts that are part of the same internet network can exchange packets directly without going through intermediate routers. An internet network can be subdivided logically using a subnet mask. All host interfaces to the same physical network are given the same subnetwork number. An internet domain can provide standards for assigning addresses to networks, broadcasts, and subnetworks. Dotted-Decimal Notation: A commonly used notation for internet host addresses is the dotted-decimal format, which divides the 32-bit address into four 8-bit fields. The value of each field is specified as a decimal number, and the fields are separated by periods (for example, 10.2.0.52). Address examples in this document use dotted-decimal notation in the following forms:  nnn.lll.lll.lll  nnn.nnn.lll.lll  nnn.nnn.nnn.lll where: nnn represents part or all of a network number. lll represents part or all of a local address. Note: Additional details about internet network address format class A, B, C, and D addresses, subnetwork address format, and broadcast address formats can be found in the TCP/IP Guide Addressing within an Internet Domain: A socket address in an internet communication domain is composed of five fields in the following sockaddr_in structure: length, address family, port, internet address, and a .* reserved field. The sockaddr_in structure should be cleared before use. The structure is located in the header file: struct in_addr { u_long s_addr; }; struct sockaddr_in { u_short sin_family; /* AF_INET */ u_short sin_port; /* port id */ struct in_addr sin_addr; /* address */ char sin_zero[8]; /* not used */ }; The sin_family field is set to AF_INET. The sin_port field is set to the port number in network-byte order. If you are specifying your workstation address in sin_addr and you set sin_port to 0 using the bind() call, the system assigns an available port. If you specify a different workstation address in sin_addr, you must specify the port. For more information on ports, see Ports. The sin_addr field is set to the internet address represented in network-byte order. When specified as a parameter to bind(), sin_addr is usually set to the constant INADDR_ANY, as defined in . This binds the socket to any and all local internet addresses. By using INADDR_ANY, an application can bind a socket without specifying the local internet address. The constant INADDR_ANY also allows an application running on a host with multiple interfaces (called a multihomed host) to receive UDP datagrams and TCP connection requests arriving at any interface on a single socket. (The application is not required to have one socket per interface, with each interface bound to a specific internet address). To specify your workstation address, you can leave sin_addr unspecified. If you are specifying a different workstation address, you must specify a valid internet address for that workstation. The sin_zero field is not used, and it should be set to 0 by the application before passing the address structure to any sockets call. ═══ 4.5. TCP/IP-Specific Network Utility Routines ═══ This section describes the library of network utility routines. Network utility routines are described in the following sections. Topics Host Names Information Network Names Information Protocol Names Information Service Names Information Network Address Translation Network-Byte Order Translation Internet Address Manipulation Domain Name Resolution ═══ 4.5.1. Host Names Information ═══ The following is a list of host-related calls:  gethostbyname()  gethostbyaddr()  sethostent()  gethostent()  endhostent()  gethostname()  gethostid() The gethostbyname() call takes an internet host name and returns a hostent structure, which contains the name of the host, aliases, host address family and host address. The hostent structure is defined in the header file. The gethostbyaddr() call maps the internet host address into a hostent structure. The database for these calls is provided by the name server or the ETC\HOSTS file if a name server is not present or is unable to resolve the host name. The sethostent(), gethostent(), and endhostent() calls open, provide sequential access to, and close the ETC\HOSTS file. The gethostname() call gets the name for the local host machine. The gethostid() call returns an integer that identifies the host machine. Host IDs fall under the category of internet network addressing because, by convention, the 32-bit internet address is used. ═══ 4.5.2. Network Names Information ═══ The following is a list of network-related calls:  getnetbyname()  getnetbyaddr()  setnetent()  getnetent()  endnetent() The getnetbyname() call takes a network name and returns a netent structure, which contains the name of the network, aliases, network address family, and network number. The netent structure is defined in the header file. The getnetbyaddr() call maps the network number into a netent structure. The database for these calls is provided by the ETC\NETWORKS file. The setnetent(), getnetent(), and endnetent() calls open, provide sequential access to, and close the ETC\NETWORKS file. ═══ 4.5.3. Protocol Names Information ═══ The following is a list of protocol related calls:  getprotobyname()  getprotobynumber()  setprotoent()  getprotoent()  endprotoent() The getprotobyname() call takes the protocol name and returns a protoent structure, which contains the name of the protocol, aliases, and protocol number. The protoent structure is defined in the header file. The getprotobynumber() call maps the protocol number into a protoent structure. The database for these calls is provided by the ETC\PROTOCOL file. The setprotoent(), getprotoent(), and endprotoent() calls open, provide sequential access to, and close the ETC\PROTOCOL file. ═══ 4.5.4. Service Names Information ═══ The following is a list of service related calls:  getservbyname()  getservbyport()  setservent()  getservent()  endservent() The getservbyname() call takes the service name and protocol, and returns a servent structure that contains the name of the service, aliases, port number, and protocol. The servent structure is defined in the header file. The getservbyport() call maps the port number and protocol into a servent structure. The database for these calls is provided by the ETC\SERVICES file. The setservent(), getservent(), and endservent() calls open, provide sequential access to, and close the ETC\SERVICES file. ═══ 4.5.5. Network Address Translation ═══ Network library calls enable an application program to locate and construct network addresses while using interprocess communication facilities in a distributed environment. Locating a service on a remote host requires many levels of mapping before client and server can communicate. A network service is assigned a name that is intended to be understandable for a user. This name and the name of the peer host must then be translated into network addresses. Finally, the address must then be used to determine a physical location and route to the service. Network library calls map:  Host names to network addresses  Network names to network numbers  Protocol names to protocol numbers  Service names to port numbers Additional network library calls exist to simplify the manipulation of names and addresses. An application program must include the file when using any of the network library calls. Note: All networking services return values in standard network byte order. ═══ 4.5.6. Network-Byte Order Translation ═══ Internet domain ports and addresses are usually specified to calls using the network-byte ordering convention. The following calls translate integers from host- to network-byte order and from network- to host-byte order. htonl() Translates host to network, long integer (32-bit) htons() Translates host to network, short integer (16-bit) ntohl() Translates network to host, long integer (32-bit) ntohs() Translates network to host, short integer (16-bit) ═══ 4.5.7. Internet Address Manipulation ═══ The following calls convert internet addresses and decimal notation, and manipulate the network number and local network address portions of an internet address: inet_addr() Translates dotted-decimal notation to a 32-bit internet address (network-byte order). inet_network() Translates dotted-decimal notation to a network number (host-byte order), and zeros in the host part. inet_ntoa() Translates 32-bit internet address (network-byte order) to dotted-decimal notation. inet_netof() Extracts network number (host-byte order) from 32-bit internet address (network-byte order). inet_lnaof() Extracts local network address (host-byte order) from 32-bit internet address (network-byte order). inet_makeaddr() Constructs internet address (network-byte order) from network number and local network address. ═══ 4.5.8. Domain Name Resolution ═══ In TCP/IP, communication is based on internet addresses. When a TCP/IP application receives a symbolic host name, it calls a host name resolver routine to resolve the symbolic name into an internet address. The host name resolver routine queries a domain name server or a local HOSTS file, or both, to perform the name resolution. If a RESOLV2 file or RESOLV file exists in the ETC subdirectory, the host name resolver routine first tries to resolve the name by querying the name servers specified in that file. If resolution through a name server fails or if a RESOLV2 or RESOLV file does not exist, the host name resolver routine tries to resolve the name locally by searching the HOSTS file in the ETC subdirectory for a match of the symbolic host name. If a match is found, the routine returns the corresponding internet address. If a match is not found, the routine displays a message stating that the host is unknown. RESOLV and RESOLV2 files ┌───────────────────────────────────────────────────────────────────┐ │NETWORK RESOLV FILE RESOLV2 FILE │ │CONNECTION │ ├───────────────────────────────────────────────────────────────────┤ │LAN only X │ │connection │ ├───────────────────────────────────────────────────────────────────┤ │SLIP only X │ │connection │ ├───────────────────────────────────────────────────────────────────┤ │LAN and SLIP X X (used for domain name │ │connections resolution) │ └───────────────────────────────────────────────────────────────────┘ The following resolver calls are used to make, send, and interpret packets for name servers in the internet domain:  res_query()  res_querydomain()  res_mkquery()  res_send()  res_search()  res_init()  dn_comp()  dn_expand()  dn_find()  dn_skipname()  _getshort()  _getlong()  putlong()  putshort() ═══ 4.6. The _res Data Structure ═══ Global information used by these resolver calls is kept in the _res data structure. This structure is defined in the file and contains the following members: ┌─────────────────────────────────────────────────────────────────┐ │Type Member Contents │ ├─────────────────────────────────────────────────────────────────┤ │int retrans Retransmission time │ │ interval │ ├─────────────────────────────────────────────────────────────────┤ │int retry Number of times to │ │ retransmit │ ├─────────────────────────────────────────────────────────────────┤ │long options Option flags │ ├─────────────────────────────────────────────────────────────────┤ │int nscount Number of name │ │ servers │ ├─────────────────────────────────────────────────────────────────┤ │struct nsaddr_list Address of name │ │sockaddr_in[MAXNS] server │ ├─────────────────────────────────────────────────────────────────┤ │unsigned short id Current packet id │ ├─────────────────────────────────────────────────────────────────┤ │char[MAXDNAME] defdname Default domain │ ├─────────────────────────────────────────────────────────────────┤ │char*[MAXDNSRCH+1] dnsrch Components of domain │ │ to search │ └─────────────────────────────────────────────────────────────────┘ The options field of the _res data structure is constructed by logically ORing the following values: RES_INIT Indicates whether the initial name server and default domain name have been initialized (that is, whether the res_init() call has been called). RES_DEBUG Prints debugging messages. RES_USEVC Uses Transmission Control Protocol/Internet Protocol (TCP/IP) connections for queries instead of User Datagram Protocol/Internet Protocol (UDP/IP). RES_STAYOPEN Used with the RES_USEVC value, keeps the TCP/IP connection open between queries. While UDP/IP is the mode normally used, TCP/IP mode and this option are useful for programs that regularly perform many queries. RES_RECURSE Sets the Recursion Desired bit for queries. This is the default. RES_DEFNAMES Appends the default domain name to single-label queries. This is the default. These environment variables affect values related to the _res data structure: LOCALDOMAIN Overrides the default local domain, which is read from the ETC\RESOLV.conf file and stored in the defdname field of the _res data structure. RES_TIMEOUT Overrides the default value of the retrans field of the _res data structure, which is the value of the RES_TIMEOUT constant defined in the file. This value is the base timeout period in seconds between queries to the name servers. After each failed attempt, the timeout period is doubled. The timeout period is divided by the number of name servers defined. The minimum timeout period is 1 second. RES_RETRY Overrides the default value for the retry field of the _res data structure, which is 4. This value is the number of times the resolver tries to query the name servers before giving up. Setting RES_RETRY to 0 prevents the resolver from querying the name servers. The res_send() call does not perform interactive queries and expects the name server to handle recursion. ═══ 4.7. Name Resolution ═══ The process of obtaining an internet address from a host name is known as name resolution and is done by the gethostbyname() call. The process of translating an internet address into a host name is known as reverse name resolution and is done by the gethostbyaddr() call. When a process receives a symbolic host name and needs to resolve it into an address, it calls a resolver routine. Resolver routines on hosts running TCP/IP attempt to resolve names using the following sources:  BIND/DNS (the DOMAIN name server, named)  Search local ETC\HOSTS file To resolve a name in a domain network, the resolver routine first queries the domain name server database, which may be local if the host is a domain name server or may be on a foreign host. Name servers translate domain names into internet addresses. The group of names for which a name server is responsible is its zone of authority. If the resolver routine is using a remote name server, the routine uses the Domain Name Protocol (DOMAIN) to query for the mapping. To resolve a name in a flat network, the resolver routine checks for an entry in the local ETC\HOSTS file. By default, resolver routines attempt to resolve names using the above resources. BIND/DNS will be tried first; if the ETC\RESOLV file does not exist or if BIND/DNS could not find the name, then the local ETC\HOSTS file is searched. If none of these services could find the name then the resolver routines return with HOST_NOT_FOUND. If all of the services were unavailable, then the resolver routines return with SERVICE_UNAVAILABLE. TCP/IP name servers use caching to reduce the cost of searching for names of hosts on remote networks. Instead of searching anew for a host name each time a request is made, a name server looks at its cache to see if the host name was resolved recently. Since domain and host names do change, each item remains in the cache for a limited length of time specified by the record's time-to-live (TTL). In this way, authorities can specify how long they expect the name resolution to be accurate. In a DOMAIN name server environment, the host name set using the hostname command from the command line or in the RC.NET file format must be the official name of the host as returned by the name server. Generally, this name is the full domain name of the host in the form: host.subdomain.subdomain.rootdomain If the host name is not set up as a fully qualified domain name, and if the system is set up to use a DOMAIN name server in conjunction with the sendmail program, the sendmail configuration file (ETC\SENDMAIL.CF) must be edited to reflect this official host name. In addition, the domain name macros in this configuration file must be set for the sendmail program to operate correctly. Note: The domain specified in the ETC\SENDMAIL.CF file takes precedence over the domain set by the hostname command for all sendmail functions. For a host that is in a domain network but is not a name server, the local domain name and domain name server are specified in the RESOLV file. In a DOMAIN name server host, the local domain and other name servers are defined in files read by the NAMED daemon when it starts. ═══ 4.8. Ports ═══ A port is used to differentiate between multiple applications on a host using the same protocol (TCP or UDP). It is an additional qualifier used by the system software to get data to the correct application. Physically, a port is a 16-bit integer. Some ports are reserved for particular applications and are called well-known ports. Well-Known Port Assignments contains the well-known port assignments list. ═══ 4.9. IP Multicasting ═══ This section presents general concepts as well as technical implementation details about IP multicasting. Multicasting enables a message to be transmitted to a group of hosts, instead of having to address and send the message to each group member individually. This reduces the traffic impact on networks with, for example, audio/video applications involving more than two participants. internet addressing provides for Class D addressing that is used for multicasting. Topics Multicasting and the setsockopt() Call A Socket Program Example ═══ 4.9.1. Multicasting and the setsockopt() Call ═══ When a datagram socket is defined, the setsockopt() call can be used to modify it. In order to join or leave a multicast group, use the setsockopt() call with the IP_ADD_MEMBERSHIP or IP_DROP_MEMBERSHIP flags. The interface that is used and the group used are specified in an ip_mreq structure that contains the following fields: struct ip_mreq{ struct in_addr imr_multiaddr; struct in_addr imr_interface; } The in_addr structure is defined as: struct in_addr{ ulong s_addr; } A host group consists of zero or more IP hosts. An IP datagram designated to a host group address will be delivered to all the current members of that group. A host group does not have a fixed membership. Any IP multicast-capable hosts can join or leave a host group dynamically. To join or leave a host group, an application needs to specify a host group address, ranging from 224.0.0.2 to 239.255.255.255, and a network interface address. (Note that 224.0.0.0 is reserved and 224.0.0.1 is permanently assigned to the all hosts group, which includes all hosts and routers participating in IP multicast.) It is possible to join the same host group on more than one network interface. It is also possible for more than one application to join the same host group. A host's IP module discards an incoming multicast datagram designated for a host group not joined on that incoming network interface, even though the same host group is joined on another network interface. In order to send to a multicasting group it is not necessary to join the groups. For receiving transmissions sent to a multicasting group membership is required. For multicast sending use an IP_MULTICAST_IF flag with the setsockopt() call. This specifies the interface to be used. An application can specify the time-to-live value of outgoing multicast datagrams. The default value is one for all IP multicast datagrams. An application can also specify whether a copy of the multicast datagram is looped back in the case where the host itself is a member of the destination host group. By default, a copy of the multicast datagram is looped back. It may be necessary to call the setsockopt() call with the IP_MULTICAST_LOOP flag in order to control the loopback of multicast packets. By default, packets are delivered to all members of the multicast group including the sender, if it is a member. However, this can be disabled with the setsockopt() call using the IP_MULTICAST_LOOP flag. For hosts that attach to more than one network, an application can choose which interface is used for the initial transmission. Only one interface can be used for the initial transmission. Further transmission to other networks is the responsibility of multicast routers. Do not be confused by the interface where a host group joins the outgoing interface for multicast transmission. The interface specified when joining or leaving a host group is mainly for receiving incoming multicast datagrams. An application can join one host group on one network interface but transmit data to the same host group by way of another interface. Currently multicast is supported only on UDP, so datagram sockets should be used to do multicast operations. One thing to consider is that using aliasing and multicasting together (with multiple processes) may give unexpected results, and the following limitations apply.  More than one socket can bind on Class D IP address (or mcast address) and a common port; for example, two clients that want to receive the same mcast packet.  These sockets must also set a socket option, SO_REUSEADDR. The setsockopt() call flags that are required for multicast communication and used with the IPPROTO_IP protocol level follow: IP_ADD_MEMBERSHIP Joins a multicast group as specified in the optval parameter of type struct ip_mreq. A maximum of 20 groups may be joined per socket. IP_DROP_MEMBERSHIP Leaves a multicast group as specified in the optval parameter of type struct ip_mreq. Only allowable for processes with UID=0. IP_MULTICAST_IF Permits sending of multicast messages on an interface as specified in the optval parameter of type struct in_addr. An address of INADDR_ANY (0x000000000) removes the previous selection of an interface in the multicast options. If no interface is specified then the interface leading to the default route is used. IP_MULTICAST_LOOP Sets multicast loopback, determining whether or not transmitted messages are delivered to the sending host. An optval parameter of type uchar is used to control loopback being on or off. IP_MULTICAST_TTL Sets the time-to-live for multicast packets. An optval parameter of type uchar is used to set this value between 0 and 255. The getsockopt() function can also be used with the multicast flags to obtain information about a particular socket: IP_MULTICAST_IF Retrieves the interface's IP address. IP_MULTICAST_LOOP Retrieves the specified looping mode from the multicast options. IP_MULTICAST_TTL Retrieves the time-to-live in the multicast options. The following examples demonstrate the use of the setsockopt() call with the protocol level set to the Internet Protocol (IPPROTO_IP). To mark a socket for sending to a multicast group on a particular interface: struct ip_mreq imr; setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &imr.imr_interface, sizeof(struct in_addr)); To disable the loopback on a socket: char loop = 0; setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(uchar)); To allow address reuse for binding multiple multicast applications to the same IP group address: int on = 1; setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(int)); To join a multicast group for receiving: struct ip_mreq imr; setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof(struct ip_mreq)); To leave a multicast group: struct ip_mreq imr; setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &imr, sizeof(struct ip_mreq)); ═══ 4.9.2. A Socket Program Example ═══ Following is an example of a socket application using IP multicasting. struct sockaddr_in *to = (struct sockaddr_in *)&group; /* group address */ struct sockaddr_in listen_addr; struct ip_mreq imr; /* multicast request structure */ struct in_addr ifaddr; /* multicast outgoing interface */ short loop = 0; /* don't loop back */ short ttl = 16; /* multicast time-to-live */ sock_init(); /* init */ imr.imr_multiaddr.s_addr = 0xe0010101; /* 224.1.1.1 */ imr.imr_multiaddr.s_addr = htonl(imr.imr_multiaddr.s_addr); imr.imr_interface.s_addr = INADDR_ANY; imr.imr_interface.s_addr = htonl(imr.imr_interface.s_addr); ifaddr.s_addr = INADDR_ANY; ifaddr.s_addr = htonl(ifaddr.s_addr); bzero( (char *)&group, sizeof(struct sockaddr_in) ); to->sin_family = AF_INET; to->sin_port = 1201; /* some port number */ to->sin_port = htons(to->sin_port); to->sin_addr.s_addr = imr.imr_multiaddr.s_addr; listen_addr = (*to); sock = socket(AF_INET, SOCK_DGRAM, 0); if (sock <= 0) { psock_errno("Bad socket"); exit(1); } /* join group */ if( setsockopt( sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof(struct ip_mreq) ) == -1 ) { psock_errno( "can't join group" ); exit(1); } /* set multicast options */ if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, &ifaddr, sizeof(ifaddr)) == -1) { perror ("can't set multicast source interface"); exit(1); } if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, 1) == -1)) { psock_errno ("can't disable multicast loopback"); exit(1); } if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, 1) == -1)) { psock_errno ("can't set multicast ttl"); exit(1); } /* bind to a group address */ if (bind(sock, &listen_addr, sizeof(struct sockaddr_in)) != 0) { psock_errno("Binding multicast socket"); exit(1); } . . . /* leave group */ if( setsockopt( sock, IPPROTO_IP, IP_DROP_MEMBERSHIP, &imr, sizeof(struct ip_mreq) ) == -1 ) { psock_errno( "can't leave group" ); exit(1); } . . . ═══ 4.10. Socket Secure Support ═══ OS/2 supports Socket Secure Support (SOCKS) Version 4. This section presents information about OS/2 SOCKSification. Topics The SOCKS Server The SOCKS Library ═══ 4.10.1. The SOCKS Server ═══ A SOCKS server is a type of firewall that protects computers in a network from access by users outside that network. A SOCKS server is similar to a proxy gateway in that they both work as proxy agents but their approaches are different. OS/2 SOCKS support for TCP/IP applications allows client applications to interact with a SOCKS server. OS/2 SOCKSified DLLs get the necessary information from socks.cfg. The DLL checks to determine if the connection should go through SOCKS. If socks_flag is on in socks.env and socks.cfg indicates that the connection should go through socks, then the connection goes through SOCKS. Otherwise, the connection does not go through SOCKS. The following figure illustrates how a typical write() to a socket would appear. A Typical Write() to a SOCKS Server With SOCKS support, client applications connect to the SOCKS server and then the SOCKS server connects to an external network. The SOCKS server verifies that a host name and user ID are allowed to access an internet. If you are using a SOCKS server, connect() will call Rconnect(). See connect() for information about the connect() call. The following figure illustrates connect(). connect() Request From the user's point of view (behind the firewall host within the local area network), there is no difference between running SOCKS and the regular client software on a host. All connections at the application level appear to work the same, with the hidden difference that all traffic is passing through sockd on the firewall host. This transparency is achieved through the Socks library routines. Connect requests are originated by a call to Rconnect() on the internal host. This causes sockd to establish a connection to the remote host and return a success or fail response. At this point, the application can read and write to the socket connection to the firewall and sockd acts as a bridge between the local and external socket connections. ═══ 4.10.2. The SOCKS Library ═══ The SOCKS library calls establish connections to sockd on the firewall and transmit information. The sockd daemon performs the operation as if it were originating the request. Any data sockd receives from the external connection is then passed on to the original requestor. To the internal host everything appears as usual, but to the external host sockd appears to be the originator of the communication. The SOCKS library routines pass all network connections to sockd, which is running on the firewall. The functions that are provided are designated by the letter R preceding the name of the regular C library socket calls that they are replacing. The SOCKS routines take the same parameters as the original functions, with the exception of Rbind(). Rbind() has an additional parameter: the address of the remote host from which the connection is established. The following routines are supported: Routine Parameters Raccept (int socket, struct sockaddr*addr, int addrlen) Rbind (int socket, struct sockaddr*name, int namelen, struct sockaddr*remote) Rconnect (int socket, struct sockaddr*name, int namelen) Rgethostbyname (char *host) Rgetsockname (int socket, struct sockaddr*name, int namelen) Rlisten (int socket, int backlog) See the information for the regular calls in Protocol-Independent C Sockets API. The following figure shows how a gethostbyname() call works. gethostbyname The following figure shows how an Rbind() request works. Rbind() Request ═══ 5. Sockets over Local IPC ═══ This section describes how sockets over Local Inter-Processor Communication (IPC) allow the programmer to communicate between applications on the same machine using the sockets API. Local IPC sockets are not bound to a network protocol but rather use the underlying host facilities to provide high-performance IPC. Topics Getting Started with Sockets Over Local IPC Local IPC Address Format ═══ 5.1. Getting Started with Sockets Over Local IPC ═══ This section provides some basic information for getting started with sockets over Local IPC:  Use PF_OS2, or PF_UNIX for the protocol family  Use AF_OS2, or AF_UNIX for the address family  The following socket types are supported for the Local IPC domain: - Datagram (SOCK_DGRAM) - Stream (SOCK_STREAM) The socket type is passed as a parameter to the socket() call. For additional information, see Socket Types.  A unique text string is used as a name. See Local IPC Address Format for details.  If a connect() socket call is received without an explicit bind() call, an implicit bind is automatically performed. The application can use any name, and a unique Local IPC name is generated by networking services. You can retrieve the Local IPC name by using the getsockname() call. ═══ 5.2. Local IPC Address Format ═══ A socket address in a local system is composed of three fields in the following sockaddr_un structure: length, address family, and path name. The structure is located in the header file: struct sockaddr_un { u_short sun_family; /* AF_OS2 or AF_UNIX */ char sun_path[108]; /* path name */ }; struct sockaddr_un un; The sun_family field is set to AF_OS2 or AF_UNIX. The sun_path field is the OS/2 Warp file and path name to be used as the address of the Local IPC socket. If the address is NULL, the bind call binds a unique local address to the socket descriptor s. Each address is a combination of address family (sun_family) and a character string (sun_path) no longer than 108 characters. Each socket must use a unique character string as its local name to bind a name to a socket. The name in sun_path should begin with "\socket\". For example, struct sockaddr_un un; int sd; sd = socket(PF_OS2, SOCK_STREAM, 0); memset(&un, 0, sizeof(un)); un.sun_family=AF_OS2; strcpy(un.sun_path, "\socket\XYZ", 12); bind(sd, (struct sockaddr *)&un, sizeof(un)); ═══ 6. Sockets over NetBIOS ═══ This section describes the use of sockets with NetBIOS. Each application assigns itself one or more NetBIOS names for each adapter. The NetBIOS protocol maintains a table of the names that a node is known by on the network. NetBIOS supports two types of names: unique and group. When the name is unique, the application binds the name and NetBIOS checks the network to ensure that the name is not already being used as a unique name. NetBIOS supports multicast by allowing applications to bind to a group name and communicate. Topics Getting Started with Sockets Over NetBIOS NetBIOS Address Format ═══ 6.1. Getting Started with Sockets Over NetBIOS ═══ This section provides some basic information for getting started with sockets over NetBIOS:  Use PF_NETBIOS or PF_NB for the protocol family.  Use AF_NETBIOS or AF_NB for the address family.  The following socket types are supported for the NetBIOS domain: - Datagram (SOCK_DGRAM) - Sequenced packet (SOCK_SEQPACKET) The socket type is passed as a parameter to the socket() call. For additional information see Socket Types.  If a connect() socket call is received without an explicit bind() call, an implicit bind is automatically performed. In this case, the application does not care about its own name, and a unique NetBIOS name is generated by networking services. You can retrieve the NetBIOS name by using the getsockname() call.  Applications using the NetBIOS communication domain can use sockets in both a connection-oriented (sequenced packet) and connectionless (datagram) mode.  A NetBIOS application on one workstation can use sockets to communicate with an NCB NetBIOS application on a different workstation. ═══ 6.2. NetBIOS Address Format ═══ A socket address in a NetBIOS address family is composed of the six fields in the following sockaddr_nb structure: length, address family, address type, a reserved field, adapter number, and NetBIOS name. This structure is located in the header file: struct sockaddr_nb { u_short snb_family; /* AF_NETBIOS */ short snb_type; /* 0=unique or 1=group */ char snb_nbnetid[NB_NETIDLEN]; /* RESERVED */ unsigned short snb_adapter; /* adapter number */ char snb_name[NAMELEN]; /* NetBIOS name */ } The snb_family field is set to AF_NETBIOS or AF_NB. The address type field (snb_type) is used to specify the name as either a unique (NB_UNIQUE) or a group (NB_GROUP) name. The snb_adapter field contains the adapter number that the name is associated with. The adapter number must be a numeric value in the range 0-255. The snb_name field contains the 16-byte NetBIOS name, and is used as is. If a connect() socket call is received without an explicit bind() call, an implicit bind is automatically performed. The application can use any name, and a unique NetBIOS name is generated by the system. A NetBIOS name is generated for this socket by converting the 6-byte MAC address to an ASCII hex string, and postpended with a 2-byte number that increments after each use. You can retrieve the NetBIOS name by using the getsockname() call. Note that for the NetBIOS domain, more than one socket can be bound to the same local address to establish multiple connections to one or more remote destinations. To enable this feature, the socket option SO_REUSEADDR must be set (see setsockopt()). In addition, you can bind more than one address to the same adapter. ═══ 7. Windows Sockets Version 1.1 for OS/2 ═══ This section presents information for implementing OS/2 applications that use the Windows Sockets, or Winsock, API. OS/2 supports two varieties of the Winsock API: one for use by 32-bit Developer API Extensions (Open32) applications, and another for use by 32-bit PM applications and 32-bit Command Line (VIO) applications. Except for the specific differences listed in this section, these implementations comply with the Windows Sockets Version 1.1 specification, and corrections or amplifications as described in the draft Windows Sockets Version 2.0 specification. Topics Overview Blocking Hook Support Asynchronous Functions Differences between OS/2 WInsock and the Winsock 1.1 Specification Using the Winsock 1.1 for OS/2 Trace Command and Trace Formatter Where to Find Winsock Reference Information ═══ 7.1. Overview ═══ Winsock for OS/2 consists of two DLLs: PMWSOCK.DLL for the 32-bit PM and 32-bit VIO environments DAPWSOCK.DLL for the Open32 environment Two header files, and , which are tailored to the PM and Open32 environments respectively, are included. is similar to but has changes to data types and function prototypes to accommodate PM. is also used by VIO applications. ═══ 7.2. Blocking Hook Support ═══ Blocking hooks were introduced in Winsock to support Windows 3.x's non-preemptive multitasking. When an application issues a blocking sockets call, Winsock starts processing the call and then enters a loop where it alternates between calling a blocking hook and checking to see if the socket call has completed or been cancelled. The blocking hook is responsible for dispatching messages to keep the system responsive while the socket call is processing. Blocking hooks are installed on a per-thread basis. In Win32 systems, blocking hooks aren't necessary because Win32 systems support preemptive multitasking. Consequently, Win32 versions of Winsock do not provide a default blocking hook, and using blocking hooks is discouraged. Nonetheless, an application programmer can call WSASetBlockingHook to install one. In the OS/2 implementation of Winsock, when a call is made to a Winsock function that blocks and a blocking hook has been installed in that thread, a new thread is started to issue the socket call. The original thread then starts spinning in a loop, alternating between calling the user's blocking-hook function and checking to see if the socket call has completed or has been cancelled. A half-second sleep is inserted between each iteration of the loop to avoid consuming large amounts of CPU time. When the socket call completes, or is cancelled, the new thread passes the results of the socket call to the original thread and then ends. When a call is made to a Winsock function that blocks and a blocking hook has not been installed for that thread, the socket call is issued directly and no threads are started. ═══ 7.3. Asynchronous Functions ═══ Asynchronous functions were added to Winsock to make sockets friendlier to the GUI programmer. When an application issues an asynchronous Winsock call, Winsock starts processing the call and immediately returns to the caller. When the call completes, Winsock posts a message to the application's message queue to inform the application of the results of the function. For the OS/2 implementation of Winsock, asynchronous calls are handled similarly to the way blocking hooks are handled. Each call to an asynchronous Winsock function causes a secondary thread to issue the socket call. The original thread then returns to the application. When the socket call returns, the secondary thread posts a message to the appropriate message queue. To avoid creating and terminating many threads, the asynchronous calls maintain a small pool of threads that are dedicated to servicing asynchronous calls. The threads are created as needed and are not terminated until the application ends. When the application issues an asynchronous call, Winsock determines if there is a free thread in the pool. If a free thread exists, Winsock uses it to service the call. If there is not a free thread in the pool, Winsock checks to see if the maximum number of threads that can fit in the pool has been started. If the maximum number of threads has not been started, Winsock starts a new thread, adds it to the pool, and has the new thread service the socket call. If no free threads are in the pool and the pool is filled to capacity, Winsock starts a new thread to service the call. After the call completes and the message has been posted, the new thread terminates. ═══ 7.4. Differences between OS/2 WInsock and the Winsock 1.1 Specification ═══ This section describes the differences between the TCP/IP for OS/2 implementation of Winsock and the Winsock 1.1 specification. WSASetLastError and WSAGetLastError APIs The Winsock specification states that on Win32 systems, WSAGetLastError and WSASetLastError will simply call the Win32 GetLastError and SetLastError functions. For reasons of efficiency, the Open32 version of OS/2 Winsock implements these two calls internally and does not call GetLastError or SetLastError. Also because PM does not have a function that is equivalent to SetLastError, the PM version of Winsock also implements these calls internally. BSD Compatibility Files The Winsock 1.1 specification states that the standard , , , , and header files should be supplied by Winsock implementations and should just include . Because TCP/IP for OS/2 also supplies a BSD socket library, it does not comply with the specification in this regard. If a developer includes any of those header files, the developer will get the BSD version of those header files, not the Winsock version. Calling Conventions In the Winsock 1.1 specification, Winsock calls are defined to use the PASCAL calling convention (the standard calling convention on Windows systems). OS/2 also has the PASCAL calling convention, but instead it uses APIENTRY as the standard calling convention. Because of this, OS/2 Winsock uses the APIENTRY convention for all of its Winsock calls. In the Open32 environment, PASCAL is defined (with #define) to be APIENTRY by , which is part of Open32, so no changes are needed to to accommodate APIENTRY. In the PM and VIO environments, PASCAL and APIENTRY are two different calling conventions, so the Winsock function prototypes in have been modified by replacing all occurrences of PASCAL with APIENTRY. ═══ 7.4.1. Differences between and Standard Header Files ═══ Following are the differences between and standard header files:  does not include (with #include) any header files.  The keyword FAR has been removed from all functions and pointers.  The keyword PASCAL has been removed from all of the prototypes and replaced with APIENTRY.  The FARPROC type in the WSASetBlockingHook prototype has been replaced with PFN.  The hostent, netent, servent, and protoent structures had several entries that were defined as "short;" these have been widened to "int." The two fields of the linger structure have been widened from "u_short" to "int." These changes were made to comply with the definitions in the BSD header files.  A bug in the IN_CLASSC macro has been corrected.  The CONST keyword for the buf parameter of the prototype for WSAAsyncGetHostByAddr has been removed (it was an error). ═══ 7.4.2. Differences between IBM Open32 and Standard Header Files ═══ Following are the differences between IBM Open32 and :  includes instead of .  The keyword FAR has been removed from all functions and pointers.  The hostent, netent, servent, and protoent structures had several entries that were defined as "short." These have been widened to "int." The two fields of the linger structure have been widened from "u_short" to "int." These changes were made to comply with the definitions in the BSD header files.  A bug in the IN_CLASSC macro has been corrected.  The CONST keyword for the buf parameter of the prototype for WSAAsyncGetHostByAddr has been removed (it was an error). ═══ 7.5. Using the Winsock 1.1 for OS/2 Trace Command and Trace Formatter ═══ Winsock 1.1 for OS/2 includes tracing capability to aid Winsock developers in isolating problems related to one of the following:  The client application  The Winsock 1.1 DLL Topics Sample Winsock Trace Output WSTRACE Command WSFORMAT Command ═══ 7.5.1. Sample Winsock Trace Output ═══ Using the trace capability, developers can trace Winsock procedure calls and exits, parameter values, and return values. Following is a sample of formatted Winsock trace output: Winsock Trace - Version 1 Trace Date 05/07/1996 Trace Time 14:04:51.28 Thread TimeStamp Winsock Function (Parameters) ------------------------------------------------------------------------------- 00001 14:04:51.35 WSAISBLOCKING Entry () 00001 14:04:51.35 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:04:51.35 WSASTARTUP Exit (wVersionRequired=101, lpWSADATA=4B00C Return=0) 00001 14:04:51.35 GETHOSTNAME Entry () 00001 14:04:51.35 WSAISBLOCKING Entry () 00001 14:04:51.35 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:04:51.35 GETHOSTNAME Exit (Return=0, Hostname=screamin) 00001 14:04:51.38 INET_NTOA Entry (in_addr=4263781641) 00001 14:04:51.38 INET_NTOA Exit (in_addr=4263781641, Return=9.37.36.254) 00001 14:04:57.25 SOCKET Entry (address family=2[af_inet], type=1[sock_stream], protocol=0[ip]) 00001 14:04:57.25 WSAISBLOCKING Entry () 00001 14:04:57.25 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:04:57.25 SOCKET Exit (address family=2[af_inet], type=1[sock_stream], protocol=0[ip] Return=187) 00001 14:05:05.88 GETHOSTNAME Entry () 00001 14:05:05.88 WSAISBLOCKING Entry () 00001 14:05:05.88 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:05:05.88 GETHOSTNAME Exit (Return=0, Hostname=screamin) 00001 14:05:11.03 HTONS Entry (host=0) 00001 14:05:11.03 HTONS Exit (host=0, Return=0) 00001 14:05:11.03 BIND Entry (socket=187, sockaddr struct[family=2 (af_inet), port=0, s_addr=9.37.36.254]) 00001 14:05:11.03 WSAISBLOCKING Entry () 00001 14:05:11.03 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:05:11.03 BIND Exit (socket=187, sockaddr struct[family=2 (af_inet), port=0, s_addr=9.37.36.254] Return=0) 00001 14:05:19.31 CLOSESOCKET Entry (Socket=187) 00001 14:05:19.31 WSAISBLOCKING Entry () 00001 14:05:19.31 WSAISBLOCKING Exit (False : No blocking call in progress) 00001 14:05:19.31 CLOSESOCKET Exit (Socket=187, Return=0) 00001 14:05:28.91 WSACLEANUP Entry () 00001 14:05:28.91 WSAISBLOCKING Entry () 00001 14:05:28.91 WSAISBLOCKING Exit (False : No blocking call in progress) The following sections provide details for using the Winsock 1.1 for OS/2 trace command and trace formatter. ═══ 7.5.2. WSTRACE Command ═══ The WSTRACE command enables and disables Winsock tracing in an OS/2 session. Syntax ┌─on──┐ ┌─64───────────┐ ─WSTRACE───┼─────┼─┬──────────────────┬─┼──────────────┼───── └─off─┘ ├─┬──────────┬─────┤ └─ -b buffsize─┘ │ ├─filename─┤ │ │ ├─COM1─────┤ │ │ ├─COM2─────┤ │ │ ├─COM3─────┤ │ │ └─COM4─────┘ │ │ ┌─WSTRACE──┐│ └─ -p ─┼──────────┼┘ └─pipename─┘ Parameters on Turns tracing on. This is the default. off Turns tracing off. filename Specifies the file name of the file that the trace output will be written to. COM1, COM2, COM3, and COM4 may be used to direct the trace to a serial port. -p pipename Specifies the pipe name of an OS/2 pipe that the trace output will be written to. Pipe names do not have to include a \PIPE\ prefix. If pipename is not specified with the -p parameter, the pipe name defaults to WSTRACE. -b buffsize Specifies the size of the global trace buffer. If the -b parameter is not specified, the buffer size defaults to 64 KB. Notes: 1. When neither filename nor pipename is specified, trace output is written by default to the file WSTRACE.DMP in the local directory. 2. When a pipe or COM port is specified as the destination for tracing information, start the WSFORMAT command in an OS/2 session on the destination device before running the Winsock application to be traced. 3. When specifying a serial port as the Winsock trace device, be sure that the serial port settings match on both ends of the line. The OS/2 MODE command lets you set the serial port settings. For more information about the MODE command, see the OS/2 Command Reference or enter: help mode in an OS/2 session. ═══ 7.5.3. WSFORMAT Command ═══ The WSFORMAT command is the Winsock trace formatter. The WSFORMAT command accepts the binary trace input from a serial port, file, or OS/2 pipe, and converts the input into a readable format that can then be displayed on-screen or written to a file, serial port, or OS/2 pipe. Syntax ─WSFORMAT───┬────────────────────────┬──────────────────────── ├─┬────────────────┬─────┤ │ ├─input_filename─┤ │ │ ├─COM1───────────┤ │ │ ├─COM2───────────┤ │ │ ├─COM3───────────┤ │ │ └─COM4───────────┘ │ │ ┌─WSTRACE────────┐│ └─ -p ─┼────────────────┼┘ └─input_pipename─┘ ┌─WSFORMAT.DMP──────────────────┐ ──┼───────────────────────────────┼──────────────────────────── └─ -f formatted_output_filename─┘ ┌─WSTRACE.DMP────────────────┐ ──┼────────────────────────────┼────────────────────────────── └─ -b binary_output_filename─┘ Parameters input_filename Specifies the file name of the input file containing the trace information to format. COM1, COM2, COM3, and COM4 may be used to accept trace data from a serial port. -p input_pipename Specifies the pipe name of the OS/2 pipe that contains the trace data to format. Pipe names do not have to include a \PIPE\ prefix. If input_pipename is not specified with the -p parameter, the pipe name defaults to WSTRACE. -f formatted_output_file Specifies the file name of the file that the formatted trace output will be written to. If formatted_output_file is not specified with the -f parameter, the file name defaults to WSFORMAT.DMP in the current directory. -b binary_output_file Specifies the file name of the file that will receive a copy of the binary information being formatted. This can be used to save a copy of the trace information coming from a serial port or pipe. If binary_output_file is not specified with the -b parameter, the output file name defaults to WSTRACE.DMP in the local directory. Notes: 1. If the -f option is not specified, the formatted trace output is written to the screen. 2. When specifying a serial port as the Winsock trace device, be sure that the serial port settings match on both ends of the line. The OS/2 MODE command lets you set the serial port settings. For more information about the MODE command, see the OS/2 Command Reference or enter: help mode in an OS/2 session. ═══ 7.6. Where to Find Winsock Reference Information ═══ To obtain Winsock reference information, including socket and database routines and Microsoft Windows-specific extensions, consult the Windows Sockets specification. This specification is documented by authors from a number of corporations and is available from many places, including:  The IBM TCP/IP for OS/2 Programmer's Development Toolkit on the IBM Developer's Connection CD-ROM ( Windows Sockets Version 1.1 only)  The Internet, at URL http://www.stardust.com ( Windows Sockets Version 1.1 only)  Directory /pub/winsock on host microdyne.com by way of anonymous ftp To be added to the Windows Sockets mailing list, address your request to winsock-request@microdyne.com. ═══ 8. Remote Procedure Calls ═══ This section describes the high-level remote procedure calls (RPCs) implemented in TCP/IP for OS/2, including the RPC programming interface to the C language and communication between processes. Topics The RPC Protocol The RPC Interface Remote Programs and Procedures Portmapper eXternal Data Representation (XDR) The RPC Intermediate Layer The RPC Lowest Layer rpcgen Command rpcinfo Command The enum clnt_stat Structure The Remote Procedure Call Library Differences between OS/2 and Sun Microsystems RPCs Compiling an RPC API Application ═══ 8.1. The RPC Protocol ═══ The RPC protocol enables remote execution of subroutines across a TCP/IP network. RPC, together with the eXternal Data Representation (XDR) protocol, defines a standard for representing data that is independent of internal protocols or formatting. RPCs can communicate between processes on the same or different hosts. The RPC protocol enables users to work with remote procedures as if the procedures were local. The remote procedure calls are defined through routines contained in the RPC protocol. Each call message is matched with a reply message. The RPC protocol is a message-passing protocol that implements other non-RPC protocols, such as batching and broadcasting remote calls. The RPC protocol also supports callback procedures and the select subroutine on the server side. RPC provides an authentication process that identifies the server and client to each other. RPC includes a slot for the authentication parameters on every remote procedure call so that the caller can identify itself to the server. The client package generates and returns authentication parameters. RPC supports various types of authentication, such as the UNIX systems. In RPC, each server supplies a program that is a set of procedures. The combination of a host address, a program number, and a procedure number specifies one remote service procedure. In the RPC model, the client makes a procedure call to send a data packet to the server. When the packet arrives, the server calls a dispatch routine, performs whatever service is requested, and sends a reply back to the client. The procedure call then returns to the client. RPC is divided into two layers: intermediate and lowest. Generally, you use the RPC interface to communicate between processes on different workstations in a network. However, RPC works just as well for communication between different processes on the same workstation. The Portmapper program maps RPC program and version numbers to a transport-specific port number. The Portmapper program makes dynamic binding of remote programs possible. To write network applications using RPC, programmers need a working knowledge of network theory and C programming language. For most applications, understanding the RPC mechanisms usually hidden by the RPCGEN protocol compiler is also helpful. However, RPCGEN makes understanding the details of RPC unnecessary. The figures in The RPC Interface give an overview of the high-level RPC client and server processes from initialization through cleanup. See the SAMPLES\RPC directory for sample RPC client, server, and raw data stream programs. RPCGEN samples are in the SAMPLES\RPCGEN directory. For more information about the RPC and XDR protocols, see the Sun Microsystems publication, Networking on the Sun Workstation: Remote Procedure Call Programming Guide , RFC 1057 and RFC 1014. ═══ 8.2. The RPC Interface ═══ The RPC model is similar to the local procedure call model. In the local model, the caller places the argument to a procedure in a specified location such as a result register. Then, the caller transfers control to the procedure. The caller eventually regains control, extracts the results of the procedure, and continues the execution. RPC works in the same way: One thread of control winds logically through the caller and server processes as follows: 1. The caller process sends a call message that includes the procedure parameters to the server process and then waits for a reply message (blocks). 2. A process on the server side, which is dormant until the arrival of the call message, extracts the procedure parameters, computes the results, and sends a reply message. Then the server waits for the next call message. 3. A process on the caller side receives the reply message and extracts the results of the procedure. The caller then resumes the execution. See the following figures for an illustration of the RPC model: Remote Procedure Call (Client) Remote Procedure Call (Server) ═══ 8.3. Remote Programs and Procedures ═══ The RPC call message has three unsigned fields:  Remote program number  Remote program version number  Remote procedure number The three fields uniquely identify the procedure to be called. The program number defines a group of related remote procedures, each of which has a different procedure number. Each program also has a version number. The central system authority administers the program number. A remote program number is assigned by groups of 0x20000000, as shown in the following list: Program Number Description 0-1xxxxxxx Is predefined and administered by the OS/2 TCP/IP system. 20000000-3xxxxxxx Represents the user defined numbers 40000000-5xxxxxxx Represents transient numbers 60000000-7xxxxxxx Reserved 80000000-9xxxxxxx Reserved a0000000-bxxxxxxx Reserved c0000000-dxxxxxxx Reserved e0000000-fxxxxxxx Reserved ═══ 8.4. Portmapper ═══ This section describes the Portmapper service and its uses. Topics Portmapper Protocol Registering and Unregistering a Port with Portmapper Contacting Portmapper Portmapper Procedures ═══ 8.4.1. Portmapper Protocol ═══ The Portmapper protocol defines a network service that clients use to look up the port number of any remote program supported by the server. The client programs must find the port numbers of the server programs that they intend to use. The Portmapper program:  Maps RPC program and version numbers to transport specific port numbers.  Enables dynamic binding of remote programs. This is desirable because the range of reserved port numbers is small, and the number of potential remote programs is large. When running only the Portmapper program on a reserved port, you can determine the port numbers of other remote programs by querying Portmapper.  Supports both the UDP and TCP protocols. The RPC client contacts Portmapper on port number 111 on either of these protocols. ═══ 8.4.2. Registering and Unregistering a Port with Portmapper ═══ Portmapper is the only network service that must have a dedicated port (111). Other RPC network services can be assigned port numbers statically or dynamically, if the services register their ports with the host's local Portmapper. The RPC server can register or unregister their services by using the following calls: svc_register() Associates a program with the service dispatch routine svc_unregister() Removes all local mappings to dispatch routines and port numbers registerrpc() Registers a procedure with the local Portmapper and creates a control structure to remember the server procedure and its XDR routine ═══ 8.4.3. Contacting Portmapper ═══ To find the port of a remote program, the client sends an RPC request to well-known port 111 of the server's host. If Portmapper has a port number entry for the remote program, Portmapper provides the port number in the RPC reply. The client then requests the remote program by sending an RPC request to the port number provided by Portmapper. Clients can save port numbers of recently called remote programs to avoid having to contact Portmapper for each request to a server. RPC also provides the following calls for interfacing with Portmapper: Call Description pmap_getmaps() Returns a list of current program-to-port mappings on the foreign host pmap_getport() Returns the port number associated with the remove program, version, and transport protocol pmap_rmtcall() Instructs Portmapper to make an RPC call to a procedure on the host pmap_set() Sets the mapping of a program to a port on the local machine pmap_unset() Removes mappings associated with the program and version number on the local machine xdr_pmap() Translates an RPC procedure identification xdr_pmaplist() Translates a variable number of RPC procedure identifications ═══ 8.4.4. Portmapper Procedures ═══ The Portmapper program supports the following procedures: Procedure Description PMAPPROC_NULL Has no parameters. A caller can use the return code to determine if Portmapper is running. PMAPPROC_SET Registers itself with the Portmapper program on the same machine. It passes the:  Program number  Program version number  Transport protocol number  Port number The procedure has successfully established the mapping if the return value is TRUE. The procedure does not establish a mapping if one already exists. PMAPPROC_UNSET Unregisters the program and version numbers with Portmapper on the same machine. PMAPPROC_GETPORT Returns the port number when given a program number, version number, and transport protocol number. A port value of 0 indicates the program has not been registered. PMAPPROC_DUMP Takes no input, but returns a list of program, version, protocol, and port numbers. PMAPPROC_CALLIT Allows a caller to call another remote procedure on the same machine without knowing the remote procedure's port number. The PMAPPROC_CALLIT procedure sends a response only if the procedure is successfully run. ═══ 8.5. eXternal Data Representation (XDR) ═══ This section describes the eXternal Data Representation (XDR) standard and its use. Topics The XDR Standard Basic Block Size The XDR Subroutine Format XDR Data Types and their Filter Primitives XDR Filter Primitives XDR Nonfilter Primitives ═══ 8.5.1. The XDR Standard ═══ An eXternal Data Representation (XDR) is a data representation standard that is independent of languages, operating systems, manufacturers, and hardware architecture. This standard enables networked computers to share data regardless of the machine on which the data is produced or consumed. The XDR language permits transfer of data between diverse computer architectures. An XDR approach to standardizing data representations is canonical. That is, XDR defines a single byte (big endian), a single floating-point representation (IEEE), and so on. Any program running on any machine can use XDR to create portable data by translating its local representation to the XDR standards. Similarly, any program running on any machine can read portable data by translating the XDR standard representations to its local equivalents. The XDR standard is the backbone of the RPC, because data for remote procedure calls is sent using the XDR standard. To use XDR routines, C programs must include the header file, which is automatically included by the header file. ═══ 8.5.2. Basic Block Size ═══ The XDR language is based on the assumption that bytes (an octet) can be ported to, and encoded on, media that preserve the meaning of the bytes across the hardware boundaries of data. XDR does not represent bit fields or bit maps; it represents data in blocks of multiples of 4 bytes (32 bits). If the bytes needed to contain the data are not a multiple of four, enough (1 to 3) bytes to make the total byte count a multiple of four follow the n bytes. The bytes are read from, or written to, a byte stream in order. The order dictates that byte m precedes m+1. Bytes are ported and encoded from low order to high order in local area networks (LANs). Representing data in standardized formats resolves situations that occur when different byte-ordering formats exist on networked machines. This also enables machines with different structure-alignment algorithms to communicate with each other. ═══ 8.5.3. The XDR Subroutine Format ═══ An XDR routine is associated with each data type. XDR routines have the following format: xdr_xxx(xdrs,dp) XDR *xdrs; xxx *dp; { } The routine has the following parameters: xxx XDR data type. xdrs Opaque handle that points to an XDR stream. The system passes the opaque handle pointer to the primitive XDR routines. dp Address of the data value that is to be encoded or decoded. If they succeed, the XDR routines return a value of 1; if they do not succeed, they return a value of 0. ═══ 8.5.4. XDR Data Types and their Filter Primitives ═══ The XDR standard defines basic and constructed data types. The XDR filter primitives are routines that define the basic and constructed data types. The XDR language provides RPC programmers with a specification for uniform representation that includes filter primitives for basic and constructed data types. The basic data types include:  Integers  Enumeration  Booleans  Floating point decimals  Void  Constants  Typedef  Optional data The constructed data types include:  Arrays  Opaque data  Strings  Byte arrays  Structures  Discriminated unions  Pointers ═══ 8.5.5. XDR Filter Primitives ═══ The XDR standard translates both basic and constructed data types. For basic data types such as integer, XDR provides basic filter primitives that:  Serialize information from the local host's representation to XDR representation  Deserialize information from the XDR representation to the local host's representation For constructed data types, XDR provides constructed filter primitives that allow the use of basic data types (such as integers and floating-point numbers) to create more complex constructs (such as arrays and discriminated unions). Topics Integer Filter Primitives Enumeration Filter Primitives Floating-Point Filter Primitives Opaque Data Filter Primitive Array Filter Primitives String Filter Primitives Primitive for Pointers to Structures Primitive for Discriminated Unions Passing Routines without Data ═══ 8.5.5.1. Integer Filter Primitives ═══ The XDR filters cover signed and unsigned integers, as well as signed and unsigned short and long integers. The routines for XDR integer filters are: Routine Description xdr_int() Translates between C integers and their external representations xdr_u_int() Translates between C unsigned integers and their external representations xdr_long() Translates between C long integers and their external representations xdr_u_long() Translates between C unsigned long integers and their external representations xdr_short() Translates between C short integers and their external representations xdr_u_short() Translates between C unsigned short integers and their external representations ═══ 8.5.5.2. Enumeration Filter Primitives ═══ The XDR library provides a primitive for generic enumerations based on the assumption that a C enumeration value (enum) has the same representation. A special enumeration in XDR, known as the Boolean, provides a value of 0 or 1 represented internally in a binary notation. The routines for the XDR library enumeration filters are: Routine Description xdr_enum() Translates between C language enums and their external representations xdr_bool() Translates between Booleans and their external representations ═══ 8.5.5.3. Floating-Point Filter Primitives ═══ The XDR library provides primitives that translate between floating-point data and their external representations. Floating-point data encodes an integer with an exponent. Floats and double-precision numbers compose floating-point data. Note: Numbers are represented as Institute of Electrical and Electronics Engineers (IEEE) standard floating points. Routines might fail when decoding IEEE representations into machine specific representations. The routines for the XDR floating-point filters are: Routine Description xdr_float() Translates between C language floats and their external representations xdr_double() Translates between C language double-precision numbers and their external representations ═══ 8.5.5.4. Opaque Data Filter Primitive ═══ Opaque data is composed of bytes of a fixed size that are not interpreted as they pass through the data streams. Opaque data bytes, such as handles, are passed between server and client without being inspected by the client. The client uses the data as it is and then returns it to the server. By definition, the actual data contained in the opaque object is not portable between computers. The XDR library includes the following routine for opaque data: Routine Description xdr_opaque() Translates between opaque data and its external representation ═══ 8.5.5.5. Array Filter Primitives ═══ Arrays are constructed filter primitives that can be generic arrays or byte arrays. The XDR library provides filter primitives for handling both types of arrays. ═══ 8.5.5.5.1. Generic Arrays ═══ These consist of arbitrary elements. You use them in much the same way as byte arrays. The primitive for generic arrays requires an additional parameter to define the size of the element in the array and to call an XDR routine to encode or decode each element in the array. The XDR library includes the following routines for generic arrays: Routine Description xdr_array() Translates between variable-length arrays and their corresponding external representations xdr_vector() Translates between fixed-length arrays and their corresponding external representations ═══ 8.5.5.5.2. Byte Arrays ═══ These differ from strings by having a byte count. That is, the length of the array is set to an unsigned integer. They also differ in that byte arrays do not end with a null character. The XDR library provides a primitive for byte arrays. External and internal representations of byte arrays are the same. The XDR library includes the following routine for byte arrays: Routine Description xdr_bytes() Translates between counted byte string arrays and their external representations ═══ 8.5.5.6. String Filter Primitives ═══ A string is a constructed filter primitive that consists of a sequence of bytes terminated by a null byte. The null byte does not figure into the length of the string. Externally, strings are represented by a sequence of American Standard Code Information Interchange (ASCII) characters. Internally, XDR represents them as pointers to characters with the designation char *. The XDR library includes primitives for the following string routines: Routine Description xdr_string() Translates between C language strings and their external representations xdr_wrapstring() Calls the xdr_string subroutine ═══ 8.5.5.7. Primitive for Pointers to Structures ═══ The XDR library provides the primitive for pointers so that structures referenced within other structures can be easily serialized, deserialized, and released. The XDR library includes the following routine for pointers to structures: Routine Description xdr_reference() Provides pointer chasing within structures ═══ 8.5.5.8. Primitive for Discriminated Unions ═══ A discriminated union is a C language union, which is an object that holds several data types. One arm of the union contains an enumeration value (enum_t), or discriminant, that holds a specific object to be processed over the system first. The XDR library includes the following routine for discriminated unions: Routine Description xdr_union() Translates between discriminated unions and their external representations ═══ 8.5.5.9. Passing Routines without Data ═══ Sometimes an XDR routine must be supplied to the RPC system, but no data is required or passed. The XDR library provides the following primitive for this function: Routine Description xdr_void() Supplies an XDR subroutine to the RPC system without sending data ═══ 8.5.6. XDR Nonfilter Primitives ═══ Use the XDR nonfilter primitives to create, manipulate, implement, and destroy XDR data streams. These primitives allow you to:  Describe the data stream position  Change the data stream position  Destroy a data stream Topics Creating and Using XDR Data Streams Manipulating an XDR Data Stream Implementing an XDR Data Stream Destroying an XDR Data Stream ═══ 8.5.6.1. Creating and Using XDR Data Streams ═══ You get XDR data streams by calling creation routines that take arguments specifically designed for the properties of the stream. There are existing XDR data streams for serializing or deserializing data in standard input and output streams, memory streams, and record streams. Note: RPC clients do not have to create XDR streams, because the RPC system creates and passes these streams to the client. The types of data streams include:  Standard I/O streams  Memory streams  Record streams ═══ 8.5.6.1.1. Standard I/O Streams ═══ XDR data streams serialize and deserialize standard input/output( I/O) by calling the standard I/O creation routine to initialize the XDR data stream pointed to by the xdrs parameter. The XDR library includes the following routine for standard I/O data streams: Routine Description xdrstdio_create() Initializes the XDR data stream pointed to by the xdrs parameter ═══ 8.5.6.1.2. Memory Streams ═══ XDR data streams serialize and deserialize data from memory by calling the XDR memory creation routine to initialize, in local memory, the XDR stream pointed at by the xdrs parameter. In RPC, the UDP/IP implementation of remote procedure calls uses this routine to build entire call and reply messages in memory before sending the message to the recipient. The XDR library includes the following routine for memory data streams: Routine Description xdrmem_create() Initializes, in local memory, the XDR stream pointed to by the xdrs parameter ═══ 8.5.6.1.3. Record Streams ═══ Record streams are XDR streams built on top of record fragments, which are built on TCP/IP streams. TCP/IP is a connection protocol for transporting large streams of data at one time rather than transporting a single data packet at a time. The primary use of a record stream is to interface remote procedure calls to TCP connections. It can also be used to stream data into or out of normal files. XDR provides the following routines for use with record streams: Routine Description xdrrec_create() Provides an XDR stream that can contain long sequences of records xdrrec_endofrecord() Causes the current outgoing data to be marked as a record xdrrec_skiprecord() Causes the position of an input stream to move to the beginning of the next record xdrrec_eof() Checks the buffer for an input stream that identifies the end of file (EOF) ═══ 8.5.6.2. Manipulating an XDR Data Stream ═══ XDR provides the following routines for describing the data stream position and changing the data stream position: Routine Description xdr_getpos() Returns an unsigned integer that describes the current position in the data stream xdr_setpos() Changes the current position in the XDR stream ═══ 8.5.6.3. Implementing an XDR Data Stream ═══ You can create and implement XDR data streams. The following example shows the abstract data types (XDR handle) required for you to implement your own XDR streams. They contain operations applied to the stream (an operation vector for the particular implementation) and two private fields for using that implementation. enum xdr_op { XDR_ENCODE=0, XDR_DECODE=1, XDR_FREE=2 }; typedef struct xdr { enum xdr_op x_op; struct xdr_ops { bool_t (*x_getlong)(struct xdr *, long *); bool_t (*x_putlong)(struct xdr *, long *); bool_t (*x_getbytes)(struct xdr *, caddr_t, u_int); /* get some bytes from " */ bool_t (*x_putbytes)(struct xdr *, caddr_t, u_int); /* put some bytes to " */ u_int (*x_getpostn)(struct xdr *); bool_t (*x_setpostn)(struct xdr *,u_int); long * (*x_inline)(struct xdr *,u_int); void (*x_destroy)(struct xdr *); } *x_ops; caddr_t x_public; caddr_t x_private; caddr_t x_base; int x_handy; } XDR; The following parameters are pointers to XDR stream manipulation routines: Parameter Description x_getlong Gets long integer values from the data stream. x_putlong Puts long integer values into the data stream. x_getbytes Gets bytes from the data streams. x_putbytes Puts bytes into the data streams. x_getpostn Returns the stream offset. x_setpostn Repositions the offset. x_inline Points to an internal data buffer, used for any purpose. x_destroy Frees the private data structure. x_ops Specifies the current operation being performed on the stream. This field is important to the XDR primitives, but the stream's implementation does not depend on the value of this parameter. The following fields are specific to a stream's implementation: Field Description x_public Specific user data that is private to the stream's implementation and that is not used by the XDR primitive x_private Points to the private data x_base Contains the position information in the data stream that is private to the user implementation x_handy Data can contain extra information as necessary ═══ 8.5.6.4. Destroying an XDR Data Stream ═══ XDR provides a routine that destroys the XDR stream pointed to by the xdrs parameter and frees the private data structures allocated to the stream. Routine Description xdr_destroy() Destroys the XDR stream pointed to by the xdrs parameter The use of the XDR stream handle is undefined after it is destroyed. ═══ 8.6. The RPC Intermediate Layer ═══ The calls of the RPC intermediate layer are: Routine Description registerrpc() Registers a procedure with the local Portmapper callrpc() Calls a remote procedure on the specified system svc_run() Accepts RPC requests and calls the appropriate service using svc_getreq() The transport mechanism is the User Datagram Protocol (UDP). The UDP transport mechanism handles only arguments and results that are less than 8K bytes in length. At this level, RPC does not allow timeout specifications, choice of transport, or process control, in case of errors. If you need this kind of control, consider the lowest layer of RPC. With only these three RPC calls, you can write a powerful RPC-based network application. The sequence of events follows: 1. Use the registerrpc() call to register your remote program with the local Portmapper. See Portmapper for more information. The following is an example of an RPC server: /* define remote program number and version */ #define RMTPROGNUM (u_long)0x3fffffffL #define RMTPROGVER (u_long)0x1 #define RMTPROCNUM (u_long)0x1 #include #include main() { int *rmtprog(); /* register remote program with Portmapper */ registerrpc(RMTPROGNUM, RMTPROGVER, RMTPROCNUM, rmtprog, xdr_int, xdr_int); /* infinite loop, waits for RPC request from client */ svc_run(); printf("Error: svc_run should never reach this point \n"); exit(1); } int * rmtprog(inproc) /* remote program */ int *inproc; { int *outproc; ... /* Process request */ ... return (outproc); } The registerrpc() call registers a C procedure rmtprog, which corresponds to a given RPC procedure number. The registerrpc() call has six parameters:  The first three parameters are the program, version, and procedure numbers of the remote procedure to be registered.  The fourth parameter, rmtprog, is the name of the local procedure that implements the remote procedure.  The last two parameters, xdr_int, are the XDR filters for the remote procedure's arguments and results. After registering a procedure, the RPC server goes into an infinite loop waiting for a client request to service. 2. The RPC client uses callrpc() to make a service request to the RPC server. The following is an example of an RPC client using the callrpc() call: /* define remote program number and version */ #define RMTPROGNUM (u_long)0x3fffffffL #define RMTPROGVER (u_long)0x1 #define RMTPROCNUM (u_long)0x1 #include #include main() { int inproc=100, outproc, rstat; ... /* service request to host RPCSERVER_HOST */ if (rstat = callrpc("RPCSERVER_HOST", RMTPROGNUM, RMTPROGVER, RMTPROCNUM, xdr_int, (char *)&inproc, xdr_int, (char *)&outproc)!= 0) { clnt_perrno(rstat); /* Why callrpc() failed ? */ exit(1); } ... } The callrpc() call has eight parameters:  The first is the name of the remote server machine.  The next three parameters are the program, version, and procedure numbers.  The fifth and sixth parameters are an XDR filter, and an argument to be encoded and passed to the remote procedure.  The final two parameters are a filter for decoding the results returned by the remote procedure, and a pointer to the place where the procedure's results are to be stored. You handle multiple arguments and results by embedding them in structures. The callrpc() call returns 0 if it succeeds, otherwise nonzero. The exact meaning of the returned code is in the header file and is an enum clnt_stat structure cast into an integer. ═══ 8.7. The RPC Lowest Layer ═══ This section describes the lowest layer of RPC and when to use it. Topics When to Use the RPC Lowest Layer Server Side Program Client Side Program ═══ 8.7.1. When to Use the RPC Lowest Layer ═══ Use the lowest layer of RPC in the following situations:  You need to use TCP. The intermediate layer uses UDP, which restricts RPC calls to 8K bytes of data. TCP permits calls to send long streams of data.  You want to allocate and free memory while serializing or deserializing messages with XDR routines. No RPC call at the intermediate level explicitly permits freeing memory. XDR routines are used for memory allocation as well as for serializing and deserializing.  You need to perform authentication on the client side or the server side by supplying credentials or verifying them. ═══ 8.7.2. Server Side Program ═══ The following is an example of the lowest layer of RPC on the server side program: #define RMTPROGNUM (u_long)0x3fffffffL #define RMTPROGVER (u_long)0x1L #define LONGPROC 1 #define STRINGPROC 2 #define MAXLEN 100 #include #include #include main(argc, argv) int argc; char *argv[ ]; { int rmtprog(); SVCXPRT *transp; ... /* create TCP transport handle */ transp = svctcp_create(RPC_ANYSOCK, 1024*10, 1024*10); /* or create UDP transport handle */ /* transp = svcudp_create(RPC_ANYSOCK); */ if (transp == NULL) /* check transport handle creation */ { fprintf(stderr, "can't create an RPC server transport\n"); exit(-1); } /* If exists, remove the mapping of remote program and port */ pmap_unset(RMTPROGNUM, RMTPROGVER); /* register remote program (TCP transport) with local Portmapper */ if (!svc_register(transp, RMTPROGNUM, RMTPROGVER, rmtprog, IPPROTO_TCP)) /* or register remote program (UDP transport) with local Portmapper */ /* if (!svc_register(transp, RMTPROGNUM, RMTPROGVER, rmtprog,*/ /* IPPROTO_UDP)) */ { fprintf(stderr, "can't register rmtprog() service\n"); exit(-1); } svc_run(); printf("Error:svc_run should never reaches this point \n"); exit(1); } rmtprog(rqstp, transp) /* code for remote program */ struct svc_req *rqstp; SVCXPRT *transp; { long in_long,out_long; char buf[100], *in_string=buf, *out_string=buf; ... switch((int)rqstp->rq_proc) /* Which procedure ? */ { case NULLPROC: if (!svc_sendreply(transp,xdr_void, 0)) { fprintf(stderr,"can't reply to RPC call\n"); exit(-1); } return; case LONGPROC: ... /* Process the request */ if (!svc_sendreply(transp,xdr_long,&out_long)) { fprintf(stderr,"can't reply to RPC call\n"); exit(-1); } return; case STRINGPROC: /* send received "Hello" message back */ /* to client */ svc_getargs(transp,xdr_wrapstring,(char *)&in_string); strcpy(out_string,in_string); /* send a reply back to a RPC client */ if (!svc_sendreply(transp,xdr_wrapstring, (char *)&out_string)) { fprintf(stderr,"can't reply to RPC call\n"); exit(-1); } return; case ... : ... /* Any Remote procedure in RMTPROGNUM program */ ... default: /* Requested procedure not found */ svcerr_noproc(transp); return; } } The following steps describe the lowest layer of RPC on the server side program: 1. Service the transport handle. The svctcp_create() and svcudp_create() calls create TCP and UDP transport handles (SVCXPRT) respectively, used for receiving and replying to RPC messages. The SVCXPRT transport handle structure is defined in the header file. If the argument of the svctcp_create() call is RPC_ANYSOCK, the RPC library creates a socket on which to receive and reply to remote procedure calls. The svctcp_create() and clnttcp_create() calls cause the RPC library calls to bind the appropriate socket, if it is not already bound. If the argument of the svctcp_create() call is not RPC_ANYSOCK, the svctcp_create() call expects its argument to be a valid socket number. If you specify your own socket, it can be bound or unbound. If it is bound to a port by you, the port numbers of the svctcp_create() and clnttcp_create() calls must match. If the send and receive buffer size parameter of svctcp_create() is 0, the system selects a reasonable default. 2. Register the rmtprog service with Portmapper. If the rmtprog service terminated abnormally the last time it was used, the pmap_unset() call erases any trace of it before restarting. The pmap_unset() call erases the entry for RMTPROGNUM from the Portmapper's table. A service can register its port number with the local Portmapper service by specifying a nonzero protocol number in the svc_register() call. A programmer at the client machine can determine the server port number by consulting Portmapper at the server machine. You can do this automatically by specifying 0 as the port number in the clntudp_create() or clnttcp_create() calls. Finally, the program and version number are associated with the rmtprog procedure. The final argument to the svc_register() call is the protocol being used, which in this case is IPPROTO_TCP. Register at the program level, not at the procedure level. 3. Run the remote program RMTPROG. The rmtprog service routine must call and dispatch the appropriate XDR calls based on the procedure number. Unlike the registerrpc() call, which performs them automatically, the rmtprog routine requires two tasks:  When the NULLPROC procedure (currently 0) returns with no results, use it as a simple test for detecting whether a remote program is running.  Check for incorrect procedure numbers. If you detect one, call the svcerr_noproc() call to handle the error. As an example, the procedure STRINGPROC has an argument for a character string and returns the character string back to the client. The svc_getargs() call takes an SVCXPRT handle, the xdr_wrapstring() call, and a pointer that indicates where to place the input. The user service (rmtprog) serializes the results and returns them to the RPC caller through the svc_sendreply() call. Parameters of the svc_sendreply() call include the:  SVCXPRT handle  XDR routine, which indicates return data type  Pointer to the data to be returned ═══ 8.7.3. Client Side Program ═══ The following is an example of the lowest layer of RPC on the client side program: #define RMTPROGNUM (u_long)0x3fffffffL #define RMTPROGVER (u_long)0x1L #define STRINGPROC (u_long)2 #include #include #include #include main(argc, argv) int argc; char *argv[ ]; { struct hostent *hp; struct timeval pertry_timeout, total_timeout; struct sockaddr_in server_addr; int sock = RPC_ANYSOCK; static char buf[100], *strc_in= "Hello", *strc_out=buf; char *parrc_in, *parrc_out; register CLIENT *clnt; enum clnt_stat cs; ... /* get the Internet address of RPC server host */ if ((hp = gethostbyname("RPCSERVER_HOST")) == NULL) { fprintf(stderr,"Can't get address for %s\n","RPCSERVER_HOST"); exit (-1); } pertry_timeout.tv_sec = 3; pertry_timeout.tv_usec = 0; /* set sockaddr_in structure */ bcopy(hp->h_addr, (caddr_t)&server_addr.sin_addr.s_addr, hp->h_length); server_addr.sin_family = AF_INET; server_addr.sin_port = 0; /* create clnt TCP handle */ if ((clnt = clnttcp_create(&server_addr, RMTPROGNUM, RMTPROGVER, &sock, 1024*10, 1024*10)) == NULL) { clnt_pcreateerror("clnttcp_create fail"); /* Why failed ? */ exit(-1); } /* * create clnt UDP handle * if ((clnt = clntudp_create(&server_addr, RMTPROGNUM, RMTPROGVER, * pertry_timeout, &sock)) == NULL) * { * clnt_pcreateerror("clntudp_create fail"); * exit(-1); * } */ total_timeout.tv_sec = 10; total_timeout.tv_usec = 0; ... /*call the remote procedure STRINGPROC associated with */ /*client handle (clnt) */ cs=clnt_call(clnt, STRINGPROC,xdr_wrapstring, (char *)&strc_in[j], xdr_wrapstring, (char *)&strc_out,total_timeout); if (cs != RPC_SUCCESS) printf("*Error* clnt_call fail :\n"); clnt_destroy(clnt); /* deallocate any memory associated */ /* with clnt handle */ ... } The following steps describe the lowest layer of RPC on the client side program: 1. Determine the internet address of the RPC server host. Use the gethostbyname() call to determine the internet address of the host, which is running the RPC server. Initialize the socaddr_in structure, found in the header file. If you are not familiar with socket calls, see Sockets General Programming Information. 2. Use the client RPC handle. The clnttcp_create() and clntudp_create() calls create TCP and UDP client RPC handles (CLIENT), respectively. The CLIENT structure is defined in the header file. There are six parameters for the clnttcp_create() call:  Server address  Program number  Version number  Pointer to a valid socket descriptor  Send buffer size  Receive buffer size Use the same parameters for the clntudp_create() call, except for the send and receive buffer size. Instead, specify a timeout value (between tries). 3. Call the remote procedure. The low-level version of the callrpc() call is the clnt_call(), which has seven parameters:  CLIENT pointer  Remote procedure number (STRINGPROC)  XDR call for serializing the argument  Pointer to the argument  XDR call for deserializing the return value from the RPC server  Pointer to where the return value is to be placed  Total time in seconds to wait for a reply For UDP transport, the number of tries is the clnt_call() timeout divided by the clntudp_create() timeout. The return code RPC_SUCCESS indicates a successful call; otherwise, an error has occurred. You find the RPC error code in the header file. The clnt_destroy() call always deallocates the space associated with the client handle. If the RPC library opened the socket associated with the client handle, the clnt_destroy() call closes it. If you open the socket, it stays open. ═══ 8.8. rpcgen Command ═══ Use the rpcgen command to generate C code to implement an RPC protocol. The input to RPCGEN is a language similar to C, known as RPC language. You normally use rpcgen infile to generate the following four output files. For example, if the infile is named PROTO.X, rpcgen generates:  A header file called PROTO.H  XDR routines called PROTOX.C  Server-side stubs called PROTOS.C  Client-side stubs called PROTOC.C For more information on the rpcgen command, see the Sun Microsystems publication, Networking on the Sun Workstation: Remote Procedure Call Programming Guide. Syntax ─rpcgen── infile───────────────────────────────────────────── ─rpcgen───┬─ -c─┬─┬─────────────────────────┬──────────────── ├─ -h─┤ └─ -o outfile┬─────────┬──┘ ├─ -l─┤ └─ infile─┘ └─ -m─┘ ─rpcgen─── -s transport──┬─────────────┬──┬──────────┬─────── └─ -o outfile─┘ └─ infile──┘ Parameters -c Compiles into XDR routines. -h Compiles into C data definitions (a header file). -l Compiles into client-side stubs. -m Compiles into server-side stubs without generating a main routine. -o outfile Specifies the name of the output file. If none is specified, standard output is used for -c, -h, -l, -m, and -s modes. infile Specifies the name of the input file written in the RPC language. -s transport Compiles into server-side stubs, using the given transport. ═══ 8.9. rpcinfo Command ═══ The rpcinfo command makes an RPC call to the RPC server and reports the status of the server, which is registered and operational with Portmapper. Syntax rpcinfo for a Host ┌─ local_host─┐ ─rpcinfo── -p───┼─────────────┼─┬─────────────┬────────────── └─ host───────┘ └─ > filename─┘ Using UDP to send rpcinfo for a Host ─rpcinfo───┬─────────────┬── -u host prognum┬──────────┬────── └─ -n portnum─┘ └─ versnum─┘ ──┬─────────────┬───────────────────────────────────────────── └─ > filename─┘ Using TCP to send rpcinfo for a Host ─rpcinfo───┬─────────────┬── -t host prognum┬──────────┬────── └─ -n portnum─┘ └─ versnum─┘ ──┬─────────────┬───────────────────────────────────────────── └─ > filename─┘ Using UDP to send rpcinfo Broadcast to Hosts ─rpcinfo─┬─────┬─── prognum── versnum───┬─────────────┬────── └─ -b─┘ └─ > filename─┘ Parameters -p host Queries the Portmapper about the specified host and prints a list of all registered RPC programs. If the host is not specified, the system defaults to the local host name. > filename Specifies a file to which the list of registered RPC programs is redirected. -n portnum Specifies the port number to be used for the -t and -u parameters. This value replaces the port number that is given by the Portmapper. -u host prognum versnum Uses UDP to send an RPC call to procedure 0 of prognum and versnum on the specified host, and reports whether a response is received. -t host prognum versnum Uses TCP to send an RPC call to procedure 0 of prognum and versnum on the specified host and reports whether a response is received. -b prognum versnum Uses UDP to sends an RPC broadcast to procedure 0 of the specified prognum and versnum and reports all hosts that respond. The prognum argument can be either a name or a number. If you specify a versnum, the rpcinfo command tries to call that version of the specified program. Otherwise, it tries to find all the registered version numbers for the program you specify by calling version 0; then it tries to call each registered version. The TCPIP\ETC\RPC file is associated with the rpcinfo command. This file contains a list of server names and their corresponding RPC program numbers and aliases. Examples Use the rpcinfo command as follows to display RPC services registered on the local host: rpcinfo -p Examples Use the rpcinfo command as follows to display RPC services registered on a remote host named charm: rpcinfo -p charm Examples Use the rpcinfo command as follows to display the status of a particular RPC program on the remote host named charm: rpcinfo -u charm 100003 2 or rpcinfo -u charm nfs 2 In the previous examples, the rpcinfo command shows one of the following: Program 100003 Version 2 ready and waiting or Program 100003 Version 2 is not available Examples Use the rpcinfo command as follows to display all hosts on the local network that are running a certain version of a specific RPC server: rpcinfo -b 100003 2 or rpcinfo -b nfsprog 2 In these examples, the rpcinfo command lists all hosts that are running Version 2 of the NFS daemon. Note: The version number is required for the -b parameter. ═══ 8.10. The enum clnt_stat Structure ═══ The enum clnt_stat structure is defined in the file. RPCs frequently return enum clnt_stat information. The format of the enum clnt_stat structure follows: enum clnt_stat { RPC_SUCCESS=0, /* call succeeded */ /* * local errors */ RPC_CANTENCODEARGS=1, /* can't encode arguments */ RPC_CANTDECODERES=2, /* can't decode results */ RPC_CANTSEND=3, /* failure in sending call */ RPC_CANTRECV=4, /* failure in receiving result */ RPC_TIMEDOUT=5, /* call timed out */ /* * remote errors */ RPC_VERSMISMATCH=6, /* RPC versions not compatible */ RPC_AUTHERROR=7, /* authentication error */ RPC_PROGUNAVAIL=8, /* program not available */ RPC_PROGVERSMISMATCH=9, /* program version mismatched */ RPC_PROCUNAVAIL=10, /* procedure unavailable */ RPC_CANTDECODEARGS=11, /* decode arguments error */ RPC_SYSTEMERROR=12, /* generic "other problem" */ /* * callrpc errors */ RPC_UNKNOWNHOST=13, /* unknown host name */ /* * create errors */ RPC_PMAPFAILURE=14, /* the pmapper failed in its call */ RPC_PROGNOTREGISTERED=15, /* remote program is not registered */ /* * unspecified error */ RPC_FAILED=16 }; ═══ 8.11. The Remote Procedure Call Library ═══ To use the RPCs described in this section, you must have the following header files in your H\INCLUDE directory: RPC Header File What It Contains RPC\AUTH.H Authentication interface RPC\AUTH_UNI.H Protocol for UNIX-style authentication parameters for RPC RPC\CLNT.H Client-side remote procedure call interface RPC\PMAP_CLN.H Supplies C routines to get to PORTMAP services RPC\PMAP_PRO.H Protocol for the local binder service, or pmap RPC\RPC.H Includes the RPC header files necessary to do remote procedure calling RPC\RPC_MSG.H Message definitions RPC\RPCNETDB.H Data definitions for network utility calls RPC\RPCTYPES.H RPC additions to RPC\SVC.H Server-side remote procedure call interface RPC\SVC_AUTH.H Service side of RPC authentication RPC\XDR.H eXternal Data Representation serialization routines The RPC routines are in the RPC32DLL.LIB file in the LIB directory. Put the following statement at the beginning of any file using RPC code: #include ═══ 8.12. Differences between OS/2 and Sun Microsystems RPCs ═══ The IBM OS/2 RPC implementation differs from the Sun Microsystems RPC implementation as follows:  The global variables svc_socks[ ] and noregistered are used in place of the svc_fds global variable. See svc_socks[ ] for the use of these variables.  Functions that rely on file descriptor structures are not supported.  The svc_getreq() call supports the socks and noavail global variables. In the Sun Microsystems implementation, the svc_getreq() call supports the rdfds global variable.  TYPES.H for RPC has been renamed to RPCTYPES.H. ═══ 8.13. Compiling an RPC API Application ═══ Follow these steps to compile and link the RPC API application using an IBM 32-bit compiler for OS/2: 1. To compile your program, enter: icc /C myprog.c 2. To create an executable program, you can enter: For VisualAge C++ ilink /NOFREEFORMAT myprog,myprog.exe,NULL, rpc32dll.lib Notes: 1. The RPC API is not re-entrant. If you are using a multithreaded program, you must serialize the access to the APIs. 2. For more information about the compile and link options, and dynamic link libraries, see the User's Guide provided with your compiler. ═══ 9. File Transfer Protocol ═══ The File Transfer Protocol (FTP) API allows applications to have a client interface for file transfer. Applications written to this interface can communicate with multiple FTP servers at the same time. The interface supports a maximum of 256 simultaneous connections and enables third-party proxy transfers between pairs of FTP servers. Consecutive third-party transfers are allowed between any sequence of pairs of FTP servers. The FTP API tracks the servers to which an application is currently connected. When a new request for FTP service is requested, the API checks whether a connection to the server exists and establishes one if it does not exist. If the server has dropped the connection since last use, the API re-establishes it. Note: The FTP API is not re-entrant. If you are using a multithreaded program, you must serialize the access to the APIs. For example, without serialization, the program may fail if it has two threads running concurrently and each thread has its own connection to a server. Topics FTP API Call Library Compiling and Linking an FTP API Application ═══ 9.1. FTP API Call Library ═══ To use the FTP API, you must have the header file in your TCPIP\INCLUDE directory. The FTP API routines are in the FTPAPI.LIB file in the LIB directory. Put the following statement at the top of any file using FTP API code: #include ═══ 9.2. Compiling and Linking an FTP API Application ═══ Follow these steps to compile and link the FTP API application using an IBM 32-bit compiler for OS/2: 1. To compile your program, enter: icc /C myprog.c 2. To create an executable program, you can enter: For VisualAge C++ ilink /NOFREEFORMAT myprog,myprog.exe,NULL, ftpapi.lib Notes: 1. The FTP API is not re-entrant. If you are using a multithreaded program, you must serialize the access to the APIs. 2. For more information about the compile and link options, and dynamic link libraries, see the User's Guide provided with your compiler. 3. The FTP API can connect to an FTP server using a specific port rather than the well-known port. Code the port number as part of the host name specification, such as ftpget ("server1 1234", ...) to connect to server1 by port 1234. ═══ 10. Resource ReSerVation Protocol ═══ The sender and receiver of a data stream use the RSVP (Resource ReSerVation Protocol) to ensure that some quality of service can be reserved on the network. This is in contrast to the usual "best effort" service that is provided, where packets are handled "first come first serve". This section describes the resource reservation protocol implemented in TCP/IP for OS/2. Topics RSVP Introduction Consequences of Partial RSVP Deployment on a Network Using the RSVP API Determining Addresses and Ports Starting a Session Getting an Alert Socket Establishing the Program as a Sender Using Select() With the Alert Socket Callback Function Example Making a QoS Reservation Receiving a Reservation Message Watching for Asynchronous RSVP Events Closing the RSVP Session Reservation Styles Tspecs and Flowspecs Adspecs Controlled Load Reservations Guaranteed Reservations Resource ReSerVation Protocol API ═══ 10.1. RSVP Introduction ═══ RSVP is a Quality of Service (QoS) setup protocol. RSVP does not send or receive data. Other protocols do the actual transmitting and receiving of data. A 5-tuple (protocol, destination address, destination port, sender address, sender port) defines the data flow for this QoS. RSVP sets up QoS for flow in a single direction. If two programs will be both sending and receiving and need QoS for each direction, QOS for each flow must be reserved independently. Initial implementations of RSVP have been mainly concerned with UDP unicast or UDP multicast, or other IP protocols, such as TCP. The rsvpd.exe daemon implements the RSVP protocol. Applications use an API interface (librsvp.dll) to communicate with the daemon. The associated toolkit contains a header file (rsvprapi.h) and the library stub for the dll (librsvp.lib). The sender initiates a session and causes RSVP path messages to go to the receiver. The path messages indicate what flow the sender is willing to send. RSVP daemons between the sender and receiver can also add information about what flows they can support. A reservation is set up when the receiver sends a reservation to the sender of a path message. The receiver can ask for confirmation that the reservation was set up. Once a flow is established, the daemons along that flow maintain it automatically by periodically resending path packets from the sender daemon and resending reservation packets in the reverse direction from the receiver's daemon. There are two types of QoS: a controlled load flowspec and a guaranteed flowspec. Generally, requesting a Quality of Service means at least that a specific bandwidth (number of bytes per second) is requested. There are five parameters in a Controlled Load flowspec. There are implications in these parameters about how much the packets can get "bunched up". For example, if you send a 100k byte burst of packets once every two seconds, the average data rate is 50k bytes per second. This data flow could be unacceptable, because the sender or receiver (or intervening routers) might only be able to handle 10k bursts every 0.2 seconds, for a much more even flow of data. In the part of the TCP/IP stack that performs QoS processing on the local machine, setting up for a particular reservation usually involves at least two major actions: 1. prioritizing packets as they wait to leave the machine onto the network (or to applications running on the machine) 2. preallocation of buffers so that space resources will be adequate for the QoS. Some applications, like audio data for a conversation, where excessive delay can easily become intolerable, require packets to be delivered within a specified time. Such applications should use the Guaranteed flowspec. Besides the five parameters of the Controlled Load flowspec, two other parameters, guaranteed rate and slack term, specify the delay through the network. ═══ 10.2. Consequences of Partial RSVP Deployment on a Network ═══ RSVP works in a network where not every node along a data flow path has RSVP implemented. The effects on QoS on transmission through sections of the network where RSVP is not implemented can be unpredictable, and are "best effort". The setup process will still be done where the flow passes through RSVP-capable nodes. ═══ 10.3. Using the RSVP API ═══ This section outlines typical sender and receiver scenarios for using the RSVP API functions. An RSVP sender session might have these steps: 1. Determine the sender and destination addresses and ports. 2. Start a session with rapi_session(), and provide it with the name of your callback function. 3. Call rapi_getfd() to obtain an alert socket. 4. Call rapi_sender() to establish the program as a sender. 5. Call select() to wait for a read on the alert socket. 6. When data is ready to be read on the alert socket, call rapi_dispatch() to read it. 7. Your callback routine is called as needed by rapi_dispatch(). 8. When your callback sees a reservation message from a receiver, go to the next step, otherwise go back to step (5). 9. Process the flowspec information to determine packet size, etc., and start sending data on a data socket. 10. The select() on the alert socket should continue to be used to watch for asynchronous error conditions. 11. When you are finished sending the data, call rapi_release() to end the RSVP session. An RSVP receiver session might have these steps: 1. Determine the sender and destination addresses and ports, and if the destination is a multicast group, join it. 2. Call rapi_session() to start a session, and provide it with your callback function. 3. Call rapi_getfd() to get the alert socket. 4. Use select() to wait for a read on the alert socket. 5. When data is ready to be read on the alert socket, call rapi_dispatch() to read it. 6. Call rapi_dispatch() as needed to call your callback routine. 7. When your callback sees a path message from a sender, go to the next step, otherwise go back to step (4). 8. Process the adspec information in the path message to determine what the reservation should be, and call rapi_reserve() to let the sender(s) see reservation messages. 9. Call select() to begin listening for the data stream on a data socket. Continue to call select() on the alert socket as well, to watch for asynchronous error conditions. 10. When you are finished receiving the data, use rapi_release() to end the RSVP session. ═══ 10.3.1. Determining Addresses and Ports ═══ The destination address and port are a specific IP address and port if the data flow is unicast. If the data flow is via a multicast group, the destination address and port are for a multicast group. Generally address and port determination depends upon the protocol to be used to send and receive the data stream. If the data flow is for the TCP protocol, the usual listen() - connect() - accept() sequence, can be done by server and client. Then the IP address and port for each end of the connection are available using the getsockname() and getpeername() functions. If the data flow is for UDP unicast or multicast, agreement about IP addresses and ports may have to be done externally to the RSVP protocol or the UDP protocol. This would depend upon the application. For example, it might be necessary ahead of time to agree upon a multicast address and port to use for a video broadcast. When joining a multicast group as a receiver, it is possible to see path messages to that group which are coming from senders. Then a receiver can make reservations for data flows from the senders. A path message includes the IP address and port of the sender. RSVP is designed to use a variety of network address types. Thus the API uses the more general sockaddr structure. To operate with Internet Protocol addresses, the sockaddr structure must be cast to sockaddr_in. ═══ 10.3.2. Starting a Session ═══ The sender and receiver start sessions in the same way, using the rapi_session() function. This call requires a sockaddr structure, which defines a destination address and port, a protocol number, an optional callback function that you provide, and some other parameters. If the session is multicast, then the address is for a multicast group to which the senders send data. The port can be considered an extension of the multicast address. The address and port must agree for all users of that multicast group. The rapi_session() function returns a session ID that is used in subsequent calls to the RSVP API. This example assumes that the destination is a multicast group. #include int retcode; rapi_sid_t sessID; /* RSVP session ID */ int proto = IPPROTO_UDP; /* protocol (UDP) */ struct sockaddr_in mulAddr; /* multicast address, port, protocol */ int alertSoc; /* alert socket for asynchronous events */ int ttl; /* multicast time to live value */ mulAddr.sin_family = AF_INET; mulAddr.sin_addr.s_addr = inet_addr("224.1.1.1"); mulAddr.sin_port = htons(1201); /* Do multicast group setup at this point. Code omitted here. */ sessID = rapi_session((struct sockaddr *)&mulAddr, proto, 0, callback, NULL, &retcode); if (! sessID) { printf("Session did not start! rapi_session() error code %d\n", retcode); exit(1); } else { alertSoc = rapi_getfd(sessID); printf("Session %d started, alert socket is %d\n", sessID, alertSoc); } if (alertSoc <= 0) { printf("Error, rapi_getfd() could not provide an alert socket!\n"); exit(1); } ═══ 10.3.3. Getting an Alert Socket ═══ The sender and receiver both would call rapi_getfd() at this point. The function returns an alert socket. The socket is used to send data to the RSVP API. The program should do a select() on the socket as a read socket in order to know when asynchronous events are available. The program should not read the socket. If the program is going to receive data, this is a good point to use select() to wait for path messages that indicate that one or more senders are available. There is an example of this in a later section. If the program is going to send data, this is a good time to tell the RSVP API that the program will be a sender. ═══ 10.3.4. Establishing the Program as a Sender ═══ The rapi_sender() function tells RSVP that the program will be a sender. This call establishes the sender address and port for the data flow, and it specifies the characteristics of the data stream in RSVP terms, with a Tspec (transmission specification). This information will go to the destination in an RSVP path message. The RSVP API will take care of repeating the message as needed according to the RSVP protocol. This example shows the use of rapi_sender(): int retcode; struct sockaddr_in senderAddr; /* sender address, port, protocol */ rapi_tspec_t sndTSpec; /* set up senderAddr and sndTSpec */ senderAddr.sin_family = AF_INET; senderAddr.sin_addr.s_addr = inet_addr("129.5.24.1"); senderAddr.sin_port = htons(1024); /* set the object size and form in the object header */ sndTSpec.len = sizeof(sndTSpec); sndTSpec.form = RAPI_FORMAT_IS_GEN; /* fill in the body of the Tspec object */ sndTSpec.tspec_r = 100000; sndTSpec.tspec_b = 2600; sndTSpec.tspec_p = 100000; sndTSpec.tspec_m = 1300; sndTSpec.tspec_M = 1300; retcode = rapi_sender( sessID, /* Session ID */ 0, /* Flags - not defined */ (struct sockaddr *)&senderAddr, /* Local host: (Src addr, port), net order */ NULL, /* Sender template - not supported */ &sndTSpec, /* Sender Tspec */ NULL, /* Sender Adspec - not supported */ NULL, /* Sender policy data - not supported */ ttl /* TTL of multicast session (if multicast) */ ); if (retcode) printf("rapi_sender() error %d\n", retcode); ═══ 10.3.5. Using Select() With the Alert Socket ═══ The alert socket is used to communicate messages from the RSVP daemon to the API. These messages generally turn into events for the program. Select() is used to wait for read data on the alert socket. Once there is read data available, the program must call rapi_dispatch() so that the RSVP API can read the data and handle it properly. Typically, rapi_dispatch() will, in turn, call your callback function, possibly more than once. In the rsvprapi.h header file, the data type rapi_event_rtn_t is declared to be a pointer to a callback function. The arguments of the function are also declared there, so that you can see how to declare your callback function arguments. This example shows a loop with a select() call waiting on the alert socket until a path message is received and handled by a callback function: fd_set readSockets; int rc, rapi_rc; int receivedPathEvent = 0; /* set to 1 by the callback routine */ while (! receivedPathEvent) { FD_ZERO(&readSockets); FD_SET(alertSoc, &readSockets); if ((rc = select(FD_SETSIZE, &readSockets, NULL, NULL, &timeout)) < 0) { psock_errno("select() on alert socket"); exit(1); } if (rc > 0 && FD_ISSET(alertSoc, &readSockets)) { rapi_rc = rapi_dispatch(); if (rapi_rc == RAPI_ERR_NORSVP) { printf("Warning! RSVP has gone away.\n"); exit(1); } } } /* end while */ Waiting for a reservation message would be similar. ═══ 10.3.6. Callback Function Example ═══ This example mainly shows the code that works with the previous example, which looks for a path message. This example also prints all the event information, using the format routines of the RSVP API where appropriate: struct sockaddr_in sndAddr; /* remember the sender IP addr:port here */ int _System callback( rapi_sid_t sid, /* Which sid generated event */ rapi_eventinfo_t eventType, /* Event type */ rapi_styleid_t styleID, /* Style ID */ int errorCode, /* Error code */ int errorValue, /* Error value */ struct sockaddr *pNodeAddr, /* Error node address */ u_char errorFlags, /* Error flags */ int nFilterSpecs, /* Number of filter specs/sender*/ /* templates in list */ rapi_filter_t *pFilterSpec, /* Filter spec/sender templ list*/ int nFlowSpecs, /* Number of flowspecs/Tspecs */ rapi_flowspec_t *pFlowSpec, /* Flowspec/Tspec list */ int nAdSpecs, /* Number of adspecs */ rapi_adspec_t *pAdSpec, /* Adspec list */ void * pClientArg /* Client supplied arg */ ) { int i; #define FMT_BUF_SIZE 600 char buf[FMT_BUF_SIZE]; printf("callback() sid %d, eventType %d, styleID %d\n", sid, eventType, styleID); /* if we received the path event then tell the select loop */ if (eventType == RAPI_PATH_EVENT) { receivedPathEvent = 1; /* get the sender address from pFilterSpec */ if (nFilterSpec && (pFilterSpec->form == RAPI_FILTERFORM_BASE)) sndAddr = pFilterSpec->filter.base.sender; /* else it is another address form... */ } In a realistic program, the adspec information would be processed to determine what services are supported by network elements that support RSVP. Information on data rate, bandwidth, packet MTU, etc., normally would be available. A receiver would determine what reservation flowspec would be suitable for the data stream that the sender could send. If a reservation event is being processed by a sender, the adspec information normally would provide the upper limit on packet size, and other useful information, and the sender could adjust its data flow accordingly. To print all the event information: if (errorCode == RAPI_ERR_OK) printf("errorCode %d\n", errorCode); else printf("errorCode %d, errorValue %d, nodeAddr %s:%d, errorFlags %d\n", errorCode, errorValue, inet_ntoa(((struct sockaddr_in*)pNodeAddr->sin_addr), ((struct sockaddr_in*)pNodeAddr->sin_port, errorFlags); if (nFilterSpecs) for (i = 0; i < nFilterSpecs; ++i) { rapi_fmt_filtspec(pFilterSpec + i, buf, FMT_BUF_SIZE); printf("filterspec %d, %s\n", i, buf); } else printf("No filter specs\n"); if (nFlowSpecs) for (i = 0; i < nFlowSpecs; ++i) { rapi_fmt_flowspec(pFlowSpec + i, buf, FMT_BUF_SIZE); printf("flowspec %d, %s\n", i, buf); } else printf("No flowspecs\n"); if (nAdSpecs) for (i = 0; i < nAdSpecs; ++i) { rapi_fmt_adspec(pAdSpec + i, buf, FMT_BUF_SIZE); printf("adspec %d, %s\n", i, buf); } else printf("No adspecs\n"); /* the function must return a value, but the API does nothing to it */ return 0; } /* end callback */ ═══ 10.3.7. Making a QoS Reservation ═══ The rapi_reserve() function is used by the receiver to make a reservation or change a reservation. The call specifies a reservation style, filter specs (data senders), and flowspecs (Quality of Service specifications). This example shows how a receiver makes or changes a reservation: #define MAX_RSVP_SENDERS 10 int retcode; rapi_styleid_t rapiStyle = RAPI_RSTYLE_FIXED; /* fixed reservation */ int filterSpecCount; rapi_filter_t filterSpec[MAX_RSVP_SENDERS]; int flowSpecCount; rapi_flowspec_t flowSpec[MAX_RSVP_SENDERS]; filterSpecCount = 1; /* one specified sender this time */ /* set the object size and form in the object header */ filterSpec[0].len = sizeof(rapi_hdr_t) + sizeof(rapi_filter_base_t); filterSpec[0].form = RAPI_FILTERFORM_BASE; /* fill in the body of the filterspec object */ filterSpec[0].filter.base.sender = sndAddr; /* copied from path event */ flowSpecCount = 1; /* one flowspec this time */ /* set the object size and form in the object header */ flowSpec[0].len = sizeof(rapi_hdr_t) + sizeof(CL_flowspec_t); flowSpec[0].form = RAPI_FORMAT_IS_CL; /* fill in the body of the flowspec object */ flowSpec[0].cl_tspec_r = 100000; flowSpec[0].cl_tspec_b = 2600; flowSpec[0].cl_tspec_p = 100000; flowSpec[0].cl_tspec_m = 1300; flowSpec[0].cl_tspec_M = 1300; retcode = rapi_reserve( sessID, /* session id */ RAPI_REQ_CONFIRM, /* flags */ NULL, /* rcv host addr (optional, sessID has destination) */ rapiStyle, /* style ID */ NULL, /* style extension, not supported */ NULL, /* receiver policy, not supported */ filterSpecCount, filterSpec, /* array of filter specs */ flowSpecCount, flowSpec /* array of flow specs */ ); if (retcode) printf("rapi_reserve() error %d\n", retcode); The rapi_reserve() call above has the optional RAPI_REQ_CONFIRM flag, that asks for a confirmation message to be sent if the reservation is made. Such an event indicates that the reservation had a very high probability of succeeding. After making the reservation, the receiver should start listening for the data stream on a data socket. ═══ 10.3.8. Receiving a Reservation Message ═══ After a sender's callback function receives a reservation message, the sender can start sending data to the destination. The RSVP data flow has been set up with the reserved Quality of Service. Start listening for the data stream on a data socket. ═══ 10.3.9. Watching for Asynchronous RSVP Events ═══ Both a sender and a receiver should continue to use a select() on the alert socket to watch for asynchronous error conditions. The select() can be in separate thread, or it can be a select() that is used in sending or receiving the data stream. ═══ 10.3.10. Closing the RSVP Session ═══ Use the rapi_release() function to close an RSVP session. When the program terminates, the RSVP API will also close sessions that a program has open. ═══ 10.4. Reservation Styles ═══ Bandwidth reservation relates to the way the bandwidth is to be allocated (the reservation type), and the technique used to select senders (the sender selection). The reservation type may be distinct for individual data flows, or may be shared among multiple data flows. The selection of the senders may be explicit (meaning that individual senders are identified individually), or it may be a wildcard selection that implicitly selects all the senders to a session. This table shows the reservation styles that are defined for these two types of options of Sender Selection and Reservation type. For example, for the Sender Selection type of "explicit" and the Reservation Type of "distinct" the Reservation Style is "Fixed-Filter (FF)". ┌─────────────────────────────────────────────────────────────────┐ │Sender Selection Reservation Type Reservation Style │ ├─────────────────────────────────────────────────────────────────┤ │explicit distinct Fixed-Filter (FF) │ ├─────────────────────────────────────────────────────────────────┤ │explicit shared Shared-Explicit (SE) │ ├─────────────────────────────────────────────────────────────────┤ │wildcard distinct (none defined) │ ├─────────────────────────────────────────────────────────────────┤ │wildcard shared Wildcard-Filter (WF) │ └─────────────────────────────────────────────────────────────────┘ The fixed filter (FF) style specifies a distinct flow for each sender. The bandwidth reservations are made separately for each flow. Parameters in the reservation specify each sender explicitly. With the shared explicit (SE) style, each of the senders is specified explicitly in the reservation message, but the reserved bandwidth is shared by all the senders wherever they can be merged upstream from the receiver. The wildcard filter (WF) style specifies a single reservation of bandwidth which is to be shared by all the senders. This type of reservation is propagated upstream to all senders as they become senders in the RSVP session. Besides there being a single bandwidth reservation for all the senders to the receiver that makes the reservation, the other receivers in the same multicast group will have their bandwidth reservations merged as well. The "largest" such reservation for the session at any point in the multicast tree determines how much bandwidth is reserved at that point in the tree. The wildcard and shared explicit styles are primarily useful for multicast applications where the data sources are unlikely to transmit simultaneously. ═══ 10.5. Tspecs and Flowspecs ═══ The sender Tspec contains a structure with five fields that define the flow. The two receiver flowspecs also contain this structure. typedef struct { float32_t IS_Tspec_r; /* Token bucket rate (IP packet bytes/sec) */ float32_t IS_Tspec_b; /* Token bucket depth (bytes) */ float32_t IS_Tspec_p; /* Peak data rate (IP packet bytes/sec) */ u_int32_t IS_Tspec_m; /* Min Policed Unit (bytes) */ u_int32_t IS_Tspec_M; /* Max packet size (bytes) */ } IS_Tspec_t; The token bucket rate (r) is in bytes of IP datagrams per second. That is, the packets must include the IP packet header (20 bytes) and the UDP header (8 bytes) or the TCP header (20 bytes), as well as the data in the packet, when computing packet sizes. The legal value of r may range from 1 byte per second to 40 terabytes per second. The bucket depth (b) may range from 1 bytes to 250 gigabytes. The maximum packet size (M) should be no bigger than the Maximum Transmission Unit (MTU) of the path between sender and receiver. The value of m must be no bigger than M. In a Tspec the sender indicates, for any arbitrary time period of T seconds, that the amount of data sent in that period will not be greater than r*T+b. When computing this, any packet that is less than the minimum policed unit (m) in size should be counted as m bytes. The token bucket model is a way of viewing the transmission of data. The sender has a stream of data that comes from some source, and the sender expects to send it using RSVP. It may need to send at a specified rate dictated by the data stream source, for example an audio or video data stream. The receiver may need to output the data in a timely fashion after receiving it as well. The token bucket rate is the rate at which the sender will send. Imagine bytes (tokens) filling the token bucket. When enough accumulate so that the above formula is not violated, a packet is built and sent. The bucket is reduced by the amount that was sent. The peak data rate (p) is mainly used in guaranteed flowspecs. It can be set the same as r, for controlled load flowspecs. In guaranteed flowspecs, it is required that for any time period T, that the amount of data sent in that period cannot exceed M+p*T. A Guaranteed flowspec has a Tspec and an Rspec. An Rspec is shown below. typedef struct { float32_t Guar_Rspec_R; /* Guaranteed Rate (IP packet bytes/sec) */ u_int32_t Guar_Rspec_S; /* Slack term (microseconds) */ } Guar_Rspec_t; The guaranteed rate (R) and slack term (S) are computed by the receiver based upon the values in the adspec in the path message. They are explained in a later section. A sender and receiver in an RSVP session negotiate reasonable values of packet size, etc., by using information in the path and reservation messages. Typically, a sender specifies the largest packet it is willing to send. This value will be in the path message Tspec. When the path message is seen by a receiver, the packet size (in the adspec) will be the maximum that can be handled by all the RSVP-enabled nodes that the message passed through. (If one or more nodes was not RSVP-enabled, then that fact is also indicated in the adspec. In that case, the reservation that is made should be considered unreliable.) Once the receiver makes a reservation, a similar process can happen as the reservation message goes toward the sender, if the reservation gets merged with other reservations. Thus the sender can see what the maximum packet size should be to have the packets be sent reliably to all receivers. If a packet is larger than that size, it will be sent by "best effort" technique rather than according to the reservation that was made. A similar process occurs for delay through the network, so that the receiver has an estimate of what sort of service it can expect and request. ═══ 10.6. Adspecs ═══ Adspecs are a part of path events. Adspecs carry information about the RSVP support that is possible in the network for a specified flow. An adspec is created by the RSVP daemon when a sender calls rapi_sender(). The path message traverses the network to the receiver, and accumulates changes to the adspec when passing through each RSVP enabled network node. The receiver callback function is called with a path event. The path event has the original sender Tspec, and the adspec that indicates the support that is possible through the network for that Tspec. The receiver then calls rapi_reserve() to make a reservation based upon the information in the Tspec and adspec. Then the reservation message traverses the network to the sender. The QoS reservation is set up in each RSVP node until the reservation message reaches the sender. The sender callback function is called with a reserve event. The sender then may adjust packet size or other factors in order to use the reservation effectively, based upon the reservation information. When the application callback function is passed a non-NULL pointer for the adspec, then the pointer is to an IS_adspec_t data type, shown below. typedef struct { Gen_adspec_t Gen_Adspec; rbool_t CL_present; CL_adspec_t CL_Adspec; rbool_t Guar_present; Guar_adspec_t Guar_Adspec; } IS_adspec_t; The IS_adspec_t has several fields. The Gen_Adspec field is always present. If CL_present is true, then CL_Adspec contains a CL_adspec_T, which is a composite of the controlled flow support for the path. If Guar_present is true, then Guar_Adspec contains a Guar_adspec_t, which is a composite of the guaranteed flow support for the path. The Gen_Adspec is shown below. typedef struct { rbool_t servBreak; /* break in service */ u_int16_t ISHops; /* num Int-serv aware hops */ float32_t pathBW; /* min path band width (bytes/sec) */ u_int32_t pathLatency; /* min path latency (microseconds) */ u_int16_t composedMTU; /* composed path MTU */ } Gen_adspec_t; If servBreak is true, then there is at least one hop on the path that does not have QoS support and QoS must be considered unreliable. ISHops specifies the number of hops that do have QoS support of some sort (controlled load or guaranteed). There are estimates for minimum path bandwidth and minimum delay through the path. The composedMTU is the maximum transmission unit that can be sent on the path without fragmentation of the packet. The composedMTU includes the IP packet header and whatever protocol headers (UDP, TCP, etc.) will be in the packet. Note that a particular type of service might have a different value for the composedMTU, due to implementation differences for various types of QoS. The CL_adspec_t below provides information specifically for controlled load flows on the path. Note that it is possible for there to be a break in service for controlled load even if QoS is supported at every node. Some nodes may only implement QoS for guaranteed flows. typedef struct { rbool_t servBreak; /* break in service */ u_int16_t ISHops; /* num Int-serv aware hops */ float32_t pathBW; /* min path band width (bytes/sec) */ u_int32_t pathLatency; /* min path latency (microseconds) */ u_int16_t composedMTU; /* composed path MTU */ } CL_adspec_t; The fields have the same significance as for Gen_adspec_t but refer only to path hops for which controlled load is supported. The Guar_adspec_t below provides information specifically for guaranteed flows on the path. Note that it is possible for there to be a break in service for guaranteed flows even if QoS is supported at every node. Some nodes may only implement controlled load QoS. typedef struct { rbool_t servBreak; /* break in service */ u_int16_t ISHops; /* num Int-serv aware hops */ float32_t pathBW; /* min path band width (bytes/sec) */ u_int32_t pathLatency; /* min path latency (microseconds) */ u_int16_t composedMTU; /* composed path MTU (bytes) */ u_int32_t Ctot; /* total rate dep. err (bytes) */ u_int32_t Dtot; /* total rate indep. err (microseconds) */ u_int32_t Csum; /* reshaped rate dep. err (bytes) */ u_int32_t Dsum; /* reshaped rate indep. err (microseconds) */ } Guar_adspec_t; The first five fields have the same significance as for Gen_adspec_t but refer only to path hops for which guaranteed flow is supported. The remaining fields are unique to guaranteed flows. ═══ 10.7. Controlled Load Reservations ═══ The controlled load reservation requests a reservation for a guaranteed data rate. The receiver is asking for an IP packet byte rate that is no greater than r*T+b bytes for any arbitrary time of T seconds. The receiver expects to not need more than b bytes of packet space for arriving packets in the TCP/IP stack, while it is busy processing previously received packets. The receiver should request a maximum packet size M no bigger than the composedMTU from the controlled load adspec. When computing r*T+b, packets smaller than m should be treated as if they were size m. The peak rate p in the reservation is checked for validity but usually is ignored. For more information, refer to Internet RFC 1633 Integrated Services in the Internet Architecture: an Overview, and Internet Draft draft-ietf-intserv-ctrl-load-svc-07. ═══ 10.8. Guaranteed Reservations ═══ Guaranteed reservations are more complex than controlled load because guaranteed flow provides a way to reserve a specified maximum delay through the network, as well as a specified data rate. Guaranteed service does not control the average or minimum packet delay. Guaranteed service also does not control jitter, the difference between minimum and maximum packet delays. The guaranteed flow model of the network assumes that there are two sources of delay in the network, the delay (D) that is independent of rate of flow, and the delay (C) that is proportional to rate of flow. Delay for a rate r would be C*r+D in an ideal situation. In practice, the RSVP-enabled network elements provide an upper bound for their contribution to C and D, and a lower bound for D. The lower bound for C is 0. The receiver chooses a reservation that takes these bounds into consideration. The pathLatency field of the adspec for guaranteed service is an estimate of the minimum delay through the network for that type of service. It can be estimated from many diverse factors such as speed of light through fiber cables or minimum path length of routing code. Each RSVP-enabled node adds its own estimate of this value to the adspec. The delay that is based on the data rate can include many factors, such as time to queue a packet, and maximum time to wait for the current packet to be sent before the next one can be sent out an interface. When a path message arrives at the receiver, the guaranteed flow adspec will contain Ctot and Dtot, which are accumulations of the C and D delay factors on the path through the network. The terms Csum and Dsum are used by intermediate nodes along with the slack term that the guaranteed flow will provide. These terms are used by nodes that will "reshape" the data flow to make it conform to the flow parameters. These are the formula variables and their sources, for determining the Guaranteed flowspec. ┌──────────────────────────────────────────────────────────────────┐ │Var Spec Spec Field Description │ ├──────────────────────────────────────────────────────────────────┤ │Bmin Guar_adspec_t pathBW min path bandwidth (IP │ │ pkt bytes/sec) │ ├──────────────────────────────────────────────────────────────────┤ │MTU Guar_adspec_t composedMTU composed path MTU │ │ (bytes) │ ├──────────────────────────────────────────────────────────────────┤ │Ctot Guar_adspec_t Ctot total rate dep. error │ │ (bytes) │ ├──────────────────────────────────────────────────────────────────┤ │Dtot Guar_adspec_t Dtot total rate indep. err │ │ (microseconds) │ ├──────────────────────────────────────────────────────────────────┤ │r IS_Tspec_t IS_Tspec_r Token bucket rate (IP │ │ packet bytes/sec) │ ├──────────────────────────────────────────────────────────────────┤ │b IS_Tspec_t IS_Tspec_b Token bucket depth │ │ (bytes) │ ├──────────────────────────────────────────────────────────────────┤ │p IS_Tspec_t IS_Tspec_p Peak data rate (IP │ │ packet bytes/sec) │ ├──────────────────────────────────────────────────────────────────┤ │m IS_Tspec_t IS_Tspec_m Minimum Policed Unit │ │ (bytes) │ ├──────────────────────────────────────────────────────────────────┤ │M IS_Tspec_t IS_Tspec_M Maximum packet size │ │ (bytes) │ ├──────────────────────────────────────────────────────────────────┤ │R Guar_Rspec_t Guar_Rspec_R Guaranteed rate (IP │ │ packet bytes/sec) │ ├──────────────────────────────────────────────────────────────────┤ │S Guar_Rspec_t Guar_Rspec_S Slack term │ │ (microseconds) │ └──────────────────────────────────────────────────────────────────┘ Values for r, b, p, m, M, R, and S are to be computed for the guaranteed reservation. Assume that the reservation r, b, p, and m are chosen based on the original Tspec values in the path message. If Bmin is greater than r or p, they should be increased at least to Bmin. Assume that the reservation M is set to a reasonable value for the application that is not greater than MTU. Assume that the minimum delay is not greater than the maximum that the application can tolerate. Note that all computation described below should be in floating point, especially the division by 1000000 that converts between microseconds and seconds. If r <= p <= R then the upper bound on end-to-end requested delay (Dreq) in seconds is Dreq = (M+Ctot)/R + Dtot/1000000 If r <= R < p then the upper bound on Dreq in seconds is Dreq = [(b-M)/R*(p-R)/(p-r)] + (M+Ctot)/R + Dtot/1000000 The higher the value of R is, the lower Dreq will be. The application will choose an R value that is sufficiently high that the maximum delay is sufficent for what the sender and receiver need to do. Note that studies have shown that packets will often arrive much more quickly than the maximum delay, and therefore the application must be prepared to buffer them. If the peak rate p is unknown or unspecified, it should be set to infinity. Infinity is represented in IEEE floating point with an exponent of all one bits (255), and a sign and mantisa of all zero bits. In that case the upper bound on end-to-end delay in seconds simplifies to Dreq = b/R + Ctot/R + Dtot/1000000 The slack term S is the difference between the requested maximum delay and the desired delay, and must be a non-negative number. A typical desired delay is when R is set to r, in the ideal fluid model of flow. The delay is in that model is Dideal = b/r + Ctot/r + Dtot/1000000 The slack term can then be S = Dreq - Dideal. If the application chooses an S greater than zero, then RSVP-enabled nodes on the path can use it and the Csum and Dsum values to adjust their local reservations to lower the amount of resources allocated to the flow. Note that a guaranteed reservation may have its values R and S adjusted by intervening nodes, so that the reservation seen by the sender in the reservation message may be different from what the receiver provided with rapi_reserve(). For more information, refer to Internet RFC 1633 Integrated Services in the Internet Architecture: an Overview, and Internet Draft draft-ietf-intserv-ctrl-load-svc-07. ═══ 11. Reference Information ═══ This section describes:  Protocol-Independent C Sockets API Describes the protocol-independent socket calls supported by networking services. This information includes call syntax, usage, and related information.  TCP/IP Network Utility Routines API Describes the sockets utility and Sockets Secure Support (SOCKS) function calls supported by networking services. This information includes call syntax, usage, and related information.  Remote Procedure and eXternal Data Representation API Describes the remote procedure and XDR function calls along with their syntax, usage, and related information.  File Transfer Protocol API Describes the file transfer protocol function calls along with their syntax, usage, and related information.  Resource ReSerVation Protocol API Describes the resource reservation protocol function calls along with their syntax, usage, and related information. ═══ 12. Protocol-Independent C Sockets API ═══ The following table briefly describes each protocol-independent socket call supported by networking services and identifies where you can find the syntax, parameters, and other appropriate information. The socket calls described in this section can be used to access services for all protocols. Note: If you are using the internet communications domain (PF_INET protocol family), you can use all APIs in the following table and those in TCP/IP Network Utility Routines API. Protocol-Independent Sockets API Quick Reference ┌──────────────────────────────────────────────────────────────────┐ │Socket Call Description │ ├──────────────────────────────────────────────────────────────────┤ │accept() Accepts a connection request from a│ │ remote host │ ├──────────────────────────────────────────────────────────────────┤ │addsockettolist() Adds a socket to the list of owned │ │ sockets for the calling process │ ├──────────────────────────────────────────────────────────────────┤ │bind() Binds a local name to the socket │ ├──────────────────────────────────────────────────────────────────┤ │connect() Requests a connection to a remote │ │ host │ ├──────────────────────────────────────────────────────────────────┤ │getpeername() Gets the name of the peer connected│ │ to socket │ ├──────────────────────────────────────────────────────────────────┤ │getsockname() Gets the local socket name │ ├──────────────────────────────────────────────────────────────────┤ │getsockopt() Gets the socket options associated │ │ with a socket │ ├──────────────────────────────────────────────────────────────────┤ │ioctl() Performs special operations on │ │ socket │ ├──────────────────────────────────────────────────────────────────┤ │listen() Completes the binding necessary for│ │ a socket to accept connections and │ │ creates a connection request queue │ │ for incoming requests │ ├──────────────────────────────────────────────────────────────────┤ │os2_ioctl() Performs special operations on │ │ socket, particularly related to │ │ returning status from kernel │ ├──────────────────────────────────────────────────────────────────┤ │os2_select() Gets read, write, and exception │ │ status on a group of sockets (OS/2 │ │ version) │ ├──────────────────────────────────────────────────────────────────┤ │psock_errno() Writes a short error message to the│ │ standard error device │ ├──────────────────────────────────────────────────────────────────┤ │readv() Receives data on a socket into a │ │ set of buffers │ ├──────────────────────────────────────────────────────────────────┤ │recv() Receives data on a connected socket│ ├──────────────────────────────────────────────────────────────────┤ │recvfrom() Receives data on a socket │ ├──────────────────────────────────────────────────────────────────┤ │recvmsg() Receives data and control │ │ information on a socket │ ├──────────────────────────────────────────────────────────────────┤ │removesocketfromlist() Removes a socket from the list of │ │ owned sockets for the calling │ │ process │ ├──────────────────────────────────────────────────────────────────┤ │select() Gets read, write, and exception │ │ status on a group of sockets (BSD │ │ version) │ ├──────────────────────────────────────────────────────────────────┤ │send() Sends data on a connected socket │ ├──────────────────────────────────────────────────────────────────┤ │sendmsg() Sends data and control information │ │ on a socket │ ├──────────────────────────────────────────────────────────────────┤ │sendto() Sends data on a socket │ ├──────────────────────────────────────────────────────────────────┤ │setsockopt() Sets options associated with a │ │ socket │ ├──────────────────────────────────────────────────────────────────┤ │shutdown() Shuts down all or part of a full │ │ duplex connection │ ├──────────────────────────────────────────────────────────────────┤ │so_cancel() Cancels a pending blocking sockets │ │ API call on a socket │ ├──────────────────────────────────────────────────────────────────┤ │sock_errno() Returns error code set by a socket │ │ call │ ├──────────────────────────────────────────────────────────────────┤ │socket() Creates an endpoint for │ │ communication and returns a socket │ │ descriptor representing the │ │ endpoint │ ├──────────────────────────────────────────────────────────────────┤ │soclose() Shuts down a socket and frees │ │ resources allocated to the socket │ ├──────────────────────────────────────────────────────────────────┤ │sysctl() Performs special operations on the │ │ TCP/IP stack kernel │ ├──────────────────────────────────────────────────────────────────┤ │writev() Writes data from a set of specified│ │ buffers on a socket │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.1. accept() ═══ The accept() socket call accepts a connection request from a remote host. Raccept() accepts a connection request from a SOCKS server. See Socket Secure Support for information about SOCKS. Syntax #include #include #include #include #include int accept(s, name, namelen) int s; sockaddr *name; int *namelen; Parameters s Socket descriptor name Pointer to a sockaddr structure that contains the socket address of the connection client when the accept() call returns. The format of name is determined by the communications domain where the client resides. This parameter can be NULL if the caller is not interested in the client address. namelen Must initially point to an integer that contains the size in bytes of the storage pointed to by name. On return, that integer contains the size of the data returned in the storage pointed to by name. If name is NULL, namelen is ignored and can be NULL. Description This call is used by a server acting in a connection-oriented mode to accept a connection request from a client. The call accepts the first connection on its queue of pending connection requests. The accept() call creates a new socket descriptor with the same properties as s and returns it to the caller. The new socket descriptor cannot be used to accept new connections. The original socket, s, remains available to accept more connection requests. If the queue has no pending connection requests, accept() blocks the caller unless s is in nonblocking mode. If no connection requests are queued and s is in nonblocking mode, accept() returns a value of -1 and sets the return code to SOCEWOULDBLOCK. The s parameter must be a socket descriptor created with the socket() call. It is usually bound to an address with the bind() call and must be made capable of accepting connections with the listen() call. The listen() call marks the socket as one that accepts connections and allocates a queue to hold pending connection requests. The listen() call allows the caller to place an upper boundary on the size of the queue. The name parameter is a pointer to a buffer where the connection requester address is placed. The name parameter is optional and can be set to be the NULL pointer. If set to NULL, the requester address is not copied into the buffer. The exact format of name depends on the communications domain where the communication request originated. For example, if the connection request originated in the internet domain, name points to a sockaddr_in structure as defined in the header file . The namelen parameter is used only if name is not NULL. Before calling accept(), you must set the integer pointed to by namelen to the size, in bytes, of the buffer pointed to by name. On successful return, the integer pointed to by namelen contains the actual number of bytes copied into the buffer. If the buffer is not large enough to hold the address, up to namelen bytes of the requester address are copied. This call is used only with SOCK_STREAM or SOCK_SEQPACKET sockets. You cannot screen requesters without calling accept(). The application cannot tell the system the requesters it will accept connections from. The caller can, however, choose to close a connection immediately after discovering the identity of the requester. The select() call can be used to check the socket for incoming connection requests. Return Values A non-negative socket descriptor indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using name and namelen would result in an attempt to copy the address into a portion of the caller address space into which information cannot be written. SOCEINTR Interrupted system call. SOCEINVAL Listen() was not called for socket s. SOCENOBUFS Insufficient buffer space available to create the new socket. SOCEOPNOTSUPP The s parameter is not connection-oriented. SOCEWOULDBLOCK The s parameter is in nonblocking mode and no connections are on the queue. SOCECONNABORTED The software caused a connection close. Examples The following are two examples of the accept() call. In the first, the caller wants to have the requester address returned. In the second, the caller does not want to have the requester address returned. int clientsocket; int s; struct sockaddr clientaddress; int addrlen; int accept(int s, struct sockaddr *addr, int *addrlen); /* extracted from sys/socket.h */ /* socket(), bind(), and listen() have been called */ /* EXAMPLE 1: I want the address now */ addrlen = sizeof(clientaddress); clientsocket = accept(s, &clientaddress, &addrlen); /* EXAMPLE 2: I can get the address later using getpeername() */ clientsocket = accept(s, (struct sockaddr *) 0, (int *) 0); Related Calls bind() connect() getpeername() getsockname() listen() sock_errno() socket() ═══ 12.2. addsockettolist() ═══ The addsockettolist() call adds a socket to the list of owned sockets for the calling process. Syntax #include #include void addsockettolist(s) int s; Parameters s Socket descriptor Description When a process ends, the sockets library automatically cleans up sockets by registering an exit list handler. This exit routine closes all open sockets that are maintained in a process's socket list. When a process is initiated the list is empty, and whenever a socket(), accept(), or soclose() call is made the list is updated. The addsockettolist() call provides a mechanism to transfer socket ownership to another process. The addsockettolist() call adds the socket indicated by the s parameter to the calling process's socket ownership list. Return Values The value 1 indicates success; the value 0 indicates an error. Related Calls removesocketfromlist() ═══ 12.3. bind() ═══ The bind() socket call binds a local name to the socket. Rbind() binds a SOCKS local name to the socket. See Socket Secure Support for information about SOCKS. Syntax #include #include int bind(s, name, namelen) int s; struct sockaddr *name; int namelen; Parameters s Socket descriptor returned by a previous call to socket() name Pointer to a sockaddr structure containing the name that is to be bound to s namelen Size in bytes of the sockaddr structure pointed to by name Description The bind() call binds a unique local name to the socket with descriptor s. After calling socket(), a descriptor does not have a name associated with it. However, it does belong to a particular addressing family as specified when socket() is called. The exact format of a name depends on the addressing family. The bind() procedure also allows servers to specify from which network interfaces they wish to receive UDP packets and TCP connection requests. If s was created in the AF_INET domain, the format of the name buffer is expected to be sockaddr_in as defined in the header file : struct in_addr { u_long s_addr; }; struct sockaddr_in { u_char sin_len; u_char sin_family; u_short sin_port; struct in_addr sin_addr; char sin_zero[8]; }; The sin_len field is ignored. The sin_family field must be set to AF_INET. The sin_port field is set to the port that the application must bind to. It must be specified in network byte order. If sin_port is set to 0, the caller leaves it to the system to assign an available port. The application can call getsockname() to discover the port number assigned. The sin_addr field is set to the internet address and must be specified in network byte order. On hosts with more than one network interface (called multihomed hosts), a caller can select the interface that the host will bind to. Subsequently, only UDP packets or TCP connection requests which match the bound name from this interface are routed to the socket. If sin_addr is set to the constant INADDR_ANY, as defined in , the caller is requesting that the socket be bound to all network interfaces on the host. After this, UDP packets or TCP connections which match the bound name from all interfaces are routed to the socket. This becomes important when a server offers a service to multiple networks. By leaving the address unspecified, the server can accept all UDP packets or TCP connection requests made for its port, regardless of the network interface on which the requests arrived. The sin_zero field is not used and must be set to all zeros. In the NetBIOS (AF_NET) domain, set all 16 characters in snb_name in the sockaddr_nb structure to binary zeros (null). The system will generate a name for the socket. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCEADDRINUSE The address is already in use. See the SO_REUSEADDR option described under getsockopt() and the SO_REUSEADDR option described under setsockopt(). SOCEADDRNOTAVAIL The address specified is not valid on this host. For example, the internet address does not specify a valid network interface. SOCEAFNOSUPPORT The address family is not supported. SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using name and namelen would result in an attempt to copy the address into a non-writable portion of the caller's address space. SOCEINVAL The socket is already bound to an address, or namelen is not the expected length. SOCENOBUFS No buffer space is available. Examples Note the following about the bind() call examples:  For the internet examples, put the internet address and port in network-byte order. To put the port into network-byte order, use the htons() utility routine to convert a short integer from host-byte order to network-byte order.  For the internet examples, set the address field using the inet_addr() utility routine, which takes a character string representing the dotted-decimal address of an interface and returns the binary internet address representation in network-byte order.  Zero the structure before using it to ensure that the name requested does not set any reserved fields. See connect() for examples of how a client might connect to servers. int rc; int s; struct sockaddr_in myname; int bind(int s, struct sockaddr *name, int namelen); /* extracted from sys/socket.h */ /* Bind to a specific interface in the internet domain */ /* clear the structure */ memset(&myname, 0, sizeof(myname)); myname.sin_family = AF_INET; myname.sin_addr = inet_addr("129.5.24.1"); /* specific interface */ myname.sin_port = htons(1024); ... rc = bind(s, (struct sockaddr *) &myname, sizeof(myname)); /* Bind to all internet network interfaces on the system */ /* clear the structure */ memset(&myname, 0, sizeof(myname)); myname.sin_family = AF_INET; myname.sin_addr.s_addr = INADDR_ANY; /* all interfaces */ myname.sin_port = htons(1024); ... rc = bind(s, (struct sockaddr *) &myname, sizeof(myname)); /* Bind to a specific interface in the internet domain. Let the system choose a port */ /* clear the structure */ memset(&myname, 0, sizeof(myname)); myname.sin_family = AF_INET; myname.sin_addr = inet_addr("129.5.24.1"); /* specific interface */ myname.sin_port = 0; ... rc = bind(s, (struct sockaddr *) &myname, sizeof(myname)); /* Bind to a unique NetBIOS name on adapter 0 */ struct sockaddr_nb nbname; memset(&nbname, 0, sizeof(nbname)); nbname.snb_family = AF_NB; nbname.snb_type = NB_UNIQUE; nbname.snb_adapter = 0; strcpy(nbname.snb_name, "NBSERVER"); /* Note that a NetBIOS name is 16 bytes long. In this example, the last 8 bytes are filled with zeros. */ ... rc = bind(s, (struct sockaddr *) &nbname, sizeof(nbname)); Related Calls connect() gethostbyname() getsockname() htons() inet_addr() listen() sock_errno() socket() ═══ 12.4. connect() ═══ The connect() socket call requests a connection to a remote host. Syntax #include #include int connect(s, name, namelen) int s; struct sockaddr *name; int namelen; Parameters s Socket descriptor used to originate the connection request name Pointer to a sockaddr structure containing the address of the socket to which a connection will be attempted namelen Size in bytes of the sockaddr structure pointed to by name Description The following diagram illustrates connect() processing: connect() Processing If you are using a SOCKS server, connect() calls Rconnect(). See Socket Secure Support for information about SOCKS. Stream or sequenced packet sockets: The connect() call performs two tasks when called for a stream or sequenced packet socket: 1. Completes the binding if necessary for a socket 2. Attempts to create a connection between two sockets. This call is used by the client side of socket-based applications to establish a connection with a server. The remote server must have a passive open pending. This means the server must successfully call bind() and listen(); otherwise, connect() returns a value of -1 and the error value is set to SOCECONNREFUSED. If you are using a SOCKS server and the connection is rejected by the SOCKS server, the return code will be SOCECONNREFUSED. In the internet communication domain, a timeout occurs if a connection to the remote host is not successful within 75 seconds (1 minute and 15 seconds). There is no timeout for Local IPC. In the NetBIOS communication domain, a timeout occurs if a connection to the host is not successful within the time defined by the NetBIOS protocol parameters Transmit Timer multiplied by Transmit Retry. If s is in blocking mode, the connect() call blocks the caller until the connection is established or until an error is received. If the socket is in nonblocking mode, and the connection was successfully initiated, connect() returns a value of -1 and sets the error value to SOCEINPROGRESS. The caller can test the completion of the connection setup by calling:  select(), to test for the ability to write to the socket  getsockopt(), with option SO_ERROR, to test if the connection succeeded Stream or sequenced packet sockets can call connect() only once. Datagram or raw sockets: The connect() call specifies the destination peer address when called for a datagram or raw socket. Normally, datagram and raw sockets use connectionless data transfer calls such as sendto() and recvfrom(). However, applications can call connect() to specify and store the destination peer address for this socket. The system will then know which address to send data to on this socket. This method of communication allows datagram and raw sockets to be connected. However, data is still not guaranteed to be delivered. Thus the normal features of connectionless mode sockets are maintained. The address is remembered until another connect() call is made. This permits the use of readv(), recv(), send(), and writev(), which are usually reserved for connection-oriented sockets. The application can still use sendto(), recvfrom(), sendmsg(), and recvmsg(). The advantage of calling connect() and being connected is that the destination peer address does not have to be specified for all datagrams sent. Datagram and raw sockets can call connect() multiple times. The application can reset their destination address by specifying a new address on the connect() call. In addition, the socket can be returned to operate in a connectionless mode by calling connect() with a null destination address. The null address is created by zeroing the sockaddr structure and only setting the address family field. The call to connect will return a value of -1, indicating that the connection to the null address cannot be established. Calling sock_errno() will return SOCEADDRNOTAVAIL. For more information on connecting datagram sockets, see Description for sendto(). Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). If you are using a SOCKS server and the SOCKS server rejects the connection, the return code will be SOCECONNREFUSED. Error Code Description SOCEADDRNOTAVAIL The calling host cannot reach the specified destination. SOCEAFNOSUPPORT The address family is not supported. SOCEALREADY The socket s is marked nonblocking, and a previous connection attempt has not completed. SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCECONNREFUSED The connection request was rejected by the destination host. If you are using a SOCKS server and the SOCKS server rejects the connection, the return code will be SOCECONNREFUSED. SOCEFAULT Using name and namelen would result in an attempt to copy the address into a portion of the caller's address space to which data cannot be written. SOCEINPROGRESS The socket s is marked nonblocking, and the connection cannot be completed immediately. The SOCEINPROGRESS value does not indicate an error condition. SOCEINTR Interrupted system call. SOCEINVAL The namelen parameter is not a valid length. SOCEISCONN The socket s is already connected. SOCENETUNREACH The network cannot be reached from this host. SOCETIMEDOUT The connection establishment timed out before a connection was made. SOCENOBUFS No buffer space is available. SOCEOPNOTSUPP The operation is not supported on socket s. Examples Note the following about these connect() call examples:  For the internet examples, put the internet address and port in network-byte order. To put the port into network-byte order, use the htons() utility routine to convert a short integer from host-byte order to network-byte order.  For the internet examples, set the address field using the inet_addr() utility routine, which takes a character string representing the dotted-decimal address of an interface and returns the binary internet address representation in network-byte order.  To ensure that the name requested does not set any reserved fields, zero the structure before using it. These examples could be used to connect to the servers shown in the examples listed for bind(). int s; struct sockaddr_in servername; int rc; int connect(int s, struct sockaddr *name, int namelen); /* extracted from sys/socket.h */ /* Connect to server bound to a specific interface in the internet domain */ /* clear the structure */ memset(&servername, 0, sizeof(servername)); servername.sin_family = AF_INET; servername.sin_addr.s_addr = inet_addr("129.5.24.1"); /* specific interface */ servername.sin_port = htons(1024); /* set to the port to which */ /* the server is bound */ ... rc = connect(s, (struct sockaddr *) &servername, sizeof(servername)); /* Connect to a NetBIOS server */ struct sockaddr_nb nbservername; memset(&nbservername, 0, sizeof(nbservername)); nbservername.snb_family = AF_NB; nbservername.snb_type = NB_UNIQUE; nbservername.snb_adapter = 0; strcpy(nbservername.snb_name, "NBSERVER"); ... rc = connect(s, (struct sockaddr *) &nbservername, sizeof(nbservername)); Related Calls accept() bind() getsockname() htons() inet_addr() listen() Rconnect() select() send() sock_errno() socket() ═══ 12.5. getpeername() ═══ The getpeername() socket call gets the name of the peer connected to socket. Syntax #include #include int getpeername(s, name, namelen) int s; struct sockaddr *name; int *namelen; Parameters s Socket descriptor. name Pointer to a sockaddr structure. The name of the peer connected to socket s is returned. The exact format of name is determined by the domain where communication occurs. namelen Pointer to the size in bytes of the sockaddr structure pointed to by name. Description This call returns the name of the peer connected to socket s. The namelen parameter must be initialized to indicate the size of the space pointed to by name. On return, namelen is set to the size of the peer name copied. If the buffer is too small, the peer name is truncated. The getpeername() call operates only on connected sockets. If the connection is through a SOCKS server, the address returned will be that of the SOCKS server. A process can use the getsockname() call to retrieve the local address of a socket. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the name and namelen parameters as specified would result in an attempt to access storage outside of the address space of the caller. SOCENOTCONN The socket is not connected. SOCENOBUFS No buffer space is available. Related Calls accept() bind() connect() getsockname() Rgetsockname() sock_errno() socket() ═══ 12.6. getsockname() ═══ The getsockname() socket call gets the local socket name. If you are using a SOCKS server, see Socket Secure Support for information about SOCKS. Syntax #include #include int getsockname(s, name, namelen) int s; struct sockaddr *name; int *namelen; Parameters s Socket descriptor. name Pointer to a sockaddr structure. The name of s is returned. namelen Pointer to the size in bytes of the buffer pointed to by name. Description This call returns the name for the socket specified by the s parameter in the structure pointed to by the name parameter. It returns the address to the socket that has been bound. If the socket is not bound to an address, the call returns with the family set and the rest of the structure is set to zero. For example, an unbound socket in the internet domain would cause the name to point to a sockaddr_in structure with the sin_family field set to AF_INET and all other fields zeroed. The namelen parameter must be initialized to indicate the size of the space pointed to by name and is set to the size of the local name copied. If the buffer is too small, the local name is truncated. Sockets are explicitly assigned a name after a successful call to bind(). Stream and sequenced packet sockets are implicitly assigned a name after a successful call to connect() or accept() if bind() was not called. If the socket is connected through a SOCKS server, this call returns the IP address and port of the local machine that is being used to communicate with the SOCKS server. The getsockname() call is often used to discover the port assigned to a socket after the socket has been implicitly bound to a port. For example, an application can call connect() without previously calling bind(). In this case, the connect() call completes the binding necessary by assigning a port to the socket. A process can use the getpeername() call to determine the address of a destination socket in a socket connection. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the name and namelen parameters as specified would result in an attempt to access storage outside of the address space of the caller. SOCENOBUFS No buffer space available. Related Calls accept() bind() connect() getpeername() Rgetsockname() sock_errno() socket() ═══ 12.7. getsockopt() ═══ The getsockopt() socket call gets the socket options associated with a socket. Syntax #include #include int getsockopt(s, level, optname, optval, optlen) int s; int level; int optname; char *optval; int *optlen; Parameters s Socket descriptor. level Specifies which option level is being queried for the specified optname. optname Name of a specified socket option. Only one option can be specified on a call. optval Pointer to buffer to receive the option data requested. optlen Pointer to the size of the buffer. Description This call returns the value of a socket option at the socket or protocol level. It can be called for sockets of all domain types. Some options are supported only for specific socket types. You must specify the level of the option and the name of the option to retrieve option values. The following table lists the supported levels. Supported Levels ┌─────────────────────────────────────────────────────────────────┐ │Supported Level #define in │ ├─────────────────────────────────────────────────────────────────┤ │SOL_SOCKET │ ├─────────────────────────────────────────────────────────────────┤ │IPPROTO_IP │ ├─────────────────────────────────────────────────────────────────┤ │IPPROTO_TCP │ ├─────────────────────────────────────────────────────────────────┤ │NBPROTO_NB │ └─────────────────────────────────────────────────────────────────┘ The optval parameter is a pointer to the buffer where the option values are returned. The optlen parameter must be initially set to the size of the buffer before calling getsockopt(). On return, the optlen parameter is set to the actual size of the data returned. For socket options that are Boolean, the option is enabled if optval is nonzero and disabled if optval is 0. The following tables list the supported options for getsockopt() at each level (SOL_SOCKET, IPPROTO_IP, IPPROTO_TCP). Detailed descriptions of the options follow each table. Supported getsockopt() Socket Options for SOL_SOCKET ┌────────────────────────────────────────────────────────────────────┐ │Option Name Description Domains(*) Data Boolean │ │ Type or Value│ ├────────────────────────────────────────────────────────────────────┤ │SO_ACCEPTCONN listen status I, L int boolean │ ├────────────────────────────────────────────────────────────────────┤ │SO_BROADCAST allow sending of I, N int boolean │ │ broadcast messages │ ├────────────────────────────────────────────────────────────────────┤ │SO_DEBUG turn on recording of I, L int boolean │ │ debugging information │ ├────────────────────────────────────────────────────────────────────┤ │SO_DONTROUTE bypass routing tables I, L int boolean │ ├────────────────────────────────────────────────────────────────────┤ │SO_ERROR return any pending I, L int value │ │ error and clear │ ├────────────────────────────────────────────────────────────────────┤ │SO_KEEPALIVE keep connections alive I int boolean │ ├────────────────────────────────────────────────────────────────────┤ │SO_LINGER linger on close if data I struct value │ │ present linger │ ├────────────────────────────────────────────────────────────────────┤ │SO_L_BROADCAST limited broadcast sent I int boolean │ │ on all interfaces │ ├────────────────────────────────────────────────────────────────────┤ │SO_OOBINLINE leave received OOB data I int boolean │ │ in-line │ ├────────────────────────────────────────────────────────────────────┤ │SO_RCVBUF receive buffer size I, L, N int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_RCV_SHUTDOWN if shutdown called for I, L int boolean │ │ receive │ ├────────────────────────────────────────────────────────────────────┤ │SO_RCVLOWAT receive low water mark I, L int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_RCVTIMEO receive timeout I, L int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_REUSEADDR allow local address I, N int boolean │ │ reuse │ ├────────────────────────────────────────────────────────────────────┤ │SO_REUSEPORT allow local port reuse I int boolean │ ├────────────────────────────────────────────────────────────────────┤ │SO_SNDBUF send buffer size I, L, N int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_SND_SHUTDOWN if shutdown called for I, L int boolean │ │ send │ ├────────────────────────────────────────────────────────────────────┤ │SO_SNDLOWAT send low water mark I, L int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_SNDTIMEO send timeout I, L int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_TYPE socket type I, L, N int value │ ├────────────────────────────────────────────────────────────────────┤ │SO_USELOOPBACK bypass hardware when I, L int boolean │ │ possible │ └────────────────────────────────────────────────────────────────────┘ Table Note (*) This column specifies the communication domains to which this option applies: I for internet, L for local IPC, and N for NetBIOS. The following options are recognized for SOL_SOCKET: Option Description SO_ACCEPTCONN Returns true if the socket is in the listen state. SO_BROADCAST (datagram sockets only) Retrieves the current status of the SO_BROADCAST option. When this option is enabled, the application can send broadcast messages over s, if the interface specified in the destination supports broadcasting of packets. SO_DEBUG Retrieves the current status of the SO_DEBUG option. SO_DONTROUTE Retrieves the current status of the SO_DONTROUTE option. When this option is enabled, it causes outgoing messages to bypass the standard routing algorithm and be directed to the appropriate network interface, according to the network portion of the destination address. When enabled, packets can be sent only to directly connected networks (networks for which this host has an interface). SO_ERROR Returns any pending error on the socket and clears the error status. It can be used to check for asynchronous errors on connected datagram sockets or for other asynchronous errors (errors that are not returned explicitly by one of the socket calls). SO_KEEPALIVE (stream sockets only) Retrieves the current status of the SO_KEEPALIVE option. TCP uses a timer called the keepalive timer. This timer is used to monitor idle connections that might have been disconnected because of a peer crash or timeout. When this option is enabled, a keepalive packet is periodically sent to the peer. This is mainly used to allow servers to close connections that are no longer active as a result of clients going away without properly closing connections. SO_LINGER (stream sockets only) Retrieves the current status of the SO_LINGER option. When this option is enabled and there is unsent data present when soclose() is called, the calling application is blocked during the soclose() call until the data is transmitted or the connection has timed out. When this option is disabled, the soclose() call returns without blocking the caller, and TCP waits to try to send the data. Although the data transfer is usually successful, it cannot be guaranteed, because TCP waits only a finite amount of time to send the data. SO_L_BROADCAST Gets limited broadcast sent on all interfaces. SO_OOBINLINE (stream sockets only) Retrieves the current status of the SO_OOBINLINE option. When this option is enabled, it causes out-of-band data to be placed in the normal data input queue as it is received, making it available to recv(), and recvfrom() without having to specify the MSG_OOB flag in those calls. When this option is disabled, it causes out-of-band data to be placed in the priority data input queue as it is received, making it available to recv(), and recvfrom(), only by specifying the MSG_OOB flag in those calls. SO_RCVBUF Retrieves buffer size for input. This value tailors the receive buffer size for specific application needs, such as increasing the buffer size for high-volume connections. SO_RCV_SHUTDOWN Returns true if shutdown was called for receive. SO_RCVLOWAT Retrieves the receive low water mark. SO_RCVTIMEO Retrieves the receive timeout. SO_REUSEADDR (stream and datagram sockets only) Retrieves the current status of the SO_REUSEADDR option. When this option is enabled, local addresses that are already in use can be bound. This alters the normal algorithm used in the bind() call. At connect time, the system checks to be sure that no local address and port have the same foreign address and port. The error SOCEADDRINUSE is returned if the association already exists. SO_REUSEPORT (stream and datagram sockets only) Retrieves the current status of the SO_REUSEPORT option. This option specifies that the rules used in validating ports supplied by a bind subroutine should allow reuse of a local port/address combination. Each binding of the port/address combination must specify the socket option. This option enables or disables the reuse of local port/address combinations. SO_SNDBUF Retrieves the send buffer size. This value tailors the send buffer size for specific application needs, such as increasing the buffer size for high-volume connections. SO_SND_SHUTDOWN Returns true if shutdown was called for send. SO_SNDLOWAT Retrieves the send low water mark. SO_SNDTIMEO Retrieves the send timeout. SO_TYPE Retrieves the socket type. On return, the integer pointed to by optval is set to one of the following: SOCK_STREAM, SOCK_DGRAM, or SOCK_RAW. SO_USELOOPBACK Bypasses hardware when possible. struct linger: For the SO_LINGER option, optval points to a linger structure. This structure is defined in and contains the following fields: Field Description l_onoff Option on/off l_linger Linger time The l_onoff field is set to zero if the SO_LINGER option is being disabled. A nonzero value enables the option. The l_linger field specifies the amount of time in seconds to linger on close. A value of zero will cause soclose() to wait until the disconnect completes. Supported getsockopt() Socket Options for IPPROTO_IP ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value│ ├───────────────────────────────────────────────────────────────────┤ │IP_HDRINCL header is included with int boolean │ │ data │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_IF default interface for struct value │ │ outgoing multicasts in_addr │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_LOOP loopback of outgoing uchar boolean │ │ multicast │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_TTL default TTL for outgoing uchar value │ │ multicast │ ├───────────────────────────────────────────────────────────────────┤ │IP_OPTIONS IP options char * value │ ├───────────────────────────────────────────────────────────────────┤ │IP_RECVDSTADDR queueing IP destination int boolean │ │ address │ ├───────────────────────────────────────────────────────────────────┤ │IP_RECVTRRI queueing token ring int boolean │ │ routing information │ ├───────────────────────────────────────────────────────────────────┤ │IP_RETOPTS IP options char * value │ ├───────────────────────────────────────────────────────────────────┤ │IP_TOS IP type of service for int value │ │ outgoing datagrams │ ├───────────────────────────────────────────────────────────────────┤ │IP_TTL IP time to live for int value │ │ outgoing datagrams │ └───────────────────────────────────────────────────────────────────┘ The following options are recognized for IPPROTO_IP: Option Description IP_HDRINCL (raw sockets only) Specifies whether the IP header is included with data. IP_MULTICAST_IF Retrieves the default interface for outgoing multicasts. IP_MULTICAST_LOOP Retrieves value of loopback setting for outgoing multicast. IP_MULTICAST_TTL Retrieves the default TTL for outgoing multicast packets. IP_OPTIONS Retrieves IP options. Same as IP_RETOPTS. The data type is char * ip_retopts[4], such as ip_retopts[0]=IPOPT_OPTVAL ip_retopts[1]=IPOPT_OLEN ip_retopts[2]=IPOPT_OFFSET ip_retopts[3]=IPOPT_MINOFF For an example that uses IP_RETOPTS, see Example of IP_RETOPTS Socket Call. IP_RECVDSTADDR (UDP only) Retrieves queueing IP destination address. This option must get this information through a recvmsg() call. For more information, see Example of recvmsg() Call. IP_RECVTRRI (UDP only. Only for token ring) Retrieves the current ability for queueing token ring routing information. IP_RETOPTS Retrieves IP options to be included in outgoing datagrams. The data type is char * ip_retopts[4], such as ip_retopts[0]=IPOPT_OPTVAL ip_retopts[1]=IPOPT_OLEN ip_retopts[2]=IPOPT_OFFSET ip_retopts[3]=IPOPT_MINOFF For an example that uses IP_RETOPTS, see Example of IP_RETOPTS Socket Call. IP_TOS Retrieves IP type of service for outgoing datagrams. IP_TTL Retrieves IP time to live value for outgoing datagrams. Supported getsockopt() Socket Options for IPPROTO_TCP ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_CC connection count function int boolean │ ├───────────────────────────────────────────────────────────────────┤ │TCP_MAXSEG maximum segment size int value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_MSL TCP MSL value int value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_NODELAY don't delay send to int boolean │ │ coalesce packets │ ├───────────────────────────────────────────────────────────────────┤ │TCP_TIMESTMP time stamp function int boolean │ ├───────────────────────────────────────────────────────────────────┤ │TCP_WINSCALE window scale function int boolean │ └───────────────────────────────────────────────────────────────────┘ The following options are recognized for IPPROTO_TCP: Option Description TCP_CC (TTCP only) Retrieves the connection count function status flag (RFC 1644). TCP_MAXSEG Retrieves the maximum segment size. TCP_MSL Retrieves the TCP Maximum Segment Lifetime (MSL) value. TCP_NODELAY (stream sockets only) Retrieves the current status of the TCP_NODELAY option. Disables the buffering algorithm so that the client's TCP sends small packets as soon as possible. This often has no performance effects on LANs, but can degrade performance on Wide Area Networks (WAN). TCP_TIMESTMP (TTCP only) Retrieves the TCP timestamp function status flag (RFC 1323). TCP_WINSCALE (TTCP only) Retrieves the window scale function status flag (RFC 1323). Supported getsockopt() Socket Options for NBPROTO_NB ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value │ ├───────────────────────────────────────────────────────────────────┤ │NB_DGRAM_TYPE type of datagrams to int value │ │ receive │ └───────────────────────────────────────────────────────────────────┘ The following option is recognized for NBPROTO_NB: Option Description NB_DGRAM_TYPE (datagram sockets only) Retrieves the type of datagrams to be received on the socket. The possible values are: NB_DGRAM The socket is to receive normal (unicast) datagrams only. NB_BROADCAST The socket is to receive broadcast datagrams only .. NB_DGRAM_ANY The socket can receive both normal or broadcast datagrams. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCEADDRINUSE The address is already in use. SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using optval and optlen parameters would result in an attempt to access memory outside the caller's address space. SOCENOPROTOOPT The optname parameter or level parameter is not recognized. Examples The following are examples of the getsockopt() call. See setsockopt() for examples of how the options are set. int rc; int s; int optval; int optlen; struct linger lstruct; int getsockopt(int s, int level, int optname, char *optval, int *optlen); /* extracted from sys/socket.h */ ... /* Is out of band data in the normal input queue? */ optlen = sizeof(int); rc = getsockopt( s, SOL_SOCKET, SO_OOBINLINE, (char *) &optval, &optlen); if (rc == 0) { if (optlen == sizeof(int)) { if (optval) /* yes it is in the normal queue */ else /* no it is not */ } } ... /* Do I linger on close? */ optlen = sizeof(lstruct); rc = getsockopt( s, SOL_SOCKET, SO_LINGER, (char *) &lstruct, &optlen); if (rc == 0) { if (optlen == sizeof(lstruct)) { if (lstruct.l_onoff) /* yes I linger */ else /* no I do not */ } } The following is an example of the ip_retopts socket option. Example of IP_RETOPTS Socket Call /* [0]:IPOPT_OPTVAL, [1]:IPOPT_OLEN, [2]:IPOPT_OFFSET, [3]:IPOPT_MINOFF */ char ip_retopts[8]; main() { int optlen, sraw, i; if ((sraw = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) psock_errno("Socket()"); printf("IP_RETOPTS or OP_OPTIONS will get/set the IP options \n"); ip_retopts[IPOPT_OPTVAL] = IPOPT_TS ; /* TimeStamp IP options to set */ ip_retopts[IPOPT_OLEN] = 8; ip_retopts[IPOPT_OFFSET] = 4; ip_retopts[IPOPT_MINOFF] = 4; printf("Setting the IP_RETOPTS to TimeStamp option (%d) \n", ip_retopts[IPOPT_OPTVAL]); if (setsockopt(sraw,IPPROTO_IP,IP_RETOPTS,(char *)&ip_retopts[0] , sizeof(ip_retopts)) < 0) psock_errno("setsockopt() IP_RETOPTS"); /* NOTE ::: when the getsockopt returns it will stick in the first hop */ /* destination in the first 4 bytes by shifting all data right. */ memset(ip_retopts, 0, sizeof(ip_retopts)); printf("Get the ip_retopts value set for this socket\n"); optlen = sizeof(ip_retopts); if (getsockopt(sraw,IPPROTO_IP,IP_OPTIONS,(char *)ip_retopts,&optlen) < 0) { psock_errno("getsockopt() IP_RETOPTS "); } else { if (ip_retopts[4+IPOPT_OPTVAL] == IPOPT_TS) printf ("IP_RETOPTS now set to TimeStamp option(%d) \n", ip_retopts[4+IPOPT_OPTVAL]); else printf ("IP_RETOPTS now set to ??? (%d) \n", ip_retopts[4+IPOPT_OPTVAL]); } soclose(sraw); } Related Calls bind() endprotoent() getprotobyname() getprotobynumber() getprotoent() setprotoent() setsockopt() sock_errno() socket() ═══ 12.8. ioctl() ═══ The ioctl() socket call performs special operations on socket. Syntax #include #include #include #include #include #include int ioctl(s, cmd, data) int s; int cmd; caddr_t data; Parameters s Socket descriptor cmd Command to perform data Pointer to the data associated with cmd Description This call controls the operating characteristics of sockets. The data parameter is a pointer to data associated with the particular command, and its format depends on the command that is requested. Option Description FIOASYNC This option has no effect. FIONBIO Sets or clears nonblocking input/output for a socket. When this option is set, input/output calls will not block until the call is completed. The data parameter is a pointer to an integer. If the integer is 0, nonblocking input/output on the socket is cleared. Otherwise, the socket is set for nonblocking input/output. FIONREAD Gets the number of immediately readable bytes for the socket. The data parameter is a pointer to an integer. Sets the value of the integer to the number of immediately readable characters for the socket. Internet: The following ioctl commands are supported for the internet domain: Option Description OSIOCGIFADDR Provided for compatibility with releases of TCP/IP prior to 4.1. data is a pointer to an ifreq structure. The interface address is returned in the old sockaddr format in the argument. OSIOCGIFDSTADDR Provided for compatibility with releases of TCP/IP prior to 4.1. data is a pointer to an ifreq structure. The destination address is returned in the old sockaddr format in the argument. OSIOCGIFBRDADDR Provided for compatibility with releases of TCP/IP prior to 4.1. data is a pointer to an ifreq structure. The broadcast address is returned in the old sockaddr format in the argument. OSIOCGIFCONF Provided for compatibility with releases of TCP/IP prior to 4.1. data is a pointer to an ifreq structure. The interface configuration is returned in the old sockaddr format in the argument. OSIOCGIFNETMASK Provided for compatibility with releases of TCP/IP prior to 4.1. data is a pointer to an ifreq structure. The interface netmask is returned in the old sockaddr format in the argument. SIOCADDMULTI Adds a 48-bit physical multicast address. This works only for Ethernet. data is a pointer to an ifreq structure. SIOCADDRT Adds a routing table entry. data is a pointer to an rtentry structure, as defined in . The routing table entry, passed as an argument, is added to the routing tables. SIOCAIFADDR Adds an IP address for an interface. data is a pointer to an ifaliasreq structure, which is defined in SIOCARP Sends an ARP request to all interfaces for a given IP address. data is a pointer to the IP address in the type of an unsigned long integer. SIOCATMARK Queries whether the current location in the data input is pointing to out-of-band data. data is a pointer to an integer. Sets the argument to 1 if the socket points to a mark in the data stream for out-of-band data. Otherwise, sets the argument to 0. SIOCDARP Deletes an arp table entry. data is a pointer to an arpreq as defined in . The arp table entry passed as an argument is deleted from the arp tables, if it exists. SIOCDELMULTI Deletes a 48-bit physical multicast address. This works only for Ethernet. ifr is of type ifreq, which is defined in . SIOCDELRT Deletes a routing table entry. data is a pointer to a rtentry structure, as defined in . If it exists, the routing table entry passed as an argument is deleted from the routing tables. SIOCDIFADDR Deletes an IP address for an interface. data is a pointer to an ifreq structure, defined in . SIOCGARP Gets the arp table entries. data is a pointer to an arpreq, as defined in . The arp table entry passed as an argument is returned from the arp tables if it exists. SIOCGARP_TR Gets the token-ring arp table entries with routing information field. data is a pointer to an arpreq_tr structure, as defined in . The arp table entry from the arp table is returned if it exists. SIOCGIFADDR Gets the network interface address. data is a pointer to an ifreq structure, as defined in . The interface address is returned in the argument. SIOCGIFBOUND Checks the number of Medium Access Control (MAC) drivers that will be bound or have been bound. data is a pointer to a bndreq structure, defined in . The bindinds variable in the structure will return the number of MAC drivers that the INET protocol will bind to, and the bound variable will return the number of MAC drivers that have been bound. SIOCGIFBRDADDR Gets the network interface broadcast address. data is a pointer to an ifreq structure, as defined in . The interface broadcast address is returned in the argument. SIOCGIFCONF Gets the network interface configuration. data is a pointer to an ifconf structure, as defined in . The interface configuration is returned in the argument. It is important to note that the ifconf structure changed in TCP/IP 4.1. SIOCGIFDSTADDR Gets the network interface destination address. data is a pointer to an ifreq structure, as defined in . The interface destination (point-to-point) address is returned in the argument. SIOCGIFEFLAGS Gets extended flags for the interface. data is a pointer to an ifreq structure, as defined in . The interface extended flags are returned in the ifr_eflags field. SIOCGIFFLAGS Gets the network interface flags. data is a pointer to an ifreq structure, as defined in . The interface flags are returned in the ifr_flags field. SIOCGIFMETRIC Gets the network interface routing metric. data is a pointer to an ifreq structure, as defined in . The interface routing metric is returned in the ifr_metric field. SIOCGIFMTU Gets the interface MTU value. data is a pointer to an ifreq structure, as defined in . The interface MTU is returned in the ifr_metric field. SIOCGIFNETMASK Gets the network interface network mask. data is a pointer to an ifreq structure, as defined in . The interface network mask is returned in the ifr_dstaddr field. SIOCGIFTRACE Gets data from the interface i/o tracing buffer. data is a pointer to an ifreq structure, as defined in . The ifr_data field should point to the pkt_trace_hdr structure as defined in . SIOCGIFVALID Checks if the interface is valid. data is a pointer to an ifreq structure, as defined in . SIOCGMCAST Gets the joined multicast addresses for the interface. data is a pointer to an addrreq structure, as defined in . SIOCGMSL Gets the TCP Maximum Segment Lifetime (MSL) value, in seconds. SIOCGSTAT Gets the serial link interface statistics. data is a pointer to an ifreq structure, as defined in . The ifr_data field should point to an ifstat structure, as defined in . SIOCGUNIT Gets the interface unit number. SIOCMULTISBC Use broadcast for physical transmission of IP multicast datagrams. (RFC 1469). SIOCMULTISFA Use functional address for physical transmission of IP multicast datagrams. (RFC 1469). SIOCSARP Sets an arp table entry. data is a pointer to an arpreq as defined in . The arp table entry passed as an argument is added to the arp tables. SIOCSARP_TR Sets a token-ring arp table entry with routing information. data is a pointer to an arp_req structure, as defined in . SIOCSHOSTID Sets the IP address of the host that will be displayed by the hostid.exe utility. data is a pointer to the IP address of the type of unsigned long. SIOCSIF802_3 Sets the interface to send packets in 802.3 format. data is a pointer to an ifreq structure, as defined in . SIOCSIFADDR Sets the network interface address. data is a pointer to an ifreq structure, as defined in . Sets the interface address to the value passed in the argument. SIOCSIFALLRTB Sets the interface to use all-route broadcast, for token ring only. data is a pointer to an ifreq structure, as defined in . SIOCSIFBRD Sets the interface to use single route broadcast, for token ring only. data is a pointer to an ifreq structure, as defined in . SIOCSIFBRDADDR Sets the network interface broadcast address. data is a pointer to an ifreq structure, as defined in . Sets the interface broadcast address to the value passed in the argument. SIOCSIFDSTADDR Sets the network interface destination address. data is a pointer to an ifreq structure, as defined in . Sets the interface destination (point-to-point) address to the value passed in the argument. SIOCSIFEFLAGS Sets extended flags for the interface. data is a pointer to an ifreq structure, as defined in . The extended flags should be passed in the ifr_eflags field. SIOCSIFFDDI Sets the token-ring interface to use canonical format of ARP. data is a pointer to an ifreq structure, as defined in . SIOCSIFFLAGS Sets the network interface flags. data is a pointer to an ifreq structure, as defined in . Sets the interface flags to the values passed in the ifr_flags field. SIOCSIFMETRIC Sets the network interface routing metric. data is a pointer to an ifreq structure, as defined in . Sets the interface routing metric to the value passed in the ifr_metric field. SIOCSIFMTU Sets the interface MTU value. data is a pointer to an ifreq structure, as defined in . Sets the interface MTU to the value passed in the ifr_metric field. SIOCSIFNETMASK Sets the network interface network mask. data is a pointer to an ifreq structure, as defined in . Sets the interface network mask to the value passed in the argument. SIOCSIFNO802_3 Sets the interface to send packets with Ethernet header frame format. data is a pointer to an ifreq structure, as defined in . SIOCSIFNOFDDI Sets the token-ring interface to use noncanonical format for ARP. SIOCSIFNOREDIR Disable ICMP redirect function for an interface. data is a pointer to an ifreq structure, as defined in . SIOCIFRUNNINGBLK Blocks the calling thread until the interface is back in running state. data is a pointer to an ifreq structure, as defined in . This is typically useful when the network cable needs to be disconnected temporarily. For token ring only. SIOCSIFTRACE Creates an interface i/o tracing packet. data is a pointer to an ifreq structure, as defined in . The trace packet should be placed in the pkt_trace_hdr structure, as defined in , which should be pointed to by the ifr_data field. SIOCSIFYESREDIR Enables ICMP redirect function for an interface. data is a pointer to an ifreq structure, as defined in . SIOCSMSL Sets the TCP Maximum Segment Lifetime (MSL) value in seconds. SIOCSNBNAME (NetBIOS only) Gets the NetBIOS name. SIOCSRDBRD Enables loopback for broadcast packets. SIOCSSTAT Sets the serial link interface statistics. data is a pointer to an ifreq structure, as defined in . The statistics are returned in an ifstat structure pointed to by the ifr_data field. SIOCSSYN Sets the SYN attack prevention function flag on or off. data should point to an integer that contains zero for off and nonzero for on. The function is off by default. SIOFLUSHRT Flushes the entire routing table, including all routes to all interfaces. SIOFLUSHRTIFP Flushes all routes for the specified interface only. data is a pointer to an interface name, such as lan0. SIOSTATCNTAT Gets the count of ARP entries. SIOSTATCNTRT Gets the count of entries in the routing table. SIOSTATICMP Gets ICMP statistics. data is a pointer to an icmpstat structure, as defined in . SIOSTATICMPZ Clears ICMP statistics. data is a pointer to an icmpstat structure, as defined in . SIOSTATIGMP Gets IGMP statistics. data is a pointer to an igmpstat structure, as defined in . SIOSTATIGMPZ Clears IGMP statistics. data is a pointer to an igmpstat structure, as defined in . SIOSTATIP Gets IP statistics. data is a pointer to an ipstat structure, as defined in . SIOSTATIPZ Clears IP statistics. data is a pointer to an ipstat structure, as defined in . SIOSTATMBUF Gets memory usage status. data is a pointer to an mbstat structure, as defined in . SIOSTATTCP Gets TCP statistics. data is a pointer to a tcpstat structure, as defined in . SIOSTATTCPZ Clears TCP statistics. data is a pointer to a tcpstat structure, as defined in . SIOSTATUDP Gets UDP statistics. data is a pointer to a udpstat structure, as defined in . SIOSTATUDPZ Clears UDP statistics. data is a pointer to a udpstat structure, as defined in . NetBIOS : The following ioctl commands are supported for the NetBIOS domain: Option Description SIOCGNBNAME Issues ncb.find.name. SIOCGNCBFN Sets the NetBIOS hostname. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEINVAL The request is not valid or not supported. SOCEOPNOTSUPP The operation is not supported on the socket. SOCEFAULT Using data would result in an attempt to access memory outside the caller address space. Examples The following is an example of the ioctl() call. int s; int dontblock; int rc; int ioctl(int s, int cmd, caddr_t data); /* extracted from sys\socket.h */ ... /* Place the socket into nonblocking mode */ dontblock = 1; rc = ioctl(s, FIONBIO, (char *) &dontblock); ... Related Calls os2_ioctl() sock_errno() ═══ 12.9. listen() ═══ The listen() socket call completes the binding necessary for a socket to accept connections and creates a connection request queue for incoming requests. Syntax #include #include #include int listen(s, backlog) int s; int backlog; Parameters s Socket descriptor. backlog Controls the maximum queue length for pending connections. Description The listen() call performs two tasks: 1. Completes the binding necessary for a socket s, if bind() has not been called for s 2. Creates a connection request queue of length backlog, to queue incoming connection requests. When the queue is full, additional connection requests are ignored. The listen() call indicates a readiness to accept client connection requests. It transforms an active socket into a passive socket. After listen() is called, s can never be used as an active socket to initiate connection requests. listen() is called after allocating a socket with socket() and after binding a name to s with bind(). listen() must be called before calling accept(). listen() can only be called on connection-oriented sockets. If the backlog parameter is less than 0, then listen() interprets backlog as 0. If the backlog parameter is greater than SOMAXCONN, as defined in , then listen() interprets backlog as SOMAXCONN. Return Values The value 0 indicates success, the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEOPNOTSUPP The s parameter is not a socket descriptor that supports the listen() call. Related Calls accept() bind() connect() sock_errno() socket() ═══ 12.10. os2_ioctl() ═══ The os2_ioctl() socket call performs special operations on socket particularly related to returning status from kernel. Syntax #include #include #include #include #include #include int os2_ioctl(s, cmd, data, lendata) int s; int cmd; caddr_t data; int lendata; Parameters s Socket descriptor cmd Command to perform data Pointer to the data buffer associated with cmd where returned data is placed. lendata Length (in bytes) of the data to be returned in the buffer. Description The following os2_ioctl() commands are supported for the internet domain. The data parameter is a pointer to data associated with the particular command, and its format depends on the command that is requested. Option Description SIOSTATARP Gets the ARP table. data is a pointer to an oarptab structure as defined in . SIOSTATAT Gets all interface addresses. data is a pointer to the buffer for receiving returned data. At return, the first two bytes of the buffer contain the number of returned addresses, followed by the address information for each interface address. For each address, the buffer contains:  the IP address, of type unsigned long  an interface index, of type unsigned short  a netmask, of type unsigned long  the broadcast address, of type unsigned long SIOSTATIF Gets interface statistics. data is a pointer to an ifmib structure as defined in . SIOSTATIF42 Gets interface statistics for all interfaces (maximum of 42). data is a pointer to sequential instances of an ifmib structure as defined in . SIOSTATRT Gets routing entries from the routing table. data is a pointer to an rtentries structure as defined in . SIOSTATSO Gets sockets' statistics. data is a pointer to sequential instances of a sostats structure as defined in . Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEINVAL The request is not valid or not supported. SOCEOPNOTSUPP The operation is not supported on the socket. SOCEFAULT Using data and lendata would result in an attempt to access memory outside the caller address space. Examples The following is an example of the os2_ioctl() call. int s; char buf [1024]; int rc; int os2_ioctl(int s, int cmd, caddr_t data, int lendata); /* extracted from sys\socket.h */ ... rc = os2_ioctl(s, SIOSTATAT, (char *) buf, sizeof(buf)); ... Related Calls sock_errno() ioctl() ═══ 12.11. os2_select() ═══ The socket call gets read, write, and exception status on a group of sockets. In os2_select(), the socket numbers are specified as an array of integers, in which the read socket numbers are followed by write socket numbers, followed by the exception pending connection socket numbers. TCP/IP for OS/2 Warp monitors the activity on a socket by specifying the number of sockets to be checked for readability, readiness for writing, and exception pending conditions. Syntax #include #include int os2_select(s, noreads, nowrites, noexcepts, timeout) int *s; int noreads; int nowrites; int noexcepts; long timeout; Parameters s Pointer to an array of socket numbers where the read socket numbers are followed by the write socket numbers, and then followed by the exception socket numbers. noreads Number of sockets to be checked for readability. nowrites Number of sockets to be checked for readiness for writing. noexcepts Number of sockets to be checked for exceptional pending conditions. The only exceptional pending condition is out-of-band data in the receive buffer. timeout Maximum interval, in milliseconds, to wait for the selection to complete. Description This call monitors activity on a set of different sockets until a timeout expires, to see if any sockets are ready for reading or writing, or if any exceptional conditions are pending. If the timeout value is 0, select() does not wait before returning. If the timeout value is -1, select() does not timeout, but returns when a socket becomes ready. If the timeout value is a number of milliseconds, select() waits for the specified interval before returning. The select() call checks all indicated sockets at the same time and returns when any of them is ready. Reinitializing the socket array every time select() is called is required. Return Values The number of ready sockets is returned. The value -1 indicates an error. The value 0 indicates an expired time limit. If the return value is greater than 0, the socket numbers in s that were not ready are set to -1. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT The address is not valid. SOCEINVAL Invalid argument. SOCEINTR Interrupted system call. Examples The following is an example of the os2_select() call. #define MAX_TIMEOUT 1000 /* input_ready(insock)- Check to see if there is available input on * socket insock. * Returns 1 if input is available. * 0 if input is not available. * -1 on error. */ int input_ready(insock) int insock; /* input socket descriptor */ { int socks[1]; /* array of sockets */ long timeout = MAX_TIMEOUT; /* put socket to check in socks[] */ socks[0] = insock; /* check for READ availability on this socket */ return os2_select(socks, 1, 0, 0, timeout); } Related Calls accept() connect() recv() select() send() sock_errno() socket() ═══ 12.12. psock_errno() ═══ The psock_errno() socket call writes a short error message to the standard error device. Syntax #include void psock_errno(s) char *s; Parameters s Pointer to a buffer Description This call writes a short error message to the standard error display describing the last error encountered during a call to a socket library function. If s is not a NULL pointer and does not point to a null string, the string it points to is printed, followed by a colon, followed by a space, followed by the message. If s is a NULL pointer or points to a null string, only the message is printed. The error code is acquired by calling sock_errno(). The error code is set when errors occur. Subsequent socket calls do not clear the error code. Related Calls sock_errno() ═══ 12.13. readv() ═══ The readv() socket call receives data on a socket into a set of buffers. Syntax #include #include int readv(s, iov, iovcnt) int s; struct iovec *iov; int iovcnt; Parameters s Socket descriptor iov Pointer to an array of iovec structures iovcnt Number of iovec structures pointed to by the iov parameter. The maximum number of iovec structures is 16. Description This call reads data on a socket with descriptor s and stores it in a set of buffers. The data is scattered into the buffers specified by iov[0]...iov[iovcnt-1]. The iovec structure is defined in and contains the following fields: Field Description iov_base Points to the buffer iov_len Length of the buffer The readv() call applies only to connected sockets. For information on how to use readv() with datagram and raw sockets, see Datagram or Raw Sockets. TCP/IP alters iov_base and iov_len for each element in the input struct iovec array. iov_base will point to the next character of the processed (sent or received) data on the original buffer, and iov_len will become (input value - processed length). Thus if only partial data has been sent or received and the application expects more data to send or receive, it can pass the same iovec structure back in a subsequent call. This call returns up to the number of bytes in the buffers pointed to by the iov parameter. This number is the sum of all iov_len fields. If less than the number of bytes requested is available, the call returns the number currently available. If data is not available at the socket with descriptor s, the readv() call waits for data to arrive and blocks the caller, unless the socket is in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. The UDP sockets can send and receive datagrams as large as 32739 bytes (32 * 1024 -1 - IP header (20 bytes) - UDP header (8 bytes)). Return Values When successful, the number of bytes of data received into the buffer is returned. The value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using iov and iovcnt would result in an attempt to access memory outside the caller's address space. SOCEINTR Interrupted system call. SOCEINVAL iovcnt was not valid, or one of the fields in the iov array was not valid. SOCEWOULDBLOCK The s parameter is in nonblocking mode and no data is available to read, or the SO_RCVTIMEO option has been set for socket s and the timeout expired before any data arrived to read. Related Calls accept() connect() getsockopt() ioctl() recv() recvfrom() recvmsg() select() send() sendto() setsockopt() so_cancel() sock_errno() socket() writev() ═══ 12.14. recv() ═══ The socket call receives data on a connected socket. Syntax #include #include int recv(s, buf, len, flags) int s; char *buf; int len; int flags; Parameters s Socket descriptor buf Pointer to the buffer that receives the data len Length of the buffer in bytes pointed to by the buf parameter. flags Permits the call to exercise control over the reception of messages. Set this parameter by specifying one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTWAIT Do not wait for resources or data during this call. MSG_OOB Reads any out-of-band data on the socket. MSG_PEEK Peeks at the data present on the socket; the data is returned but not consumed, so that a subsequent receive operation sees the same data. MSG_WAITALL Wait for data to fill all buffers before returning. Description This call receives data on a socket with descriptor s and stores it in the buffer pointed to by buf. The recv() call applies only to connected sockets. For information on how to use recv() with datagram and raw sockets, see Datagram or Raw Sockets. The recv() call returns the length of the incoming data. If a datagram or sequenced packet is too long to fit in the buffer, the excess is discarded. No data is discarded for stream or sequenced packet sockets. If data is not available at the socket with descriptor s, the recv() call waits for data to arrive and blocks the caller, unless the socket is in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. Use the select() call to determine when more data arrives. Return Values When successful, the number of bytes of data received into the buffer is returned. The value 0 indicates that the connection is closed. The value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the buf and len parameters would result in an attempt to access memory outside the caller's address space. SOCEINTR Interrupted system call. SOCEINVAL Invalid argument. SOCEWOULDBLOCK The s parameter is in nonblocking mode and no data is available to receive, or the SO_RCVTIMEO option has been set for socket s and the timeout expired before any data arrived to receive. Related Calls connect() getsockopt() ioctl() readv() recvfrom() recvmsg() select() send() sendmsg() sendto() setsockopt() shutdown() sock_errno() socket() writev() ═══ 12.15. recvfrom() ═══ The socket call receives data on a socket. Syntax #include #include int recvfrom(s, buf, len, flags, name, namelen) int s; char *buf; int len; int flags; struct sockaddr *name; int *namelen; Parameters s Socket descriptor buf Pointer to the buffer that receives the data len Length of the buffer in bytes pointed to by the buf parameter flags Permits the call to exercise control over the reception of messages. Set this parameter by specifying one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTWAIT Do not wait for resources or data during this call. MSG_OOB Reads any out-of-band data on the socket. MSG_PEEK Peeks at the data present on the socket; the data is returned but not consumed, so that a subsequent receive operation sees the same data. MSG_WAITALL Wait for data to fill all buffers before returning. name Pointer to a sockaddr structure (buffer) that data is received from. If name is a nonzero value, the source address is returned. namelen Pointer to the size in bytes of the buffer pointed to by name Description The recvfrom() call receives data on a socket with descriptor s and stores it in a buffer. The recvfrom() call applies to any socket type, whether connected or not. If name is nonzero, the address of the data sender is returned. The namelen parameter is first initialized to the size of the buffer associated with name; on return, it is modified to indicate the actual number of bytes stored there. The recvfrom() call returns the length of the incoming message or data. If a datagram or sequenced packet is too long to fit in the supplied buffer, the excess is discarded. No data is discarded for stream or sequenced packet sockets. If data is not available at the socket with descriptor s, the recvfrom() call waits for data to arrive and blocks the caller, unless the socket is in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. Return Values When successful, the number of bytes of data received into the buffer is returned. The value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the buf and len parameters would result in an attempt to access memory outside the caller's address space. SOCEWOULDBLOCK The s parameter is in nonblocking mode and no data is available to receive, or the SO_RCVTIMEO option has been set for socket s and the timeout expired before any data arrived to receive. SOCEINVAL Invalid argument. Related Calls ioctl() readv() recv() recvmsg() select() send() sendmsg() sendto() setsockopt() shutdown() sock_errno() socket() writev() ═══ 12.16. recvmsg() ═══ The socket call receives data and control information on a specified socket. Syntax #include #include int recvmsg(s, msg, flags) int s; struct msghdr *msg; int flags; Parameters s Socket descriptor. msg Pointer to a message header that receives the message. flags Permits the call to exercise control over the reception of messages. Set this parameter by specifying one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTWAIT Do not wait for resources or data during this call. MSG_OOB Reads any out-of-band data on the socket. MSG_PEEK Peeks at the data present on the socket; the data is returned but not consumed, so that a subsequent receive operation will see the same data. MSG_WAITALL Wait for data to fill all buffers before returning. Description This call receives a message on a socket with descriptor s. Networking services supports the following msghdr structure. Note: The fields msg_control and msg_controllen are ignored for the NetBIOS and Local IPC domains. struct msghdr { caddr_t msg_name; /* optional pointer to destination address buffer */ int msg_namelen; /* size of address buffer */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* how many elements in msg_iov */ caddr_t msg_control; /* ancillary data */ u_int msg_controllen; /* ancillary data length */ int msg_flags; /* flags on receive message */ }; msg_iov is a scatter/gather array of iovec structures. The iovec structure is defined in and contains the following fields: Field Description iov_base Pointer to the buffer iov_len Length of the buffer TCP/IP alters iov_base and iov_len for each element in the input struct iovec array. iov_base will point to the next character of the processed (sent or received) data on the original buffer, and iov_len will become (input value - processed length). Thus if only partial data has been sent or received and the application expects more data to send or receive, it can pass the same iovec structure back in a subsequent call. The recvmsg() call applies to connection-oriented or connectionless sockets. This call returns the length of the data received. If a datagram or sequenced packet is too long to fit in the supplied buffer, the excess is discarded. No data is discarded for stream sockets. If data is not available at the socket with descriptor s, the recvmsg() call waits for a message to arrive and blocks the caller, unless the socket is in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. Return Values When successful, the number of bytes of data received into the buffer is returned. The value 0 indicates the connection is closed; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using msg would result in an attempt to access memory outside the caller's address space. SOCEINTR Interrupted system call. SOCENOTCONN The socket is not connected. SOCEWOULDBLOCK The s parameter is in nonblocking mode, and no data is available to receive. Examples The following is an example of using recvmsg() call to receive token ring routing information in the msg_control buffers: Example of recvmsg() Call char buf[50], control_buf[100]; main(int argc, char *argv[]) { struct sockaddr_in server; int optlen, smsg, byterecv,rv,i, ip_recvtrri; struct msghdr msg; struct cmsghdr *cmsg; struct iovec iov; struct timeval tv; if ((smsg = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) psock_errno("Socket()"); server.sin_len = sizeof(struct sockaddr); server.sin_family = AF_INET; server.sin_port = htons(atoi(argv[1])); /* port number */ server.sin_addr.s_addr = INADDR_ANY; if (bind(smsg, (struct sockaddr *)&server , sizeof(server)) < 0) psock_errno("bind()"); iov.iov_base = buf; iov.iov_len = sizeof(buf)-1; msg.msg_name = NULL; msg.msg_namelen = sizeof(struct sockaddr); msg.msg_iov = &iov msg.msg_iovlen = 1; msg.msg_control = control_buf; msg.msg_controllen = sizeof(struct cmsghdr)+4+18;/*4 byte ipaddr + 18 TRRI*/ ip_recvtrri = 1; if (setsockopt(smsg,IPPROTO_IP,IP_RECVTRRI,(char *)&ip_recvtrri , sizeof(ip_recvtrri)) < 0) psock_errno("setsockopt() IP_RECVTRRI"); /* Set another IP socket options for timeout so we do not block waiting */ tv.tv_sec = 10; /* Wait for max 10 sec on recvmsg */ tv.tv_usec = 0; rv = setsockopt(smsg, SOL_SOCKET, SO_RCVTIMEO, (char *) &tv, sizeof(struct timeval)); if (rv < 0) psock_errno("Set SO_RCVTIMEO"); if((byterecv=recvmsg(smsg, &msg, 0))<0) psock_errno("recvmsg()"); else { cmsg = (struct cmsghdr *) msg.msg_control; printf(" IP_RECV TR RI (data in network byte order): "); for (i=sizeof(struct cmsghdr); i < cmsg->cmsg_len;i++) printf(" %x",msg.msg_control[i]); } soclose(smsg); } Related Calls connect() getsockopt() ioctl() os2_ioctl() recv() recvfrom() select() send() sendmsg() sendto() shutdown() sock_errno() socket() ═══ 12.17. removesocketfromlist() ═══ The removesocketfromlist() call removes a socket from the list of owned sockets for the calling process. Syntax #include #include int removesockettolist(s) int s; Parameters s Socket descriptor Description When a process ends, the sockets library automatically cleans up sockets by registering an exit list handler. This exit routine closes all open sockets that are maintained in a process's socket list. When a process is initiated the list is empty, and whenever a socket() or soclose() call is made the list is updated. The removesocketfromlist() call provides a mechanism to transfer socket ownership to another process: it removes the socket indicated by the s parameter from the calling process's socket ownership list. Return Values The value 1 indicates success; the value 0 indicates that the socket could not be found in the list. Related Calls addsockettolist() ═══ 12.18. select() ═══ The socket call gets read, write, and exception status on a group of sockets. The BSD version monitors the activity on sockets by specifying an array (fd_set) of socket numbers for which the caller wants to read the data, write the data, and check exception pending conditions. The BSD version provides FD_SET, FD_CLR, FD_ISSET, and FD_ZERO macros to add or delete socket numbers from the array. Syntax #include #include #include int select(nfds, readfds, writefds, exceptfds, timeout) int nfds; fd_set *readfds; fd_set *writefds; fd_set *exceptfds; struct timeval *timeout; Parameters nfds This parameter is unused; it is maintained for compatibility with BSD. readfds Pointer to a list of descriptors to be checked for reading. writefds Pointer to a list of descriptors to be checked for writing. exceptfds Pointer to a list of descriptors to be checked for exceptional pending conditions. For networking services sockets, the only exceptional pending condition is out-of-band data in the receive buffer. timeout Pointer to the time to wait for the select() call to complete. Description This call monitors activity on a set of different sockets until a timeout expires, to see if any sockets are ready for reading or writing, or if any exceptional conditions are pending. Reinitializing readfds, writefds, and exceptfds every time select() is called is required. If timeout is a NULL pointer, the call blocks indefinitely until one of the requested conditions is satisfied. If timeout is non-NULL, it specifies the maximum time to wait for the call to complete. To poll a set of sockets, the timeout pointer should point to a zeroed timeval structure. The timeval structure is defined in the header file and contains the following fields: Field Description tv_sec Number of seconds tv_usec Number of microseconds An fd_set is made up of an array of integers. Macros are provided to manipulate the array. Macro Description FD_SET(socket, array_address) Adds the socket to the list pointed to by array_address. FD_CLR(socket, array_address) Removes the socket from the list. FD_ISSET(socket, array_address) Returns true if the descriptor is part of the array; otherwise, it returns false. FD_ZERO(socket, array_address) Clears the entire array for all socket descriptors. Note: For macros FD_SET, FD_CLR, FD_ISSET, and FD_ZERO, define the parameters socket and array_address in the following manner: int socket; struct fd_set *array_address; Setting any of the descriptor pointers to zero indicates that no checks are to be made for the conditions. For example, setting exceptfds to be a NULL pointer causes the select call to check for only read and write conditions. Return Values The total number of ready sockets (in all arrays) is returned. The value -1 indicates an error. The value 0 indicates an expired time limit. If the return value is greater than 0, the socket descriptors in each array that are not ready are removed from the array. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT The address is not valid. SOCEINVAL Invalid argument. Examples Following is an example of the select() call. ... fd_set readsocks; fd_set writesocks; fd_set exceptsocks; struct timeval timeout; int number_found; ... /* add socket to read/write/except arrays. To add descriptor s use * FD_SET (s, &readsocks); * */ ... number_found = select(0,&readsocks, &writesocks, &exceptsocks, &timeout); Related Calls accept() connect() os2_select() recv() send() sock_errno() socket() ═══ 12.19. send() ═══ The socket call sends data on a connected socket. Syntax #include #include int send(s, msg, len, flags) int s; char *msg; int len; int flags; Parameters s Socket descriptor msg Pointer to a buffer containing the message to transmit len Length of the message pointed to by the msg parameter. flags Allows the sender to control the transmission of the message. Set this parameter by specifying one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTROUTE The SO_DONTROUTE socket option is turned on for the duration of the operation. This is usually used only by diagnostic or routing programs. MSG_DONTWAIT Do not wait for resources during this call. MSG_EOF Indicates that the sending of data on the connection is complete. This flag is effective on T/TCP connections only. MSG_OOB Sends out-of-band data on sockets that support SOCK_STREAM communication. Description This call sends data on the socket with descriptor s. The send() call applies to connected sockets. For information on how to use send() with datagram and raw sockets, see Datagram or Raw Sockets. The sendto() and sendmsg() calls can be used with unconnected or connected sockets. To broadcast on a socket, first issue a setsockopt() call using the SO_BROADCAST option to gain broadcast permission. Specify the length of the message with the len parameter. If the message is too long to pass through the underlying protocol, the system returns an error and does not transmit the message. No indication of failure to deliver is implied in a send() call. A return value of -1 indicates some locally detected errors. If buffer space is not available at the socket to hold the message to be sent, the send() call normally blocks, unless the socket is placed in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. Use the select() call to determine when it is possible to send more data. Return Values When successful, the number of bytes of the socket with descriptor s that is added to the send buffer is returned. This may be less than the number of bytes specified in the length parameter. Successful completion does not imply that the data has already been delivered to the receiver. The return value -1 indicates an error was detected on the sending side of the connection. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the msg and len parameters would result in an attempt to access memory outside the caller's address space. SOCEINTR Interrupted system call. SOCEINVAL Invalid argument. SOCENOBUFS No buffer space is available to send the message. SOCEWOULDBLOCK The s parameter is in nonblocking mode and the data cannot be sent without blocking, or the SO_SNDTIMEO option has been set for socket s and the timeout expired before any data was sent. Related Calls connect() getsockopt() ioctl() readv() recv() recvfrom() recvmsg() select() sendmsg() sendto() setsockopt() shutdown() sock_errno() socket() writev() ═══ 12.20. sendmsg() ═══ The socket call sends data and control information on a specified socket. Syntax #include #include int sendmsg(s, msg, flags) int s; struct msghdr *msg; int flags; Parameters s Socket descriptor msg Pointer to a message header containing a message to be sent flags Allows the sender to control the message transmission. Set this parameter by specifying one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTROUTE The SO_DONTROUTE socket option is turned on for the duration of the operation. This is usually used only by diagnostic or routing programs. MSG_DONTWAIT Do not wait for resources during this call. MSG_EOF Indicates that the sending of data on the connection is complete. This flag is effective on T/TCP connections only. MSG_OOB Sends out-of-band data on the socket. Description This call sends a msghdr structure on a socket with descriptor s. Networking services supports the following msghdr structure. Note: The fields msg_control and msg_controllen are ignored for the NetBIOS and Local IPC domains. struct msghdr { caddr_t msg_name; /* optional pointer to destination address buffer */ int msg_namelen; /* size of address buffer */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* how many elements in msg_iov */ caddr_t msg_control; /* ancillary data */ u_int msg_controllen; /* ancillary data length */ int msg_flags; /* flags on received message */ }; To broadcast on a socket, the application program must first issue a setsockopt() call using the SO_BROADCAST option, to gain broadcast permission. The sendmsg() call applies to connection-oriented and connectionless sockets. msg_iov is a scatter/gather array of iovec structures. The iovec structure is defined in and contains the following fields: Field Description iov_base Pointer to the buffer iov_len Length of the buffer TCP/IP alters iov_base and iov_len for each element in the input struct iovec array. iov_base will point to the next character of the processed (sent or received) data on the original buffer, and iov_len will become (input value - processed length). Thus if only partial data has been sent or received and the application expects more data to send or receive, it can pass the same iovec structure back in a subsequent call. This call returns the length of the data sent. If the socket with descriptor s is not ready for sending data, the sendmsg() call waits unless the socket is in nonblocking mode. See ioctl() for a description of how to set nonblocking mode. Return Values When successful, the number of bytes of data sent is returned. Successful completion does not guarantee delivery of the data to the receiver. The return value -1 indicates an error was detected on the sending side of the connection. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCEDESTADDRREQ The msghdr msg_name parameter is set to NULL and a destination address is required. SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using msg would result in an attempt to access memory outside the caller's address space. SOCEINTR Interrupted system call. SOCEINVAL msg_namelen is not the size of a valid address for the specified address family. SOCEMSGSIZE The message was too big to be sent as a single datagram. SOCENOBUFS No buffer space is available to send the message. SOCENOTCONN The socket is not connected. SOCEWOULDBLOCK The s parameter is in nonblocking mode and the data cannot be sent without blocking. Related Calls getsockopt() ioctl() readv() recv() recvfrom() recvmsg() select() send() sendto() setsockopt() shutdown() sock_errno() socket() writev() ═══ 12.21. sendto() ═══ The socket call sends data on a socket. Syntax #include #include int sendto(s, msg, len, flags, to, tolen) int s; char *msg; int len; int flags; struct sockaddr *to; int tolen; Parameters s Socket descriptor msg Pointer to the buffer containing the message to transmit len Length of the message in the buffer pointed to by the msg parameter flags Allows the sender to control the message transmission. Set this parameter to 0, or to one or more of the following flags. If you specify more than one flag, use the logical OR operator (|) to separate them. Setting this parameter is supported only for sockets in the internet domain. MSG_DONTROUTE The SO_DONTROUTE socket option is turned on for the duration of the operation. This is usually used only by diagnostic or routing programs. MSG_DONTWAIT Do not wait for resources during this call. MSG_EOF Indicates that the sending of data on the connection is complete. This flag is effective on T/TCP connections only. MSG_OOB Sends out-of-band data on the socket. to Pointer to a sockaddr structure (buffer) containing the destination address tolen Size in bytes of the buffer pointed to by the to parameter Description This call sends data on the socket with descriptor s. The sendto() call applies to connected or unconnected sockets. For unconnected datagram and raw sockets, the sendto() call sends data to the specified destination address. For stream and sequenced packet sockets the destination address is ignored. To broadcast on a socket, first issue a setsockopt() call using the SO_BROADCAST option to gain broadcast permissions. Provide the address of the target using the to parameter. Specify the length of the message with the tolen parameter. If the message is too long to pass through the underlying protocol, the error SOCEMSGSIZE is returned and the message is not transmitted. If the sending socket has no space to hold the message to be transmitted, the sendto() call blocks the message, unless the socket is in a nonblocking I/O mode. Use the select() call to determine when it is possible to send more data. Datagram sockets are connected by calling connect(). This identifies the peer to send/receive the datagram. Once a datagram socket is connected to a peer, you may still use the sendto() call but a destination address cannot be included. To change the peer address when using connected datagram sockets, issue a connect() call with a null address. Specifying a null address on a connected datagram socket removes the peer address specification. You can then either issue a sendto() call specifying a different destination address or issue a connect() call to connect to a different peer. For more information on connecting datagram sockets and specifying null addresses, see Datagram or Raw Sockets. If the to parameter is specified and this sendto() call was preceded by a connect() call, the dst parameter must be NULL. If not NULL, the error SOCEISCONN is returned and the message is not sent. If the to parameter is specified and this sendto() call was not preceded by a connect() call, this sendto() call results in socket s being connected to dst, the message being sent, and socket s being disconnected from dst. Return Values When successful, the number of bytes of data sent is returned. Successful completion does not guarantee delivery of the data to the receiver. The return value -1 indicates an error was detected on the sending side. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using the msg and len parameters would result in an attempt to access memory outside the caller's address space. SOCEINVAL The tolen parameter is not the size of a valid address for the specified address family. SOCEISCONN This call was preceded by a connect() call, the to parameter of this call is specified, but the dst parameter is not NULL. SOCEMSGSIZE The message was too big to be sent as a single datagram. SOCENOBUFS No buffer space is available to send the message. SOCEWOULDBLOCK The s parameter is in nonblocking mode and the data cannot be sent without blocking, or the SO_SNDTIMEO option has been set for socket s and the timeout expired before any data was sent. SOCENOTCONN The socket is not connected. SOCEDESTADDRREQ Destination address required. Related Calls getsockopt() readv() recv() recvfrom() recvmsg() select() send() sendmsg() setsockopt() shutdown() sock_errno() socket() writev() ═══ 12.22. setsockopt() ═══ The socket call sets options associated with a socket. Syntax #include #include int setsockopt(s, level, optname, optval, optlen) int s; int level; int optname; char *optval; int optlen; Parameters s Socket descriptor level Specifies which option level is being set optname Name of a specified socket option optval Pointer to the option data optlen Length of the option data Description This call provides an application program with the means to control a socket communication. The setsockopt() call can be used to set options associated with a socket such as enabling debugging at the socket or protocol level, controlling timeouts, or permitting socket data broadcasts. Options can exist at the socket or the protocol level; options are always present at the highest socket level. When setting socket options, the level of the option and the name of the option must be specified. The following table lists the supported levels: Supported Levels ┌─────────────────────────────────────────────────────────────────┐ │Supported Level #define in │ ├─────────────────────────────────────────────────────────────────┤ │SOL_SOCKET │ ├─────────────────────────────────────────────────────────────────┤ │IPPROTO_IP │ ├─────────────────────────────────────────────────────────────────┤ │IPPROTO_TCP │ ├─────────────────────────────────────────────────────────────────┤ │NBPROTO_NB │ └─────────────────────────────────────────────────────────────────┘ The optval and optlen parameters are used to pass data used by the particular set command. The optval parameter points to a buffer containing the data needed by the set command. The optval parameter is optional and if data is not needed by the command, can be set to the NULL pointer. The optlen parameter must be set to the size of the data or data type pointed to by optval. For socket options that are toggles, the option is enabled if optval is nonzero and disabled if optval is 0. The following tables list the supported options for setsockopt() at each level (SOL_SOCKET, IPPROTO_IP, IPPROTO_TCP). Detailed descriptions of the options follow each table. Supported setsockopt() Socket Options for SOL_SOCKET ┌─────────────────────────────────────────────────────────────────────┐ │Option Name Description Domains(*) Data Boolean │ │ Type or Value│ ├─────────────────────────────────────────────────────────────────────┤ │SO_BROADCAST allow sending of I, N int boolean │ │ broadcast messages │ ├─────────────────────────────────────────────────────────────────────┤ │SO_DEBUG turn on recording of I, L int boolean │ │ debugging information │ ├─────────────────────────────────────────────────────────────────────┤ │SO_DONTROUTE bypass routing tables I int boolean │ ├─────────────────────────────────────────────────────────────────────┤ │SO_KEEPALIVE keep connections alive I int boolean │ ├─────────────────────────────────────────────────────────────────────┤ │SO_LINGER linger on close if data I struct value │ │ present linger │ ├─────────────────────────────────────────────────────────────────────┤ │SO_L_BROADCAST limited broadcast sent I int boolean │ │ on all interfaces │ ├─────────────────────────────────────────────────────────────────────┤ │SO_OOBINLINE leave received OOB data I int boolean │ │ in-line │ ├─────────────────────────────────────────────────────────────────────┤ │SO_RCVBUF receive buffer size I, L, N int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_RCVLOWAT receive low water mark I, L int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_RCVTIMEO receive timeout I, L int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_REUSEADDR allow local address I, N int boolean │ │ reuse │ ├─────────────────────────────────────────────────────────────────────┤ │SO_REUSEPORT allow local address and I int boolean │ │ port reuse │ ├─────────────────────────────────────────────────────────────────────┤ │SO_SNDBUF send buffer size I, L, N int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_SNDLOWAT send low water mark I, L int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_SNDTIMEO send timeout I, L int value │ ├─────────────────────────────────────────────────────────────────────┤ │SO_USELOOPBACK bypass hardware when I int value │ │ possible │ └─────────────────────────────────────────────────────────────────────┘ Table Note (*) This column specifies the communication domains to which this option applies: I for internet, L for Local IPC, and N for NetBIOS. The following options are recognized for SOL_SOCKET: Option Description SO_BROADCAST (datagram sockets only) Sets the ability to broadcast messages. When this option is enabled, the application can send broadcast messages over s, if the interface specified in the destination supports broadcasting of packets. SO_DEBUG Sets the ability to record debug information for a socket. This options is a prerequisite for tracing TCP debug information through the inetdbg utility. For more information enter inetcfg -?. SO_DONTROUTE Sets the ability for the socket to bypass the routing of outgoing messages. When this option is enabled, it causes outgoing messages to bypass the standard routing algorithm and be directed to the appropriate network interface according to the network portion of the destination address. When enabled, packets can be sent only to directly connected networks (networks for which this host has an interface). SO_KEEPALIVE (stream sockets only) Sets the ability of the socket to send keepalive packets that will keep the connection alive. TCP uses a timer called the keepalive timer. This timer is used to monitor idle connections that might have been disconnected because of a peer crash or timeout. When this option is enabled, a keepalive packet is periodically sent to the peer. This is mainly used to allow servers to close connections that are no longer active as a result of clients going away without properly closing connections. SO_LINGER (stream sockets only) Sets the ability of the socket to linger on close if data is present. When this option is enabled and there is unsent data present when soclose() is called, the calling application is blocked during the soclose() call until the data is transmitted or the connection has timed out. When this option is disabled, the soclose() call returns without blocking the caller, and TCP waits to try to send the data. Although the data transfer is usually successful, it cannot be guaranteed, because TCP waits only a finite amount of time to send the data. SO_L_BROADCAST Sets limited broadcast sent on all interfaces (dhcp client). SO_OOBINLINE (stream sockets only) Sets the ability of the socket to receive out-of-band data. Out-of-band data is a logically separate data path using the same connection as the normal data path. When this option is enabled, it causes out-of-band data to be placed in the normal data input queue as it is received, making it available to recv(), and recvfrom(), without having to specify the MSG_OOB flag in those calls. When this option is disabled, it causes out-of-band data to be placed in the priority data input queue as it is received, making it available to recv(), and recvfrom(), only by specifying the MSG_OOB flag in those calls. SO_RCVBUF Sets buffer size for input. This option sets the size of the receive buffer to the value contained in the buffer pointed to by optval. This allows the buffer size to be tailored for specific application needs, such as increasing the buffer size for high-volume connections. Use inetcfg -g tcprwinsize to see the default and maximum receive socket buffer sizes for stream (TCP) sockets or raw sockets. Use inetcfg -g udprwinsize to see the default and maximum receive socket buffer sizes for UDP sockets. SO_RCVLOWAT Sets the receive low water mark. SO_RCVTIMEO Sets the receive timeout. SO_REUSEADDR (stream and datagram sockets only) Sets the ability of a socket to reuse a local address. When this option is enabled, local addresses that are already in use can be bound. This alters the normal algorithm used in the bind() call. The system checks at connect time to be sure that no local address and port have the same foreign address and port. The error SOCEADDRINUSE is returned if the association already exists. Multicast applications must set this socket option if they want to join the same Class D IP address and port for sending and receiving multicast packets. SO_REUSEPORT Specifies that the rules used in validating addresses supplied by a bind subroutine should allow reuse of a local port/address combination. Each binding of the port/address combination must specify the SO_REUSEPORT socket option SO_SNDBUF Sets the send buffer size. This option sets the size of the send buffer to the value contained in the buffer pointed to by optval. This allows the send buffer size to be tailored for specific application needs, such as increasing the buffer size for high-volume connections. Use inetcfg -g tcpswinsize to see the default and maximum send socket buffer sizes for stream (TCP) sockets or raw sockets. Use inetcfg -g udpswinsize to see the default and maximum send socket buffer sizes for UDP sockets. SO_SNDLOWAT Sets the send low water mark. SO_SNDTIMEO Sets the send timeout. SO_USELOOPBACK Bypasses hardware when possible. struct linger: For the SO_LINGER option, optval points to a linger structure. This structure is defined in and contains the following fields: Field Description l_onoff Option on/off l_linger Linger time The l_onoff field is set to zero if the SO_LINGER option is being disabled. A nonzero value enables the option. The l_linger field specifies the amount of time in seconds to linger on close. A value of zero will cause soclose() to wait until the disconnect completes. Supported setsockopt() Socket Options for IPPROTO_IP ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value│ ├───────────────────────────────────────────────────────────────────┤ │IP_ADD_MEMBERSHIP join a multicast group struct value │ │ ip_mreq │ ├───────────────────────────────────────────────────────────────────┤ │IP_DROP_MEMBERSHIP leave a multicast group struct value │ │ ip_mreq │ ├───────────────────────────────────────────────────────────────────┤ │IP_HDRINCL header is included with int boolean │ │ data │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_IF default interface for struct value │ │ outgoing multicasts in_addr │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_LOOP loopback of outgoing uchar boolean │ │ multicast │ ├───────────────────────────────────────────────────────────────────┤ │IP_MULTICAST_TTL default TTL for outgoing uchar value │ │ multicast │ ├───────────────────────────────────────────────────────────────────┤ │IP_OPTIONS IP options buf value │ ├───────────────────────────────────────────────────────────────────┤ │IP_RECVDSTADDR queueing IP destination int boolean │ │ address │ ├───────────────────────────────────────────────────────────────────┤ │IP_RCVTRRI queueing token ring int boolean │ │ routing information │ ├───────────────────────────────────────────────────────────────────┤ │IP_RETOPTS IP options to be buf value │ │ included in outgoing │ │ datagrams │ ├───────────────────────────────────────────────────────────────────┤ │IP_TOS IP type of service for int value │ │ outgoing datagrams │ ├───────────────────────────────────────────────────────────────────┤ │IP_TTL IP time to live for int value │ │ outgoing datagrams │ └───────────────────────────────────────────────────────────────────┘ The following options are recognized for IPPROTO_IP: Option Description IP_ADD_MEMBERSHIP Used to join a multicast group. There can be 20 groups per socket, and the maximum number of groups for the entire OS/2 TCP/IP system is 320. A multicast packet is delivered to a socket if it has joined the same group on the same interface on which the packet arrived. More than one socket can bind() on a multicast (Class D IP) address and a common port, such as when two clients want to receive the same multicast packet. These sockets must set the SO_REUSEADDR socket option. IP_DROP_MEMBERSHIP Used to leave a multicast group. IP_HDRINCL (raw sockets only) When set, the IP header is included with the data received on the socket. IP_MULTICAST_IF Sets the default interface for outgoing multicasts. IP_MULTICAST_LOOP This option is used for sending multicast packets. It enables or disables loopback of outgoing multicast packets and is enabled by default. If loopback is disabled, outgoing multicast packets will not loopback in this system; this means that other applications running in this system will not receive outgoing multicast packets even if they have joined the same multicast group. IP_MULTICAST_TTL Sets the default TTL for outgoing multicast packets. IP_OPTIONS Sets IP options. Same as IP_RETOPTS. See Example of IP_RETOPTS Socket Call for how to use IP_RETOPS. IP_RECVDSTADDR (UDP only) Sets the queueing IP destination address. See Example of recvmsg() Call for the way to get this information through recvmsg() call. IP_RCVTRRI (UDP only) Sets queueing token ring routing information. See Example of recvmsg() Call for the way to get this information through recvmsg() call. IP_RETOPTS Sets the IP options to be included in outgoing datagrams. See Example of IP_RETOPTS Socket Call for how to use IP_RETOPS. IP_TOS Sets the IP type of service for outgoing datagrams. IP_TTL Sets the IP time to live value for outgoing datagrams. Supported setsockopt() Socket Options for IPPROTO_TCP ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_CC connection count flag int boolean │ ├───────────────────────────────────────────────────────────────────┤ │TCP_MAXSEG maximum segment size int value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_MSL TCP MSL value int value │ ├───────────────────────────────────────────────────────────────────┤ │TCP_NODELAY don't delay send to int boolean │ │ coalesce packets │ ├───────────────────────────────────────────────────────────────────┤ │TCP_TIMESTMP TCP timestamp flag int boolean │ ├───────────────────────────────────────────────────────────────────┤ │TCP_WINSCALE window scale flag int boolean │ └───────────────────────────────────────────────────────────────────┘ The following options are recognized for IPPROTO_TCP: Option Description TCP_CC (TTCP only) Sets the connection count function status flag (RFC 1644). TCP_MAXSEG Sets the maximum segment size. TCP_MSL Sets the TCP Maximum Segment Lifetime (MSL) value. TCP_NODELAY (stream sockets only) Setting on disables the buffering algorithm so that the client's TCP sends small packets as soon as possible. This often has no performance effects on LANs, but can degrade performance on Wide Area Networks (WAN). TCP_TIMESTMP (TTCP only) Sets the timestamp function status flag (RFC 1323). TCP_WINSCALE (TTCP only) Sets the window scale function status flag (RFC 1323). Supported setsockopt() Socket Options for NBPROTO_NB ┌───────────────────────────────────────────────────────────────────┐ │Option Name Description Data Type Boolean │ │ or Value │ ├───────────────────────────────────────────────────────────────────┤ │NB_DGRAM_TYPE type of datagrams to int value │ │ receive │ └───────────────────────────────────────────────────────────────────┘ The following option is recognized for NBPROTO_NB: Option Description NB_DGRAM_TYPE (datagram sockets only) Sets type of datagrams to be received on the socket. The possible values are: NB_DGRAM The socket is to receive normal (unicast) datagrams only. NB_BROADCAST The socket is to receive broadcast datagrams only. NB_DGRAM_ANY The socket can receive both normal or broadcast datagrams. This option can be changed at any time. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCEADDRINUSE The address is already in use. SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEFAULT Using optval and optlen parameters would result in an attempt to access memory outside the caller's address space. SOCENOPROTOOPT The optname parameter is unrecognized. SOCEINVAL Invalid argument. SOCENOBUFS No buffer space is available. Examples The following are examples of the setsockopt() call. See getsockopt() for examples of how the options are queried. int rc; int s; int optval; struct linger lstruct; /* extracted from sys/socket.h */ int setsockopt(int s, int level, int optname, char *optval, int optlen); ... /* I want out of band data in the normal input queue */ optval = 1; rc = setsockopt(s, SOL_SOCKET, SO_OOBINLINE, (char *) &optval, sizeof(int)); ... /* I want to linger on close */ lstruct.l_onoff = 1; lstruct.l_linger = 100; rc = setsockopt(s, SOL_SOCKET, SO_LINGER, (char *) &lstruct, sizeof(lstruct)); Related Calls bind() endprotoent() getprotobyname() getprotobynumber() getprotoent() getsockopt() ioctl() setprotoent() sock_errno() socket() ═══ 12.23. shutdown() ═══ The socket call shuts down all or part of a full-duplex connection. Syntax #include int shutdown(s, howto) int s; int howto; Parameters s Socket descriptor howto Condition of the shutdown Description This call shuts down all or part of a full-duplex connection. Since data flows in one direction are independent of data flows in the other direction, the shutdown call allows you to independently stop data flow in either direction or all data flows with one API call. For example, you may want to stop the sender(s) from sending data to you, but you still want to send data. Using the shutdown() call is optional. The howto parameter sets the condition for shutting down the connection to socket s. It can be set to one of the following:  0 - no more data can be received on socket s.  1 - no more output to be allowed on the socket s.  2 - no more data can be sent or received on socket s. Note: In the NetBIOS domain, the shutdown() call has no effect. When called, shutdown() will return a successful return code, but no shutdown occurs. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEINVAL The howto parameter was not set to one of the valid values. Related Calls accept() connect() getsockopt() readv() recv() recvfrom() recvmsg() select() send() sendto() setsockopt() sock_errno() soclose() socket() writev() ═══ 12.24. so_cancel() ═══ The socket call cancels a pending blocking sockets API call on a socket. Syntax #include #include int so_cancel (s) int s; Parameters s Socket descriptor Description The so_cancel() call is used in multithreaded applications where one thread needs to 'wake up' another thread which is blocked in a sockets API call. The thread that has been 'awakened' will return a value of -1 from the sockets API call, and the error will be set to SOCEINTR. If multiple threads are blocked on the same socket and so_cancel() is issued for that socket, only one of the threads will be 'awakened.' When a socket is in blocking mode, if no threads are blocking on the socket when so_cancel() is issued, the next sockets API call to be issued on that socket will return SOCEINTR. When a socket is in nonblocking mode and no threads are blocking on the socket when so_cancel() is issued, the next call to select() that includes the socket will return SOCEINTR. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. ═══ 12.25. sock_errno() ═══ The socket call returns error code set by a socket call. Syntax #include int sock_errno() Description The sock_errno() call returns the last error code set by a socket call in the current thread. Subsequent socket API calls do not reset this error code. Related Calls ioctl() os2_ioctl() psock_errno() ═══ 12.26. socket() ═══ The socket call creates an endpoint for communication and returns a socket descriptor representing the endpoint. Syntax #include #include int socket(domain, type, protocol) int domain; int type; int protocol; Parameters domain Communication domain requested type Type of socket created protocol Protocol requested Description This call creates an endpoint for communication and returns a socket descriptor representing the endpoint. Each socket type provides a different communication service. Sockets are deallocated with the soclose() call. The domain parameter specifies a communications domain where communication is to take place. This parameter specifies the protocol family which is used. Protocol Family Description PF_OS2 or PF_UNIX Use addresses in the Local IPC format which take the form of OS/2 Warp file and path names. PF_INET Use addresses in the internet address format. PF_NETBIOS or PF_NB Use addresses in the NetBIOS address format. The type parameter specifies the type of socket created. These socket type constants are defined in the header file. See Socket Types for additional details. The types supported are: Type Description SOCK_STREAM Provides sequenced, two-way byte streams that are reliable and connection-oriented. It supports a mechanism for out-of-band data. Stream sockets are supported by the internet (PF_INET) communication domain and local IPC (PF_OS2, PF_UNIX, or PF_LOCAL). SOCK_DGRAM Provides datagrams, which are connectionless messages of a fixed length whose reliability is not guaranteed. Datagrams can be received out of order, lost, or delivered multiple times. Datagram sockets are supported by the internet (PF_INET), local IPC (PF_OS2, PF_UNIX, or PF_LOCAL), and NetBIOS (PF_NETBIOS or PF_NB) communication domains. SOCK_RAW Provides the interface to internal protocols (such as IP and ICMP). Raw sockets are supported by the internet (PF_INET) communication domain. SOCK_SEQPACKET Provides sequenced byte streams that are reliable and connection-oriented. Data is sent without error or duplication and is received in the same order as it was sent. Sequenced packet sockets are supported by the NetBIOS (PF_NETBIOS or PF_NB) communication domain. The protocol parameter specifies a particular protocol to be used with the socket. If the protocol field is set to 0 (default), the system selects the default protocol number for the domain and socket type requested. Default and valid protocol number-protocol family combinations are in the section Socket Protocol Families. The getprotobyname() call can be used to get the protocol number for a protocol with a well-known name. Return Values A non-negative socket descriptor return value indicates success. The return value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). sock_errno() Value Description SOCEMFILE The maximum number of sockets are currently in use. SOCEPROTONOSUPPORT The protocol is not supported in the specified domain or the protocol is not supported for the specified socket type. SOCEPFNOSUPPORT The protocol family is not supported. SOCESOCKTNOSUPPORT The socket type is not supported. Examples Following are examples of the socket() call. int s; struct protoent *p; struct protoent *getprotobyname(char *name); int socket(int domain, int type, int protocol); /* extracted from sys/socket.h */ ... /* Get stream socket in internet domain with default protocol */ s = socket(PF_INET, SOCK_STREAM, 0); ... /* Get raw socket in internet domain for ICMP protocol */ p = getprotobyname("icmp"); s = socket(PF_INET, SOCK_RAW, p->p_proto); Related Calls accept() bind() connect() getsockname() getsockopt() ioctl() listen() os2_ioctl() os2_select() readv() recv() recvfrom() recvmsg() select() send() sendmsg() sendto() setsockopt() shutdown() sock_errno() soclose() writev() ═══ 12.27. soclose() ═══ The socket call shuts down a socket and frees resources allocated to the socket. Syntax #include #include int soclose(s) int s; Parameters s Socket descriptor Description This call shuts down the socket associated with the socket descriptor s, and frees resources allocated to the socket. If s refers to a connected socket, the connection is closed. If the SO_LINGER socket option is enabled (see setsockopt() for additional information), then the task will try to send any queued data. If the SO_LINGER socket option is disabled, then the task will flush any data queued to be sent. Return Values The value 0 indicates success; the value -1 indicates an error. You can get the specific error code by calling sock_errno() or psock_errno(). Error Code Description SOCENOTSOCK The s parameter is not a valid socket descriptor. SOCEALREADY The socket s is marked nonblocking, and a previous connection attempt has not completed. Related Calls accept() getsockopt() setsockopt() sock_errno() socket() ═══ 12.28. sysctl() ═══ The sysctl() call performs special operations on the TCP/IP stack. Unlike getsockopt() or setsockopt(), sysctl() accesses and modifies systemwide parameter values for the entire TCP/IP stack. Syntax #include #include #include #include #include int sysctl(mib, namelen, oldp, oldenp, newp, newlen) int *mib; u_int namelen; void *oldp; size_t newlen; size_t *oldlenp; void *newp; Parameters mib Array of ints, consisting of command, protocol, and control functions. namelen Length of mib array. oldp Data pointer or xxx_ctl structure pointer pointing to data to be sent. oldenp Pointer to length of oldp. newp Data pointer or xxx_ctl structure pointer pointing to location where data is to be stored. newlen Length of newp. Description The sysctl() call is functionally similar to the ioctl() call but does not need a socket to carry the options to and from the stack. The sysctl() function retrieves system information and allows processes to set system information. The information available from sysctl() consists of integers, strings, and tables. Unless explicitly noted below, sysctl() returns a consistent snapshot of the data requested. Consistency is achieved by locking the destination buffer into memory so that the data may be copied without blocking. Calls to sysctl() are serialized to avoid deadlock. The state is described using a Management Information Base (MIB) style name, listed below, which is a namelen length array of integers. The information is copied into the buffer specified by oldp. The size of the buffer is given by the location specified by oldlenp before the call, and that location gives the amount of data copied after a successful call. If the amount of data available is greater than the size of the buffer supplied, the call supplies as much data as fits in the buffer provided and returns with the error code SOCENOMEM. If the old value is not desired, oldp and oldlenp should be set to NULL. The size of the available data can be determined by calling sysctl() with a NULL parameter for oldp. The size of the available data will be returned in the location pointed to by oldenp. For some operations, the amount of space may change often. For these operations, the system attempts to round up so that the returned size is large enough for a call to return the data shortly thereafter. To set a new value, newp is set to point to a buffer of length newlen from which the requested value is to be taken. If a new value is not to be set, newp should be set to NULL and newlen set to 0. An Inetcfg sysctl needs a fifth mib argument, mib[4], to specify the actual inet configuration command. route sysctls use another additional argument to be carried in mib[5] for rt_flags. The old newp may be pointing to a single integer or char buffer. Also, there are two special control structures (inetver_ctl and intecfg_ctl) used as oldp/newp structures. Similarly, for statistics the xxxstat structures should be used. Values The values that are supported for different categories of mib values are listed in the following tables. The generic mib array has the following structure ┌──────────────────────────────────────────────────────────────────┐ │mib Index Description │ ├──────────────────────────────────────────────────────────────────┤ │0 Top Level identifier │ ├──────────────────────────────────────────────────────────────────┤ │1 Protocol Family │ ├──────────────────────────────────────────────────────────────────┤ │2 Protocol │ ├──────────────────────────────────────────────────────────────────┤ │3 Address Family or Control Command │ ├──────────────────────────────────────────────────────────────────┤ │4 Control Command │ ├──────────────────────────────────────────────────────────────────┤ │5 Flags, etc. │ └──────────────────────────────────────────────────────────────────┘ The mib[0] Top Level identifiers are: ┌─────────────────────────────────────────────────────────────────┐ │Identifier Description │ ├─────────────────────────────────────────────────────────────────┤ │CTL_KERN Sockets (kernel) domain. │ ├─────────────────────────────────────────────────────────────────┤ │CTL_NET Routing domain. │ ├─────────────────────────────────────────────────────────────────┤ │CTL_OS2 LIPC (afos2) domain. │ └─────────────────────────────────────────────────────────────────┘ The supported mib values, listed alphabetically, are:  ICMPCTL_ECHOREPL  ICMPCTL_MASKREPL  ICMPCTL_STATS  ICMPCTL_TTL  IPCTL_ARPKILLC  IPCTL_ARPKILLI  IPCTL_FIREWALL  IPCTL_FORWARD  IPCTL_FORWARDING  IPCTL_FRAGTTL  IPCTL_ICMPTTL  IPCTL_INETVER  IPCTL_MULTIDEFROUTES  IPCTL_SENDREDIRECTS  IPCTL_SYNATTCK  KERNCTL_INETVER  LIPCCTL_INETVER  LIPCCTL_DG_SENDSPACE  LIPCCTL_DG_RECVSPACE  LIPCCTL_ST_RECVSPACE  LIPCCTL_ST_SENDSPACE  NET_RT_DUMP  NET_RT_FLAGS  NET_RT_IFLIST  NET_RT_LLINFO  OS2_MEMMAPIO  OS2_QUERY_MEMMAPIO  TCPCTL_CC  TCPCTL_KEEPCNT  TCPCTL_LINGERTIME  TCPCTL_MSL  TCPCTL_MSSDFLT  TCPCTL_MTU  TCPCTL_REALSLOW  TCPCTL_RTTDFLT  TCPCTL_STATS  TCPCTL_TCPRWIN  TCPCTL_TCPSWIN  TCPCTL_TIMESTMP  TCPCTL_TTL  TCPCTL_WINSCALE  UDPCTL_CHECKSUM  UDPCTL_STATS  UDPCTL_TTL  UDPCTL_UDPRWIN  UDPCTL_UPRSWIN Return Values The requested values are returned in newp. The sysctl() call itself returns the number of bytes copied, if the call is successful. Otherwise, -1 is returned and the errno is set appropriately. Error Code Description SOCENOPROTOOPT The protocol specified in mib[1] is not valid. SOCENOTDIR The length specified in namelen is not valid. SOCEOPNOTSUPP The option specified in mib[3] is not supported. SOCEINVAL Insufficient mib parameters were supplied. SOCENOMEM Memory allocation failed. This error value is returned by High Performance Send (HPS) sysctl (OS2_MEMMAPIO). SOCEPERM This parameter cannot be set, it can only be retrieved. Therefore, newp must be set to NULL. Related Calls ioctl() os2_ioctl() ═══ 12.28.1. Supported mib[3] Values When mib[0]=CTL_KERN, mib[1]=KERN_HOSTID, and mib[2]=0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │KERNCTL_INETVER struct Get (no set) the sockets.sys │ │ inetver_ctl version number. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.2. Supported mib[3] Values When mib[0]=CTL_OS2, mib[1]=PF_OS2, and mib[2]=0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │LIPCCTL_INETVER struct Get (no set) the afos2.sys │ │ inetvers_ctl (LIPC) version number. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.3. Supported mib[4] Values When mib[0]=CTL_OS2, mib[1]=PF_OS2, mib[2]=0, and mib[3]=LIPCCTL_INETCFG ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │LIPCCTL_DG_RECVSPACE int Get or set the datagram │ │ RecvSpace. │ ├──────────────────────────────────────────────────────────────────┤ │LIPCCTL_DG_SENDSPACE int Get or set the datagram │ │ SendSpace. │ ├──────────────────────────────────────────────────────────────────┤ │LIPCCTL_ST_RECVSPACE int Get or set the stream │ │ RecvSpace. │ ├──────────────────────────────────────────────────────────────────┤ │LIPCCTL_ST_SENDSPACE int Get or set the stream │ │ SendSpace. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.4. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_INET, mib[2]=IPPROTO_TCP, and mib[3]=TCPCTL_INETCFG ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_CC int Get or set the CC, CCnew and │ │ Echo flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_KEEPCNT int Get or set the number of │ │ keepalive probes. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_LINGERTIME int Get or set the linger on close │ │ time. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_MSL int Get or set the Maximum Segment │ │ Lifetime value. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_MTU int Get or set the path Maximum │ │ Transmission Unit (MTU) │ │ Discovery flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_REALSLOW int Get or set the Real Slow Timer │ │ value for the Time Wait Queue. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_TCPRWIN int Get or set the TCP receive │ │ window size. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_TCPSWIN int Get or set the TCP send window │ │ size. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_TIMESTMP int Get or set the TCP timestamp │ │ flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_TTL int Get or set the time to live │ │ (TTL) for TCP packets. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_WINSCALE int Get or set the window scale (fat│ │ pipe) flag on or off. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.5. Supported mib[3] Values When mib[0]=CTL_OS2, mib[1]=PF_INET, and mib[2]=0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │OS2_MEMMAPIO long * Get (no set) memio. │ ├──────────────────────────────────────────────────────────────────┤ │OS2_QUERY_MEMMAPIO long * Get (no set) memio status. │ └──────────────────────────────────────────────────────────────────┘ Get (no set) memio This sysctl will do memory mapped IO for High Performance Send (HPS), thus returning a 60 KByte kernel memory cluster as array of 15 char pointers to the kernel memory each of size 4KBytes. This returns kernel memory mapped to the user space but the ownership belongs to the application. It is the responsibility of the application to use either semaphores or the OS2_QUERY_MEMMAPIO call to ensure reusability of these 15 buffers after calling a send api. Kernel bears no responsibility whatsoever for the reuse of these buffers, and if not coordinated properly this may result in garbled packets being sent. There can be a maximum of 64 such simultaneous calls systemwide, thus limiting the systemwide maximum HPS memory in use to be 64 times 60KB. Any subsequent attempts to claim HPS memory will be returned with the ENOMEM error code. Note again that these buffers can be reused after each send, but with caution. For an example of High Performance Send, see High Performance Send. Get (no set) memio status This sysctl() call verifies the reusability of the buffers returned by kernel through the OS2_MEMMAPIO sysctl() call. The application needs to build an array of pointers, each pointing to the 4K memory area returned by the kernel and pass the pointer to this array as oldp, with the number of 4K chunks as oldenp. This array may hold lesser or more than 15 such pointers, each pointing to the 4K memory chunk. On return, if a particular pointer in this array is intact then 'that' memory buffer is ready for reuse. The buffer pointers not yet ready for reuse will be substituted by NULL. The application is responsible to explicitly check for reusability of these HPS buffers after each send api call. Another way of managing the reusability of these buffers is through system semaphores. ═══ 12.28.6. Supported mib[3] Values When mib[0]=CTL_NET, mib[1]=PF_INET, and mib[2]=IPPROTO_TCP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_MSSDFLT int Get or set the TCP maximum │ │ segment size (MSS) default. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_RTTDFLT int Get or set the real time trace │ │ (RTT) default. │ ├──────────────────────────────────────────────────────────────────┤ │TCPCTL_STATS struct Get (no set) the TCP statistics.│ │ tcpstat │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.7. Supported mib[3] Values When mib[0]=CTL_NET, mib[1]=PF_INET, mib[2]=IPPROTO_UDP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │UDPCTL_CHECKSUM int Get or set the UDP checksum │ │ computing on or off. │ ├──────────────────────────────────────────────────────────────────┤ │UDPCTL_STATS struct Get (no set) the UDP statistics.│ │ udpstat │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.8. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_INET, mib[2]=IPPROTO_UDP, and mib[3]=UDPCTL_INETCFG ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │UDPCTL_TTL int Get or set the time to live │ │ (TTL) for UDP packets. │ ├──────────────────────────────────────────────────────────────────┤ │UDPCTL_UDPRWIN int Get or set the UDP receive │ │ window size. │ ├──────────────────────────────────────────────────────────────────┤ │UDPCTL_UDPSWIN int Get or set the UDP send window │ │ size. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.9. Supported mib[3] Values When mib[0]=CTL_NET, mib[1]=PF_INET, and mib[2]=IPPROTO_IP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_INETVER struct Get (no set) the afinet.sys │ │ inetvers_ctl version number. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_FORWARDING int Get or set the IP forwarding │ │ flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_SENDREDIRECTS int Get set the Send Redirects flag │ │ on or off. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.10. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_INET, mib[2]=IPPROTO_IP, and mib[3]=IPCTL_INETCFG ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_ARPKILLC int Get or set the ARP cache │ │ completed entry timeout. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_ARPKILLI int Get or set the ARP cache │ │ incompleted entry timeout. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_FIREWALL int Get or set the IP firewall flag │ │ on or off. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_FORWARD int Get or set the IP forwarding │ │ flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_FRAGTTL int Get or set the fragment's time │ │ to live (TTL). │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_ICMPTTL int Get or set the time to live │ │ (TTL) for ICMP packets. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_MULTIDEFROUTES int Get or set the multiple default │ │ routes function flag on or off. │ ├──────────────────────────────────────────────────────────────────┤ │IPCTL_SYNATTCK int Get or set the SYN Attack flag │ │ on or off. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.11. Supported mib[3] Values When mib[0]=CTL_NET, mib[1]=PF_INET, and mib[2]=IPPROTO_ICMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[3] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │ICMPCTL_ECHOREPL int Get or set the ICMP echo flag on│ │ or off. │ ├──────────────────────────────────────────────────────────────────┤ │ICMPCTL_MASKREPL int Get or set the flag to check if │ │ the system should respond to │ │ ICMP address mask requests on or│ │ off. │ ├──────────────────────────────────────────────────────────────────┤ │ICMPCTL_STATS struct Get (no set) the ICMP │ │ icmpstat statistics. │ ├──────────────────────────────────────────────────────────────────┤ │ICMPCTL_TTL int Get or set the time to live │ │ (TTL) for ICMP packets. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.12. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.13. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.14. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.15. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.16. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.17. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.18. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.19. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.20. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.21. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.22. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.23. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.24. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.25. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.26. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.27. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.28. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.29. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.30. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.31. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.32. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.33. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.34. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.35. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.36. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.37. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.38. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.39. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.40. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.41. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.42. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.43. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.44. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.45. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.46. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.47. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.48. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.49. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.50. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.51. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.52. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.53. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.54. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.55. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.56. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.57. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.58. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.59. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.60. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.61. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.62. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.63. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.64. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.65. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.66. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.67. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.68. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.69. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.70. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.71. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.72. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.73. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.74. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.75. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.76. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.77. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.78. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.79. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.80. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.81. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.82. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.83. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.84. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.85. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.86. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.87. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.88. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.89. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.90. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.91. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.92. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.93. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.94. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.95. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.96. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.97. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.98. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.99. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.100. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.101. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.102. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.103. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.104. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.105. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.106. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.107. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.108. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.109. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.110. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.111. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.112. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.113. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.114. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.115. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.116. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.117. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.118. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.119. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.120. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.121. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.122. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.123. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.124. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.125. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.126. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.127. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.128. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.129. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.130. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.131. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.132. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.133. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.134. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.135. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.136. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.137. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.138. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.139. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.140. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.141. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.142. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.143. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.144. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.145. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.146. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.147. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.148. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.149. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.150. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.151. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.152. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.153. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.154. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.155. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.156. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.157. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.158. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.159. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.160. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.161. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.162. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.163. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.164. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.165. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.166. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.167. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.168. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.169. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.170. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.171. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.172. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.173. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.174. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.175. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.176. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.177. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.178. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.179. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.180. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.181. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.182. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.183. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.184. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.185. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.186. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.187. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.188. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.189. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.190. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.191. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.192. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.193. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.194. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.195. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.196. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.197. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.198. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.199. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.200. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.201. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.202. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.203. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.204. Supported mib[4] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, and mib[3]= any valid address family or 0 ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[4] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_DUMP char * Dump the routing table entries │ │ corresponding to the address │ │ family specified in mib[5]. If │ │ the address family is zero, then│ │ all routing tables are returned.│ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_FLAGS char * Dump the routing table entries │ │ corresponding to the routing │ │ flag RTF_xxx specified in │ │ mib[5]. │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_IFLIST char * Return information for all │ │ configured interfaces. A nonzero│ │ mib[5] value specifies the index│ │ for a particular interface, and │ │ interface information for only │ │ that interface is returned. │ └──────────────────────────────────────────────────────────────────┘ ═══ 12.28.205. Supported mib[5] Values When mib[0]=CTL_NET, mib[1]=PF_ROUTE, mib[2]=0, mib[3]= any valid address family or 0, and mib[4]=NET_RT_DUMP ═══ ┌──────────────────────────────────────────────────────────────────┐ │mib[5] Values Data Type Description │ ├──────────────────────────────────────────────────────────────────┤ │NET_RT_LLINFO int Dump the routing table │ │ corresponding to the address │ │ family specified in mib[3]. If │ │ the address family is zero, │ │ return all route tables. It │ │ carries the RFT_xxx flags or │ │ interface index. │ └──────────────────────────────────────────────────────────────────┘