| 1.1, _Nick_ (??), 09:38, 06/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 сильный велосипед
жаль полнота внедрения как обычно заступриццо на мс. пока оно не созреет внедрить этот протокол (не нада матов. четал, все есть и под венду. речь о том, что это пока что сторонний драйвер и всеобщая серая масса вендузятников и не думают даже что есть что-либо кроме TCP ...даже если об этом думают) и еще лучше как "рекомендуемый" и по умолчанию активный.
А до этого такая сильная наработка - лишь инструмент юниксоидов. | | |
| 1.3, Аноним (-), 23:09, 06/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>>всеобщая серая масса вендузятников и не думают даже что есть что-либо кроме TCP<<
ну почему же, мы еще UDP знаем ... А вот вас на что-то большее, чем "венда" и "вендузятники" явно не хватило ... | | |
| |
| 2.4, _Nick_ (??), 23:23, 06/03/2006 [^] [^^] [^^^] [ответить]
| +/– | |
это не нас, а дядю билли хватило
нащет UDP - это сила (если знаете....) | | |
|
| 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 в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.
| | |
|
