URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 13685
[ Назад ]

Исходное сообщение
"OpenNews: Рассказ про протокол SCTP и примеры использования."

Отправлено opennews , 06-Мрт-06 09:38 
В статье "Better Networking with SCTP (http://www-128.ibm.com/developerworks/linux/library/l-sctp/)" рассказано о новом транспортном протоколе SCTP (Stream Control Transmission Protocol), поддержка которого присутствует в Linux ядре 2.6.  Кроме того, в статье разбираются два небольших сетевых приложения на Си (клиент и сервер), использующих возможности SCTP по многопоточной передаче данных.


URL: http://www-128.ibm.com/developerworks/linux/library/l-sctp/
Новость: http://www.opennet.me/opennews/art.shtml?num=7061


Содержание

Сообщения в этом обсуждении
"Рассказ про протокол SCTP и примеры использования."
Отправлено _Nick_ , 06-Мрт-06 09:38 
сильный велосипед

жаль полнота внедрения как обычно заступриццо на мс. пока оно не созреет внедрить этот протокол (не нада матов. четал, все есть и под венду. речь о том, что это пока что сторонний драйвер и всеобщая серая масса вендузятников и не думают даже что есть что-либо кроме TCP  ...даже если об этом думают) и еще лучше как "рекомендуемый" и по умолчанию активный.

А до этого такая сильная наработка - лишь инструмент юниксоидов.


"Рассказ про протокол SCTP и примеры использования."
Отправлено CSRedRat , 28-Сен-12 16:42 
В .NET Framework 4 есть поддержка SCTP.

"Рассказ про протокол SCTP и примеры использования."
Отправлено Akademic , 06-Мрт-06 14:23 
Красивая штука. При использовании можно получить много хороших вещей.

"Рассказ про протокол SCTP и примеры использования."
Отправлено Аноним , 06-Мрт-06 23:09 
>>всеобщая серая масса вендузятников и не думают даже что есть что-либо кроме TCP<<
ну почему же, мы еще UDP знаем ... А вот вас на что-то большее, чем "венда" и "вендузятники" явно не хватило ...

"Рассказ про протокол SCTP и примеры использования."
Отправлено _Nick_ , 06-Мрт-06 23:23 
это не нас, а дядю билли хватило

нащет UDP - это сила (если знаете....)


"Рассказ про протокол SCTP и примеры использования."
Отправлено Diesel_power , 07-Мрт-06 11:10 
Да, согласен, красивая штука, особенно Multi-homing.

"Рассказ про протокол SCTP и примеры использования."
Отправлено Дмитрий Карпов , 07-Мрт-06 13:24 
Честно говоря, совершенно не впечатлило. Лично я ожидал о транспортного протокола следующее:
- Компрессия и шифрация на транспортном уровне с возможностью приложения влияния на это.
- Возможность избыточности данных, позволяющих восстанавливать потерянные/попорченные пакеты без перезапроса отправителя (допустим, на каждые десять пакетов одинакового размера посылается одинадцатый, содержащий XOR предыдущих десяти).
- Встроенная функциональность, аналогичная SOCKS, когда нет проблем типа "маскарадинг плохо обслуживает FTP в пассивном режиме клиента". А тут даже неизвестно, насколько хорошо будет маскарадиться этот SCTP.
- Точное указание использу

"Рассказ про протокол SCTP и примеры использования."
Отправлено _Nick_ , 07-Мрт-06 14:08 
>Честно говоря, совершенно не впечатлило. Лично я ожидал о транспортного протокола следующее:
>- Компрессия и шифрация на транспортном уровне с возможностью приложения
> влияния на это.
увы... единственное Ваше толковое замечание. Эти вещи действительно неплохо бы смотрелись в любом протоколе.

>- Возможность избыточности данных, позволяющих восстанавливать потерянные/попорченные пакеты без перезапроса отправителя (допустим,
>на каждые десять пакетов одинакового размера посылается одинадцатый, содержащий XOR предыдущих
>десяти).
ЛОЛ. вот здесь смеялсо %) причем сильно. не пацталом, но шото вроде.
1. для кого придумана контрольная сумма на случай "битых" пакетов с последующей ретрансмиссией оных?
2. потерянные пакеты - это проблемы в сети. Если так - то любая избыточная информация - это лишние потери и проблеы для протокола (лишние задержки, что не гуд)
3. Если, допустим, SCTP пакет будет ехать фреймами по 1500 байт (обычный езернет юзаем). Таких фреймов прошло 10. То.... НАХРЕНА ТАКОЙ КОНТРОЛЬНЫЙ??
СМЫСЛ в таком протоколе (даже если это опциональная фича, то нахрена такая фича), если скорость его вдвое меньше пропускной канала??

