[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP TCP/IP Services for OpenVMS
Sockets API and System Services Programming


Previous Contents Index

3.2.9 netent Structure

The netent structure, defined in the NETDB.H header file, holds a network name, a list of aliases associated with the network, and the network's number specified as an internet address from the network database.

The netent structure definition is as follows:



struct  netent {
        char    *n_name;       /* official name of net */
        char    **n_aliases;   /* alias list           */
        int     n_addrtype;    /* net address type     */
        long    n_net;         /* net number           */
};

The netent structure members are as follows:

  • n_name is the official network name.
  • n_aliases is a null-terminated list of pointers to alternate names for the network.
  • n_addrtype is the type of the network number returned (AF_INET or AF_INET6).
  • n_net is the network number returned in host byte order.

3.2.10 protoent Structure

The protoent structure, defined in the NETDB.H header file, holds the description of the protocol from the protocols table.

A protocol is described by the protoent structure, as follows:


struct  protoent {
        char   *p_name;       /* official name of protocol */
        char   **p_aliases;   /* alias list                */
        long   p_proto;       /* protocol number           */
};

The members of this structure are:

p_name The official name of the protocol.
p_aliases A zero-terminated list of alternate names for the protocol.
p_proto The protocol number.

3.2.11 servent Structure

The servent structure, defined in the NETDB.H header file, specifies or obtains a service name, a list of aliases associated with the service, and the service's number specified as an Internet address from the services database. An entry in the services database is created with the following TCP/IP management command:


SET SERVICE service

For more information, refer to the HP TCP/IP Services for OpenVMS Management Command Reference guide.

A service mapping is described by the servent structure, as follows:


struct servent {
   char *s_name;     /* official service name           */
   char **s_aliases; /* alias list                      */
   int  s_port;      /* port number, network byte order */
   char *s_proto;    /* protocol to use                 */
};

The servent structure members are as follows:

  • s_name is the official name of the service.
  • s_aliases is a null-terminated list of pointers to alternate names for the service.
  • s_port is the port number at which the service resides in network byte order.
  • s_proto is the name of the protocol to use with the service.

The getservbyname() function maps service names to a servent structure by specifying a service name and, optionally, a qualifying protocol.

3.2.12 sockaddr Structure

The sockaddr structure, defined in the SOCKET.H header file, holds a general address family.

The SOCKET.H header file defines the following structures for BSD Versions 4.3 and 4.4:

  • osockaddr structure (BSD Version 4.3)
  • sockaddr structure (BSD Version 4.4)

3.2.12.1 BSD Version 4.3

The osockaddr structure definition for use with BSD Version 4.3 is as follows:



   struct osockaddr {
          u_short sa_family;     /* address family                   */
          char    sa_data[14];   /* up to 14 bytes of direct address */
};

The osockaddr structure members are as follows:

  • sa_family is the address family or domain in which the socket was created.
  • sa_data is the data string of up to 14 bytes of direct address.

3.2.12.2 BSD Version 4.4

The sockaddr structure definition for use with BSD Version 4.4 is as follows:


   struct sockaddr {
           u_char  sa_len;        /* total length                     */
           u_char  sa_family;     /* address family                   */
           char    sa_data[14];   /* up to 14 bytes of direct address */
};

The sockaddr structure members are as follows:

  • sa_len is the length of the structure.
  • sa_family is the address family or domain in which the socket was created.
  • sa_data is the data string of up to 14 bytes of direct address.

3.2.13 sockaddr_in Structure

The sockaddr_in structure, defined in the IN.H header file, specifies an internet address family.

The sockaddr_in structure definition is as follows:



struct sockaddr_in {
        short   sin_family;            /* address family             */
        u_short sin_port;              /* port number                */
        struct  in_addr sin_addr;      /* internet address           */
        char    sin_zero[8];           /* 8-byte field of all zeroes */
};

The sockaddr_in structure members are as follows:

  • sin_family is the address family (AF_INET or AF_INET6).
  • sin_port is the port number in network order.
  • sin_addr is the internet address in network order.
  • sin_zero is an 8-byte field containing all zeros.

3.2.14 sockaddr_in6 Structure (IPv6)

The sockaddr_in6 structure, defined in the IN6.H header file, defines an IPv6 socket address.

The IN6.H file defines the following structures depending on the setting of the _SOCKADDR_LEN compilation symbol:

3.2.14.1 BSD Version 4.3

If an application does not define the _SOCKADDR_LEN compilation symbol, the compiler generates the following BSD Version 4.3 structure:



struct sockaddr_in6 {
    sa_family_t     sin6_family;        /* AF_INET6                      */
    in_port_t       sin6_port;          /* Transport layer port #        */
    uint32_t        sin6_flowinfo;      /* IPv6 flow information         */
    struct in6_addr sin6_addr;          /* IPv6 address                  */
    uint32_t        sin6_scope_id;      /* set of interfaces for a scope */
};

The sockaddr_in6 structure members are as follows:

  • sin6_family is the address family (AF_INET6).
  • sin6_port is the transport layer port number stored in network byte order.
  • sin6_flowinfo is the priority and flow label stored in network byte order.
  • sin6_addr is the internet address stored in network byte order.
  • sin6_scope_id is a 32-bit integer identifying a set of interfaces appropriate for the scope of the address specified by the sin6_addr field. For a link scope, sin6_scope_id specifies an interface index. For a site scope, sin6_scope_id specifies a site identifier.

3.2.14.2 BSD Version 4.4

If an application defines the _SOCKADDR_LEN compilation symbol, the compiler generates the following BSD Version 4.4 structure.



struct sockaddr_in6 {
# define SIN6_LEN
    uint8_t         sin6_len;           /* length of this struct         */
    sa_family_t     sin6_family;        /* AF_INET6                      */
    in_port_t       sin6_port;          /* Transport layer port #        */
    uint32_t        sin6_flowinfo;      /* IPv6 flow information         */
    struct in6_addr sin6_addr;          /* IPv6 address                  */
    uint32_t        sin6_scope_id;      /* set of interfaces for a scope */
};

The sockaddr_in6 structure members are as follows:

  • sin6_len is the length of this structure (28 bytes).
  • sin6_family is the address family (AF_INET6).
  • sin6_port is the transport layer port number stored in network byte order.
  • sin6_flowinfo is the priority and flow label stored in network byte order.
  • sin6_addr is the internet address stored in network byte order.
  • sin6_scope_id is a 32-bit integer identifying a set of interfaces appropriate for the scope of the address specified by the sin6_addr field. For a link scope, sin6_scope_id specifies an interface index. For a site scope, sin6_scope_id specifies a site identifier.

3.2.15 timeval Structure

The timeval structure, defined in the SOCKET.H header file, specifies time intervals. The timeval structure definition is as follows:



struct timeval {
    long tv_sec;
    long tv_usec;
};

The timeval structure members are as follows:

  • tv_sec specifies the number of seconds to wait.
  • tv_usec specifies the number of microseconds to wait.

3.3 Header Files

You can include header files on a OpenVMS system using any one of the following preprocessor directive statements:


#include types
#include <types.h>
#include <sys/types.h>

The #include types form of the #include preprocessor directive is possible on OpenVMS systems because all header files are located in a text library in the SYS$LIBRARY directory. On UNIX systems, you must specify header files (and subdirectories that locate a header file) within angle brackets (< >) or quotation marks (" ") .

For example, to include the header file TYPES.H on a UNIX system, use the following form of the #include directive:


#include <sys/types.h>

3.4 Constants and Address Variables (IPv6)

Table 3-3 lists the constants and address variables available for use with the IPv6 structures.

Table 3-3 Constants and Address Variables (IPv6)
Entry Description
in6addr_any The wildcard address in network byte order for the structure in6_addr .
IN6ADDR_ANY_INIT A symbolic constant used to initialize an in6_addr structure when it is declared.
in6addr_loopback A loopback address defined in network byte order.
IN6ADDR_LOOPBACK_INIT A symbolic constant used to initialize an in6_addr structure when it is declared.

3.5 Interface Identification (IPv6)

When TCP/IP Services initializes an interface, it assigns an integer known as an interface index to identify the interface. This interface identification is used to determine the interface on which a datagram is sent or received, or on which a multicast group is joined.

Table 3-4 lists the functions related to handling the interface identification.

Table 3-4 Interface Identification Functions
Function Description
if_nametoindex() Maps an interface name to its corresponding index.
if_indextoname() Maps an interface index to its corresponding name.
if_nameindex() Returns an array of all interface names and indexes.
if_freenameindex() Frees dynamic memory allocated by if_nameindex() to the array of interface names and indexes.

3.5.1 Sending IPv6 Multicast Datagrams

To send IPv6 multicast datagrams, an application indicates the multicast group to send to by specifying an IPv6 multicast address in a sendto() function. The system maps the specified IPv6 destination address to the appropriate Ethernet or FDDI multicast address prior to transmitting the datagram.

An application can explicitly control multicast options with arguments to the setsockopt() function. The following options can be set by an application using the setsockopt() function:

  • Hop limit (IPV6_MULTICAST_HOPS)
    The IPV6_MULTICAST_HOPS option to the setsockopt() function allows an application to specify a value between 0 and 255 for the hop limit field.
    Multicast datagrams with a hop limit value of 0 restrict distribution of the multicast datagram to applications running on the local host. Multicast datagrams with a hop limit value of 1 are forwarded only to hosts on the local link. If a multicast datagram has a hop limit value greater than 1 and a multicast router is attached to the sending host's network, multicast datagrams can be forwarded beyond the local link. Multicast routers forward the datagram to known networks that have hosts belonging to the specified multicast group. The hop limit value is decremented by each multicast router in the path. When the hop limit value is decremented to 0, the datagram is not forwarded further.
    The following example shows how to use the IPV6_MULTICAST_HOPS option to the setsockopt() function:


    
    u_char hops;
    hops=2;
    
    if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &hops,
                   sizeof(hops)) < 0)
                   perror("setsockopt: IPV6_MULTICAST_HOPS error");
    
    
  • Multicast interface (IPV6_MULTICAST_IF)
    A datagram addressed to an IPv6 multicast address is transmitted from the default network interface unless the application specifies that an alternate network interface is associated with the socket. The default interface is determined by the interface associated with the default route in the kernel routing table or by the interface associated with an explicit route, if one exists. Using the IPV6_MULTICAST_IF option to the setsockopt() function, an application can specify a network interface other than that specified by the route in the kernel routing table.
    The following example shows how to use the IPV6_MULTICAST_IF option to the setsockopt() function to specify an interface other than the default:


    
    u_int if_index = 1;
    .
    .
    .
    if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_IF, &if_index,
                   sizeof(if_index)) < 0)
                   perror ("setsockopt: IPV6_MULTICAST_IF error");
                   else
                   printf ("new interface set for sending multicast datagrams\n");
    
    

    The if_index parameter specifies the interface index of the desired interface, or specifies 0 to select a default interface. You can use the if_nametoindex() function to find the interface index.
  • Disabling loopback of local delivery (IPV6_MULTICAST_LOOP)
    If a multicast datagram is sent to a group that has the sending node as a member, a copy of the datagram is, by default, looped back by the IP layer for local delivery. The IPV6_MULTICAST_LOOP option to the setsockopt() function allows an application to disable this loopback delivery.
    The following example shows how to use the IPV6_MULTICAST_LOOP option to the setsockopt() function:


    
    u_char loop=0;
    if (setsockopt( sock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &loop,
                    sizeof(loop)) < 0)
                    perror("setsockopt: IPV6_MULTICAST_LOOP error");
    
    

    If the value of loop is 0, loopback is disabled; if the value of loop is 1, loopback is enabled. For performance reasons, you should disable the default by setting loop to 0, unless applications on the same host must receive copies of the datagrams.

