TCP/IP (компьютерное)

[avva]

1. А могли ведь, наверное (подумалось мне как-то недавно) внести в TCP встроенную возможность передавать много параллельных потоков по одному каналу. Самым простым и примитивным способом: ввести в заголовок TCP поле “номер потока”, размером в байт, например (256 потоков).
О, да кстати там и поле reserved в 6 бит есть, вижу (64 потока). Дать к номеру потока доступ на уровне сокетов или других интерфейсов с помощью соответствующих расширенных функций. И пусть те аппликации, кому удобно, используют. По умолчанию всегда будет один поток, нулевой.

Зачем это нужно и почему просто не открыть несколько TCP-соединений? Несколько соединений могут легко рассинхронизироваться и вообще пойти через разные раутеры даже. Несколько потоков в одном соединении будут ползти одним потоком с точки зрения самого TCP.

Предположим, мне нужно транслировать фильм по сети, чтобы на втором конце его могли проигрывать в realtime. Что сейчас делают? Используют формат, который мультиплексирует видео- и аудио-поток вместе, так, чтобы они были синхронизированы в общем потоке. Попеременно идут фреймы видео-аудио-видео-аудио (ясно, что удельный вес видео больше). Например, формат AVI, или MPEG, или новые OGM и Matroska. Но чем плохо было бы просто пустить фильм по TCP, пометив видео и аудио как разные потоки? Посылающая программа следила бы за синхронизацией, а сам протокол TCP обеспечивал бы тот факт, что они не рассинхронизируются по пути. И не нужен отдельный файловый формат.

Ещё, наверное, всякие примеры можно придумать.

P.S. Забыл упомянуть, что, собственно, весьма примитивная поддержка этого дела в TCP есть — но только двух потоков: обычного и "срочного" (с помощью urgent pointer). Этого, ясно, недостаточно, да и семантика тут чуть другая. Я вообще-то не знаю, пользуется ли кто-то серьёзно этими самыми urgent-данными в TCP (кажется, telnet пользуется для чего-то там — и больше никого не знаю).

2. Наивный немного вопрос: а что там вообще происходит с IPv6, кто-то следит за этим делом? А то я уже, наверное, лет восемь слышу разговоры о том, что у нас вот-вот кончатся 32-битные адреса, и что мы вот-вот перейдём все на IPv6. Тем временем адреса вроде бы не кончаются (или кончаются всё-таки?) и на IPv6 мы не переходим. В каком состоянии вообще всё это находится?

Comments

[mkay422.livejournal.com]

Строго говоря, это уже будет протокол более высокого уровня (app.-level protocol). С другой стороны, такие протоколы уже есть реализованные (прячу хитрую ухмылку).

Необходимо также учитывать, что открытие множественных ТСР-сессий может быть предпочтительнее в ряде ситуаций, т.к. каждая сессия регулирует свой размер окна независимо от других.

[cmm.livejournal.com]

> уже, наверное, лет восемь слышу разговоры о том, что у нас вот-вот кончатся 32-битные адреса, и что мы вот-вот перейдём все на IPv6. Тем временем адреса вроде бы не кончаются (или кончаются всё-таки?)

рынок регулировал-регулировал, и нарегулировал ситуацию, в которой куча народу сидит за NAT-router'ами и не жужжит.  IPv6 может особо не торопиться, насколько я понимаю.
перспектива тоже не видится мне ужасной: NAT-routing, насколько я опять же понимаю, допускает многоуровневое вложение.

[xfyre.livejournal.com]

http://www.icann.org/announcements/announcement-20jul04.htm

[dbg.livejournal.com]

1. Изобретен и кое-где уже реализован SCTP (RFC 2960, RFC 3286)
2. В довольно медленном. Адреса действительно не кончаются, да в IPv6 есть нерешенных проблем.

[xfyre.livejournal.com]

в статье в компьютерре, через которую я и нашел эту ссылку, также говорится, что ICANN планирует полностью перевести сеть на IPv6 через 20 лет. откуда они взяли эту информацию - не знаю.

[auto194419.livejournal.com]

про ipv6 - http://www.technologyreview.com/articles/print_version/wo_garfinkel010704.asp

а всё живо из-за проклятого NAT'а. если бы не он, давно бы адреса кончились.

[avva.livejournal.com]

