Introduction

After exploring how SCTP multi-homing works, it's time to see how to use this feature in Linux. This post will show how to implement multi-homing for the client-server application, used up to now. Baseline code for the development will be the 'one-to-many_advanced' branch, used in SCTP specific socket functions in Linux post. It already uses SCTP's advanced interface so only a few modifications are required to get the job done.

Implementing multi-homing means that the server should bind to more than one IP address and the client - to connect to more than one destination IP address. Both applications can also operate on single IP address. Mixed scenario is also possible, e.g. multi-homed server can communicate with non multi-homed client.

The code in this post uses one-to-many styles sockets, however the approach is the same for one-to-one sockets. I am pretty sure that you will be able to handle the latter case by yourself, so I will not discuss it. Anyway do not hesitate to leave a comment, in case you have got any questions.

Read more…

What is multihoming

In the previous posts about the SCTP protocol, I promised a separate article about multi-homing. I think we have covered most of the basic topics and now it is time to review this killer feature. The behaviour of a multi-homed SCTP node is scattered around RFC 4960 and in this post I will present the most important aspects.

I think Section 6.4 has got the best definition for multi-homing:

An SCTP endpoint is considered multi-homed if there are more than one transport address that can be used as a destination address to reach that endpoint.

Read more…

Preface

In the previous posts we have used socket related functions common for protocols other than SCTP. For example with connect() you can connect to a remote peer with either TCP or SCTP socket. recvmsg() and sendmsg() can also be used with UDP and SCTP. This is normal, because SCTP has features similar to TCP (connection oriented) and UDP (message based). However SCTP's unique features deserve specific API. In this post we will review some SCTP only functions for sending and receiving messages, establishing associations and extracting local and peer IP addresses from the association.

Read more…

Introduction

In the previous post we have discussed the ancillary data - one of the ways to access SCTP specific protocol parameters and events. Today we will review another similar topic - the SCTP notifications. They are also received with recvmsg(), but you receive different kind of information. Ancillary data allowed us to get some SCTP specific parameters for the DATA chunk containing the payload, like stream number, association id, etc. With notifications you can access more general information about the association - e.g. receive event when it is established, when it is teared down, remote errors, etc.

SCTP notifications are described in Section 6 of RFC 6458. The implementation of Linux has got some really small differences from the specification, but they are in terms of structure/parameter names. I will try to list them, but even if I forget something you will easily notice them by yourself.

Read more…