libsocket 0.8.0 Manual Copyright © 1999, 2000 by Richard Dawe and Alain Magloire
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License" (see GNU Free Documentation License).
libsocket:
Copyright © 1997, 1998 by Indrek Mandre
Copyright © 1997-2000 by Richard Dawe
Portions of libsocket:
libsocket is distributed under the terms of the GNU Library General Public License (the GNU LGPL) (see License). Please read the license before using libsocket.
libsocket is a BSD sockets library for DJGPP. It provides DJGPP programs with TCP/IP networking as well as Unix domain sockets, a form of Interprocess Communication (IPC). BSD sockets are the de facto programming interface for networking on Unix systems. Programs written to this interface can be ported to many platforms. The Windows network programming interface, Winsock, is derived from BSD sockets.
libsocket supports the following operating systems:
Please note that libsocket has not been tested under Windows 3.x for a long time. It should work, since it uses mostly the same methods as Windows '95. Any feedback would be appreciated here.
Please also note that libsocket has not been tested under Windows '98 during development, since the maintainer does not have Windows '98. It has been reported variously to work/not work.
demo/diag.exe and demo/httpget.exe. diag lists
libsocket's configuration (a diagnostic tool); httpget retrieves
the specified URL from the web and dumps it to the screen, e.g.:
httpget http://www.slashdot.org/
contrib/ls080/doc/beejng.
You can jump directly to functions in the alphabetical index:
info libsocket alpha socket
Firstly check that you haven't encountered one of the known bugs (see Known Bugs). You should also read the release notes (if any) that came with libsocket.
Secondly check that there isn't any news at the libsocket home page. More directly:
If this doesn't help, please ask a question in the DJGPP newsgroup
(mailto:djgpp@delorie.com or news:comp.os.msdos.djgpp)
and the libsocket mailing list.
Please include the output of demo/diag.exe and your libsocket
configuration files (see Configuration).
libsocket is maintained by Richard Dawe:
richdawe@bigfoot.com
http://www.bigfoot.com/~richdawe/
#include <sys/types.h> #include <sys/socket.h> int accept (int s, struct sockaddr *address, size_t *addresslen);
The accept() function returns the first completed connection from the
the pending connection queue form a listening socket. The parameter s
is a socket descriptor that has been created with socket(), bound
to a local socket-address with bind() and is listening for connections
after listen(). The accept() will return a brand new socket
descriptor. If the socket is not marked non-blocking, accept()
blocks the caller until a connection is present. If marked non-blocking
and no pending connections are present it returns -1 and set errno to
EWOULDBLOCK. If address is not NULL it specifies a buffer
in which to return the socket address, the addresslen is a value-result
that specified the amount of space for address. On return
when addresslen will hold the size written to address.
On successful completion the function returns the descriptor of the accepted socket. Otherwise, a value of -1, and errno is set.
EBADF
ECONNABORTED
EINTR
EINVAL
EMFILE
ENFILE
ENOBUFS
ENOTSOCK
EOPNOTSUPP
accept()
EWOULDBLOCK
POSIX, Unix98
#include <sys/types.h> #include <sys/socket.h> int bind (int s, const struct sockaddr *address, size_t addresslen);
The bind() function assigns a local socket-address to socket s
that has no local socket-address assigned. When a socket is created with
socket() it is associated with a specific protocol from the protocol
and in the case of libsocket also an interface, but has no local socket-address
assigned. This function requests that the local socket-address
address be assigned to it. The format of the socket-address
dpends on the address family, for example AF_INET,
AF_UNIX (also known as AF_LOCAL).
On successful completion the function returns 0. Otherwise, a value of -1, and errno is set.
EACCESS
EADDRINUSE
EADDRNOTAVAIL
EBADF
EINVAL
ENOBUFS
ENOTSOCK
POSIX, Unix98
#include <sys/types.h> #include <sys/socket.h> int connect (int s, struct sockaddr *serv_addr, size_t *addrlen);
If s refers to a stream socket (SOCK_STREAM), connect()
will attempt to establish a connection to the specified destination address.
If s refers to a datagram socket (SOCK_DGRAM), connect()
associates a default destination address for use by send() and
sendto(). It also limits recv() calls to receiving from this
address, rather than the default of any. To remove the association, call
connect() with an invalid address, e.g. a null address (0.0.0.0).
On successful completion the function returns zero. Otherwise, a value of -1 is returned and errno is set appropriately.
EBADF
EFAULT
ENOTSOCK
EISCONN
ECONNREFUSED
ETIMEDOUT
ENETUNREACH
EADDRINUSE
EINTR
EOPNOTSUPP
connect().
EINPROGRESS
getsockopt() to read the option SO_ERROR at level
SOL_SOCKET to check if the call completed successfully -
SO_ERROR's value will be 0 on success, or an errno value
otherwise.
EALREADY
connect() request is
completing.
POSIX, Unix98
#include <resolv.h>
int dn_comp (unsigned char *exp_dn, unsigned char *comp_dn, int length,
unsigned char **dnptrs, unsigned char *exp_dn,
unsigned char **lastdnptr);
The dn_comp() function compresses the domain name exp_dn
and stores it in the buffer comp_dn of length length.
The compression uses an array of pointers dnptrs to previously
compressed names in the current message. The first pointer points
to the beginning of the message and the list ends with NULL. The limit
of the array is specified by lastdnptr. If dnptr is NULL,
domain names are not compressed. If lastdnptr is NULL, the list
of labels is not updated.
See dn_expand.
The dn_comp() function returns the length of the compressed name,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <resolv.h>
int dn_expand (unsigned char *msg, unsigned char *eomorig,
unsigned char *comp_dn, unsigned char *exp_dn,
int length);
The dn_expand() function expands the compressed domain name
comp_dn to a full domain name, which is placed in the buffer
exp_dn of size length. The compressed name is contained
in a query or reply message, and msg points to the beginning of
the message.
See dn_comp.
The dn_expand() function returns the length of the compressed name,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netdb.h> void endhostent (void);
The endhostent() function ends the use of a TCP connection for name
server queries.
None
Unix98
#include <netdb.h> void endnetent (void);
The endnetent() function closes networks (see networks).
None
Unix98
#include <netdb.h> void endprotoent (void);
The endprotoent() function closes the protocols file
(see protocols).
None
Unix98
#include <netdb.h> void endservent (void);
The endservent() function closes services (see services).
None
Unix98
#include <lsck/domname.h> int getdomainname (char *name, size_t len);
This function is used to access the domain name. The domain name can be set
by setdomainname() (see setdomainname). The domain name is the
last component of the host name (see gethostname).
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
EINVAL
NULL or name is longer than len.
not POSIX, not Unix98
This function is defined in unistd.h on Linux.
#include <netdb.h> #include <sys/socket.h> extern int h_errno; struct hostent *gethostbyaddr (const char *addr, int len, int type);
The gethostbyaddr() function returns a structure of type hostent
for the given host address addr of length len and address type
type. The only valid address type is currently AF_INET.
The hostent structure is defined in the description of
gethostbyname() (see gethostbyname).
The gethostbyaddr() function return the hostent structure or
a NULL pointer if an error occurs. On error, the h_errno variable
holds an error number. h_errno can have the same values as for
gethostbyname() (see gethostbyname).
The herror() function will print an error message, based on the value
of h_errno (see herror).
Unix98
#include <netdb.h> extern int h_errno; struct hostent *gethostbyname (const char *name)
The gethostbyname() function returns a structure of type hostent
for the given host name. Here name is either a host name, or
an IPv4 address in standard dot notation, or an IPv6 address in colon
(and possibly dot) notation. (See RFC 1884 for the description of IPv6
addresses.) If name doesn't end in a dot
and the environment variable HOSTALIASES is set, the alias file
pointed to by HOSTALIASES will first be searched for name.
The current domain and its parents are searched unless name ends in a dot.
The domain name queries carried out by gethostbyname() use
a combination of any or all of:
named;
hosts (see hosts);
depending upon the contents of the order line in host.conf
(see host.conf). The default action is to query hosts
(see hosts).
The hostent structure is defined in <netdb.h> as follows:
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}
#define h_addr h_addr_list[0] /* for backward compatibility */
The members of the hostent structure are:
h_name
h_aliases
h_addrtype
h_length
h_addr_list
h_addr
h_addr_list for backward compatibility.
The gethostbyname() function returns a hostent structure or a
NULL pointer if an error occurs. On error, the h_errno variable holds
an error number.
The variable h_errno can have the following values:
HOST_NOT_FOUND
NO_ADDRESS
NO_RECOVERY
TRY_AGAIN
The herror() function will print an error message, based on the value
of h_errno (see herror).
Unix98
#include <netdb.h> struct hostent *gethostent (void);
The gethostent() function reads the next line from the file
hosts (see hosts) and returns a structure hostent
containing the broken out fields from the line. The hosts file
is opened if necessary.
The hostent structure is defined in the description of
gethostbyname() (see gethostbyname).
The gethostent() function return the hostent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <unistd.h> int gethostname (char *name, size_t len);
This function is used to access the host name of the current processor. The
host name is set using sethostname() (see sethostname). The
domain name component can be retrieved and set using getdomainname()
and setdomainname() respectively (see getdomainname,
see setdomainname).
libsocket's implementation of gethostname() overrides DJGPP's
implementation (see gethostname). libsocket will fall
back the DJGPP's implementation when it cannot find the host name from its
additional sources.
If a host name has not been set using sethostname(), then it is
determined in the following order:
HOSTNAME;
gethostname() implementation.
On success, zero is returned. On error, -1 is returned, and errno
is set appropriately.
EINVAL
EFAULT
not POSIX, not Unix98
#include <netdb.h> struct netent *getnetbyaddr (long net, int type);
The getnetbyaddr() function returns a netent structure
for the line from networks (see networks) that matches
the network number net of type type.
The netent structure is defined in the description of
getnetbyname() (see getnetbyname).
The getnetbyaddr() function return the netent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct netent *getnetbyname (const char *name);
The getnetbyname() function returns a netent structure
for the line from networks (see networks) that matches the network
name.
The netent structure is defined in <netdb.h> as follows:
struct netent {
char *n_name; /* official network name */
char **n_aliases; /* alias list */
int n_addrtype; /* net address type */
unsigned long int n_net; /* network number */
}
The members of the netent structure are:
n_name
n_aliases
n_addrtype
n_net
The getnetbyname() function return the netent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct netent *getnetent(void);
The getnetent() function reads the next line from the file
networks (see networks) and returns a structure netent
containing the broken out fields from the line. The networks file
is opened if necessary.
The netent structure is defined in the description of
getnetbyname() (see getnetbyname).
The getnetent() function return the netent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <sys/socket.h> int getpeername (int s, struct sockaddr *name, size_t *namelen);
getpeername() returns the name of the peer connected to the socket
s. namelen should be set to the size of the space pointed to by
name. On completion namelen will contain the length of the
address returned. If the buffer is too small, the address is truncated to
fit.
getsockname() returns the local name for the socket
(see getsockname).
On successful completion the function returns 0. Otherwise, a value of -1 is returned and errno is set appropriately.
EBADF
ENOTSOCK
ENOTCONN
ENOBUFS
EFAULT
POSIX, Unix98
#include <netdb.h> struct protoent *getprotobyname (const char *name);
The getprotobyname() function returns a protoent
structure for the line from protocols (see protocols) that matches
the protocol name name.
The protoent structure is defined in <netdb.h> as follows:
struct protoent {
char *p_name; /* official protocol name */
char **p_aliases; /* alias list */
int p_proto; /* protocol number */
}
The members of the protoent structure are:
p_name
p_aliases
p_proto
The getprotobyname() function returns the protoent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct protoent *getprotobynumber (int proto);
The getprotobynumber() function returns a protoent
structure for the line from protocols (see protocols) that matches
the protocol number number.
The protoent structure is defined in the description of
getprotobyname() (see getprotobyname).
The getprotobynumber() function return the protoent structure,
or a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct protoent *getprotoent (void);
The getprotoent() function reads the next line from the file
protocols (see protocols) and returns a structure
protoent containing the broken out fields from the line.
The protocols file is opened if necessary.
The protoent structure is defined in the description of
getprotobyname() (see getprotobyname).
On successful completion the function returns a protoent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct servent *getservbyname (const char *name, const char *proto);
The getservbyname() function returns a servent structure
for the line from services (see services) that matches the service
name using protocol proto.
The servent structure is defined in <netdb.h> as follows:
struct servent {
char *s_name; /* official service name */
char **s_aliases; /* alias list */
int s_port; /* port number */
char *s_proto; /* protocol to use */
}
The members of the servent structure are:
s_name
s_aliases
s_port
s_proto
The getservbyname() function return the servent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct servent *getservbyport (int port, const char *proto);
The getservbyport() function returns a servent structure
for the line from services (see services) that matches the port
port given in network byte order using protocol proto.
The servent structure is defined in the description of
getservbyname() (see getservbyname).
The getservbyport() function return the servent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <netdb.h> struct servent *getservent (void);
The getservent() function reads the next line from the file
services (see services) and returns a structure
servent containing the broken out fields from the line.
The services file is opened if necessary.
The servent structure is defined in the description of
getservbyname() (see getservbyname).
The getservent() function return the servent structure, or
a NULL pointer if an error occurs or the end of the file is reached.
Unix98
#include <sys/socket.h> int getsockname (int s, struct sockaddr *name, size_t *namelen);
getsockname() returns the local name of the socket s.
namelen should be set to the size of the space pointed to by
name. On completion namelen will contain the length of the
address returned. If the buffer is too small, the address is truncated to
fit.
getpeername() returns the peer name for the socket
(see getpeername).
On successful completion the function returns 0. Otherwise, a value of -1 is returned and errno is set appropriately.
EBADF
ENOTSOCK
ENOBUFS
EFAULT
POSIX, Unix98
#include <sys/types.h>
#include <sys/socket.h>
int getsockopt (int s, int level, int optname,
void *optval, int *optlen);
The getsockopt() function manipulates the options associated with a
socket. Options may exist at multiple protocol levels; they are always present
at the uppermost socket level.
When manipulating socket options the level at which the option resides and the
name of the option must be specified. To manipulate options at the socket
level, level is specified as SOL_SOCKET. To manipulate options at
any other level the protocol number of the appropriate protocol controlling
the option is supplied. For example, to indicate that an option is to be
interpreted by the TCP protocol, level should be set to the protocol
number of TCP, e.g. IPPROTO_TCP (see getprotoent).
The parameters optval and optlen are used to identify a buffer in which the value for the requested option(s) are to be returned. optlen is a value-result parameter, initially containing the size of the buffer pointed to by optval, and modified on return to indicate the actual size of the value returned. If no option value is to be supplied or returned, optval may be NULL.
optname and any specified options are passed uninterpreted to the
appropriate protocol module for interpretation. The include file
<sys/socket.h> contains definitions for socket level options, described
below. Options at other protocol levels vary in format and name.
Most socket-level options utilize an int parameter for optval.
SO_LINGER uses a struct linger parameter, defined in
<sys/socket.h>, which specifies the desired state of the option and the
linger interval (see below).
SO_SNDTIMEO and SO_RCVTIMEO use a struct timeval
parameter, defined in <sys/time.h>.
The following options are recognized at the socket level:
SO_DEBUG
SO_REUSEADDR
SO_KEEPALIVE
SO_DONTROUTE
SO_LINGER
SO_BROADCAST
SO_OOBINLINE
SO_SNDBUF
SO_RCVBUF
SO_SNDLOWAT
SO_RCVLOWAT
SO_SNDTIMEO
SO_RCVTIMEO
SO_TYPE
SO_ERROR
SO_DEBUG enables debugging in the underlying protocol modules.
SO_REUSEADDR indicates that the rules used in validating addresses
supplied in a bind() call should allow reuse of local addresses
(see bind).
SO_KEEPALIVE
enables the periodic transmission of messages on a connected socket.
Should the connected party fail to respond to these messages, the
connection is considered broken and processes using the socket are notified
via a SIGPIPE signal when attempting to send data.
SO_DONTROUTE
indicates that outgoing messages should bypass the standard routing
facilities. Instead, messages are directed to the appropriate network
interface according to the network portion of the destination address.
SO_LINGER controls the action taken when unsent messages
are queued on socket and a close() is performed
(see close). If the socket promises reliable delivery of
data and SO_LINGER is set, the system will block the process on the
close() attempt until it is able to transmit the data or until it
decides it is unable to deliver the information (a timeout period, termed the
linger interval, is specified in the setsockopt() call when
SO_LINGER is requested). If SO_LINGER is disabled and a
close() is issued, the system will process the close in a manner that
allows the process to continue as quickly as possible.
The linger structure is defined in <sys/socket.h>
as follows:
struct linger {
int l_onoff; /* Linger active */
int l_linger; /* How long to linger for */
};
l_onoff indicates whether to linger or not. If it is set to 1 then
l_linger contains the time in hundredths of seconds how long the process
should linger to complete the close(). If l_onoff
is set to zero the process returns immediately.
The option SO_BROADCAST requests permission to send broadcast datagrams
on the socket. Broadcast was a privileged operation in earlier versions of
the system. With protocols that support out-of-band data, the
SO_OOBINLINE option requests that out-of-band data be placed in the
normal data input queue as received; it will then be accessible with
recv() or read() calls without the MSG_OOB
flag (see recv, see read). Some protocols behave
as if this option were always set.
SO_SNDBUF and SO_RCVBUF
are options to adjust the normal buffer sizes allocated for output and
input buffers, respectively. The buffer size may be increased for
high-volume connections, or may be decreased to limit the possible backlog
of incoming data. The system places an absolute limit on these values.
SO_SNDLOWAT
is an option to set the minimum count for output operations. Most output
operations process all of the data supplied by the call, delivering data to
the protocol for transmission and blocking as necessary for flow control.
Nonblocking output operations will process as much data as permitted
subject to flow control without blocking, but will process no data if flow
control does not allow the smaller of the low water mark value or the
entire request to be processed. A select()
(see select) operation testing the ability to write to a
socket will return true only if the low water mark amount could be processed.
The default value for SO_SNDLOWAT is set to a convenient size for
network efficiency, often 1024.
SO_RCVLOWAT
is an option to set the minimum count for input operations. In general,
receive calls (see recv, see recvfrom) will block until any (non-zero)
amount of data is received, then return with smaller of the amount available
or the amount requested. The default value for SO_RCVLOWAT is 1.
If SO_RCVLOWAT is set to a larger value, blocking receive calls
normally wait until they have received the smaller of the low water mark value
or the requested amount. Receive calls may still return less than the low
water mark if an error occurs, a signal is caught, or the type of data next in
the receive queue is different than that returned.
SO_SNDTIMEO is an option to get the timeout value for output operations.
It returns a struct timeval parameter with the number of seconds and
microseconds used to limit waits for output operations to complete. If a send
operation has blocked for this much time, it returns with a partial count or
with the error EWOULDBLOCK if no data were sent. In the current
implementation, this timer is restarted each time additional data are
delivered to the protocol, implying that the limit applies to output portions
ranging in size from the low water mark to the high water mark for output.
SO_RCVTIMEO is an option to get the timeout value for input operations.
It returns a struct timeval
parameter with the number of seconds and microseconds used to limit waits
for input operations to complete. In the current implementation, this
timer is restarted each time additional data are received by the protocol,
and thus the limit is in effect an inactivity timer. If a receive
operation has been blocked for this much time without receiving additional
data, it returns with a short count or with the error
EWOULDBLOCK if no data were received.
SO_TYPE returns the type of the socket, such as SOCK_STREAM;
it is useful for servers that inherit sockets on startup.
SO_ERROR returns any pending error on the socket and clears the error
status. It may be used to check for asynchronous errors on connected datagram
sockets or for other asynchronous errors.
On success, zero is returned. On error, -1 is returned, and errno
is set appropriately.
EBADF
ENOTSOCK
ENOPROTOOPT
EFAULT
POSIX, Unix98
#include <netdb.h> extern int h_errno; void herror (const char *s);
The herror() function prints the error message associated with the
current value of h_errno on stderr. The values for h_errno
are described with gethostbyname() (see gethostbyname).
None
not Unix98
While the herror() function is not portable to Unix98, the
h_errno variable is.
#include <net/if.h> void if_freenameindex (struct if_nameindex *ptr);
This function frees the memory used by the array returned by
See if_nameindex. The program should not use ptr after calling
if_freenameindex().
None. However, an error may occur. The error code will be stored in errno.
Possible errors for this function are:
EFAULT
Open Group XNS 5.2 Draft 1.0
#include <net/if.h> char *if_nametoindex (unsigned int ifindex, char *ifname);
This returns the interface name corresponding to ifindex in the buffer
ifname. The buffer pointed to ifname must be at least
IFNAMESIZE bytes in size.
The interface name will be placed into ifname, if ifindex is a
valid interface index. Otherwise NULL is returned and errno
contains the error code.
Possible errors for this function are:
EFAULT
ENXIO
Open Group XNS 5.2 Draft 1.0
#include <net/if.h> struct if_nameindex *if_nameindex (void);
This function returns an array of if_nameindex structures, one per
interface. The array is terminated with an entry with a if_index field
of 0 and a if_name field of NULL.
The function if_freenameindex() (see if_freenameindex) should be
called, passing the pointer returned by this function, in order to free memory.
A pointer to the array of if_nameindex structures or NULL on
error. On error, errno will contain the error code.
Possible errors for this function are:
ENOBUFS
Open Group XNS 5.2 Draft 1.0
#include <net/if.h> unsigned int if_nametoindex (const char *ifname);
This returns the interface index corresponding to ifname.
The interface index will be returned if ifname is an interface name, else 0. If an error occurs, -1 will be returned and the error will be stored in errno.
Possible errors for this function are:
EFAULT
Open Group XNS 5.2 Draft 1.0
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> unsigned long int inet_addr (const char *cp);
The inet_addr() function converts the Internet host address
cp from numbers-and-dots notation into binary data in network
byte order. If the input is invalid, -1 is returned. This is an
obsolete interface to inet_aton() (see inet_aton); it is
obsolete because -1 is a valid address (255.255.255.255),
and inet_aton() provides a cleaner way to indicate error return.
If the input is invalid, -1 is returned. Otherwise, the IP address is returned as a 32-bit unsigned integer in network order.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> int inet_aton (const char *cp, struct in_addr *inp);
inet_aton() converts the Internet host address cp from the
standard numbers-and-dots notation into binary data and stores it in
the structure that inp points to.
The structure in_addr is defined in the description of
inet_ntoa() (see inet_ntoa).
Non-zero is returned, if the address is valid; otherwise zero is returned.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> unsigned long int inet_lnaof (struct in_addr in);
The inet_lnaof() function returns the local host address part
of the Internet address in. The local host address is returned
in local host byte order.
The structure in_addr is defined in the description of
inet_ntoa() (see inet_ntoa).
The local host address portion is returned.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> struct in_addr inet_makeaddr (int net, int host);
The inet_makeaddr() function makes an Internet host address
in network byte order by combining the network number net
with the local address host in network net, both in
local host byte order.
The structure in_addr is defined in the description of
inet_ntoa() (see inet_ntoa).
An Internet host addess is returned.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> unsigned long int inet_netof (struct in_addr in);
The inet_netof() function returns the network number part of
the Internet Address in. The network number is returned in
local host byte order.
The structure in_addr is defined in the description of
inet_ntoa() (see inet_ntoa).
The network number portion is returned.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> unsigned long int inet_network (const char *cp);
The inet_network() function extracts the network number in
network byte order from the address cp in numbers-and-dots
notation.
If the input is invalid, -1 is returned.
Unix98
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> char *inet_ntoa (struct in_addr in);
The inet_ntoa() function converts the Internet host address
in given in network byte order to a string in standard
numbers-and-dots notation. The string is returned in a statically
allocated buffer, which subsequent calls will overwrite.
The structure in_addr is defined in netinet/in.h as:
struct in_addr {
unsigned long int s_addr;
}
Note that on the i80x86 the host byte order is Least Significant Byte first, whereas the network byte order, as used on the Internet, is Most Significant Byte first.
inet_ntoa() returns a pointer to the address in string form.
Unix98
#include <sys/socket.h> #include <arpa/inet.h> const char *inet_ntop (int af, const void *src, char *dst, size_t size);
This function converts network addresses from numeric format (i.e. binary)
into presentation format (i.e. strings). This is a replacement for
inet_ntoa (see inet_ntoa), which cannot cope with IPv6 addresses.
af specifies the address family of the numeric format, e.g.
AF_INET or AF_INET6. The numeric data in src will be
converted in presentation format and stored in dst.
size specifies the size of the buffer pointed to by dst - it must
be large enough to store the presentation format address. The constants
INET_ADDRSTRLEN and INET6_ADDRSTRLEN are defined in
netinet/in.h as the maximum presentation string lengths, including
terminating nuls.
On successful completion the function returns a pointer to the presentation format string. Otherwise, a value of NULL is returned and errno is set appropriately.
EFAULT
ENOSPC
EAFNOSUPPORT
POSIX
#include <sys/socket.h> #include <arpa/inet.h> int inet_pton (int af, const char *src, void *dst);
This function converts network addresses from presentation format
(i.e. strings) into numeric format (i.e. binary). This is a replacement for
inet_aton (see inet_aton), which cannot cope with IPv6 addresses.
af specifies the address family of the presentation format, e.g.
AF_INET or AF_INET6. The address string src will be
converted to the appropriate address format, e.g. struct in_addr or
struct in6_addr, and stored in dst.
On successful completion the function returns 1. If the presentation format
is not understood, 0 is returned. If the address family af is not
known or supported, -1 is returned and errno is set to
EAFNOSUPPORT.
POSIX
#include <sys/ioctl.h> #include <ioctls.h> #include <sys/socket.h> #include <net/if.h>
This page documents the ioctls that are supported by libsocket. These are
used with the ioctl() function (see ioctl). Many
BSD ioctls are not listed here, because libsocket does not support them.
Some BSD socket ioctls are supported.
FIONBIO
ioctl() should be passed
an integer - if this is non-zero, non-blocking I/O will be enabled,
otherwise blocking I/O will be used.
/* Flip into non-blocking mode */ int x = 1; ioctl(sock, FIONBIO, &x);
FIONBIO is like the O_NONBLOCK flag that can be set using
fcntl() (see fcntl):
/* Flip into non-blocking mode */ int flags = flags = fcntl(sock, F_GETFL); flags |= O_NONBLOCK; fcntl(sock, F_SETFL, flags);
FIONREAD
ioctl() should
be passed an integer - on return this will contain the maximum read size.
int maxsz = 0; ioctl(sock, FIONREAD, &maxsz)
SIOCATMARK
SOCK_STREAM type sockets that have been set with the option
SO_OOBINLINE (see getsockopt, see setsockopt).
It returns 1 (true) or 0 (false) in the ioctl parameter.
The sockatmark() function should be used instead (see sockatmark).
SIOCGIFNAME
IFNAMSIZ.
The pointer to the buffer is passed as the parameter to ioctl, e.g.
ioctl(sock, SIOCGIFNAME, (int *) name)
SIOCGIFADDR
struct ifreq. The pointer to the buffer is passed as the parameter to
ioctl, e.g.
ioctl(sock, SIOCGIFADDR, (int *) &ifr)
The socket address can then be accessed via the ifr_ifru.ifru_addr
member of struct ifreq.
SIOCGIFDSTADDR
struct ifreq. The pointer to the buffer is passed as the parameter to
ioctl, e.g.
ioctl(sock, SIOCGIFDSTADDR, (int *) &ifr)
The peer's socket address can then be accessed via the
ifr_ifru.ifru_dstaddr member of struct ifreq.
SIOCGIFNETMASK
struct ifreq. The pointer to the buffer is passed as the parameter to
ioctl, e.g.
ioctl(sock, SIOCGIFDSTADDR, (int *) &ifr)
The peer's socket address can then be accessed via the
ifr_ifru.ifru_netmask member of struct ifreq.
ioctls cannot be guaranteed to be portable. However, because of the ubiquity of BSD sockets, these ioctls should work on most Unices.
#include <sys/socket.h> int isfdtype (int fd, int fd_type);
The isfdtype() function determines whether the file descriptor fd
has the properties specified by fd_type.
Valid values of fd_type include:
S_IFSOCK
1 if the type matches, 0 otherwise. If an error occurs, -1 is returned and errno is set to:
EBADF
POSIX, not Unix98
isfdtype() is usually declared in sys/stat.h rather than
sys/socket.h.
#include <sys/socket.h> int listen (int s, int backlog);
To create a passive/listening (server) socket, a socket is created with
socket() (see socket), bound to a local address with bind()
(see bind) and then given a connection queue with listen().
Connections can then be accepted with accept() (see accept).
listen() sets the maximum number of connections, backlog, that
can be waiting for handling by accept(). Any further waiting
connections will be refused.
listen() is only a valid operation for sockets of type
SOCK_STREAM or SOCK_SEQPACKET.
On successful completion the function returns 0. Otherwise, a value of -1 is returned and errno is set appropriately.
EBADF
ENOTSOCK
EOPNOTSUPP
listen() is not a valid operation on this type of socket.
POSIX, Unix98
#include <lsck/copyrite.h> char *__lsck_get_copyright (void);
This function returns a string containing the copyright information for libsocket. If this is longer than one line, it will be formatted to fit on an 80-column terminal.
A pointer to the string is returned on success; on failure, NULL is
returned.
not ANSI, not POSIX, not Unix98
This function is specific to libsocket.
char *p = __lsck_get_copyright(); puts(p);
#include <lsck/copyrite.h> char *__lsck_get_version (void);
This function returns a string containing the version information for libsocket. If this is longer than one line, it will be formatted to fit on an 80-column terminal.
The version message is constructed from constants defined in
lsck/copyrite.h. The ones that should be used in user programs are
listed in the table below. As an example, consider the version number 0.8.0.
LSCK_VERSION_MAJOR
0 for the example.
LSCK_VERSION_MINOR
8 for the example.
LSCK_VERSION_SUBMINOR
0 for
the example.
A pointer to the string is returned on success; on failure, NULL is
returned.
not ANSI, not POSIX, not Unix98
This function is specific to libsocket.
char *p = __lsck_get_version(); puts(p);
#include <sys/socket.h>
#include <unistd.h>
int rcmd (char **ahost, int inport,
const char *locuser, const char *remuser,
const char *cmd, int *fd2p);
The rcmd() function is used by the super-user to execute a command on
a remote machine using an authentication scheme based on reserved port numbers.
The rcmd() function looks up the host *ahost using
gethostbyname() (see gethostbyname), returning -1 if the host
does not exist. Otherwise *ahost is set to the standard name of the host
and a connection is established to a server residing at the well-known
Internet port inport.
If the connection succeeds, a socket in the Internet domain of type
SOCK_STREAM is returned to the caller, and given to the remote command
as stdin and stdout.
If fd2p is non-zero, then an auxiliary channel to a control process will be set up, and a descriptor for it will be placed in *fd2p. The control process will return diagnostic output from the command (unit 2) on this channel, and will also accept bytes on this channel as being UNIX signal numbers, to be forwarded to the process group of the command.
If fd2p is 0, then the stderr (unit 2 of the remote command) will be made the same as the stdout and no provision is made for sending arbitrary signals to the remote process, although you may be able to get its attention by using out-of-band data.
The protocol is described in detail in the rshd documentation.
The rcmd() function returns a valid socket descriptor on success.
It returns -1 on error and prints a diagnostic message on the standard error.
libsocket declares this function in sys/socket.h, but it's usually
defined in unistd.h.
#include <sys/uio.h> ssize_t readv (int fd, const struct iovec *iov, int iovcnt);
readv() performs a scatter-gather read from the specified file
descriptor fd. The data is written into a group of buffers described
by the array iov with iovcnt entries in a similar way to
read() (see read).
struct iovec is described in the section on writev()
(see writev).
On successful completion the function returns the number of bytes read. Otherwise, a value of -1 is returned and errno is set appropriately.
EINVAL
ssize_t.
IOV_MAX.
POSIX, Unix98
#include <sys/types.h> #include <sys/socket.h> ssize_t recv (int s, void * buf, size_t len, int flags);
The recv() function is used on a connected socket and is identical
to recvfrom() (see recvfrom) with NULL from and
fromlen parameters.
On success the number of octets received is return, or -1 and errno is set. See recvfrom.
POSIX, Unix98
#include <sys/types.h>
#include <sys/socket.h>
ssize_t recvfrom (int s, void * buf, size_t len, unsigned int flags,
struct sockaddr *from, size_t *fromlen);
recvfrom() is used to receive messages from a socket.
If from is non-NULL, the source address of the message is stored in it.
fromlen is a value-result parameter, it indicates the size of from
on entry and the size of from stored. If fromlen was too small,
it is truncated to the initial size. flags may have the value zero or
be the bitwise OR of any combination of one or more of the values:
MSG_OOB
select() (see select) indicates
an exception condition.
MSG_PEEK
MSG_WAITALL
On success the number of octets received is return, or -1 and errno is set:
EWOULDBLOCK.
EBADF
ENOTCONN
ENOTSOCK
EINTR
EFAULT
POSIX, Unix98
#include <netinet/in.h> #include <arpa/nameser.h> #include <resolv.h> extern struct state _res; int res_init (void);
The res_init() function reads the configuration files
(see host.conf, see resolv.conf) to get the default domain name,
search order and name server address(es). If no server is given, the local
host is tried. If no domain is given, that associated with the local host is
used. It can be overridden with the environment variable LOCALDOMAIN.
res_init() is normally executed by the first call to one of the
other resolver functions, e.g. res_query(), gethostbyname()
(see res_query, see gethostbyname).
The res_init() function returns 0 on success, or -1 if an error
occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
extern struct state _res;
int res_mkquery (int op, const char *dname, int class, int type,
char *data, int datalen, struct rrec *newrr,
char *buf, int buflen);
This function is a low-level routine used by res_query.
The res_mkquery() function constructs a query message in buf
of length buflen for the domain name dname. The query type
op is usually QUERY, but can be any of the types defined in
<arpa/nameser.h>. newrr is currently unused.
The resolver routines use global configuration and state information
contained in the structure _res, which is described with
res_query() (see res_query).
The res_mkquery() function returns the length of the response,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
extern struct state _res;
int res_query (const char *dname, int class, int type,
unsigned char *answer, int anslen);
The res_query() function queries the name server for the
fully-qualified domain name name of specified type and
class. The reply is left in the buffer answer of length
anslen supplied by the caller.
The resolver routines use global configuration and state information
contained in the structure _res, which is defined in
<resolv.h>. The only field that is normally manipulated by the
user is _res.options. This field can contain the bitwise OR
of the following options:
RES_INIT
res_init() has been called.
RES_DEBUG
RES_AAONLY
res_send() continues until
it fins an authoritative answer or returns an error. [Not currently
implemented].
RES_USEVC
RES_PRIMARY
RES_IGNTC
RES_RECURSE
res_send(). [Enabled by
default].
RES_DEFNAMES
res_search() will append the default domain name to
single component names, ie. those that do not contain a dot.
[Enabled by default].
RES_STAYOPEN
RES_DNSRCH
res_search() will search for host names in the current
domain and in parent domains. This option is used by gethostbyname()
(see gethostbyname). [Enabled by default].
res_query() returns the length of the response, or -1 if an error
occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
extern struct state _res;
int res_querydomain (const char *name, const char *domain,
int class, int type,
unsigned char *answer, int anslen);
The res_querydomain() function makes a query using res_query()
(see res_query) on the concatenation of name and domain.
The resolver routines use global configuration and state information
contained in the structure _res, which is described in
res_query() (see res_query).
The res_querydomain() function returns the length of the response,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
extern struct state _res;
int res_search(const char *dname, int class, int type,
unsigned char *answer, int anslen);
The res_search() function makes a query and waits for the response
like res_query() (see res_query, but in addition implements the
default and search rules controlled by RES_DEFNAMES and
RES_DNSRCH (see description of _res with res_query()
(see res_query)).
The res_search() function returns the length of the response,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netinet/in.h> #include <arpa/nameser.h> #include <resolv.h> extern struct state _res; int res_send (const char *msg, int msglen, char *answer, int anslen);
This function is a low-level routine used by res_query()
(see res_query).
The res_send() function sends a pre-formatted query given in
msg of length msglen and returns the answer in answer
which is of length anslen. It will call res_init()
(see res_init), if it has not already been called.
The resolver routines use global configuration and state information
contained in the structure _res, which is described with
res_query() (see res_query).
The res_send() function returns the length of the response,
or -1 if an error occurs.
This function is not portable. It is taken from Linux's libc 5 and so may be portable to Linux.
#include <netdb.h>
int rexec (char **ahost, int rport, const char *name, const char *pass,
const char *cmd, int *fd2p);
Under construction - if you have a good description, please inform the libsocket maintainer.
#include <sys/socket.h> #include <unistd.h> int rresvport (int *port);
The rresvport() function is used to obtain a socket with a privileged
address bound to it. This socket is suitable for use by
rcmd() (see rcmd) and several other functions. Privileged Internet
ports are those in the range 0 to 1023. Only the super-user is allowed to
bind an address of this sort to a socket.
The rresvport() function returns a valid, bound socket descriptor on
success. It returns -1 on error with errno set according to the reason
for failure. The error code EAGAIN is overloaded to mean
"All network ports in use".
libsocket declares this function in sys/socket.h, but it's usually
defined in unistd.h.
#include <sys/socket.h>
#include <unistd.h>
int ruserok (const char *rhost, int superuser,
const char *ruser, const char *luser);
The ruserok() function is used by servers to authenticate clients
requesting service with rcmd() (see rcmd).
The ruserok() function takes a remote host's name, two user names
and a flag indicating whether the local user's name is that of the
super-user. Then, if the user is *NOT* the super-user, it checks the
/etc/hosts.equiv file. If that lookup is not done, or is unsuccessful,
the .rhosts in the local user's home directory is checked to see if
the request for service is allowed.
If this file does not exist, is not a regular file, is owned by anyone other than the user or the super-user, or is writeable by anyone other than the owner, the check automatically fails.
If the local domain (as obtained from gethostname()
(see gethostname) is the same as the remote domain, only the machine name
need be specified.
Zero is returned if the machine name is listed in the hosts.equiv
file, or the host and remote user name are found in the .rhosts
file; otherwise -1 is returned.
libsocket declares this function in sys/socket.h, whereas it's usually
defined in unistd.h.
#include <sys/types.h> #include <sys/socket.h> int send (int s, const void * msg, size_t len, int flags);
The send() function is used to transmit data to a peer via socket,
send() is equivalent to sendto() (see sendto) call with a
NULL to parameter to and tolen.
The function return the number of octets accepted for transmission, Otherwise -1 with errno set. See See sendto.
POSIX, Unix98
#include <sys/types.h>
#include <sys/socket.h>
ssize_t sendto (int s, const void * msg, size_t len,
int flags, const struct sockaddr *to, size_t tolen);
The function sendto() is used to transmit a message to another socket.
The address of the target is given by to with tolen specifying
its size. A NULL value fo to indicats that no socket-address is
specifiend and the socket is in the CONNECTED state, the corresponding
tolen is then ignored. The length of the message is given by len.
If the message is too long to pass atomically through the underlying protocol,
the error EMSGSIZE is returned, and the message is not transmitted.
If no messages space is available at the socket to hold the message to be
transmitted, then sendto normally blocks, unless the socket has been
placed in non-blocking I/O mode. The select()
(see select)
call may be used to determine when it is possible to send more data.
The flags parameter may include one or more of the following:
MSG_OOB
out-of-band data on sockets that support this notion.
MSG_DONTROUTE
MSG_EOR
The call returns the number of characters sent, or -1 and errno set, if an error occurred.
EBADF
ENOTSOCK
s is not a socket.
EFAULT
EMSGSIZE
EWOULDBLOCK
EPIPE
ENOBUFS
POSIX, Unix98
#include <lsck/domname.h> int setdomainname (const char *name, size_t len);
This function is used to change the domain name. The domain name can be
accessed using getdomainname() (see getdomainname).
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
EPERM
EINVAL
not POSIX, not Unix98
This function is defined in unistd.h on Linux.
#include <netdb.h> extern int h_errno; void sethostent (int stayopen);
The sethostent() function specifies, if stayopen is true (1),
that a connected TCP socket should be used for the name server queries and
that the connection should remain open during successive queries. Otherwise,
name server queries will use UDP datagrams.
None
Unix98
#include <unistd.h> #include <lsck/hostname.h> int sethostname (const char *name, size_t len);
This function is used to change the host name of the current processor. The
host name is retrieved using gethostname() (see gethostname). The
domain name component can be retrieved and set using getdomainname()
and setdomainname() respectively (see getdomainname,
see setdomainname).
On success, zero is returned. On error, -1 is returned, and
errno is set appropriately.
EINVAL
EPERM
EFAULT
not POSIX, not Unix98
lsck/hostname.h is particular to libsocket. On Linux it is defined
in unistd.h.
#include <netdb.h> void setnetent (int stayopen);
The setnetent() function opens and rewinds the
networks file (see networks). If stayopen is true
(1), then the file will not be closed between calls to
getnetbyname() or getnetbyaddr()
(see getnetbyname, see getnetbyaddr).
None
Unix98
#include <netdb.h> void setprotoent (int stayopen);
The setprotoent() function opens and rewinds the
protocols file (see protocols). If stayopen is true
(1), then the file will not be closed between calls to
getprotobyname() or getprotobynumber()
(see getprotobyname, see getprotobynumber).
None
Unix98
#include <netdb.h> void setservent (int stayopen);
The setservent() function opens and rewinds the
services file (see services). If stayopen is true
(1), then the file will not be closed between calls to
getservbyname() or getservbyport()
(see getservbyname, see getservbyport).
None
Unix98
#include <sys/types.h>
#include <sys/socket.h>
int setsockopt (int s, int level, int optname,
const void *optval, int optlen);
setsockopt() manipulates the options associated with a socket.
Options may exist at multiple protocol levels; they are always present at the
uppermost socket level.
When manipulating socket options the level at which the option resides and the
name of the option must be specified. To manipulate options at the socket
level, level is specified as SOL_SOCKET. To manipulate options at
any other level the protocol number of the appropriate protocol controlling
the option is supplied. For example, to indicate that an option is to be
interpreted by the TCP protocol, level should be set to the protocol
number of TCP (see getprotoent).
The parameters optval and optlen are used to access option values
for setsockopt().
optname and any specified options are passed uninterpreted to the
appropriate protocol module for interpretation. The include file
<sys/socket.h> contains definitions for socket level options, described
below. Options at other protocol levels vary in format and name.
Most socket-level options utilize an int parameter for optval.
The parameter should be non-zero to enable a boolean option, or zero if the
option is to be disabled.
SO_LINGER uses a struct linger parameter, defined in
<sys/socket.h>, which specifies the desired state of the option and
the linger interval (see below).
SO_SNDTIMEO and SO_RCVTIMEO use a struct timeval
parameter, defined in <sys/time.h>.
The following options are recognized at the socket level.
SO_DEBUG
SO_REUSEADDR
SO_KEEPALIVE
SO_DONTROUTE
SO_LINGER
SO_BROADCAST
SO_OOBINLINE
SO_SNDBUF
SO_RCVBUF
SO_SNDLOWAT
SO_RCVLOWAT
SO_DEBUG enables debugging in the underlying protocol modules.
SO_REUSEADDR indicates that the rules used in validating addresses
supplied in bind() (see bind) call should allow reuse of local
addresses.
SO_KEEPALIVE enables the periodic transmission of messages on a
connected socket. Should the connected party fail to respond to these
messages, the connection is considered broken and processes using the socket
are notified via a SIGPIPE signal when attempting to send data.
SO_DONTROUTE indicates that outgoing messages should bypass the standard
routing facilities. Instead, messages are directed to the appropriate network
interface according to the network portion of the destination address.
SO_LINGER controls the action taken when unsent messages are queued on
socket and a close() is performed (see close).
If the socket promises reliable delivery of data and SO_LINGER is set,
the system will block the process on the close() attempt until it is
able to transmit the data or until it decides it is unable to deliver the
information (a timeout period, termed the linger interval, is specified in the
setsockopt() call when SO_LINGER is requested).
If SO_LINGER is disabled and a close() is issued, the system will
process the close in a manner that allows the process to continue as quickly
as possible.
The linger structure is defined in <sys/socket.h> as follows:
struct linger {
int l_onoff; /* Linger active */
int l_linger; /* How long to linger for */
};
l_onoff indicates whether to linger or not. If it is set to 1 then
l_linger contains the time in hundredths of seconds how long the
process should linger to complete the close(). If l_onoff
is set to zero the process returns immediately.
The option SO_BROADCAST requests permission to send broadcast datagrams
on the socket. Broadcast was a privileged operation in earlier versions of the
system.
With protocols that support out-of-band data, the SO_OOBINLINE
option requests that out-of-band data be placed in the normal data input
queue as received; it will then be accessible with recv or
read calls without the MSG_OOB flag. Some protocols always
behave as if this option is set.
SO_SNDBUF and SO_RCVBUF are options to adjust the normal buffer
sizes allocated for output and input buffers, respectively. The buffer size
may be increased for high-volume connections, or may be decreased to limit the
possible backlog of incoming data. The system places an absolute limit on
these values.
SO_SNDLOWAT is an option to set the minimum count for output
operations. Most output operations process all of the data supplied by the
call, delivering data to the protocol for transmission and blocking as
necessary for flow control. Nonblocking output operations will process as
much data as permitted subject to flow control without blocking, but will
process no data if flow control does not allow the smaller of the low water
mark value or the entire request to be processed. A select()
(see select) operation testing the ability to write to a
socket will return true only if the low water mark amount could be processed.
The default value for SO_SNDLOWAT is set to a convenient size for
network efficiency, often 1024.
SO_RCVLOWAT is an option to set the minimum count for input operations.
In general, receive calls will block until any (non-zero) amount of data is
received, then return with smaller of the amount available or the amount
requested. The default value for SO_RCVLOWAT is 1. If
SO_RCVLOWAT is set to a larger value, blocking receive calls normally
wait until they have received the smaller of the low water mark value or the
requested amount. Receive calls may still return less than the low water mark
if an error occurs, a signal is caught, or the type of data next in the
receive queue is different than that returned.
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
Possible errors from this function are:
EBADF
ENOTSOCK
ENOPROTOOPT
EFAULT
Unix98
#include <sys/socket.h> int shutdown (int s, int how);
shutdown() stops communication in one or both directions of a
full-duplex connection on socket s. how is one of the following:
SHUT_RD
SHUT_WR
SHUT_RDWR
These correspond to the values 0, 1 and 2 respectively.
If sends are disabled for a stream socket (SOCK_STREAM), any further
writes on the socket will return EPIPE and raise the signal
SIGPIPE (see sendto).
On successful completion the function returns 0. Otherwise, a value of -1 is returned and errno is set appropriately.
EBADF
ENOTSOCK
ENOTCONN
POSIX, Unix98
#include <sys/socket.h> int sockatmark (int s);
The sockatmark() function determines whether the socket descriptor
s is at the out-of-band data mark. If the libsocket interface supports
it, sockatmark() will return 1 when all data preceding the mark have
been read and the out-of-band data mark is the first element in the receive
queue. sockatmark() does not remove the mark from the stream.
On successful initialization the function returns 1, if the protocol has marked the data stream and all data preceeding the mark have been read. It returns 0, if there is no mark, or if data preceeds the mark in the receive queue. Otherwise, -1 is return and errno is set:
EBADF
ENOSYS
sockatmark() operation.
not ANSI, POSIX
#include <sys/socket.h> int socket (int domain, int type, int protocol);
socket() creates a communication end-point and returns its file
descriptor.
domain refers to a communication domain, e.g. Internet domain, Unix
domain. These are specified by the AF_* constants, e.g. AF_INET,
AF_UNIX, as defined in sys/socket.h.
type specifies how the communication takes place, e.g. streams,
datagrams. These are specified by the SOCK_ constants, e.g.
SOCK_STREAM, SOCK_DGRAM, as defined in sys/socket.h.
SOCK_STREAM supports reliable, sequenced, bidirectional streams of
binary data. SOCK_DGRAM supports unreliable connectionless packets.
These packets may have a maximum size.
protocol specifies the communications protocol to use, e.g. TCP, UDP.
For the Internet domain (i.e. IP), these are defined by the IPPROTO_
constants in netinet/in.h, e.g. IPPROTO_TCP, IPPROTO_UDP.
If protocol is zero, the default protocol for the socket's domain &
type is used, e.g.
fd = socket(AF_INET, SOCK_STREAM, 0); would create a TCP/IP socket.
fd = socket(AF_INET, SOCK_DGRAM, 0); would create a UDP/IP socket.
libsocket supports the following triplets:
-1 is returned and errno set on error. Otherwise, a positive non-zero integer number is returned, a file descriptor.
Possible errors are:
EMFILE
ENFILE
ENODEV
ENOAFSUPPORT
EPROTONOSUPPORT
POSIX, Unix98
#include <sys/socket.h> int socketpair (int domain, int type, int protocol, int sv[2]);
socketpair() creates a pair of unbound connected sockets. The sockets
are identical. sv contains two file descriptors, one for each socket.
domain, type and protocol are described in the section
on socket() (see socket). Using a protocol of 0 will give a
default protocol.
0 is returned on success. Otherwise -1 is returned and the error code is stored in errno.
Possible errors for this function are:
EOPNOTSUPP
EAFNOTSUPP
ENOPROTOSUPPORT
POSIX, Unix98
#include <sys/uio.h> ssize_t writev (int fd, const struct iovec *iov, int iovcnt);
writev() performs a scatter-gather write to the specified file
descriptor fd. A group of buffers described by the array iov,
with iovcnt entries, is written to fd in a similar
way to write() (see write).
struct iovec is defined as follows:
struct iovec {
void *iov_base; /* Base address of a memory region for I/O */
size_t iov_len; /* Size of memory region */
};
On successful completion the function returns the number of bytes written. Otherwise, a value of -1 is returned and errno is set appropriately.
EINVAL
ssize_t.
IOV_MAX.
POSIX, Unix98
Installing the binary distribution (ready-to-run) version of libsocket is
fairly straightforward. Firstly, back up the DJGPP header file
include/netinet/in.h, because this is overwritten by one of libsocket's
header files. Then extract the ZIP file into the DJGPP directory
(e.g. c:\djgpp), preserving directory names - e.g. use PKUNZIP's
-d option. The distribution documentation files (e.g. readme files)
can then be found off the c:\djgpp\contrib directory.
To install the info files properly, you will need GNU texinfo 4.02. Run the following commands:
install-info --info-file=c:/djgpp/info/lsck.inf --info-dir=c:/djgpp/info install-info --info-file=c:/djgpp/info/netsetup.inf --info-dir=c:/djgpp/info
Now install the Winsock 2 support virtual device driver (see the section below). libsocket should now be installed correctly and ready to use (see Getting Started).
libsocket's binary distribution is built with debugging information, because it is still in development. Programs built with libsocket may be larger than expected, because of the debugging information. Debugging information can be removed using strip (see strip).
Installing the documentation distribution (ready-to-run) version of libsocket
is fairly straightforward. Extract the ZIP file into the DJGPP directory
(e.g. c:\djgpp), preserving directory names - e.g. use PKUNZIP's
-d option. The distribution documentation files (e.g. readme files)
can then be found off the c:\djgpp\contrib directory.
Extract the ZIP into the DJGPP directory (e.g. c:\djgpp), preserving
directory names - e.g. use PKUNZIP's -d option. The sources can
then be found off the c:\djgpp\contrib directory.
To build libsocket requires the following packages:
Optional packages are as follows:
In the following instructions, I have assumed that bash is the shell. If not,
type bash and then follow the instructions.
autoconf config.in | sed -e 's/config\.guess/config.gue/' > config
It may be necessary to regenerate the configure script, because the DJGPP port of autoconf has some extra m4 macros that make it work on DOS. If a Linux (or other Unix) configure script is used under DOS, it will not work properly.
The usage of sed above is necessary to convert the filename
config.guess to the short filename config.gue that is used in
the libsocket distribution (so that libsocket can be compiled on plain ol'
DOS).
[ Note that source distributions of libsocket should be set up for compilation
with DJGPP, so this step shouldn't be necessary. If it doesn't work, try
running autoconf. ]
./config to detect programs and the default prefix (the DJGPP
directory, $DJDIR). If you wish to enable debugging information, use
the --enable-debug switch, like so:
./config --enable-debug
The --prefix option can be used to specify the prefix used when
installing the built package. This should probably be the DJGPP directory,
but you can install it elsewhere if you want. The default is the DJGPP
directory. As an example:
./config --prefix=c:/somedir/ls080
make dep
make all
make install to install libsocket. If you want to
see what would be installed, use make -n install instead. This will
install the headers, library and info documentation (including adding an entry
to the info directory) into the prefix specified above.
Now install the Winsock 2 support virtual device driver (see the section below).
libsocket should now be installed correctly and ready to use (see Getting Started).
To work with Winsock 2, libsocket needs a virtual device driver (VxD) to be installed. This VxD is called SOCK.VXD and was written as part of the port of the Coda Network File System to Windows '95.
SOCK.VXD is included in the redist directory of the libsocket
binary and source distributions. The program sockvxd.exe is
a self-extracting installer. To run this program, use the installvxd
Makefile target:
make installvxd
When prompted, select the option to dynamically load SOCK.VXD - then it will only be loaded when used by libsocket programs.
This section is under construction.
See Configuration.
libsocket's configuration can be controlled by a number of files. These files have the same purpose and are in the same format as the ones on Linux, and hence many Unices. Some of these files are also present on Windows - these can be used libsocket. libsocket can run without configuration files, but only in certain circumstances.
libsocket comes with a program called netsetup, which generates the necessary configuration files (see Introduction).
libsocket's main configuration file is lsck.cfg.
libsocket's main configuration file is lsck.cfg. Its location is
specified by the environment variable LSCK. If you use the normal
DOS shell, command.com, you would use:
SET LSCK=c:\lsck
You may want to add this to your autoexec.bat.
In bash (see Top) you would use:
export LSCK=c:/lsck
You could also add a line to DJGPP.ENV
(see DJGPP.ENV) somewhere near the start, e.g. just
after the line like:
+LFN=Y
add a line like:
+LSCK=c:/lsck
If you are using bash, you should be aware that it sets the environment
variable HOSTNAME automatically
(see Bash Variables). This
interferes with libsocket's automatic configuration; it may cause problems,
when trying to resolve DNS names.
To avoid this problem, please add the following line to your _bashrc file (see Bash Startup Files):
unset HOSTNAME
lsck.cfg is written in a similar way to Windows .INI files - the file
is split into different sections. There are four sections:
main, for libsocket global settings, e.g. resolver files, host name;
wsock, for the wsock (Winsock 1) interface;
csock, for the csock (Winsock 2) interface;
unix, for the unix (Unix domain sockets) interface.
| Key | Possible Values | Default Value
|
| hostname | Host name with domain | (Via auto-configuration)
|
| debug | on, off, verbose, yes, no, 0, 1, 2 | off
|
| hosts | 'hosts' file location | 'hosts', Windows directory
|
| networks | 'networks' file location | 'networks', Windows directory
|
| services | 'services' file location | 'services', Windows directory
|
| protocols | 'protocols' file location | 'protocol', Windows directory
|
| host.conf | 'host.conf' file location |
|
| resolv.conf | 'resolv.conf' file location |
|
| hosts.equiv | 'hosts.equiv' file location |
|
| .rhosts | '.rhosts' file location | User's home directory
|
| .netrc | '.netrc' file location | User's home directory
|
The host name could be, for example, myhost.mycompany.com. It is usually a good idea to set hosts, networks, services and protocols to point to your Windows directory, e.g.:
hosts=c:\windows\hosts networks=c:\windows\networks services=c:\windows\services protocols=c:\windows\protocol
hosts.equiv, .rhosts and .netrc are for remote command
execution - See netrc. libsocket will look for .rhosts
and .netrc in the current user's home directory with the names
.rhosts, rhosts, rhosts and .netrc, netrc
and _netrc respectively. The files specified in lsck.cfg are
global and are only used if none were found in the user's home directory.
The home directory is specified by the environment variable HOME.
| Key | Possible Values | Default Value
|
| Enabled | true, yes, 1, false, no, 0 | true
|
| IPAddress | Computer's IP address | (Via auto-configuration)
|
| IPMask | Computer's IP network mask | (Via auto-configuration)
|
| Gateway | Gateway's IP address | (Via auto-configuration)
|
| DNS1Address | DNS server 1's IP address | (Via auto-configuration)
|
| DNS2Address | DNS server 2's IP address | (Via auto-configuration)
|
| DNS3Address | DNS server 3's IP address | (Via auto-configuration)
|
| DNS4Address | DNS server 4's IP address | (Via auto-configuration)
|
The loopback network is always present and should not be included in the list above. The loopback network is an internal IP network with the address range 127.x.x.x (also written as 127.0.0.0/8). The localhost is the host's IP address on this network - 127.0.0.1.
| Key | Possible Values | Default Value
|
| Enabled | true, yes, 1, false, no, 0 | true
|
host.conf configures the order of name resolving. This file tells the networking libraries which name resolving resources to use, and in what order.
Valid sources are hosts, bind and nis.
hosts refers to the file hosts, which contains name to IP
address mappings. bind refers to DNS servers, which are configured
elsewhere - See resolv.conf. nis refers to Network Information
Services (NIS) aka Yellow Pages (YP), which probably won't be very common in a
Windows environment, but might be present if Unix hosts are used.
[ NIS support is not present in libsocket. ]
If you have DNS servers, the recommended order is
bind then hosts:
order bind, hosts
If you don't have a DNS server, then only hosts is required, like so:
order hosts
If you specify bind as well as hosts
without a DNS server, then programs are likely to stall when resolving names.
order
order service-1 ... service-n
This specifies the order in which name resolving services should be used.
Valid service options are bind, hosts and nis.
trim
trim domains
?
multi
multi (on|off)
This makes the resolver return multiple matches from hosts
(see hosts), which can be slow.
nospoof
nospoof (on|off|warn|warn off)
?
alert
alert (on|off)
?
reorder
reorder (on|off)
?
The resolver is a set of routines in the C library (in this case libsocket) that provide access to the Internet Domain Name System (DNS). The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information.
On a normally configured system this file should not be necessary. The only name server to be queried will be on the local machine, the domain name is determined from the host name, and the domain search path is constructed from the domain name.
The different configuration options are:
nameserver
nameserver address
Address specifies the Internet address (in dot notation) of a name server
that the resolver should query. Up to MAXNS (currently 3) name servers may be
listed, one per keyword. If there are multiple servers, the resolver library
queries them in the order listed. If no nameserver entries are present,
the default is to use the name server on the local machine. (The algorithm
used is to try a name server, and if the query times out, try the next, until
out of name servers, then repeat trying all the name servers until a maximum
number of retries are made).
domain
domain domain
Domain specifies the local domain name. Most queries for names within
this domain can use short names relative to the local domain. If no
domain entry is present, the domain is determined from the local host
name returned by gethostname. The domain part is
taken to be everything after the first .. Finally, if the host name
does not contain a domain part, the root domain is assumed.
search
search domain-1 ... domain-n
This specifies the search list for host-name lookup. The search list is
normally determined from the local domain name; by default, it contains only
the local domain name. This may be changed by listing the desired domain
search path following the search keyword with spaces or tabs separating
the names.
Most resolver queries will be attempted using each component of the search path in turn until a match is found. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains.
The search list is currently limited to six domains
with a total of 256 characters.
sortlist
sortlist address-1[/netmask-1] ... address-n[/netmask-n]
Sortlist allows addresses returned by gethostbyname to be sorted (see gethostbyname). A sortlist is specified by IP address and netmask pairs. The netmask is optional and defaults to the natural netmask of the net. The IP address and optional network pairs are separated by slashes. Up to 10 pairs may be specified. Here is an example:
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
options
options option-1 ... option-n
Options allows certain internal resolver variables to be modified. Option can be one of the following:
debug
debug sets RES_DEBUG in _res.options.
ndots
ndots:n
ndots sets a threshold, n, for the number of dots which
must appear in a name given to res_query() (see res_query)
before an initial absolute query will be made. The default for
n is 1, meaning that if there are any dots in a name, the name
will be tried first as an absolute name before any search list
elements are appended to it.
The domain and search keywords are mutually exclusive.
If more than one instance of these keywords is present,
the last instance wins.
The search keyword of a system's resolv.conf file can be
overridden on a per-process basis by setting the environment variable
LOCALDOMAIN to a space-separated list of search domains.
The options keyword of a system's resolv.conf file can be
amended on a per-process basis by setting the environment variable
RES_OPTIONS to a space-separated list of resolver options
as explained above under options.
The keyword and value must appear on a single line, and the keyword
(e.g. nameserver) must start the line. The value follows
the keyword, separated by white space.
This section describes host name resolution. Hostnames are domains. A domain
is a hierarchical, dot-separated list of subdomains. For example, the machine
monet, in the Berkeley subdomain of the EDU subdomain of
the Internet Domain Name System would be represented as:
monet.Berkeley.EDU
(with no trailing dot).
Hostnames are often used with network client and server programs, which must generally translate the name to an address for use. (This task is usually performed by the library routine gethostbyname.) The default method for resolving hostnames by the Internet name resolver is to follow RFC 1535's security recommendations. Actions can be taken by the administrator to override these recommendations and to have the resolver behave the same as earlier, non-RFC 1535 resolvers.
The default method (using RFC 1535 guidelines) follows:
If the name consists of a single component, i.e. contains no dot, and if the
environment variable HOSTALIASES is set to the name of a file,
that file is searched for a string matching the input hostname. The file
should consist of lines made up of two strings separated by white-space, the
first of which is the hostname alias, and the second of which is the complete
hostname to be substituted for that alias. If a case-insensitive match is
found between the hostname to be resolved and the first field of a line in
the file, the substituted name is looked up with no further processing.
If there is at least one dot in the name, then the name is first tried as
is. The number of dots to cause this action is configurable by setting the
threshold using the ndots option in
resolv.conf (see resolv.conf) (default: 1). If the name
ends with a dot, the trailing dot is removed, and the remaining name is
looked up (regardless of the setting of the 'ndots' option) and no further
processing is done.
If the input name does not end with a trailing dot, it is looked up by
searching through a list of domains until a match is found. If neither the
search option in the resolv.conf (see resolv.conf)
file or the LOCALDOMAIN environment variable is used, then the
search list of domains contains only the full domain specified by the domain
option (in resolv.conf) or the domain used in the local hostname
(see resolv.conf).
For example, if the domain option is set to CS.Berkeley.EDU,
then only CS.Berkeley.EDU will be in the search list and will be the only
domain appended to the partial hostname, for example, lithium,
making lithium.CS.Berkeley.EDU the only name to be tried using the
search list.
If the search option is used in resolv.conf or the environment
variable, LOCALDOMAIN is set by the user, then the search list will
include what is set by these methods. For example, if the search
option contained
ICS.Berkeley.EDU CChem.Berkeley.EDU Berkeley.EDU
then the partial hostname (e.g., lithium) will be tried with each
domainname appended (in the same order specified). The resulting hostnames
that would be tried are:
lithium.CS.Berkeley.EDU lithium.CChem.Berkeley.EDU lithium.Berkeley.EDU
The environment variable LOCALDOMAIN overrides the
search and domain options, and if both search and domain
options are present in the resolver configuration file, then only the last
one listed is used (see resolv.conf).
If the name was not previously tried as-is (i.e., it fell below the
ndots threshold or did not contain a dot), then the name as
originally provided is attempted.
hosts is the host name to IP address mapping file. This file tells the
host name resolver the IP address corresponding to each host name. This is
useful if there is no DNS server on the network. It can also be used if the
DNS server does not have a record for a particular host name, but its IP
address is known. A similar mapping for networks is performed by
networks.
The file is a plain ASCII file. Comments are denoted by a hash at the start of a line. Each line has the following format:
IP-address host-name [alias]
e.g.
# hosts - host name to IP address translation file 127.0.0.1 localhost 192.168.0.2 gertrude 192.168.0.3 herbert 192.168.0.4 norman 192.168.0.5 jonathon jon
There should always be a line refering to localhost. This is the local
computer, and is always accessible.
Note: Windows doesn't use the aliases, so you will need multiple lines for the same IP address to fake aliasing.
networks is the network name to network IP address mapping file.
This file tells the host name resolver the network component of an IP address
corresponding to each network name. This is useful if there is no DNS server
on the network. It can also be used if the DNS server does not have a record
for a particular network name, but its IP address is known. A similar mapping
for hosts is performed by hosts.
The file is a plain ASCII file. Comments are denoted by a hash at the start of a line. Each line has the following format:
IP-address network-name [alias]
e.g.
# networks - network name to IP address translation file 127 loopback 192.168.0 mynet intranet
There should always be a line refering to loopback. This is the
loopback device, and is always accessible.
Note 1: Windows doesn't use the aliases, so you will need multiple lines for the same network IP address to fake aliasing.
Note 2: The network IP address can be constructed from an IP address and network mask, e.g. if you have an IP address of 1.2.3.4 and a netmask of 255.255.0.0, then AND'ing them gives a network IP address of 1.2.
services is the Internet network services list file. services
is a plain ASCII file providing a mapping between friendly textual
names for internet services, and their underlying assigned port
numbers and protocol types. Every networking program should look into
this file to get the port number (and protocol) for its service.
The following C library routines support querying services from
programs:
Port numbers are assigned by the IANA (Internet Assigned Numbers Authority), and their current policy is to assign both TCP and UDP protocols when assigning a port number. Therefore, most entries will have two entries, even for TCP only services.
Port numbers below 1024 (so-called 'low numbered' ports) can only be bound to by root (see bind). This is so that clients connecting to low numbered ports can trust that the service running on the port is the standard implementation, and not a rogue service run by a user of the machine. Well-known port numbers specified by the IANA are normally located in this root only space.
The presence of an entry for a service in the
services file does not necessarily mean that the service is currently
running on the machine.
The location of the services file is defined by _PATH_SERVICES
in /usr/include/netdb.h. This is usually set to /etc/services.
Each line describes one service, and is of the form:
service-name port protocol [alias-1 ... alias-n]
where:
tcp
and udp.
Either spaces or tabs may be used to separate the fields.
Comments are started by the hash sign (#) and continue until the end of the line. Blank lines are skipped.
The service-name should begin in the first column of the file, since
leading spaces are not stripped. A service-name
can be any printable characters excluding space and tab, however,
a conservative choice of characters should be used to minimise
inter-operability problems. Eg: a-z, 0-9, and hyphen (-) would seem a
sensible choice.
Lines not matching this format should not be present in the file.
(Currently, they are silently skipped by getservent(),
getservbyname() and getservbyport(). However, this behaviour
should not be relied on.)
As a backwards compatibility feature, the slash (/) between the port
number and protocol name can in fact be either a slash or a comma
(,). Use of the comma in modern installations is depreciated.
This file might be distributed over a network using a network-wide naming service like Yellow Pages/NIS or BIND/Hesiod.
A sample services file might look like this:
netstat 15/tcp qotd 17/tcp quote msp 18/tcp # message send protocol msp 18/udp # message send protocol chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp 21/tcp # 22 - unassigned telnet 23/tcp
protocols is the protocols definition file. This file is a plain
ASCII file, describing the various DARPA internet protocols that are
available from the TCP/IP subsystem. It should be consulted instead of using
the numbers in the ARPA include files, or, even worse, just guessing them.
These numbers will occur in the protocol field of any IP header.
Keep this file untouched since changes would result in incorrect IP packages. Protocol numbers and names are specified by the DDN Network Information Center.
Each line is of the following format:
protocol-name protocol-number [alias-1 ... alias-n]
where the fields are delimited by spaces or tabs. Empty lines and lines starting with a hash mark (#) are ignored. Remainder of lines are also ignored from the occurrence of a hash mark.
The field descriptions are:
This file might be distributed over a network using a networkwide naming service like Yellow Pages/NIS or BIND/Hesoid.
netrc configures auto-logins for remote hosts. [ This was taken from the man page ftp(1) from GNU inetutils. ]
The .netrc file contains login and initialization information
used by the auto-login process. It resides in the user's home directory.
The following tokens are recognized; they may be separated by spaces,
tabs, or new-lines:
machine
machine name
This identifies a remote machine name. The auto-login process searches
the .netrc file for a machine token that matches the remote
machine specified on the ftp(1) command line or as an open command
argument. Once a match is made, the subsequent .netrc tokens are
processed, stopping when the end of file is reached or another machine
or a default token is encountered.
default
default name
This is the same as machine except that default matches any name.
There can be only one default token, and it must be after all
machine tokens. This is normally used as:
default login anonymous password user@site
thereby giving the user automatic anonymous ftp login to machines not
specified in .netrc. This can be overridden by using the -n
flag to disable auto-login.
login
login name password password
If this token is present, the auto-login process will initiate a login using the specified name.
If the password token is present, the auto-login process will supply the
specified string if the remote server requires a password as part of the login
process. Note that if this token is present in the .netrc
file for any user other than anonymous, ftp(1) will abort the auto-login
process if the .netrc is readable by anyone besides the user.
account
account string
This supplies an additional account password. If this token is present,
the auto-login process will supply the specified string if the remote server
requires an additional account password, or the auto-login process will
initiate an ACCT command if it does not.
macdef
macdef name
This defines a macro. This token functions like the ftp(1) macdef
command functions. A macro is defined with the specified name; its contents
begin with the next .netrc line and continue until a null line
(consecutive new-line characters) is encountered. If a macro named
init is defined, it is automatically executed as the last step in the
auto-login process.
This section gives a brief introduction to SMTP mail addresses, as used on the Internet. These addresses are in the general format
user@domain
where a domain is a hierarchical dot separated list of subdomains. For example, the addresses
eric@monet.berkeley.edu Eric Allman <eric@monet.berkeley.edu> eric@monet.berkeley.edu (Eric Allman)
are valid forms of the same address.
The domain part (monet.berkeley.edu) may be the name of an internet
host, or it may be a logical mail address. The domain part is not
case sensitive.
The local part (eric) is often a user name, but its meaning is
defined by the local software. It can be case sensitive, but usually
isn't. If you see a local-part that looks like garbage, it is usually
because of a gateway between an internal e-mail system and the net,
here are some examples:
"surname/admd=telemail/c=us/o=hp/prmd=hp"@some.where USER%SOMETHING@some.where machine!machine!name@some.where I2461572@some.where
(These are, respectively, an X.400 gateway, a gateway to an arbitrary inernal mail system that lacks proper internet support, an UUCP gateway, and the last one is just boring username policy.)
The real-name part (Eric Allman) can either be placed first, outside
<>, or last, inside (). (Strictly speaking the two aren't the same,
but the difference is outside the scope of this page.) The name may
have to be quoted using "" if it contains certain characters, most
commonly .:
"Eric P. Allman" <eric@monet.berkeley.edu>
Many mail systems let users abbreviate the domain name. For instance,
users at berkeley.edu may get away with eric@monet to send mail to
Eric Allman. This behavior is deprecated.
Under some circumstances it may be necessary to route a message through several hosts to get it to the final destination. Normally this happens automatically and invisibly, but sometimes not, particularly with old and broken software. Addresses which show these relays are termed route-addrs. These use the syntax:
<@hosta,@hostb:user@hostc>
This specifies that the message should be sent to hosta, from there to hostb, and finally to hostc. Some hosts disregard route-addrs and send directly to hostc.
Route-addrs occur frequently on return addresses, since these are generally
augmented by the software at each host. It is generally possible to ignore
all but the user@hostc part of the address to determine the actual
sender.
Every site is required to have a user or user alias designated postmaster to which problems with the mail system may be addressed. The postmaster address is not case sensitive.
rtfm.mit.edu and many mirrors store a collection of FAQs. Please find and use a nearby FAQ archive; there are dozens or hundreds around the world.
setsockopt() call.
SO_OOBINLINE or a SIGURG handler.
The Winsock 2.x support is provided by SOCK.VXD from the Windows '95 port of the Coda Network File System. The following are bugs in SOCK.VXD:
SO_REUSEADDR is set, so local addresses are reused on
the bind() call.
getsockname() call does not seem to work. libsocket
attempts to circumvent this by using a table of IP addresses to determine
the local IP address, but this can easily fail.
accept()'d. The number of connections is that specified by
the earlier listen() call.
IAMDRV.VXD.
There may be problems with other firewall software, but no other programs have been reported yet.
There are a number of bugs in the csock inteface within libsocket:
recv() function is for stream sockets only; its
recvfrom() function is for datagrams only. The csock interface does
not distinguish properly between these two - i.e. it does not map the BSD
socket call recvfrom() on a stream socket onto
SOCK.VXD's recv() call.
The auto-configuration code does not work for dial-up or WAN links. It should work on LANs for statically or dynamically (DHCP) assigned IP addresses. A method is needed that will obtain the IP address information successfully in all cases.
The Unix domain socket code is an alpha state. It uses pairs of LAN Manager mailslots to implement bidirectional communication. It was written using the assumption that local mailslots are 100% reliable. Mailslots are not reliable; hence the code needs to be rewritten to cope with data loss.
libsocket programs crash on exit on Windows NT. Although Windows NT is not supported by libsocket, these programs should abort gracefully.
The following people have contributed to libsocket. The list is in no particular order. A big thank you to all those listed!
His Wsock library is the base of this library.
His dsock library helped Indrek to get select() and blocking recv() calls
work. He also contributed some information on how to obtain Windows machine
and DNS IP addresses.
They contributed the registry-access code that is used to automatically find
out some IP settings. Alfons is the maintainer.
For Win95 port of the Coda network file system, a VxD for BSD socket
networking was produced. This enabled me to add Winsock 2 support to
libsocket. This is something I had been trying to do for over a year,
so I am extremely grateful and happy that this has happened! Big thanks.
- Rich
He has a very nice habit of finding all the nastiest bugs and reporting them. There would be some very bad "features" in the library without him. - Indrek
He pointed out some bugs and has some great ideas. A man with an open
mind. - Indrek - I agree - Rich
Thanks to Indrek for writing the library in the first place, letting me
contribute to it, and then, gulp, trusting me to look after it. This man has
a lot faith and trust! Thanks also for providing a mirror site.
- Rich
Thanks to Petr for finding that libsocket's non-blocking sockets didn't work
properly, and for informing me how they should work. - Rich
Thanks to Vlad for noticing that his data was being mangled by libsocket,
which lead to me finding an absolutely huge bug! - Rich
Thanks to Phillipe for trying to port BSD traceroute, finding problems and
then diving into libsocket's internals to find out the problem.
Bravery! Thanks for the feedback. - Rich
Thanks to Ove for providing me with information about how Windows 3.11
stores its DNS IP addresses. Thanks for your packet driver code - sorry
I was unable to integrate it into libsocket. - Rich
Thanks to Michael for pointing out that the resolving code didn't open the
files in text mode, which meant that setting fmode to binary could lead to
the resolving code failing inexplicably. - Rich
Thanks for providing a mirror site for a while. - Rich
Thanks for sending me a *huge* amount of networking information. I hope I
actually have enough time at some point to something useful with it ;)
Thanks for the support and ideas! - Rich
Thanks for all the advice on sockets on Unix, POSIX, etc. Thanks for
motivating me to add Unix domain socket support. I think libsocket will
improve and prosper greatly with your support! - Rich
Thanks for letting me distribute your sockets programming guide with
libsocket. - Rich
Thanks for being patient, giving me copious debugging info and feedback
generally! - Rich
For his continual advice and help with all things DJGPP - an inspiration.
For the DJGPP phenomenom!
Thanks to everyone else who has shown interest in libsocket, and has mailed me to say they are using it. Please continue to do this!
These changes are in no particular order:
FIONBIO versus O_NONBLOCK (see ioctl_list).
gethostname() page now describes how the host name
is discovered (see gethostname).
tags, id and ID targets to Makefile, for building
Emacs tags and GNU id-utils files respectively.
gethostname(); previously EINVAL was erroneously
returned for buffers larger than MAXHOSTNAME. This broke the name
resolving code for automatic configuration.
$HOSTNAME (see libsocket and environment variables).
netinet/in.h to work around a compiler bug in g++ 2.95.x.
The structure struct ip_opts is not defined, when using g++ 2.95.x.
These changes are in no particular order:
solist now builds on Linux.
echo was actually
required).
all target now fixed in source distribution, so that it doesn't run
netsetup by default. This problem stopped cross-compilation from
completing.
ELOOP is now defined conditionally in
include/lsck/errno.h, so as not to conflict with DJGPP 2.04's
symlink support (DJGPP 2.04 is currently in development). Thanks to
Laurynas Biveinis.
src/newerror.c.
These changes are in no particular order:
redist directory.
readv() and
writev().
solist, to list the available socket options for
UDP and TCP options.
Makefile.src, used to create the
directory lib when building the library. This was moved to
src/Makefile, since this is where the library is actually built.
uninstall Makefile target previously failed to uninstall some
files from $DJDIR/include/arpa. This has been fixed.
socketpair() function has been implemented, but only for Unix domain
sockets (see below).
sockatmark(), which always fails.
SHUT_* definitions for shutdown(); use of
size_t, ssize_t instead of int.
fcntl() so that it accepts more than one option simultaneously.
Previously passing more than one option OR'd together would have caused
fcntl() to fail.
accept() to work when the peer address is NULL. This error was
pointed out by Alain Magloire.
__lsck_init()
calls and use of isfdtype(), as suggested by Alain Magloire.
gethostname(), sethostname(),
perror(), strerror() and uname() functions. The old
libsocket functions __lsck_gethostname(), __lsck_sethostname(),
lsck_perror() and lsck_strerror() are now deprecated, but will
still work.
gethostname(), sethostname(), getdomainname(),
setdomainname(), so that they interact properly.
send(), sendto() now raise SIGPIPE when sending data on a
connection that has had its outbound channel shutdown.
getsockopt()) support for the following socket options:
connect(),
sendto(). Hopefully not too many bugs have been introduced here.
struct so_linger passed to
WSOCK.VXD, supported socket options, etc.
lsck/copyrite.h, containing information about
the version of libsocket (version numbers, etc.).
src/inet/ghstnmad.c,
src/inet/r_init.c, src/csock/c_initnt.c.
man/ off the DJGPP directory, not in
share/man/ as previously.
sys/socket.h, which meant that u_int was undefined
when using SO_DONTLINGER. sys/socket.h now includes
lsck/bsdtypes.h too, to define u_int.
src/initnt.c where csock interface was not
uninitialised.
src/fcntl.c that meant the logical NOT of the true value
would be obtained doing e.g.:
fcntl(sock, F_GETFL, O_NONBLOCK)
src/csock/c_recv.c in __csock_recvfrom(). It should
now return the address correctly. Also, it should work if the from
parameter is NULL.
src/wsock/w_recv.c which always returned the address, even
if the from parameter were NULL.
FIONREAD with ioctl() for Winsock 1.x module
(wsock).
src/csock/c_select.c functions __csock_select(),
__csock_select_wait() so they actually work properly.
isfdtype(). However, necessary includes are in
sys/socket.h rather than sys/stat.h.
fcntl() support for csock interface.
FIONBIO for both wsock &
csock.
select() on socket that lead to select'ing for
reading always succeeded if the socket was ready for writing.
| Old name(s) | New name(s)
|
| src/wsock/win311 | src/win3x
|
| src/wsock/win95 | src/win9x
|
| src/wsock/win95/*.c | src/win9x/w9x_*.c (& some names altered)
|
demo/linioctl.c to demo/ioctl.c. The refs in the man
pages have also been changed.
accept() & closesocket() memory leaks fixed.
connect() fixed for non-blocking operation.
getsockopt() for wsock interface (src/wsock/w_sckopt.c) now
converts errors returned by SO_ERROR from Winsock to BSD errors.
select() for sockets bug (again).
connect() so it stores the local socket name.
There are probably many more changes than this, as I've been working on this version for a while, trying to add DOS support. It still seems to work the same as version 0.7.3 though :( Still no support for DOS, Win98, etc.
sys/socket.h.
ENOTSOCK error message as
appropriate.
SIOCGIFNAME,
SIOCGIFADDR, SIOCGIFDSTADDR, SIOCGIFNETMASK.
LIBSOCKET to LSCK environment variable.
Also made the configuration more flexible by the use of a configuration file.
perror() and strerror() give
proper error messages for BSD socket errors.
resolv_conf_getdomainname() in
src/config/domname.c. Fixed the bug in the Windows 3.11 DNS IP address
code. Fixed the dependency checking, so it works again (oops). The problems
with ioctls have also been fixed (see above). Finally nailed the bizarre
select() bugs (phew).
-Werror is only used when compiling debug versions.
#include <lsck/blah.h>
The include files have been heavily reorganised, but existing programs shouldn't have to be changed.
ls_
was changed to lsck_.
Added lsck_perror() and lsck_strerror() functions, which work as
perror() and strerror(), but print/return error messages for
socket errors too, unlike the libc versions.
resolv_conf_getdomainname() in src/config/domname.c now looks
for the various filename combinations possible (created long, read short,
etc.); file extension handling of __FSEXT_ready in src/fsext.c;
more checks are done on socket function parameters; fixed bugs in the RAS code
and the DNS IP list code (lsck_getdnsaddrs()).
demo/internal.c was renamed to
demo/diag.c and modified to give lots of diagnostic information about
libsocket's auto-configuration, in addition to demonstrating the internal
functions. The demo demo/netnet.c was added to demonstrate lookups from
the networks file. httpget can now cope with URLs without a trailing slash,
e.g. http://myhost.
src/resolve/rcmd.c, src/resolve/rexec.c and
src/resolve/rusrpass.c were removed because they are untested and
probably won't work as they rely on functions DJGPP doesn't support
(properly). They implement(ed) remote execution of commands. I will put
these back if there is demand for them. The man pages for the
WS_* functions were removed as the functions no longer exist.
make lfn
to build long filename programs.
read() and write(). Previously they didn't return the
correct values for non-blocking sockets when no data was present. winsock.h
is now installed to support non-blocking sockets properly - please see
question 3.6 of the FAQ for more details.
F_GETFL parameter on fcntl().
recv() sometimes. Also fixed
send(), recv(), sendto(), recvfrom(),
getpeername(), getsockname(), getsockopt() and
setsockopt() to avoid data loss / rubbish being returned.
make lfn and make sfn).
Added debug and nodebug targets to binary distribution.
read(), write(),
fcntl(), ioctl() and select(). Fixed mistakes in
a couple of the libsocket man pages.
gethostname() will no longer return spaces in host names.
callvxd.c that lead to nearly *all* socket functions
failing :(
contrib/ tree and added manifest files.
SET LFN=N at the DOS prompt.
getdomainname() to look at the environment variable
LOCALDOMAIN, resolv.conf or the registry, so it's more likely to
succeed.
WS_init() to return errors.
LIBSOCKET, so that
configuration files could be placed somewhere other than in the Windows
directory.
resit jimbo now works).
FIONREAD, FIONBIO.
socket() and accept() calls.
select() demo, demo/select.c.
close(), now fopen() after creating and closing sockets
works.
fcntl() call and defined some new flags that I would like to see
in future DJGPP versions: O_NDELAY and O_FNDELAY.
recv(). I discovered that programs crash
after connect on many Windows '95 installations.
recv()/recvfrom() (blocking and return value and
EOF condition).
connect() now waits for Windows; this means send() just after
connect() works now.
Portions of libsocket are distributed under different terms; the table below lists the base directories for these sources:
src/sxbxinet
src
src/win9x/regdos
src/oldlibc
The remainder of libsocket is distributed under the GNU Library General Public License (GNU LGPL):
GNU LIBRARY GENERAL PUBLIC LICENSE
**********************************
Version 2, June 1991
Copyright (C) 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the library GPL. It is
numbered 2 because it goes with version 2 of the ordinary GPL.]
Preamble
========
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Library General Public License, applies to some
specially designated Free Software Foundation software, and to any
other libraries whose authors decide to use it. You can use it for
your libraries, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it in
new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the library, or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link a program with the library, you must provide
complete object files to the recipients so that they can relink them
with the library, after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
Our method of protecting your rights has two steps: (1) copyright
the library, and (2) offer you this license which gives you legal
permission to copy, distribute and/or modify the library.
Also, for each distributor's protection, we want to make certain
that everyone understands that there is no warranty for this free
library. If the library is modified by someone else and passed on, we
want its recipients to know that what they have is not the original
version, so that any problems introduced by others will not reflect on
the original authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that companies distributing free
software will individually obtain patent licenses, thus in effect
transforming the program into proprietary software. To prevent this,
we have made it clear that any patent must be licensed for everyone's
free use or not licensed at all.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License, which was designed for utility
programs. This license, the GNU Library General Public License,
applies to certain designated libraries. This license is quite
different from the ordinary one; be sure to read it in full, and don't
assume that anything in it is the same as in the ordinary license.
The reason we have a separate public license for some libraries is
that they blur the distinction we usually make between modifying or
adding to a program and simply using it. Linking a program with a
library, without changing the library, is in some sense simply using
the library, and is analogous to running a utility program or
application program. However, in a textual and legal sense, the linked
executable is a combined work, a derivative of the original library,
and the ordinary General Public License treats it as such.
Because of this blurred distinction, using the ordinary General
Public License for libraries did not effectively promote software
sharing, because most developers did not use the libraries. We
concluded that weaker conditions might promote sharing better.
However, unrestricted linking of non-free programs would deprive the
users of those programs of all benefit from the free status of the
libraries themselves. This Library General Public License is intended
to permit developers of non-free programs to use free libraries, while
preserving your freedom as a user of such programs to change the free
libraries that are incorporated in them. (We have not seen how to
achieve this as regards changes in header files, but we have achieved
it as regards changes in the actual functions of the Library.) The
hope is that this will lead to faster development of free libraries.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, while the latter only
works together with the library.
Note that it is possible for a library to be covered by the ordinary
General Public License rather than by this special one.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library which
contains a notice placed by the copyright holder or other
authorized party saying it may be distributed under the terms of
this Library General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or
translated straightforwardly into another language. (Hereinafter,
translation is included without limitation in the term
"modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code
means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the library.
Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The act
of running a program using the Library is not restricted, and
output from such a program is covered only if its contents
constitute a work based on the Library (independent of the use of
the Library in a tool for writing it). Whether that is true
depends on what the Library does and what the program that uses
the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided
that you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep
intact all the notices that refer to this License and to the
absence of any warranty; and distribute a copy of this License
along with the Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange
for a fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a. The modified work must itself be a software library.
b. You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c. You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d. If a facility in the modified Library refers to a function or
a table of data to be supplied by an application program that
uses the facility, other than as an argument passed when the
facility is invoked, then you must make a good faith effort
to ensure that, in the event an application does not supply
such function or table, the facility still operates, and
performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots
has a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function
must be optional: if the application does not supply it, the
square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Library, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works. But when you distribute the same sections as part of a
whole which is a work based on the Library, the distribution of
the whole must be on the terms of this License, whose permissions
for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the
Library with the Library (or with a work based on the Library) on
a volume of a storage or distribution medium does not bring the
other work under the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.
To do this, you must alter all the notices that refer to this
License, so that they refer to the ordinary GNU General Public
License, version 2, instead of to this License. (If a newer
version than version 2 of the ordinary GNU General Public License
has appeared, then you can specify that version instead if you
wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to
all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable
form under the terms of Sections 1 and 2 above provided that you
accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software
interchange.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy
the source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being
compiled or linked with it, is called a "work that uses the
Library". Such a work, in isolation, is not a derivative work of
the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because
it contains portions of the Library), rather than a "work that
uses the library". The executable is therefore covered by this
License. Section 6 states terms for distribution of such
executables.
When a "work that uses the Library" uses material from a header
file that is part of the Library, the object code for the work may
be a derivative work of the Library even though the source code is
not. Whether this is true is especially significant if the work
can be linked without the Library, or if the work is itself a
library. The threshold for this to be true is not precisely
defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a
derivative work. (Executables containing this object code plus
portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section
6. Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered
by this License. You must supply a copy of this License. If the
work during execution displays copyright notices, you must include
the copyright notice for the Library among them, as well as a
reference directing the user to the copy of this License. Also,
you must do one of these things:
a. Accompany the work with the complete corresponding
machine-readable source code for the Library including
whatever changes were used in the work (which must be
distributed under Sections 1 and 2 above); and, if the work
is an executable linked with the Library, with the complete
machine-readable "work that uses the Library", as object code
and/or source code, so that the user can modify the Library
and then relink to produce a modified executable containing
the modified Library. (It is understood that the user who
changes the contents of definitions files in the Library will
not necessarily be able to recompile the application to use
the modified definitions.)
b. Accompany the work with a written offer, valid for at least
three years, to give the same user the materials specified in
Subsection 6a, above, for a charge no more than the cost of
performing this distribution.
c. If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the
above specified materials from the same place.
d. Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special
exception, the source code distributed need not include anything
that is normally distributed (in either source or binary form)
with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that
component itself accompanies the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you
cannot use both them and the Library together in an executable
that you distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other
library facilities not covered by this License, and distribute
such a combined library, provided that the separate distribution
of the work based on the Library and of the other library
facilities is otherwise permitted, and provided that you do these
two things:
a. Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b. Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same
work.
8. You may not copy, modify, sublicense, link with, or distribute the
Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate
your rights under this License. However, parties who have
received copies, or rights, from you under this License will not
have their licenses terminated so long as such parties remain in
full compliance.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify
or distribute the Library or its derivative works. These actions
are prohibited by law if you do not accept this License.
Therefore, by modifying or distributing the Library (or any work
based on the Library), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying,
distributing or modifying the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the
Library subject to these terms and conditions. You may not impose
any further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing compliance
by third parties to this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent
obligations, then as a consequence you may not distribute the
Library at all. For example, if a patent license would not permit
royalty-free redistribution of the Library by all those who
receive copies directly or indirectly through you, then the only
way you could satisfy both it and this License would be to refrain
entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable
under any particular circumstance, the balance of the section is
intended to apply, and the section as a whole is intended to apply
in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of
any such claims; this section has the sole purpose of protecting
the integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is
willing to distribute software through any other system and a
licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed
to be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces,
the original copyright holder who places the Library under this
License may add an explicit geographical distribution limitation
excluding those countries, so that distribution is permitted only
in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of
this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Library General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library specifies a version number of this License which applies
to it and "any later version", you have the option of following
the terms and conditions either of that version or of any later
version published by the Free Software Foundation. If the Library
does not specify a license version number, you may choose any
version ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free
status of all derivatives of our free software and of promoting
the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE
LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY
OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
GNU Free Documentation License
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Document", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you".
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file
format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is
not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification. Opaque formats include
PostScript, PDF, proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML produced by some word processors for output
purposes only.
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present
the full title with all words of the title equally prominent and
visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications",
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements"
or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgements",
and any sections entitled "Dedications". You must delete all sections
entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the
original English version of this License. In case of a disagreement
between the translation and the original English version of this
License, the original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http:///www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
__lsck_get_copyright: __lsck_get_copyright
__lsck_get_version: __lsck_get_version
accept: accept
bind: bind
connect: connect
dn_comp: dn_comp
dn_expand: dn_expand
endhostent: endhostent
endnetent: endnetent
endprotoent: endprotoent
endservent: endservent
getdomainname: getdomainname
gethostbyaddr: gethostbyaddr
gethostbyname: gethostbyname
gethostent: gethostent
gethostname: gethostname
getnetbyaddr: getnetbyaddr
getnetbyname: getnetbyname
getnetent: getnetent
getpeername: getpeername
getprotobyname: getprotobyname
getprotobynumber: getprotobynumber
getprotoent: getprotoent
getservbyname: getservbyname
getservbyport: getservbyport
getservent: getservent
getsockname: getsockname
getsockopt: getsockopt
herror: herror
if_freenameindex: if_freenameindex
if_indextoname: if_indextoname
if_nameindex: if_nameindex
if_nametoindex: if_nametoindex
inet_addr: inet_addr
inet_aton: inet_aton
inet_lnaof: inet_lnaof
inet_makeaddr: inet_makeaddr
inet_netof: inet_netof
inet_network: inet_network
inet_ntoa: inet_ntoa
inet_ntop: inet_ntop
inet_pton: inet_pton
isfdtype: isfdtype
listen: listen
rcmd: rcmd
readv: readv
recv: recv
recvfrom: recvfrom
res_init: res_init
res_mkquery: res_mkquery
res_query: res_query
res_querydomain: res_querydomain
res_search: res_search
res_send: res_send
rexec: rexec
rresvport: rresvport
ruserok: ruserok
send: send
sendto: sendto
setdomainname: setdomainname
sethostent: sethostent
sethostname: sethostname
setnetent: setnetent
setprotoent: setprotoent
setservent: setservent
setsockopt: setsockopt
shutdown: shutdown
sockatmark: sockatmark
socket: socket
socketpair: socketpair
writev: writev
account: netrc
alert: host.conf
alias: protocols
alias-n: services
debug: resolv.conf
default: netrc
domain: resolv.conf
h_addr: gethostbyname
h_addr_list: gethostbyname
h_addrtype: gethostbyname
h_aliases: gethostbyname
h_length: gethostbyname
h_name: gethostbyname
login: netrc
LSCK_VERSION_MAJOR: __lsck_get_version
LSCK_VERSION_MINOR: __lsck_get_version
LSCK_VERSION_SUBMINOR: __lsck_get_version
macdef: netrc
machine: netrc
multi: host.conf
nameserver: resolv.conf
ndots: resolv.conf
nospoof: host.conf
options: resolv.conf
order: host.conf
port: services
protocol: services
protocol-name: protocols
protocol-number: protocols
reorder: host.conf
RES_AAONLY: res_query
RES_DEBUG: res_query
RES_DEFNAMES: res_query
RES_DNSRCH: res_query
RES_IGNTC: res_query
RES_INIT: res_query
RES_PRIMARY: res_query
RES_RECURSE: res_query
RES_STAYOPEN: res_query
RES_USEVC: res_query
search: resolv.conf
service-name: services
sortlist: resolv.conf
trim: host.conf