The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Рассказ про протокол SCTP и примеры использования.

05.03.2006 21:30

В статье "Better Networking with SCTP" рассказано о новом транспортном протоколе SCTP (Stream Control Transmission Protocol), поддержка которого присутствует в Linux ядре 2.6. Кроме того, в статье разбираются два небольших сетевых приложения на Си (клиент и сервер), использующих возможности SCTP по многопоточной передаче данных.

  1. Главная ссылка к новости (http://www-128.ibm.com/develop...)
  2. Перевод RFC 3286. Введение в SCTP
  3. SCTP: новый транспортный протокол для TCP/IP
  4. RFC 3286 - Introduction to the Stream Control Transmission Protocol (SCTP).
Лицензия: CC-BY
Источник: osnews.com
Тип: английский / Справочная информация
Ключевые слова: tcp, socket, ip, stream, sctp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (13) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, _Nick_ (??), 09:38, 06/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сильный велосипед

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

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

     
     
  • 2.20, CSRedRat (ok), 16:42, 28/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В .NET Framework 4 есть поддержка SCTP.
     

  • 1.2, Akademic (??), 14:23, 06/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Красивая штука. При использовании можно получить много хороших вещей.
     
  • 1.3, Аноним (-), 23:09, 06/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>всеобщая серая масса вендузятников и не думают даже что есть что-либо кроме TCP<<
    ну почему же, мы еще UDP знаем ... А вот вас на что-то большее, чем "венда" и "вендузятники" явно не хватило ...
     
     
  • 2.4, _Nick_ (??), 23:23, 06/03/2006 [^] [^^] [^^^] [ответить]  
  • +/
    это не нас, а дядю билли хватило

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

     

  • 1.5, Diesel_power (?), 11:10, 07/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да, согласен, красивая штука, особенно Multi-homing.
     
  • 1.6, Дмитрий Карпов (?), 13:24, 07/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Честно говоря, совершенно не впечатлило. Лично я ожидал о транспортного протокола следующее:
    - Компрессия и шифрация на транспортном уровне с возможностью приложения влияния на это.
    - Возможность избыточности данных, позволяющих восстанавливать потерянные/попорченные пакеты без перезапроса отправителя (допустим, на каждые десять пакетов одинакового размера посылается одинадцатый, содержащий XOR предыдущих десяти).
    - Встроенная функциональность, аналогичная SOCKS, когда нет проблем типа "маскарадинг плохо обслуживает FTP в пассивном режиме клиента". А тут даже неизвестно, насколько хорошо будет маскарадиться этот SCTP.
    - Точное указание использу
     
     
  • 2.8, _Nick_ (ok), 14:08, 07/03/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Честно говоря, совершенно не впечатлило. Лично я ожидал о транспортного протокола следующее:
    >- Компрессия и шифрация на транспортном уровне с возможностью приложения
    > влияния на это.
    увы... единственное Ваше толковое замечание. Эти вещи действительно неплохо бы смотрелись в любом протоколе.

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

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

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

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

     

  • 1.7, Дмитрий Карпов (?), 13:25, 07/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Добавляю обрезанное CGI-скриптом:
    - Точное указание используемого протокола (номер порта как-то не очень удобен).
     
  • 1.16, Дмитрий Карпов (?), 16:20, 03/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > для кого придумана контрольная сумма на случай "битых" пакетов с последующей ретрансмиссией оных?

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

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

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

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

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

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

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

     
     
  • 2.17, KHNP (?), 12:33, 09/11/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > SOCKS и NAT/Masquerading работают как раз на четвёртом уровне модели OSI.
    NAT на четвертом уровне? С каких пор?
    Опишите в таком случае схему прохождения icmp-пакета :)
     
  • 2.18, Хелагар. (?), 17:38, 01/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> для кого придумана контрольная сумма на случай "битых" пакетов с последующей ретрансмиссией оных?
    >
    >Дело в том, что далеко не во всех случаях возможна/удобна повторная пересылка
    >данных. В частности, в реалтаймовом трафике (управление реальными устройствами, мультимедия, VoIP)
    >повторная пересылка приводит к большим задержкам.

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

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

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

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

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


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

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

     

  • 1.19, CSRedRat (ok), 08:24, 20/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давно пора продвигать данный протокол повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру