Доступ к 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 нагуглил. Остальные вопросы актуальны, как и рекомендации по теме передачи куска данных в соседний процесс.

← →
Андреевич (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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну а что с SQLite?

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

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

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

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

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

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

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

> [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-файлу из нескольких процессов Найти похожие ветки