TCP/IP (компьютерное)
Aug. 23rd, 2004 10:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva1. А могли ведь, наверное (подумалось мне как-то недавно) внести в 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 мы не переходим. В каком состоянии вообще всё это находится?
О, да кстати там и поле 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 мы не переходим. В каком состоянии вообще всё это находится?
no subject
Date: 2004-08-23 01:38 pm (UTC)Там совершенно ни к чему иметь фиксированный и неизменный IP-адрес.
Адресация осуществляется по другим параметрам через SIP-регистратор-локатор.
Более того, им совершенно не обязательно в мире иметь адреса, различные от провайдоровского SIP-proxy. Что скорее всего и будет делаться в целях биллинга.
no subject
Date: 2004-08-23 01:40 pm (UTC)no subject
Date: 2004-08-23 01:58 pm (UTC)Но что я уяснил попав случайно с месяц назад на сайт 3G комитета (какого из двух -- не помню) -- это то, что 3G делается на основе SIP. Ну где про SIP читать -- не проблема. Хоть с www.vovida.org.
Про проксю -- это уже мои домыслы-компиляции на основе наблюдения за рынком VoIP и проблем с тарификацией (точнее с проблемой точного определения момента окончания разговора между клиентами двух провайдеров -- если они законектились напрямую, то теоретически они могут послать на гейткипер сообщение о дисконекте но продолжать болтать).
no subject
Date: 2004-08-23 02:42 pm (UTC)no subject
Date: 2004-08-23 03:02 pm (UTC)Когда звуковой поток гонится напрямую с клиент1-IP на клиент2-IP, проходя только через роутеры.
> То есть, этот прокси может быть прозрачным, и сидеть на каком-нибудь раутере по дороге.
Ну в данном случае это не принципиально. Что в лоб, что по лбу -- произойдет подмена адреса клиента на адрес роутера. А клиенты при этом спокойно могут вариться в сетке 10.x.x.x