Защита и надёжность превыше всего. В наше время информация играет очень значительную роль в жизни. В связи с этим очень уместно было бы внедрение реализации протокола SCTP (Stream Control Transmission Protocol — «протокол передачи с управлением потоком») в новую версию Windows. Это обеспечит защиту от SYN-flood атак, безопасное установление подключения (с помощью четырёхэтапного квитирования), а также приятные нововведения в виде сохранения границ сообщения, многопоточность, неупорядоченная доставка, поддержка множественных интерфейсов. Внедрение данного протокола позволит вывести сети на новый уровень, увеличить скорость, надёжность, безопасность и возможности передачи данных по сети. Ведь новый протокол создавался с учётом недостатков устаревшего TCP, с учётом современных сетей и полного использования их возможностей, а также особое внимание было уделено надёжности и безопасности.
Давно пора продвигать протокол SCTP повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.
Здравствуйте, CSRedRat, Вы писали:
CSR>Защита и надёжность превыше всего. В наше время информация играет очень значительную роль в жизни. В связи с этим очень уместно было бы внедрение реализации протокола SCTP (Stream Control Transmission Protocol — «протокол передачи с управлением потоком») в новую версию Windows. Это обеспечит защиту от SYN-flood атак, безопасное установление подключения (с помощью четырёхэтапного квитирования), а также приятные нововведения в виде сохранения границ сообщения, многопоточность, неупорядоченная доставка, поддержка множественных интерфейсов. Внедрение данного протокола позволит вывести сети на новый уровень, увеличить скорость, надёжность, безопасность и возможности передачи данных по сети. Ведь новый протокол создавался с учётом недостатков устаревшего TCP, с учётом современных сетей и полного использования их возможностей, а также особое внимание было уделено надёжности и безопасности.
:yawn:
А где реализация искаропки в винде? Где нормальная реализация в линуксе?
Почему с 2000 года в мире только два энтузиаста, которые его развивают?
Мне он тоже нравится. Но почему так получается, что реально его использовать просто нельзя, потому что поддержка, мягко говоря, слабовата?
CSR>Давно пора продвигать протокол SCTP повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.
О! Осталось убедить Рокфеллера (c)
Что-то я уже второй раз за последние 2 дня вспоминаю эту фразу. Видимо, музыкой навеяло.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, CSRedRat, Вы писали:
CSR>>Защита и надёжность превыше всего. В наше время информация играет очень значительную роль в жизни. В связи с этим очень уместно было бы внедрение реализации протокола SCTP (Stream Control Transmission Protocol — «протокол передачи с управлением потоком») в новую версию Windows. Это обеспечит защиту от SYN-flood атак, безопасное установление подключения (с помощью четырёхэтапного квитирования), а также приятные нововведения в виде сохранения границ сообщения, многопоточность, неупорядоченная доставка, поддержка множественных интерфейсов. Внедрение данного протокола позволит вывести сети на новый уровень, увеличить скорость, надёжность, безопасность и возможности передачи данных по сети. Ведь новый протокол создавался с учётом недостатков устаревшего TCP, с учётом современных сетей и полного использования их возможностей, а также особое внимание было уделено надёжности и безопасности.
N>:yawn: N>А где реализация искаропки в винде? Где нормальная реализация в линуксе? N>Почему с 2000 года в мире только два энтузиаста, которые его развивают?
N>Мне он тоже нравится. Но почему так получается, что реально его использовать просто нельзя, потому что поддержка, мягко говоря, слабовата?
CSR>>Давно пора продвигать протокол SCTP повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.
N>О! Осталось убедить Рокфеллера (c) N>Что-то я уже второй раз за последние 2 дня вспоминаю эту фразу. Видимо, музыкой навеяло.
В том и проблема, что поддержки со стороны Microsoft нет (не считая поддержки в .NET Framework 4, а значит подвижки есть), а является серьёзной преградой. В Linux реализация включена в основную ветвь ядра с версии 2.4 и уже более года является устоявшейся. Для Windows есть сторонние реализации под .NET и Win32. Тут не хватает поддержки в развитии самого протокола со стороны влиятельных компаний, они решили ограничиться кратким освещением данной темы и поддержки (кроме MS), а ведь тут есть из-за чего поддержать.
Здравствуйте, netch80, Вы писали:
N>А где реализация искаропки в винде? Где нормальная реализация в линуксе? N>Почему с 2000 года в мире только два энтузиаста, которые его развивают?
В Линуксе замечательная реализация. Я его даже использовал уже пару раз, когда надо было interleaving сделать для нескольких потоков по одному сокету.
CSR>Защита и надёжность превыше всего. В наше время информация играет очень значительную роль в жизни. В связи с этим очень уместно было бы внедрение реализации протокола SCTP (Stream Control Transmission Protocol — «протокол передачи с управлением потоком») в новую версию Windows. Это обеспечит защиту от SYN-flood атак, безопасное установление подключения (с помощью четырёхэтапного квитирования)
Както мне не ясно чем это самое "четырехэтапное квитирование" обеспечивает защиту от син-флуда.
Из педивикии:
Протокол SCTP защищен от подобных атак с помощью механизма четырехэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.
Непонятен момент: Почему именно после получения cookie-ack сервер выделяет ресурсы? Ведь для того чтобы запоминать эту самую cookie (а ее надо запоминать, иначе как же серверу знать, что именно должен прислать клиент в ответ) серверу требуются ресурсы. И чтото мне совсем не очевидно в чем выигрыш такой схемы по сравнению с трехэапным хэндшэйком TCP.
Впрочем, если предположить что кука генерируется криптографически (представляет собой рандом + подпись этого рандома, гаммированного IP отправителя для надежности) то можно избежать расходов памяти на хранение куки и просто верифицировать ее приватным ключом на стороне сервера при получении ECHO, но тут имхо мы заменяем жор памяти жором CPU
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Непонятен момент: Почему именно после получения cookie-ack сервер выделяет ресурсы? Ведь для того чтобы запоминать эту самую cookie (а ее надо запоминать, иначе как же серверу знать, что именно должен прислать клиент в ответ) серверу требуются ресурсы. И чтото мне совсем не очевидно в чем выигрыш такой схемы по сравнению с трехэапным хэндшэйком TCP.
Серверу не надо сохранять cookie, так как она вычисляется по фиксированному алгоритму с использованием случайного секретного ключа и пары адресов клиента и сервера.
O>>Непонятен момент: Почему именно после получения cookie-ack сервер выделяет ресурсы? Ведь для того чтобы запоминать эту самую cookie (а ее надо запоминать, иначе как же серверу знать, что именно должен прислать клиент в ответ) серверу требуются ресурсы. И чтото мне совсем не очевидно в чем выигрыш такой схемы по сравнению с трехэапным хэндшэйком TCP. C>Серверу не надо сохранять cookie, так как она вычисляется по фиксированному алгоритму с использованием случайного секретного ключа и пары адресов клиента и сервера.
см мое помледнее предложение в пред мессаге — не позволи ли это атакеру пожрать весь CPU (а не память ка раньше) и эффективно добиться того же DDoS'а пожиранием просто другого ресурса? Впрочем, подписи всяческие мона ускорять аппаратно почти вплоть до одного така CPU, в отличии объема памяти... Но тем не менее...
Далее — вызывает вопросы фича протокола "нарезки потока на пакеты". Фича само собой нубами востребованная, судя по половине вопросов в этом разделе RSDN, но не ограничит ли она возможности оптимизации обработки большого потока данных приходящего от карты — раньше драйвер мог напрямую складывать приходящие данные сразу в юзермодный буфер, с возможностью обхождения без промежуточного буфера ваще (несколько одновременных асинхронных WSARecv'ов в винде), а сейчас принимающему приложению по любому нужно будет знать "наперед" несколько размеров пакетов чтобы воспользоваться такой же техникой.
И еще — раз уж сделали блэкжек заменяющиий udp и tcp, где же девушки легкого поведения мультикаст? Или я его плохо искал — все что бегло находилось по запросу sctp больше напоминало "круто было бы сделатьеще и мультикаст" чем спецификацию того, что он его умеет.
И возвращаясь к syn-флуду — я тут обратил внимание на наличие "потоков" в sctp — не могут ли эти потоки оказаться объектом для DoS — скажем я подключусь по честному, потом открою стопяццот потоков на передачу 100 байтного пакета в каждом?...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
C>>Серверу не надо сохранять cookie, так как она вычисляется по фиксированному алгоритму с использованием случайного секретного ключа и пары адресов клиента и сервера. O>см мое помледнее предложение в пред мессаге — не позволи ли это атакеру пожрать весь CPU (а не память ка раньше) и эффективно добиться того же DDoS'а пожиранием просто другого ресурса? Впрочем, подписи всяческие мона ускорять аппаратно почти вплоть до одного така CPU, в отличии объема памяти... Но тем не менее...
Там вся "подпись" — это несколько xor'ов, в общем даже на 10ГБит совершенно пофиг будет.
O>Далее — вызывает вопросы фича протокола "нарезки потока на пакеты". Фича само собой нубами востребованная, судя по половине вопросов в этом разделе RSDN, но не ограничит ли она возможности оптимизации обработки большого потока данных приходящего от карты — раньше драйвер мог напрямую складывать приходящие данные сразу в юзермодный буфер, с возможностью обхождения без промежуточного буфера ваще (несколько одновременных асинхронных WSARecv'ов в винде), а сейчас принимающему приложению по любому нужно будет знать "наперед" несколько размеров пакетов чтобы воспользоваться такой же техникой.
Не ограничит. Сохранение границ пакетов — опциональная фича.
А вот ускорить работу может, так как переключение в usermode будет только когда гарантировано придёт весь пакет.
O>И еще — раз уж сделали блэкжек заменяющиий udp и tcp, где же девушки легкого поведения мультикаст? Или я его плохо искал — все что бегло находилось по запросу sctp больше напоминало "круто было бы сделатьеще и мультикаст" чем спецификацию того, что он его умеет.
Мультикаст — это вообще отдельная история. К sctp непонятно как его прикрутить — многостороннее рукопожатие через multicast я слабо представляю.
O>И возвращаясь к syn-флуду — я тут обратил внимание на наличие "потоков" в sctp — не могут ли эти потоки оказаться объектом для DoS — скажем я подключусь по честному, потом открою стопяццот потоков на передачу 100 байтного пакета в каждом?...
Только по согласованию с сервером.
Здравствуйте, Cyberax, Вы писали:
O>>Далее — вызывает вопросы фича протокола "нарезки потока на пакеты". Фича само собой нубами востребованная, судя по половине вопросов в этом разделе RSDN, но не ограничит ли она возможности оптимизации обработки большого потока данных приходящего от карты — раньше драйвер мог напрямую складывать приходящие данные сразу в юзермодный буфер, с возможностью обхождения без промежуточного буфера ваще (несколько одновременных асинхронных WSARecv'ов в винде), а сейчас принимающему приложению по любому нужно будет знать "наперед" несколько размеров пакетов чтобы воспользоваться такой же техникой. C>Не ограничит. Сохранение границ пакетов — опциональная фича.
На SCTP, насколько я его понимаю, не опциональная — оно всегда будет их передавать.
C>Мультикаст — это вообще отдельная история. К sctp непонятно как его прикрутить — многостороннее рукопожатие через multicast я слабо представляю.
Здравствуйте, ononim, Вы писали:
O>И еще — раз уж сделали блэкжек заменяющиий udp и tcp, где же девушки легкого поведения мультикаст? Или я его плохо искал — все что бегло находилось по запросу sctp больше напоминало "круто было бы сделатьеще и мультикаст" чем спецификацию того, что он его умеет.
Мультикаст для протокола с установлением соединения неприменим по определению. Если где-то он пристроен к этому, то хитрым винтом сбоку.
O>И возвращаясь к syn-флуду — я тут обратил внимание на наличие "потоков" в sctp — не могут ли эти потоки оказаться объектом для DoS — скажем я подключусь по честному, потом открою стопяццот потоков на передачу 100 байтного пакета в каждом?...
Не откроешь. По умолчанию каждая сторона обязана поддерживать только 10 потоков, и то если запрошено при установлении соединения. То есть потоки 0-9 будут, каждый со своим пределом приёма, а дальше — фиг.
N>>О! Осталось убедить Рокфеллера (c) N>>Что-то я уже второй раз за последние 2 дня вспоминаю эту фразу. Видимо, музыкой навеяло. CSR>В том и проблема, что поддержки со стороны Microsoft нет (не считая поддержки в .NET Framework 4, а значит подвижки есть), а является серьёзной преградой. В Linux реализация включена в основную ветвь ядра с версии 2.4 и уже более года является устоявшейся.
В Linux реализация имеет много проблем.
На сейчас единственная нормальная и хорошо развивающаяся реализация — в BSD системах. Авторы протокола ведут его в первую очередь во FreeBSD и затем переносят. Уже в Linux оно совершенно на тяп-ляп. Виндовые реализации я даже боюсь трогать.
CSR>Кому интересно — статья на сайте IBM.
Здравствуйте, Cyberax, Вы писали:
N>>А где реализация искаропки в винде? Где нормальная реализация в линуксе? N>>Почему с 2000 года в мире только два энтузиаста, которые его развивают? C>В Линуксе замечательная реализация. Я его даже использовал уже пару раз, когда надо было interleaving сделать для нескольких потоков по одному сокету.
"Пару раз" — рифма напрашивается. Если бы ты постоянно использовал, сам бы нарвался на достаточное количество грабель.
C>В Винде тоже появляется постепенно.
Вот пусть вложат в коробку, тогда поверю. И ещё — чтобы я согласился с серьёзностью поддержки, нужен хотя бы один вариант ограничения переповтора сообщения (по времени или по количеству попыток), без этого он мне сейчас нафиг не сдался ни для одной из работ.
C>>>Серверу не надо сохранять cookie, так как она вычисляется по фиксированному алгоритму с использованием случайного секретного ключа и пары адресов клиента и сервера. O>>см мое помледнее предложение в пред мессаге — не позволи ли это атакеру пожрать весь CPU (а не память ка раньше) и эффективно добиться того же DDoS'а пожиранием просто другого ресурса? Впрочем, подписи всяческие мона ускорять аппаратно почти вплоть до одного така CPU, в отличии объема памяти... Но тем не менее... C>Там вся "подпись" — это несколько xor'ов, в общем даже на 10ГБит совершенно пофиг будет.
Эээ. А нет ли возможности атакеру угадать ключик для этих ксоров, получая от сервера легальные куки и далее самому генерить кук валидные с тз сервера? ==> cookie flood
Как много веселых ребят, и все делают велосипед...
O>>И возвращаясь к syn-флуду — я тут обратил внимание на наличие "потоков" в sctp — не могут ли эти потоки оказаться объектом для DoS — скажем я подключусь по честному, потом открою стопяццот потоков на передачу 100 байтного пакета в каждом?... N>Не откроешь. По умолчанию каждая сторона обязана поддерживать только 10 потоков, и то если запрошено при установлении соединения. То есть потоки 0-9 будут, каждый со своим пределом приёма, а дальше — фиг.
ну вот.. начинаются magic numbers..
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>И возвращаясь к syn-флуду — я тут обратил внимание на наличие "потоков" в sctp — не могут ли эти потоки оказаться объектом для DoS — скажем я подключусь по честному, потом открою стопяццот потоков на передачу 100 байтного пакета в каждом?... N>>Не откроешь. По умолчанию каждая сторона обязана поддерживать только 10 потоков, и то если запрошено при установлении соединения. То есть потоки 0-9 будут, каждый со своим пределом приёма, а дальше — фиг. O>ну вот.. начинаются magic numbers..
Они никогда и не кончались. Но с точки зрения общей логики я не знаю, зачем хотеть более 10 потоков. Всякие внутренние цели можно передать в основном сообщении, потоки такого рода имеют смысл только для QoS, а реальный QoS такого рода никогда не использовал на моей памяти более 4 уровней приоритета (формально позволяется 8 — например, в 802.1p). Так что 10 — с головой и выше.
N>Они никогда и не кончались. Но с точки зрения общей логики я не знаю, зачем хотеть более 10 потоков. Всякие внутренние цели можно передать в основном сообщении, потоки такого рода имеют смысл только для QoS, а реальный QoS такого рода никогда не использовал на моей памяти более 4 уровней приоритета (формально позволяется 8 — например, в 802.1p). Так что 10 — с головой и выше.
640КБ должно хватить каждому (с)
Чота мне ето число напомнило.. А.. вспомнил — вот че http://www.mydigitallife.info/half-open-outbound-tcp-connections-limit-removed-in-windows-7-and-vista-sp2-no-patch-required/
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
N>>Они никогда и не кончались. Но с точки зрения общей логики я не знаю, зачем хотеть более 10 потоков. Всякие внутренние цели можно передать в основном сообщении, потоки такого рода имеют смысл только для QoS, а реальный QoS такого рода никогда не использовал на моей памяти более 4 уровней приоритета (формально позволяется 8 — например, в 802.1p). Так что 10 — с головой и выше. O>640КБ должно хватить каждому (с)
Аналогия некорректна. Память расширяется линейно, а каждый следующий уровень QoS это как следующий уровень абстракции в логике приложения: слишком много — запутаешься.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, ononim, Вы писали:
N>>>Они никогда и не кончались. Но с точки зрения общей логики я не знаю, зачем хотеть более 10 потоков. Всякие внутренние цели можно передать в основном сообщении, потоки такого рода имеют смысл только для QoS, а реальный QoS такого рода никогда не использовал на моей памяти более 4 уровней приоритета (формально позволяется 8 — например, в 802.1p). Так что 10 — с головой и выше. O>>640КБ должно хватить каждому (с)
N>Аналогия некорректна. Память расширяется линейно, а каждый следующий уровень QoS это как следующий уровень абстракции в логике приложения: слишком много — запутаешься.
N>Ну и если вдруг захотелось побольше потоков — просто договорись с другой стороной, проблем-то.
O>>Чота мне ето число напомнило.. А.. вспомнил — вот че http://www.mydigitallife.info/half-open-outbound-tcp-connections-limit-removed-in-windows-7-and-vista-sp2-no-patch-required/
N>Ну и? Это ограничение вполне разумно, но надо было его более адекватно оформить и задокументировать.
N>В случае SCTP прошу привести реальный пример, когда было бы нужно более 10 потоков и это нельзя было бы решить тегом в отдельном сообщении.
Я не понимаю, почему здесь речь идет про QoS и приоритеты. Какое отношение они имеют к SCTP streams? Объясните, пожалуйста.
Я всегда считал, что первичное предназначение этого механизма — избежание HOLB. И для этой цели вполне может понадобиться довльно большое количество потоков.
Здравствуйте, Изя Рнет, Вы писали:
N>>В случае SCTP прошу привести реальный пример, когда было бы нужно более 10 потоков и это нельзя было бы решить тегом в отдельном сообщении. ИР>Я не понимаю, почему здесь речь идет про QoS и приоритеты. Какое отношение они имеют к SCTP streams? Объясните, пожалуйста. ИР>Я всегда считал, что первичное предназначение этого механизма — избежание HOLB. И для этой цели вполне может понадобиться довльно большое количество потоков.
Что такое HOLB?
Разделение на разные потоки в SCTP ценно только одним: в каждом потоке своё упорядочение сообщений и свои зависимости между ними, когда нежелательно, чтобы проблемы передачи в среде и приёма обработчиком влияли на другую группу сообщений. А это непосредственно стыкается с QoS.
Если HOLB — это head-of-line blocking, то множество потоков не является единственным или даже лучшим методом решения этой проблемы, всегда легче организовать адекватную буферизацию в userland.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Изя Рнет, Вы писали:
N>>>В случае SCTP прошу привести реальный пример, когда было бы нужно более 10 потоков и это нельзя было бы решить тегом в отдельном сообщении. ИР>>Я не понимаю, почему здесь речь идет про QoS и приоритеты. Какое отношение они имеют к SCTP streams? Объясните, пожалуйста. ИР>>Я всегда считал, что первичное предназначение этого механизма — избежание HOLB. И для этой цели вполне может понадобиться довльно большое количество потоков.
N>Что такое HOLB? N>Разделение на разные потоки в SCTP ценно только одним: в каждом потоке своё упорядочение сообщений и свои зависимости между ними, когда нежелательно, чтобы проблемы передачи в среде и приёма обработчиком влияли на другую группу сообщений. А это непосредственно стыкается с QoS.
Неа. Не стыкается. Есть логическая связь внутри группы сообщений и важен порядок их поступления — ок, это поток. Если есть другая группа сообщений, внутри которой есть порядок, но он не связан с порядком в первой, то это другой поток. Нет никаких причин, чтобы проблемы в первой группе влияли на вторую. И таких групп сообщений хоть миллион.
N>Если HOLB — это head-of-line blocking, то множество потоков не является единственным или даже лучшим методом решения этой проблемы, всегда легче организовать адекватную буферизацию в userland.
Да, head of line blocking. И буферизация не спасает. Пусть у нас в едет что-то массивное, а тем временем хочется послать что-нибудь мелкое. Вот чтобы мелкое не оттормозилось, пока едет большое, мелкое стоит послать отдельным потоком.
Здравствуйте, Изя Рнет, Вы писали:
N>>Что такое HOLB? N>>Разделение на разные потоки в SCTP ценно только одним: в каждом потоке своё упорядочение сообщений и свои зависимости между ними, когда нежелательно, чтобы проблемы передачи в среде и приёма обработчиком влияли на другую группу сообщений. А это непосредственно стыкается с QoS. ИР>Неа. Не стыкается. Есть логическая связь внутри группы сообщений и важен порядок их поступления — ок, это поток. Если есть другая группа сообщений, внутри которой есть порядок, но он не связан с порядком в первой, то это другой поток. Нет никаких причин, чтобы проблемы в первой группе влияли на вторую. И таких групп сообщений хоть миллион.
Теоретически — да. На практике миллион мне кажется ну совсем маловероятным; тысячи — можно при извращённом раскладе, но это можно заказать; в практически заметных случаях группа (поток) определяется приоритетом.
N>>Если HOLB — это head-of-line blocking, то множество потоков не является единственным или даже лучшим методом решения этой проблемы, всегда легче организовать адекватную буферизацию в userland. ИР>Да, head of line blocking. И буферизация не спасает. Пусть у нас в едет что-то массивное, а тем временем хочется послать что-нибудь мелкое. Вот чтобы мелкое не оттормозилось, пока едет большое, мелкое стоит послать отдельным потоком.
А почему хочется послать что-нибудь мелкое? Потому что оно важнее/срочнее? Тогда см. выше.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Изя Рнет, Вы писали:
N>>>Что такое HOLB? N>>>Разделение на разные потоки в SCTP ценно только одним: в каждом потоке своё упорядочение сообщений и свои зависимости между ними, когда нежелательно, чтобы проблемы передачи в среде и приёма обработчиком влияли на другую группу сообщений. А это непосредственно стыкается с QoS. ИР>>Неа. Не стыкается. Есть логическая связь внутри группы сообщений и важен порядок их поступления — ок, это поток. Если есть другая группа сообщений, внутри которой есть порядок, но он не связан с порядком в первой, то это другой поток. Нет никаких причин, чтобы проблемы в первой группе влияли на вторую. И таких групп сообщений хоть миллион.
N>Теоретически — да. На практике миллион мне кажется ну совсем маловероятным; тысячи — можно при извращённом раскладе, но это можно заказать; в практически заметных случаях группа (поток) определяется приоритетом.
Это был фигуральный "миллион" в смысле дофига
Что касается заметных случаев, то Главное Приложение, под которое и дизайнился SCTP на том и строится — нет смысла стоять и ждать прогресса в тех случаях, когда от того прогресса ничего не зависит, а можно действовать независимо.
N>>>Если HOLB — это head-of-line blocking, то множество потоков не является единственным или даже лучшим методом решения этой проблемы, всегда легче организовать адекватную буферизацию в userland. ИР>>Да, head of line blocking. И буферизация не спасает. Пусть у нас в едет что-то массивное, а тем временем хочется послать что-нибудь мелкое. Вот чтобы мелкое не оттормозилось, пока едет большое, мелкое стоит послать отдельным потоком.
N>А почему хочется послать что-нибудь мелкое? Потому что оно важнее/срочнее? Тогда см. выше.
Неа. Не важнее и не срочнее. Просто нет смысла ждать, пока пролезет толстое, если нет зависимости по порядку от него.
Здравствуйте, Изя Рнет, Вы писали:
ИР>>>Да, head of line blocking. И буферизация не спасает. Пусть у нас в едет что-то массивное, а тем временем хочется послать что-нибудь мелкое. Вот чтобы мелкое не оттормозилось, пока едет большое, мелкое стоит послать отдельным потоком. N>>А почему хочется послать что-нибудь мелкое? Потому что оно важнее/срочнее? Тогда см. выше. ИР>Неа. Не важнее и не срочнее. Просто нет смысла ждать, пока пролезет толстое, если нет зависимости по порядку от него.
Для этого вообще никакие потоки не нужны: флаг внеочередной, независимой от соседей доставки ставится независимо от номера потока.
— вот че http://www.mydigitallife.info/half-open-outbound-tcp-connections-limit-removed-in-windows-7-and-vista-sp2-no-patch-required/
