Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
SCTP Programmer's Guide: HP-UX 11i v2, HP-UX 11i v3 > Chapter 2 SCTP Socket APIs

Common Socket Calls

» 

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

This section discusses socket calls that are common to both one-to-one and one-to-many style APIs.

The send(), sendto(), recv(), and recvfrom() Socket Calls

Applications can use the send()() and sendto()() socket calls to transmit data to the peer. The recv()() and recvfrom()() socket calls can be used to receive data from the peer.

Following are the syntaxes for the send()(), sendto()(), recv()(), and recvfrom()() socket calls, respectively:

ssize_t send(int sd, const void *msg, size_t len, int flags);
ssize_t sendto(int sd, const void *msg, size_t len, int flags,
        const struct sockaddr *to, socklen_t tolen);
ssize_t recv(int sd, void *buf, size_t len, int flags);
ssize_t recvfrom(int sd, void *buf, size_t len, int flags,
        struct sockaddr *from, socklen_t *fromlen);

where:

sd

Specifies the socket descriptor of an SCTP endpoint.

msg

Specifies the message to be sent.

len

Specifies the size of the message or the size of buffer.

to

Specifies one of the peer addresses of the association to be used to send the message.

tolen

Specifies the size of the address.

buf

Specifies the buffer to store a received message.

from

Specifies the buffer to store the peer address used to send the received message.

fromlen

Specifies the size of the from address.

flags

Contains flags affecting the message being sent.

The send()(), sendto()(), recv()(), and recvfrom()() calls provide access to only basic SCTP protocol features. If a peer in an association uses multiple streams or sends unordered data, these calls may not be adequate. As a result, it may deliver data in unpredictable ways.

These calls do not allow the application to specify the stream on which a message must be sent. SCTP uses stream 0 as the default stream to send data using send()() and sendto()(). The recv()() and recvfrom()() calls return data from any stream. However, the application cannot distinguish the different streams. As a result, data arrives without any order. Similarly, if an application sends unordered data chunk, recv()() and recvfrom()() do not provide any notification for the unordered data.

The message buffer buf in the send()() and sendto()() calls is a single message buffer. If the caller wants to send a message that is composed of several buffers, the caller must combine all the buffers, before calling send()() and sendto()(). Alternately, the caller can use the sendmsg()() call to send multiple buffers, without combining the buffers. The recv()() and recvfrom()() calls cannot distinguish message boundaries.

You cannot use the send()() and recv()() calls in the case of one-to-many style sockets.

NOTE: If an application calls a send function without user and ancillary data, SCTP rejects the request with an appropriate error message.

The setsocktopt() and getsockopt() Socket Calls

Applications use the setsockopt()() and the getsockopt()() calls to set and retrieve socket options. You can use the socket options to modify the default behavior of the sockets calls. For information on socket options, see “API Options to Modify Socket Behavior”.

NOTE: While using the SCTP_ASSOCINFO option to set the maximum number of retransmissions, the sctp_opt_info()() call does not fail if this number is greater than the sum of all maximum path retransmissions for each remote address. Therefore, the success or failure of this option does not depend on the number of remote addresses and whether the association is up.

Following are the syntaxes for the getsockopt()() and setsockopt()() socket calls, respectively:

getsockopt(int sd, int level, int optname, void *optval,
 socklen_t *optlen);
setsockopt(int sd, int level, int optname, const void *optval,
 socklen_t optlen);

where:

sd

Specifies the socket description.

level

Specifies the type of protocol. You must set the level to IPPROTO_SCTP for all SCTP options.

optname

Specifies the option name.

optval

Specifies the buffer to store the value of the option.

optlen

Specifies the size of the buffer (or the length of the option returned).

NOTE: A positive linger time for the SO_LINGER option results in an immediate termination of the process following the SCTP shutdown.

The read() and write() Socket Calls

Applications use read()() and write()() socket calls to send and receive data to and from a peer. These socket calls have the same functionality as the send()() and recv()() socket calls, except that the flags parameter is not present in the read()() and write()() calls.

If these calls are used in one-to-many style sockets, applications can use these calls only with branched off socket descriptors.

The getsockname() Socket Call

Applications use getsockname()() to retrieve the locally-bound socket address of the specified socket. This is especially useful if the caller allows SCTP to select a local port. The getsockname()() API is also useful if an SCTP endpoint is not multihomed. An HP-UX socket uses its copy of the bound address to implement the getsockname()() system call.

Following is the syntax for the getsockname()() socket call:

 int getsockname(int sd, struct sockaddr *address,
 socklen_t *len);

where:

sd

Specifies the socket descriptor to be queried.

address

Stores the locally bound address that is selected by the SCTP stack. If the socket is an IPv4 socket, the address will be an IPv4 address. If the socket is an IPv6 socket, the address can be either an IPv6 or IPv4 address.

len

Specifies the length of the address.

If the actual length of the address is greater than the length of the sockaddr structure, the stored address is truncated. If the socket is not bound to a local name, the value contained in the address variable is not specified.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2007–2008 Hewlett-Packard Development Company, L.P.