Сообщение Re[14]: epoll и reassembled TCP segments от 24.04.2015 9:37
Изменено 01.05.2015 7:26 netch80
Здравствуйте, v_andal, Вы писали:
_>Резюме. Всё наше разногласие сводится к тезису о том, что тупой программер сможет делать более качественный код, если ему подсунуть SCTP вместо TCP. Если тебе хочет верить в эту глупость — то я ничего против не имею. Я же не настолько наивен. Для нормального программиста в базовом случае, разницы между SCTP и TCP нет, но документация для TCP проще и разобраться с ней получится быстрее. Собственно поэтому, большинство индусов знакомы (поверхностно) именно с TCP, а не с SCTP
Они знакомы именно с TCP, потому что ему 40 лет и он успешно занял нишу, а SCTP активно всего 10 (а для Windows и вообще, считай, 0) и в эту нишу тяжело и нудно просачивается.
В остальном я согласен, я действительно верю (не априорно, а на основании своего опыта), что тупой программер, поставленный на правильные рельсы, будет значительно меньше глупостей творить в случае SCTP, чем в случае TCP. У меня есть примеры успешного такого решения перед глазами. Один, самый эффективный, правда, не AF_INET+SCTP, а AF_UNIX+SOCK_SEQPACKET, но результат чрезвычайно вкусный. С SCTP похоже, но не настолько впечатляюще — может, потому, что у меня нет индусов.
N>>Вот именно поэтому я говорю, что из-за таких проблем надо в качестве подложки по умолчанию считать SCTP, а TCP применять только в трёх случаях — или неустранимое наследство, или требуется максимальная производительность на относительно мелких порциях, или поток вообще не ложится в концепцию сообщений крупнее октета (вряд ли это относится к чему-то более новому, чем telnet или ftp data).
_>Боже мой. Да тупойиндус программер наворочает дерьма для SCTP столько же, сколько он его льёт для TCP. Он просто вообще не сможет разобраться, как с ним работать. Утонет на фазе создания ассоциации.
connect на конкретный хост и порт — что может быть проще? Сложности с построением ассоциации пропускаем.
N>>Фазы "смести начало буфера" в случае SCTP нет. "Удали обработанное" сводится к полной вычистке буфера. Так что тут реально проще. Но опять же дело не в этом. Я полностью согласен с тезисом, что при необходимости выжать максимум скорости получается множество слоёв сверху, по сравнению с которым работа с буфером — мелочь. Но см. выше про случаи из моего мира.
_>И эту разницу ты и считаешь "архисложной"? Только не надо меня опять отсылать к кодерам не знающим, что творят. Если для человека добавление одной-двух строчек кода — архисложно, то ему уже ничем не помочь. ИМХО
Ещё раз. Дело не в сложности как таковой. Дело в ловушке, которая позволяет пропустить этот шаг в лабораторных условиях TCP, показать, что и без него всё работает, и наплевать на проблемы тех, кто будет пользоваться результатом в реальных условиях. Идеальный программист в идеальных условиях, да, такого не допустит. Реальный чужой программист, заинтересованный не в результате, а в оплате времени и карьерных KPI — сделает, и пока ты пробьёшься через 5-10 административных слоёв для доказательства, что он был неправ, ты успеешь поседеть.
N>>Будут уметь, просто потому, что они натренированы, как собачки, написать заданное в инструкции имя сисколла и подставить ему заданные параметры, и это будет работать.
_>Не смеши. Работать это дерьмо никогда не будет, точнее будет до ближайшей нестандартной ситуации в сети. И без разницы, какой протокол использовали.
Пример такой нестандартной ситуации? (Файрволлы и NAT не предлагать)
_>Резюме. Всё наше разногласие сводится к тезису о том, что тупой программер сможет делать более качественный код, если ему подсунуть SCTP вместо TCP. Если тебе хочет верить в эту глупость — то я ничего против не имею. Я же не настолько наивен. Для нормального программиста в базовом случае, разницы между SCTP и TCP нет, но документация для TCP проще и разобраться с ней получится быстрее. Собственно поэтому, большинство индусов знакомы (поверхностно) именно с TCP, а не с SCTP
Они знакомы именно с TCP, потому что ему 40 лет и он успешно занял нишу, а SCTP активно всего 10 (а для Windows и вообще, считай, 0) и в эту нишу тяжело и нудно просачивается.
В остальном я согласен, я действительно верю (не априорно, а на основании своего опыта), что тупой программер, поставленный на правильные рельсы, будет значительно меньше глупостей творить в случае SCTP, чем в случае TCP. У меня есть примеры успешного такого решения перед глазами. Один, самый эффективный, правда, не AF_INET+SCTP, а AF_UNIX+SOCK_SEQPACKET, но результат чрезвычайно вкусный. С SCTP похоже, но не настолько впечатляюще — может, потому, что у меня нет индусов.
N>>Вот именно поэтому я говорю, что из-за таких проблем надо в качестве подложки по умолчанию считать SCTP, а TCP применять только в трёх случаях — или неустранимое наследство, или требуется максимальная производительность на относительно мелких порциях, или поток вообще не ложится в концепцию сообщений крупнее октета (вряд ли это относится к чему-то более новому, чем telnet или ftp data).
_>Боже мой. Да тупой
connect на конкретный хост и порт — что может быть проще? Сложности с построением ассоциации пропускаем.
N>>Фазы "смести начало буфера" в случае SCTP нет. "Удали обработанное" сводится к полной вычистке буфера. Так что тут реально проще. Но опять же дело не в этом. Я полностью согласен с тезисом, что при необходимости выжать максимум скорости получается множество слоёв сверху, по сравнению с которым работа с буфером — мелочь. Но см. выше про случаи из моего мира.
_>И эту разницу ты и считаешь "архисложной"? Только не надо меня опять отсылать к кодерам не знающим, что творят. Если для человека добавление одной-двух строчек кода — архисложно, то ему уже ничем не помочь. ИМХО
Ещё раз. Дело не в сложности как таковой. Дело в ловушке, которая позволяет пропустить этот шаг в лабораторных условиях TCP, показать, что и без него всё работает, и наплевать на проблемы тех, кто будет пользоваться результатом в реальных условиях. Идеальный программист в идеальных условиях, да, такого не допустит. Реальный чужой программист, заинтересованный не в результате, а в оплате времени и карьерных KPI — сделает, и пока ты пробьёшься через 5-10 административных слоёв для доказательства, что он был неправ, ты успеешь поседеть.
N>>Будут уметь, просто потому, что они натренированы, как собачки, написать заданное в инструкции имя сисколла и подставить ему заданные параметры, и это будет работать.
_>Не смеши. Работать это дерьмо никогда не будет, точнее будет до ближайшей нестандартной ситуации в сети. И без разницы, какой протокол использовали.
Пример такой нестандартной ситуации? (Файрволлы и NAT не предлагать)
Re[14]: epoll и reassembled TCP segments
Здравствуйте, v_andal, Вы писали:
_>Резюме. Всё наше разногласие сводится к тезису о том, что тупой программер сможет делать более качественный код, если ему подсунуть SCTP вместо TCP. Если тебе хочет верить в эту глупость — то я ничего против не имею. Я же не настолько наивен. Для нормального программиста в базовом случае, разницы между SCTP и TCP нет, но документация для TCP проще и разобраться с ней получится быстрее. Собственно поэтому, большинство индусов знакомы (поверхностно) именно с TCP, а не с SCTP
Они знакомы именно с TCP, потому что ему 40 лет и он успешно занял нишу, а SCTP активно всего 10 (а для Windows и вообще, считай, 0) и в эту нишу тяжело и нудно просачивается.
В остальном я согласен, я действительно предсказываю (не априорно, а на основании своего опыта), что тупой программер, поставленный на правильные рельсы, будет значительно меньше глупостей творить в случае SCTP, чем в случае TCP. У меня есть примеры успешного такого решения перед глазами. Один, самый эффективный, правда, не AF_INET+SCTP, а AF_UNIX+SOCK_SEQPACKET, но результат чрезвычайно вкусный. С SCTP похоже, но не настолько впечатляюще — может, потому, что у меня нет индусов.
N>>Вот именно поэтому я говорю, что из-за таких проблем надо в качестве подложки по умолчанию считать SCTP, а TCP применять только в трёх случаях — или неустранимое наследство, или требуется максимальная производительность на относительно мелких порциях, или поток вообще не ложится в концепцию сообщений крупнее октета (вряд ли это относится к чему-то более новому, чем telnet или ftp data).
_>Боже мой. Да тупойиндус программер наворочает дерьма для SCTP столько же, сколько он его льёт для TCP. Он просто вообще не сможет разобраться, как с ним работать. Утонет на фазе создания ассоциации.
connect на конкретный хост и порт — что может быть проще? Сложности с построением ассоциации пропускаем.
N>>Фазы "смести начало буфера" в случае SCTP нет. "Удали обработанное" сводится к полной вычистке буфера. Так что тут реально проще. Но опять же дело не в этом. Я полностью согласен с тезисом, что при необходимости выжать максимум скорости получается множество слоёв сверху, по сравнению с которым работа с буфером — мелочь. Но см. выше про случаи из моего мира.
_>И эту разницу ты и считаешь "архисложной"? Только не надо меня опять отсылать к кодерам не знающим, что творят. Если для человека добавление одной-двух строчек кода — архисложно, то ему уже ничем не помочь. ИМХО
Ещё раз. Дело не в сложности как таковой. Дело в ловушке, которая позволяет пропустить этот шаг в лабораторных условиях TCP, показать, что и без него всё работает, и наплевать на проблемы тех, кто будет пользоваться результатом в реальных условиях. Идеальный программист в идеальных условиях, да, такого не допустит. Реальный чужой программист, заинтересованный не в результате, а в оплате времени и карьерных KPI — сделает, и пока ты пробьёшься через 5-10 административных слоёв для доказательства, что он был неправ, ты успеешь поседеть.
N>>Будут уметь, просто потому, что они натренированы, как собачки, написать заданное в инструкции имя сисколла и подставить ему заданные параметры, и это будет работать.
_>Не смеши. Работать это дерьмо никогда не будет, точнее будет до ближайшей нестандартной ситуации в сети. И без разницы, какой протокол использовали.
Пример такой нестандартной ситуации? (Файрволлы и NAT не предлагать)
_>Резюме. Всё наше разногласие сводится к тезису о том, что тупой программер сможет делать более качественный код, если ему подсунуть SCTP вместо TCP. Если тебе хочет верить в эту глупость — то я ничего против не имею. Я же не настолько наивен. Для нормального программиста в базовом случае, разницы между SCTP и TCP нет, но документация для TCP проще и разобраться с ней получится быстрее. Собственно поэтому, большинство индусов знакомы (поверхностно) именно с TCP, а не с SCTP
Они знакомы именно с TCP, потому что ему 40 лет и он успешно занял нишу, а SCTP активно всего 10 (а для Windows и вообще, считай, 0) и в эту нишу тяжело и нудно просачивается.
В остальном я согласен, я действительно предсказываю (не априорно, а на основании своего опыта), что тупой программер, поставленный на правильные рельсы, будет значительно меньше глупостей творить в случае SCTP, чем в случае TCP. У меня есть примеры успешного такого решения перед глазами. Один, самый эффективный, правда, не AF_INET+SCTP, а AF_UNIX+SOCK_SEQPACKET, но результат чрезвычайно вкусный. С SCTP похоже, но не настолько впечатляюще — может, потому, что у меня нет индусов.
N>>Вот именно поэтому я говорю, что из-за таких проблем надо в качестве подложки по умолчанию считать SCTP, а TCP применять только в трёх случаях — или неустранимое наследство, или требуется максимальная производительность на относительно мелких порциях, или поток вообще не ложится в концепцию сообщений крупнее октета (вряд ли это относится к чему-то более новому, чем telnet или ftp data).
_>Боже мой. Да тупой
connect на конкретный хост и порт — что может быть проще? Сложности с построением ассоциации пропускаем.
N>>Фазы "смести начало буфера" в случае SCTP нет. "Удали обработанное" сводится к полной вычистке буфера. Так что тут реально проще. Но опять же дело не в этом. Я полностью согласен с тезисом, что при необходимости выжать максимум скорости получается множество слоёв сверху, по сравнению с которым работа с буфером — мелочь. Но см. выше про случаи из моего мира.
_>И эту разницу ты и считаешь "архисложной"? Только не надо меня опять отсылать к кодерам не знающим, что творят. Если для человека добавление одной-двух строчек кода — архисложно, то ему уже ничем не помочь. ИМХО
Ещё раз. Дело не в сложности как таковой. Дело в ловушке, которая позволяет пропустить этот шаг в лабораторных условиях TCP, показать, что и без него всё работает, и наплевать на проблемы тех, кто будет пользоваться результатом в реальных условиях. Идеальный программист в идеальных условиях, да, такого не допустит. Реальный чужой программист, заинтересованный не в результате, а в оплате времени и карьерных KPI — сделает, и пока ты пробьёшься через 5-10 административных слоёв для доказательства, что он был неправ, ты успеешь поседеть.
N>>Будут уметь, просто потому, что они натренированы, как собачки, написать заданное в инструкции имя сисколла и подставить ему заданные параметры, и это будет работать.
_>Не смеши. Работать это дерьмо никогда не будет, точнее будет до ближайшей нестандартной ситуации в сети. И без разницы, какой протокол использовали.
Пример такой нестандартной ситуации? (Файрволлы и NAT не предлагать)