Клиент-серверное приложение. Методы оповещения клиентов?
И так, опишу ситуацию:
Есть сервер, который производит операции с БД. Т.е. он отвечает за добавление/удаление и выборку нужной информации.
Есть ряд клиентов, которые работают с этой информацией.
У меня возникла проблема, как оповестить клиента о том, что было сделано какое-либо изменение?
Изначально я реализовывал данную возможность при помощи событий, но при 5-10 клиентов нагрузка на сервер была значительной и от этой идеи пришлось отказаться.
Я что-то слышал о методе пинга для клиент-серверных приложений. Насколько я понял, это когда клиент периодически посылает запрос на сервер на предмет изменений. Так вот, отсюда ряд проблем:
1) Как хранить добавленные/измененные/удаленные записи?
2) Как понять, что все клиенты уже получили данную запись...
ЗЫ: Изначально думал сделать так:
Каждая информация хранит в себе дату последнего изменения. У каждого клиента хранится эта дата последнего изменения (локальная статическая переменная). Клиент посылает запрос к серверу с этой датой и получает добавленную/удаленную или отредактированную информацию. Запрос этот идет раз 2-3 минуты. Но отсюда опять же возникает нюанс, либо мы всегда информацию проверяем таким образом, даже для локального обновления, т.е. клиент изменил запись, нажал сохранить, и она у него обновится только через эти 2-3 минуты, а не сразу, либо мы рискуем потерять часть записей. Т.к. при изменений даты последнего изменения, у клиента, мы рискуем потерять записи которые были изменены до этой даты.
ЗЫЫ: Хотелось бы услышать советы как можно сделать так, что бы изменения для клиента, который делает эти изменения, вносились моментально, а для остальных клиентов через эти 2-3 минуты, и так, что бы не нарушилась целостность информации.
Можно даже ссылки на документаху, у кого есть :-D
Либо посылать некое уведомление всем клиентам об изменении данных (но не конкретизируя что именно изменилось) а клиент уже будет решать, обновляться или нет, и если обновляться, то какие именно данные тягать с сервера.
Либо посылать некое уведомление всем клиентам об изменении данных (но не конкретизируя что именно изменилось) а клиент уже будет решать, обновляться или нет, и если обновляться, то какие именно данные тягать с сервера.
Хм...Вы читали, то что написано или нет?
Проверка изменения делается элементарным счетчиком. При изменении данных сервер увеличивает его, каждый клиент сверяет собственный счетчик с северным, если они расходятся - требуется подгрузить данные.
Какие это должны быть данные - решать вам, так как вы о них ничего не сказали.
А вы? У вас обычная проблема синхронизации и недостаточно данных для всеобъемлющего охвата поставленной задачи. Нет, например, ответа на вопрос - зачем? С какой целью? Посмотрите как работают любые многопользовательские БД-ориентированные приложения (чет на ум счас приходит только 1С..)
Счетчик - это хорошо. Получается, что если счетчик изменился, то мне необходимо подгружать все данные на сторону клиента/сервера, что бы их потом сравнивать - это дополнительная нагрузка на сеть, скажем так, лишняя пересылка информации.
to Phodopus:
А какой информации вам не достаточно?
Есть ряд клиентов, есть сервер.
Свящь один ко многим.
Надо, что бы все клиенты имели актуальную информацию. Если один из клиентов ее изменил, об этом должны узнать все остальные клиенты. Какой вам информации не достаточно?
Зачем? - Актуальность информации.
С какой целью? - цель, простая, надо, что бы каждый клиент имел актуальную информацию.
ЗЫ: Уточню, информация - это некий набор данных, который состоит из Текст + картинки, объем может достигать 2-3 метров (одной ячейки информации). Общий размер БД достигает 500 метров.
Есть ряд клиентов, есть сервер.
Свящь один ко многим.
Надо, что бы все клиенты имели актуальную информацию. Если один из клиентов ее изменил, об этом должны узнать все остальные клиенты. Какой вам информации не достаточно?
Зачем? - Актуальность информации.
С какой целью? - цель, простая, надо, что бы каждый клиент имел актуальную информацию.
ЗЫ: Уточню, информация - это некий набор данных, который состоит из Текст + картинки, объем может достигать 2-3 метров (одной ячейки информации). Общий размер БД достигает 500 метров.
а что в моем сообщении напрягает?
Счетчик - это хорошо. Получается, что если счетчик изменился, то мне необходимо подгружать все данные на сторону клиента/сервера, что бы их потом сравнивать - это дополнительная нагрузка на сеть, скажем так, лишняя пересылка информации.
Со счетчиком может быть связан журнал изменений, на основании которого клиент будет подгружать данные (каждое значение счетчика - некоторое изменение, похоже на SVN). Кроме того, нет никакой необходимости сразу прогружать полностью на клиента многие мегабайты данных, достаточно первоначально передавать ему их хэши ("контрольные суммы"), клиент по этим дайджестам сможет загрузить действительно изменившийся контент.
Да. Спасибо. Идея хорошая. как-то я об этом не подумал :)
Сегодня попробую сделать с журналом изменений. Завтра/Послезавтра напишу результаты, какой из методов подошел или не подошел и почему :-D
Когда информацию изменяет один человек - проблемы вообще не видно, она возникает только когда ее изменяют несколько человек (в svn это тот же конфликт). Вообще посмотрите как работают подобные системы, посмотрите - полезно. SVN, 1С, словом все где присутствует многопользовательская синхронизация.
В данном конкретном случае, думаю, топикстартер может ограничится принципом "кто успел того и тапки" (оптимистичная политика транзакции): фиксируется первое отправленное изменение, остальные клиенты получают ошибку сохранения (SVN в этом случае предлагает сказать update а потом merge).
А получилось следующее:
После долгого обдумывания алгоритма и чтения разныйх факов и доков, было выяснено, что WCF поддерживает колбэк функции и было принято решение именно ими и пользоваться. При подключении к серверу программа-клиент себя регистрирует, и с переодичностью 5-10 минут проверяет соединение. Если было произведено какое-то изменение, то вызывается функция для каждого клиента. Если соединение пропало, то программа-клиент его восстанвливает. Вот так все оказалось просто :)
и не только с языками но и с логикой... как относится это сообщение к теме топика?
Вот именно в этом, как мне кажется, и есть вся загвоздка. Лучше эти процессы осуществлять не сторонним приложением, а средствами самой СУБД.
В таком случае ваша реализация с событиями будет вполне уместной.