If the sctp_sendmsg function returns an error, no message will be sent and the application would then do a blocking sctp_recvmsg, waiting for a response message that would never be sent to it.

A way to fix this is to check the error return codes, and if an error occurs on sending, the client should NOT do the receive, but instead should report an error.

If the sctp_recvmsg function returns an error, no message will arrive and the server will still attempt to send a message, possibly setting up an association. To avoid this, the error code should be checked, and depending on the error, you may wish to report the error and close the socket, letting the server also then receive an error; or, if the error is transient, you could retry the sctp_recvmsg call.

If the server receives a request and then exits, the client in its current form will hang forever waiting for a message that will never come. A method that can be used by the client to detect this is to enable association events. This will allow the client application to receive a message when the server exits, telling the client that the association is now gone. This would allow the client to then take a recovery action such as contacting a different server.

An alternative method the client could use is to set up a timer and abort after some time period.

We choose 800 bytes to attempt to get each chunk in a single packet. A better way would be to get or set the SCTP_MAXSEG socket option to determine the size that will fit in one chunk.

The Nagle algorithm (controlled by the SCTP_NODELAY socket option; see Section 7.10) will cause a problem only if we choose a small data transfer size. So as long as we send a size that forces SCTP to send immediately, no harm will occur. However, choosing a smaller size for out_sz would skew the results, holding some transmissions awaiting SACKs from the remote endpoint. So if a smaller size is to be used, turning off the Nagle algorithm (i.e., turning on the SCTP_NODELAY socket option) would be a good idea.

If an application sets up an association and then changes the number of streams, the association will not have a different number of streams, it will have the original number before the change. This is because changing the number of streams only affects new associations, not existing ones.

The one-to-many style allows implicit setup of associations. To use ancillary data to change the setup of an association, you need to use the sendmsg call to provide the data before the association is set up. Thus, you must use an implicit association setup.