Строго говоря, это уже будет протокол более высокого уровня

Сегодня - да, но я как раз предлагаю "спустить" эту возможность на transport layer, путём внесения её в сам протокол TCP.

Необходимо также учитывать, что открытие множественных ТСР-сессий может быть предпочтительнее в ряде ситуаций, т.к. каждая сессия регулирует свой размер окна независимо от других.

Да, это понятно.

[trurle.livejournal.com]

А почему, собственно, мультиплексирование потока данных должно поддерживаться на уровне IP пакета если вполне можно сделать на уровне транспортного протокола?

[avva.livejournal.com]

Я и предлагаю - на уровне транспортного протокола TCP, а вовсе не на уровнр IP-пакета. Ты невнимательно читаешь.

[growler.livejournal.com]

SCTP? (http://www.ietf.org/rfc/rfc2960.txt)

[avva.livejournal.com]

1. Ух, какая интересная штука! спасибо, читаю ;)

[avva.livejournal.com]

Ага, уже подсказали. Выглядит аппетитно.

[trurle.livejournal.com]

Я имел в виду уровнем выше, там где находится, скажем, HTTP.
Использование бита TCP пакета предполагает что надо изменить все TCP стеки, а это нереально. Выигрыш же в количестве передаваемых данных относительно мал.

[avva.livejournal.com]

Не совсем; поведение стека менять не нужно, только интерфейс к нему. Стек будет игнорировать это дополнительное поле, и только нужно передавать его аппликации, а она сама интерпретирует. Для того, чтобы не нужно было менять даже структуры заголовка, можно использовать reserved поле или поле TCP-опций (см. структуру заголовка TCP, самое последнее поле перед padding в конце; там есть расширяемые опции).

Я полагаю, что понятие мультиплексирования потоков достаточно общее, чтобы не нужно было заставлять разные application-level protocols его пере-изобретать и пере-воплощать.

[avva.livejournal.com]

Мне это понравилось: "This next generation version of the Internet Protocol provides trillions more addresses than the IPv4 system that is in use by most networks today."

Т.е. технически это верно, конечно, "триллионы" новых адресов. Очень-очень много триллионов... ;)

[avva.livejournal.com]

Ах, какой противный рынок, тормозит наш технический прогресс ;)

[growler.livejournal.com]

А гнездо у него тут (http://www.sctp.org/). И там же список (http://www.sctp.org/implementations.html) реализаций.

Курица и яйцо

[trurle.livejournal.com]

Во всех интересных системах TCP/IP стек сидит в ядре ОС, доступ к TCP/IP функциональности осуществляется через системные вызовы, обернутые в API, как правило, sockets. Использование для мультиплексации дополнительного бита предполагает изменения в ядрах систем, аргументах системных вызовов и т.д.
Даже если пренебречь сушествующими компьютерами, внедерение мультиплексирования на уровне битов TCP пакета требует от производителей ОС поддерживать протокол для которого нет аппликаций, а разработчиков аппликаций - использовать протокол который еще не поддерживается ОС.

[dimrub.livejournal.com]

многоуровневое вложение - да, конечно допускает. Проблемы будут у нас когда вовсю начнет внедряться сотовые 3-го поколения, где каждый телефон - IP-device. Как там с NAT - не совсем понятно. При роуминге, например, чей IP у них будет? Родной - или принимающей сети?

[ktyz.livejournal.com]

слишком мало холодильников с выходом в тырнет сделали,
вот и весь вопрос.

[cmm.livejournal.com]

ага, большим невидимым тормозом.

[109.livejournal.com]

зачем изменения? дополнения. blablablaEx, как обычно.

Курица и яйцо

эта проблема всегда стоит.

[cmm.livejournal.com]

проблемы с телефонами те же, что и с обычными компутерами за NAT'ом.  то есть сервера на телефонах, видимо, гонять будет несколько затруднительно.
а для клиентского режима хватит одного IP-адреса на сеть, да.

[stas]

Я так думаю, IP будет принимающей сети, а ID - родной. ID в IP и будет роумер переводить. А уж как они это раутить будут с друг другом - на то есть соотв. протоколы, я думаю. Т.е. за реальные телефоны отвечать не могу, но это самый логичный выход. Интересно, угадал ли я :)

[trurle.livejournal.com]

Не все люди столь же нечистоплотны как рабы империи зла.