Berkeley Software Distribution compatibility

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.

The following list summarizes the differences between the i5/OS implementation and the BSD implementation.

/etc/hosts, /etc/services, /etc/networks, and /etc/protocols

For these files, the i5/OS implementation supplies the following database files.

/etc/resolv.conf

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:

1. In iSeries Navigator, expand your iSeries server > Network > TCP/IP Configuration.
2. Right-click TCP/IP Configuration.
3. Click Properties.

bind()

On a BSD system, a client can create an AF_UNIX socket using socket(), connect to a server using connect(), and then bind a name to its socket using bind(). The i5/OS implementation does not support this scenario (the bind() fails).

close()

The i5/OS implementation supports the linger timer for the close() function, except for AF_INET sockets over Systems Network Architecture (SNA). Some BSD implementations do not support the linger timer for close().

connect()

On a BSD system, if a connect() 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 connect() fails and the socket is still connected).

A connectionless transport socket for which a connect() has been issued can be disconnected by setting the address_length parameter to zero and issuing another connect().

accept(), getsockname(), getpeername(), recvfrom(), and recvmsg()

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^® 98 and other implementations may return a small address structure with just the address family specified.

ioctl()

• 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.
• Not all requests available on most BSD implementations of ioctl() are available on the i5/OS implementation of ioctl().

listen()

On a BSD system, issuing a listen() 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}.

Out-of-band (OOB) data

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.

protocol parameter of socket()

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.

res_xlate() and res_close()

These functions are included in the resolver routines for the i5/OS implementation. res_xlate() translates Domain Name System (DNS) packets from EBCDIC to ASCII and from ASCII to EBCDIC. res_close() is used to close a socket that was used by res_send() with the RES_STAYOPEN option set. It also resets the _res structure.

sendmsg() and recvmsg()

The i5/OS implementation of sendmsg() and recvmsg() allows {MSG_MAXIOVLEN} I/O vectors. The BSD implementation allows {MSG_MAXIOVLEN - 1} I/O vectors.

Signals

There are several differences relating to signal support:

• 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.
• 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.

SO_REUSEADDR option

On BAsynchronous I/OSD systems, a connect() 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 connect(). 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 getsockname() 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.

In contrast, in this example, the i5/OS implementation does not change the local address from INADDR_ANY to a.b.c.e. getsockname() continues to return INADDR_ANY after the connection is performed.

SO_SNDBUF and SO_RCVBUF options

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.