2010-10-01 2 views
2

У меня есть приложение Delphi 2006, которое собирает данные и отображает его как сводку по многим каналам, по одному каналу в строке на TDrawGrid. У меня такое же приложение работает на других ПК в сети, но эти другие ПК являются подчиненными - они не собирают данные, а просто предоставляют удаленное отображение сводки.Совместное использование общей области памяти в Delphi между ПК

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

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

Могу ли я использовать некоторую схему общей памяти для переноса данных в файл с отображением памяти, где подчиненные устройства могут иметь доступ из любого места (через Интернет, даже)? Мы говорим о размере памяти размером 100 тыс. Байт, скажем, обновляемом мастером примерно один раз в секунду, возможно, в потоке, чтобы задача мастера переднего плана была отзывчивой.

ответ

2

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

Использование простого файла имеет то преимущество, что оно не требует какого-либо дополнительного программного обеспечения (например, сервера daetabase или некоторого промежуточного программного обеспечения) в соответствии с принципом KISS. Но, конечно, это далеко не сексуально ;-) и не использует правильную технологию модного слова.

+0

Не могли ли стандартные механизмы доступа к файлам Windows предотвращать грязные чтения? Иногда раб не мог получить данные, но это не было бы реальной проблемой. Грязные чтения не имеют значения, поскольку они будут заменены на следующем опросе мастера в любом случае. Предположительно, чтение и запись кэширования диска в главном случае означало бы, что большинство обращений к файлу было бы прочитано или записано в память в любом случае? – rossmcm

+0

@ user89691: Это зависит от того, как открывается файл и используются ли какие-либо механизмы блокировки. Самый простой способ заключается в том, чтобы мастер открыл файл write/allow read и ведомые пользователи readonly/allow read/write. Но это позволит грязным чтениям. Другие открытые флаги могут предотвращать грязные чтения, но тогда обе стороны должны обрабатывать ошибки, связанные с доступом. – dummzeuch

+0

Что же такое грязное чтение? Вы говорите, что если мастер находился в процессе обновления файла «write/allow read», а ведомое устройство читало его, ведомое устройство могло бы получить половину старых данных и половину новых данных? Я думал, что операционная система хотя бы записывает запись как атомную. Если это не так, будет ли подходящий механизм блокировки открыть файл как «Write/deny read», обновить данные, закрыть файл (и заставить подчиненный справиться со временем, когда он coudlnt получит данные)? – rossmcm

2

Вы можете использовать базу данных, такую ​​как DBISAM, Firebird и т. Д. С помощью DBISAM я использовал трюк для чтения первых 8 байтов файла базы данных, который кажется заголовком. Если он изменится, я знаю, что данные в таблице изменились, иначе это не так. Вы можете использовать это в клиенте, если используете цикл опроса, или если вы хотите продолжать использовать почтовые ящики в качестве метода уведомления. т. е. опросить файл каждые 10 секунд или по уведомлению по почте, в зависимости от того, что наступит раньше.

0

Мы используем MSMQ для чего-то подобного.

4

Общая память не работает через Интернет (если только вы не запускаете VPN), и она не работает хорошо по сети в целом (представления могут быть десинхронизированы, и вы не можете синхронизировать их по сети).

Я вижу несколько решений для Вашей задачи:

Вариант 1. Используйте промежуточное ПО, ориентированное на обработку сообщений (MOM), такие как MSMQ, kbmMW, наш MsgConnect транслировать уведомления, которые включают только изменения в данных. Таким образом, клиентам не нужно будет дополнительно опросить сервер для моментального снимка данных. Все решения MOM используют TCP-соединения для операций, и это более надежно, чем почтовые ящики.

Вариант 2. Использование некоторых клиент-серверных СУБД, возможно, тот, который поддерживает уведомления клиентам (я не эксперт в DMBS, поэтому я не могу сказать вам имена).

2

Что случилось с использованием TCP/IP? Вы можете использовать Indy (поставляется с Delphi уже) или ICS, чтобы ваше основное (основное) приложение отвечало на запросы IP (например, HTTP или ICMP или что-то, что подходит вашим потребностям в данных) с потоком или двумя, и иметь «подчиненный» «приложения просто запрашивают данные через IP-адрес мастера на конкретном порту. Это будет работать в интрасети или через Интернет прозрачно.