Доступ к INI-файлу из нескольких процессов

← →
ProgRAMmer Dimonych © (2012-08-09 12:42) [40]

Упс, про PostMessage нагуглил. Остальные вопросы актуальны, как и рекомендации по теме передачи куска данных в соседний процесс.

← →
Андреевич (2012-08-09 13:16) [41]

я бы тогда остановился на MMF

← →
sniknik © (2012-08-09 14:01) [42]

ИМХО, вижу мучительные попытки создать самопальную файл серверную базу из одного ini-шника, хотя от них все давно уже отказались в пользу клиент серверных.
не нужна собственно база, посмотри хотя бы на принципы работы.

← →
ProgRAMmer Dimonych © (2012-08-09 14:10) [43]

> [41] Андреевич (09.08.12 13:16)
> я бы тогда остановился на MMF

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

> [42] sniknik © (09.08.12 14:01)
> ИМХО, вижу мучительные попытки создать самопальную файл
> серверную базу из одного ini-шника, хотя от них все давно
> уже отказались в пользу клиент серверных.
> не нужна собственно база, посмотри хотя бы на принципы работы.

Исходная задача - обмениваться данными между приложениями. Попытки использования INIшника для этих целей отброшены как бесперспективные.

← →
AV © (2012-08-09 14:12) [44]

Один процесс читает и пишет файл, выполняя команды других процессов.
Общаются по сети. Если чтец/писец умер, выбирается новый.

← →
sniknik © (2012-08-09 15:47) [45]

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

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

← →
ProgRAMmer Dimonych © (2012-08-09 15:51) [46]

ОК, был неправ насчёт сообщений: в соседнюю терминальную сессию не приходят :( Возникает вопрос.

Есть MMF. В него один процесс пишет какую-то информацию и уведомляет остальных взведением event"а (например). Как убедиться, что все процессы прочитали эту информацию? Кол-во процессов заранее неизвестно. Завести счётчик - проблема, ибо процесс могут просто грохнуть из таск менеджера.

← →
ProgRAMmer Dimonych © (2012-08-09 15:53) [47]

> [45] sniknik © (09.08.12 15:47)

Соглашусь. Но выбор момента отправки запроса для меня пока затруднителен :(

← →
ProgRAMmer Dimonych © (2012-08-09 15:57) [48]

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

← →
AV © (2012-08-09 16:30) [49]

Кстати, а можно от сферических коней перейти к конкретной лс.
или
А для чего это все? какая задача решается? (Только, _конкретная_!!)

← →
ProgRAMmer Dimonych © (2012-08-09 16:40) [50]

> [49] AV © (09.08.12 16:30)

Так ещё в [29]. Можно только дополнить, что в пределах одного узла INIшник общий.

Всё остальное - подзадачи, которые приходится решать в поисках подходящей реализации.

← →
Сергей М. © (2012-08-09 16:55) [51]

> ProgRAMmer Dimonych © (08.08.12 18:54) [33]

Самая правильная мысль - отказаться от ini и самодельного огорода вокруг него в пользу любой подходящей готовой многопользовательской СУБД со встроенным механизмом извещения о событиях.

Полагаю что та же Firebird вполне перекроет описанные потребности.

← →
ProgRAMmer Dimonych © (2012-08-09 17:04) [52]

> [51] Сергей М. © (09.08.12 16:55)

И ставить СУБД на каждый узел? И добавлять к настройкам монитора параметры соединения с БД? Пользователь вряд ли оценит это.

← →
Inovet © (2012-08-09 17:09) [53]

FAR с версии 3.0 хранит настройки, историю и пр в базе SQLite. Только что там с многопользовательностью (сервера же нет), на сайте не упоминается.
http://www.sqlite.org/features.html

← →
Inovet © (2012-08-09 17:10) [54]

> [52] ProgRAMmer Dimonych © (09.08.12 17:04)
> И ставить СУБД на каждый узел?

Так где ты файл хранишь, там и сервер ставить.

← →
AV © (2012-08-09 17:12) [55]

> И ставить СУБД на каждый узел?

??
На один, который все видят

← →
ProgRAMmer Dimonych © (2012-08-09 17:17) [56]

> [54] Inovet © (09.08.12 17:10)
> [55] AV © (09.08.12 17:12)

> [29] ProgRAMmer Dimonych © (08.08.12 18:41)

Монитор может быть на нескольких узлах сети. Скажу больше: в реальности он есть на каждом узле. Список обязательных серверов - настройка личная, отдельная для каждого монитора. Проблема - в синхронизации списка в пределах одного узла.

← →
Сергей М. © (2012-08-09 17:50) [57]

> ProgRAMmer Dimonych © (09.08.12 17:17) [56]

Данные об узлах и списках, ассоциированных с каждым из этих узлов, будут храниться в одной-единственной БД.

Где в своей сети ты поднимешь СУБД и подключишь к ней БД - не суть как важно, главное чтобы все узлы имели доступ к СУБД-серверу.

← →
ProgRAMmer Dimonych © (2012-08-09 18:03) [58]

> [57] Сергей М. © (09.08.12 17:50)

Всего лишь ради того, чтобы 2-3 приложения, запущенные на одном и том же компе, могли сказать друг другу, что что-то изменилось, условно говоря, в настройках. :(

← →
AV © (2012-08-09 18:09) [59]

> ProgRAMmer Dimonych © (09.08.12 18:03) [58]

так зато _любой_ узел может узнать _всю_ топологию

← →
ProgRAMmer Dimonych © (2012-08-09 18:41) [60]

> [59] AV © (09.08.12 18:09)

Если СУБД не лежит.

Всего-то задача, чтобы каждый монитор умел помнить "своих" "в лицо" и работать в несколько копий на одном компе. Понимаю, что в принципе решение с ещё одним приложением (хоть СУБД, хоть велосипед) рабочее, но ощущение пушки не отпускает.

← →
Inovet © (2012-08-09 18:46) [61]

Ну а что с SQLite?

← →
Petr V. Abramov © (2012-08-09 19:01) [62]

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

так а в реестр, какой-нить appdata под юзером чем не подходит?

← →
ProgRAMmer Dimonych © (2012-08-09 19:03) [63]

> [61] Inovet © (09.08.12 18:46)

Ну так ведь карманная пушка :)

К тому же СУБД не позволяют получать уведомления о том, что данные в таблице изменились: при запуске программы из БД прочитал, а толку ноль, потому что главная проблема - согласование списков между процессами - не решена.

Решение с WM_COPYDATA, кстати, работает. Но только в пределах своей терминальной сессии. Обойти это ограничение - это реализовывать свою очередь сообщений. Либо поверх сокетов, либо поверх MMF, либо ещё как-нибудь. Проще уж менеджер кучи для MMF написать и весь список там держать.

Собственно, пока упираюсь в то, что не могу гарантировать доставку уведомления всем процессам-копиям. Event взвёл, а когда снимать - непонятно: количество копий неизвестно, считать - ненадёжно.

← →
ProgRAMmer Dimonych © (2012-08-09 19:12) [64]

> [62] Petr V. Abramov © (09.08.12 19:01)

Но вот отследить изменения... RegNotifyChangeKeyValue(), судя по описанию, не даст понять, какое именно изменение произошло, - значит. или опять полное перестроение, или супер-алгоритм сравнения. Опять же RegRestoreKey() она не отслеживает.

И, кстати, у другого юзера ведь другая ветка будет.

> [63] ProgRAMmer Dimonych © (09.08.12 19:03)
> К тому же СУБД не позволяют получать уведомления о том,
> что данные в таблице изменились:

Это почему. В ФБ можно.

← →
Андреевич (2012-08-09 19:45) [66]

а пайпы?

> [66] Андреевич (09.08.12 19:45)
> а пайпы?

Листал сегодня весь день MSDN и на пайпах особое внимание заострил. Там на кжадую пару процессов - свой пайп. А то же самое можно и на MMF сделать - проблемы синхронизации это не решает: определить, что все прочитали, доставить всем. К тому же по сложности реализации - те же сокеты: многопоточность организовать и всякое-такое. Из плюсов разве что масштабируемость какая-нибудь.

> [65] Inovet © (09.08.12 19:39)
> > [63] ProgRAMmer Dimonych © (09.08.12 19:03)
> > К тому же СУБД не позволяют получать уведомления о том,
> > что данные в таблице изменились:
> Это почему. В ФБ можно.

А подробнее?

> ProgRAMmer Dimonych © (09.08.12 18:03) [58]
>
> > [57] Сергей М. © (09.08.12 17:50)
>
> Всего лишь ради того, чтобы 2-3 приложения, запущенные на
> одном и том же компе

Тебя, барин, не поймешь)..
Ты кого вообще "хостом" обзываешь ?

> ощущение пушки не отпускает

FB в этом плане скорее женский браунинг, нежели, скажем Oracle-мортира)
Но в определенных условиях может стать и МБР.

