Андрей Сидоров представил (http://permalink.gmane.org/gmane.comp.lang.javascript.nodejs...) проект vnc-over-gif (https://github.com/sidorares/vnc-over-gif), в рамках которого подготовлен работающий в браузере VNC-просмотрщик, использующий для отображения содержимого удалённого рабочего стола поток в виде анимированного GIF-изображения. Данные передаются в форме непрерывного потока, а не отдельных файлов, что потребовало внесение изменения в библиотеку для формирования анимированных GIF.Код серверной части, транслирующей вывод от VNC-сервера, написан на JavaScript и работает под управлением Node.js. На стороне клиента для просмотра сеанса рабочего стола достаточно поддержки анимированных GIF-изображений (следует открыть ссылку вида http://localhost:4455/screen.gif?host=хост&port=5900&password=пароль), т.е. поддерживаются браузеры начиная с выпущенного в 1995 году Netscape Navigator 2.0.
URL: http://www.theregister.co.uk/2013/05/27/dev_releases_vnc_ove.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=37020
Тяжеловато наверное... Переписывать на С будут?
Бойян - у нас такое работает аж с 2006 году. Не GPL и не опен соурс. ФСБ Private License :)Кстати в двух вариантах: один GIF или pJPEG с задаваемой в реалтайме частотой.
Ессесенно шифрование по 89 или 2004 ГОСТам, можно SSL/DES/AES врубить.
Более того, VNC это всего лишь один из вариантов транспорта, дамп экрана
снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,
прям в езернет/ip/http фреймы. А еще есть вариант JPEG-diff - отсылаются
только изменения от предыдущего фрейма, обратная сборка перекладывается на клиента.
Да ты крутой!
> Да ты крутой!Потому, что Гладиолус!
> Бойян - у нас такое работает аж с 2006 году. Не GPL
> и не опен соурс. ФСБ Private License :)
> Кстати в двух вариантах: один GIF или pJPEG с задаваемой в реалтайме
> частотой.
> Ессесенно шифрование по 89 или 2004 ГОСТам, можно SSL/DES/AES врубить.
> Более того, VNC это всего лишь один из вариантов транспорта, дамп экрана
> снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,
> прям в езернет/ip/http фреймы. А еще есть вариант JPEG-diff - отсылаются
> только изменения от предыдущего фрейма, обратная сборка перекладывается на клиента.А что ж вы не пользуетесь легендарной сетевой прозрачностью иксов, про которую нам прожужжали все уши?
> А что ж вы не пользуетесь легендарной сетевой прозрачностью иксов, про которую
> нам прожужжали все уши?Винды ж, небось.
> снимается прям в ядре с устройства. Можно пихать эти дампы сплющенные LZMA,Можно. Только LZMA тормозной при сжатии и проц озадачится конкретно.
т.е. нельзя, на практике. И не даст оно сильно большого прироста сжатия на таких объёмах
> т.е. нельзя, на практике.Ну я саркастично намекнул павлину что ему не понравится нагрузка на проц :). Если ему делать нех - пусть zpaq жмет. Сжатие будет одно из лучших в мире. А то что там скорость сжатия полметра в час - да подумаешь, эка невидаль...
> Бойян - у нас такое работает аж с 2006 году. Не GPL и не опен соурс. ФСБ Private License :)Под Win, что ли. Такие только ей давали. Не может это работать.
Проговорился.
ну это не удивительно, все гос. учреждения просто кладезь идиотизма.
итак езернет-фреймы, ip, или http? че вы теплое с мягким перепутали в стремлении показать как оно там у вас огого..
Крутая штука! Жалко только, что только посмотрщик. Но это дело времени. Так держать!!)))
Изображение можно сделать фоновым и регистрировать клики и перемещение курсора на стороне пользователя.
> Изображение можно сделать фоновым и регистрировать клики и перемещение курсора на стороне пользователя.Ждём новостей!
* На основе бblдло-хаб-лицензированного node.js просмотрщика выпущен полнофункцианальный конкурент teamviewer-а
* Зарегистрированы первые взломы клиетов нового полнофункционального...
* Обнаружен троян, имитирующий тимвьюер, на основе полнофункционального...
* Новые еженедельные уязвимости: ..., диирки в коде обработки gif полнофункционального...
> * На основе бblдло-хаб-лицензированного node.js просмотрщикаПоправочка: бblдло-MIT-лицензированного
vnc-over-gif / package.json
2 contributors
file 31 lines (30 sloc) 0.597 kb
1 {
2 "name": "vnc-over-gif",
3 "version": "0.0.2",
4 "description": "vnc over gif server",
[...]
24 "license": "MIT",
Ты-то сам хоть что-нибудь написал?
> Ты-то сам хоть что-нибудь написал?Много постов на опеннет.
---24 "license": "Alright reserved",
>> Ты-то сам хоть что-нибудь написал?
> Много постов на опеннет.
> ---24 "license": "Alright reserved",Однажды Мастер Фу сказал заезжему программисту: "В одной строке кода shell-сценария больше духа Unix, чем в десяти тысячах строк на языке С!"
Программист, гордый своими познаниями в С, ответил: "Может ли быть такое? Ведь С — язык, в котором реализовано само ядро Unix!"
На это Мастер Фу ответил: "Это так. Тем не менее, в одной строке shell-сценария больше духа Unix, чем в десяти тысячах строк С!"
Программист выглядел удрученным. "Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!"
Мастер Фу сказал: "То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа Unix, чем в десяти тысячах строк С".
Это был не мастер Фу. Это, вероятно, был FUBAR.
> Это был не мастер Фу. Это, вероятно, был FUBAR.На Форумк Опеннет обнаружен Аноним-самозванец, не чтящий классику.
смотри-ка... походу привинтить к костылям костыли много желающих.
ЭВМ - это костыли для тех, кто не осилил счеты. Очевидно, что среди пользователей ЭВМ одни любители костылей.
> ЭВМ - это костыли для тех, кто не осилил счеты. Очевидно, что
> среди пользователей ЭВМ одни любители костылей.Ты не считаешь костылями гонять по сети битмапы?
> Ты не считаешь костылями гонять по сети битмапы?В конечном итоге, картинка с десктопе - это неизбежно битмап :). Просто передавать его можно по разному. Можно и крайне субоптимально. Вот gif с его 256 цветов и неважной степенью сжатия - знатный костыль.
Между прочим, в прошивках дешёвеньких IP-камер D-Link есть фича - они умеют отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров по Server-Push :) т.е. работает в Firefox. А в Chrome кстати есть серверпуш?
у меня zoneminder так с одной китайской камеры поток снимает :)
> отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадровЭто mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.
>> отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров
> Это mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к
> качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый
> кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.Для систем наблюдения - MJPEG гораздо лучше, чем "более эффективные" кодеки. Банально потому что каждый кадр никак не зависит от качества обработки предыдущих, не теряются мелкие детали.
>>> отдавать то ли "MJPEG", то ли "MPNG" с помощью бесконечной отдельных кадров
>> Это mjpeg. Он есть. Но он отличается хреновой эффективностью соотношением траффика к
>> качеству картинки. Потому что даже дельта-компрессии между кадрами - нет, каждый
>> кадр передается целиком. Соотношение битрейт/качество при этом ни к черту.
> Для систем наблюдения - MJPEG гораздо лучше, чем "более эффективные" кодеки. Банально
> потому что каждый кадр никак не зависит от качества обработки предыдущих,
> не теряются мелкие детали.Всего ничего - звука только нету.
> Всего ничего - звука только нету.И соотношение битрейт/качество ни к черту. Так что или видеонаблюдать 320x240x5FPS, или качество сжатия ставить "ой, а что это за квадратики?", или оно канал забьет. Видеопотоком это недоразумение можно считать весьма условно.
> не теряются мелкие детали.Они теряются по другой причине: чтобы пролезло через имеющийся бандвиз, вы или завинчиваете уровень сжатия, или получаете офигенное слайдшоу упирающееся даже на довольно жирном канале в его бандвиз.
Поэтому получить качественную картинку высокого разрешения с отображением деталей и без искажений - это вообще совсем не про mjpeg. Он обычно может показывать слайд-шоу умеренного разрешения с средненьким качеством. На что-то сверх того ему не хватит бандвиза. Как раз потому что каждый кадр шлется целиком. Даже если вообще не отличается от прошлого кадра ни на бит.
Г-нецо. Никакой поддержки flow control, изменения частоты обновлений в зависимости от ширинцы канала и пропуска кадров там нет - если канал узкий, будете видеть состояние экрана часовой давности. Не нужно.
http://... ... ...&password=
"Может ещё и ключи от квартиры"Пароль по http только если в тунели ssh.
> поток в виде анимированного GIF-изображенияПро более эффективное сжатие, например webm - этот чудак не слышал? Поточное видео из гифок - это жосска.
>> поток в виде анимированного GIF-изображения
> Про более эффективное сжатие, например webm - этот чудак не слышал? Поточное
> видео из гифок - это жосска.И чо что GIF? Зато патентами не обложен (кончились они). Бери и юзай.
> И чо что GIF? Зато патентами не обложен (кончились они). Бери и юзай.Спасибо, сами такое юзайте как-нибудь. Меня 256-цветная графика сервируемая методом "гланды, через ж...у, автогеном" как-то совершенно не возбуждает.
Непонятно, что Вы вкладываете в смысл 256-цветной графики. Представляется, что Вы не знаете, что 256 цветов могут быть в определенной палитре, например, в серой, превращаясь в оттенки (в данном случае это более точное определение). Т.о., 256 цветов (оттенков) может быть не так мало для некоторых задач. Например, для охранного наблюдения или наблюдения за действиями пользователей этого достаточно. И с точки зрения производительности гонять по сети 24-битные картинки просто глупо.
> Непонятно, что Вы вкладываете в смысл 256-цветной графики.То самое, не более 256 цветов в единицу времени. Что намекает что полноцветной графики там в принципе не видать.
> Представляется, что Вы не знаете, что 256 цветов могут быть в определенной палитре,
Знаю, но в палитре только 256 записей. Адаптивная палитра конечно сделает картинку лучше, но до 24 битов этому как пехом до Пeкина.
> Т.о., 256 цветов (оттенков) может быть не так мало для некоторых задач.
Для некоторых, ага.
> Например, для охранного наблюдения или наблюдения за действиями пользователей этого достаточно.
Это вообще не применение а идиoтизм какой-то. А что, какие-то де'Биллы и отдельному вахтеру за это платить готовы? oO
> И с точки зрения производительности гонять по сети 24-битные картинки просто глупо.
С умным сжатием - нормально вполне. Иногда 24-битная битмапа жмется даже лучше, от картинки зависит сильно.
вот браузер-то обрадуется от картинки таких размеров! человек, видимо, не в курсе, что браузер пытается скачать в память ВСЮ картинку, а не «последние пять кадров».
да нормально всё, будет пользоваьель раз в минут 30 перегружать браузер с виндовском, не привыкать
> что браузер пытается скачать в память ВСЮ картинку,А что, декомпресанутые и показанные кадры он не дропает? Если это так - можно конкретную такую декомпресс-бомбу изобразить.
Хинт: генерим белую простыню, 100500х100500 пикселей (ну или сколько там гиф позволяет). Даже убогий LZW сожмет такое весьма во много раз. Пхаем 100500 кадров такого формата. Подпихиваем жертве. Смотрим что будет :)
> А что, декомпресанутые и показанные кадры он не дропает?возможно, тут я перегнул: очень давно не видел незацикленых гифов, не уверен, как себя ведут браузеры с ними. буду, впрочем, сильно удивлён, если кому-то было настолько нечего делать, чтобы писать два варианта кода для обработки гифов — учитывая то, что большинство их них зацикленые. надо бы, конечно, глянуть исходники вебкита и гекона, но пардон — лень.
опера, например, ведёт себя забавно: проигрывает гиф заново при каждой активации таба. вебкит и гекон так себя не ведут, но сохраняют ли все кадры — не знаю.
> Хинт: генерим белую простыню, 100500х100500 пикселей (ну или сколько там гиф позволяет).
> Даже убогий LZW сожмет такое весьма во много раз. Пхаем 100500
> кадров такого формата. Подпихиваем жертве. Смотрим что будет :)если поставить бесконечную зацикленность — смешно очень будет. впрочем, подозреваю, что какие-то ограничения на всё это внутри движков стоят, иначе подобные бомбы давно уже по интернетам бы прыгали.
> возможно, тут я перегнул: очень давно не видел незацикленых гифов, не уверен,
> как себя ведут браузеры с ними.Ну да, там несколько вариантов возможно. Сжатый вариант наверное все прихранивают в кэше, но там по идее должны действовать правила на максимальный размер кэша в RAM. Если браузер на это забивает - это баг, по любому. А вот хранят ли они декомпресснутые кадры... с одной стороны это немного разгрузило бы CPU, с другой - на большой гифке это сожрет дофига RAM.
> буду, впрочем, сильно удивлён, если кому-то было настолько нечего делать,
> чтобы писать два варианта кода для обработки гифов — учитывая то,
> что большинство их них зацикленые. надо бы, конечно, глянуть исходники
> вебкита и гекона, но пардон — лень.Они, конечно, как правило, зациклены, но IIRC
1) Спеки анимированных гифок довольно гибкие (что и позволило гражданам изобразить такой изврат). Насколько я помню, каждый кадр идет с отдельной задержкой, отдельной палитрой и прочая. Для своего времени - вполне культурно и продвинуто сделано, IMHO.2) Можно и не хранить расжатые кадры а декомпрессить их по мере надобностии, забывая о них потом. Но можно и попытаться соптимизировать на свой зад, храня декомпресснутые версии кадров, да. Вот только эту оптимизацию, если она есть, можно попробовать профлудить старинным фокусом с декомпресс-бомбардировкой, если уж развить идею :).
> опера, например, ведёт себя забавно: проигрывает гиф заново при каждой активации таба.
> вебкит и гекон так себя не ведут,Они честно выполняют спецификацию, в отличие от еперы. Ну то-есть они играют гифки так как там задано.
> но сохраняют ли все кадры — не знаю.
Зависит от того соптимизили ли они декомпрессию кольцевых гифок в пользу пожирания памяти или нет. Лень смотреть в сорце, да :)
> бомбы давно уже по интернетам бы прыгали.
Вот это кстати не факт. Таких веселых бомб было, есть и наверное еще немало будет. Например, виндовые дрова (ATI, intel) падали в бсод если в браузере пытаютcя показать большую картинку (порядка 99999 х 99999 пикселей). Ее даже не генерили - просто попросили браузер в свойствах элемента растянуть картинку на вот столько. Аналогичная по смыслу атака существовала и на иксы, и как минимум через лису прокатывала. Фокус был в том чтобы запросить дофига памяти. Запрашивалась. И иксы сыпались к черту. В современных версиях или лисы, или иксов сие вроде как заделали.
Например, вот этот PNG - http://apollo.sese.asu.edu/METRIC_PREVIEW/AS15-M-0081/AS15-M... - выносил народу браузер и иксы (warning: весит 251Mb). Сейчас вроде не выносит. Правда памяти жрет, да :)
Всего 54 строчки кода. Инновационно!
Проект достойный Сколково!
https://github.com/sidorares/vnc-over-gif/wiki/FAQ
