Доступ до INI-файлу з декількох процесів
Додаток управляє списком записів про об'єкти мережі. Записи можуть бути двох типів: одні створюються автоматично у міру отримання інформації з мережі ( "звичайні"), інші - задаються користувачем явно ( "обов'язкові"). Інформація про задаються користувачем об'єктах зберігається в INI-файл. Всі записи (і звичайні, і обов'язкові) візуалізуються в UI. Для однієї копії додатку все просто: змінили набір обов'язкових записів - відразу записали в INIшнік і відобразили в UI.
Завдання полягає в тому, щоб забезпечити можливість спільної роботи декількох копій програми. Причому додавання / видалення обов'язкового запису в одній копії додатку повинно підхоплюватися у всіх інших. Бачу кілька можливих рішень:
1. Створювати memory-mapped file і тримати там бінарну версію списку записів.
2. Синхронізувати доступ до INI-файлу м'ютексів, повідомляти про необхідність повторного читання event "ом.
3. Варіації на тему пайпов або сокетів.
Поки схиляюся до варіанту №2.
Хотілося б думки з боку :)
Створюється окремий процес (сервер), який управляє записами (можна служба). Копії додатки звертаються (будь-яким доступним способом межпроцессорного взаємодії) з сервером.
а навіщо там взагалі більше одного процесу? більше однієї копії однієї і тієї ж програми?
тоді до чого тут м'ютекси або ММФ?
якщо одночасно працюють кілька користувачів. то стало бути вони сидять за різними комп'ютерами.
> Якщо одночасно працюють кілька користувачів, то стало
> Бути вони сидять за різними комп'ютерами.
термінальний сервер
> Трудомісткий - боюся, не схвалять.
Та облиш - хвилин 15 роботи програміста з налагодженням. Відмовки все це.
Взагалі є ще варіант, в інішніке заводимо поле версія. Усі працюючі з інішніком (а він захищений м'ютексів) повинні після зміни інкременіровать поле версія. Інші перечитують регулярно інішнік і дивляться чи не змінилася версія, якщо змінилася оновлюють свої значення.
на сервері це не так
ну тоді знову питання номер один:
нахрена там кілька однакових процесів?
вони що, збільшать число ядер проца, або пропускну сітки підвищать і все закрутиться швидше?
+1 до служби, при необхідності спілкування можна зробити через сокети і навіть винести службу на інший сервер (ну це так, фінт вухами =))
Дивлячись що в цих інішках (Інформація про задаються користувачем об'єктах) зберігається, а також в якому режимі повинна крутитися облікова система.
Якщо зберігається щось велике і серйозне або не можна залежати від ПК, де запущений "облік", не повинно бути прив'язки до ПК взагалі, або велику кількість користувачів, або робота "обліку" цілодобово і т.д. то треба явно ухил до скл-сервера.
потрібно ще якась робота в цьому самому додатку
так це первинний дизайн приладнати кривої означає.
якщо він такий, що там надмірне вимога по інтерактиву з користувачем.
саме його і треба правити, замість наніманія ще кількох людей для роботи з нееффетівной програмою.
Панове, панове! Це додаток - лише частина системи. Моніторить софтіна якраз служби, запущені на інших компах мережі. До складу системи входить ще кілька программуліна. Додавати туди ще одну - це самий-самий крайній варіант.
письменник
1. Захопити м'ютекс.
2. Записати в файл.
3. Встановити event.
4. Звільнити м'ютекс.
читач
Чекає на event "е. Коли чекає:
1. Захопити м'ютекс.
2. Прочитати з файлу.
3. Звільнити м'ютекс.
Момент поновлення даних відстежується без проблем. Бентежить те, що для 3+ процесів знадобляться танці з декількома event "ами або з семафором - то раз. І два: проблема в тому, що потрібно буде при читанні файлу кожен раз половину списку перебудовувати - дуже дорога операція, тому що пов'язана зі зверненнями в мережу. Тому, до речі, не виключаю і варіанти 1 і 3: щоб обмінюватися тільки змінами, а не повним списком.
Власне, ось і хотів поцікавитися, як таке завдання вирішують інші.
> Так це первинний дизайн приладнати кривої означає.
>
> Якщо він такий, що там надмірне вимога по інтерактиву
> З користувачем.
> Саме його і треба правити, замість наніманія ще кількох
> Людина для роботи з нееффетівной програмою.
я думаю не варто намагатися телепатіровать при відсутності схильності до цього :)
ви змішали в купу різні речі.
моніторити щось там може один єдиний процес.
а якщо потрібна ще робота, то цей же процес оповіщає адмінів, які повинні користуватися іншими програмами, в яких не вимагається такий чарівний інішнік.
> В INIШніках - умовно кажучи, хостнейм і порт. Для кожного
> Записи.
Зараз це вже ini, або архітектуру ще належить написати?
(У мене, приклад вище в [20], окрема служба з веб-сервера віддає теж ini, програми запитують дані у неї (по http). В самих програмах передбачена завантаження ini з файлу (тобто ядра обробляє цей ini дані віддає або клас отримання файлу з мережі по http, або клас зчитує його з файлу). ну а на сервері все зберігається в sqlite, служба лише віддає в потрібному форматі їх, завжди актуальні дані)
в загальному в будь-якому випадку схоже, що ваша система спроектована з претензією на розумність, але ось таке застосування інішніка в ній - це відвертий колгосп. потрібно позбутися від нього.
> # XA0; [25]
ну і відповідно даних як таких передається трохи і софт може працювати з будь-якого комп'ютера підприємства (і під терміналкой теж).
> Власне, ось і хотів поцікавитися, як таке завдання
> Вирішують інші.
Нафіга два об'єкти синхронізації коли досить Event-а іменованого?
1. В мережі є комп'ютери (сервери), які обслуговують по мережі інші комп'ютери (клієнти). Тут "багато до багатьох".
2. Потрібно моніторити, хто і кого обслуговує. Для цього є сабжевое додаток (монітор), яке знаходить сервера, зв'язується з ними і запитує у них інформацію про їхніх клієнтів. Тут теж "багато до багатьох".
3. Комп'ютер може одночасно бути і сервером, і клієнтом, і ще моніторити.
4. Знаходження всіх серверів вимагає часу, тому дозволено вручну задавати розташування деяких серверів - ця інформація кожним монітором складається в свій INIшнік.
5. Кілька копій монітора, що працюють на одному вузлі, повинні якось синхронізувати свої списки серверів, заданих явно.
ну в загальному працювати з інішніком (якщо він залишиться) потрібно через процес посередника ось і все.
хоча можливо я захопився і стріляю по горобцях з гармати =)
> Типу агрегатор вийде :)
та й взагалі пошук серверів теж можна доручити такій службі, за таймером наприклад це робити, дивлячись що там в пошуку робити треба :) а вона буде віддавати готовий список в зручному форматі (ini, xml)
Вся система історично навпаки рухається швидше до p2p. Можливо, помилково. Зараз сервери повідомляють про себе бродкастом безпосередньо моніторів. Це дозволяє будь-який комп'ютер додати / перенести / прибрати в / з мережу / мережі - і це пройде прозоро для користувачів. Робити централізовану систему збору списку серверів - досить марнотратно, особливо при тому, що явно задані сервери - це лише надбудова над успішно працюючою системою. Хоча в p2p начебто теж трапляється деяким вузлам бути головнішим?
А явне завдання серверів було в першу чергу для того, щоб знайти тих, які можуть обслужити, але не отримають UDP-датаграмму. Маршрутизація.
Далі наступна ідея: а чому б не скористатися чергою повідомлень Windows? Не треба турбуватися про те, що додаток вилетить, залишивши залоченним всіх інших, не треба чекати, поки пройде повна обробка.
Подальші роздуми і гуглёж привели мене до DDE.
2. Часто зустрічається твердження, що DDE застарів. Що з більш нових технологій дозволяє з мінімальним оверхедів відправити пару кілобайт даних в сусідній процес з приміщенням в чергу?
3. Раніше з DDE не працював, поверхневий огляд показав, що відправкою одного повідомлення там справа не обійдеться - а значить, доведеться писати багато коду. Чи можна в межах свого застосування спростити?
Упс, про PostMessage нагугліть. Решта питання актуальні, як і рекомендації по темі передачі шматка даних в сусідній процес.
Пам'ять: 0.84 MB
Час: 0.145 c