Comments 25
Получается это просто RDP одного окна-приложения по-линуксятски? Ведь все вычисления и файлы хранятся на сервере? Или как? не оч понятно. Но идея хорошая, спору нет
Выглядит как RemoteApp для Linux...
Я никогда не работал в Липнуксе, и ничего не знаю про Termit. Поэтому я не смог понять из статьи: любое ли Windows-приложение можно подключить таким образом? Ведь большинство Windows-приложений имеют полноценный оконный интерфейс. Юзер видит перед собой окно, которое обрабатывает перемещения и клики мышки, показывает всплывающие подсказки, ну и естественно ловит события клавиатуры. Будет ли это окно вести себя точно так же на линукс-машине, если она подключена к Windows-серверу через Termit? Можно ли развернуть такое окно на весь экран?
Это не чисто теоретический интерес
Дело в том, что мы написали программу для научных исследований, которая работает в среде Windows. Но по мере развития и совершенствования этой ОС все больше пользователей спрашивают: а можно с нашей прогой работать в Линуксе. А мы не программисты, мы научные сотрудники,.. мы сами этого не знаем. "Простые решения" вроде перекомпилировать под линуксом не проходят, так как у нас довольно специфический стек и весь интерфейсный "велосипед" придется переписывать заново. А ресурсов (да и знаний) для этого просто нет, так как "мы не программисты, мы научные сотрудники.. (ну и далее бесконечный зацикл ;-).
Есть гораздо более вменяемые и общепринятые способы запускать Windows приложение на Linux. Способ, описанный здесь, применяется, когда на софт ещё и одна лицензия на всех и её нужно соблюдать.
А так - шлите пользователей запускать в Wine и пусть пишут вам, почему не смогли.
Действительно, Wine тоже можно использовать. Но под ним работают не все приложения, зачастую проще оставить все как есть (т.е. на Windows), и перенести на Linux только пользователей.
В Wine у нас не получается из-за наших велосипедов.
У нас интерфейс реализован одним exe-шником (т.н. "сервер интерфейса"), а вся содержательная работа - другими (т.н. "клиентами"). Они постоянно обмениваются между собой сообщениями, включая проверку наличия друг друга в системе и т.д. Причем, в разных сценариях работы эти "клиенты" могут запускаться и как дочерние процессы сервера интерфейса, и самостоятельно, и как дочерние процессы друг друга.
Описание велосипеда
Сначала у нас запускается т.н. "сервер интерфейса". Он висит в системе как фоновый процесс и ловит сообщения от "клиентов". При первом обращении - создает окно клиента, и дальше уже выступает такой "прокладкой" между клиентом и этим окном.
Когда мы это мутили, задача была в том, чтобы переселить пакет из DOS в Windows, почти ничего не меняя в "клиентах". (До этого они при общении с юзером полагались на DOS-прерывания).
Был привлечен специальный чел, который
такую прокладку сделал
Она даже сперва называлась DOS10, если кто-то тут еще помнит смысл этой цифры;-)
Заодно добавил немного новых функций, которых у нас в DOS-версии не было. Которые мы постепенно стали к своим "клиентам" прикручивать... Фактически получился свой собственный фреймворк, через который у нас реализован весь интерфейс.
Написаны и отлажены эти велосипеды были в XP, но семерку все перекочевало на ура. В десятке и в 11-ке были отдельные непонятки, но только для некоторых специфических установок винды (в стандарте все вроде работает). Самый труднопонимаемый баг был в том, что окно клиента не закрывалось после закрытия программы. Сервер интерфейса почему-то не мог получить информацию, что клиент больше не активен. Пришлось добавить костыль: перед завершением работы клиент теперь посылает серверу сообщение "я мухожук навсегда". Если успеет, конечно ;-)
А под Вайном так и не заработало.
У меня есть похожая архитектура Win приложения. Коммуникация между клиентами происходит через pipes. В таком случае проблем с закрытием клиентов проблем не будет, так как в случае закрытия канала летит евент который отваливается и можно закрываться.
Коммуникация между клиентами происходит через pipes (...) в случае закрытия канала летит евент
Эту часть писал не я, поэтому могу наврать. Но у нас через pipe идут только большие объемы данных. Которые нужно передавать очень редко (такая архитектура). Поэтому они открываются, выполняют свою задачу и сразу же закрываются. А все оперативное взаимодействие идет через SendMessage. Если я правильно понимаю, это быстрее и проще (не надо готовить канал и т.д.).
В общем, по каким-то причинам было сделано именно так. Товарищ, который это писал, намного грамотнее всех нас остальных, поэтому решение явно не с потолка взято. Но по итогу имеем то, что имеем. Под Wine не работает...
Здесь описывается клиентская часть, которая на стороне Linux. Само приложение, его ресурсы и устройства на Windows.
Очевидно, если вашему приложению нужны, к примеру, графические акселлераторы или USB токены, - их следует подключать непосредственно в Windows, то есть ресурсы вашего ПК/ноута (процессорные, дисковые, память, графика) использованы не будут. Приложение использует ресурсы Windows сервера, у вас лишь картинка с отображением окна.
Из описания мне не очень понятно, чем данный RDP клиент круче других, более известных. Поддерживает ли он фермы, перенаправление папок и профилей, Remote Desktop IP Virtualization (IP у терминального приложения под каждым пользователем свой) - что есть у Windows 7 в коробке.
Termit - это не совсем терминальный клиент. Это система терминального доступа, позволяющая работать с приложениями, опубликованными на терминальных серверах Windows и Linux. Наша клиентская часть поддерживает Windows/MacOS/Linux. В качестве серверов можно использовать Windows Server 2012R2 или самые разные Linux-системы (РедОС, Astra Linux, ALT Linux или Debian).
В рамках Termit можно объединять терминальные серверы в группы и публиковать приложения на них. Таким образом обеспечивается отказоустойчивость и распределение нагрузки (балансировка).
Перенаправление папок и перемещаемые профили поддерживаются на Windows-серверах, мы работаем над реализацией этих функций для Linux-серверов.
Termit - это не совсем терминальный клиент.
Спасибо, дяденька! А что ты сейчас сказал? (с)
;-)
Да, я тупой (и понимаю, что ответ был не мне ;-).
Но у меня есть тупой вопрос, ответ на который я ищу по всей переписке.
Условия задачи:
1) У меня есть комп с Виндой. Совершенно обычной. Там может стоять что угодно, от XP до 11, от рус/англ домашки и Про до LTSC (но это не серверная версия точно). Он работает круглосуточно, и там на нем лежат файлы с данными, которые должна обрабатывать некая прога. Которая на этом компе (локально) прекрасно работает. И которую там иногда запускают местные юзеры.
2) На другом компе с неизвестной версией линукса есть юзер, который тоже хочет запустить эту прогу и с ней поработать. Желательно не вставая со стула.
3) Оба компа подключены к инету. И даже могут быть в одной локальной сети.
4) Но, менять версии ОС ни на первом, ни на втором компе нельзя. Можно только установить небольшое (нетяжелое по ресурсам) дополнительное приложение.
============
А теперь вопрос: можно ли с помощью Термита как-нибудь выполнить то, что хочется юзеру в пункте 2? То есть соединить этого юзера с прогой? Желательно не заметив разницы с тем, как он это обычно делает на Windows-компе?
Как бы вы решили эту проблему, если бы на 2 компе стоял тоже Windows, а не Linux?
Подключайтесь со второго компа на первый через AnyDesk (или через другое аналогичное ПО). Или ставьте на первый комп сервер RDP и подключайтесь через RDP. А Termit, насколько я понял, аналог сервера RDP.
Как бы вы решили эту проблему, если бы на 2 компе стоял тоже Windows, а не Linux?
В этом варианте у нас все давно решено: юзер на втором компе просто запускает у себя свой exe-шник программы. Дальше прога через сеть лезет в БД, которая лежит на первом компе, и т.д. У нас нет проблемы клонировать exe-шники. Проблема в том, что нам надо работать с одними и теми же файлами данных с разных компов. Пока что мы умеем это делать, только если на всех компах стоит какая-нибудь Windows и они видят файлы БД через сеть.
То есть, юзеры на каждом компе запускают свой клон exe-шников. Эти exe-шники физически работают там, где запущены: используют свой локальный процессор, свою ОП, свои конфиги, организуют на локальном компе свое рабочее пространство на диске и т.д. Но, при этом все они могут залезть в одну и ту же БД на удаленном компе. Точнее, у нас симметричная система: на каждом компе может лежать несколько БД, и любой экземпляр проги (запущенный где угодно) может залезть в любую из этих БД.
Мы сами не знали, что так можно, пока не попробовали ;-)
В порядке прикола, расскажу эту историю поподробнее.
Изначально у нас была самодельная однопользовательская квазиСУБД, рассчитанная на единственного юзера. Вообще без каких-то защит и блокировок - просто такой проблемно-ориентированный интерфейс к файлам данных. Программа представляла собой своеобразный монолит из этой квазиСУБД, среды визуализации данных и пакета методов обработки временных рядов.
Но юзеры любят запускать одновременно много программ. И в один момент выяснилось, что юзер может открыть БД и забыть об этом. Окно программы скроется где-то в глубине под другими окнами. После этого он вспоминает про следующий вопрос к данным и запускает программу заново. После чего лезет в ту же самую БД, которая уже открыта другим экземпляром программы. В результате в БД иногда могло что-то испортиться.
Я тогда (лет 25 назад) решил эту проблему так. При открытии БД там ставится флаг, что она занята. Если юзер хочет открыть ту же БД повторно, то программа видит флаг "занято". Дальше она могла бы сразу сказать что-то типа "переключись в другое окно, балбес, я уже там запущенная" и закрыться. Когда комп ровно один, юзер тоже один, большего вроде как и не нужно. Но я не поленился и сделал режим ожидания: прога периодически заглядывает в БД и проверяет там этот флаг: как давно он был установлен, и делал ли что-либо второй юзер в последнее время. Если (когда) оказывается, что флаг снялся, прога монополизирует базу и т.д. Все это было сделано задолго до того, как у нас появились сети и прочие излишества.
А спустя много лет мы вдруг выяснили, что если компы соединены в локальную сеть, то я могу через нее работать с диском другого компа. А если это Яндекс-диск, то с ним можно работать из Москвы и с Камчатки одновременно. И что если записать БД на Я-диск, то благодаря архаичной системе блокировки БД наша программа внезапно превращается
в многопользовательскую
У нас очень-очень самодельный велосипед, с нестандартными задачами и архитектурой, поэтому доступ к БД на запись бывает нужен исключительно редко и чаще всего ненадолго. А число юзеров у каждой БД не больше нескольких человек. Поэтому ждать, пока БД освободится, почти не приходится.
Сначала мы удивились, потом обрадовались, а теперь вовсю этим пользуемся ;-) Единственное, что мне пришлось сделать - это подкрутить временные лаги в своих алгоритмах, так как синхронизация Я-диска может занимать определенное время. Сейчас на Хабре модно ругать преждевременную оптимизацию... но вот у нас получился нагляднейший контрпример, как она пригодилась спустя много лет ;-))
То есть, у нас сейчас есть такая условная сеть равноправных компов под Виндой, на каждом из которых есть свой экземпляр программы и свои БД. Но из данной статьи я понял, что в эту сеть вроде бы можно как-то заглянуть с Линукс-компа. И пытаюсь понять: как конкретно это могло бы быть.
Или ставьте на первый комп сервер RDP и подключайтесь через RDP.
Насколько я понял, это потребует серьезных изменений на первом (основном) компе. Нужно будет не просто добавить в систему какой-то модуль, а переустановить Винду целиком?
Ну и во-вторых, я все равно плохо понял из описания RDP, как будут взаимодействовать между собой два экземпляра одной программы, запущенные локально (комп N1) и удаленно (через терминальный канал) с компа N2. Это эквивалентно тому, как если бы я запустил два экземпляра проги локально? Или они каким-либо способом изолируются друг от друга? Каким?
Более конкретно, вопросы такие:
1) Будет ли один экземпляр "видеть" в системе другой экземпляр? И что будут видеть другие программы, работающие на компе-1? У нас сейчас каждый экземпляр программы - это несколько exe-шников, которые ищут друг друга в системе методом FindWindow('ИМЯ',0). А что произойдет при одновременном запуске двух экземпляров программы (локального и удаленного)? Ведь они идентичны и создают окна с одинаковым именем?
2) Второй вопрос: при запуске наша программа определяет папку, из которой она запущена, и читает там всяческие конфиги, подгружает по мере необходимости библиотеки и другие exe-шники и т.д. Правильно ли я понимаю, что удаленно запущенная программа фактически запускается из той же самой папки на локальном компе-1, что и локальная копия, и будет видеть идентичное с ней окружение, а также все изменения, которые делает первый экземпляр проги? Или же для этого создается какой-то изолированный контейнер, в который эти папки копируются и дальше живут своей независимой жизнью?
3) Третий вопрос про файлы данных. У нас обоим экземплярам нужны одни и те же файлы данных, лежащие на компе-1. Файлы довольно большие. Когда экземпляр программы, запущенный удаленно, лезет в этот файл, то он видит один и тот же файл с локально запущенным экземпляром, или же копию этого файла? Если копию, то получается, что ее нельзя изменять (проблема слияния изменений)? Или как?
Да, Termit здесь сможет помочь. Ваша программа физически будет работать на Windows-сервере, пользователи будут её запускать удаленно со своих Linux-машин. То есть программа выполняется на Windows, на Linux просто отображается интерфейс.
То есть программа выполняется на Windows, на Linux просто отображается интерфейс.
Это я понял. Вопрос в том, насколько полноценно и быстро он отображается. Например, графика у нас векторная и довольно увесистая. 100 тыс. элементов на графике - это норма, при которой юзер не замечает задержек; миллион должен отрисовываться за разумное время. Если просто посылать сообщения на экран, то на старых компах оно вообще не работает. Чтобы как-то разрулить ситуацию, наш так называемый "сервер интерфейса" создает в памяти виртуальный экран с разрешением, равным фактическому размеру окна в пикселах. Затем выводит на этот виртуальный экран векторные элементы изображения (там что-то похожее на wmf-стиль). Потом этот виртуальный экран отображается в Windows-окно. При изменении виртуального экрана он ре-отрисовывается (заново проецируется на Windows-окно) после каждого изменения, но не чаще 10 раз в секунду. Причем, если что-то где-то начинает вдруг тормозить, сервер это как-то контролирует (я не знаю, как именно) и динамически снижает частоту ре-отрисовки. Иначе работать было бы невозможно.
Так вот. Простите за тупой вопрос, но Вы уже поняли из прошлого абзаца, что я даже под Windows очень туманно все понимаю. А как это происходит при работе через терминал, для меня совсем темный лес
совсем темный лес
В те древние времена, когда я что-то я умел "в терминал", он выглядел наподобие командной строки: я там печатал вопросы, а оно в ответ что-то выводило в следующей строке, причем обычно с прокруткой экрана. Я правильно понимаю, что при удаленном подключении у Win-серверу Термит использует аналогичные протоколы только для передачи сообщений между компами? А формированием и обработкой этих сообщений на каждом компе занимаются местные "фоновые" программы? То есть, функциональность определяется вовсе не протоколом передачи сообщений, а функциональностью этих приложений?
Ну или точнее, протокол вкупе с пропускной способностью канала может накладывать дополнительные ограничения на количество (объем) сообщений, но на практике оно несущественное?
Если я правильно понял, то на Windows-сервере работает какой-то фоновый процесс, который эмулирует окно,
перехватывая поступающие ему сообщения, и наоборот?
В нашем пакете я имею отношение только к "клиентам", и вообще не представляю, как "внутри" устроены окна Винды.
Из соображений здравого смысла мне казалось, что непосредственной работой с окнами занимается Винда. А как в это взаимодействие вклинивается Термит? В частности, будет ли окно программы отображаться на Windows-сервере?
Мне трудно себе представить, что не будет
Но если вдруг такое и правда возможно (я просто не в курсе), то для наших программ такой вариант не подойдет. Они просто не смогут корректно взаимодействовать друг с другом, т.к. у них не получится послать сообщение в другое окно клиенту-коллеге...
Или же окно программы на Windows-сервере функционирует в обычном режиме, а Термит клиент просто отслеживает его изменения? Но как он это делает? Не попиксельно же (например, в нашем случае это приведет к фатальному торможению).
Или он снимает копии всех сообщений и дублирует исполнение всех команд в линукс-окне? Но как тогда разрешаются конфликты? Например, юзер что-то щелкнул на Win-сервере, и состояние окна изменилось. А в тот же момент (до отображения этих изменений) юзер в линукс-терминале дал другую команду, которая в новом (измененном) окне выполняет совершенно другое действие?
del
Как будто не было последних лет 20 с их терминальными серверами (от Citrix WinFrame до Virtual Apps, MS Terminal Server ...), потом VDI от того же Citrix, VMware, даже уже наших Space, Termidesk, Loudplay...
Термиты, вы где были все это время? Почему ИХ уроков не выучили? Где были последние 2 года( когда тех же Space и Термидеск буквально завалили критикой за их протоколы)? Предлагать в кач-ве "решения" rdp ( freerdp 2.x?) , когда известны все его ограничения? Как вы собираетесь вписаться в существующие сети с потреблением на сессию в 4-8 раз выше , чем у наиболее популярного в терминальных серверах HDX/ICA? Без малейшей оптимизации ВКС( в rdp нагрузка на CPU терминального сервера в 12 раз выше, чем при использовании такой оптимизации)?
Термидеск и Space во всю "пилят" свои протоколы, осознав, что ни один опенсорсный или rdp для enterprise никак не подходят, Loudplay уже давно на уровне Citrix или VMware по работе с тяжёлой графикой.
И тут - "да, это - rdp!"
Для изучения статья лохматого года по сравнению протоколов. В кач-ве домашнего задания : https://vm-guru.com/news/vdi-protocol-comparison-dec2010
До управления профилями юзеров, балансировки нагрузки, провижининга серверов и приложений даже доходить не стану.
Резко? Не извиняюсь. Хуже будет, когда это от заказчика услышите
Предлагать в кач-ве "решения" rdp ( freerdp 2.x?)
А что не так? Да, для миллионных ферм не подходит, само собой, но тут речь и не про них. Из открытых протоколов разве что spice работает без лагов и тормозов (сколько использую - очень доволен, пролезает даже через сотовый интернет), все остальное - жуткое глюкалово. Из "полуоткрытых" лучшее - RDP, особенно с виндой.
Ну, статья 2010 года необъективна после того, как в RDP завезли AVC444 кодирование.
Мы используем RDP только для доступа к Windows-серверам. И для них это вполне естественный протокол, неплохо поддерживаемый на Linux через freerdp, пусть и со своими ограничениями.
У Cubes OS был драйвер для семерки, позволявший прозрачно шарить окна из вируалки в основную систему. Реально рабоали вперемешку виндовые и линуксовые окошки. Но сам Cubes OS монструозен и крив, потому идея провалилась...
Похоже, тут идея аналогичная.
у нас импортозамещение и иб, и вдруг появляется левый софт и появляется сервер виндовый, если статья для пользователя как запустить виндовое приложение на линуксе, так у него не будет ни рутового доступа, ни доступа к виндовому серверу, если это инструкция для админа которому надо импортозаместиться, так у винды достаточно своих функций без лишнего софта ака термит, если вы субъект кии то данная статья из серии вредных советов
В статье описывается сценарий, когда у заказчика переведены на Linux и клиентские места, и серверы. Есть ПО, которое работает только под Windows, и с этим ничего нельзя сделать. Можно запускать его через Wine, как указали выше (но там есть свои нюансы), или поставить это ПО на Windows Server и пускать туда пользователей с их Linux-клиентов. Т.е. Windows остается там, где без неё никуда.
Как пользователям Linux продолжить работать с приложениями Windows: решаем с помощью Termit