Собственно они слегка достали, ТВ своей "борьбой с халявщиками" а аммии тормознутостью (вытекает что вместо написания своего переделали сорцы VNC) и что его банит Chrome.

Хочу свой с посекундной тарификацией за время работы и прочими.

Для кроссплатформы решил freepascal|lazarus и чтобы ничего допом типа jre или .net не нужно было ставить.

Вообщем нужен план и фичи первоочередные.
Пока набросок

1. Сервер-репитер с белым ip пашет как пересылатель туды/сюды и еще для учета и прочего

2. Прога включает в себе сервер:
2.1 соединяется с репитером, отправляет ему свой id
2.2 ждет коннекта, после
2.3 начинает слать скриншоты сжатые чем то // чем лучше?
2.4 получает команды мыши/клавы и выполняет

3. И клиент:
3.1 соединяется с репитером, отправляет ему свой id
3.2 делает запрос на подключение к серверу по id
3.3 получает сжатые скриншоты, распаковывает и показывает
3.4 отправляет команды мыши/клавы

ЗЫ собственно что я упустил?

ЗЗЫ получение скриншотов уже сделал )) раз в 10 миллисекунд вроде сильно слегка устаревший комп не грузит, причем еще и отображение пашет

ЗЗЗЫ http://saveimg.ru/show-image.php?id=f00f2cef9a7e71599dadbc28ad7f5034

(436)Тимвьювер не кроссплатформенный.
Попробуй модуль для винды запустить на линуксе.

Для каждой платформы свой клиент, написанный именно под эту платформу.
Т.е для винды, для андроида, для мака, и для линукса.
Причем не каждый клиент поддерживает все функции.

(439) вот это уже холивар пошел...

как бы у меня код кроссплатформенный (одинаковый для всех), понятно что под каждую отдельно компилить

(440)Вот у меня есть программулька кроссплатформенная - джава
Ее хоть на винде, хоть на маке запускай, лишь бы джава машина была. Прекрасно работает.

Это полная кроссплатформенность.

Есть софт который можно перекомпилировать под другую платформу.
Но тимвьювер к нему не относится.
Ты не скомпилируешь софт написанный исключительно под винду, для линукса. Ибо он работает с Win API.
Для линукса есть свой нативный клиент.
И общего у него с клиентом для винды только название и внешний вид.

(441) с паскажем тут какраз "есть варианты"

(442) тьфу.. "с паскалем"

(439) Кстати, запускат тимвьювер под виндой через вайн - почти нормально работал)

Определить на глаз очень просто - тимвьювер рисует окошки через WinAPI, эти окошки выглядят по разному в зависимости от темы оформления винды.
Т.е нативные виндовые окошки.

А кросплатформенный софт рисует окна, своей библиотекой, которую таскает вместе с собой.

(444) Пардон, имел в виду виндовый тимвьювер в линуксе.

(444)Чего?
Под виндой? Через вайн? Да вы однако извращенец.
Не подскажете где скачать вайн под винду?

(446)Ааа, понятно.
Ну не проще ли нативный клиент скачать?

(447) уточняю... тим под линукс и так через свой вайн работает

(441) хм а как насчет эту программульку на java запустить в андроиде?
под который кстати на java в основном и пишут программы...

(445) Так основная проблема не в отрисовке, а в захвате экрана. На разных системах это делается по разному.

(451) если бы только захват экрана...

(449)Нет.
Вайн это собственно куча библиотек которые обеспечивают под линуксом обработку WinAPI.
И весят они офигеть как немало.

А тимвьювер под линуксом использует родные библиотеки.

(450) под андройд надо переписывать, то на чём под андройд программы пишут...это не совсем правильная java...это изврат

(451)Да основная проблема в захвате, отрисовку я привел как наглядный пример.

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

Сам не пробовал, но по идее на нетбуке с андроидом должна стартануть.

(453) teamviewer для linux содержит свою версию wine. Кроссплатформенность это иллюзия

(457) в андройде нет полноценной jvm, там кособокий dalvik собранный ищ обломков java 6 ...а в новых андройдах из него какойто ART соорудили... но один фиг нативная java там не работает

(459)Ну может и так, я с андроидом не дружу.

Но вернемся к теме.
Garykom ты уже написал план работ?
Базовый функционал, и схема работы сервиса?

(461) как бы просто (0) расписал более детально после того как демку накидал

но куча пунктов добавилось и фичей

вот сча думаю в простом варианте запускать или все таки пилить до "конфетки", но тогда $ нужно искать и еще разработчиков

imho стоит запускать в простом варианте, и искать инвестора под стартап

иначе допиливание может очень на долго затянутся
я так один свой проектик с декабря "допиливаю"...всё никак не могут выползти от попыток "конфетку" сделать

(462)Ты все еще думаешь делать скриншоты слать их?
Или нашел другое решение?
ИМХО это тупиковый путь - трафик будет такой, что канал потребуется на 100мегабит.

(463)Инвестора есть смысл искать, когда есть готовое и хорошо работающее приложение, которое можно допиливать.

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

