Здравствуйте, netch80, Вы писали:

N>Здравствуйте, v_andal, Вы писали:

_>>Резюме. Всё наше разногласие сводится к тезису о том, что тупой программер сможет делать более качественный код, если ему подсунуть SCTP вместо TCP. Если тебе хочет верить в эту глупость — то я ничего против не имею. Я же не настолько наивен. Для нормального программиста в базовом случае, разницы между SCTP и TCP нет, но документация для TCP проще и разобраться с ней получится быстрее. Собственно поэтому, большинство индусов знакомы (поверхностно) именно с TCP, а не с SCTP

N>Они знакомы именно с TCP, потому что ему 40 лет и он успешно занял нишу, а SCTP активно всего 10 (а для Windows и вообще, считай, 0) и в эту нишу тяжело и нудно просачивается.

Да и сам протокол тяжеловат...

N>connect на конкретный хост и порт — что может быть проще? Сложности с построением ассоциации пропускаем.

Хе, чтобы пропустить то, что можно пропустить и выцепить то, что что нужно выцепить, талант надо иметь. А с талантом без разницы какой протокол штудировать

N>Ещё раз. Дело не в сложности как таковой. Дело в ловушке, которая позволяет пропустить этот шаг в лабораторных условиях TCP, показать, что и без него всё работает, и наплевать на проблемы тех, кто будет пользоваться результатом в реальных условиях.

Так блин, такой программист и partial read в SCTP проигнорирует, на тех же условиях.

N>Пример такой нестандартной ситуации? (Файрволлы и NAT не предлагать)

А если подсунуть удалённому хосту заведомо большой пакет (выходящий за пределы системных буферов), вынуждающий его скармливать этот пакет в несколько приёмов?
Или мы говорим исключительно о протоколах внутреннего использования? Или начнёшь заверять, что индус отказывающийся верить, что в TCP пакет может прийти разбитым, вдруг чудесным образом поверит, что в SCTP это возможно? И это после того, как его заверят, что SCTP в отличие от TCP сохраняет границы пакета? Увольте, в такие чудеса я не верю.