3.5.2 Receiving IPv6 Multicast Datagrams

Before a node can receive IPv6 multicast datagrams destined for a particular multicast group other than the All Nodes group, an application must direct the node to become a member of that multicast group.

This section describes how an application can direct a node to add itself to and remove itself from a multicast group.

An application can direct the node it is running on to join a multicast group by using the IPV6_JOIN_GROUP option to the setsockopt() function:



struct ipv6_mreq imr6;
.
.
.
imr6.ipv6mr_interface = if_index;
if (setsockopt( sock, IPPROTO_IPV6, IPV6_JOIN_GROUP,
                (char *)&imr6, sizeof(imr6)) < 0)
                perror("setsockopt: IPV6_JOIN_GROUP error");

The imr6 parameter has the following structure:



structipv6_mreq {
        struct in6_addr ipv6mr_multiaddr; /* IP multicast address of group */
        unsigned int ipv6mr_interface;    /* local interface index         */
        };

Each multicast group membership is associated with a particular interface. It is possible to join the same group on multiple interfaces. The ipv6mr_interface variable can be specified with a value of 0, which allows an application to choose the default multicast interface. Alternatively, specifying one of the host's local interfaces allows an application to select a particular multicast-capable interface. The maximum number of memberships that can be added on a single socket is subject to the IPV6_MAX_MEMBERSHIPS value, which is defined in the IN6.H header file.

To drop membership from a particular multicast group, use the IPV6_LEAVE_GROUP option to the setsockopt function:



struct ipv6_mreq imr6;
if (setsockopt( sock, IPPROTO_IPV6, IPV6_LEAVE_GROUP, &imr6,
                sizeof(imr6)) < 0)
                perror("setsockopt: IPV6_LEAVE_GROUP error");

The imr6 parameter contains the same structure values used for adding membership.

If multiple sockets request that a node join a particular multicast group, the node remains a member of that multicast group until the last of those sockets is closed.

To receive multicast datagrams sent to a specific UDP port, the receiving socket must be bound to that port using the bind() function. More than one process can receive UDP datagrams destined for the same port if the bind() function is preceded by a setsockopt() function that specifies the SO_REUSEPORT option.

Delivery of IP multicast datagrams to SOCK_RAW sockets is determined by the protocol type of the destination.


Previous Next Contents Index