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

TCP непригоден для передачи media

[sysprg.livejournal.com]

Про SCTP Вам уже написали, про вредность связывания аудио и видео - тоже: человек плохо реагирует на проблемы со звуком (рывки, пропадания звука), но легко переносит пропуск нескольких видеокадров. Добавлю, что для передачи кино и звука в реальном времени обычно используют не TCP, а RTP (протокол прикладного уровня, бегущий поверх UDP). Дело в том, что все современные аудио- и видеокодеки умеют восстанавливаться после потери отдельных кадров, а некоторые из них даже интерполируют данные для эмуляции потерянных кадров, поэтому они мало чувствительны к небольшим потерям. Кроме того, для RTP разработаны эффективные схемы FEC (Forward Error Correction) для восстановления информации в случае потери нескольких кадров в потоке. Таким образом, для аудио- и видеоданных ЗАДЕРЖКИ на приемнике намного страшнее, чем пропадание отдельных кадров. Иногда задержки страшнее, чем даже потеря 20-30% информации. TCP же приостанавливает работу столкнувшись с пропажей даже одного-единственного байта, до тех пор, пока этот байт не будет доставлен. Поэтому, TCP принципиально не подходит для передачи мультимедийной информации в реальном времени.