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

← →
ProgRAMmer Dimonych © (2012-08-08 17:32) [0]

Приложение управляет списком записей об объектах сети. Записи могут быть двух типов: одни создаются автоматически по мере получения информации из сети ("обычные"), другие - задаются пользователем явно ("обязательные"). Информация о задаваемых пользователем объектах сохраняется в INI-файл. Все записи (и обычные, и обязательные) визуализируются в UI. Для одной копии приложения всё просто: изменили набор обязательных записей - сразу записали в INIшник и отобразили в UI.

Задача состоит в том, чтобы обеспечить возможность совместной работы нескольких копий приложения. Причём добавление/удаление обязательной записи в одной копии приложения должно подхватываться во всех остальных. Вижу несколько возможных решений:

1. Создавать memory-mapped file и держать там бинарную версию списка записей.
2. Синхронизировать доступ к INI-файлу мьютексом, уведомлять о необходимости повторного чтения event"ом.
3. Вариации на тему пайпов или сокетов.

Пока склоняюсь к варианту №2.

Хотелось бы мнения со стороны :)

← →
Dimka Maslov © (2012-08-08 17:54) [1]

Создаётся отдельный процесс (сервер), который управляет записями (можно служба). Копии приложения обращаются (любым доступным способом межпроцессорного взаимодействия) с сервером.

← →
Медвежонок Пятачок © (2012-08-08 17:57) [2]

а зачем там вообще больше одного процесса? больше одной копии одной и той же программы?

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

> [2] Медвежонок Пятачок © (08.08.12 17:57)

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

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

> [1] Dimka Maslov © (08.08.12 17:54)

Трудозатратно - боюсь, не одобрят.

← →
Rouse_ © (2012-08-08 18:04) [5]

+1 к

> Dimka Maslov © (08.08.12 17:54) [1]

← →
Медвежонок Пятачок © (2012-08-08 18:06) [6]

тогда при чем здесь мьютексы или ммф?

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

← →
DVM © (2012-08-08 18:08) [7]

> ProgRAMmer Dimonych © (08.08.12 17:32)

если без служб то второе, но вот по поводу уведомлений есть сомнение, что ReadDiretoryChanges не поймает изменение инишника на середине, т.е. главное чтоб он в 2 и более приемом на диск не сбрасвался.

← →
DVM © (2012-08-08 18:09) [8]

> Медвежонок Пятачок © (08.08.12 18:06) [6]

> если одновременно работают несколько пользователей, то стало
> быть они сидят за разными компами.

на сервере это не так

← →
antonn © (2012-08-08 18:10) [9]

> если одновременно работают несколько пользователей, то стало
> быть они сидят за разными компами.

терминальный сервер

← →
Rouse_ © (2012-08-08 18:10) [10]

> Трудозатратно - боюсь, не одобрят.

Да брось - минут 15 работы программиста с отладкой. Отговорки все это.

← →
DVM © (2012-08-08 18:11) [11]

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

← →
Медвежонок Пятачок © (2012-08-08 18:12) [12]

на сервере это не так

ну тогда снова вопрос номер один:

нахрена там несколько одинаковых процессов?

они что, увеличат число ядер проца, или пропускную сетки повысят и все завертится быстрее?

← →
Rouse_ © (2012-08-08 18:12) [13]

> Трудозатратно - боюсь, не одобрят.

Оть тебе как пример ради смеха, береш эту демку: http://rouse.drkb.ru/network.php#fwiocompletionpipe
переписываешь сервер чтобы он отдавал по запросу содержимое инишника и умер перезаписывать по команде от нового клиента. И собственно все - вот тебе и отдельный сервер, 10-15 минут работы на причесывание.

← →
antonn © (2012-08-08 18:12) [14]

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

← →
antonn © (2012-08-08 18:15) [15]

> Медвежонок Пятачок © (08.08.12 18:12) [12]
>
> на сервере это не так
>
> ну тогда снова вопрос номер один:
>
> нахрена там несколько одинаковых процессов?

"нахрена" объясняется очень просто - видимо кроме хранения данных в ини и их визуализации требуется еще какая-то работа в этом самом приложении

← →
DVM © (2012-08-08 18:16) [16]

> Медвежонок Пятачок © (08.08.12 18:12) [12]

> нахрена там несколько одинаковых процессов?

а нахрена вообще терминальные сервера?

