home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 14 Text
/
14-Text.zip
/
mptsref.zip
/
MPTSPREF.INF
(
.txt
)
< prev
Wrap
OS/2 Help File
|
1996-04-04
|
202KB
|
7,908 lines
ΓòÉΓòÉΓòÉ 1. Version Notice ΓòÉΓòÉΓòÉ
First Edition (August 1994)
The following paragraph does not apply to the United Kingdom or any country
where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS
MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states
do not allow disclaimer of express or implied warranties in certain
transactions; therefore, this statement may not apply to you.
This publication could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time.
It is possible that this publication may contain reference to, or information
about, IBM products (machines and programs), programming, or services that are
not announced in your country. Such references or information must not be
construed to mean that IBM intends to announce such IBM products, programming,
or services in your country.
Requests for copies of this publication and for technical information about IBM
products should be made to your IBM Authorized Dealer or your IBM Marketing
Representative.
ΓòÉΓòÉΓòÉ 2. Notices ΓòÉΓòÉΓòÉ
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the Agreement for IBM
Licensed Programs.
Any reference to an IBM licensed program in this document is not intended to
state or imply that only the IBM program may be used.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send inquiries, in writing, to the IBM
Director of Commercial Relations, International Business Machines Corporation,
Purchase, New York, 10577.
Asia-Pacific users can inquire, in writing, to the IBM Director of Intellectual
Property and Lisensing, IBM World Trade Asia Corporation, 2-31, Roppongi
3-chome, Minato-ku, Tokyo 106, Japan.
References in this publication to IBM products, programs, or services do not
imply that IBM intends to make them available in all countries in which IBM
operates.
This document is not intended for production use and is furnished as is without
any warranty of any kind, and all warranties are hereby disclaimed including
the warranties of merchantability and fitness for a particular purpose.
Portions herein (C) Copyright 1979, 1980, 1983, 1986, Regents of the University
of California. Reproduced by permission. Portions herein were developed at the
Electrical Engineering and Computer Sciences Department at the Berkeley campus
of the University of California under the auspices of the Regents of the
University of California.
ΓòÉΓòÉΓòÉ 2.1. Trademarks ΓòÉΓòÉΓòÉ
The following terms, denoted by an asterisk (*) at their first occurrences in
this publication, are trademarks of IBM Corporation in the United States or
other countries:
┤БББББББББББББББББББББББББСББББББББББББББББББББББББББСБББББББББББББББББББББББББЖ
В AIX В AnyNet В IBM В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББТБББББББББББББББББББББББББЙ
В Operating System/2 В OS/2 В PC AT В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББТБББББББББББББББББББББББББЙ
В Presentation Manager В PS/2 В RISC System/6000 В
БББББББББББББББББББББББББ╔ББББББББББББББББББББББББББ╔БББББББББББББББББББББББББД
The following terms, denoted by a double asterisk (**) at their first
occurrences in this publication, are trademarks of other companies:
Trademark Owned By
AppleTalk Apple Computer, Inc.
Hayes Hayes Microcomputer Products, Inc.
Intel Intel Corporation
Microsoft C Microsoft Corporation
Motorola Motorola
NCS Apollo Computer, Inc.
Network Computing System Apollo Computer, Inc.
NDIS 3Com Corporation/Microsoft Corporation
Network File System Sun Microsystems, Inc.
NFS Sun Microsystems, Inc.
Portmapper Sun Microsystems, Inc.
PostScript Adobe Systems, Inc.
Sun Sun Microsystems, Inc.
UNIX UNIX System Laboratories, Inc.
X Window System Massachusetts Institute of Technology.
ΓòÉΓòÉΓòÉ 3. About This Book ΓòÉΓòÉΓòÉ
IBM Multi-Protocol Transport Services - AnyNet for OS/2: Programmer's
Reference describes the Socket programming interface in an multi-protocol
transport services (MPTS) environment for Operating System/2 software on a
personal computer (PC).
The MPTS Sockets over NetBIOS code and this MPTS publication are provided to
encourage users who want to start writing Sockets applications while
maintaining their use of NetBIOS applications on the LAN. Users are hereby
advised, however, that this code is due to be replaced with equivalent code
within a relatively short time. The Socket API will not be affected. It is
suggested that only applications of a developmental nature be written to these
interfaces. Such applications should not be used in high stress environments
until the replacement code has been delivered.
Note: In this book, the abbreviation PC refers to a personal computer that can
run IBM OS/2 Version 2.0 or later. The abbreviation OS/2 refers to
Operating System/2, Version 2.0.
ΓòÉΓòÉΓòÉ 3.1. Who Should Use This Book ΓòÉΓòÉΓòÉ
This book is intended for system programmers writing Socket applications for a
PC.
You should have a working knowledge of the transport protocols (such as TCP/IP
and NetBIOS). In this book, the term protocol refers to a set of rules for
handling communication tasks.
If you are not familiar with TCP/IP concepts, see Internetworking with TCP/IP
Volume I: Principles, Protocols, and Architectures, and Internetworking with
TCP/IP Volume II: Implementation and Internals.
If you are not familiar with LAN and NetBIOS protocol, see the IBM OS/2 LAN
Technical Reference.
ΓòÉΓòÉΓòÉ 3.2. How to Use This Book ΓòÉΓòÉΓòÉ
You should read this book before you start writing Socket applications on MPTS.
ΓòÉΓòÉΓòÉ 3.2.1. How This Book Is Organized ΓòÉΓòÉΓòÉ
This book is organized into the following chapters and appendixes. Read the
beginning of each chapter to familiarize yourself with the topics that you need
to know to plan and install this product.
General Programming Information, contains fundamental, technical information
about the application program interfaces (API) provided with MPTS for OS/2.
Sockets, describes the socket interface and how to use the socket routines in a
user-written application.
Sample Socket Programs provides sample TCP and UDP client and server C socket
communications programs.
System Return Codes provides the system error messages, along with codes and
descriptions.
Socket Quick Reference describes each socket call supported by MPTS for OS/2.
This book also includes a glossary, a bibliography, and an index.
ΓòÉΓòÉΓòÉ 3.2.2. How the Term "internet" is Used ΓòÉΓòÉΓòÉ
In this book, an internet is a logical collection of networks supported by
gateways, routers, hosts, and various layers of protocols that permit the
network to function as a large, virtual network.
Note: 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 a
myriad of regional and local campus networks all over the world.
ΓòÉΓòÉΓòÉ 3.2.3. How Numbers Are Used in This Book ΓòÉΓòÉΓòÉ
In this book, numbers over four digits are represented in metric style. A space
is used rather than a comma to separate groups of three digits. For example,
the number sixteen thousand one hundred forty-seven is written 16 147.
ΓòÉΓòÉΓòÉ 3.3. Related Books ΓòÉΓòÉΓòÉ
The following is a list of related publications that you might want to read for
more information about MPTN:
o IBM TCP/IP Tutorial and Technical Overview
o Internetworking with TCP/IP Volume I: Principles, Protocols, and
Architectures
o Internetworking with TCP/IP Volume II: Implementation and Internals
o IBM Operating System/2 Extended Edition Version 1.3 System Administrator's
Guide for Communications
o Introducing IBM's TCP/IP Products for OS/2, VM, and MVS
o IBM TCP/IP Version 2.0 for OS/2: Programmer's Reference
o IBM TCP/IP Version 2.0 for OS/2: User's Guide
o IBM TCP/IP Version 2.0 for OS/2: Quick Reference Guide.
o IBM Local Area Network Technical Reference
o IBM MPTS - AnyNet for OS/2: Configuration Guide.
For more information about related publications, see the Bibliography at the
back of this book.
ΓòÉΓòÉΓòÉ 4. General Programming Information ΓòÉΓòÉΓòÉ
This chapter contains technical information that you need to know before you
attempt to work with the Socket application program interfaces (API) provided
with the Socket/MPTS for OS/2, which are described in this book.
You should have installed the MPTS for OS/2 product and application programming
interfaces (APIs) in the MPTN directory.
ΓòÉΓòÉΓòÉ 4.1. Header Files ΓòÉΓòÉΓòÉ
The following are some of the Socket application header files located on MPTS -
Disk 3.
ARPA\NAMESER.H NERRNO.H
NET\IF_ARP.H NETDB.H
NET\IF.H NETINET\IN.H
NET\ROUTE.H NETLIB.H
SYS\SELECT.H SYS\SOCKET.H
SYS\TIME.H TYPES.H
UTILS.H NETNB\NB.H
SYS\DOMAIN.H SYS\PROTOSW.H
SYS\UN.H SYS\IOCTL.H
ΓòÉΓòÉΓòÉ 4.2. Library Files ΓòÉΓòÉΓòÉ
Library Files and Their Application and DLL Files and Their Application list
library files to which an application must link. These files are in the
<mptn\lib> directory and the <mptn\dll> directory.
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 1. Library Files and Their Application В
╙БББББББББББББББББББББББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В LIBRARY FILE В APPLICATION В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В SO32DLL.LIB В Dynamic 32-bit protocol-independent Socket calls В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TCPIPDLL.LIB В Dynamic 16-bit Socket calls В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TCP32DLL.LIB В Dynamic 32-bit protocol-dependent Socket calls В
БББББББББББББББББББББББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББД
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 2. DLL Files and Their Application В
╙БББББББББББББББББББББББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В DLL FILE В APPLICATION В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TCPIPDLL.DLL В Executable 16-bit Socket calls В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В SO32DLL.DLL В Executable 32-bit protocol-independent Socket calls В
╙БББББББББББББББББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TCP32DLL.DLL В Executable 32-bit protocol-dependent Socket calls В
БББББББББББББББББББББББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББД
Note: All DLL files must reside in a directory listed in the LIBPATH system
variable for the program to run.
ΓòÉΓòÉΓòÉ 4.3. Porting Considerations ΓòÉΓòÉΓòÉ
You should be aware of the following when you port your application:
o To access system return values, you need to use only the errno.h include
statement supplied with the compiler.
o To access network return values, you must add the following include
statement:
#include <nerrno.h>
o To access system and network return values from Socket APIs, you must use
sock_errno() or psock_errno() rather than errno or perror() to return the
errno information.
For more information about porting a specific application, see the chapter for
that application.
ΓòÉΓòÉΓòÉ 4.4. 16-Bit Application Compiling and Linking ΓòÉΓòÉΓòÉ
Although 16-bit application compiling and linking are not supported in this
MPTS package, a 16-bit application can still run.
ΓòÉΓòÉΓòÉ 4.5. 32-Bit Application Compiling and Linking ΓòÉΓòÉΓòÉ
The Socket/MPTS support for 32-bit applications is compatible with TCP/IP 2.0.
The following steps describe the compiling and linking procedure for an
Application Programming Interface (API) using the IBM C Set/2 compiler.
1. Set your environment variables to find the following:
o Executable programs
o Link libraries
o Header files
You can set the environment variables interactively, or you can include
them in your CONFIG.SYS file. The following is an example of the entries
you may have in your CONFIG.SYS file.
SET PATH=C:\IBMC\BIN;%PATH%
SET DPATH=C:\IBMC\LOCALE;C:\IBMC\HELP;%DPATH%
SET LIB=C:\IBMC\LIB;C:\MPTN\LIB;%LIB%
SET INCLUDE=C:\IBMC\INCLUDE;C:\MPTN\INCLUDE;%INCLUDE%
SET HELP=C:\IBMC\HELP;%HELP%
SET BOOKSHELF=C:\IBMC\HELP;%BOOKSHELF%
SET TZ=EST5EDT,0,0,0,0,0,0,0,0,0
2. To compile your program, enter the following command:
icc /C+ /DMPTN /DSO32 /DOS2 myprog
o For a dynamically linked, single-threaded program:
LINK386 myprog.obj,,DDE4SBS.LIB DDE4SBM.LIB SO32DLL.LIB TCP32DLL.LIB
OS2386.LIB
o For a dynamically linked, multithreaded program:
LINK386 myprog.obj,,DDE4MBS.LIB DDE4MBM.LIB SO32DLL.LIB TCP32DLL.LIB
OS2386.LIB
Note:
1. For information about compiling and linking a particular application
program interface, see the chapter on that interface.
2. When running an application that is built using DLL, the LIBPATH
environment variable in your CONFIG.SYS file must point to the MPTN\DLL
directory.
3. For more information about the compile and link option, multithreaded
libraries, and dynamic link libraries, see the IBM C Set/2 User's Guide.
4. You must include the Socket/MPTS library header files to ensure that proper
function declaration and parameter types are used.
ΓòÉΓòÉΓòÉ 5. Sockets ΓòÉΓòÉΓòÉ
This chapter describes the C socket application programming interface (API),
which is provided with Socket/MPTS for OS/2. Use the socket routines to
interface with the Local IPC, NetBIOS, TCP/IP over NetBIOS, TCP, UDP, ICMP, and
IP protocols. These socket routines allow a program to communicate across
networks with other programs. You can, for example, make use of socket
routines when you write a client program that must communicate with a server
program running on another computer.
To use the sockets, you must know C language programming.
ΓòÉΓòÉΓòÉ 5.1. Programming with Sockets ΓòÉΓòÉΓòÉ
The OS/2 socket API provides a standard interface to the transport and
internetwork layer interfaces of MPTN. It supports four socket types: stream,
sequence packet, datagram, and raw. Stream, sequence packet, and datagram
sockets interface to the transport layer protocols, and raw sockets interface
to the TCP/IP network layer protocols. You should choose the most appropriate
interface for an application.
ΓòÉΓòÉΓòÉ 5.1.1. Socket Programming Concepts ΓòÉΓòÉΓòÉ
Before programming with the socket API, it is helpful to consider some
important concepts.
ΓòÉΓòÉΓòÉ 5.1.1.1. What is a Socket ΓòÉΓòÉΓòÉ
A socket is an endpoint for communication that can be named and addressed in a
network. From an application program perspective, it is a resource allocated
by the operating system. It is represented by an integer called a socket
descriptor.
The socket interface is designed to provide applications with a network
interface that hides the details of the physical network. The interface is
differentiated by the different services that are provided. Stream, datagram,
and raw sockets each define a different service available to applications.
ΓòÉΓòÉΓòÉ 5.1.1.2. Socket Types ΓòÉΓòÉΓòÉ
The stream socket (SOCK_STREAM) interface defines a reliable
connection-oriented service. Data is sent without errors or duplication and is
received in the same order as it is sent. Flow control is built in to avoid
data overruns. No boundaries are imposed on the data; it is considered to be a
stream of bytes. An example of an application that uses stream sockets is the
File Transfer Protocol (FTP).
The sequence packet (SOCK_SEQPACKET) interface defines a reliable
connection-oriented service. Data is sent without error or duplication and is
received in the same order as it was sent. Flow control is built in to avoid
data overruns. Every sequence packet is sent and received as a complete
record.
The datagram socket (SOCK_DGRAM) interface defines a connectionless service.
Datagrams are sent as independent packets. The service provides no guarantees;
data can be lost or duplicated, and datagrams can arrive out of order. The
size of a datagram is limited to the size that an underlying protocol supports.
For UDP, the maximum datagram size (that can be sent in a single transaction)
is 32 767. The default is 8192. No packet disassembly and reassembly is
performed. An example of an application that uses datagram sockets is the
Network File System (NFS).
The raw socket (SOCK_RAW) interface allows direct access to lower layer
protocols such as IP and Internet Control Message Protocol (ICMP). The
interface is often used for testing new protocol implementations or gaining
access to some of the more advanced facilities of an existing protocol.
The socket types are defined in the <SYS\SOCKET.H> header file.
The socket interface can be extended; therefore, you can define new socket
types to provide additional services. An example of this is the transaction
type sockets defined for interfacing to the versatile message transfer protocol
(VMTP). НDavid R. Cheriton and Carey L. Williamson, "VMTP as the Transport
Layer for High-Performance Distributed Systems," IEEE Communications, June
1989, Vol. 27, No. 6. Γöÿ
Transaction-type sockets are not supported by MPTN for OS/2. Because socket
interfaces isolate you from the communication functions of the different
protocol layers, the interfaces are largely independent of the underlying
network. In the OS/2 implementation of sockets, stream sockets interface to
TCP, sequence packet socket interface to native NetBIOS, datagram sockets
interface to UDP, and raw sockets interface to ICMP and IP. In the future, the
underlying protocols may change, but the socket interface will remain the same.
For example, stream sockets may eventually interface to the International
Standards Organization (ISO) Open System Interconnection (OSI) transport class
4 protocol. This means that applications will not have to be rewritten as
underlying protocols change. НThis does not imply an IBM statement of
direction. Γöÿ
ΓòÉΓòÉΓòÉ 5.1.2. Guidelines for Using Socket Types ΓòÉΓòÉΓòÉ
The following considerations help you choose the appropriate socket type for an
application.
If you are communicating with an existing application, you must use the same
protocols as the existing application. For example, if you interface to an
application that uses NetBIOS or LIPC, you must use stream sockets. For other
applications, you should consider the following factors:
o Reliability. Stream sockets provide the most reliable connection. Datagram,
or raw sockets, are unreliable, because packets can be discarded, corrupted,
or duplicated during transmission. This may be acceptable if the application
does not require reliability, or if the application implements the
reliability on top of the socket's interface. The trade-off is the increased
performance available over stream sockets.
o Performance. The overhead associated with reliability, flow control, packet
reassembly, and connection maintenance degrades the performance of stream
sockets so that they do not perform as well as datagram sockets.
o Amount of data to be transferred. Datagram sockets impose a limit on the
amount of data transferred, depending on the protocol. If you send less than
4089 bytes at a time, use datagram sockets. As the amount of data in a
single transaction increases, it is preferable to use stream sockets.
If you are writing a new protocol on top of IP or wish to use the ICMP
protocol, then you must choose raw sockets.
ΓòÉΓòÉΓòÉ 5.1.2.1. Address Families ΓòÉΓòÉΓòÉ
or communication domains. All hosts in the same address family understand and
use the same scheme of address socket endpoints. MPTN for OS/2 supports three
address families:
o AF_INET - Defines addresses in the internet domain.
o AF_NETBIOS - Defines addresses in the NetBIOS LAN.
o AF_OS2 - Defines addresses in the Local IPC.
The AF_INET domain defines address in the internet domain. The AF_NETBIOS
defines addresses in the NetBIOS LAN and the AF_OS2 defines addresses in the
Local IPC. The address families are defined in the <SYS\SOCKET.H> header file.
ΓòÉΓòÉΓòÉ 5.1.2.2. Socket Address ΓòÉΓòÉΓòÉ
A socket address is defined by the sockaddr structure in the <SYS\SOCKET.H>
header file. It has two fields, as shown in the following example:
struct sockaddr
{
u_short sa_family; /* address family */
char sa_dataН14┘; /* up to 14 bytes of direct address */
};
The sa_family field contains the address family. It is AF_INET for the internet
domain. The sa_data field is different for each address family. Each address
family defines its own structure, which can be overlaid on the sockaddr
structure.
Addressing within a NetBIOS/LAN
A socket address in a NetBIOS address family is comprised of four fields: the
address family (AF_NETBIOS), the address type, NetBIOS netid and NetBIOS name.
The structure of a NetBIOS socket address is defined by the following
sockaddr_nb structure, which is found in the <NETNB\NB.H> header file:
struct sockaddr_nb
{
short snb_family; /* netbios protocol family */
short snb_type; /* unique or multicast */
char snb_netidНNB_NETIDLEN┘; /* netbios netid */
char snb_nameНNB_NAMELEN┘; /* netbios name */
};
Addressing within a Local Socket (LIPC)
A socket address in a local system is comprised of two fields: the address
family (AF_OS2) and the path name. The structure of a local IPC socket address
is defined by the following sockaddr_un structure, which is found in the
<SYS\UN.H> header file:
struct sockaddr_un
{
short sun_family; /* AF_UNIX or AF_OS2 */
char sun_pathН108┘; /* path name */
};
Addressing within an Internet Domain
A socket address in an internet address family comprises four fields: the
address family (AF_INET), an internet address, a port, and a character array.
The structure of an internet socket address is defined by the following
sockaddr_in structure, which is found in the <NETINET\IN.H> header file:
struct in_addr
{
u_long s_addr;
};
struct sockaddr_in
{
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zeroН8┘;
};
The sin_family field is set to AF_INET. The sin_port field is the port used by
the application, in network-byte order. The sin_addr field is the internet
address of the network interface used by the application. It is also in
network-byte order. The sin_zero field should be set to all zeros.
ΓòÉΓòÉΓòÉ 5.1.2.3. Internet Addresses ΓòÉΓòÉΓòÉ
Internet addresses are 32-bit quantities that represent a network interface.
Every internet address within an administered AF_INET domain must be unique. A
common misunderstanding is that every host must have only one internet address.
In fact, a host has 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.
ΓòÉΓòÉΓòÉ 5.1.2.4. Ports ΓòÉΓòÉΓòÉ
A port is used to differentiate between different applications 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.
ΓòÉΓòÉΓòÉ 5.1.2.5. Network-Byte Order ΓòÉΓòÉΓòÉ
using the network-byte ordering convention. Network-byte order is also known as
big endian byte ordering, as in MotorolaН**┘ microprocessors (compared with
little endian byte ordering in IntelН**┘ microprocessors). Using network-byte
ordering for data exchanged between hosts allows hosts using different
architectures to exchange address information. See pages Main Socket Calls,
Main Socket Calls, and Main Socket Calls for examples of using the htons() call
to put ports into network-byte order. For more information about network-byte
order, see accept(), bind(), htonl(), htons(), ntohl(), and ntohs().
Note: The socket interface does not handle application data byte ordering
differences. Application writers must handle byte order differences
themselves or use higher-level interfaces, such as Remote Procedure
Calls (RPC) or Network Computing System (NCS).
ΓòÉΓòÉΓòÉ 5.1.3. Main Socket Calls ΓòÉΓòÉΓòÉ
With few socket calls, you can write a very powerful network application.
1. First, an application must be initialized with sockets using the
sock_init() call, as in the example listed in An Application Uses the
sock_init() Call. For a more detailed description, see sock_init().
An Application Uses the sock_init() Call
int rc;
int sock_init();
.
.
.
rc = sock_init();
The code fragment in An Application Uses the sock_init() Call initializes
the process with the socket library and checks whether MPTN.SYS is running.
2. Next, an application must get a socket descriptor example listed in An
Application Uses the socket() Call. For a more detailed description, see
socket().
An Application Uses the socket() Call
int socket(int domain, int type, int protocol);
.
.
.
int s;
.
.
.
s = socket(AF_INET, SOCK_STREAM, 0);
The code fragment in An Application Uses the socket() Call allocates a
socket descriptor s in the internet address family. The domain parameter
is a constant that specifies the domain where the communication is taking
place. A domain is the collection of applications using the same naming
convention. Socket/MPTS supports three address families: AF_INET,
AF_NETBIOS, and AF_OS2. The type parameter is a constant that specifies the
type of socket, which can be SOCK_STREAM, SOCK_SEQPACKET, SOCK_DGRAM, or
SOCK_RAW. protocol parameter is a constant that specifies the protocol to
use. Passing 0 chooses the default protocol. If successful, socket()
returns a positive integer called socket descriptor.
3. After an application has a socket descriptor, it can explicitly bind() a
unique name to the socket, as in the example listed in An Application Uses
the bind() Call. For a more detailed description, seebind().
An Application Uses the bind() Call
int rc;
int s;
struct sockaddr_in myname;
int bind(int s, struct sockaddr *name, int namelen);
/* clear the structure to be sure that the sin_zero field is clear */
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));
This example binds myname to socket s. The name specifies that the
application is in the internet domain (AF_INET) at internet address
129.5.24.1, and is bound to port 1024. Servers must bind a name to become
accessible from the network. The example in An Application Uses the bind()
Call shows two useful utility routines:
o 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().
o htons() takes a port number in host-byte order and returns the port in
network-byte order. For a more detailed description, see htons().
4. After binding a name to a socket, a server using stream sockets must
indicate its readiness to accept connections from clients. The server does
this with the listen() call, as illustrated in the example in An
Application Uses the listen() Call.
An Application Uses the listen() Call
int s;
int backlog;
int rc;
int listen(int s, int backlog);
.
.
.
rc = listen(s, 5);
socket/MPTS software that the server is ready to begin accepting
connections and that a maximum of five connection requests can be queued
for the server. Additional requests are ignored. For a more detailed
description, see listen().
5. Clients using stream sockets initiate a connection request by calling
connect(), as shown in An Application Uses the connect() Call.
An Application Uses the connect() Call
int s;
struct sockaddr_in servername;
int rc;
int connect(int s, struct sockaddr *name, int namelen);
.
.
.
memset(&servername, 0,sizeof(servername));
servername.sin_family = AF_INET;
servername.sin_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
servername. This could be the server that was used in the previous bind()
example. The caller optionally blocks until the connection is accepted by
the server. On successful return, the socket s is associated with the
connection to the server. For a more detailed description, see connect().
An Application Uses the gethostbyname() Call
int s;
struct sockaddr_in servername;
char *hostname = "serverhost";
int rc;
int connect(int s, struct sockaddr_in *name, int namelen);
struct servent *sp;
struct hostent *hp;
.
.
.
hp = gethostbyname(hostname);
/* clear the structure to be sure that the sin_zero field is clear */
memset(&servername,0,sizeof(servername));
servername.sin_family = AF_INET;
servername.sin_addr.s_addr = *((u_long *)hp->h_addr);
servername.sin_port = 1024;
.
.
.
rc = connect(s,(struct sockaddr *)&servername,sizeof(servername));
An Application Uses the gethostbyname() Call shows an example of a network
utility routine, gethostbyname() call, to find out the internet address of
serverhost from the name server or the \ETC\HOSTS file.
6. Servers using stream sockets accept a connection request with the accept()
call, as shown in the example in An Application Uses the accept() Call.
An Application Uses the accept() Call
int clientsocket;
int s;
struct sockaddr clientaddress;
int addrlen;
int accept(int s, struct sockaddr *addr, int *addrlen);
.
.
.
addrlen = sizeof(clientaddress);
.
.
.
clientsocket = accept(s, &clientaddress, &addrlen);
If connection requests are not pending on socket s, the accept() call
optionally blocks the server. When a connection request is accepted on
socket s, the name of the client and length of the client name are
returned, along with a new socket descriptor. The new socket descriptor is
associated with the client that initiated the connection and s is again
available to accept new connections. For a more detailed description,
seeaccept().
7. Clients and servers have many calls from which to choose for data transfer.
The readv() and writev(), and send() and recv() calls can be used only on
sockets that are in the connected state. The sendto() and recvfrom() calls
can be used at any time. The example in An Application Uses the send() and
recv() Calls illustrates the use of send() and recv().
An Application Uses the send() and recv() Calls
int bytes_sent;
int bytes_received;
char data_sentН256┘;
char data_receivedН256┘;
int send(int socket, char *buf, int buflen, int flags);
int recv(int socket, char *buf, int buflen, int flags);
int s;
.
.
.
bytes_sent = send(s, data_sent, sizeof(data_sent), 0);
.
.
.
bytes_received = recv(s, data_received, sizeof(data_received), 0);
The example in An Application Uses the send() and recv() Calls 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. See readv(), recv(),
send(), and writev() for more information about these routines.
8. If the socket is not in a connected state, additional address information
must be passed to sendto() and may be optionally returned from recvfrom().
An example of the use of the sendto() and recvfrom() calls is shown in An
Application Uses the sendto() and recvfrom() Call.
An Application Uses the sendto() and recvfrom() Call
int bytes_sent;
int bytes_received;
char data_sentН256┘;
char data_receivedН256┘;
struct sockaddr_in to;
struct sockaddr from;
int addrlen;
int sendto(int socket, char *buf, int buflen, int flags,
struct sockaddr *addr, int addrlen);
int recvfrom(int socket, char *buf, int buflen, int flags,
struct sockaddr *addr, int *addrlen);
int s;
.
.
.
to.sin_family = AF_INET;
to.sin_addr = inet_addr("129.5.24.1");
to.sin_port = htons(1024);
.
.
.
bytes_sent = sendto(s, data_sent, sizeof(data_sent), 0, &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. Usually, sendto() and recvfrom() are used for
datagram sockets, and send() and recv() are used for stream sockets.
9. The writev(), and readv() calls provide the additional features of scatter
and gather data. Scattered data can be located in multiple data buffers.
The writev() call gathers the scattered data and sends it. The readv() call
receives data and scatters it into multiple buffers.
10. Applications can handle multiple sockets. In such situations, 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
exceptional conditions. An example of how the BSD version select() call is
used is shown in An Application Uses the BSD Version select() Call.
An Application Uses the BSD Version select() Call
#define BSD_SELECT
fd_set readsocks;
fd_set writesocks;
fd_set exceptsocks;
struct timeval timeout;
int number_of_sockets;
int number_found;
.
.
.
/* set bits in read write except bit masks. To set mask for a descriptor s use
* readsocks |= fd_set(s);
*
* set number of sockets to be checked
* number_of_sockets = x;
*/
.
.
.
number_found = select(number_of_sockets,
&readsocks, &writesocks, &exceptsocks, &timeout);
In this example, the application sets bit masks to indicate the sockets
being tested for certain conditions and also indicates a time-out. If the
time-out parameter is NULL, the call does not wait for any socket to become
ready on these conditions. If the time-out parameter is nonzero, select()
waits up to this amount of time 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. For a more detailed description, see BSD Version.
11. In addition to select(), applications can use the ioctl() call to help
perform asynchronous (nonblocking) socket operations. An example of the
use of the ioctl() call is shown in An Application Uses the ioctl() Call.
An Application Uses the ioctl() Call
int s;
int dontblock;
char bufН256┘;
int rc;
int ioctl(int s, unsigned long command, char *command_data, int datasize);
.
.
.
dontblock = 1;
.
.
.
rc = ioctl(s, FIONBIO, (char *) &dontblock, sizeof(dontblock));
.
.
.
if (recv(s, buf, sizeof(buf), 0) == -1 && errno == EWOULDBLOCK)
/* no data available */
else
/* either got data or some other error occurred */
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, seeioctl().
12. A socket descriptor, s, is deallocated with the soclose() call. For a more
detailed description, see soclose(). An example of the soclose() call is
shown in An Application Uses the soclose() Call.
An Application Uses the soclose() Call
.
.
.
/* close the socket */
soclose(s);
.
.
.
ΓòÉΓòÉΓòÉ 5.1.3.1. A Typical Stream or Sequence Packet Socket Session ΓòÉΓòÉΓòÉ
You can use TCP sockets for both passive (server) and active (client)
processes. While some commands are necessary for both types, some are
role-specific. See Sample Socket Programs, for sample C socket communication
client and server programs.
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
Socket/MPTS.
See A Typical Socket Session for the general sequence of calls to be followed
for most socket routines using TCP sockets.
ΓòÉΓòÉΓòÉ 5.1.3.2. A Typical Datagram Socket Session ΓòÉΓòÉΓòÉ
UDP socket processes, unlike TCP socket processes, are not clearly
distinguished by server and client roles. Instead, the distinction is between
connected and unconnected sockets. An unconnected socket can be used to
communicate with any host; but a connected socket, because it has a dedicated
destination, can send data to, and receive data from, only one host.
Both connected and unconnected sockets send their data over the network without
verification. Consequently, after a packet has been accepted by the UDP
interface, the arrival of the packet and the integrity of the packet cannot be
guaranteed.
See A Typical UDP Socket Session for the general sequence of calls to be
followed for most socket routines using UDP sockets.
CLIENT SERVER
┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ ┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ
В В В В
В Create stream socket s with the socket() В В Create stream socket s with the socket() В
В call. В В call. В
В В В В
БББББББББББББББББББББББББББББББББББББББББББББББББД БББББББББББББББББББББББББББББББББББББББББББББББББД
В В
┤Б ББ ББ ББ ББ ББ ББ ББ Б╔Б ББ ББ ББ ББ ББ ББ БББЖ ┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
(optional) В В
Bind socket s to a local address with the В Bind socket s to a local address with the В
bind() call. В bind() call. В
В В
Б ББ ББ ББ ББ ББ ББ ББ БСБ ББ ББ ББ ББ ББ ББ БББД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
В ┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
В В В
В В With the listen() call, alert the В
В В machine of your willingness to accept В
В В connections. В
В ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ В
В В В
В Connect socket s to a foreign host with the В В
В connect() call. В В
В В В
ББББББББББББББББББББББББСББББББББББББББББББББББББД В
В В
В ┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
В В Accept the connection and receive a second В
В В socket, for example ns, with the accept() В
В В call. В
В В В
В ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
В For the server, socket s remains available В
В to accept new connections. Socket ns В
В is dedicated to the client. В
В В
В В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ ┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
В Read and write data on socket s, using the В В Read and write data on socket ns, using the В
В send() and recv() calls, until all data has В БББББВ send() and recv() calls, until all data has В
В been exchanged. В ББББ В been exchanged. В
В В В В
ББББББББББББББББББББББББСББББББББББББББББББББББББД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ ┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
В В В В
В Close socket s and end the session В | Close socket ns with the soclose() call. В
В with the soclose() call. В В В
В В В В
БББББББББББББББББББББББББББББББББББББББББББББББББД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ
В Accept another connection from a client, or В
В close the original socket s with the soclose() В
В call. В
В В
БББББББББББББББББББББББББББББББББББББББББББББББББД
A Typical Socket Session
CLIENT SERVER
┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ ┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ
В В В В
В Create datagram socket s with the socket() В В Create datagram socket s with the socket() В
В call. В В call. В
В В В В
ББББББББББББББББББББББББСББББББББББББББББББББББББД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
┤Б ББ ББ ББ ББ ББ ББ ББ Б╔Б ББ ББ ББ ББ ББ ББ ББ БЖ ┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ
(optional) В В
Bind socket s to a local address with the В Bind socket s to a local address with the В
bind() call. В bind() call. В
В В
Б ББ ББ ББ ББ ББ ББ ББ БСБ ББ ББ ББ ББ ББ ББ ББ БД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
┤Б ББ ББ ББ ББ ББ ББ ББ Б╔Б ББ ББ ББ ББ ББ ББ ББ БЖ ┤Б ББ ББ ББ ББ ББ ББ ББ Б╔Б ББ ББ ББ ББ ББ ББ ББ БЖ
(optional) (optional)
Connect socket s using the connect() call to Connect socket s using the connect() call to
associate s with the server address. associate s with the client address.
Б ББ ББ ББ ББ ББ ББ ББ БСБ ББ ББ ББ ББ ББ ББ ББ БД Б ББ ББ ББ ББ ББ ББ ББ БСБ ББ ББ ББ ББ ББ ББ ББ БД
В В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ ┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Send and receive data on socket s, using the В В Send and receive data on socket s, using the В
В sendto() and recvfrom() calls, until all data В ББББББВ sendto() and recvfrom() calls, until all data В
В has been exchanged. Use the send() and recv() ВББББББ В has been exchanged. Use the send() and recv() В
В calls if connect() was called. В В calls if connect() was called. В
ББББББББББББББББББББББББСББББББББББББББББББББББББД ББББББББББББББББББББББББСББББББББББББББББББББББББД
В В
┤ББББББББББББББББББББББББ╔ББББББББББББББББББББББББЖ ┤БББББББББББББББББББББББББББББББББББББББББББББББББЖ
В В В В
В Close socket s and end the session with the В В Close socket s and end the session with the В
В soclose() call. В В soclose() call. В
В В В В
БББББББББББББББББББББББББББББББББББББББББББББББББД БББББББББББББББББББББББББББББББББББББББББББББББББД
A Typical UDP Socket Session
ΓòÉΓòÉΓòÉ 5.1.3.3. TCP/IP Specific Network Utility Routines ΓòÉΓòÉΓòÉ
The OS/2 socket API also provides a set of network utility routines to perform
useful tasks such as internet address translation, domain name resolution,
network-byte order translation, and access to the database of useful network
information. Network utility routines are discribed in the following pages.
Host Names Information
The following is a list of host calls.
o gethostbyname()
o gethostbyaddr()
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 <NETDB.H> 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.
Because of the differences in the databases and their access protocols, the
information returned can differ.
Network-Byte Order Translation
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)
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.
ΓòÉΓòÉΓòÉ 5.2. Porting a Socket API Application ΓòÉΓòÉΓòÉ
The IBM OS/2 socket implementation differs from the Berkeley socket
implementation as follows:
o 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.
o Some socket calls require that you call the sock_init() routine before you
call them. Therefore, always call sock_init() at the beginning of programs
using the socket interface.
o Error codes set by the MPTS sockets implementation are not made available
through the global errno variable. Instead, error codes are accessed by using
the sock_errno() API described on page 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. It is not possible for an application to assign new values
to error codes.
This is intended to obtain per-thread error codes in a multithreaded
application environment and to avoid conflict with standard IBM C Set/2 V1.0
error constants.
For compatibility with BSD, an application can choose to define:
#define errno sock_errno()
#define perror psock_errno()
If a source file includes code that checks errno for both OS/2 socket and
OS/2 nonsocket functions, this mechanism cannot be used.
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. Refer to System Return Codes, or the <NERRNO.H> file for
definitions of error constants.
o The select() call has a different interface. 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.
o ioctl() implementation might differ from the current Berkeley ioctl()
implementation. For example, IBM has added a lendata parameter, which the
current Berkeley ioctl() implementation does not support. Other functions of
the IBM ioctl() call might also differ from the current Berkeley ioctl()
implementation. In addition, the getsockopt() and setsockopt() might provide
different support. See ioctl(), getsockopt(), and setsockopt() for more
information.
You must define the variable OS2 by doing one of the following:
o Place #define OS2 at the top of each file that includes MPTS header files.
o Use the /DOS2 option when compiling the source for your application.
For a summary of each socket call supported by MPTS, see Socket Quick
Reference.
ΓòÉΓòÉΓòÉ 5.3. C Socket Calls ΓòÉΓòÉΓòÉ
This section provides the syntax, parameters, and other appropriate information
for each C socket call supported by MPTS.
If you are uing TCP/IP protocol or non-native INET over NetBIOS, you can make
all these socket calls. However, if you are using sockets to access the NetBIOS
protocol natively, then you can only use the calls that are in the
protocol-independent set.
The following is a list of the protocol-independent socket calls that can be
used to access services for all protocols:
accept()
bind()
connect()
getpeername()
getsockname()
getsockopt()
ioctl()
listen()
psock_errno()
readv()
recv()
recvfrom()
recvmsg()
select()
send()
sendmsg()
sendto()
setsockopt()
shutdown()
sock_errno ()
sock_init()
socket()
soclose()
writev()
The following is a list of the protocol-dependent socket calls that can be used
to access services related to the TCP/IP protocol:
bswap()
dn_comp()
dn_expand()
endhostent()
endnetent()
endprotoent()
endservent()
gethostbyaddr()
gethostbyname()
gethostent()
gethostid()
gethostname()
getnetbyaddr()
getnetbyname()
getnetent()
getprotobyname()
getprotobynumber()
getprotoent()
getservbyname()
getservbyport()
getservent()
htonl()
htons()
inet_addr()
inet_inaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
lswap()
ntohl()
ntohs()
res_init()
res_mkquery()
res_send()
sethostent()
setnotent()
setprotoent()
setservent()
ΓòÉΓòÉΓòÉ 5.4. Protocol-Independent Socket Calls ΓòÉΓòÉΓòÉ
The protocol-independent socket calls that can be used to access services for
all protocols are described in the following text.
ΓòÉΓòÉΓòÉ 5.4.1. accept() ΓòÉΓòÉΓòÉ
# include< types . h >
#include <sys\socket.h>
#include <netinet\in.h>
#include <netnb\nb.h>
#include <sys\un.h>
int accept(s, name, namelen)
int s;
union {
short sa_family;
struct sockaddr_un *name1;
struct sockaddr_nb *name2;
struct sockaddr_in *name3;
} name;
int *namelen;
Parameter Description
s The socket descriptor
name The socket address of the connecting client that is filled by
accept() before it returns. The format of name is determined by
the 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: The accept() call is used by a server to accept a connection
request from a client. The call accepts the first connection on its queue of
pending connections. The accept() call creates a new socket descriptor with the
same properties as s and returns it to the caller. 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 -1 and sets the return code to SOCEWOULDBLOCK. The new socket
descriptor cannot be used to accept new connections. The original socket, s,
remains available to accept more connection requests.
Use the select() call to accept multiple incoming connections on different
sockets. For more information, refer to select().
The s parameter must be a stream socket descriptor created with the socket()
call. It is usually bound to an address with the bind() call and is 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 addressing domain where the
communication request originated. For example, if the connection request
originated in the AF_INET domain, name points to a sockaddr_in structure as
defined in the header file <NETINET\IN.H>. 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.
Non-Native Networking: See "Non-Native Networking" for MPTN connectivities
provided. The accept() call in MPTN environment can accept an inbound
connection request from any of the locally connected native or nonnative
networks.
Return Value and Errno Value: A non-negative socket descriptor indicates
success; the value -1 indicates an error. Specific error values are obtained by
calling sock_errno() or psock_(). tsize=15.
Errno Value 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.
SOCEINVAL Listen() was not called for socket s.
SOCENOBUFS Insufficient buffer space available to create the new
socket.
SOCEOPNOTSUPP The s parameter is not of type SOCK_STREAM.
SOCEWOULDBLOCK The s parameter is in nonblocking mode and no
connections are on the queue.
SOCECONNABORTED The software caused a connection abort.
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);
/* 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() */
addrlen = 0;
clientsocket = accept(s, (struct sockaddr *) 0, (int *) 0);
See Also: bind(), connect(), getpeername(), listen(), and socket().
ΓòÉΓòÉΓòÉ 5.4.2. bind() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int bind(s, name, namelen)
int s;
struct sockaddr *name;
int namelen;
Parameter Description
s The socket descriptor returned by a previous socket() call
name Points to a sockaddr structure containing the name that is to be
bound to s
namelen The size of name in bytes
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 s parameter is a socket descriptor of any type created by calling socket().
The name parameter is a pointer to a buffer containing the name to be bound to
s. The namelen parameter is the size, in bytes, of the buffer pointed to by
name.
The format of name is determined by the domain where communication occurs.
This parameter can be NULL if the caller is not interested in its own address.
In local socket, the domain is AF_OS2 (or AF_UN) and the address structure is
defined in <sys\un.h>. If the address is NULL, the bind call binds to a unique
local address to the socket descriptor s. Each name is a combination of
address family (AF_UNIX in local socket) and a character string no longer than
108 characters. The file/path name character string should be prefixed with the
string \SOCKET\.... followed by any character string terminated by the ASCII 0.
Each socket must use a unique character string as its local name.
struct sockaddr_un {
short sun_family; /* AF_OS2 (AF_UNIX) */
char sun_pathН108┘; /* path name */
}
For the NetBIOS domain (AF_NETBIOS), the address structure is defined in
<netnb\nb.h>. The address type field is used to specify the name as either a
unique (NB_UNIQUE) or a group (NB_GROUP) name. The leftmost character in the
netid field is used to select the LAN adapter number. It can be a binary
number or an ASCII digit, thus 0X01 and '1' bit are resolved to adapter 1. For
convenience, an ASCII space is also accepted as 0. The name field contains the
16-byte NetBIOS name, and is used as is.
struct sockaddr_nb {
short snb_family; /* AF_NETBIOS */
short snb_type; /* address type*/
char snb_netidН8┘; /* netid */
char snb_nameН16┘; /* name */
}
If a connect() socket call is received without an explicit bind(), an implicit
bind is automatically performed. In this case, the application does not care
about its own name and is asking the system to select one for it. A NetBIOS
name is generated for this socket by converting the 6-byte MAC address to an
ASCII hex string, prepended with NB, and postpended with a 2-byte number that
increments after each use.
Note that for the NetBIOS domain AF_NETBIOS (and protocols that support
parallel connection such as SNA or OSI), more than one socket can be bound to
the same local name/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().
For the INET domain (AF_INET), the address structure is defined in
<netinet\in.h>. The sin_port field is set to the port the application must
bind to. It must be specified in network-byte order. If the 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 it is to bind to.
Subsequently, only UDP packets and TCP connection requests from this interface
that match the bound name are routed to the application. If this field is set
to the constant INADDR_ANY, as defined in <netinet\in.h>, the caller is
requesting that the socket be bound to all network interfaces on the host.
Subsequently, UDP packets and TCP connections from all interfaces that match
the bound name are routed to the application. This becomes important when a
server offers a service to multiple networks. By leaving the address
unspecified, the server can accept all UDP packets and TCP connection requests
made for its port, regardless of the network interface where the requests
arrived. The sin_zero field is not used and must be set to all zeros as shown
in the following example.
struct sockaddr_in {
short sin_family; /* AF_INET */
u_short sin_port; /* port id */
struct in_addr sin_addr; /* address */
char sin_zeroН8┘
}
For DIRECT mode user (AF_DIRECT), the address family for the local name can be
any of the network address types except AF_OS2 (local).
Non-Native Networking: See "Non-Native Networking" for MPTN connectivities
provided.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specific error values are obtained by calling sock_errno()
or psock_().
Errno Value Description
SOCEADDRINUSE The address is already in use.
SOCEADDRNOTAVAIL The address specified is not valid on this host.
For example, if the internet address does not
specify a valid network interface or if the LIPC
prefix \Socket\ is missing.
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. For
example, trying to bind a name to a socket that is
in the connected state. This value is also returned
if namelen is not the expected length.
SOCENOBUFS No buffer space is available.
Examples: The following are examples of the bind() call. Several things
should be noted about the examples. The internet address and port must be in
network-byte order. To put the port into network-byte order, a utility routine,
htons(), is called to convert a short integer from host-byte order to
network-byte order. The address field is set using another utility routine,
inet_addr(), which takes a character string representing the dotted decimal
address of an interface and returns the binary internet address representation
in network-byte order. Finally, note that it is a good idea to 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);
/* Bind to a specific interface in the internet domain */
/* make sure the sin_zero field is cleared */
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 network interfaces in the internet domain */
/* make sure the sin_zero field is cleared */
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 */
/* make sure the sin_zero field is cleared */
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));
The binding of a stream socket is not complete until a successful call to
bind(), listen(), or connect() is made. Applications using stream sockets
should check the return values of bind(), listen(), and connect() before using
any function that requires a bound stream socket.
See Also: connect(), gethostbyname(), getsockname(), htons(), inet_addr(),
listen(), and socket().
ΓòÉΓòÉΓòÉ 5.4.3. connect() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int connect(s, name, namelen)
int s;
struct sockaddr *name;
int namelen;
Parameter Description
s The socket descriptor
name The pointer to a socket address structure containing the address
of the socket to which a connection will be attempted
namelen The size of the socket address pointed to by name in bytes
Description: For stream or sequenced_packet sockets, the connect() call
attempts to establish a connection between two sockets. For datagram sockets,
the connect() call specifies the peer for a socket. The s parameter is the
socket used to originate the connection request. The connect() socket call
performs two tasks when called for a stream or sequenced_packet socket: 1) it
completes the binding necessary for a socket, and 2) it attempts to create a
connection with a foreign socket.
The connect() call for a stream socket or a sequenced_packet socket is used by
the client side of socket-based applications to establish a connection with a
server. The server must have a passive open pending. If the server is using
sockets, this means the server must successfully call bind() and listen()
before a connection can be accepted by the server with accept(). Otherwise,
the connection returns -1 and the error value is set to SOECONNREFUSED.
If s is in blocking mode, the connect() call blocks the caller until connection
is set up or until an error is received. If the socket is in nonblocking mode,
connect() returns -1 and sets the error value to SOCEINPROGRESS if the
connection can be initiated (no other errors occurred). The caller can test
the completion of the connection setup by calling select() and testing for the
ability to write to the socket.
When called for a datagram or raw socket, connect() specifies the peer with
which this socket is associated. This gives the application the ability to use
data transfer calls reserved for sockets that are in the connected state. In
this case, readv(), writev(), send(), recv() are then available in addition to
sendto(), recvfrom(), sendmsg(), and recvmsg(). Stream or sequenced_packet
sockets can call connect() only once, but datagram sockets can call connect()
multiple times to change their association. Datagram sockets can dissolve
their association by connecting to an invalid address such as the null address
(all fields zeroed).
The name parameter is a pointer to a buffer containing the name of the peer to
which the application needs to connect. The namelen parameter is the size, in
bytes, of the buffer pointed to by name.
See bind() for the format of the name field.
Non-Native Networking: See "Non-Native Networking" for MPTN connectivities
provided. The connect() call attempts to locate the remote destination using
any of the locally connected native and non-native networks. The search order
is based on the configuration setup and a cache with information of the remote
destinations saved from previous locate calls.
For other address format, see the description of bind().
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specific error values are obtained by calling sock_errno()
or psock_().
Errno Value 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.
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
EINPROGRESS value does not indicate an error
condition.
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.
ΓòÉΓòÉΓòÉ 5.4.4. getpeername() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int getpeername(s, name, namelen)
int s;
struct sockaddr *name;
int *namelen;
Parameter Description
s The socket descriptor.
name The internet address of the connected socket that is filled by
getpeername() before it returns. The exact format of name is
determined by the domain where communication occurs.
namelen The size of the address structure pointed to by name in bytes.
Description: The getpeername() 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 and is set to the number of bytes copied into the
space before the call returns. The size of the peer name is returned in bytes.
If the buffer of the local host is too small, the peer name is truncated.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specific error values are obtained by calling sock_errno()
or psock_().
Errno Value 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 in the connected state.
SOCENOBUFS No buffer space is available.
See Also: accept(), connect(), getsockname(), and socket().
ΓòÉΓòÉΓòÉ 5.4.5. getsockname() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int getsockname(s, name, namelen)
int s;
struct sockaddr *name;
int *namelen;
Parameter Description
s The socket descriptor.
name The address of the buffer getsockname() copies the name of s
into.
namelen Must initially point to an integer that contains the size in
bytes of the storage pointed to by name. Upon return, that
integer contains the size of the data returned in the storage
pointed to by name.
Description: The getsockname() call stores the current name for the socket
specified by the s parameter into 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 inbound 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.
Stream or sequenced_packet sockets are not assigned a name, until after a
successful call to either bind(), connect(), or accept().
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. This assignment can be discovered with a call to getsockname().
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. The value of errno indicates the specific error.
Errno Value 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.
See Also: accept(), bind(), connect(), getpeername(), and socket().
ΓòÉΓòÉΓòÉ 5.4.6. getsockopt() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int getsockopt(s, level, optname, optval, optlen)
int s;
int level;
int optname;
char *optval;
int *optlen;
Parameter Description
s The socket descriptor.
level The level the option is set for. Only SOL_SOCKET is supported.
optname The name of a specified socket option.
optval Points to option data.
optlen Points to the length of the option data.
Description: The getsockopt() call returns the values of socket options at
various protocol levels. It can be called for sockets of all AF domain types.
Some options are supported only for specific address families and/or network
protocols installed with TCP/IP.
When manipulating socket options, you must specify the level where the option
resides and the name of the option. To manipulate options at the socket level,
the level parameter must be set to SOL_SOCKET, as defined in <sys\socket.h>. To
manipulate protocol-specific options at any other level, such as the TCP
(IPROTO_TCP) or IP(IPROTO_IP) supply the appropriate protocol number for the
installed protocol controlling the option. For example, The getprotobyname()
call from the TCP/IP product can be used to return the protocol number for a
named protocol in TCP/IP. Currently, only the SOL_SOCKET level is supported.
The optval and optlen parameters are used to return data used by the particular
get command. The optval parameter points to a buffer that is to receive the
data requested by the get command. The optlen parameter points to the size of
the buffer pointed to by the optval parameter. 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.
All of the socket level options except SO_LINGER, SO_SNDBUF, and SO_RCVBUF
expect optval to point to an integer and optlen to be set to the size of an
integer. When the integer is nonzero, the option is enabled. When it is zero,
the option is disabled. The SO_LINGER option expects optval to point to a
linger structure, as defined in <SYS\SOCKET.H>. The SO_SNDBUF and SO_RCVBUF
options expect optval to point to a long. This structure is defined in the
following example:
struct linger
{
int l_onoff; /* option on/off */
int 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 to linger on close.
The following options are recognized at the socket level:
Option Description
SO_BROADCAST Toggles the ability to broadcast messages. If this option
is enabled, it allows the application to send broadcast
messages over s, if the interface specified in the
destination supports broadcasting of packets. This option
has no meaning for stream or sequenced_packet sockets.
SO_DEBUG Toggles recording of debugging information.
SO_DONTROUTE Toggles the routing bypass for 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 this host has an interface for). This option
has no meaning for stream sockets.
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 Toggles keep 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. If this option is toggled, a
keepalive packet is periodically sent to the peer. This
is used mainly to allow servers to close connections that
have already disappeared as a result of clients going
away without closing connections. This option has meaning
only for stream sockets.
SO_LINGER Lingers 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. If this option is disabled,
INET waits to try to send the data. Although the data
transfer is usually successful, it cannot be guaranteed,
because INET waits only a finite amount of time trying to
send the data. The soclose() call returns without
blocking the caller. This option has meaning only for
stream or sequenced_packet sockets.
SO_OOBINLINE Toggles reception of out-of-band data. 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. This
option has meaning only for stream sockets.
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.
SO_RCVLOWAT Retrieves receive low-water mark information.
SO_RCVTIMEO Retrieves receive timeout information.
SO_REUSEADDR Toggles local address reuse. When enabled, this option
allows local addresses that are already in use to 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 EADDRINUSE is returned if the
association already exists.
SO_SNDBUF Sets buffer size for output. 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.
SO_SNDLOWAT Retrieves send low-water mark information.
SO_SNDTIMEO Retrieves send timeout information.
SO_TYPE Returns the type of the socket. On return, the integer
pointed to by optval is set to one of the following:
SOCK_STREAM, SOCK_SEQPACKET, SOCK_DGRAM, or SOCK_RAW.
SO_USELOOPBACK Bypasses hardware when possible.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
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 results in an
attempt to access memory outside the caller's address
space.
SOCENOPROTOOPT The optname parameter is unrecognized, or the level
parameter is not SOL_SOCKET.
Examples: The following are examples of the getsockopt() call. See
setsockopt() for examples of how the setsockopt() call options are set.
int rc;
int s;
int optval;
int optlen;
struct linger l;
int getsockopt(int s, int level, int optname, char *optval, int *optlen);
.
.
.
/* 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(l);
rc = getsockopt(
s, SOL_SOCKET, SO_LINGER, (char *) &l, &optlen);
if (rc == 0)
{
if (optlen == sizeof(l))
{
if (l.l_onoff)
/* yes I linger */
else
/* no I do not */
}
}
See Also: getprotobyname(), setsockopt(), and socket().
ΓòÉΓòÉΓòÉ 5.4.7. ioctl() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
#include <sys\ioctl.h>
#include <net\route.h>
#include <net\if.h>
int ioctl(s, cmd, data, lendata)
int s;
int cmd;
caddr_t data;
int lendata;
Parameter Description
s The socket descriptor
cmd The command to perform
data A pointer to the data associated with cmd
lendata The length of the data in bytes
Description: The operating characteristics of sockets can be controlled with
ioctl() requests. The operations to be controlled are determined by cmd. The
data parameter is a pointer to data associated with the particular command, and
its format depends on the command that is requested. In the following
descriptions, (AF_INET on TCP/IP) indicates that this option applies to INET
native networking only. (AF_INET) indicates that this option applies to INET
native networking and INET over non-native NetBIOS LAN. The following are valid
ioctl() commands:
Option Description
FIOASYNC Sets or clears asynchronous input-output for a socket.
data is a pointer to an integer. If the integer is 0,
asynchronous input-output on the socket is cleared.
Otherwise, the socket is set for asynchronous
input-output.
FIONBIO Sets or clears nonblocking input-output for a socket. 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.
SIOCADDRT (AF_INET on TCP/IP) Adds a routing table entry. data is a
pointer to a rtentry structure, as defined in
<NET\ROUTE.H>. The routing table entry, passed as an
argument, is added to the routing tables.
SIOCATMARK Queries whether the current location in the data input is
pointing to out-of-band data. The data parameter 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 (AF_INET on TCP/IP) Deletes an arp table entry. data is a
pointer to a arpreq as defined in <NET\IF_ARP.H>. The arp
table entry passed as an argument is deleted from the arp
tables, if it exists.
SIOCDELRT (AF_INET on TCP/IP) Deletes a routing table entry. data
is a pointer to a rtentry structure, as defined in
<NET\ROUTE.H>. If it exists, the routing table entry
passed as an argument is deleted from the routing tables.
SIOCGARP (AF_INET on TCP/IP) Get the arp table entries. data is a
pointer to an arpreq, as defined in <NET\IF_ARP.H>. The
arp table entry passed as an argument is returned from the
arp tables if it exists.
SIOCGIFADDR (AF_INET) Gets the network interface address. The data
parameter is a pointer to an ifreq structure, as defined
in <NET\IF.H>. The interface address is returned in the
argument.
SIOCGIFBRDADDR (AF_INET) Gets the network interface broadcast address.
The data parameter is a pointer to an ifreq structure, as
defined in <NET\IF.H>. The interface broadcast address is
returned in the argument.
SIOCGIFCONF (AF_INET) Gets the network interface configuration. The
data parameter is a pointer to an ifconf structure, as
defined in <NET\IF.H>. The interface configuration is
returned in the argument.
SIOCGIFDSTADDR (AF_INET on TCP/IP) Gets the network interface destination
address. The data parameter is a pointer to an ifreq
structure, as defined in <NET\IF.H>. The interface
destination (point-to-point) address is returned in the
argument.
SIOCGIFFLAGS (AF_INET) Gets the network interface flags. The data
parameter is a pointer to an ifreq structure, as defined
in <NET\IF.H>. The interface flags are returned in the
argument.
SIOCGIFMETRIC (AF_INET on TCP/IP) Gets the network interface routing
metric. The data parameter is a pointer to an ifreq
structure, as defined in <NET\IF.H>. The interface routing
metric is returned in the argument.
SIOCGIFNETMASK (AF_INET) Gets the network interface network mask. The
data parameter is a pointer to an ifreq structure, as
defined in <NET\IF.H>. The interface network mask is
returned in the argument.
SIOCSARP (AF_INET on TCP/IP) Sets an arp table entry. The data
parameter is a pointer to an arpreq as defined in
<NET\IF_ARP.H>. The arp table entry passed as an argument
is added to the arp tables.
SIOCSIFADDR (AF_INET on TCP/IP) Sets the network interface address.
The data parameter is a pointer to an ifreq structure, as
defined in <NET\IF.H>. Set the interface address to the
value passed in the argument.
SIOCSIFBRDADDR (AF_INET on TCP/IP) Sets the network interface broadcast
address. The data parameter is a pointer to an ifreq
structure, as defined in <NET\IF.H>. Set the interface
broadcast address to the value passed in the argument.
SIOCSIFDSTADDR (AF_INET on TCP/IP) Sets the network interface destination
address. The data parameter is a pointer to an ifreq
structure, as defined in <NET\IF.H>. Set the interface
destination (point-to-point) address to the value passed
in the argument.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
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.
Example: The following is an example of the ioctl() call.
int s;
int dontblock;
int rc;
.
.
.
/* Place the socket into nonblocking mode */
dontblock = 1;
rc = ioctl(s, FIONBIO, (char *) &dontblock, sizeof(dontblock));
.
.
.
ΓòÉΓòÉΓòÉ 5.4.8. listen() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int listen(s, backlog)
int s;
int backlog;
Parameter Description
s The socket descriptor
backlog Defines the maximum length for the queue of pending connections
Description: The listen() call applies only to stream sockets. It performs two
tasks: it completes the binding necessary for a socket s, if bind() has not
been called for s, and it creates a connection request queue of length backlog
to queue incoming connection requests. When backlog 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 it is called, s
can never be used as an active socket to initiate connection requests. Calling
listen() is the third of four steps that a server performs to accept a
connection. Listen() is called after allocating a stream socket with socket()
and after binding a name to s with bind(). Listen() must be called before
calling accept().
If the backlog is less than 0, backlog is set to 0. If the backlog is greater
than SOMAXCONN, as defined in <SYS\SOCKET.H>, backlog is set to SOMAXCONN.
Non-Native Networking: See "Non-Native Networking" for the MPTN connectivities
provided. In the MPTN environment, the listen() call applies to all locally
connected native and non-native networks.
Return Value and Errno Values: The value 0 indicates success, the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
Errno Value 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.
See Also: accept(), bind(), connect(), and socket().
ΓòÉΓòÉΓòÉ 5.4.9. psock_errno() ΓòÉΓòÉΓòÉ
#include <nerrno.h>
void psock_errno(s)
char *s;
Parameter Description
s Pointer to a buffer
Description: Use psock_errno() to produce short error messages on 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 taken from calling sock_errno() call. The error code is set
when errors occur, but is not cleared when non-erroneous calls are made.
See Also: sock_errno().
ΓòÉΓòÉΓòÉ 5.4.10. readv() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int readv(s, iov, iovcnt)
int s;
struct iovec *iov;
int iovcnt;
Parameter Description
s The socket descriptor
iov A pointer to an array of iovec structure
iovcnt The number of buffers pointed to by the iov parameter
Description: The readv() 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 <SYS\SOCKET.H> and
contains the following fields:
Parameter Description
iov_base Points to the buffer
iov_len The length of the buffer
The readv() call applies only to connected sockets.
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.
Return Value and Errno Values: If successful, the number of bytes read into
the buffers is returned. The value -1 indicates an error. Specified error
values are obtained by calling sock_errno() or psock_errno().
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.
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.
See Also: connect(), getsockopt(), ioctl(), recv(), recvfrom(), select(),
send(), sendto(), setsockopt(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.11. recv() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int recv(s, buf, len, flags)
int s;
char *buf;
int len;
int flags;
Parameter Description
s The socket descriptor.
buf The pointer to the buffer that receives the data.
len The length in bytes of the buffer pointed to by the buf
parameter.
flags The flags parameter is set by specifying one or more of the
following flags. If more than one flag is specified, the logical
OR operator ( | ) must be used to separate them. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_OOB (AF_INET) 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.
Description: The recv() call receives data on a socket with descriptor s and
stores it in a buffer. The recv() call applies only to connected sockets.
This call returns the length of the incoming message or data. If a datagram
packet is too long to fit in the supplied buffer, datagram sockets discard
excess bytes. If data is not available at the socket with descriptor s, the
recv() 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 Value and Errno Values: If successful, the length, in bytes, of the
message or datagram is returned. The value 0 indicates that the connection is
closed. The value -1 indicates an error. Specified error values are obtained by
calling sock_errno() or psock_errno().
Errno Value 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 read.
SOCEINVAL Invalid argument.
See Also: connect(), getsockopt(), ioctl(), readv(), recvfrom(), select(),
send(), sendto(), setsockopt(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.12. recvfrom() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int recvfrom(s, buf, len, flags, name, namelen)
int s;
char *buf;
int len;
int flags;
struct sockaddr *name;
int *namelen;
Parameter Description
s The socket descriptor.
buf The pointer to the buffer that receives the data.
len The length in bytes of the buffer pointed to by the buf
parameter.
flags A parameter that can be set to 0 or MSG_PEEK. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_OOB (AF_INET) 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.
name A pointer to a socket address structure data is received from.
If name is a nonzero value, the source address is returned.
namelen The pointer to the size of name in bytes.
Description: The recvfrom() call receives data on a socket with descriptor s
and stores it in a buffer. The recvfrom() call applies to any datagram socket,
either connected or unconnected.
If name is nonzero, the source address of the message is filled. The namelen
parameter must first be initialized to the size of the buffer associated with
name and then modified on return to indicate the actual size of the address
stored there.
This call returns the length of the incoming message or data. If a datagram
packet is too long to fit in the supplied buffer, datagram sockets discard
excess bytes. If datagram packets are not available at the socket with
descriptor s, the recvfrom() 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 Value and Errno Values: If successful, the length, in bytes, of the
message or datagram is returned. The value -1 indicates an error. Specified
error values are obtained by calling sock_errno() or psock_errno().
Errno Value 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 read.
SOCEINVAL Invalid argument.
See Also: getsockopt(), ioctl(), readv(), recv(), select(), send(), sendto(),
setsockopt(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.13. recvmsg() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int recvmsg(s, msg, flags)
int s;
struct msghdr msgН┘;
int flags;
Parameter Description
s The socket descriptor.
msg An array of message headers where messages are received.
flags The flags parameter is set by specifying one or more of the
following flags. If more than one flag is specified, the logical
OR operator ( | ) must be used to separate them. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_OOB (AF_INET) 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.
Description: The recvmsg() call receives messages on a socket with descriptor
s and stores them in an array of message headers. A message header is defined
by a structure called msghdr. The definition of this structure can be found in
the <SYS\SOCKET.H> header file and contains the following elements:
Parameter Description
msg_name The optional pointer to the buffer containing the recipient
address
msg_namelen The size of the address buffer
msg_iov An array of iovec buffers containing the message
msg_iovlen The number of elements in the msg_iov array
msg_accrights The access rights received. This field is ignored.
msg_accrightslen The length of access rights received. This field is
ignored.
The recvmsg() call applies to sockets, regardless of whether or not they are in
the connected state.
This call returns the length of the data received. 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 Value and Errno Values: If successful, the length of the message in
bytes is returned. The value -1 indicates an error.
Errno Value 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.
SOCEWOULDBLOCK The s parameter is in nonblocking mode, and no data is
available to read.
See Also: connect(), getsockopt(), ioctl(), readv(), recv(), recvfrom(),
select(), send(), sendmsg(), sendto(), setsockopt(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.14. select() ΓòÉΓòÉΓòÉ
Socket/MPTN for OS/2 supports two versions of the select() call:
o OS/2 Version
o Berkeley Software Distributions (BSD) Version
ΓòÉΓòÉΓòÉ 5.4.14.1. OS/2 Version ΓòÉΓòÉΓòÉ
In the OS/2 version, 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. The OS/2 version monitors
the activity on a socket by specifying the number of sockets to be checked for
readability, readiness for writing, and exception pending conditions.
#include <types.h>
#include <sys\socket.h>
int select(s, noreads, nowrites, noexcepts, timeout)
int *s;
int noreads;
int nowrites;
int noexcepts;
long timeout;
Parameter Description
s An array of socket numbers where the read socket numbers are
followed by the write socket numbers, and also followed by the
exception socket numbers.
noreads The number of sockets to be checked for readability.
nowrites The number of sockets to be checked for readiness for writing.
noexcepts The number of sockets to be checked for exceptional pending
conditions.
timeout The maximum interval, in milliseconds, to wait for the selection
to complete.
Description: The select() call monitors activity on a set of different sockets
until a time-out expires, to see if any sockets are ready for reading or
writing, or if any exceptional conditions are pending.
If the time-out value is 0, select() does not wait before returning. If the
time-out value is -1, select() does not time out, but returns when a socket
becomes ready. The time-out value is in milliseconds.
The select() call checks all indicated sockets at the same time without
becoming blocked. See Porting a Socket API Application for information on how
the OS/2 implementation of the select() call differs from the Berkeley
implementation.
Return Value and Errno 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. Specified error values are obtained by calling sock_errno() or
psock_errno().
Errno Value Description
SOCENOTSOCK The s parameter is not a valid socket descriptor.
SOCEFAULT Bad address.
SOCEINVAL Invalid argument.
Examples: The following is an example of the 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Н┘; /* array of sockets */
long timeout = MAX_TIMEOUT;
/* put sockets to check in socksН┘ */
socksН0┘ = insock;
/* check for READ availability on this socket */
return select(socks, 1, 0, 0, timeout);
}
See Also: accept(), connect(), recv(), and send().
ΓòÉΓòÉΓòÉ 5.4.14.2. BSD Version ΓòÉΓòÉΓòÉ
The BSD version monitors the activity on sockets by specifying a set mask
(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 set mask.
Note: You must define #define BSD_SELECT to access the BSD version of the
select() call. Otherwise, the OS/2 version is assumed.
#define BSD_SELECT
#include <types.h>
#include <sys\select.h>
#include <sys\time.h>
int select(nfds, readfds, writefds, exceptfds, timeout)
int nfds;
fd_set *readfds;
fd_set *writefds;
fd_set *exceptfds;
struct timeval *timeout;
Parameter Description
nfds The highest socket descriptors to check plus 1
readfds Points to a bit mask of descriptors to check for reading
writefds Points to a bit mask of descriptors to check for writing
exceptfds Points to a bit mask of descriptors to be checked for
exceptional pending conditions
timeout Points to the time to wait for the select() call to complete
Description: The select() call monitors activity on a set of different sockets
until a time-out expires, to see if any sockets are ready for reading or
writing, or if any exceptional conditions are pending. The bit mask is made up
of an array of integers. Macros are provided to manipulate the bit masks.
Macro Description
FD_SET( socket, bit_mask_address) Sets the bit for the socket in the bit
mask pointed to by bit_mask_address.
FD_CLR( socket, bit_mask_address) Clears the bit.
FD_ISSET( socket, bit_mask_address) Returns true if the bit is set for this
socket descriptor; otherwise, it
returns false.
FD_ZERO( socket, bit_mask_address) Clears the entire bit mask for all
socket descriptors.
Note: For macros FD_SET, FD_CLR, and FD_ISSET, the parameters socket and
bit_mask_address should be defined in the following manner:
int socket;
struct fd_set *bit_mask_address, bit_mask_address;
The first nfds descriptors in each bit mask are tested for the specified
condition.
Socket descriptors are specified by setting bits in a bit mask. If time-out is
a NULL pointer, the call blocks indefinitely until one of the requested
conditions is satisfied. If time-out is non-NULL, it specifies the maximum time
to wait for the call to complete. To poll a set of sockets, the time-out
pointer should point to a zeroed timeval structure. The timeval structure is
defined in the <SYS\TIME.H> header file and contains the following fields:
Field Description
tv_sec The number of seconds
tv_usec The number of microseconds
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 Value and Errno Values: The total number of ready sockets (in all bit
masks) 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 bit mask that are ready are set to 1. All others are set to
0. Specified error values are obtained by calling sock_errno() or
psock_errno().
Errno Value Description
SOCENOTSOCK The s parameter is not a valid socket descriptor.
SOCEFAULT Bad address.
SOCEINVAL Invalid argument.
See Also: accept(), connect(), recv(), and send().
ΓòÉΓòÉΓòÉ 5.4.15. send() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int send(s, msg, len, flags)
int s;
char *msg;
int len;
int flags;
Parameter Description
s The socket descriptor.
msg Points to the buffer containing the message to transmit.
len The length of the message pointed to by the msg parameter.
flags The flags parameter is set by specifying one or more of the
following flags. If more than one flag is specified, the logical
OR operator (|) must be used to separate them. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_OOB (AF_INET) Sends out-of-band data on sockets that
support this notion. Only SOCK_STREAM sockets created
in the AF_INET address family support out-of-band data.
MSG_DONTROUTE (AF_INET on UDP) The SO_DONTROUTE option is turned on
for the duration of the operation. This is usually used
only by diagnostic or routing programs.
Description: The send() call sends packets on the socket with descriptor s.
The send() call applies to all connected sockets.
If buffer space is not available at the socket to hold the message to be
transmitted, the send() call normally blocks, unless the socket is placed in
nonblocking mode. See ioctl() for a description of how to set nonblocking mode.
The select() call can be used to determine when it is possible to send more
data.
Return Value and Errno Values: No indication of failure to deliver is implicit
in a send() routine. The value -1 indicates locally detected errors. Specified
error values are obtained by calling sock_errno() or psock_errno().
Errno Value 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 Invalid argument.
SOCENOBUFS No buffer space is available to send the message.
SOCEWOULDBLOCK The s parameter is in nonblocking mode and no data is
available to read.
See Also: connect(), getsockopt(), ioctl(), readv(), recv(), recvfrom(),
select(), sendto(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.16. sendmsg() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int sendmsg(s, msg, flags)
int s;
struct msghdr msgН┘;
int flags;
Parameter Description
s The socket descriptor.
msg An array of message headers where messages are received.
flags The flags parameter is set by specifying one or more of the
following flags. If more than one flag is specified, the logical
OR operator (|) must be used to separate them. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_OOB (AF_INET) Sends out-of-band data on the socket.
MSG_DONTROUTE (AF_INET on UDP) The SO_DONTROUTE option is turned on for
the duration of the operation. This is usually used only
by diagnostic or routing programs.
Description: The sendmsg() call sends messages on a socket with descriptor s
passed in an array of message headers. A message header is defined by a
structure called msghdr. The definition of this structure can be found in the
<SYS\SOCKET.H> header file and contains the following elements:
Parameter Description
msg_name The optional pointer to the buffer containing the
recipient address.
msg_namelen The size of the address buffer.
msg_iov An array of iovec buffers containing the message.
msg_iovlen The number of elements in the msg_iov array.
msg_accrights The access rights sent. This field is ignored.
msg_accrightslen The length of the access rights sent. This field is
ignored.
The sendmsg() call applies to sockets regardless of whether they are in the
connected state.
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 Value and Errno Values: If successful, the length of the message in
bytes is returned. The value -1 indicates an error. Specified error values are
obtained by calling sock_errno() or psock_errno().
Errno Value Description
SOCENOTSOCK The s parameter is not a valid socket descriptor.
SOCEFAULT Using msg results in an attempt to access memory outside
the caller's address space.
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.
The maximum message size is xxxx.
Note to reviewer
The message size is pending. See Don Woods
SOCENOBUFS No buffer space is available to send the message.
SOCEWOULDBLOCK The s parameter is in nonblocking mode, and no data is
available to read.
See Also: connect(), getsockopt(), ioctl(), readv(), recv(), recvfrom(),
recvmsg(), select(), send(), sendto(), setsockopt(), socket(), and writev().
ΓòÉΓòÉΓòÉ 5.4.17. sendto() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int sendto(s, msg, len, flags, to, tolen)
int s;
char *msg;
int len;
int flags;
struct sockaddr *to;
int tolen;
Parameter Description
s The socket descriptor.
msg The pointer to the buffer containing the message to transmit.
len The length of the message in the buffer pointed to by the msg
parameter.
flags A parameter that can be set to 0 or MSG_DONTROUTE. Setting this
parameter is supported only for sockets in the AF_INET domain.
MSG_DONTROUTE (AF_INET on UDP) The SO_DONTROUTE option is turned on
for the duration of the operation. This is usually used
only by diagnostic or routing programs.
to The address of the target.
tolen The size of the address pointed to by the to parameter.
Description: The sendto() call sends packets on the socket with descriptor s.
The sendto() call applies to any datagram socket, whether connected or
unconnected.
Non-Native Networking: See "Non-Native Networking" for the MPTN connectivities
provided. Before sending the data, the sendto() call attempts to locate the
remote destination through any of the locally connected native and non-native
networks. The search order is based on the configuration setup and a cache
with information of the remote destinations saved from previous locate calls.
Return Value and Errno Values: If successful, the number of characters sent is
returned. The value -1 indicates an error. Specified error values are obtained
by calling sock_errno() or psock_errno(). No indication of failure to deliver
is implied in the return value of this call when used with datagram sockets.
Errno Value 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.
SOCEMSGSIZE The message was too big to be sent as a single
datagram. The default and maximum is 8192.
SOCENOBUFS No buffer space is available to send the message.
SOCEWOULDBLOCK The s parameter is in nonblocking mode and no data
is available to read.
SOCENOTCONN Socket is not connected.
SOCEDESTADDRREQ Destination address required.
See Also: readv(), recv(), recvfrom(), send(), select(), socket(), and
writev().
ΓòÉΓòÉΓòÉ 5.4.18. setsockopt() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int setsockopt(s, level, optname, optval, optlen)
int s;
int level;
int optname;
char *optval;
int optlen;
Parameter Description
s The socket descriptor.
level The level the option is being set for. Only SOL_SOCKET is
supported.
optname The name of a specified socket option.
optval Points to option data.
optlen Specifies the length of the option data.
Description: The setsockopt() call sets options associated with a socket.
Options can exist at multiple protocol levels; they are always present at the
highest socket level.
When manipulating socket options, the level where the option resides and the
name of the option must be specified. To manipulate options at the socket
level, the level parameter must be set to SOL_SOCKET, as defined in
<SYS\SOCKET.H>. To manipulate options at any other level, such as the TCP or IP
level, supply the appropriate protocol number for the protocol controlling the
option. Currently, only the SOL_SOCKET level is supported.
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 can be set to the NULL
pointer, if data is not needed by the command. The optlen parameter must be set
to the size of the data pointed to by optval.
All of the socket level options except SO_LINGER expect optval to point to an
integer and optlen to be set to the size of an integer. When the integer is
nonzero, the option is enabled. When it is zero, the option is disabled. The
SO_LINGER option expects optval to point to a linger structure, as defined in
<SYS\SOCKET.H>. This structure is defined in the following example:
struct linger
{
int l_onoff; /* option on/off */
int 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 to linger on close. The units of l_linger are seconds.
The following options are recognized at the socket level:
Option Description
SO_BROADCAST Toggles the ability to broadcast messages. If this
option is enabled, it allows the application to send
broadcast messages over s, if the interface specified in
the destination supports broadcasting of packets. This
option has no meaning for stream sockets.
SO_DONTROUTE Toggles the routing bypass for 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). This option has no meaning for stream
sockets.
SO_KEEPALIVE Toggles keep 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. If this option is toggled, a
keepalive packet is periodically sent to the peer. This
is used mainly to allow servers to close connections
that have already disappeared as a result of clients
going away without closing connections. This option only
has meaning for stream sockets.
SO_LINGER Lingers 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. If this option is disabled,
INET waits to try to send the data. Although the data
transfer is usually successful, it cannot be guaranteed,
because INET waits only a finite amount of time trying
to send the data. The soclose() call returns without
blocking the caller. This option has meaning only for
stream sockets.
SO_OOBINLINE Toggles the reception of out-of-band data. 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. This
option has meaning only for stream sockets.
SO_DEBUG Toggles recording or debugging information.
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 high-volume connections.
SO_RCVLOWAT Sets receive low-water mark.
SO_RCVTIMEO Sets receive timeout.
SO_REUSEADDR Toggles local address reuse. When enabled, this option
allows local addresses that are already in use to 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 EADDRINUSE is
returned if the association already exists.
SO_SNDBUF Sets buffer size for output. 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.
SO_SNDLOWAT Sets send low-water mark.
SO_SNDTIMEO Sets send timeout.
SO_USELOOPBACK Bypasses when possible.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
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, or the level
parameter is not SOL_SOCKET.
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 getsockopt() options set are queried.
int rc;
int s;
int optval;
struct linger l;
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 */
l.l_onoff = 1;
l.l_linger = 100;
rc = setsockopt(s, SOL_SOCKET, SO_LINGER, (char *) &l, sizeof(l));
See Also: getprotobyname(), getsockopt(), ioctl(), and socket().
ΓòÉΓòÉΓòÉ 5.4.19. shutdown() ΓòÉΓòÉΓòÉ
int shutdown(s, how)
int s;
int how;
Parameter Description
s The socket descriptor.
how The condition of the shutdown. The values 0, 1, or 2 set the
condition.
Description: The shutdown() call shuts down all or part of a duplex
connection. how sets the condition for shutting down the connection to socket
s.
how can have a value of 0, 1, or 2, where:
o 0 ends communication from socket s.
o 1 ends communication to socket s.
o 2 ends communication both to and from socket s.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
Errno Value Description
SOCENOTSOCK The s parameter is not a valid socket descriptor.
SOCEINVAL The how parameter was not set to one of the valid values.
Valid values are 0, 1, and 2.
See Also: accept(), connect(), socket(), and soclose().
ΓòÉΓòÉΓòÉ 5.4.20. sock_errno() ΓòÉΓòÉΓòÉ
#include <nerrno.h>
init sock_errno(s)
Description: The sock_errno() call returns the error code set by Socket calls.
See Also: psock_errno().
ΓòÉΓòÉΓòÉ 5.4.21. sock_init() ΓòÉΓòÉΓòÉ
int sock_init()
Description: There are no parameters associated with this call. The
sock_init() call initializes the socket data structures and checks whether
INET.SYS is running. Therefore, sock_init() should be called at the beginning
of each program that uses socket().
Return Value: The value 0 indicates success; the value 1 indicates an error.
ΓòÉΓòÉΓòÉ 5.4.22. socket() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int socket(domain, type, protocol)
int domain;
int type;
int protocol;
Parameter Description
domain The address domain requested. Either AF_INET, AF_OS2, or AF_NU.
type The type of socket created, either SOCK_STREAM, SOCK_DGRAM,
SOCK_RAW, or SOCK_SEQPACKET.
protocol The protocol requested. Some possible values are 0, IPPROTO_UDP,
IPPROTO_TCP, or IPPROTO_NB.
Description: The socket() call creates an endpoint for communication and
returns a socket descriptor representing the endpoint. Different types of
sockets provide different communication services.
The domain parameter specifies a communication domain where communication is to
take place. This parameter selects the address family (format of addresses
within a domain) that is used.
Address Family Description
AF_OS2 or AF_UNIX Local IPC domain using OS/2 file/path naming format for
high performance IPC between applications within the same
node.
AF_INET INET domain using INET address format. Support of INET
domain access may be via a locally connected native or
non-native INET network. See "Non-Native Networking".
AF_NETBIOS or AF_NB NetBIOS domain using NetBIOS address format.
AF_DIRECT MPTN domain using any address format for local and
destination name. AF_DIRECT is used primarily by MPTN
system services for commmunicating with each other over a
locally connected network independent of the address
format used.
The type parameter specifies the type of socket created. The type is analogous
with the semantics of the communication requested. These socket type constants
are defined in the <sys\socket.h> header file. The types supported are:
Type Description
SOCK_STREAM Provides sequenced, two-way byte streams that are reliable
and connection-oriented. They support a mechanism for
out-of-band data. SOCK_STREAM is supported in AF_OS2 (or
AF_UN), AF_INET, and AF_DIRECT domain.
SOCK_SEQPACKET Provides sequenced, two-way byte records that are reliable
and connection-oriented.
SOCK_SEQPACKET is supported for protocols such as NetBIOS
and AF_NETBIOS domains. When NBPROTO protocol is
specified, a socket application can be used to communicate
with a remote application using the NetBIOS NCB I/F.
AF_DIRECT mode does not support SOCK_SEQPACKET.
SOCK_DGRAM Provides datagram, which are connectionless messages of a
fixed length whose reliability is not guaranteed. Datagram
can be corrupted, received out of order, lost, or delivered
multiple times.
SOCK_DGRAM is supported in AF_OS2(or AF_UNIX), AF_NETBIOS,
and AF_INET.
SOCK_RAW (AF_INET) Provides the interface to internal protocols
(such as IP and ICMP).
The protocol parameter specifies a particular protocol to be used with the
socket. Only native protocol can be selected for an address family. In most
cases, a single protocol exists to support a particular type of socket in an
address family (except for raw sockets or non-native networking support as
discussed later). If the protocol field is set to 0 (default), the system
selects the default protocol number for the domain and socket type requested.
How a protocol is selected is based on whether MPTN has been configured. When
MPTN access is not configured, the protocol default is the same as BSD; that
is, only protocols native to the requested domain and type. When MPTN access is
configured, the protocol is expanded to include any attached native and
non-native protocols/networks capable of supporting MPTN.
In TCP/IP, native protocol value is set to IPPROTO_TCP and UDP as defined in
the <\ETC\PROTOCOL> file. Alternatively, the getprotobyname() call can be used
to get the protocol number for a protocol with a known name. However, with
MPTN, the default protocol and locally connected native or non-native INET
network is selected based on installation configuration.
Default protocol is always used for AF_DIRECT mode. TCP/IP selects the protocol
that supports DIRECT mode addressing.
SOCK_STREAM sockets model duplex byte streams. They provide reliable
flow-controlled connections between peer applications. Stream sockets are
either active or passive. Active sockets are used by clients who initiate
connection requests with connect(). By default, socket() creates active
sockets. Passive sockets are used by servers to accept connection requests
with the connect() call. An active socket is transformed into a passive socket
by binding a name to the socket with the bind() call and by indicating a
willingness to accept connections with the listen() call. After a socket
becomes passive, it cannot be used to initiate connection requests.
Wildcard Address: From the AF_INET domain, the bind() call applied to a stream
socket lets the application specify the networks it is willing to accept
connection requests from. The application can fully specify the network
interface by setting the internet address field in the address structure to the
internet address of a network interface in a locally connected INET network.
Alternatively, the application can use a wildcard to specify that it wants to
receive connection requests from any locally connected INET networks. This is
done by setting the internet address field in the address structure to the
constant INADDR_ANY as defined in <sys\socket.h>. When INADDR_ANY is used, the
INET_ADDR for each of the INET networks will be used.
Similarly, in other domains(AF_OS2 and AF_NETBIOS), wildcard address is also
supported. The wildcard address is specified in the corresponding include files
<sys\un.h, netnb\nb.h>.
Wildcard address is supported for the AF_DIRECT user. However, the bind() call
must be used to specify the address family type.
Non-Native Networking: In the MPTN environment, non-native networking is the
ability to provide networking services of one domain type to applications using
a transport API (socket library in this case) over other locally connected
network and protocol types. The domain used by the application is the
non-native network, while the locally connected network actually providing the
services is called the native network.
The TCP/IP provides the necessary address/name mapping and protocol
compensation services to support the semantics of the non-native network over
the selected native network. Currently, only TCP/IP over NetBIOS is supported.
Non-Native INET (AF_INET) Networking over the NetBIOS LAN Network: This
capability allows an application to use INET addressing across a native NetBIOS
LAN network.
Non-native networking requires the TCP/IP to map non-native network addresses
supplied by the socket application to native network addresses. Address mapping
is either provided by an MPTN network level directory called A-B mapper or done
locally using algorithmic mapping. Algorithmic mapping for INET domain uses the
4-byte IP address to map to a protocol-specific address. The protocol-specific
address generated is used to service all INET non-native networking connection
requests for that non-native INET network. Each non-native connection request
results in a separate native network connection created using this
protocol-specific address. INET port ID is used for local routing to the
individual application within the node. The non-native local and destination
addresses are sent as part of the MPTN connect header information to be used
for routing to the remote partner application.
In NetBIOS LAN, the NetBIOS name mapped from INET address is of the form:
Byte: 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
NETBIOS name "M P T N . I N . <-- ip addr -->"
MPTN.IN. appended with an IP address converted into
an 8-byte hexadecimal character string
Algorithmic mapping for non-native networking over a local socket is done by
locating local socket users with matching local and destination address
independent of the address family types.
To invoke non-native INET networking, the application specifies the protocol
value as 0 (when configured for MPTN access). The common MPTN manager searches
all the connected networks to locate the destination. The search order always
starts with the search over local domain first, followed by a search of each of
the connected networks as defined by the configuration until a path to the
destination can be located.
If a non-native network is selected for INET, the protocol layer generates a
unique protocol-specific address (local and NetBIOS LAN networking) to service
the INET non-native networking request.
Wildcard addressing is also supported in non-native networking. When
INADDR_ANY is used in INET domain, the INET address is first generated as
described in the preceding text. A corresponding protocol-specific address is
generated from this generated INET address.
After a connection has been established between stream sockets or sequenced
packets, any of the data transfer calls can be used: send(), recv(), read(),
writev(), sendto(), recvfrom(), or recvmsg(). Usually, a send-recv pair is used
for sending data on stream or sequenced_packet sockets.
SOCK_DGRAM sockets model datagrams. They provide connectionless message
exchange with no guarantees on reliability. Messages sent have a maximum size.
There is no active or passive analogy to stream or sequenced_packet socket with
datagram sockets. Servers must still call bind() to name a socket and to
specify the network interfaces it wants to receive packets from. Wildcard
addressing, as described for stream sockets, applies for datagram sockets also.
Because datagram sockets are connectionless, the listen() call has no meaning
for them and must not be used with them.
After an application has received a datagram socket, it can exchange datagrams
using the sendto() and recfrom() calls or the sendmsg() and recvmsg() calls.
If the application goes one step further by calling connect() and fully
specifying the name of the peer all messages are to be exchanged with, the
other data transfer calls, readv(), writev(), send(), and recv(), can also be
used.
Datagram sockets allow messages to be broadcast to multiple recipients.
Setting the destination address to be a broadcast address is network
interface-dependent. Only AF_NETBIOS and AF_INET support the broadcast
function. For INET, broadcast function is dependent on the class of address
and whether subnets are being used. The constant INADDR_BROADCAST, defined in
<sys\socket.h>, can be used to broadcast to the primary network if the primary
network configured supports broadcast. For AF_NETBIOS, the address format has
a type field that specifies whether the address is individual, multicast, or
broadcast address.
SOCK_RAW sockets gives the application an interface to lower-layer protocols
such as IP and ICMP. This interface is often used to bypass the transport
layer when direct access to lower layer protocols is needed. Raw sockets are
also used to test new protocols.
Raw sockets are connectionless and data transfer semantics are the same as
those described previously for datagram sockets. The connect() call can be
used similarly to specify the peer.
Outgoing packets have an IP header prefixed to them. IP options can be set and
inspected using the setsockopt() and getsockopt() calls respectively. Incoming
packets are received with the IP header and options intact.
Sockets are deallocated with the soclose() call.
Return Value and Errno Values: A non-negative socket descriptor indicates
success. The value -1 indicates an error. Specified error values are obtained
by calling sock_errno() or psock_errno().
Errno Value Description
SOCEPROTONOSUPPORT The protocol is not supported in this domain
or this protocol is not supported for this
socket type.
SOCEPROTOTYPE The protocol is the wrong type for the socket.
Examples: The 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);
.
.
.
/* Get stream socket in internet domain with default protocol */
s = socket(AF_INET, SOCK_STREAM, 0);
.
.
.
/* Get raw socket in internet domain for ICMP protocol */
p = getprotobyname("icmp");
s = socket(AF_INET, SOCK_RAW, p->p_proto);
See Also: accept(), bind(), connect(), getprotobyname(), getsockname(),
getsockopt(), ioctl(), readv(), recv(), recvfrom(), select(), send(), sendto(),
shutdown(), soclose(), and writev().
ΓòÉΓòÉΓòÉ 5.4.23. soclose() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int soclose(s)
int s;
Parameter Description
s The descriptor of the socket to discard
Description: The soclose() call shuts down the socket associated with the
socket descriptor s, and frees resources allocated to the socket. If s refers
to an open TCP connection, the connection is closed.
Return Value and Errno Values: The value 0 indicates success; the value -1
indicates an error. Specified error values are obtained by calling sock_errno()
or psock_errno().
Errno Value 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.
SOCENOTCONN The socket is not connected.
See Also: accept() and socket().
ΓòÉΓòÉΓòÉ 5.4.24. writev() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <sys\socket.h>
int writev(s, iov, iovcnt)
int s;
struc iovec *iov;
int iovcnt;
Parameter Description
s The socket descriptor
iov A pointer to an array of iovec buffers
iovcnt The number of buffers pointed to by the iov parameter
Description: The writev() call writes data on a socket with descriptor s. The
data is gathered from the buffers specified by iovН0┘...iovНiovcnt-1┘. The
iovec structure is defined in SYS\SOCKET.H and contains the following fields:
Parameter Description
iov_base Pointer to the buffer.
iov_len Length of the buffer.
The writev() call applies only to connected sockets.
This call writes iov_len bytes of data. If there is not enough available buffer
space to hold the socket data to be transmitted and the socket is in blocking
mode, writev() blocks the caller until additional buffer space becomes
available. If the socket is in a nonblocking mode, writev() returns -1 and sets
return code to SOCWOULDBLOCK. See ioctl() for a description of how to set
nonblocking mode.
For datagram sockets, this call sends the entire datagram, provided the
datagram fits into the TCPIP buffers. Stream sockets act like streams of
information with no boundaries separating data. For example, if an application
sends 1000 bytes, each call to this function can send 1 byte, 10 bytes, or the
entire 1000 bytes. Therefore, applications using stream sockets must place this
call in a loop, calling this function until all data has been sent.
Return Value and Errno Values: If successful, the number of bytes written from
the buffer (s) is returned. The value -1 indicates an error. Specified error
values are obtained by calling sock_errno() or psock_errno().
Errno Value Description
SOCENOTSOCK s is not a valid socket descriptor.
SOCEFAULT Using the iov and iovcnt parameters results in an
attempt to access memory outside the caller's
address space.
SOCEINVAL Invalid argument.
SOCENOBUFS Buffer space is not available to send the message.
SOCEWOULDBLOCK s is in nonblocking mode and data is not available
to read.
SOCEMSGSIZE The message was too big to be sent as a single
datagram. The default and maximum is 8192.
SOCEDESTADDRREQ A destination address is required.
See Also: connect(), fcntl(), getsockopt(), ioctl(), write(), read(), readv(),
recv(), recvmsg(), recvfrom(), select(), selectex(), send(), sendmsg(),
sendto(), setsockopt(), socket(), and write().
ΓòÉΓòÉΓòÉ 5.5. Protocol-Dependent Socket Calls ΓòÉΓòÉΓòÉ
This section describes the protocol-dependent socket calls.
ΓòÉΓòÉΓòÉ 5.5.1. bswap() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <utils.h>
u_short bswap(a)
u_short a;
Parameter Description
a The unsigned short integer whose bytes are to be swapped
Description: The bswap() call swaps bytes in a short integer.
Return Value: Returns the translated short integer.
See Also: htonl(), htons(), lswap(), ntohl(), and ntohs().
ΓòÉΓòÉΓòÉ 5.5.2. dn_comp() ΓòÉΓòÉΓòÉ
The dn_comp() call compresses the expanded domain name.
#include <types.h>
#include <netinet\in.h>
#include <arpa\nameser.h>
#include <resolv.h>
int dn_comp(exp_dn, comp_dn, length, dnptrs, lastdnptr)
u_char *exp_dn;
u_char *comp_dn;
int length;
u_char **dnptrs;
u_char **lastdnptr;
Parameter Description
exp_dn Pointer to the location of an expanded domain name
comp_dn Pointer to an array containing the compressed domain name
length Length in bytes of the array pointed to by the comp_dn parameter
dnptrs List of pointers to previously compressed names in the current
message
lastdnptr Pointer to the end of the array pointed to by dnptrs
Description: The dn_comp() call compresses the domain name pointed to by the
exp_dn parameter and stores it in the area pointed to by the comp_dn parameter.
It uses the global _res structure, which is defined in the <RESOLV.H> header
file.
Return Value: When successful, the dn_comp() call returns the size of the
compressed domain name. See also dn_expand(), res_init(), des_mkquery(), and
res_send(). If it fails, the call returns a value of -1.
See Also: htonl(), htons(), lswap(), ntohl(), and ntohs().
ΓòÉΓòÉΓòÉ 5.5.3. dn_expand() ΓòÉΓòÉΓòÉ
The dn_expand() call expands a compressed domain name to a full domain name.
#include <types.h>
#include <netinet\in.h>
#include <arpa\nameser.h>
#include <resolv.h>
int dn_expand(msg, eomorig, comp_dn, exp_dn, length)
u_char *msg;
u_char *eomorig;
u_char *comp_dn;
u_char *exp_dn;
int length;
Parameter Description
msg Pointer to the beginning of a message
eomorig Pointer to the end of the original message that contains the
compressed domain name
comp_dn Pointer to the compressed domain name
exp_dn Pointer to a buffer that holds the resulting expanded domain
name
length Length in bytes of the buffer pointed to by the exp_dn parameter
Description The dn_expand() call expands a compressed domain name to a full
domain name, converting the expanded name to all uppercase letters. It uses the
global _res structure, which is defined in the <RESOLV.H> header file.
Return Value: If it succeeds, the dn_expand() call returns the size of the
expanded domain name. If it fails, the call returns a value of -1.
See Also: dn_comp(), res_init(), res_mkquery(), and res_send().
ΓòÉΓòÉΓòÉ 5.5.4. endhostent() ΓòÉΓòÉΓòÉ
The endhostent() call closes the HOSTS file.
void endhostent()
Description: The endhostent() call closes the \ETC\HOSTS file, which contains
information about known hosts.
See Also: gethostbyaddr(), gethostbyname(), gethostent(), and sethostent().
ΓòÉΓòÉΓòÉ 5.5.5. endnetent() ΓòÉΓòÉΓòÉ
The endnetent() call closes the NETWORKS file.
void endnetent()
Description: The endnetent() call closes the \ETC\NETWORKS file, which
contains information about known networks.
See Also: getnetbyaddr(), getnetbyname(), getnetent(), and setnetent().
ΓòÉΓòÉΓòÉ 5.5.6. endprotoent() ΓòÉΓòÉΓòÉ
The endprotoent() call closes the PROTOCOL file.
void endprotoent()
Description: The endprotoent() call closes the \ETC\PROTOCOL file, which
contains information about known protocols.
See Also: getprotobyname(), getprotobynumber(), getprotoent(), and
setprotoent().
ΓòÉΓòÉΓòÉ 5.5.7. endservent() ΓòÉΓòÉΓòÉ
The endservent() call closes the SERVICES file.
void endservent()
Description: The endservent() call closes the \ETC\SERVICES file, which
contains information about known services.
See Also: getservbyname(), getservbyport(), getservent(), and setservent().
ΓòÉΓòÉΓòÉ 5.5.8. gethostbyaddr() ΓòÉΓòÉΓòÉ
The gethostbyaddr() call returns information about a host specified by an
internet address.
#include <netdb.h>
struct hostent *gethostbyaddr(addr, addrlen, domain)
char *addr;
int addrlen;
int domain;
Parameter Description
addr A pointer to a 32-bit internet address in network-byte order
addrlen The size of addr in bytes
domain The address domain supported (AF_INET)
Description: The gethostbyaddr() call resolves the host name through a name
server, if one is present. If a name server is not present or cannot resolve
the host name, gethostbyaddr() searches the \ETC\HOSTS file in sequence until a
matching host address is found or an EOF marker is reached. The gethostbyaddr()
call returns a pointer to a hostent structure for the host address specified on
the call.
The <NETDB.H> header file defines the hostent structure, and contains the
following elements:
Element Description
h_name Official name of the host.
h_aliases A zero-terminated array of alternative names for the host.
h_addrtype The type of address being returned; always set to AF_INET.
h_length The length of the address in bytes.
h_addr A pointer to the network address of the host.
Return Value and h_errno Values: The return value points to static data that
is overwritten by subsequent calls. A pointer to a hostent structure indicates
success. A NULL pointer indicates an error or end-of-file. The value of h_errno
indicates the specific error.
┤БББББББББББББББББББББББББББББББББББББББСБББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В H_ERRNO VALUE В CODE В DESCRIPTION В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В HOST_NOT_FOUND В 1 В The host specified by the addr parameter is not found. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TRY_AGAIN В 2 В The local server does not receive a response from an В
В В В authorized server. Try again later. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_RECOVERY В 3 В This error code indicates an unrecoverable error. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_DATA В 4 В The requested addr is valid, but does not have an В
В В В internet address at the name server. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_ADDRESS В 4 В The requested addr is valid, but does not have an В
В В В internet address at the name server. В
БББББББББББББББББББББББББББББББББББББББ╔БББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББД
See Also: gethostbyname().
ΓòÉΓòÉΓòÉ 5.5.9. gethostbyname() ΓòÉΓòÉΓòÉ
#include <netdb.h>
struct hostent *gethostbyname(name)
char *name;
Parameter Description
name The name of the host being queried
Description: The gethostbyname() call resolves the host name through a name
server, if one is present. If a name server is not present or is unable to
resolve the host name, gethostbyname() searches the \ETC\HOSTS file in sequence
until a matching host name is found or an EOF marker is reached. The
gethostbyname() call returns a pointer to a hostent structure for the host name
specified on the call.
The <NETDB.H> header file defines the hostent structure and contains the
following elements:
Element Description
h_name Official name of the host.
h_aliases A zero-terminated array of alternative names for the host.
h_addrtype The type of address being returned; always set to AF_INET.
h_length The length of the address in bytes.
h_addr A pointer to the network address of the host.
Return Value and h_errno Value: The return value points to static data that is
overwritten by subsequent calls. A pointer to a hostent structure indicates
success. A NULL pointer indicates an error or end-of-file. The value of h_errno
indicates the specific error.
┤БББББББББББББББББББББББББББББББББББББББСБББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В H_ERRNO VALUE В CODE В DESCRIPTION В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В HOST_NOT_FOUND В 1 В The host specified by the name parameter is not found. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В TRY_AGAIN В 2 В The local server does not receive a response from an В
В В В authorized server. Try again later. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_RECOVERY В 3 В This error code indicates an unrecoverable error. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_DATA В 4 В The requested name is valid, but does not have an В
В В В internet address at the name server. В
╙БББББББББББББББББББББББББББББББББББББББТБББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В NO_ADDRESS В 4 В The requested name is valid, but does not have an В
В В В internet address at the name server. В
БББББББББББББББББББББББББББББББББББББББ╔БББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББД
See Also: gethostbyaddr().
ΓòÉΓòÉΓòÉ 5.5.10. gethostent() ΓòÉΓòÉΓòÉ
#include <manifest.h>
#include <netdb.h>
struct hostent *gethostent()
The gethostent() call has no parameters.
Description: The gethostent() call returns a pointer to the next entry in the
SITEINFO data set or, if you are using BSD-formatted files, the ETC_HOSTS data
set. The gethostent() call uses SITEINFO (ETC_HOSTS if you are using
BSD-formatted files) to get aliases.
The NETDB.H header file defines the hostent structure and contains the
following elements:
Parameter Description
h_name The official name of the host.
h_aliases A zero-terminated array of alternative names for host.
h_addrtype The type of address returned; currently, always set to AF_INET.
h_length The length, in bytes, of the address.
h_addr A pointer to the network address of the host.
Return Value: The return value points to static data that is overwritten by
subsequent calls. A pointer to a hostent structure indicates success. A NULL
pointer indicates an error or end of file. Since gethostent() uses C/370
functions, failures are reflected in errno as either a C/370 errno value or
EIBMDYNLERR (if an error was encountered while communicating with the
sockets-over-SNA address space).
See Also: gethostbyaddr(), gethostbyname(), sethostent().
ΓòÉΓòÉΓòÉ 5.5.11. gethostid() ΓòÉΓòÉΓòÉ
The gethostid() call returns the unique 32-bit identifier of the current host.
#include <types.h>
u_long gethostid()
Description: The gethostid() call gets the unique 32-bit identifier for the
current host.
Return Value: The gethostid() call returns the 32-bit identifier, in
network-byte order of the current host, which should be unique across all
hosts.
ΓòÉΓòÉΓòÉ 5.5.12. gethostname() ΓòÉΓòÉΓòÉ
The gethostname() call returns the standard host name for the local host
machine.
#include <netdb.h>
int gethostname(name, namelen)
char *name;
int namelen;
Parameter Description
name Pointer to a buffer
namelen Length of the buffer
Description: The gethostname() call returns the standard host name for the
local host into the buffer specified by the name parameter. The returned name
is a null-terminated string.
Return Value: The value 0 indicates success; the value -1 indicates an error.
See Also: gethostbyaddr(), gethostbyname(), and gethostid().
ΓòÉΓòÉΓòÉ 5.5.13. getnetbyaddr() ΓòÉΓòÉΓòÉ
The getnetbyaddr() call returns the NETWORKS file entry that contains the
specified address.
#include <netdb.h>
struct netent *getnetbyaddr(net, type)
u_long net;
int type;
Parameter Description
net Network address
type Address domain supported (AF_INET)
Description: The getnetbyaddr() call searches the \ETC\NETWORKS file for the
specified network address.
Return Value: The return value points to static data that later calls
overwrite. A pointer to a netent structure indicates success. A NULL pointer
indicates an error or EOF.
The netent structure is defined in the <NETDB.H> header file and contains the
following elements:
Element Description
n_name Official name of the network.
n_aliases An array, terminated with a NULL pointer, of alternative names for
the network.
n_addrtype Type of network address being returned, always set to AF_INET.
n_net Network number, returned in host-byte order.
See Also: endnetent(), getnetbyname(), getnetent(), and setnetent().
ΓòÉΓòÉΓòÉ 5.5.14. getnetbyname() ΓòÉΓòÉΓòÉ
The getnetbyname() call returns the NETWORKS file entry that contains the
specified name.
#include <netdb.h>
struct netent *getnetbyname(name)
char *name;
Parameter Description
name Pointer to a network name
Description: The getnetbyname() call searches the \ETC\NETWORKS file for the
specified network name.
Return Value: The getnetbyname() call returns a pointer to a netent structure
for the network name specified on the call. The netent structure is defined in
the <NETDB.H> header file; it contains the following elements:
Parameter Description
n_name Official name of the network.
n_aliases Array, terminated with a NULL pointer, of alternative names for the
network.
n_addrtype Type of network address being returned, always set to AF_INET.
n_net Network number, returned in host-byte order.
The return value points to static data that later calls overwrite. A pointer to
a netent structure indicates success; a NULL pointer indicates an error or EOF.
See Also: endnetent(), getnetbyaddr(), getnetent(), and setnetent().
ΓòÉΓòÉΓòÉ 5.5.15. getnetent() ΓòÉΓòÉΓòÉ
The getnetent() call returns the next entry in the NETWORKS file.
#include <netdb.h>
struct netent *getnetent()
Description: The getnetent() call returns the next entry of the \ETC\NETWORKS
file.
Return Value: The getnetent() call returns a pointer to the next entry in the
\ETC\NETWORKS file. The return value points to static data that later calls
overwrite.
A pointer to a netent structure indicates success. A NULL pointer indicates an
error or EOF.
The netent structure is defined in the <NETDB.H> header file, and it contains
the following elements:
Element Description
n_name Official name of the network.
n_aliases Array, terminated with a NULL pointer, of alternative names for the
network.
n_addrtype Type of network address being returned, always set to AF_INET.
n_net Network number, returned in host-byte order.
See Also: endnetent(), getnetbyaddr(), getnetbyname(), and setnetent().
ΓòÉΓòÉΓòÉ 5.5.16. getprotobyname() ΓòÉΓòÉΓòÉ
The getprotobyname() call returns a protocol entry specified by a name in the
PROTOCOL file.
#include <netdb.h>
struct protoent *getprotobyname(name)
char *name;
Parameter Description
name Pointer to the specified protocol
Description: The getprotobyname() call searches the \ETC\PROTOCOL file for the
specified protocol name.
Return Value: The getprotobyname() call returns a pointer to a protoent
structure for the network protocol specified on the call. The protoent
structure is defined in the <NETDB.H> header file and contains the following
elements:
Element Description
p_name Official name of the protocol.
p_aliases Array, terminated with a NULL pointer, of alternative names for the
protocol.
p_proto Protocol number.
The return value points to static data that later calls overwrite. A pointer to
a protoent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also: endprotoent(), getprotobynumber(), getprotoent(), and setprotoent().
ΓòÉΓòÉΓòÉ 5.5.17. getprotobynumber() ΓòÉΓòÉΓòÉ
The getprotobynumber() call returns a protocol entry specified by a number in
the PROTOCOL file.
#include <netdb.h>
struct protoent * getprotobynumber(proto)
int proto;
Parameter Description
proto Protocol number
Description: The getprotobynumber() call searches the \ETC\PROTOCOL file for
the specified protocol number.
Return Value: The getprotobynumber() call returns a pointer to a protoent
structure for the network protocol specified on the call. The protoent
structure is defined in the <NETDB.H> header file and contains the following
elements:
Element Description
p_name Official name of the protocol.
p_aliases Array, terminated with a NULL pointer, of alternative names for the
protocol.
p_proto Protocol number.
The return value points to static data that later calls overwrite. A pointer to
a protoent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also:, endprotoent(), getprotobyname(), getprotoent(), and setprotoent().
ΓòÉΓòÉΓòÉ 5.5.18. getprotoent() ΓòÉΓòÉΓòÉ
The getprotoent() call returns the next entry in the PROTOCOL file.
#include <netdb.h>
struct protoent *getprotoent()
Description: The getprotoent() call searches for the next line in the
\ETC\PROTOCOL file.
Return Value: The getprotoent() call returns a pointer to the next entry in
the file, \ETC\PROTOCOL.
The protoent structure is defined in the <NETDB.H> header file and contains the
following elements:
Element Description
p_name Official name of the protocol.
p_aliases Array, terminated with a NULL pointer, of alternative names for the
protocol.
p_proto Protocol number.
The return value points to static data that later calls overwrite. A pointer to
a protoent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also: endprotoent(), getprotobyname(), getprotobynumber(), and
setprotoent().
ΓòÉΓòÉΓòÉ 5.5.19. getservbyname() ΓòÉΓòÉΓòÉ
The getservbyname() call returns a service entry specified by a name in the
SERVICES file.
#include <netdb.h>
struct servent *getservbyname(name, proto)
char *name;
char *proto;
Parameter Description
name Pointer to the service name
proto Pointer to the specified protocol
Description: The getservbyname() call searches the \ETC\SERVICES file for the
specified service name, which must match the protocol if a protocol is stated.
Return Value: The call returns a pointer to a servent structure for the
network service specified on the call. The servent structure is defined in the
<NETDB.H> header file and contains the following elements:
Element Description
s_name Official name of the service.
s_aliases Array, terminated with a NULL pointer, of alternative names for the
service.
s_port Port number of the service.
s_proto Required protocol to contact the service.
The return value points to static data that later calls overwrite. A pointer to
a servent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also: endservent(), getservbyport(), getservent(), and setservent().
ΓòÉΓòÉΓòÉ 5.5.20. getservbyport() ΓòÉΓòÉΓòÉ
The getservbyport() call returns a service entry specified by a port number in
the SERVICES file.
#include <netdb.h>
struct servent *getservbyport(port, proto)
int port;
char *proto;
Parameter Description
port Specified port
proto Pointer to the specified protocol
Description: The getservbyport() call sequentially searches the \ETC\SERVICES
file for the specified port number, which must match the protocol if a protocol
is stated.
Return Value: The getservbyport() call returns a pointer to a servent
structure for the port number specified on the call. The servent structure is
defined in the <NETDB.H> header file and contains the following elements:
Element Description
s_name Official name of the service.
s_aliases Array, terminated with a NULL pointer, of alternative names for the
service.
s_port Port number of the service.
s_proto Required protocol to contact the service.
The return value points to static data that later calls overwrite. A pointer to
a servent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also: endservent(), getservbyname(), getservent(), and setservent().
ΓòÉΓòÉΓòÉ 5.5.21. getservent() ΓòÉΓòÉΓòÉ
The getservent() call returns the next entry in the SERVICES file.
#include <netdb.h>
struct servent *getservent()
Description: The getservent() call searches for the next line in the
\ETC\SERVICES file.
Return Value: The getservent() call returns a pointer to the next entry in the
\ETC\SERVICES file. The servent structure is defined in the <NETDB.H> header
file and contains the following elements:
Element Description
s_name Official name of the service.
s_aliases Array, terminated with a NULL pointer, of alternative names for the
service.
s_port Port number of the service.
s_proto Required protocol to contact the service.
The return value points to static data that later calls overwrite. A pointer to
a servent structure indicates success. A NULL pointer indicates an error or
EOF.
See Also: endservent(), getservbyname(), getservbyport(), and setservent().
ΓòÉΓòÉΓòÉ 5.5.22. htonl() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <utils.h>
u_long htonl(a)
u_long a;
Parameter Description
a The unsigned long integer to be put into network-byte order
Description: The htonl() call translates a long integer from host-byte order
to network-byte order.
Return Value: Returns the translated long integer.
See Also: bswap(), htons(), lswap(), ntohl(), ntohs().
ΓòÉΓòÉΓòÉ 5.5.23. htons() ΓòÉΓòÉΓòÉ
#include <types.h>
#include <utils.h>
u_short htons(a)
u_short a;
Parameter Description
a The unsigned short integer to be put into network-byte order
Description: The htons() call translates a short integer from host-byte order
to network-byte order.
Return Value: Returns the translated short integer.
See Also: bswap(), htonl(), lswap(), ntohl(), and ntohs().
ΓòÉΓòÉΓòÉ 5.5.24. inet_addr() ΓòÉΓòÉΓòÉ
The inet_addr() call constructs an internet address from character strings
representing numbers expressed in standard dotted-decimal notation.
#include <types.h>
u_long inet_addr(cp)
char *cp;
Parameter Description
cp A character string in standard dotted-decimal notation
Description: The inet_addr() call interprets character strings representing
numbers expressed in standard dotted-decimal notation and returns numbers
suitable for use as an internet address.
Values specified in standard dotted-decimal notation take one of the following
forms:
a.b.c.d
a.b.c
a.b
a
When a four-part address is specified, each part is interpreted as a byte of
data and assigned, from left to right, to one of the 4 bytes of an internet
address.
When a three-part address is specified, the last part is interpreted as a
16-bit quantity and placed in the two rightmost bytes of the network address.
This makes the three-part address format convenient for specifying Class B
network addresses as 128.net.host.
When a two-part address is specified, the last part is interpreted as a 24-bit
quantity and placed in the three rightmost bytes of the network address. This
makes the two-part address format convenient for specifying Class A network
addresses as net.host.
When a one-part address is specified, the value is stored directly in the
network address space without any rearrangement of its bytes.
Numbers supplied as address parts in standard dotted-decimal notation can be
decimal, hexadecimal, or octal. Numbers are interpreted in C language syntax. A
leading 0x implies hexadecimal; a leading 0 implies octal. A number without a
leading 0 implies decimal.
Return Value: The internet address is returned in network-byte order.
See Also: inet_lnaof(), inet_makeaddr(), inet_netof(), inet_network(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.25. inet_lnaof() ΓòÉΓòÉΓòÉ
The inet_lnaof() call returns the local network portion of an internet address.
#include <types.h>
#include <netinet\in.h>
u_long inet_lnaof(in)
struct in_addr in;
Parameter Description
in The host internet address
Description: The inet_lnaof() call breaks apart the internet host address and
returns the local network address portion.
Return Value: The local network address is returned in host-byte order.
See Also: inet_addr(), inet_makeaddr(), inet_netof(), inet_network(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.26. inet_makeaddr() ΓòÉΓòÉΓòÉ
The inet_makeaddr() call constructs an internet address from a network number
and a local address.
#include <types.h>
#include <netinet\in.h>
struct in_addr inet_makeaddr(net, lna)
u_long net;
u_long lna;
Parameter Description
net The network number
lna The local network address
Description: The inet_makeaddr() call takes a network number and a local
network address and constructs an internet address.
Return Value: The internet address is returned in network-byte order.
See Also: inet_addr(), inet_lnaof(), inet_netof(), inet_network(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.27. inet_netof() ΓòÉΓòÉΓòÉ
The inet_netof() call returns the network number portion of the internet host
address.
#include <types.h>
#include <netinet\in.h>
u_long inet_netof(in)
struct in_addr in;
Parameter Description
in The internet address in network-byte order
Description: The inet_netof() call breaks apart the internet host address and
returns the network number portion.
Return Value: The network number is returned in host-byte order.
See Also: inet_addr(), inet_lnaof(), inet_makeaddr(), inet_network(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.28. inet_network() ΓòÉΓòÉΓòÉ
The inet_network() call constructs a network number from caracters strings
representing numbers expressed in standard dotted-decimal notation.
#include <types.h>
u_long inet_network(cp)
char *cp;
Parameter Description
cp A character string in standard dotted-decimal notation
Description: The inet_network() call interprets character strings representing
numbers expressed in standard dotted-decimal notation and returns numbers
suitable for use as a network number.
Return Value: The network number is returned in host-byte order.
See Also: inet_addr(), inet_lnaof(), inet_makeaddr(), inet_netof(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.29. inet_ntoa() ΓòÉΓòÉΓòÉ
The inet_ntoa() call returns a pointer to a string in dotted-decimal notation.
#include <types.h>
#include <netinet\in.h>
char *inet_ntoa(in)
struct in_addr in;
Parameter Description
in The host internet address
Description: The inet_ntoa() call returns a pointer to a string expressed in
the dotted-decimal notation. The inet_ntoa() call accepts an internet address
expressed as a 32-bit quantity in network-byte order and returns a string
expressed in dotted-decimal notation.
Return Value: Returns a pointer to the internet address expressed in
dotted-decimal notation.
See Also: inet_addr(), inet_lnaof(), inet_makeaddr(), inet_network(), and
inet_ntoa().
ΓòÉΓòÉΓòÉ 5.5.30. lswap() ΓòÉΓòÉΓòÉ
The lswap() call constructs a network number from character strings
representing numbers expressed in standard dotted-decimal notation.
#include <types.h>
#include <utils.h>
u_long lswap(a)
u_long a;
Parameter Description
a The unsigned long integer whose bytes are to be swapped
Description: The lswap() call swaps bytes in a long integer.
Return Value: Returns the translated long integer.
See Also: bswap(), htonl(), htons(), ntohl(), and ntohs().
ΓòÉΓòÉΓòÉ 5.5.31. ntohl() ΓòÉΓòÉΓòÉ
The ntohl() call translates a long integer from network-byte order to host-byte
order.
#include <types.h>
#include <utils.h>
u_long ntohl(a)
u_long a;
Parameter Description
a The unsigned long integer to be put into host-byte order
Description: The ntohl() call translates a long integer from network-byte
order to host-byte order.
Return Value: Returns the translated long integer.
See Also: bswap(), htonl(), htons(), lswap(), and ntohs().
ΓòÉΓòÉΓòÉ 5.5.32. ntohs() ΓòÉΓòÉΓòÉ
The ntohs() call translates a short integer from network-byte order to
host-byte.order.
#include <types.h>
#include <utils.h>
u_short ntohs(a)
u_short a;
Parameter Description
a The unsigned short integer to be put into host-byte order
Description: The ntohs() call translates a short integer from network-byte
order to host-byte order.
Return Value: The ntohs() call returns the translated short integer.
See Also: bswap(), htonl(), htons(), lswap(), and ntohl().
ΓòÉΓòÉΓòÉ 5.5.33. res_init() ΓòÉΓòÉΓòÉ
The res_init() call reads the RESOLV file for the default domain name.
include <types.h>
#include <netinet\in.h>
#include <arpa\nameser.h>
#include <resolv.h>
void res_init()
Description: The res_init() call reads the TCPIP\ETC\RESOLV file for the
default domain name and for the internet address of the initial hosts running
the name server. If that file does not exist, the call attempts name resolution
using the TCPIP\ETC\HOSTS file. One of these files should be operational.
The call stores domain name information in the global _res structure, which is
defined in the <RESOLV.H> header file.
See Also: dn_comp(), dn_expand(), res_mkquery(), and res_send().
ΓòÉΓòÉΓòÉ 5.5.34. res_mkquery() ΓòÉΓòÉΓòÉ
The res_mkquery() call makes a query message for the name servers in the
Internet domain.
#include <types.h>
#include <netinet\in.h>
#include <arpa\nameser.h>
#include <resolv.h>
int re_mkquery (op, dname, class, type, data, datalen, newrr,
buf, buflen)
int op;
char *dname;
int class;
int type;
char *data;
int datalen;
struct rrec *newrr;
char *buf;
int buflen;
Parameter Description
op The usual type is QUERY, but you can set the parameter to any
query type defined in the <ARPA\NAMESER.H> header file.
dname Pointer to the domain name. If dname points to a single label
and the RES_DEFNAMES bit in the _res structure defined in the
<RESOLV.H> header file is set, the call appends dname to the
current domain name. The current domain name is defined in the
TCPIP\ETC\RESOLV file.
class One of the following values:
C_IN ARPA Internet
C_CHAOS Chaos network at MIT
type One of the following type values for resources and queries:
T_A Host address
T_NS Authoritative server
T_MD Mail destination
T_MF Mail forwarder
T_CNAME Canonical name
T_SOA Start of authority zone
T_MB Mailbox domain name
T_MG Mail group member
T_MR Mail rename name
T_NULL NULL resource record
T_WKS Well-known service
T_PTR Domain name pointer
T_HINFO Host information
T_MINFO Mailbox information
T_MX Mail routing information
T_UINFO User information
T_UID User ID
T_GID Group ID
data Pointer to the data sent to the name server as a search key.
datalen Size of the parameter data in bytes.
newrr Reserved for future updates; currently an unused parameter.
buf Pointer to the query message.
buflen Length in bytes of the buffer pointed to by the buf parameter.
Description: The res_mkquery() call makes a query message for the name servers
in the Internet domain and puts that query message in the location pointed by
the buf parameter. It uses global _res structure, which is defined in the
<RESOLV.H> header file.
Return Value: If it succeeds, the res_mkquery() call returns the size of the
query. If the query is larger than the value of buflen, the call fails and
returns a value of -1.
See Also: dn_comp(), dn_expand(), res_init(), and res_send().
ΓòÉΓòÉΓòÉ 5.5.35. res_send() ΓòÉΓòÉΓòÉ
The res_send() call sends a query to a local name server.
#include <types.h>
#include <netinet\in.h>
#include <arpa\nameser.h>
#include <resolv.h>
int re_send(msg, msglen, ans, anslen)
char *msg;
int msglen;
char *ans;
int anslen;
Parameter Description
msg Pointer to the beginning of a message
msglen Length in bytes of the buffer pointed to by the msg parameter
ans Pointer to the location where the received response is stored
anslen Length in bytes of the buffer pointed by the ans parameter
Description: The res_send() call sends a query to the local name server and
calls the res_init() call if the RES_INIT option of the global _res structure
is not set. It also handles time-outs and retries. It uses the global _res
structure, which is defined in the <RESOLV.H> header file.
Return Value: If it succeeds, the call returns the length of the message. If
it fails, the call returns a value of -1.
See Also: dn_comp(), dn_expand(), res_init(), and res_mkquery().
ΓòÉΓòÉΓòÉ 5.5.36. sethostent() ΓòÉΓòÉΓòÉ
The sethostent() call opens and rewinds the HOSTS file.
void sethostent(stayopen)
int stayopen;
Parameter Description
stayopen Allows the TCPIP\ETC\HOSTS file to stay open after each call
Description: The sethostent() call opens and rewinds the \ETC\HOSTS file. If
the stayopen parameter is nonzero, the \ETC\HOSTS file stays open after each of
the gethost calls.
Return Value: A NULL pointer indicates an error or EOF.
See Also: endhostent(), gethostbyaddr(), gethostbyname(), and gethostent().
ΓòÉΓòÉΓòÉ 5.5.37. setnetent() ΓòÉΓòÉΓòÉ
The setnetent() call opens and rewinds the NETWORKS file.
void setnetent(stayopen)
int stayopen;
Parameter Description
stayopen Allows the \ETC\NETWORKS file to stay open after each call
Description: The setnetent() call opens and rewinds the \ETC\NETWORKS file,
which contains information about known networks. If the stayopen parameter is
nonzero, the \ETC\NETWORKS file stays open after each of the getnet calls.
Return Value: A NULL pointer indicates an error or EOF.
See Also: endnetent(), getnetbyaddr(), getnetbyname(), and getnetent().
ΓòÉΓòÉΓòÉ 5.5.38. setprotoent() ΓòÉΓòÉΓòÉ
The setprotoent() call opens and rewinds the PROTOCOL file.
void setprotoent(stayopen)
int stayopen;
Parameter Description
stayopen Allows the TCPIP\ETC\PROTOCOL file to stay open after each call
Description: The setprotoent() call opens and rewinds the \ETC\PROTOCOL file,
which contains information about known protocols. If the stayopen parameter is
nonzero, the TCPIP\ETC\PROTOCOL file stays open after each of the getproto
calls.
Return Value: A NULL pointer indicates an error or EOF.
See Also:, endprotoent() getprotobyname(), getprotobynumber(), and
getprotoent().
ΓòÉΓòÉΓòÉ 5.5.39. setservent() ΓòÉΓòÉΓòÉ
The setservent() call opens and rewinds the SERVICES file.
void setservent(stayopen)
int stayopen;
Parameter Description
stayopen Allows the TCPIP\ETC\SERVICES file to stay open after each call
Description: The setservent() call opens and rewinds the \ETC\SERVICES file,
which contains information about known services and well-known ports. If the
stayopen parameter is nonzero, the TCPIP\ETC\SERVICES file stays open after
each of the getserv calls.
Return Value: A NULL pointer indicates an error or EOF.
See Also:, endservent() getservbyname(), getservbyport(), and getservent().
ΓòÉΓòÉΓòÉ 6. Sample Socket Programs ΓòÉΓòÉΓòÉ
This appendix provides examples of the following C socket programs:
o UDP client
o UDP server
o TCP client
o TCP server
o NB client
o NB server
ΓòÉΓòÉΓòÉ 6.1. C Socket UDP Client ΓòÉΓòÉΓòÉ
The following is an example of a C socket UDP client program:
#include <stdlib.h>
#include <types.h>
#include <netinet/in.h>
#include <sys/socket.h>
main(argc, argv)
int argc;
char **argv;
{
int sockint, s;
unsigned short port;
struct sockaddr_in server;
char bufН32┘;
/* argvН1┘ is internet address of server argvН2┘ is port of server.
* Convert the port from ascii to integer and then from host byte
* order to network byte order.
*/
if(argc != 3)
{
printf("Usage: %s <host address> <port> \n",argvН0┘);
exit(1);
}
port = htons(atoi(argvН2┘));
/* Initialize with sockets */
if ((sockint = sock_init()!=0)
{
printf ("INET.SYS probably not running");
exit (1);
/* Create a datagram socket in the internet domain and use the
* default protocol (UDP).
*/
if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
{
psock_errno("socket()");
exit(1);
}
/* Set up the server name */
server.sin_family = AF_INET; /* Internet Domain */
server.sin_port = port; /* Server Port */
server.sin_addr.s_addr = inet_addr(argvН1┘);
/* Server's Address */
strcpy(buf, "Hello");
/* Send the message in buf to the server */
if (sendto(s, buf, (strlen(buf)+1), 0, &server, sizeof(server)) < 0)
{
psock_errno("sendto()");
exit(2);
}
/* Deallocate the socket */
soclose(s);
}
ΓòÉΓòÉΓòÉ 6.2. C Socket UDP Server ΓòÉΓòÉΓòÉ
The following is an example of a C socket UDP server program:
#include <stdlib.h>
#include <types.h>
#include <netinet/in.h>
#include <sys/socket.h>
main()
{
int sockint, s, namelen, client_address_size;
struct sockaddr_in client, server;
char bufН32┘;
/*
* Initialize with sockets.
*/
if ((sockint = sock_init()!=0)
{
printf ("INET.SYS probably not running");
exit (1);
/*
* Create a datagram socket in the internet domain and use the
* default protocol (UDP).
*/
if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
{
psock_errno("socket()");
exit(1);
}
/*
* Bind my name to this socket so that clients on the network can
* send me messages. (This allows the operating system to demultiplex
* messages and get them to the correct server.)
*
* Set up the server name. The internet address is specified as the
* wildcard INADDR_ANY so that the server can get messages from any
* of the physical internet connections on this host. (Otherwise, we
* would limit the server to messages from only one network interface.)
*/
server.sin_family = AF_INET; /* Server is in Internet Domain */
server.sin_port = 0; /* Use any available port */
server.sin_addr.s_addr = INADDR_ANY;/* Server's Internet Address */
if (bind(s, &server, sizeof(server)) < 0)
{
psock_errno("bind()");
exit(2);
}
/* Find out what port was really assigned and print it. */
namelen = sizeof(server);
if (getsockname(s, (struct sockaddr *) &server, &namelen) < 0)
{
psock_errno("getsockname()");
exit(3);
}
printf("Port assigned is %d\n", ntohs(server.sin_port));
/*
* Receive a message on socket s in buf of maximum size 32
* from a client. Because the last two parameters
* are not null, the name of the client will be placed into the
* client data structure and the size of the client address will
* be placed into client_address_size.
*/
client_address_size = sizeof(client);
if(recvfrom(s, buf, sizeof(buf), 0, (struct sockaddr *) &client,
&client_address_size) <0)
{
psock_errno("recvfrom()");
exit(4);
}
/*
* Print the message and the name of the client.
* The domain should be the internet domain (AF_INET).
* The port is received in network byte order, so we translate it to
* host byte order before printing it.
* The internet address is received as 32 bits in network byte order
* so we use a utility that converts it to a string printed in
* dotted decimal format for readability.
*/
printf("Received message %s from domain %s port %d internet address %s\n",
buf,
(client.sin_family == AF_INET?"AF_INET":"UNKNOWN"),
ntohs(client.sin_port),
inet_ntoa(client.sin_addr));
/*
* Deallocate the socket.
*/
soclose(s);
}
ΓòÉΓòÉΓòÉ 6.3. C Socket TCP Client ΓòÉΓòÉΓòÉ
The following is an example of a C socket TCP client program:
/*
* Include Files.
*/
#include <types.h>
#include <netinet\in.h>
#include <sys\socket.h>
#include <netlib.h>
#include <netdb.h>
#include <stdio.h>
/*
* Client Main.
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned short port; /* port client will connect to */
char bufН12┘; /* data buffer for sending and receiving */
struct hostent *hostnm; /* server host name information */
struct sockaddr_in server; /* server address */
int sockint, s; /* client socket */
/*
* Check Arguments Passed. Should be hostname and port.
*/
if (argc != 3)
{
fprintf(stderr, "Usage: %s hostname port\n", argvН0┘);
exit(1);
}
/*
* Initialize with sockets.
*/
if ((sockint = sock_init()!=0)
{
printf ("INET.SYS probably not running");
exit (1);
/*
* The host name is the first argument. Get the server address.
*/
hostnm = gethostbyname(argvН1┘);
if (hostnm == (struct hostent *) 0)
{
fprintf(stderr, "Gethostbyname failed\n");
exit(2);
}
/*
* The port is the second argument.
*/
port = (unsigned short) atoi(argvН2┘);
/*
* Put a message into the buffer.
*/
strcpy(buf, "the message");
/*
* Put the server information into the server structure.
* The port must be put into network byte order.
*/
server.sin_family = AF_INET;
server.sin_port = htons(port);
server.sin_addr.s_addr = *((unsigned long *)hostnm->h_addr);
/*
* Get a stream socket.
*/
if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
psock_errno("Socket()");
exit(3);
}
/*
* Connect to the server.
*/
if (connect(s, &server, sizeof(server)) < 0)
{
psock_errno("Connect()");
exit(4);
}
if (send(s, buf, sizeof(buf), 0) < 0)
{
psock_errno("Send()");
exit(5);
}
/*
* The server sends back the same message. Receive it into the buffer.
*/
if (recv(s, buf, sizeof(buf), 0) < 0)
{
psock_errno("Recv()");
exit(6);
}
/*
* Close the socket.
*/
soclose(s);
printf("Client Ended Successfully\n");
exit(0);
}
ΓòÉΓòÉΓòÉ 6.4. C Socket TCP Server ΓòÉΓòÉΓòÉ
The following is an example of a C socket TCP server program:
/*
* Include Files.
*/
#include <types.h>
#include <netinet\in.h>
#include <sys\socket.h>
#include <netlib.h>
#include <stdio.h>
/*
* Server Main.
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned short port; /* port server binds to */
char bufН12┘; /* buffer for sending and receiving data */
struct sockaddr_in client; /* client address information */
struct sockaddr_in server; /* server address information */
int sockint, s; /* socket for accepting connections */
int ns; /* socket connected to client */
int namelen; /* length of client name */
/*
* Check arguments. Should be only one: the port number to bind to.
*/
if (argc != 2)
{
fprintf(stderr, "Usage: %s port\n", argvН0┘);
exit(1);
}
/*
* Initialize with sockets.
*/
if ((sockint = sock_init()!=0)
{
printf ("INET.SYS probably not running");
exit (1);
/*
* First argument should be the port.
*/
port = (unsigned short) atoi(argvН1┘);
/*
* Get a socket for accepting connections.
*/
if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
psock_errno("Socket()");
exit(2);
}
/*
* Bind the socket to the server address.
*/
server.sin_family = AF_INET;
server.sin_port = htons(port);
server.sin_addr.s_addr = INADDR_ANY;
if (bind(s, &server, sizeof(server)) < 0)
{
psock_errno("Bind()");
exit(3);
}
/*
* Listen for connections. Specify the backlog as 1.
*/
if (listen(s, 1) != 0)
{
psock_errno("Listen()");
exit(4);
}
/*
* Accept a connection.
*/
namelen = sizeof(client);
if ((ns = accept(s, &client, &namelen)) == -1)
{
psock_errno("Accept()");
exit(5);
}
/*
* Receive the message on the newly connected socket.
*/
if (recv(ns, buf, sizeof(buf), 0) == -1)
{
psock_errno("Recv()");
exit(6);
}
/*
* Send the message back to the client.
*/
if (send(ns, buf, sizeof(buf), 0) < 0)
{
psock_errno("Send()");
exit(7);
}
soclose(ns);
soclose(s);
printf("Server ended successfully\n");
exit(0);
}
ΓòÉΓòÉΓòÉ 6.5. C Socket NB Client ΓòÉΓòÉΓòÉ
The following is an example of a C socket NB Client program:
/*
* Include Files.
*/
#include <types.h>
#include <netnb\nb.h>
#include <sys\socket.h>
#include <netlib.h>
#include <netdb.h>
#include <stdio.h>
struct sockaddr_nb server; /* server address */
/*
* Client Main.
*/
main(int argc, char **argv) {
char bufН12┘; /* data buffer for sending and receiving */
int s; /* client socket */
/*
* Check Arguments Passed. Should be server-name and adapter-id.
*/
if (argc != 3) {
fprintf(stderr, "Usage: %s server-name adapter-id\n", argvН0┘);
exit(1);
}
/*
* Initialize with sockets.
*/
sock_init();
/*
* Put a message into the buffer.
*/
strcpy(buf, "the message");
/*
* Put the server information into the server structure.
*/
strcpy(server.snb_name, argvН1┘); // From first argument
strcpy(server.snb_netid, argvН2┘); // From second argument
server.snb_family = AF_NB; // NetBIOS address family
server.snb_type = NB_UNIQUE; // Unique name
/*
* Get a stream socket.
*/
if ((s = socket(AF_NB, SOCK_STREAM, 0)) < 0) {
psock_errno("Socket()");
exit(3);
}
/*
* Connect to the server.
*/
if (connect(s, (struct sockaddr *)&server, sizeof(server)) < 0) {
psock_errno("Connect()");
exit(4);
}
if (send(s, buf, sizeof(buf), 0) < 0) {
psock_errno("Send()");
exit(5);
}
/*
* The server sends back the same message. Receive it into the buffer.
*/
if (recv(s, buf, sizeof(buf), 0) < 0) {
psock_errno("Recv()");
exit(6);
}
/*
* Close the socket.
*/
soclose(s);
printf("Client Ended Successfully\n");
exit(0);
}
ΓòÉΓòÉΓòÉ 6.6. C Socket NB Server ΓòÉΓòÉΓòÉ
The following is an example of a C socket NB Server program:
/*
* Include Files.
*/
#include <types.h>
#include <netnb\nb.h>
#include <sys\socket.h>
#include <netlib.h>
#include <stdio.h>
struct sockaddr_nb server; /* server address information */
/*
* Server Main.
*/
main(int argc, char **argv) {
char bufН12┘; /* buffer for sending and receiving data */
struct sockaddr_nb client; /* client address information */
int s; /* socket for accepting connections */
int ns; /* socket connected to client */
int namelen; /* length of client name */
/*
* Check Arguments Passed. Should be server-name and adapter-id.
*/
if (argc != 3) {
fprintf(stderr, "Usage: %s server-name adapter-id\n", argvН0┘);
exit(1);
}
/*
* Initialize with sockets.
*/
sock_init();
/*
* Get a socket for accepting connections.
*/
if ((s = socket(AF_NB, SOCK_STREAM, 0)) < 0) {
psock_errno("Socket()");
exit(2);
}
/*
* Bind the socket to the server address.
*/
strcpy(server.snb_name, argvН1┘); // First argument
strcpy(server.snb_netid, argvН2┘); // Second argument
server.snb_family = AF_NB; // NetBIOS address family
server.snb_type = NB_UNIQUE; // Unique name type
if (bind(s, (struct sockaddr *)&server, sizeof(server)) < 0) {
psock_errno("Bind()");
exit(3);
}
/*
* Listen for connections. Specify the backlog as 1.
*/
if (listen(s, 1) != 0) {
psock_errno("Listen()");
exit(4);
}
/*
* Accept a connection.
*/
namelen = sizeof(client);
if ((ns = accept(s, (struct sockaddr *)&client, &namelen)) == -1) {
psock_errno("Accept()");
exit(5);
}
/*
* Receive the message on the newly connected socket.
*/
if (recv(ns, buf, sizeof(buf), 0) == -1) {
psock_errno("Recv()");
exit(6);
}
/*
* Send the message back to the client.
*/
if (send(ns, buf, sizeof(buf), 0) < 0) {
psock_errno("Send()");
exit(7);
}
soclose(ns);
soclose(s);
printf("Server ended successfully\n");
exit(0);
}
ΓòÉΓòÉΓòÉ 7. System Return Codes ΓòÉΓòÉΓòÉ
TCP/IP Error Messages provides the TCPIP error message numbers set by TCPIP
call and will be found in the <NERRNO.H>. For further system error message
numbers, refer to the compiler <ERRNO.H> header file.
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 3. TCP/IP Error Messages В
╙БББББББББББББББББББББББББСБББББББББББББСББББББББББББББББББББББББББББББББББББББЙ
В MESSAGE В CODE В DESCRIPTION В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEPERM В 10001 В Not owner. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCESRCH В 10003 В No such process. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEINTR В 10004 В Interrupted system call. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENXIO В 10006 В No such device or address. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEBADF В 10009 В Bad file number. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEACCES В 10013 В Permission denied. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEFAULT В 10014 В Bad address. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEINVAL В 10022 В Argument not valid. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEMFILE В 10024 В Too many open files. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEPIPE В 10032 В Broken pipe. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEWOULDBLOCK В 10035 В Operation would block. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEINPROGRESS В 10036 В Operation now in progress. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEALREADY В 10037 В Operation already in progress. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENOTSOCK В 10038 В Socket operation on non-socket. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEDESTADDRREQ В 10039 В Destination address required. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEMSGSIZE В 10040 В Message too long. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEPROTOTYPE В 10041 В Protocol wrong type for socket. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENOPROTOOPT В 10042 В Protocol not available. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEPROTONOSUPPORT В 10043 В Protocol not supported. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCESOCKTNOSUPPORT В 10044 В Socket type not supported. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEOPNOTSUPP В 10045 В Operation not supported on socket. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEPFNOSUPPORT В 10046 В Protocol family not supported. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEAFNOSUPPORT В 10047 В Address family not supported by pro- В
В В В tocol family. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEADDRINUSE В 10048 В Address already in use. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEADDRNOTAVAIL В 10049 В Can not assign requested address. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENETDOWN В 10050 В Network is down. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENETUNREACH В 10051 В Network is unreachable. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENETRESET В 10052 В Network dropped connection on reset. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCECONNABORTED В 10053 В Software caused connection abort. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCECONNRESET В 10054 В Connection reset by peer. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENOBUFS В 10055 В No buffer space available. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEISCONN В 10056 В Socket is already connected. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENOTCONN В 10057 В Socket is not connected. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCESHUTDOWN В 10058 В Cannot send after socket shutdown. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCETOOMANYREFS В 10059 В Too many references: cannot splice. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCETIMEDOUT В 10060 В Connection timed out. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCECONNREFUSED В 10061 В Connection refused. В
БББББББББББББББББББББББББ╔БББББББББББББ╔ББББББББББББББББББББББББББББББББББББББД
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 3. TCP/IP Error Messages В
╙БББББББББББББББББББББББББСБББББББББББББСББББББББББББББББББББББББББББББББББББББЙ
В MESSAGE В CODE В DESCRIPTION В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCELOOP В 10062 В Too many levels of symbolic links. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENAMETOOLONG В 10063 В File name too long. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEHOSTDOWN В 10064 В Host is down. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEHOSTUNREACH В 10065 В No route to host. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCENOTEMPTY В 10066 В Directory not empty. В
╙БББББББББББББББББББББББББТБББББББББББББТББББББББББББББББББББББББББББББББББББББЙ
В SOCEOS2ERR В 10100 В OS/2 error. В
БББББББББББББББББББББББББ╔БББББББББББББ╔ББББББББББББББББББББББББББББББББББББББД
ΓòÉΓòÉΓòÉ 8. Socket Quick Reference ΓòÉΓòÉΓòÉ
The following table describes each protocol-independent socket call supported
by Socket/MPTS for OS/2.
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 4. Socket Quick Reference В
╙БББББББББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В SOCKET CALL В DESCRIPTION В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В accept() В Accepts a connection request from a foreign host. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В bind() В Assigns a local address to the socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В connect() В Requests a connection to a foreign server. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getpeername() В Returns the name of the peer connected to socket В
В В s. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getsockname()mm В Obtains local socket name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getsockopt() В Returns values of options associated with a В
В В socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В ioctl() В Performs special operations on s socket В
В В descriptor. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В listen() В Indicates that a stream socket is ready for a con- В
В В nection request from a foreign client. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В psock_errno() В Produces sort error messages. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В readv() В Reads data on a socket with descriptor s. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В recv() В Receives messages on a connected socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В recvfrom() В Receives messages on a datagram socket, regardless В
В В of its connection status. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В recvmsg() В Receives messages on a socket with descriptor s. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В select() В Returns read, write, and exception status on a В
В В group of sockets. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В send() В Sends packets on a connected socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В sendmsg() В Sends messages on a socket with descriptor s. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В sendto() В Sends packets on a datagram socket, regardless of В
В В its connection status. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В setsockopt() В Sets options associated with a socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В shutdown() В Shuts down all or part of a full-duplex con- В
В В nection. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В sock_errno() В Returns error code set by Socket calls. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В sock_init() В Initializes the socket data structures. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В socket() В Requests that a socket be created. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В soclose() В Closes the socket associated with the descriptor В
В В s. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В writev() В Writes data on a socket with descriptor s. В
БББББББББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББД
The following table describes each protocol-dependent socket call supported by
TCP/IP for OS/2.
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 5. Socket Quick Reference В
╙БББББББББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В SOCKET CALL В DESCRIPTION В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В bswap() В Swaps bytes in a short integer. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В dn_comp() В Compresses the expanded domain name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В dn_expand() В Expands a compressed domain name to a full domain В
В В name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В endhostent() В Closes the SITEINFO and ADDRINFO datasets. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В endnetent() В Closes the SITEINFO dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В endprotoent() В Closes the ETC_PROTOCOLS dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В endservent() В Closes the ETC_SERVICES dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В gethostbyaddr() В Returns information about a host specified by an В
В В address. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В gethostbyname() В Returns information about a host specified by a В
В В name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В gethostent() В Returns a pointer to the next entry in the В
В В SITEINFO dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В gethostid() В Returns the unique identifier of the current host. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В gethostname() В Returns the name of the host processor on which В
В В the program is running. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getnetbyaddr() В Searches the SITEINFO and ADDRINFO datasets for В
В В the specified network address. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getnetbyname() В Searches the ADDRINFO and SITEINFO datasets for В
В В the specified network name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getnetent() В Returns a pointer to the next entry in the В
В В SITEINFO dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getprotobyname() В Searches the ETC_PROTOCOLS dataset for the speci- В
В В fied protocol name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getprotobynumber() В Searches the ETC_Protocols dataset for the speci- В
В В fied protocol number. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getprotoent() В Returns a pointer to the next entry in the В
В В ETC_PROTOCOLS dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getservbyname() В Searches the ETC_SERVICES dataset for the speci- В
В В fied service name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getservbyport() В Searches the ETC_SERVICES dataset for the speci- В
В В fied port number. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getservent() В Returns a pointer the the next entry in the В
В В ETC_SERVICES dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В getsockopt() В Gets the socket options associated with a socket. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В htonl() В Translates byte order from host to network for a В
В В long integer. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В htons() В Translates byte order from host to network for a В
В В short integer. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_addr() В Constructs an internet address from character В
В В strings set in standard dotted-decimal notation. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_lnaof() В Returns the local network portion of an internet В
В В address. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_makeaddr() В Constructs an internet address from a network В
В В number and a local address. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_netof() В Returns the network portion of the internet В
В В address in network byte order. В
БББББББББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББД
┤ББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББББЖ
В Table 5. Socket Quick Reference В
╙БББББББББББББББББББББББББСББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В SOCKET CALL В DESCRIPTION В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_network() В Constructs a network number from character strings В
В В set in standard dotted-decimal notation. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В inet_ntoa() В Returns a pointer to a string in dotted-decimal В
В В notation. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В lswap() В Translates byte order from network to host for a В
В В long integer. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В ntohs() В Translates byte order from network to host for a В
В В short integer. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В res_init() В Reads the RESOLV file for the default domain name. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В res_mkquery() В Makes a query messsage for the name servers in the В
В В Internet domain. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В res_send() В Sends a query to a local name server. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В sethostent() В Opens and rewinds the SITEINFO dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В setnetent() В Opens and rewinds the SITEINFO dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В setprotoent() В Opens and rewinds the ETC_PROTOCOLS dataset. В
╙БББББББББББББББББББББББББТББББББББББББББББББББББББББББББББББББББББББББББББББББЙ
В setservent() В Opens and rewinds the ETC_SERVICES dataset. В
БББББББББББББББББББББББББ╔ББББББББББББББББББББББББББББББББББББББББББББББББББББД
ΓòÉΓòÉΓòÉ 9. Glossary ΓòÉΓòÉΓòÉ
This glossary describes the most common terms associated with TCP/IP
communication in an internet environment, as used in this book.
If you do not find the term you are looking for, see IBM Dictionary of
Computing, SC20-1699.
This glossary includes some terms from IBM Dictionary of Computing.
For abbreviations, the definition usually consists only of the words
represented by the letters; for complete definitions, see the entries for the
words.
ΓòÉΓòÉΓòÉ 9.1. A ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.1.1. ABEND ΓòÉΓòÉΓòÉ
ABEND
The abnormal termination of a program or task.
ΓòÉΓòÉΓòÉ 9.1.2. accelerator key ΓòÉΓòÉΓòÉ
accelerator key
A key or combination of keys that invokes an application-defined function. Also
known as a function key.
ΓòÉΓòÉΓòÉ 9.1.3. action bar ΓòÉΓòÉΓòÉ
action bar
The highlighted area at the top of a panel that contains the choices currently
available in the application program that a user is running.
ΓòÉΓòÉΓòÉ 9.1.4. active open ΓòÉΓòÉΓòÉ
active open
The state of a connection that is actively seeking a service. Contrast with
passive open.
ΓòÉΓòÉΓòÉ 9.1.5. adapter ΓòÉΓòÉΓòÉ
adapter
1. A piece of hardware that connects a computer and an external device.
2. An auxiliary device or unit used to extend the operation of another system.
ΓòÉΓòÉΓòÉ 9.1.6. address ΓòÉΓòÉΓòÉ
address
The unique code assigned to each device or workstation connected to a network.
A standard internet address is a 32-bit address field. This field can be broken
into two parts. The first part contains the network address; the second part
contains the host number.
ΓòÉΓòÉΓòÉ 9.1.7. Address Resolution Protocol (ARP) ΓòÉΓòÉΓòÉ
Address Resolution Protocol (ARP)
A protocol used to dynamically bind an internet address to a hardware address.
ARP is implemented on a single physical network and is limited to networks that
support broadcast addressing.
ΓòÉΓòÉΓòÉ 9.1.8. agent ΓòÉΓòÉΓòÉ
agent
As defined in the SNMP architecture, an agent, or an SNMP server is responsible
for performing the network management functions requested by the network
management stations.
ΓòÉΓòÉΓòÉ 9.1.9. American National Standard Code for Information Interchange (ASCII) ΓòÉΓòÉΓòÉ
American National Standard Code for Information Interchange (ASCII)
1. The standard code, using a coded character set consisting of 7-bit coded
characters (8 bits including parity check), used for information
interchange among data processing systems, data communication systems, and
associated equipment. The ASCII set consists of control characters and
graphic characters.
2. The default file transfer type for FTP, used to transfer files that contain
ASCII text characters.
ΓòÉΓòÉΓòÉ 9.1.10. American National Standards Institute (ANSI) ΓòÉΓòÉΓòÉ
American National Standards Institute (ANSI)
An organization consisting of producers, consumers, and general interest
groups, that establishes the procedures by which accredited organizations
create and maintain voluntary industry standards in the United States.
ΓòÉΓòÉΓòÉ 9.1.11. ANSI ΓòÉΓòÉΓòÉ
ANSI
American National Standards Institute
ΓòÉΓòÉΓòÉ 9.1.12. application ΓòÉΓòÉΓòÉ
application
The use to which an information processing system is put, for example, a
payroll application, an airline reservation application, a network application.
ΓòÉΓòÉΓòÉ 9.1.13. argument ΓòÉΓòÉΓòÉ
argument
A parameter passed between a calling program and a called program.
ΓòÉΓòÉΓòÉ 9.1.14. ARP ΓòÉΓòÉΓòÉ
ARP
Address Resolution Protocol.
ΓòÉΓòÉΓòÉ 9.1.15. ASCII ΓòÉΓòÉΓòÉ
ASCII
American National Standard Code for Information Interchange.
ΓòÉΓòÉΓòÉ 9.1.16. asynchronous ΓòÉΓòÉΓòÉ
asynchronous
Without regular time relationship; unexpected or unpredictable with respect to
the execution of program instruction. See synchronous.
ΓòÉΓòÉΓòÉ 9.1.17. attribute ΓòÉΓòÉΓòÉ
attribute
A characteristic or property. For example, the color of a line, or the length
of a data field.
ΓòÉΓòÉΓòÉ 9.1.18. authentication server ΓòÉΓòÉΓòÉ
authentication server
The service that reads a Kerberos database to verify that a client making a
request for access to an end-service is the client named in the request. The
authentication server provides an authenticated client a ticket as permission
to access the ticket-granting server.
ΓòÉΓòÉΓòÉ 9.1.19. authenticator ΓòÉΓòÉΓòÉ
authenticator
Information encrypted by a Kerberos authentication server that a client
presents along with a ticket to an end-server as permission to access the
service.
ΓòÉΓòÉΓòÉ 9.1.20. authorization ΓòÉΓòÉΓòÉ
authorization
The right granted to a user to communicate with, or to make use of, a computer
system or service.
ΓòÉΓòÉΓòÉ 9.2. B ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.2.1. backbone ΓòÉΓòÉΓòÉ
backbone
1. In a local area network multiple-bridge ring configuration, a high-speed
link to which rings are connected by means of bridges. A backbone can be
configured as a bus or as a ring.
2. In a wide area network, a high-speed link to which nodes or data switching
exchanges (DSES) are connected.
ΓòÉΓòÉΓòÉ 9.2.2. batch ΓòÉΓòÉΓòÉ
batch
1. An accumulation of data to be processed.
2. A group of records or data processing jobs brought together for processing
or transmission.
3. Pertaining to activity involving little or no user action. See interactive.
ΓòÉΓòÉΓòÉ 9.2.3. block ΓòÉΓòÉΓòÉ
block
A string of data elements recorded, processed, or transmitted as a unit. The
elements can be characters, words, or physical records.
ΓòÉΓòÉΓòÉ 9.2.4. Boolean ΓòÉΓòÉΓòÉ
Boolean
A value of 0 or 1 represented internally in binary notation.
ΓòÉΓòÉΓòÉ 9.2.5. bridge ΓòÉΓòÉΓòÉ
bridge
A router that connects two or more networks and forwards packets among them.
The operations carried out by a bridge are done at the physical layer and are
transparent to TCP/IP and TCP/IP routing.
ΓòÉΓòÉΓòÉ 9.2.6. broadcast ΓòÉΓòÉΓòÉ
broadcast
The simultaneous transmission of data packets to all nodes on a network or
subnetwork.
ΓòÉΓòÉΓòÉ 9.2.7. broadcast address ΓòÉΓòÉΓòÉ
broadcast address
An address that is common to all nodes on a network.
ΓòÉΓòÉΓòÉ 9.2.8. bus topology ΓòÉΓòÉΓòÉ
bus topology
A network configuration in which only one path is maintained between stations.
Any data transmitted by a station is concurrently available to all other
stations on the link.
ΓòÉΓòÉΓòÉ 9.2.9. button ΓòÉΓòÉΓòÉ
button
1. A mechanism on a pointing device, such as a mouse, used to request or
initiate an action.
2. A rounded-corner rectangle with text inside, used in graphics applications
for actions that occur when the pushbutton is selected.
ΓòÉΓòÉΓòÉ 9.3. C ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.3.1. case-sensitive ΓòÉΓòÉΓòÉ
case-sensitive
A condition in which entries for an entry field must conform to a specific
lower -, upper -, or mixed-case format in order to be valid.
ΓòÉΓòÉΓòÉ 9.3.2. checksum ΓòÉΓòÉΓòÉ
checksum
The sum of a group of data associated with the group and used for checking
purposes.
ΓòÉΓòÉΓòÉ 9.3.3. Class A network ΓòÉΓòÉΓòÉ
Class A network
An internet network in which the high-order bit of the address is 0. The host
number occupies the three low-order octets.
ΓòÉΓòÉΓòÉ 9.3.4. Class B network ΓòÉΓòÉΓòÉ
Class B network
An internet network in which the high-order bit of the address is 1 and the
next high-order bit is 0. The host number occupies the two low-order octets.
ΓòÉΓòÉΓòÉ 9.3.5. Class C network ΓòÉΓòÉΓòÉ
Class C network
An internet network in which the two high-order bits of the address are 1 and
the next high-order bit is 0. The host number occupies the low-order octet.
ΓòÉΓòÉΓòÉ 9.3.6. click ΓòÉΓòÉΓòÉ
click
To press and release the select button on a mouse.
ΓòÉΓòÉΓòÉ 9.3.7. client ΓòÉΓòÉΓòÉ
client
A function that requests services from a server, and makes them available to
the user.
ΓòÉΓòÉΓòÉ 9.3.8. client-server relationship ΓòÉΓòÉΓòÉ
client-server relationship
A device that provides resources or services to other devices on a network is a
server. A device that employs the resources provided by a server is a client.
ΓòÉΓòÉΓòÉ 9.3.9. clipboard ΓòÉΓòÉΓòÉ
clipboard
A temporary storage area used for copying and storing data.
ΓòÉΓòÉΓòÉ 9.3.10. CMS ΓòÉΓòÉΓòÉ
CMS
Conversational Monitor System
ΓòÉΓòÉΓòÉ 9.3.11. command ΓòÉΓòÉΓòÉ
command
The name and any parameters associated with an action that can be performed by
a program. The command is entered by the user; the computer performs the action
requested by the command name.
ΓòÉΓòÉΓòÉ 9.3.12. command prompt ΓòÉΓòÉΓòÉ
command prompt
A displayed symbol, such as НC:\┘ that requests input from a user.
ΓòÉΓòÉΓòÉ 9.3.13. Communications Manager ΓòÉΓòÉΓòÉ
Communications Manager
A component of OS/2 that allows a workstation to connect to a host computer and
use the host resources as well as the resources of other personal computers to
which the workstation is attached, either directly or through a host.
ΓòÉΓòÉΓòÉ 9.3.14. community name ΓòÉΓòÉΓòÉ
community name
The name of a group of hosts that share SNMP management network information.
ΓòÉΓòÉΓòÉ 9.3.15. compile ΓòÉΓòÉΓòÉ
compile
1. To translate a program written in a high-level language into a machine
language program.
2. The computer actions required to transform a source file into an executable
object file.
ΓòÉΓòÉΓòÉ 9.3.16. Compiler ΓòÉΓòÉΓòÉ
Compiler
A program that translates a source program into an executable program (an
object program).
ΓòÉΓòÉΓòÉ 9.3.17. CONFIG.SYS ΓòÉΓòÉΓòÉ
CONFIG.SYS
A file that contains the configuration options for an OS/2 personal computer.
ΓòÉΓòÉΓòÉ 9.3.18. configuration file ΓòÉΓòÉΓòÉ
configuration file
For the base operating system, the CONFIG.SYS file that describes the devices,
system parameters, and resource options of a personal computer.
ΓòÉΓòÉΓòÉ 9.3.19. connection ΓòÉΓòÉΓòÉ
connection
1. An association established between functional units for conveying
information.
2. The path between two protocol modules that provides reliable stream
delivery service. In an internet, a connection extends from a TCP module on
one machine to a TCP module on the other.
ΓòÉΓòÉΓòÉ 9.3.20. conversational monitor system (CMS) ΓòÉΓòÉΓòÉ
conversational monitor system (CMS)
A virtual machine operating system that provides general interactive time
sharing, problem solving, and program development capabilities, and operates
only under control of the VM/370 VM control program.
ΓòÉΓòÉΓòÉ 9.4. D ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.4.1. daemon ΓòÉΓòÉΓòÉ
daemon
A background process usually started at system initialization that runs
continuously and performs a function required by other processes.
ΓòÉΓòÉΓòÉ 9.4.2. datagram ΓòÉΓòÉΓòÉ
datagram
The basic unit of information that is passed across the internet, it consists
of one or more data packets.
ΓòÉΓòÉΓòÉ 9.4.3. data set ΓòÉΓòÉΓòÉ
data set
The major unit of data storage and retrieval in MVS, consisting of a collection
of data in one of several prescribed arrangements and described by control
information to which the system has access. Synonymous with file in VM and
OS/2.
ΓòÉΓòÉΓòÉ 9.4.4. default ΓòÉΓòÉΓòÉ
default
A value, attribute or option that is assumed when none is explicitly specified.
ΓòÉΓòÉΓòÉ 9.4.5. destination node ΓòÉΓòÉΓòÉ
destination node
The node to which a request or data is sent.
ΓòÉΓòÉΓòÉ 9.4.6. dialog box ΓòÉΓòÉΓòÉ
dialog box
A movable window, fixed in size, which provides information that is required by
an application to continue your request.
ΓòÉΓòÉΓòÉ 9.4.7. directory ΓòÉΓòÉΓòÉ
directory
A named grouping of files in a file system.
ΓòÉΓòÉΓòÉ 9.4.8. Distributed Program Interface ΓòÉΓòÉΓòÉ
Distributed Program Interface
The SNMP DPI is a programming interface that provides an extension to the
functionality provided by the SNMP agents.
ΓòÉΓòÉΓòÉ 9.4.9. DLL ΓòÉΓòÉΓòÉ
DLL
Dynamic Link Library
ΓòÉΓòÉΓòÉ 9.4.10. DNS ΓòÉΓòÉΓòÉ
DNS
Domain Name System
ΓòÉΓòÉΓòÉ 9.4.11. domain ΓòÉΓòÉΓòÉ
domain
In an internet, a part of the naming hierarchy. Syntactically, a domain name
consists of a sequence of names (labels) separated by periods (dots).
ΓòÉΓòÉΓòÉ 9.4.12. Domain Name System ΓòÉΓòÉΓòÉ
Domain Name System
A system in which a resolver queries name servers for resource records about a
host.
ΓòÉΓòÉΓòÉ 9.4.13. domain naming ΓòÉΓòÉΓòÉ
domain naming
A hierarchical system for naming network resources.
ΓòÉΓòÉΓòÉ 9.4.14. dotted-decimal notation ΓòÉΓòÉΓòÉ
dotted-decimal notation
The syntactic representation for a 32-bit integer that consists of four 8-bit
numbers, written in base 10 and separated by periods (dots). many internet
application programs accept dotted decimal notations in place of destination
machine names.
ΓòÉΓòÉΓòÉ 9.4.15. double-precision ΓòÉΓòÉΓòÉ
double-precision
A specification that causes a floating-point value to be stored internally in
the long format.
ΓòÉΓòÉΓòÉ 9.4.16. DPI ΓòÉΓòÉΓòÉ
DPI
Distributed Program Interface.
ΓòÉΓòÉΓòÉ 9.4.17. dragging ΓòÉΓòÉΓòÉ
dragging
Moving an object on the display screen as if it were attached to the pointer,
or mouse; performed by holding the select button and moving the pointer.
ΓòÉΓòÉΓòÉ 9.4.18. drive ΓòÉΓòÉΓòÉ
drive
The device used to read and write data on disks or diskettes.
ΓòÉΓòÉΓòÉ 9.4.19. dynamic link library (DLL) ΓòÉΓòÉΓòÉ
dynamic link library (DLL)
A module containing dynamic link routines that is linked at load or run time.
ΓòÉΓòÉΓòÉ 9.5. E ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.5.1. EBCDIC ΓòÉΓòÉΓòÉ
EBCDIC
Extended binary-coded decimal interchange code.
ΓòÉΓòÉΓòÉ 9.5.2. encapsulation ΓòÉΓòÉΓòÉ
encapsulation
A process used by layered protocols in which a lower level protocol accepts a
message from a higher level protocol and places it in the data portion of the
low level frame.
ΓòÉΓòÉΓòÉ 9.5.3. entry field ΓòÉΓòÉΓòÉ
entry field
A panel element, usually highlighted in some manner and usually with its
boundaries indicated, where users type in information.
ΓòÉΓòÉΓòÉ 9.5.4. Ethernet ΓòÉΓòÉΓòÉ
Ethernet
The name given to a local area packet-switched network technology invented in
the early 1970s by Xerox Incorporated. Ethernet uses a Carrier Sense Multiple
Access/Collision Detection (CSMA/CD) mechanism to send packets.
ΓòÉΓòÉΓòÉ 9.5.5. extended binary-coded decimal interchange code (EBCDIC) ΓòÉΓòÉΓòÉ
extended binary-coded decimal interchange code (EBCDIC)
A coded character set consisting of 8-bit coded characters.
ΓòÉΓòÉΓòÉ 9.5.6. eXternal Data Representation (XDR) ΓòÉΓòÉΓòÉ
eXternal Data Representation (XDR)
A standard developed by SUN Microsystems Incorporated for representing data in
machine-independent format.
ΓòÉΓòÉΓòÉ 9.6. F ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.6.1. file ΓòÉΓòÉΓòÉ
file
In VM and OS/2, a named set of records stored or processed as a unit.
Synonymous with data set in MVS.
ΓòÉΓòÉΓòÉ 9.6.2. File Transfer Protocol (FTP) ΓòÉΓòÉΓòÉ
File Transfer Protocol (FTP)
A TCP/IP protocol used for transferring files to and from foreign hosts. FTP
also provides the capability to access directories. Password protection is
provided as part of the protocol.
ΓòÉΓòÉΓòÉ 9.6.3. folder ΓòÉΓòÉΓòÉ
folder
In LaMail, a collection of mail files that share a common attribute, such as
userid, location, or subject.
ΓòÉΓòÉΓòÉ 9.6.4. foreign host ΓòÉΓòÉΓòÉ
foreign host
Any host on the network including the local host.
ΓòÉΓòÉΓòÉ 9.6.5. foreign network ΓòÉΓòÉΓòÉ
foreign network
In an internet, any other network interconnected to the local network by one or
more intermediate gateways or routers.
ΓòÉΓòÉΓòÉ 9.6.6. foreign node ΓòÉΓòÉΓòÉ
foreign node
See foreign host.
ΓòÉΓòÉΓòÉ 9.6.7. FTAM ΓòÉΓòÉΓòÉ
FTAM
File Transfer Access and Management.
ΓòÉΓòÉΓòÉ 9.6.8. FTP ΓòÉΓòÉΓòÉ
FTP
File Transfer Protocol.
ΓòÉΓòÉΓòÉ 9.7. G ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.7.1. gateway ΓòÉΓòÉΓòÉ
gateway
1. A functional unit that interconnects a local data network with another
network having different protocols.
2. A host that connects a TCP/IP network to a non-TCP/IP network at the
application layer. See also router.
ΓòÉΓòÉΓòÉ 9.8. H ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.8.1. handle ΓòÉΓòÉΓòÉ
handle
A temporary data representation that identifies a file.
ΓòÉΓòÉΓòÉ 9.8.2. header file ΓòÉΓòÉΓòÉ
header file
A file that contains constant declarations, type declarations, and variable
declarations and assignments. Header files are supplied with all programming
interfaces.
ΓòÉΓòÉΓòÉ 9.8.3. High Performance File System (HPFS) ΓòÉΓòÉΓòÉ
High Performance File System (HPFS)
An installable file system (IFS) designed to provide better performance than
the existing file allocation table (FAT) based file system. HPFS is designed to
provide extremely fast access to very large disk volumes.
ΓòÉΓòÉΓòÉ 9.8.4. hop count ΓòÉΓòÉΓòÉ
hop count
The number of hosts through which a packet passes on its way to its
destination.
ΓòÉΓòÉΓòÉ 9.8.5. host computer ΓòÉΓòÉΓòÉ
host computer
1. In a computer network, a computer that usually performs network control
functions and provides end users with services such as computation and
database access.
2. The primary or controlling computer in a multiple computer installation.
3. A computer used to prepare programs for use on another computer or on
another data processing system; for example, a computer used to compile,
link edit, or test programs to be used on another system.
4. A computer connected to a network, which provides an access method to that
network.
ΓòÉΓòÉΓòÉ 9.8.6. HPFS ΓòÉΓòÉΓòÉ
HPFS
High Performance File System
ΓòÉΓòÉΓòÉ 9.9. I ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.9.1. ICAT (Installation Configuration Automation Tool) ΓòÉΓòÉΓòÉ
ICAT (Installation Configuration Automation Tool)
TCP/IP for OS/2 provides this application for installing and configuring TCP/IP
for OS/2.
ΓòÉΓòÉΓòÉ 9.9.2. ICMP ΓòÉΓòÉΓòÉ
ICMP
Internet Control Message Protocol.
ΓòÉΓòÉΓòÉ 9.9.3. IEEE ΓòÉΓòÉΓòÉ
IEEE
Institute of Electrical and Electronic Engineers.
ΓòÉΓòÉΓòÉ 9.9.4. include file ΓòÉΓòÉΓòÉ
include file
A file that contains preprocessor text, which is called by a program, using a
standard programming call. Synonymous with header file.
ΓòÉΓòÉΓòÉ 9.9.5. installation ΓòÉΓòÉΓòÉ
installation
The process of placing one or more OS/2 components on a personal computer's
fixed disk.
ΓòÉΓòÉΓòÉ 9.9.6. instance ΓòÉΓòÉΓòÉ
instance
One of the three parts of a Kerberos name. Instance specifies the machine on
which a service is run.
ΓòÉΓòÉΓòÉ 9.9.7. Institute of Electrical and Electronic Engineers (IEEE) ΓòÉΓòÉΓòÉ
Institute of Electrical and Electronic Engineers (IEEE)
An electronics industry organization.
ΓòÉΓòÉΓòÉ 9.9.8. Integrated Services Digital Network (ISDN) ΓòÉΓòÉΓòÉ
Integrated Services Digital Network (ISDN)
A digital end-to-end telecommunication network that supports multiple services
including, but not limited to, voice and data.
ΓòÉΓòÉΓòÉ 9.9.9. interactive ΓòÉΓòÉΓòÉ
interactive
Pertaining to a program or a system that alternately accepts input and then
responds. An interactive system is conversational, that is, a continuous dialog
exists between user and system. See batch.
ΓòÉΓòÉΓòÉ 9.9.10. International Organization for Standardization (ISO) ΓòÉΓòÉΓòÉ
International Organization for Standardization (ISO)
An organization of national standards bodies from various countries established
to promote development of standards to facilitate international exchange of
goods and services, and develop cooperation in intellectual, scientific,
technological, and economic activity.
ΓòÉΓòÉΓòÉ 9.9.11. internet or internetwork ΓòÉΓòÉΓòÉ
internet or internetwork
A collection of packet switching networks interconnected by gateways, routers,
bridges, and hosts to function as a single, coordinated, virtual network.
ΓòÉΓòÉΓòÉ 9.9.12. internet address ΓòÉΓòÉΓòÉ
internet address
The unique 32-bit address identifying each node in an internet. See also
address.
ΓòÉΓòÉΓòÉ 9.9.13. Internet Control Message Protocol (ICMP) ΓòÉΓòÉΓòÉ
Internet Control Message Protocol (ICMP)
The part of the Internet Protocol layer that handles error messages and control
messages.
ΓòÉΓòÉΓòÉ 9.9.14. Internet Protocol (IP) ΓòÉΓòÉΓòÉ
Internet Protocol (IP)
The TCP/IP layer between the higher level host-to-host protocol and the local
network protocols. IP uses local area network protocols to carry packets, in
the form of datagrams, to the next gateway, router, or destination host.
ΓòÉΓòÉΓòÉ 9.9.15. interoperability ΓòÉΓòÉΓòÉ
interoperability
The capability of different hardware and software by different vendors to
effectively communicate together.
ΓòÉΓòÉΓòÉ 9.9.16. IP ΓòÉΓòÉΓòÉ
IP
Internet Protocol.
ΓòÉΓòÉΓòÉ 9.9.17. ISDN ΓòÉΓòÉΓòÉ
ISDN
Integrated Services Digital Network.
ΓòÉΓòÉΓòÉ 9.9.18. ISO ΓòÉΓòÉΓòÉ
ISO
International Organization for Standardization.
ΓòÉΓòÉΓòÉ 9.10. K ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.10.1. Kerberos Authentication System ΓòÉΓòÉΓòÉ
Kerberos Authentication System
An authentication mechanism used to check authorization at the user level.
ΓòÉΓòÉΓòÉ 9.11. L ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.11.1. LaMail ΓòÉΓòÉΓòÉ
LaMail
The client that communicates with the OS/2 Presentation Manager to manage mail
on the network.
ΓòÉΓòÉΓòÉ 9.11.2. LAN ΓòÉΓòÉΓòÉ
LAN
Local area network.
ΓòÉΓòÉΓòÉ 9.11.3. Line printer daemon (LPD) ΓòÉΓòÉΓòÉ
Line printer daemon (LPD)
The remote printer server that allows other hosts to print on a printer local
to your host.
ΓòÉΓòÉΓòÉ 9.11.4. Line Printer Protocol ΓòÉΓòÉΓòÉ
Line Printer Protocol
A TCP/IP protocol used for printing files on printers attached to remote hosts.
ΓòÉΓòÉΓòÉ 9.11.5. local area network (LAN) ΓòÉΓòÉΓòÉ
local area network (LAN)
A data network located on the user's premises in which serial transmission is
used for direct data communication among data stations.
ΓòÉΓòÉΓòÉ 9.11.6. local host ΓòÉΓòÉΓòÉ
local host
In an internet, the computer to which a user's terminal is directly connected
without using the internet.
ΓòÉΓòÉΓòÉ 9.11.7. local network ΓòÉΓòÉΓòÉ
local network
The portion of a network that is physically connected to the host without
intermediate gateways or routers.
ΓòÉΓòÉΓòÉ 9.11.8. Logical ANDing ΓòÉΓòÉΓòÉ
Logical ANDing
When the Boolean operator AND is applied to two bits, the result is one when
both bits are one; otherwise, the result is zero. When two bytes are ANDed,
each pair of bits is handled separately; there is no connection from one bit
position to another.
ΓòÉΓòÉΓòÉ 9.11.9. Loopback ΓòÉΓòÉΓòÉ
Loopback
The local loopback interface bypasses the network interface drivers to provide
a direct internal connection back to the local internet protocol support.
ΓòÉΓòÉΓòÉ 9.11.10. LPD ΓòÉΓòÉΓòÉ
LPD
Line printer daemon.
ΓòÉΓòÉΓòÉ 9.11.11. LPR ΓòÉΓòÉΓòÉ
LPR
A client command that allows the local host to submit a file to be printed on a
remote print server.
ΓòÉΓòÉΓòÉ 9.12. M ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.12.1. Management Information Base (MIB) ΓòÉΓòÉΓòÉ
Management Information Base (MIB)
A standard used to define SNMP objects, such as packet counts and routing
tables, that are in a TCP/IP environment.
ΓòÉΓòÉΓòÉ 9.12.2. mapping ΓòÉΓòÉΓòÉ
mapping
The process of relating internet addresses to physical addresses in the
network.
ΓòÉΓòÉΓòÉ 9.12.3. MARK ΓòÉΓòÉΓòÉ
MARK
A Presentation Manager function that marks a section of text to be copied or
cut.
ΓòÉΓòÉΓòÉ 9.12.4. marshall ΓòÉΓòÉΓòÉ
marshall
To copy data into an RPC packet. Stubs perform marshalling. See also
unmarshall.
ΓòÉΓòÉΓòÉ 9.12.5. mask ΓòÉΓòÉΓòÉ
mask
1. A pattern of characters used to control retention or elimination of
portions of another pattern of characters.
2. To use a pattern of characters to control retention or elimination of
another pattern of characters.
3. A pattern of characters that controls the keeping, deleting, or testing of
portions of another pattern of characters.
ΓòÉΓòÉΓòÉ 9.12.6. menu ΓòÉΓòÉΓòÉ
menu
A type of panel that consists of one or more selection fields.
ΓòÉΓòÉΓòÉ 9.12.7. menu item ΓòÉΓòÉΓòÉ
menu item
A selection item on a pull-down menu.
ΓòÉΓòÉΓòÉ 9.12.8. MIB ΓòÉΓòÉΓòÉ
MIB
Management Information Base.
ΓòÉΓòÉΓòÉ 9.12.9. mouse ΓòÉΓòÉΓòÉ
mouse
A device that is used to move a pointer on the screen and select items.
ΓòÉΓòÉΓòÉ 9.12.10. multitasking ΓòÉΓòÉΓòÉ
multitasking
A mode of operation that provides for the concurrent performance execution of
two or more tasks.
ΓòÉΓòÉΓòÉ 9.12.11. MVS ΓòÉΓòÉΓòÉ
MVS
Multiple Virtual Storage.
ΓòÉΓòÉΓòÉ 9.13. N ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.13.1. name server ΓòÉΓòÉΓòÉ
name server
The server that stores resource records about hosts.
ΓòÉΓòÉΓòÉ 9.13.2. NCP ΓòÉΓòÉΓòÉ
NCP
Network Control Program.
ΓòÉΓòÉΓòÉ 9.13.3. NCS ΓòÉΓòÉΓòÉ
NCS
Network Computing System.
ΓòÉΓòÉΓòÉ 9.13.4. network ΓòÉΓòÉΓòÉ
network
An arrangement of nodes and connecting branches. Connections are made between
data stations.
ΓòÉΓòÉΓòÉ 9.13.5. network adapter ΓòÉΓòÉΓòÉ
network adapter
A physical device, and its associated software, that enables a processor or
controller to be connected to a network.
ΓòÉΓòÉΓòÉ 9.13.6. network administrator ΓòÉΓòÉΓòÉ
network administrator
The person responsible for the installation, management, control, and
configuration of a network.
ΓòÉΓòÉΓòÉ 9.13.7. Network Computing System (NCS) ΓòÉΓòÉΓòÉ
Network Computing System (NCS)
Network Computing System. A set of software components developed by Apollo that
conform to the Network Computing Architecture (NCA). NCS is made up of two
parts: the nidl Compiler and Network Computing Kernel (NCK).
ΓòÉΓòÉΓòÉ 9.13.8. network control program (NCP) ΓòÉΓòÉΓòÉ
network control program (NCP)
An IBM-licensed program that provides communication controller support for
single-domain, multiple-domain, and interconnected network capability.
ΓòÉΓòÉΓòÉ 9.13.9. network elements ΓòÉΓòÉΓòÉ
network elements
As defined in the SNMP architecture, network elements are gateways, routers,
and hosts that contain management agents responsible for performing the network
management functions requested by the network management stations.
ΓòÉΓòÉΓòÉ 9.13.10. network file system (NFS) ΓòÉΓòÉΓòÉ
network file system (NFS)
The NFS protocol, which was developed by Sun Microsystems Incorporated, allows
computers in a network to access each other's file systems. Once accessed, the
file system appears to reside on the local host.
ΓòÉΓòÉΓòÉ 9.13.11. network management stations ΓòÉΓòÉΓòÉ
network management stations
As defined in the SNMP architecture, network management stations, or SNMP
clients, execute management applications that monitor and control network
elements.
ΓòÉΓòÉΓòÉ 9.13.12. NFS ΓòÉΓòÉΓòÉ
NFS
Network file system.
ΓòÉΓòÉΓòÉ 9.13.13. node ΓòÉΓòÉΓòÉ
node
1. In a network, a point at which one or more functional units connect
channels or data circuits.
2. In a network topology, the point at an end of a branch.
ΓòÉΓòÉΓòÉ 9.14. O ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.14.1. octet ΓòÉΓòÉΓòÉ
octet
A byte composed of eight binary elements.
ΓòÉΓòÉΓòÉ 9.14.2. open system ΓòÉΓòÉΓòÉ
open system
A system with specified standards and that therefore can be readily connected
to other systems that comply with the same standards.
ΓòÉΓòÉΓòÉ 9.14.3. Open Systems Interconnection (OSI) ΓòÉΓòÉΓòÉ
Open Systems Interconnection (OSI)
1. The interconnection of open systems in accordance with specific ISO
standards.
2. The use of standardized procedures to enable the interconnection of data
processing systems.
ΓòÉΓòÉΓòÉ 9.14.4. OS/2 ΓòÉΓòÉΓòÉ
OS/2
Operating System/2.
ΓòÉΓòÉΓòÉ 9.14.5. OSI ΓòÉΓòÉΓòÉ
OSI
Open Systems Interconnection.
ΓòÉΓòÉΓòÉ 9.15. P ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.15.1. packet ΓòÉΓòÉΓòÉ
packet
A sequence of binary digits, including data and control signals, that is
transmitted and switched as a composite whole.
ΓòÉΓòÉΓòÉ 9.15.2. parameter ΓòÉΓòÉΓòÉ
parameter
A variable that is given a constant value for a specified application.
ΓòÉΓòÉΓòÉ 9.15.3. parse ΓòÉΓòÉΓòÉ
parse
To analyze the operands entered with a command.
ΓòÉΓòÉΓòÉ 9.15.4. passive open ΓòÉΓòÉΓòÉ
passive open
The state of a connection that is prepared to provide a service on demand.
Contrast with active open.
ΓòÉΓòÉΓòÉ 9.15.5. path ΓòÉΓòÉΓòÉ
path
The course or route of drives and subdirectories leading from the root
directory and drive of an operating system to where files or data information
are stored.
ΓòÉΓòÉΓòÉ 9.15.6. PC ΓòÉΓòÉΓòÉ
PC
Personal computer.
ΓòÉΓòÉΓòÉ 9.15.7. PC Network ΓòÉΓòÉΓòÉ
PC Network
A low-cost broadband network that allows attached IBM personal computers, such
as IBM 5150 Personal Computers, IBM Computer ATs, IBM PC/XTs, and IBM Portable
Personal Computers to communicate and to share resources.
ΓòÉΓòÉΓòÉ 9.15.8. PDU ΓòÉΓòÉΓòÉ
PDU
Protocol Data Units
ΓòÉΓòÉΓòÉ 9.15.9. peer-to-peer ΓòÉΓòÉΓòÉ
peer-to-peer
In network architecture, any functional unit that resides in the same layer as
another entity.
ΓòÉΓòÉΓòÉ 9.15.10. PING ΓòÉΓòÉΓòÉ
PING
The command that sends an ICMP Echo Request packet to a gateway, router, or
host with the expectation of receiving a reply.
ΓòÉΓòÉΓòÉ 9.15.11. piping ΓòÉΓòÉΓòÉ
piping
in advanced DOS, a feature that allows the output of a program as it is
displayed on the screen to be used as input to another program without
reentering the data on the keyboard.
ΓòÉΓòÉΓòÉ 9.15.12. port ΓòÉΓòÉΓòÉ
port
1. An endpoint for communication between devices, generally referring to a
logical connection.
2. A 16-bit number identifying a particular Transmission Control Protocol or
User Datagram Protocol resource within a given TCP/IP node.
ΓòÉΓòÉΓòÉ 9.15.13. Portmapper ΓòÉΓòÉΓòÉ
Portmapper
A program that maps client programs to the port numbers of server programs.
Portmapper is used with Remote Procedure Call (RPC) programs.
ΓòÉΓòÉΓòÉ 9.15.14. Presentation Manager ΓòÉΓòÉΓòÉ
Presentation Manager
A component of OS/2 that provides a complete graphics-based user interface,
with pull-down windows, action bars, and layered menus.
ΓòÉΓòÉΓòÉ 9.15.15. principal name ΓòÉΓòÉΓòÉ
principal name
One of the three parts of a Kerberos name. Principal name specifies the name of
a user or service.
ΓòÉΓòÉΓòÉ 9.15.16. process ΓòÉΓòÉΓòÉ
process
1. A unique, finite course of events defined by its purpose or by its effect,
achieved under defined conditions.
2. Any operation or combination of operations on data.
3. A function being performed or waiting to be performed.
4. A program in operation; for example, a daemon is a system process that is
always running on the system.
ΓòÉΓòÉΓòÉ 9.15.17. protocol ΓòÉΓòÉΓòÉ
protocol
A set of semantic and syntactic rules that determines the behavior of
functional units in achieving communication. Protocols can determine low-level
details of machine-to-machine interfaces, such as the order in which bits from
a byte are sent; they can also determine high-level exchanges between
application programs, such as file transfer.
ΓòÉΓòÉΓòÉ 9.15.18. Protocol Data Unit (PDU) ΓòÉΓòÉΓòÉ
Protocol Data Unit (PDU)
A set of commands used by the SNMP agent to request management station data.
ΓòÉΓòÉΓòÉ 9.15.19. protocol suite ΓòÉΓòÉΓòÉ
protocol suite
A set of protocols that cooperate to handle the transmission tasks for a data
communication system.
ΓòÉΓòÉΓòÉ 9.15.20. pull-down ΓòÉΓòÉΓòÉ
pull-down
An extension of the action bar that displays a list of choices that are
available for a selected action bar choice.
ΓòÉΓòÉΓòÉ 9.16. R ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.16.1. RAM ΓòÉΓòÉΓòÉ
RAM
Random Access Memory.
ΓòÉΓòÉΓòÉ 9.16.2. Random Access Memory (RAM) ΓòÉΓòÉΓòÉ
Random Access Memory (RAM)
A memory device into which data is entered and from which data is retrieved in
a nonsequential manner.
ΓòÉΓòÉΓòÉ 9.16.3. RARP ΓòÉΓòÉΓòÉ
RARP
Reverse Address Resolution Protocol.
ΓòÉΓòÉΓòÉ 9.16.4. realm ΓòÉΓòÉΓòÉ
realm
One of the three parts of a Kerberos name. Realm specifies the service that
provides authentication for the principal name. Realm can also specify the name
of an administrative entry that is responsible for its own database on its own
Kerberos machine.
ΓòÉΓòÉΓòÉ 9.16.5. Remote Execution Protocol (REXEC) ΓòÉΓòÉΓòÉ
Remote Execution Protocol (REXEC)
A protocol that allows the execution of a command or program on a foreign host.
The local host receives the results of the command execution. This protocol
uses the REXEC command.
ΓòÉΓòÉΓòÉ 9.16.6. remote host ΓòÉΓòÉΓòÉ
remote host
Any foreign host, not including the local host.
ΓòÉΓòÉΓòÉ 9.16.7. remote logon ΓòÉΓòÉΓòÉ
remote logon
The process by which a terminal user establishes a terminal session with a
remote host.
ΓòÉΓòÉΓòÉ 9.16.8. Remote Procedure Call (RPC) ΓòÉΓòÉΓòÉ
Remote Procedure Call (RPC)
A facility that a client uses to request the execution of a procedure call from
a server. This facility includes a library of procedures and an eXternal data
representation.
ΓòÉΓòÉΓòÉ 9.16.9. Request For Comments (RFC) ΓòÉΓòÉΓòÉ
Request For Comments (RFC)
A series of documents that covers a broad range of topics affecting
internetwork communication. Some RFCs are established as internet standards.
ΓòÉΓòÉΓòÉ 9.16.10. resolver ΓòÉΓòÉΓòÉ
resolver
A program or subroutine that obtains information from a name server or local
table for use by the calling program.
ΓòÉΓòÉΓòÉ 9.16.11. resource records ΓòÉΓòÉΓòÉ
resource records
Individual records of data used by the Domain Name System. Examples of resource
records include the following: a host's Internet Protocol addresses, preferred
mail addresses, and aliases.
ΓòÉΓòÉΓòÉ 9.16.12. return code ΓòÉΓòÉΓòÉ
return code
1. A code used to influence the execution of succeeding instructions.
2. A value returned to a program to indicate the results of an operation
requested by that program.
ΓòÉΓòÉΓòÉ 9.16.13. Reverse Address Resolution Protocol (RARP) ΓòÉΓòÉΓòÉ
Reverse Address Resolution Protocol (RARP)
A protocol that maintains a database of mappings between physical hardware
addresses and IP addresses.
ΓòÉΓòÉΓòÉ 9.16.14. REXEC ΓòÉΓòÉΓòÉ
REXEC
Remote Execution Protocol.
ΓòÉΓòÉΓòÉ 9.16.15. RFC ΓòÉΓòÉΓòÉ
RFC
Request For Comments.
ΓòÉΓòÉΓòÉ 9.16.16. RIP ΓòÉΓòÉΓòÉ
RIP
Routing Information Protocol.
ΓòÉΓòÉΓòÉ 9.16.17. router ΓòÉΓòÉΓòÉ
router
A device that connects networks at the ISO Network Layer. A router is
protocol-dependent and connects only networks operating the same protocol.
Routers do more than transmit data; they also select the best transmission
paths and optimum sizes for packets. In TCP/IP, routers operate at the
Internetwork layer. See also gateway.
ΓòÉΓòÉΓòÉ 9.16.18. Routing Information Protocol (RIP) ΓòÉΓòÉΓòÉ
Routing Information Protocol (RIP)
The protocol that maintains routing table entries for gateways, routers, and
hosts.
ΓòÉΓòÉΓòÉ 9.16.19. routing table ΓòÉΓòÉΓòÉ
routing table
A list of network numbers and the information needed to route packets to each.
ΓòÉΓòÉΓòÉ 9.16.20. RPC ΓòÉΓòÉΓòÉ
RPC
Remote Procedure Call.
ΓòÉΓòÉΓòÉ 9.17. S ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.17.1. Sendmail ΓòÉΓòÉΓòÉ
Sendmail
The OS/2 mail server that uses Simple Mail Transfer Protocol to route mail from
one host to another host on the network.
ΓòÉΓòÉΓòÉ 9.17.2. serial line ΓòÉΓòÉΓòÉ
serial line
A network media that is a de facto standard, not an international standard,
commonly used for point-to-point TCP/IP connections. Generally, a serial line
consists of an RS-232 connection into a modem and over a telephone line.
ΓòÉΓòÉΓòÉ 9.17.3. server ΓòÉΓòÉΓòÉ
server
A function that provides services for users. A machine can run client and
server processes at the same time.
ΓòÉΓòÉΓòÉ 9.17.4. Simple Mail Transfer Protocol (SMTP) ΓòÉΓòÉΓòÉ
Simple Mail Transfer Protocol (SMTP)
A TCP/IP application protocol used to transfer mail between users on different
systems. SMTP specifies how mail systems interact and the format of control
messages they use to transfer mail.
ΓòÉΓòÉΓòÉ 9.17.5. Simple Network Management Protocol (SNMP) ΓòÉΓòÉΓòÉ
Simple Network Management Protocol (SNMP)
A protocol that allows network management by elements, such as gateways,
routers, and hosts. This protocol provides a means of communication between
network elements regarding network resources.
ΓòÉΓòÉΓòÉ 9.17.6. SMI ΓòÉΓòÉΓòÉ
SMI
Structure for Management Information.
ΓòÉΓòÉΓòÉ 9.17.7. SMTP ΓòÉΓòÉΓòÉ
SMTP
Simple Mail Transfer Protocol.
ΓòÉΓòÉΓòÉ 9.17.8. SNMP ΓòÉΓòÉΓòÉ
SNMP
Simple Network Management Protocol.
ΓòÉΓòÉΓòÉ 9.17.9. socket ΓòÉΓòÉΓòÉ
socket
1. An endpoint for communication between processes or applications.
2. A pair consisting of TCP port and IP address, or UDP port and IP address.
ΓòÉΓòÉΓòÉ 9.17.10. socket interface ΓòÉΓòÉΓòÉ
socket interface
An application interface that allows users to write their own applications to
supplement those supplied by TCP/IP.
ΓòÉΓòÉΓòÉ 9.17.11. stream ΓòÉΓòÉΓòÉ
stream
A continuous sequence of data elements being transmitted, or intended for
transmission, in character or binary-digit form, using a defined format.
ΓòÉΓòÉΓòÉ 9.17.12. stubs ΓòÉΓòÉΓòÉ
stubs
1. A program module that transfers remote procedure calls and responses
between a client and a server. Stubs perform marshalling, unmarshalling and
data format conversion. Both clients and servers have stubs. The NIDL
Compiler generates client and server stub code from an interface
definition.
2. Hooking functions used as extensions to the protocol to generate protocol
requests for X Window System.
ΓòÉΓòÉΓòÉ 9.17.13. subagent ΓòÉΓòÉΓòÉ
subagent
In the SNMP architecture, a subagent provides an extension to the functionality
provided by the SNMP agent.
ΓòÉΓòÉΓòÉ 9.17.14. subdirectory ΓòÉΓòÉΓòÉ
subdirectory
A directory contained within another directory in a file system hierarchy.
ΓòÉΓòÉΓòÉ 9.17.15. subnet ΓòÉΓòÉΓòÉ
subnet
A networking scheme that divides a single logical network into smaller physical
networks to simplify routing.
ΓòÉΓòÉΓòÉ 9.17.16. subnet address ΓòÉΓòÉΓòÉ
subnet address
The portion of the host address that identifies a subnetwork.
ΓòÉΓòÉΓòÉ 9.17.17. subnet mask ΓòÉΓòÉΓòÉ
subnet mask
A mask used in the IP protocol layer to separate the subnet address from the
host portion of the address.
ΓòÉΓòÉΓòÉ 9.17.18. subnetwork ΓòÉΓòÉΓòÉ
subnetwork
Synonymous with subnet.
ΓòÉΓòÉΓòÉ 9.17.19. synchronous ΓòÉΓòÉΓòÉ
synchronous
1. Pertaining to two or more processes that depend on the occurrences of a
specific event such as common timing signal.
2. Occurring with a regular or predictable time relationship. See
asynchronous.
ΓòÉΓòÉΓòÉ 9.18. T ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.18.1. TALK ΓòÉΓòÉΓòÉ
TALK
An interactive messaging system that sends messages between the local host and
a foreign host.
ΓòÉΓòÉΓòÉ 9.18.2. task manager ΓòÉΓòÉΓòÉ
task manager
The OS/2 function that controls the starting and stopping of programs,
including shutting down the system.
ΓòÉΓòÉΓòÉ 9.18.3. TCP ΓòÉΓòÉΓòÉ
TCP
Transmission Control Protocol.
ΓòÉΓòÉΓòÉ 9.18.4. TCP/IP ΓòÉΓòÉΓòÉ
TCP/IP
Transmission Control Protocol/Internet Protocol.
ΓòÉΓòÉΓòÉ 9.18.5. Telnet ΓòÉΓòÉΓòÉ
Telnet
The Terminal Emulation Protocol, a TCP/IP application protocol for remote
connection service. Telnet allows a user at one site to gain access to a
foreign host as if the user's terminal were connected directly to that foreign
host.
ΓòÉΓòÉΓòÉ 9.18.6. TFTP ΓòÉΓòÉΓòÉ
TFTP
Trivial File Transfer Protocol.
ΓòÉΓòÉΓòÉ 9.18.7. ticket ΓòÉΓòÉΓòÉ
ticket
Encrypted information obtained from a Kerberos authentication server or a
ticket-granting server. A ticket authenticates a user and, in conjunction with
an authenticator, serves as permission to access a service when presented by
the authenticated user.
ΓòÉΓòÉΓòÉ 9.18.8. ticket-granting server ΓòÉΓòÉΓòÉ
ticket-granting server
Grants Kerberos tickets to authenticated users as permission to access an
end-service.
ΓòÉΓòÉΓòÉ 9.18.9. token ΓòÉΓòÉΓòÉ
token
In a local network, the symbol of authority passed among data stations to
indicate the station temporarily in control of the transmission medium.
ΓòÉΓòÉΓòÉ 9.18.10. token ring network ΓòÉΓòÉΓòÉ
token ring network
A ring network that allows unidirectional data transmission between data
stations by a token-passing procedure over one transmission medium, so that the
transmitted data returns to the transmitting station.
ΓòÉΓòÉΓòÉ 9.18.11. Transmission Control Protocol (TCP) ΓòÉΓòÉΓòÉ
Transmission Control Protocol (TCP)
The TCP/IP layer that provides reliable process-to-process data stream delivery
between nodes in interconnected computer networks. TCP assumes that IP
(Internet Protocol) is the underlying protocol.
ΓòÉΓòÉΓòÉ 9.18.12. Transmission Control Protocol/Internet Protocol (TCP/IP) ΓòÉΓòÉΓòÉ
Transmission Control Protocol/Internet Protocol (TCP/IP)
A suite of protocols designed to allow communication between networks
regardless of the technologies implemented in each network.
ΓòÉΓòÉΓòÉ 9.18.13. TRAP ΓòÉΓòÉΓòÉ
TRAP
An unsolicited message that is sent by an SNMP agent to an SNMP network
management station.
ΓòÉΓòÉΓòÉ 9.18.14. Trivial File Transfer Protocol (TFTP) ΓòÉΓòÉΓòÉ
Trivial File Transfer Protocol (TFTP)
A TCP/IP application primarily used to transfer files among personal computers.
TFTP allows files to be sent and received, but does not provide any password
protection or directory capability.
ΓòÉΓòÉΓòÉ 9.19. U ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.19.1. UDP ΓòÉΓòÉΓòÉ
UDP
User Datagram Protocol.
ΓòÉΓòÉΓòÉ 9.19.2. unmarshall ΓòÉΓòÉΓòÉ
unmarshall
To copy data from an RPC packet. Stubs perform unmarshalling. See also
marshall.
ΓòÉΓòÉΓòÉ 9.19.3. user ΓòÉΓòÉΓòÉ
user
A function that utilizes the services provided by a server. A host can be a
user and a server at the same time. See client.
ΓòÉΓòÉΓòÉ 9.19.4. User Datagram Protocol (UDP) ΓòÉΓòÉΓòÉ
User Datagram Protocol (UDP)
A packet-level protocol built directly on the IP layer. UDP is used for
application to application programs between TCP/IP hosts.
ΓòÉΓòÉΓòÉ 9.20. V ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.20.1. VM ΓòÉΓòÉΓòÉ
VM
Virtual Machine.
ΓòÉΓòÉΓòÉ 9.21. W ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.21.1. WAN ΓòÉΓòÉΓòÉ
WAN
Wide area network.
ΓòÉΓòÉΓòÉ 9.21.2. well-known port ΓòÉΓòÉΓòÉ
well-known port
A port number that has been preassigned for specific use by a specific protocol
or application. Clients and servers using the same protocol communicate over
the same well-known port.
ΓòÉΓòÉΓòÉ 9.21.3. wide area network (WAN) ΓòÉΓòÉΓòÉ
wide area network (WAN)
A network that provides communication services to a geographic area larger than
that served by a local area network.
ΓòÉΓòÉΓòÉ 9.21.4. window ΓòÉΓòÉΓòÉ
window
An area of the screen with visible boundaries through which a panel or portion
of a panel is displayed.
ΓòÉΓòÉΓòÉ 9.21.5. working directory ΓòÉΓòÉΓòÉ
working directory
The directory in which an application program is found. The working directory
becomes the current directory when the application is started.
ΓòÉΓòÉΓòÉ 9.22. X ΓòÉΓòÉΓòÉ
ΓòÉΓòÉΓòÉ 9.22.1. XDR ΓòÉΓòÉΓòÉ
XDR
eXternal Data Representation.
ΓòÉΓòÉΓòÉ 10. Bibliography ΓòÉΓòÉΓòÉ
This bibliography lists related publications for more information.
ΓòÉΓòÉΓòÉ 10.1. TCP/IP for OS/2 Publications ΓòÉΓòÉΓòÉ
IBM TCP/IP Introduction, GC31-6080
This book gives an overview of TCP/IP for OS/2, in addition to other products
in the TCP/IP family. Written for new or prospective users, it describes
TCP/IP's advantages, uses, installation requirements, and compatibility with
other products. It also includes scenarios that show how TCP/IP provides a
total interoperability solution for networks in various settings (university,
retail, hospital, and financial networks, for example).
IBM TCP/IP Version 2.0 for OS/2: Installation and Administration, SC31-6075
This book describes how to install, configure, administer, and start the TCP/IP
for OS/2 software on a programmable workstation. The book also summarizes the
kits that are available for TCP/IP for OS/2.
IBM TCP/IP Version 2.0 for OS/2: User's Guide, SC31-6076
This book shows how to log in to a remote host in a TCP/IP network, transfer
files between hosts, print files, send and receive electronic mail, and run
commands on remote hosts. The book also includes a computer networking overview
for new users, as well as advice on resolving common problems.
IBM TCP/IP Version 2.0 for OS/2: Command Reference, SX75-0070
This book describes each of the TCP/IP for OS/2 commands, subcommands, and
parameters. The descriptions include syntax diagrams and are arranged
alphabetically by command.
IBM TCP/IP Version 2.0 for OS/2: Ultimedia Mail/2 Installation and
Configuration Guide, SC31-7120
This book introduces the Ultimedia Mail/2 (UltiMail) program for transmitting
multimedia messages. It describes how to install and configure the UltiMail
Kit, as well as how to start UltiMail.
IBM TCP/IP Version 2.0 for OS/2: Programmer's Reference, SC31-6077
This book explains how to install the Programmer's Toolkit on a programmable
workstation. It describes the programming interfaces provided with TCP/IP for
OS/2, as well as the steps for using socket routines, remote procedure calls,
file transfer protocol (FTP) routines, and simple network management protocol
(SNMP) routines in user-written programs.
IBM TCP/IP Version 2.0 for OS/2: X Window System Client Guide, SC31-7087
This book describes how to install and use the X Window System Client Kit,
which enables users to develop and run applications that use the X Window
System in an OS/2 environment. This book also describes how to install and use
the OSF/Motif Kit, which enables users to port, develop, and run OSF/Motif V1.2
applications in an OS/2 environment.
IBM TCP/IP Version 2.0 for OS/2: X Window System Server Guide, SC31-7070
This book explains how to install and use an X Window System server. An X
Window System server enables you to display and control X Window System client
application programs in OS/2 windowed sessions.
IBM TCP/IP Version 2.0 for OS/2: Domain Name Server Guide, SC31-7174
This book describes how to install the Domain Name Server Kit, and how to
create and maintain a domain name server for your TCP/IP network. This book
also includes conceptual information on how domain name servers and name
resolvers operate in a network.
IBM TCP/IP Version 2.0 for OS/2: Network File System Guide, SC31-7069
This book explains how to install the Network File System Kit, and how to use
it to allow users to read, write, and run programs and files on remote systems
as if they were local.
IBM TCP/IP Version 2.0 for OS/2: Extended Networking Guide, SC31-7071
This book explains how to install the Extended Networking Kit, and how to
configure and start an X.25 interface or a SNALINK interface. The X.25 or
SNALINK interface can be used as a router to connect remote LANs.
IBM TCP/IP Version 2.0 for OS/2: NetBIOS Guide, SC31-6122
This book explains how to install and start the IBM NetBIOS Version 1 for
TCP/IP for OS/2 program, as well as how to write and debug application programs
that use NetBIOS services. NetBIOS provides a simple, consistent interface for
applications to use in accessing network resources.
ΓòÉΓòÉΓòÉ 10.2. Other Related Publications ΓòÉΓòÉΓòÉ
The following are other related publications.
ΓòÉΓòÉΓòÉ 10.2.1. OS/2 Publications ΓòÉΓòÉΓòÉ
The following lists shows OS/2 publications.
IBM Operating System/2 User's Guide Volume 1: Base Operating System
IBM Operating System/2 User's Guide Volume 2: Communications Manager and LAN
Requester
IBM Operating System/2 System Administrator's Guide for Communications
Operating System/2 Electronic Device Driver Distribution Mechanism
IBM Operating System/2 Command Reference
IBM OS/2 LAN Technical Reference
ΓòÉΓòÉΓòÉ 10.2.2. Programming Publications ΓòÉΓòÉΓòÉ
The following list shows selected programming publications.
AIX Communications Concepts and Procedures for IBM RISC System/6000
IBM AIX Operating System Technical Reference: System Calls and Subroutines
Network Computing System (NCS) Reference (010200, Rev.00), Apollo Computer,
Inc.
Networking on the Sun Workstation: Remote Procedure Call Programming Guide
(800-1324-03), Sun Microsystems, Inc.
Network Programming (800-1779-10), Sun Microsystems, Inc.
UNIX Programmer's Reference Manual (4.3 Berkeley Software Distribution, Virtual
VAX-11 Version). Department of Electrical Engineering and Computer Science.
University of California, Berkeley, 1988.
X Protocol Reference Manual, Adrian Nye, ed. O'Reilly & Associates, Inc.,
1990.
X Window System User's Guide, Valerie Quercia & Tim O'Reilly., O'Reilly &
Associates, Inc., 1990.
The Art of Distributed Application: Programming Techniques for Remote
Procedure Calls, John R. Corbin, Springer-Verlog, 1991.
Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schiller. "Kerberos: An
Authentication Service for Open Networks." Massachusetts Institute of
Technology, 12 January 1988.
S.P. Miller et al. "Kerberos Authentication and Authorization System," Project
Athena Technical Plan, Section E.2.1. Massachusetts Institute of Technology,
21 December 1987.
MVS NFS User's Guide
MVS/DFP Version 3 Release 3: Using the Network File System Server
ΓòÉΓòÉΓòÉ 10.2.3. Network Computing System (NCS) Publications ΓòÉΓòÉΓòÉ
The following list shows NCS publications.
Network Computing System Reference Manual, Mike Kong, (Terence H. Dineen, Paul
J. Leach, Elizabeth A. Martin, Nathaniel W. Mishkin, Joseph N. Pato, Geoffrey
L. Wyant), Apollo Computer Inc., a subsidiary of Hewlett-Packard Company,
Chelmsford, Massachusetts, Prentice Hall, Englewood Cliffs, New Jersey 07632,
1990.
Network Computing Architecture, Lisa Zahn, (Terence H. Dineen, Paul J. Leach,
Elizabeth A. Martin, Nathaniel W. Mishkin, Joseph N. Pato, Geoffrey L. Wyant),
Apollo Computer Inc., a subsidiary of Hewlett-Packard Company, Chelmsford,
Massachusetts, Prentice Hall, Englewood Cliffs, New Jersey 07632, 1990.
Network Computing Architecture (NCA) Protocol Specifications , Apollo Computer
Inc.,330 Billerica Road, Chelmsford, MA 01824, (508) 256-6600, 1989. Apollo
Order No. 010201-A00
Network Computing System (NCS) Reference, Apollo Computer Inc., 330 Billerica
Road, Chelmsford, MA 01824, 1987. Apollo Order No. 010200, Revision 00.
Managing the NCS Location Broker, Apollo Computer Inc., 330 Billerica Road,
Chelmsford, MA 01824, 1988. Apollo Order No. 011895-A00.
(.txt)
(.txt)