Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 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.07 c
15-1339158733
oxffff
2012-06-08 16:32
2013.03.22
Производственный календарь. Если web сервис бесплатный?


15-1336042075
john mc'coffe
2012-05-03 14:47
2013.03.22
java tcp client


15-1339145696
Инокентий
2012-06-08 12:54
2013.03.22
Задача по Excel


2-1338103675
Pcrepair
2012-05-27 11:27
2013.03.22
Application.ProcessMessages и загрузка процессора


15-1339245975
AV
2012-06-09 16:46
2013.03.22
О фильмах про зомби





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский