Конкретно, у меня при создании виртуальных интерфейсов и создания ассоциации на двух адресах при отключении одного из них, переключение и продолжение передачи от клиента занимает секунд 15-20.

Ты что-то всё перепутал.

Во-первых, у SCTP есть контроль доставки и основной адрес передачи. Если по основному адресу не было подтверждения сегмента данных, данные посылаются по другим адресам. Далее, если передача (в зависимости от параметров) стала не возможна несколько раз подряд, адрес считается недоступным и следующий адрес считается основным.

Во-вторых, то что ты ищешь находится в /proc/sys/net/sctp.

path_max_retrans - Максимальное количество повторных передач, после которых считается, что адрес недоступен.

rto_min - Начальный тайм-аут ожидания подтверждения принятия данных. Если подтверждения не было, с каждой повторной передаче увеличивается в 2 раза.

rto_max - Максимальный тайм-аут подтверждения принятия данных. Когда предыдущий тайм-аут увеличивается в 2 раза, он не может стать больше, чем это значение.

Также стоит отметить, что эти значения работают как значения по-умолчанию для новых ассоциаций.

В твоём примере: Значения по умолчанию: rto_min (1000) и path_max_retrans( 5)

1: Передача непотверждена 1с: ++path_max = 1; rto*2=2c: Общее время 1
2: Передача неподтверждена 2с: ++path_max = 2; rto*2=4c: Общее время 3
3: Передача неподтверждена 4с: ++path_max = 3; rto*2=8c: Общее время 7
4: Передача неподтверждена 8с: ++path_max = 4; rot*2=16c: Общее время 15
5: Передача неподтверждена 16с: ++path_max = 5 <-- адрес недоступен. Общее время: ~30.

0

Нашел аналогичные структуры в sctp.h, мне из проги надо их просто устанавливать, глобальные не надо трогать. Соответственно создаем структуру, присваиваем ей нужные параметры и передаем сокету.

Странность в чем, описываю все: есть два виртуальных eth0:2 и eth0:3 интерфейса, на которые вешается сокет сервера. Клиент коннектится, все ок, передача идет. Далее берем отключаем eth0:2. Клиент, как я понимаю начинает долбиться безуспешно по первичному адресу. Потом да, при превышении параметров sasoc_asocmaxrxt или srto_max, переходит на вторичный. При этом сервер получает недошедшие сообщения(причем последнее приходит криво):

109:hello

110:???? (последнее по старому адресу)

111:hello (первое по новому)

И странно то, что при обратной операции(включаем eth0:2, отключаем 0:3) происходит мгновенное переключение. Вот почему так? И будет ли такое переключение на лету при уменьшении максимальных параметров?

22

И странно то, что при обратной операции(включаем eth0:2, отключаем 0:3) происходит мгновенное переключение. Вот почему так? И будет ли такое переключение на лету при уменьшении максимальных параметров?

Дело в том, что primary address, при недоступности, хоть и заменяется другим доступным адресом, но временно. Если по конкретному адресу(включая недоступные) не было передано данных, то раз в 30сек (heartbeat interval), то посылается heartbeat пакет, что-то вроде пинга. Если есть ответ на heartbeat, то адрес, как минимум, считается доступным. То же самое происходит с твоим eth0:2. Протокол определил, что адрес недоступен(unreachable) и раз в 30сек(по-умолчанию /proc/sys/net/sctp/hb_interval) посылает heartbeat пакет. Как только приходит ответ на heartbeat у адреса меняется статус на confirmed. И, как следствие, если этот адрес изначально был primary, то данные мгновенно начинают бегать по нему, что у тебя и просиходит.

Нашел аналогичные структуры в sctp.h, мне из проги надо их просто устанавливать, глобальные не надо трогать. Соответственно создаем структуру, присваиваем ей нужные параметры и передаем сокету.

Да, именно так и надо. Стоит заметить, что это надо делать на обоих хостах ассоциации.

Странность в чем, описываю все: есть два виртуальных eth0:2 и eth0:3 интерфейса, на которые вешается сокет сервера. Клиент коннектится, все ок, передача идет. Далее берем отключаем eth0:2. Клиент, как я понимаю начинает долбиться безуспешно по первичному адресу. Потом да, при превышении параметров sasoc_asocmaxrxt или srto_max, переходит на вторичный. При этом сервер получает недошедшие сообщения(причем последнее приходит криво)

Еще раз, протокол устроен так, что данные всё равно доставляются по другим адресам после 1-ой неудачной попытки. Но при этом, пока адрес не получит статут недоступности, следующие данные опять идут по основному адресу и так же отправляются по другим адресам после 1-ой неудачной попытки и т.д.

sasoc_asocmaxrxt не правильный параметр, правильная структура sctp_rtoinfo к сокету

struct sctp_rtoinfo
{
	sctp_assoc_t srto_assoc_id; - Только для "один-ко-многим" сокетов. Либо для указания текущей ассоциации, либо SCTP_FUTURE_ASSOC(в текущий момент не используется).
	uint32_t srto_initial; - Устанавливает начальное значение RTO
	uint32_t srto_max; - Максимальная граница для всех RTO
	uint32_t srto_min; - Минимальная граница RTO 
}

struct sctp_paddrparams
{
	sctp_assoc_t spp_assoc_id; Только для "один-ко-многим" сокетов. Либо для указания текущей ассоциации, либо SCTP_FUTURE_ASSOC(в текущий момент не используется).
	struct sockaddr_storage spp_address; - Структура с адресом конечной точки
	uint32_t spp_hbinterval; - Содержит интервал heartbeat в миллисекундах. В поле ssp_flags должен быть установлен флаг SPP_HB_ENABLE. Нулевое значение указывает на то, что это значение будет оставленно как есть. Если необходимо установить действительно значение 0, необходимо в поле spp_flags задать флаг SPP_HB_TIME_IS_ZERO.
	uint16_t spp_pathmaxrxt; - Максимальное количсетво повторных передач, до того как этот адрес признается unreachable. Значение 0 показывает, что текущее значение должно остаться неизменным.
	uint32_t spp_pathmtu; - Это поле содержит текущее определенное "Path MTU" указанного адреса. Показывает количество байт доступных в SCTP пакете для chunk. Значение 0 не меняет текущее значение.
	uint32_t spp_flags;
	uint32_t spp_ipv6_flowlabel;
	uint8_t  spp_dscp;
}

При этом сервер получает недошедшие сообщения(причем последнее приходит криво)

SCTP не гарантирует порядок доставки пакетов. По крайней мере, для stream сокетов, с seqpacket я лично мало работал.

Спасибо большое, стало намного понятнее, буду дальше копать.