← →
MsGuns © (2012-08-08 18:16) [17]

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

← →
Медвежонок Пятачок © (2012-08-08 18:17) [18]

требуется еще какая-то работа в этом самом приложении

так это первичный дизайн прилады кривой значит.

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

← →
ProgRAMmer Dimonych © (2012-08-08 18:25) [19]

Господа, господа! Сие приложение - лишь часть системы. Мониторит софтина как раз службы, запущенные на других компах сети. В состав системы входит ещё несколько программулин. Добавлять туда ещё одну - это самый-самый крайний вариант.

> [7] DVM © (08.08.12 18:08)
>
> > ProgRAMmer Dimonych © (08.08.12 17:32)
>
> если без служб то второе, но вот по поводу уведомлений есть
> сомнение, что ReadDiretoryChanges не поймает изменение инишника
> на середине, т.е. главное чтоб он в 2 и более приемом на
> диск не сбрасвался.

Вариант 2 я вижу так.

Писатель
1. Захватить мьютекс.
2. Записать в файл.
3. Установить event.
4. Освободить мьютекс.

Читатель
Ждёт на event"е. Когда дожидается:
1. Захватить мьютекс.
2. Прочитать из файла.
3. Освободить мьютекс.

Момент обновления данных отслеживается без проблем. Смущает то, что для 3+ процессов понадобятся пляски с несколькими event"ами или с семафором - то раз. И два: проблема в том, что нужно будет при чтении файла каждый раз половину списка перестраивать - весьма дорогостоящая операция, т.к. связана с обращениями в сеть. Поэтому, кстати, не исключаю и варианты 1 и 3: чтобы обмениваться только изменениями, а не полным списком.

Собственно, вот и хотел поинтересоваться, как такую задачу решают другие.

← →
antonn © (2012-08-08 18:25) [20]

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

я думаю не стоит пытаться телепатировать при отсутствии предрасположенности к этому :)

Просто пример: сотня sql-серверов, для коннекта рабочей программы к нему используется параметр запуска (адрес+БД передается). Список серверов хранится на отдельном сервере и отдается через сокет программе, в которой список отображается, может редактироваться, из этой программы запускается рабочий софт подставляя параметры коннекта к скулям из этого списка. Типа рабочее место администратора, администраторов несколько, список один. Процессов "нахрена" тоже несколько, думаю понятно почему.

← →
ProgRAMmer Dimonych © (2012-08-08 18:26) [21]

> [17] MsGuns © (08.08.12 18:16)
> Смотря что в этих инишках (Информация о задаваемых пользователем
> объектах) хранится, а также в каком режиме должна крутиться
> учетная система.
> Если хранится что-то большое и серьезное или нельзя зависеть
> от ПК, где запущен "учет", не должно быть привязки к ПК
> вообще, или большое кол-во пользователей, или работа "учета"
> круглосуточно и т.д., то надо явно уклон к скл-серверу.

В INIШниках - условно говоря, хостнейм и порт. Для каждой записи.

← →
ProgRAMmer Dimonych © (2012-08-08 18:27) [22]

> [15] antonn © (08.08.12 18:15)
> "нахрена" объясняется очень просто - видимо кроме хранения
> данных в ини и их визуализации требуется еще какая-то работа
> в этом самом приложении

Да, не акцентировал на этом внимание. Каждая запись соответствует узлу сети, от которого периодически получается определённая информация.

← →
ProgRAMmer Dimonych © (2012-08-08 18:29) [23]

> [20] antonn © (08.08.12 18:25)

Близко. Только здесь список не хранится, а каждый раз создаётся на лету. А чтобы самые важные сервера находились быстрее, их разрешено задавать явно.

← →
Медвежонок Пятачок © (2012-08-08 18:31) [24]

вы смешали в кучу разные вещи.

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

← →
antonn © (2012-08-08 18:32) [25]

> В INIШниках - условно говоря, хостнейм и порт. Для каждой
> записи.

сейчас это уже ini, или архитектуру еще предстоит написать?

(у меня, пример выше в [20], отдельная служба с вебсервером отдает тоже ini, программы запрашивают данные у нее (по http). в самих программах предусмотрена загрузка ini из файла (т.е. ядру обрабатывающему этот ini данные отдает либо класс получения файла из сети по http, либо класс считывающий его из файла). ну а на сервере все хранится в sqlite, служба лишь отдает в нужном формате их, всегда актуальные данные)

