[Можно ли?] Сделать так, что бы X-клиенты не падали с сервером

Может лучше заставить X-сервер не падать? :)

Блобы же.

Нельзя.

А кто будет восстанавливать данные, которые потерял старый сервер при падении?

Какие такие особо ценные данные потеряет старый сервер при падении, а главное - почему?

xpra, xmove

Хм, давненько у меня X Server не падал. Я уже и забыл, когда это было в последний раз. Debian stable, если что.

Какие такие особо ценные данные потеряет старый сервер при падении,

Pixmap'ы например.

а главное - почему?

Потому что они хранятся на его стороне.

У меня недавно падал, когда шлейф у харда отошёл. Правда, тогда не только иксы упали :-)

> Может лучше заставить X-сервер не падать? :)

Сервер то может быть и не упал, а упало соединение с ним. Как сделать чтобы приложения не убивались при этом?

Другой пример: X-сервер на ноутбуке, закрыл крышку и все приложения на X-клиенте были убиты. Это нормально? С VNC/RDP можно потом просто сессию восстановить и работать дальше. А клиент-серверная архитектура X-ов позволяет такое?

>Как сделать чтобы приложения не убивались при этом?
К сожалению, никак

Другой пример: X-сервер на ноутбуке, закрыл крышку и все приложения на X-клиенте были убиты

Ты так пошутил? Только что закрыл и открыл крышку ноута, внезапно ничего не отвалилось

пиши в рассылку Xorg

> Ты так пошутил?

X-клиент не на ноутбуке, а на удаленном компьютере. Ноутбук ушел в suspend и соединение было потеряно, все приложения на удаленном компьютере убиты.

Как сделать так, чтобы при выходе из suspend можно было продолжать работать с приложениями?

Мне кажется ничего не будет.
Я пробовал так: подключался по «ssh -X» к удаленной машине, запускал там pidgin, вытыкал ethernet розетку (окно с пиджином потемнело), потом втыкал обратно и пиджин работал как ни в чем не бывало.

P.S. Кэп подсказывает, что уход в суспен по закрытию крышки можно выключить

>Другой пример: X-сервер на ноутбуке, закрыл крышку и все приложения на X-клиенте были убиты. Это нормально?

Это нормально.

С VNC/RDP можно потом просто сессию восстановить и работать дальше. А клиент-серверная архитектура X-ов позволяет такое?

Требуется теневой X Server. Для того, чтобы понять, что позволено, а что нет, надо прочитать об X Window System. Это последний бесплатный совет. :)

>Как сделать так, чтобы при выходе из suspend можно было продолжать работать с приложениями?

xpra, xmove, NX/FreeNX

опять? )))
100500 раз обсуждали - в поиск!

> Это нормально.

А главное удобно, не нужно самому закрывать все удаленные приложения.

Требуется теневой X Server.

Дополнительные костыли нужны к продуманной клиент-серверной архитектуре?

>Дополнительные костыли нужны к продуманной клиент-серверной архитектуре?

Это не костыли. Читай, как общение с сервером происходит в X Window System. Может, сумеешь понять, почему от состояния X Server зависит все. Чтобы сделать сессию неубиваемой, голой X Window System недостаточно. Ее спецификация и архитектура решает задачу отрисовки. Не больше и не меньше. Если надо запоминать, что клиент отрисовал или пытается рисовать (анимация, например), если сервера уже нет, нужен теневой сервер. Куда клиенту слать запросы на отрисовку, если основного сервера уже нет?! Кто их отработает?

>Куда клиенту слать запросы на отрисовку, если основного сервера уже нет?! Кто их отработает?

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

Другими словами, состояние X Server надо где-то запоминать.

> состояние X Server надо где-то запоминать.

Надо уметь это состояние воссоздавать с X-клиентов, это не предусмотренно что ли в X Window System?

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

Надо уметь это состояние воссоздавать с X-клиентов

Возьми любую графическую программу и научи её переживать смерть X-сервера. В чём проблема то?

это не предусмотренно что ли в X Window System?

В X Window System предусмотрено не мешать клиентам это делать.

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

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

Так все-равно надо запоминать состояние X Server, так как клиенты зависят от этого состояния. Клиент послал запрос на создание окна с некоторым XID, ты этот XID у себя помнишь и манипулируешь окном через него. На сервере под этим XID хранится структура, исходя из которой X Server что-то рисует, если окно mapped и попадает в видимую часть экрана. Теперь ты сервер перезапустил — и не знает больше сервер про окно с этим XID, забыл он все. То же самое с pixmap. Много чего надо запомнить. Клиент как бы не помнит историю своей отрисовки, по какому пути вообще шел, он сам себя не осознает, он тупо идет по программе и шлет запросы на отрисовку. :) В один прекрасный миг все, что клиент насоздавал на X Server, пропадает его с падением. Ты сервер восстановил, а клиент по своей программе прет дальше, пытаясь работать с ресурсами, которые создал раньше. Получит отлуп, разумеется, и схлопнется. Прокси-уровень нужен, чтобы помнить.

Но при использовании проксей, как я понимаю, теряется возможность использовать ускорение, реализованное на стороне полноценного сервера (точнее, в драйвере, из-за которого он и падает)?

>Но при использовании проксей, как я понимаю, теряется возможность использовать ускорение, реализованное на стороне полноценного сервера (точнее, в драйвере, из-за которого он и падает)?