достаточно на список проектов известных инкубаторов посмотреть, там такой дикий ужас, меня вообще поражает КАК за такое деньги дают...

(466)Не этот случай. Одно дело найти инвестора на нечто новое, что никогда никто не делал.
Другое дело найти инвестора на приложение которое повторяет функционал существующего.
Программ для удаленного доступа сотни, из них десяток более-менее известных. Рынок забит.

(464) как бы все скриншоты шлют (teamviewer, ammyy и прочие vnc) так что не вижу проблемы

только они не полные понятно шлют, а только изменившиеся области

еще есть вариант с векторизацией, но это нереально быстро реализовать

(469) так прочие vnc тормозят неимоверно на слабых каналах (468) сколько убийц фейсбуков и форскверов было...этож жесть какаято..

(468) как бы наоборот проще, только БП должен быть нацелен на отличия от основных конкурентов, на маркетинг и экономическую часть больше

(469)Ну самое простейшее что использовалось на заре VNC это скриншоты прямоугольных примитивов.
Т.е отслеживают область изменений и ее пересылают.
Это дикий трафик. Даже в таком виде.

А уж если целиком слать скриншоты, то это вообще жестко будет.

(470) угу только немало и взлетело как бы моя фейсбуком не пользоваться совсем в отличие от вконтактика

(470)А на слабых каналах работают только два метода из ныне существующих - это закрытый код от тимвьювера, и RDP.

(473) сколько взлетело то?

Мой мир помер, мой круг помер... осталсь только одноглазники и ВК

лучше описание RDP протокола найти (в идеале ICA, но кто ж его раскроет)

(475)_ даже гуглплюс не взлетел с такой то расруткой

(476)Да вроде RDP открытый протокол.

(474) не хочется разочаровывать, но у тимвьювера просто идет автоподстройка частоты скриншотов под канала

типа совсем если хреновый начинает кадр раз в 2-3 секунды передавать

(479)Это так, а при чем тут разочаровывать?
Главное работает. А физику не победишь.
Если канал узкий и не позволяет передать достаточно данных, надо уменьшать количество данных в ущерб качеству.
Все логично.

Единственный кто нормально, показывает видео это RDP, но и канал должен быть офигенным.

(480) при том что нету никакого "секретного метода"

а с rdp еще проще все, он на контролах работает по умолчанию и когда может
попробуйте через rdp фильму посмотреть а вот потом и говорите насчет скорости ))

(481) потому что если канал "не офигенный" он вообще тупо виснет с видео...

(482)Так какой может быть секретный метод?
Все методы известны. Вопрос лишь в том насколько качественно он реализован и допилен под задачу.

А на RDP видео классно идет, смотреть можно.

как бы ничего не мешает использовать принципы live stream video

и будет даже лучше чем rdp и при этом не так грузить канал

но будет тогда грузить проц хоста

Да RDP повиснет с видео на слабом канале. Есть такое.
У тимвьювера идет автоподстройка под ширину канала, а у RDP с этим хуже.

(485)Вот.
А у меня множество хостов - это дохлые машинки со слабым процессором и минимумом оперативки.
Если их озадачить кодированием видео на лету, будет очень печально.
Удаленка может и будет работать, а вот работать с машиной станет невозможно.

Поэтому логичнее всего будет допиливать VNC, в плане оптимизации и динамической автоподстройки к ширине канала.
А не изобретать лисапед.

(487) как бы обычная дилемма выбора

на слабых машинках лучше всего пашет radmin, он да через видеодрайвер работает, но с нагрузкой на канал у него все плохо

(488) VNC это просто сокращение https://ru.wikipedia.org/wiki/Virtual_Network_Computing

по сути протокол

конкретные реализации на языках программирования (почти всегда c++) называются с разными приставками

как бы моя ничего не нарушать даже канонов

(490)VNC это протокол удаленного доступа.
А если говорить о методах передачи изображение то там протокол RFB.

У тимвьювера скажем логика похоже следующая - есть приоритет передачи.

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

В итоге курсор, рабочий стол - отрисовываются быстро, а если где то открыто видео, оно при слабом канале будет обновляться раз в минуту.

Еще преимущество тимвьювера в том, что там реализован NAT traversal.
Хотя если будет свой личный репитер, то можно обойтись без этого.

потестил формат графики bpg, сжимает то он конечно замечательно... в 3-6 разу лучше чем jpg или png

но с такими тормозами что применить не получиться походу

кстати, если прикрутить передачу только дельта изменений то трафик упадет в разы, к примеру 1 кадр в секунду ключевой, потом передача дельты относительно ключевого.

(495) дык это и ваяю сча

а вообще ключевую картинку необходимо поделить на области и передавать дельты из каждой области

(497)Дык это собственно и делается в том же VNC.

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

(499) так мы и до реализации рдп дойдем ))

(498) хех, написал стих "Мой дядя самых честных правил...", оказалось это уже Пушкин до меня сочинил

(501)Да Пушкин вообще подлец, написал все стихи которые можно было написать, а теперь современная молодежь мучается, ибо чтобы ни придумали - у Пушкина уже есть.

