О, да кстати там и поле 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 мы не переходим. В каком состоянии вообще всё это находится?
← Ctrl ← Alt
Ctrl → Alt →
← Ctrl ← Alt
Ctrl → Alt →