← →
Медвежонок Пятачок © (2012-08-08 18:33) [26]

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

← →
antonn © (2012-08-08 18:34) [27]

> [25]

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

← →
Rouse_ © (2012-08-08 18:40) [28]

> Собственно, вот и хотел поинтересоваться, как такую задачу
> решают другие.

Нафига два объекта синхронизации когда достаточно Event-а именованного?

> [25] antonn © (08.08.12 18:32)

Архитектуре уже лет 5, не меньше. Ещё до моего прихода писалось и развивалось. Ещё раз попробую обрисовать.

1. В сети есть компьютеры (серверы), которые обслуживают по сети другие компьютеры (клиенты). Здесь "многие ко многим".
2. Нужно мониторить, кто и кого обслуживает. Для этого есть сабжевое приложение (монитор), которое находит сервера, связывается с ними и запрашивает у них информацию об их клиентах. Здесь тоже "многие ко многим".
3. Компьютер может одновременно быть и сервером, и клиентом, и ещё мониторить.
4. Нахождение всех серверов требует времени, поэтому разрешено вручную задавать расположение некоторых серверов - эта информация каждым монитором складывается в свой INIшник.
5. Несколько копий монитора, работающих на одном узле, должны как-то синхронизировать свои списки серверов, заданных явно.

> [28] Rouse_ © (08.08.12 18:40)

Один - для синхронизации доступа к разделяемому ресурсу, второй - для уведомления о его изменении.

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

> ProgRAMmer Dimonych © (08.08.12 18:43) [30]

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

> [32] Rouse_ © (08.08.12 18:46)

Навело на мысль о пересмотре способа работы с INIшником. Пока не сформулирую: обдумываю все ходы.

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

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

ЗЫ я бы таки сделал сетевую службу предоставляющую такой список. Более того, если есть возможность, на каждом сервере поднять простую программу уведомляющую службу-список о том что сервер с адресом таким-то находится в сети, и использовать эти данные для более быстрого заполнения списка. Каждый сервер сам уведомит о своем адресе. Типа агрегатор получится :)

хотя возможно я увлекся и стреляю по воробьям из пушки =)

> Типа агрегатор получится :)

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

> [34] antonn © (08.08.12 18:56)
> [35] antonn © (08.08.12 18:57)

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

Вся система исторически наоборот движется скорее к p2p. Возможно, ошибочно. Сейчас серверы сообщают о себе бродкастом напрямую мониторам. Это позволяет любой компьютер добавить/перенести/убрать в/из сеть/сети - и это пройдёт прозрачно для пользователей. Делать централизованную систему сбора списка серверов - довольно расточительно, особенно при том, что явно заданные серверы - это лишь надстройка над успешно работающей системой. Хотя в p2p вроде тоже случается некоторым узлам быть главнее?

> [36] antonn © (08.08.12 18:59)

От таймера как раз давно ушли: получить список всех серверов, работающих на порту с конкретным номером и способных получить UDP-датаграмму, - это почти моментально. Получилось вкусно.

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

Вдогонку.

В ходе выбора возможного решения пришёл к тому, чтобы уведомлять другие копии приложения об отдельных изменениях. Но проблема: в MMF, например, записали информацию о последней выполненной операции, event взвели, копии приложения начинают читать. Как узнать, когда они закончили? Намечается либо достаточно запутанная синхронизация с тормозами, либо что-нибудь не менее запутанное lock-free.

Дальше следующая идея: а почему бы не воспользоваться очередью сообщений Windows? Не надо беспокоиться о том, что приложение вылетит, оставив залоченными всех остальных, не надо ждать, пока пройдёт полная обработка...

1. Везде, где я вижу упоминание WM_COPYDATA, речь идёт о SendMessage(). Можно ли отправить его с помощью PostMessage()?
Чтобы не ждать, пока завершится долгая и мучительная обработка. Тем более, что слать придётся многим окнам.

Дальнейшие размышления и гуглёж привели меня к DDE.

2. Часто встречается утверждение, что DDE устарел. Что из более новых технологий позволяет с минимальным оверхедом отправить пару килобайт данных в соседний процесс с помещением в очередь?
3. Раньше с DDE не работал, поверхностный осмотр показал, что отправкой одного сообщения там дело не обойдётся - а значит, придётся писать много кода. Можно ли в пределах своего приложения упростить?

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

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