Cluster I/O Protocols (CIP) Configuration and Management Manual (H06.16+, J06.05+)

this feature that cannot be solved using more CLIMs is a server that binds to INADDR_ANY to act
as a backup for other servers that each bind to a specific address.
Changing Destination of a Connected UDP Socket
Conventional TCP/IP and NonStop TCP/IPv6 select a local interface based on the destination
address for each connect operation done on an unbound UDP socket or one bound to
INADDR_ANY. In CIP, once a connect operation is done on an unbound UDP socket or one bound
to INADDR_ANY, the socket is implicitly bound to an address and interface on a CLIM that has a
route to the destination address. Subsequent connect operations are sent to the same CLIM, even
if it does not have a route to the new destination address. If the CLIM cannot reach the destination,
the application gets an EACCESS error. You can avoid a problem by ensuring that all CLIMs in a
Provider are configured with the same routes.
Multicast Bind and Set or Join on Separate Interfaces
In Conventional TCP/IP and NonStop TCP/IPv6, applications can bind (using the bind call) a
socket to a multicast address on one interface, join (using the setsockopt call with the IP_ADD
_MEMBERSHIP or IPV6_JOIN_GROUP option) a multicast group on another interface, and set the
multicast send interface (using the setsockopt with the IP_MULTICAST_IF or IPV6_MULTICAST_IF
option) to yet another interface with no restrictions. In CIP, the interfaces that are referred to for
these operations must be on the same CLIM. Furthermore, each interface on a CLIM can fail over
to a different CLIM, so CIP might need to rearrange the interfaces during failover. CIP requires
binding as well as joining to a multicast group before receiving messages from that group. If your
applications use different interfaces for bind, join, and set, you need to change them.
Multicast Loopback
In Conventional TCP/IP and NonStop TCP/IPv6, an application that joins a multicast group receives
data sent to that group even from the same interface or controller.
In CIP, for IPv4, if the interfaces are on the same CLIM, an application will not receive the data
unless the sender sets the IP_MULTICAST_LOOP socket option and joins the receiver's multicast
group. For IPv6, an application receives the data regardless of whether the sender sets the
IP_MULTICAST_LOOP option and has joined the receiver's multicast group.
Receiving Broadcasts on Specific Addresses
NonStop TCP/IPv6 and Conventional TCP/IP route incoming broadcast packets (IP Address
255.255.255.255) to sockets bound to a specific IP address. CIP does not support this behavior.
CIP has a Provider attribute that gives a list of the port numbers requiring emulation of the older
behavior:
BRECVPORT port [, port] …
This attribute specifies the UDP ports to receive broadcast messages on sockets bound to specific
IP addresses as well as INADDR_ANY. Up to eight port numbers can be specified, each a port
number not in the ephemeral or shared-port ranges. Ports not in the list can receive broadcast
messages only on sockets bound to INADDR_ANY.
This attribute adds a configuration step, but makes application changes unnecessary. See “ADD
PROVIDER” (page 228) and “ALTER PROVIDER” (page 232) for BRECVPORT syntax.
NOTE: BRECVPORT is not supported with CLIM-to-CLIM failover.
Error after UDP Send to Unreachable Port
If a UDP message is sent to an unreachable port, the resulting ICMP error always causes
Conventional TCP/IP and NonStop TCP/IPv6 to return an error on the next request. CIP sometimes
does not return an error at all or returns the error on a subsequent request.
Application Programming Differences Between NonStop TCP/IPv6 and CIP 189