>- Встроенная функциональность, аналогичная SOCKS, когда нет проблем типа
> "маскарадинг плохо обслуживает FTP в пассивном режиме клиента".
гы. а как бы тебе встроенная функциональность "первые 200 метров SCTP коннекта - халявная порнуха"? ;) то же самое.
Нужно чуток различать что есть задачей какого уровня OSI модели (хотя фича multi-home - тоже прикурена па чужой уровень)

> А тут даже неизвестно, насколько хорошо будет маскарадиться этот SCTP.
че ж неизвестно?? Linux сырцы глянь (как минимум). Там все уже есть и чудно
маскарадит.

- Точное указание используемого протокола (номер порта как-то не очень удобен).
Все уже съедено до нас.
Выдохни. Смотри файл /etc/services и функцию getservbyname(3).


"Рассказ про протокол SCTP и примеры использования."
Отправлено Дмитрий Карпов , 07-Мрт-06 13:25 
Добавляю обрезанное CGI-скриптом:
- Точное указание используемого протокола (номер порта как-то не очень удобен).

"для непонимающих"
Отправлено Дмитрий Карпов , 03-Июл-06 16:20 
> для кого придумана контрольная сумма на случай "битых" пакетов с последующей ретрансмиссией оных?

Дело в том, что далеко не во всех случаях возможна/удобна повторная пересылка данных. В частности, в реалтаймовом трафике (управление реальными устройствами, мультимедия, VoIP) повторная пересылка приводит к большим задержкам.

> потерянные пакеты - это проблемы в сети. Если так - то любая избыточная информация - это лишние потери и проблеы для протокола (лишние задержки, что не гуд)

Пересылаемые повторно пакеты - тоже избыточная информация.

> Нужно чуток различать что есть задачей какого уровня OSI модели

SOCKS и NAT/Masquerading работают как раз на четвёртом уровне модели OSI.

> Смотри файл /etc/services

Это просто сопоставление имён протоколов и номеров портов. При этом ни клиент, обращаясь по определённому порту, не м.б. уверен, что там его ждёт программа, обслуживающая нужный клиенту протокол.


"для непонимающих"
Отправлено KHNP , 09-Ноя-06 12:33 
> SOCKS и NAT/Masquerading работают как раз на четвёртом уровне модели OSI.
NAT на четвертом уровне? С каких пор?
Опишите в таком случае схему прохождения icmp-пакета :)

"для непонимающих"
Отправлено Хелагар. , 01-Июл-08 17:38 
>> для кого придумана контрольная сумма на случай "битых" пакетов с последующей ретрансмиссией оных?
>
>Дело в том, что далеко не во всех случаях возможна/удобна повторная пересылка
>данных. В частности, в реалтаймовом трафике (управление реальными устройствами, мультимедия, VoIP)
>повторная пересылка приводит к большим задержкам.

Друх мой. Не обижайтесь, но я искренне рекомендую Вам покурить какой-нибудь учебник по сетевым технологиям.
Там Вы найдете для себя ответ на 2 вопроса:
1)"почему все говорят, что я тут сморозил глупость".
2)"как обеспечить передачу этого самого реалтаймового трафика"

>> потерянные пакеты - это проблемы в сети. Если так - то любая избыточная информация - это лишние потери и проблеы для протокола (лишние задержки, что не гуд)
>
>Пересылаемые повторно пакеты - тоже избыточная информация.

Но они пересылаются ТОЛЬКО в случае потери.
В предлагаеммом Вами варианте оно будет пересылаться ВСЕГДА.
Что, кстати, убьёт на корню возможность передачи чего-то реалтаймового.
Если разговор не идёт, конечно, о реал-тайм отслеживании движения материков. С точностью не более миллиметра.
Потому как большая часть полосы уйдёт на технические нужды.

>> Нужно чуток различать что есть задачей какого уровня OSI модели
>
>SOCKS и NAT/Masquerading работают как раз на четвёртом уровне модели OSI.
>
>> Смотри файл /etc/services

Вообще-то НАТ у нас работает на 3-ему уровне ОСИ, а не на четвёртом.


>Это просто сопоставление имён протоколов и номеров портов. При этом ни клиент,
>обращаясь по определённому порту, не м.б. уверен, что там его ждёт
>программа, обслуживающая нужный клиенту протокол.

Опять таки, это задача не того уровня модели ОСИ. И это уже решено. Например, см. RPC.


"SCTP в массы!"
Отправлено CSRedRat , 20-Дек-11 08:24 
Давно пора продвигать данный протокол повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.