Почему это? Те команды на отрисовку, которые передает каждый клиент к серверу, прокси исправно передает полноценному серверу. А ответы от полноценного сервера исправно передает клиентам. При этом прокси просто кое-что себе записывает в блокнотик, а настоящий сервер даже не догадывается, что кто-то посерединке.

>Куда клиенту слать запросы на отрисовку, если основного сервера уже нет?!

Ждать, пока сервер появится.

Чорт, я был неправ, когда написал «нельзя».

Может, кто щупал вот эту штуку? Должна помогать, как я понял.

>Ждать, пока сервер появится.

Это ничего не решает. Сервер и клиент работают в синхронизированном режиме. Как сервер теряет информацию, так сразу же все накрывается. Был раньше предложен механизм для восстановления состояния клиента. В ICCCM был предложен протокол WM_SAVE_YOURSELF. Идея была в том, что клиент получает ClientMessage, что сессия закрывается. В обработчике этого сообщения он должен был сохранить свое состояние где-нибудь — какие окна открыты были, что там было нарисовано и пр., а затем произойдет закрытие клиента. При перезапуске клиента он должен был вспомнить свое состояние. Протокол давно в Deprecated. Его никто не поддерживает. Я его видел только в Emacs:

WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, WM_SAVE_YOURSELF

Да и решение не совсем удачным оказалось, так как далеко не все реально сохранить. Например, если у тебя пайпы или сокеты открыты для взаимодействия с другими процессами. Короче, 100% восстановление состояния не гарантируется. Этот протокол подарузамевал, что клиенты перезапустятся и восстановят свое состояние. То есть нельзя оставить клиента работающим, когда сессию надо перезапустить.

>Например, если у тебя пайпы или сокеты открыты для взаимодействия с другими процессами.

А зачем это сохранять, когда можно не закрывать их?

Этот протокол подарузамевал, что клиенты перезапустятся

вот это зря. думаю, многие программы спокойно пережили бы ситуацию, когда вызовы Xlib уходят в никуда)

>вот это зря. думаю, многие программы спокойно пережили бы ситуацию, когда вызовы Xlib уходят в никуда)

Ну а состояние сервера кто будет запоминать и восстанавливать?

А сохранение клиентами своих состояний — это ад. Прикинь, сколько придется сохранять всего: где какие шрифты были выбраны, где и какие панели, как они расположены, где ты что-то подвинул, на какой странице документ, какое смещение внутри документа, какое увеличение. Подвинул ты что-то в веб-браузере на какой-то веб-странице — как это запоминать? Я считаю, что это жутко, это создает геморрой программисту, который протокол WM_SAVE_YOURSELF решил поддерживать. В общем случае не получишь 100%-ного восстановления. Да и это все в теории. На практике один поддержку сделал, а второй не сделал. Все профиты исчезли. Гораздо проще и очевиднее не закрывать клиентов, а сделать нормальный прокси, который будет отслеживать состояние сервера у себя. Этот прокси-сервер и есть X server, но только рисует он в виртуальный экран. Например, в xpra используется Xvfb, то есть отрисовка идет в виртуальный фреймбуфер.

а реально ли реализовать это в тулките?
наверняка во всяких кроссплатформенных Qt хранится как минимум состояние окон и их элементов

>а реально ли реализовать это в тулките?

А фиг знает. Это вещи для меня необъятные, чтобы сразу сказать да или нет. Был проектик тулкита, который свое состояние запоминает. Это давно очень было. Очень. Вспомнить бы, как он назывался, так как читал где-то. Поищу.

Эти все решения xmove, xpra — они ориентированы не на десктоп, а на конкретные приложения, которые надо запускать на другом десктопе. Устроены они по-разному. xpra пиксели гонит из Xvfb, я так понимаю, xmove в целом устарел и там его псевдосервер не поддерживает важных расширений. FreeNX/NX, наверное, ближе всего к тому, что хочет ТС.

Ага, бросился искать и сразу набрел на документик этот. Описывается система Teleporting System исследовательской лаборатории Olivetti и обзор других решений на тот момент.

www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/ORL/tr.95.7.ps.Z

Как раз по теме.

Я в своё время писал проги на голых иксах и мне лично сохранение состояния видится несколько иным способом.
Клиентам перерисовать себя ничего не стоит - они это и так делают при ресайзе окна, например. Просто ещё одно сообщение о перерисовке.
Гораздо хуже всё обстоит с ресурсами - как ты заметил, все идентификаторы станут невалидными. Тут надо либо заставить приложение пересоздать все необходимые объекты (но это ненадёжно), либо ввести дополнительный сервер ресурсов с кэшированием в том числе на диск, работающий в паре с иксами, как когда-то это делал сервер шрифтов. Имхо, последнее - вполне юникс-вей, секурно и модульно. Если иксы упадут из-за блоба или будут прибиты - сервер ресурсов останется жить и приложениям будет с чем работать.

нельзя

>Клиентам перерисовать себя ничего не стоит - они это и так делают при ресайзе окна, например. Просто ещё одно сообщение о перерисовке.

Да, наверное. Через Expose Event. Только до этого конечно надо ресурсы на сервере восстановить.

Кстати, в документе выше, что я привел, эта teleporting system таки приостанавливает запросы клинетов, пока прокси не подсоединится к реальному серверу.

When told to dematerialise, tpproxy disconnects from the real server. It continues to process requests from its clients, and for most requests, simply records any state changes before discarding the request. For some requests, however, the client needs a response from the real server. A client which issues such a request while the teleport session is dematerialised will be suspended, and no more requests from that client will be processed until the session is rematerialised on a real X server.