ssf_flags will be set to one of two values:
- SCTP_DATA_UNSENT, which indicates that the message could never be transmitted to the peer (e.g., flow control prevented the message from being sent before its lifetime expired), so the peer never received it.
- SCTP_DATA_SENT, which indicates that the data was transmitted to the peer at least once, but was never acknowledged. In this case, the peer may have received the message, but it was unable to acknowledge it.
SCTP_SHUTDOWN_EVENT
This notification is passed to an application when a peer sends a SHUTDOWN chunk to the local endpoint. This notification informs the application that no new data will be accepted on the socket. All currently queued data will be transmitted, and at the completion of that transmission, the association will be shut down. The notification format is as follows:
struct sctp_shutdown_event {
uint16_t sse_type;
uint16_t sse_flags;
uint32_t sse_length;
sctp_assoc_t sse_assoc_id;
};
SCTP_ADAPTION_INDICATION
Some implementations support an adaption layer indication parameter. This parameter is exchanged in the INIT and INIT-ACK to inform each peer what type of application adaption is being performed. The notification will have the following form:
struct sctp_adaption_event {
u_int16_t sai_type;
u_int16_t sai_flags;
u_int32_t sai_length;
u_int32_t sai_adaption_ind;
sctp_assoc_t sai_assoc_id;
};
SCTP_PARTIAL_DELIVERY_EVENT
The partial delivery application interface is used to transport large messages to the user via the socket buffer. Consider a user writing a single message of 4MB. A message of this size would tax or exhaust system resources. An SCTP implementation would fail to handle such a message unless the implementation had a mechanism to begin delivering the message before all of it arrived. When an implementation does this form of delivery, it is termed “the partial delivery API.” The partial delivery API is invoked by the SCTP implementation sending data with the msg_flags field remaining clear until the last piece of the message is ready to be delivered. The last piece of the message will have the msg_flags set to MSG_EOR. Note that if an application is going to receive large messages, it should use either recvmsg or sctp_recvmsg so that the msg_flags field can be examined for this condition.
struct sctp_pdapi_event {
uint16_t pdapi_type;
uint16_t pdapi_flags;
uint32_t pdapi_length;
uint32_t pdapi_indication;
sctp_assoc_t pdapi_assoc_id;
};
The pdapi_assoc_id field identifies the association upon which the partial delivery API event has occurred. The pdapi_indication holds the event that has occurred. Currently, the only valid value found in this field is SCTP_PARTIAL_DELIVERY_ABORTED, which indicates that the currently active partial delivery has been aborted.
SCTP Client/Server Example
Introduction
We will now use some of the elementary functions from Chapters 4(See 8.2) and Chapter 9(See 8.7) to write a complete one-to-many SCTP client/server example. Our simple example is similar to the echo server presented in Chapter 5(See 8.3), and performs the following steps:
1.A client reads a line of text from standard input and sends the line to the server. The line follows the form [#] text, where the number in brackets is the SCTP stream number on which the text message should be sent.
2.The server receives the text message from the network, increases the stream number on which the message arrived by one, and sends the text message back to the client on this new stream number.
3.The client reads the echoed line and prints it on its standard output, displaying the stream number, stream sequence number, and text string.