Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
ВнизДоступ к 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-а именованного?
← →
ProgRAMmer Dimonych © (2012-08-08 18:41) [29]> [25] antonn © (08.08.12 18:32)
Архитектуре уже лет 5, не меньше. Ещё до моего прихода писалось и развивалось. Ещё раз попробую обрисовать.
1. В сети есть компьютеры (серверы), которые обслуживают по сети другие компьютеры (клиенты). Здесь "многие ко многим".
2. Нужно мониторить, кто и кого обслуживает. Для этого есть сабжевое приложение (монитор), которое находит сервера, связывается с ними и запрашивает у них информацию об их клиентах. Здесь тоже "многие ко многим".
3. Компьютер может одновременно быть и сервером, и клиентом, и ещё мониторить.
4. Нахождение всех серверов требует времени, поэтому разрешено вручную задавать расположение некоторых серверов - эта информация каждым монитором складывается в свой INIшник.
5. Несколько копий монитора, работающих на одном узле, должны как-то синхронизировать свои списки серверов, заданных явно.
← →
ProgRAMmer Dimonych © (2012-08-08 18:43) [30]> [28] Rouse_ © (08.08.12 18:40)
Один - для синхронизации доступа к разделяемому ресурсу, второй - для уведомления о его изменении.
← →
Медвежонок Пятачок © (2012-08-08 18:44) [31]ну в общем работать с инишником (если он останется) нужно через процесс посредника вот и все.
← →
Rouse_ © (2012-08-08 18:46) [32]
> ProgRAMmer Dimonych © (08.08.12 18:43) [30]
Хм, логично, но избыточно... Пользователю будет монопенисюально, отобразятся ли ему изменения немедленно или по секундному таймеру :)
← →
ProgRAMmer Dimonych © (2012-08-08 18:54) [33]> [32] Rouse_ © (08.08.12 18:46)
Навело на мысль о пересмотре способа работы с INIшником. Пока не сформулирую: обдумываю все ходы.
← →
antonn © (2012-08-08 18:56) [34]
> ProgRAMmer Dimonych © (08.08.12 18:41) [29]
явно заданые сервера - они должны быть едины для всех копий программы использующей этот список?
ЗЫ я бы таки сделал сетевую службу предоставляющую такой список. Более того, если есть возможность, на каждом сервере поднять простую программу уведомляющую службу-список о том что сервер с адресом таким-то находится в сети, и использовать эти данные для более быстрого заполнения списка. Каждый сервер сам уведомит о своем адресе. Типа агрегатор получится :)
← →
antonn © (2012-08-08 18:57) [35]хотя возможно я увлекся и стреляю по воробьям из пушки =)
← →
antonn © (2012-08-08 18:59) [36]
> Типа агрегатор получится :)
да и вообще поиск серверов тоже можно поручить такой службе, по таймеру например это делать, смотря что там в поиске делать надо :) а она будет отдавать готовый список в удобном формате (ini, xml)
← →
ProgRAMmer Dimonych © (2012-08-08 19:05) [37]> [34] antonn © (08.08.12 18:56)
> [35] antonn © (08.08.12 18:57)
Да, список для копий программы, работающих на одном узле, должен быть одинаковым. Иначе отдельная головная боль - вопросы, связанные с уникальностью записей и т.п. Проще предотвратить, чем писать навороченные алгоритмы для определения, что с чем дублируется и кого надо из списка удалить.
Вся система исторически наоборот движется скорее к p2p. Возможно, ошибочно. Сейчас серверы сообщают о себе бродкастом напрямую мониторам. Это позволяет любой компьютер добавить/перенести/убрать в/из сеть/сети - и это пройдёт прозрачно для пользователей. Делать централизованную систему сбора списка серверов - довольно расточительно, особенно при том, что явно заданные серверы - это лишь надстройка над успешно работающей системой. Хотя в p2p вроде тоже случается некоторым узлам быть главнее?
← →
ProgRAMmer Dimonych © (2012-08-08 19:08) [38]> [36] antonn © (08.08.12 18:59)
От таймера как раз давно ушли: получить список всех серверов, работающих на порту с конкретным номером и способных получить UDP-датаграмму, - это почти моментально. Получилось вкусно.
А явное задание серверов было в первую очередь для того, чтобы найти тех, которые могут обслужить, но не получат UDP-датаграмму. Маршрутизация...
← →
ProgRAMmer Dimonych © (2012-08-09 12:39) [39]Вдогонку.
В ходе выбора возможного решения пришёл к тому, чтобы уведомлять другие копии приложения об отдельных изменениях. Но проблема: в MMF, например, записали информацию о последней выполненной операции, event взвели, копии приложения начинают читать. Как узнать, когда они закончили? Намечается либо достаточно запутанная синхронизация с тормозами, либо что-нибудь не менее запутанное lock-free.
Дальше следующая идея: а почему бы не воспользоваться очередью сообщений Windows? Не надо беспокоиться о том, что приложение вылетит, оставив залоченными всех остальных, не надо ждать, пока пройдёт полная обработка...
1. Везде, где я вижу упоминание WM_COPYDATA, речь идёт о SendMessage(). Можно ли отправить его с помощью PostMessage()?
Чтобы не ждать, пока завершится долгая и мучительная обработка. Тем более, что слать придётся многим окнам.
Дальнейшие размышления и гуглёж привели меня к DDE.
2. Часто встречается утверждение, что DDE устарел. Что из более новых технологий позволяет с минимальным оверхедом отправить пару килобайт данных в соседний процесс с помещением в очередь?
3. Раньше с DDE не работал, поверхностный осмотр показал, что отправкой одного сообщения там дело не обойдётся - а значит, придётся писать много кода. Можно ли в пределах своего приложения упростить?
← →
ProgRAMmer Dimonych © (2012-08-09 12:42) [40]Упс, про PostMessage нагуглил. Остальные вопросы актуальны, как и рекомендации по теме передачи куска данных в соседний процесс.
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.57 MB
Время: 0.074 c