(499) идея интересная но реализовать проблемно, хотя можно через отслеживание координат окон

вот если видео на экране кажется и в нем квадратик двигается то уже никак по простому

(503)Если говорить о винде, то не очень проблемно.
Кординаты всех ярлыков, окон и прочего можно узнать у эксполрера, или  через винапи.

(503)+ хотя... если хранить (как и передавать) изображения сразу с хешем то можно ))

т.е. свернули окно, показываем рабочий стол весь, назад восстановили - опс а картинка то уже есть

(504) угу только как бы сразу "для разных ОС" хочу, т.е. варианты "только для винды" рассматриваю в последнюю очередь

(506)Дык в линуксе тоже есть методы чтобы получить координаты объектов на рабочем столе.
Просто они другие.

Т.е в разных ОС будет просто разные механизмы получения и работы с ними, а объекты одинаковые.

Поэтому в любом случае для вин и лин клиенты должны быть разными.
А протокол обмена между разными клиентами должен быть один.

(507) в линухе можно из иксов напрямую тянуть примитивы которыми он рисует окно

в винде затрудняюсь сказать насколько это доступно

(509)В винде то же самое, только реализация различается.

(510) даже тимвьювер для линукс не стали переписывать а вайн заюзали... вы хотите чтобы я написал круче чем они?

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

(512) больше изменений это как?

пока простой алгоритм есть два кадра (текущий и предыдущий), бежим по пикселям слева-направо и сверху-вниз, если цвет точки на кадрах отличается то кидаем в кадр изменений (этот кадр изменений по сути целый экран с прозрачным фоном)

если много изменений (больше 50%) причем это обнаружилось еще в процессе пока не дошли до конца, то прерываем сравнение и шлем целый кадр

(513) вот кстати этот метод пробег по всем пикселям и сравнение на больших разрешениях экрана вызывает слегка тормоза

т.е. придется по некой сетке делать или еще как типа http://www.delphimaster.ru/cgi-bin/forum.pl?id=1284964400&n=7
задачка то древняя любителей лисапедов много

я плохо соображаю в математике, но сдаётся мне что картинки можно сравнивать как две матрицы...и относительно этого высчитывать различия

плюс такие вычисления видеокарта умеет делать довольно шустро

(514)Понятно что будут тормоза, как при подсчете, так и при передаче.
Не надо бегать по пикселам, работай с областями.

Вообще чтобы не городить велосипед из костылей, думаю за основу стоит взять принципы работы RFB.
http://www.realvnc.com/docs/rfbproto.pdf

жду велосипеда на тестдрайв. надеюсь, что в альфа версии тормозные колодки не прилипнут к ободам

(519) лисапед пока тока прямо едет (без репитера) и медленно, это совсем неинтересно

Гм интересная задачка, а как можно определить что 2 компа находятся в одной локальной/виртуальной сети?

Хотя понятно делаем пробный коннект к ожидаемому ид и если нет коннекта или ид не тот то нуна через репитер

(521)Не понял зачем это нужно? А вообще через широковещательную рассылку можно.

(522) чтобы через репитер поток не гнать если можно напрямую, когда компы в одной локалке или белые ip

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

т.е. компы 1 и 2 соединены с репитером 3, если комп 1 хочет управлять компом 2 то:

делаем попытки соединения 1->2 и 2->1, если обе не прошли то через репитер 1->3->2

(523)Лучше не мудрить, а сделать переключатель.
По дефолту считаем что работаем в интернете, для подключения по локальной сети ставим галку.
Или банально указываем айпишник.

(524) неа, предпочитаю следовать принципу kiss

т.е. для пользователя все должно быть как можно проще и понятнее, все сложное в доп.настройках или отдельный режим работы(эксперт)/версия

(394) +100500

(0) Хочется больше настроек качества изображения, а именно, выбирать кадры/с, кратность размера картинки и уровень качества jpeg (0..100). Кратность - это вместо 1200х1600 на клиенте увидеть 600х800. Иногда важно хоть что-то, хоть как-то увидеть, чем ничего.

(527) для этого нужно как то скорость канала оценить

все методы что я знаю дают дикий разброс на коротком интервале тестирования (меньше несколько минут)

Прошло 2 недели с начала темы.
Што написано афтором?

(529) автор дальше пока ничего не делал, пытаюсь траблы на основной работе решить и машину обновить... при этом все это перемежается отвлечением на флуд на форумах

ЗЫ пора что то бросать...

(530) Давай я тебе расскажу, что будет дальше:

1. Ничего.

А как всё хорошо начиналось :))

(531) не спорю, возможно и так

Хотели как лучше, а получилось...

Пока автор флудил на форуме, уже RDP клиент на JavaScript написали.

(535) Не верю, VNC - написали, RDP - нет.

(535) молодцы терь пусть сервер напишут...и заставят на любой оси (любом броузере) это работать

(536) https://github.com/citronneur/mstsc.js - попробуй.

Правда, кроме браузера, требуется Node.js. Пока.