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

Ответить | Сообщить модератору