219 lines
13 KiB
HTML
219 lines
13 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="reference" />
|
||
|
|
<meta name="DC.Title" content="Berkeley Software Distribution compatibility" />
|
||
|
|
<meta name="abstract" content="Sockets is a Berkeley Software Distribution (BSD) interface." />
|
||
|
|
<meta name="description" content="Sockets is a Berkeley Software Distribution (BSD) interface." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="aconcepts.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="howdosockets.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/accept.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/sendms.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/connec.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/recvfr.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/recvms.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/bind.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/gsockn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/socket.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/listen.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/ioctl.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/gpeern.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/close.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2001, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2001, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="cbsd" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title> Berkeley Software Distribution compatibility</title>
|
||
|
|
</head>
|
||
|
|
<body id="cbsd"><a name="cbsd"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1"> Berkeley Software Distribution compatibility</h1>
|
||
|
|
<div><p>Sockets is a Berkeley Software Distribution (BSD) interface.</p>
|
||
|
|
<div class="section"><p>The semantics, such as the return codes that an application receives
|
||
|
|
and the arguments available on supported functions, are BSD semantics. Some
|
||
|
|
BSD semantics, however, are not available in the i5/OS™ implementation, and changes may need
|
||
|
|
to be made to a typical BSD socket application in order for it to run on the
|
||
|
|
system.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The following list summarizes the differences between the i5/OS implementation
|
||
|
|
and the BSD implementation.</p>
|
||
|
|
|
||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" id="d0e36">QUSRSYS file</th>
|
||
|
|
<th valign="top" id="d0e38">Contents</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" headers="d0e36 ">QATOCHOST</td>
|
||
|
|
<td valign="top" headers="d0e38 ">List of host names and the corresponding IP addresses.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e36 ">QATOCPN</td>
|
||
|
|
<td valign="top" headers="d0e38 ">List of networks and the corresponding IP addresses.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e36 ">QATOCPP</td>
|
||
|
|
<td valign="top" headers="d0e38 ">List of protocols that are used in the Internet.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e36 ">QATOCPS</td>
|
||
|
|
<td valign="top" headers="d0e38 ">List of services and the specific port and protocol
|
||
|
|
that the service uses.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
<dl><dt class="dlterm">/etc/hosts, /etc/services, /etc/networks, and /etc/protocols</dt>
|
||
|
|
<dd>For these files, the i5/OS implementation supplies the following
|
||
|
|
database files. </dd>
|
||
|
|
<dt class="dlterm">/etc/resolv.conf </dt>
|
||
|
|
<dd>The i5/OS implementation
|
||
|
|
requires that this information be configured using the TCP/IP properties page
|
||
|
|
in iSeries™ Navigator.
|
||
|
|
To access the TCP/IP properties page, complete the following steps: <ol><li>In iSeries Navigator,
|
||
|
|
expand your <span class="menucascade"><span class="uicontrol">iSeries server</span> > <span class="uicontrol">Network</span> > <span class="uicontrol">TCP/IP Configuration</span></span>. </li>
|
||
|
|
<li>Right-click <span class="uicontrol">TCP/IP Configuration</span>.</li>
|
||
|
|
<li>Click <span class="uicontrol">Properties</span>. </li>
|
||
|
|
</ol>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">bind()</span></dt>
|
||
|
|
<dd><p>On a BSD system, a client can create an AF_UNIX socket using <span class="apiname">socket()</span>,
|
||
|
|
connect to a server using <span class="apiname">connect()</span>, and then bind a name
|
||
|
|
to its socket using <span class="apiname">bind()</span>. The i5/OS implementation does not support this
|
||
|
|
scenario (the <span class="apiname">bind()</span> fails).</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">close()</span></dt>
|
||
|
|
<dd> <p>The i5/OS implementation supports the linger timer for
|
||
|
|
the <span class="apiname">close()</span> function, except for AF_INET sockets over Systems
|
||
|
|
Network Architecture (SNA). Some BSD implementations do not support the linger
|
||
|
|
timer for <span class="apiname">close()</span>.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">connect()</span></dt>
|
||
|
|
<dd><p>On a BSD system, if a <span class="apiname">connect()</span> is issued against
|
||
|
|
a socket that was previously connected to an address and is using a connectionless
|
||
|
|
transport service, and an invalid address or an invalid address length is
|
||
|
|
used, the socket is no longer connected. The i5/OS implementation does not support this
|
||
|
|
scenario (the <span class="apiname">connect()</span> fails and the socket is still connected). </p>
|
||
|
|
<p>A
|
||
|
|
connectionless transport socket for which a <span class="apiname">connect()</span> has
|
||
|
|
been issued can be disconnected by setting the address_length parameter to
|
||
|
|
zero and issuing another <span class="apiname">connect()</span>.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">accept()</span>, <span class="apiname">getsockname()</span>, <span class="apiname">getpeername()</span>, <span class="apiname">recvfrom()</span>,
|
||
|
|
and <span class="apiname">recvmsg() </span></dt>
|
||
|
|
<dd><p>When using AF_UNIX or AF_UNIX_CCSID address family and the socket has
|
||
|
|
not been bound, the default i5/OS implementation may return an address length of
|
||
|
|
zero and an unspecified address structure. The i5/OS BSD 4.4/ UNIX<sup>®</sup> 98 and other implementations may return
|
||
|
|
a small address structure with just the address family specified.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">ioctl()</span></dt>
|
||
|
|
<dd><div class="p"><ul><li>On a BSD system, on a socket of type SOCK_DGRAM, the FIONREAD request
|
||
|
|
returns the length of the data plus the length of the address. On the i5/OS implementation,
|
||
|
|
FIONREAD only returns the length of data.</li>
|
||
|
|
<li>Not all requests available on most BSD implementations of <span class="apiname">ioctl()</span> are
|
||
|
|
available on the i5/OS implementation
|
||
|
|
of <span class="apiname">ioctl()</span>.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">listen()</span></dt>
|
||
|
|
<dd><p>On a BSD system, issuing a <span class="apiname">listen()</span> with the backlog
|
||
|
|
parameter set to a value that is less than zero does not result in an error.
|
||
|
|
In addition, the BSD implementation, in some cases, does not use the backlog
|
||
|
|
parameter, or uses an algorithm to come up with a final result for the backlog
|
||
|
|
value. The i5/OS implementation
|
||
|
|
returns an error if the backlog value is less than zero. If you set the backlog
|
||
|
|
to a valid value, then the value is used as the backlog. However, setting
|
||
|
|
the backlog to a value larger than {SOMAXCONN}, the backlog defaults to the
|
||
|
|
value set in {SOMAXCONN}.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Out-of-band (OOB) data </dt>
|
||
|
|
<dd><p>In the i5/OS implementation,
|
||
|
|
OOB data is not discarded if SO_OOBINLINE is not set, OOB data has been received,
|
||
|
|
and the user then sets SO_OOBINLINE on. The initial OOB byte is considered
|
||
|
|
normal data.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">protocol parameter of <span class="apiname">socket()</span></dt>
|
||
|
|
<dd><p>As a means of providing additional security, no user is allowed to
|
||
|
|
create a SOCK_RAW socket specifying a protocol of IPPROTO_TCP or IPPROTO_UDP.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">res_xlate()</span> and <span class="apiname">res_close()</span></dt>
|
||
|
|
<dd><p>These functions are included in the resolver routines for the i5/OS implementation.<span class="apiname"> res_xlate()</span> translates
|
||
|
|
Domain Name System (DNS) packets from EBCDIC to ASCII and from ASCII to EBCDIC. <span class="apiname">res_close()</span> is
|
||
|
|
used to close a socket that was used by <span class="apiname">res_send()</span> with
|
||
|
|
the RES_STAYOPEN option set. It also resets the _res structure.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><span class="apiname">sendmsg()</span> and <span class="apiname">recvmsg()</span></dt>
|
||
|
|
<dd> <p>The i5/OS implementation
|
||
|
|
of <span class="apiname">sendmsg()</span> and <span class="apiname">recvmsg()</span> allows {MSG_MAXIOVLEN}
|
||
|
|
I/O vectors. The BSD implementation allows {MSG_MAXIOVLEN - 1} I/O vectors.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Signals </dt>
|
||
|
|
<dd><div class="p">There are several differences relating to signal support: <ul><li>BSD implementations issue a SIGIO signal each time an acknowledgement
|
||
|
|
is received for data sent on an output operation. The i5/OS sockets implementation does not generate
|
||
|
|
signals related to outbound data.</li>
|
||
|
|
<li>The default action for the SIGPIPE signal is to end the
|
||
|
|
process in BSD implementations. To maintain downward compatibility with previous
|
||
|
|
releases of i5/OS,
|
||
|
|
the i5/OS implementation
|
||
|
|
uses a default action of ignoring for the SIGPIPE signal.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">SO_REUSEADDR option </dt>
|
||
|
|
<dd> <p>On BAsynchronous I/OSD systems, a <span class="apiname">connect()</span> on
|
||
|
|
a socket of family AF_INET and type SOCK_DGRAM causes the system to change
|
||
|
|
the address to which the socket is bound to the address of the interface that
|
||
|
|
is used to reach the address specified on the <span class="apiname">connect()</span>.
|
||
|
|
For example, if you bind a socket of type SOCK_DGRAM to address INADDR_ANY,
|
||
|
|
and then connect it to an address of a.b.c.d, the system changes your socket
|
||
|
|
so it is now bound to the IP address of the interface that was chosen to route
|
||
|
|
packets to address a.b.c.d. In addition, if this IP address that the socket
|
||
|
|
is bound to is a.b.c.e, for example, address a.b.c.e now appears on <span class="apiname">getsockname()</span> instead
|
||
|
|
of INADDR_ANY, and the SO_REUSEADDR option must be used to bind any other
|
||
|
|
sockets to the same port number with an address of a.b.c.e.</p>
|
||
|
|
<p>In contrast,
|
||
|
|
in this example, the i5/OS implementation does not change the local address
|
||
|
|
from INADDR_ANY to a.b.c.e. <span class="apiname"> getsockname()</span> continues to
|
||
|
|
return INADDR_ANY after the connection is performed.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">SO_SNDBUF and SO_RCVBUF options </dt>
|
||
|
|
<dd><p>The values set for SO_SNDBUF and SO_RCVBUF on a BSD system provide
|
||
|
|
a greater level of control than on an i5/OS implementation. On an i5/OS implementation,
|
||
|
|
these values are taken as advisory values.</p>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="aconcepts.htm" title="Advanced socket concepts go beyond a general discussion of what sockets are and how they work. They provide ways to design socket applications for larger and more complex networks.">Advanced socket concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="howdosockets.htm" title="Sockets are commonly used for client/server interaction. Typical system configuration places the server on one machine, with the clients on other machines. The clients connect to the server, exchange information, and then disconnect.">How sockets work</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../apis/accept.htm">accept()</a></div>
|
||
|
|
<div><a href="../apis/sendms.htm">sendmsg()</a></div>
|
||
|
|
<div><a href="../apis/connec.htm">connect()</a></div>
|
||
|
|
<div><a href="../apis/recvfr.htm">recvfrom()</a></div>
|
||
|
|
<div><a href="../apis/recvms.htm">recvmsg()</a></div>
|
||
|
|
<div><a href="../apis/bind.htm">bind()</a></div>
|
||
|
|
<div><a href="../apis/gsockn.htm">getsockname()</a></div>
|
||
|
|
<div><a href="../apis/socket.htm">socket()</a></div>
|
||
|
|
<div><a href="../apis/listen.htm">listen()</a></div>
|
||
|
|
<div><a href="../apis/ioctl.htm">ioctl()</a></div>
|
||
|
|
<div><a href="../apis/gpeern.htm">getpeername()</a></div>
|
||
|
|
<div><a href="../apis/close.htm">close()</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|