> [70] Сергей М. © (09.08.12 21:16)
> > ProgRAMmer Dimonych © (09.08.12 18:03) [58]
> > > [57] Сергей М. © (09.08.12 17:50)
> > Всего лишь ради того, чтобы 2-3 приложения, запущенные
> на
> > одном и том же компе
> Тебя, барин, не поймешь)..
> Ты кого вообще "хостом" обзываешь ?

Кого хостом? Каким хостом?

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

Служба, установка которой делает компьютер "сервером", - она в единственном экземпляре. Клиенты между собой не подерутся, ибо друг о друге ничего не знают. А вот Мониторы могут быть запущены на одном компе в нескольких копиях (в разных терминальных сессиях, например) - и все копии в пределах данного компа должны работать с одинаковым списком "обязательных" записей.

На разных компах мониторы работают совершенно независимо, согласовать надо только в пределах одного компа - и здесь проблема. Потому и говорю, что СУБД порохом пахнет: уж больно громоздко для небольшой легковесной утилитки мониторинга.

> ProgRAMmer Dimonych © (09.08.12 20:11) [68]
> > [65] Inovet © (09.08.12 19:39)
> > > [63] ProgRAMmer Dimonych © (09.08.12 19:03)
> > > К тому же СУБД не позволяют получать уведомления о том,
>
> > > что данные в таблице изменились:
> > Это почему. В ФБ можно.
>
> А подробнее?
>
>

в Firebird вообще можно подключать свои dll (udf) в том числе писанные на делфи, регистрировать функции в FB и далее полет фантазии, можно нужную функцию на триггер повесить, а функция может делать ну все что угодно, вплоть до работы с сокетами и т.д. Но там есть и стандартный механизм уведомлений.

> Кого хостом? Каким хостом?

см. [6]

> [74] Сергей М. © (09.08.12 21:55)

Ну, по крайней мере в сегодняшних сообщениях под узлом я понимал физическую машинку. Только про [6] уже написали в [8], [9], [16] и т.д.

Доступ к INI-файлу из нескольких процессов Найти похожие ветки