gen_sctp multi-homing error
Дмитрий Омелечко
На сервере и клиенте по 2 интерфейса и подключены к разным сетям.
[server] - 192.168.0.0/24 - [client]
[ ] - 10.0.0.0/24 - [ ]
Собственно код написан по примеру из man gen_sctp.
INIT & INIT-ACK при инициализации подключения содержат правильные адреса.
НО после отсылки сервером HEARTBEAT в соседний канал клиент отвечает ABBORT вместо HEARTBEAT-ACK, и насколько я понял именно это является причной не работающего fail-over`a и не только...
к серверу приходит {sctp_assoc_change, comm_lost, 0, 0, 0, 1} а у клиента вообще выскакивает {error, epipe}.
Пока сетвых на клиенте была ровно 1-а - все работало.
Пробовал выставлять клиенту {sctp_peer_addr_params, #sctp_paddrparams{flags=[hb_enable]}} - не помогло.
Что я пропустил? У кого вообще работает multi-homing поделитесь куском кода.
И второй вопрос. Неоднозначно в документации написано про балансировку нагрузки на несколько каналов. В моем случае пропускная способность каналов будет очень мала.
Можно ли с помощью sctp сагрегировать пропускную способность всех имеющихся у клиента каналов?
Возможно вопросы пионерские, но заранее спасибо за любую помощь.
Valentin Nechayev
И второй вопрос. Неоднозначно в документации написано про балансировку нагрузки на несколько каналов. В моем случае пропускная способность каналов будет очень мала.
Можно ли с помощью sctp сагрегировать пропускную способность всех имеющихся у клиента каналов?
Насколько я понял его описание - нет. Для реальной балансировки надо самому открывать несколько соединений.
-netch-
Дмитрий Омелечко
http://www.osp.ru/os/2002/02/181115/
а именно вот этот раздел (может не правильно все понял):
Снижение нагрузки
Стремясь обеспечить избыточность, предприятия часто подключаются ко второму Internet-провайдеру. Чтобы гарантировать возможность доставки пакетов по второму каналу, пользователь должен сообщить набор адресов (обычно полученный от первого провайдера), который выходит за рамки адресного диапазона, поддерживаемого вторым провайдером. Второй Internet-провайдер должен затем сообщить свое собственное объединенное адресное пространство и конкретные адреса, выделенные данному клиенту, что приводит к значительному росту числа записей в таблице маршрутизации.
Такое решение становится необязательным при работе с SCTP, поскольку ассоциация будет охватывать IP-адреса, содержащиеся в объединенных адресных диапазонах, поддерживаемых обоими провайдерами. Многодомность SCTP может, таким образом, использоваться для снижения нагрузки в системе маршрутизации Internet.
Valentin Nechayev
Такое решение становится необязательным при работе с SCTP, поскольку ассоциация будет охватывать IP-адреса, содержащиеся в объединенных адресных диапазонах, поддерживаемых обоими провайдерами. Многодомность SCTP может, таким образом, использоваться для снижения нагрузки в системе маршрутизации Internet.
Снижения нагрузки _в системе маршрутизации_. Я ни слова не вижу ни тут ни в RFC4960 про балансинг. Зато вижу про network-level fault tolerance.
-netch-
Дмитрий Омелечко
https://dbkn.ismb.it/DBKN%20Content/6/presentations/load-balancing-over-multipaths-using-bandwidth-aware-source-scheduling