NetCat for voice/video talk?

[jayrandom]

Вспомнить старое доброе интернетское прошлое. В Юниксе всё должно элегантно составляться из кубиков, даже сетевые операции.

А ведь тот же NetCat продолжает работать. И можно с его помощью запросто засервить файл или двусторонне пообщаться текстом, как и 15-20 лет назад. Вспомнить команды разделения канала (о) и (оо).

Кстати, а почему только текстом? Почему бы не наложить на простой и незамысловатый сокет передачу звука прямо из микрофона? Что-нибудь в духе двух строчек (симметрично):

        Alice$   cat /dev/mic | nc -l 12345

        Bob$     nc alice.org 12345 > /dev/audio

Ну или совсем сурово:

        Alice$   cat /dev/webcam | mpeg_compress | nc -l 12345

        Bob$     nc alice.org 12345 | mpeg_decompress | mpeg_player -

Прибавить сюда SSH-шифрование канала на лету.
И тогда Скайп может спокойно гулять лесом :)

Comments

[sanmai]

Если есть прямой IP.

Skype работает через маскарадинг и не только.

[jayrandom.livejournal.com]

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

Но интересно (просто как proof-of-concept) было бы провести видео-конференцию, собрав софт из лёгких узкоспециализированных компонентов: отдельно аудио- и видео capture, отдельно запаковка и распаковка, отдельно сетевая передача, отдельно воспроизведение. Соединить всё вместе и насладиться.

[azgar.livejournal.com]

В принципе, нчиего невозможного и даже особенно сложного не должно быть.

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

В общем, в идеальном мире хорошо.
Как любой концепт :)

[jayrandom.livejournal.com]

(а) Сжатие никто не отменяет. Пожалуйста, пакуй себе на здоровье, как показано в примере с видео.

(г) А представь себе, что P2P слой доставки с маскарадами, внутренним рутингом и прочими добавками хорошо отделён от завязки на доставляемый контент. В такой сервер/клиент пайпить чистые данные, а они уже сами на своём слое разберутся, как доставлять.

(б+в) это да, хотя и тут можно подумать.

В сущности (б+в) упирается в то, что в шеллах не предусмотрена возможность устраивать между связанными потоками цепей обратной связи. Если бы это было реализовано на уровне шеллов, слой передачи данных мог бы этой самой обратной связью "подправлять" выходной битрейт запаковщика. Или источника данных. Или... это было бы целое измерение. И если бы оно возникло *до* X11, я думаю, что программирование сейчас выглядело бы совсем по-другому.

[azgar.livejournal.com]

Сжатие выгодно производить как можно ближе к железке.
Самое смешное будет, если железка (общается с системой уже пожатыми данными)|(может отдавать данные в нужном пожатом формате). А их, данные, для совместимости станут распаковывать а потом опять запаковывать.

Отдельный канал управляющих данных к любому датастриму это было бы интересно. Только нужно выдумать формат управляющих данных, стандартизировать и повесить автора.

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

[jayrandom.livejournal.com]

Вот-вот. А *должно* быть возможно их сшивать на высоком уровне. Потому что тогда можно воротить всякие интересные штуки, которые без этого воротить нельзя.

Примеры того, как это делается, можно увидеть в AppleScript'e. Мне очень нравится идея, что любая программа - это не чёрный ящик, а серый ящик, который можно подёргать за заранее оговоренные протоколом ножки. Таким образом, даже самой GUIёвой программой можно управлять со стороны, посылая ей сообщения и получая ответы. Т.е. её можно скриптовать, и поддержка этого скриптования сделана на уровне опсистемы (а не каждой программы отдельно, как в Эмаксе и пр.).

А скрипт - это язык программирования самого высокого уровня (выше - интерактивный человек). Писать на нём новую функциональность неудобно и неэффективно, а соединять уже написанное - с превеликим удовольствием.

[azgar.livejournal.com]

Концептуально, пайпы это слишком низкий уровень, чтобы на нём были накручены управляющие потоки.
Это, как раз, самый низкий уровень общения между процессами, ниже некуда.
Гуёвые опсистемы, на сколько я знаю, многие в большей или меньшей степени предоставляют возможность слать другим процессам или их ресурсам сообщения. Которые, опять же, более или менее стандартны. Хотя, не все и не на всё обязаны адекватно реагировать.
Гуёвая платформа это очень мощная сила. В плане энфорса сложных стандартных интерфейсов.
А интерфейс процесса в *нихах, наоборот, очень прост. Договорились о стдин, стдаут и стдерр, плюс пятнадцать сигналов и фсё (?).
Вот и поди организуй передачу от сетевого интерфейса на камеру сигнала "а снизь-ка ты мне, брат, разрешение".
Конечно, на самом деле будет проще, сеть говорит запаковщику "не пролезает!", запаковщик камере "режь частоту кадров" или как-то так. Но это всё надо срастить и стандартизировать. Ты ж понимаешь, какой это гмрй. Как всегда кому-то потребуется фича, которой в стандарте нету, начнутся расширения, нахлабучки, в пайп придётся вставлять конвертеры управляющих протоколов, ...
Но самое обидное, что нужно это всё только отдельным нетипичным элементам вроде нас с тобой :)

[jayrandom.livejournal.com]

Когда это работает, это нужно всем. А поскольку не работает, то все привыкли, что этого не нужно и хотеть :)

[azgar.livejournal.com]

Обычные паровозы на командной строке замечательно работают.
Но, увы нам, увы, нужны они далеко не всем :)
Более того, большинство о них вообще не знает.

[jayrandom.livejournal.com]

Кому надо - тот знает. Кому не надо - от того и не зависит :)