Система предотвращения несанкционированного доступа, содержащая множество серверных узлов и способ совместного использования данных в этой системе

Изобретение относится к системе физической защиты, содержащей множество серверных узлов. Технический результат – обеспечение совместного использования данных в системе физической защиты без использования центрального сервера. Предложен способ совместного использования данных в системе физической защиты, содержащей множество серверных узлов, причем способ включает обращение, с использованием одного из серверных узлов, к идентификатору узла, идентифицирующего другой серверный узел, причем первый и второй узлы составляют по меньшей мере часть кластера серверов и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов, передачу данных из первого узла на второй узел; и добавление нового серверного узла к кластеру серверов, причем добавление включает обмен версии информации о составе кластера, хранящейся на новом серверном узле, с версией информации о составе кластера, хранящейся на одном из серверных узлов, который уже является частью кластера серверов, и синхронизацию версии информации о составе кластера, хранящейся на новом серверном узле, с версиями информации о составе кластера, хранящимися на всех серверных узлах, которые составляют часть кластера, прежде чем новый серверный узел присоединится к кластеру. 3 н. и 17 з.п. ф-лы, 12 ил., 1 табл.

 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННУЮ ЗАЯВКУ

[0001] Настоящая заявка является частичным продолжением заявки США №13/607,447, поданной 7 сентября 2012 г., содержание которой полностью вводится здесь ссылкой в настоящую заявку.

ОБЛАСТЬ ТЕХНИКИ

[0002] Настоящее изобретение относится к системе физической защиты, содержащей множество серверных узлов.

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

[0003] Система физической защиты - это система, осуществляющая мероприятия по предотвращению физического доступа людей, не имеющих разрешения, к объекту, такому как здание, промышленное предприятие или источник конфиденциальной информации. Примеры таких систем включают: системы наблюдения, содержащие видеокамеры для контроля объекта и прилегающей к нему зоны; системы управления доступом, например, системы, в которых в которых используются карточки с радиометками для управления доступом в здание; системы обнаружения проникновения, такие как охранные системы для жилищ, а также комбинации вышеуказанных систем.

[0004] Система физической защиты часто содержит компьютеры. По мере расширения такой системы возрастает и вычислительная мощность, необходимая для ее работы. Например, по мере роста количества видеокамер в системе наблюдения, необходимая вычислительная мощность также возрастает для обеспечения возможности хранения дополнительных видеоматериалов, а также одновременного использования и управления увеличенным количеством видеокамер. Соответственно, осуществляются исследования и разработки, направленные на преодоление проблем, возникающих при расширении систем физической защиты.

[0005] В настоящем изобретении предлагается способ совместного использования данных в системе физической защиты, содержащей множество серверных узлов. Способ включает: выборку с использованием одного из серверных узлов ("первый узел") идентификатора узла, идентифицирующего другой серверный узел ("второй узел"), причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов; и передачу данных из первого узла на второй узел.

[0006] Кластер серверов может содержать по меньшей мере три серверных узла.

[0007] Серверные узлы могут содержать видеокамеры, сетевые видеомагнитофоны и серверы управления доступом.

[0008] Способ может также включать выборку с использованием второго узла идентификатора узла, идентифицирующего первый узел; и передачу дополнительных данных из второго узла на первый узел.

[0009] Информация о составе кластера может содержать идентификатор узла, однозначным образом идентифицирующий каждый серверный узел в кластере серверов; и идентификатор кластера, однозначным образом идентифицирующий кластер серверов, к которому принадлежат серверные узлы.

[0010] Каждый серверный узел в кластере серверов может хранить локально и постоянно обновлять свою собственную версию информации о составе кластера.

[0011] Способ может также включать: перезагрузку одного из серверных узлов ("перезагруженный серверный узел") в кластере серверов; и, после возвращения перезагруженного серверного узла в режим онлайн, использование этого узла для осуществления способа, включающего: i) выборку идентификатора кластера, идентифицирующего кластер серверов; и ii) повторное присоединение к кластеру серверов в автоматическом режиме.

[0012] Способ может также включать: добавление нового серверного узла к кластеру серверов путем осуществления следующих действий: обмен версии информации о составе кластера, записанной на новом серверном узле, с версией информации о составе кластера, записанной на одном из серверных узлов, который уже является частью кластера серверов ("узел управления составом кластера"); и синхронизация версий информации о составе кластера, записанных на новом серверном узле с версиями информации о составе кластера, записанных на всех серверных узлах кластера, прежде чем новый серверный узел присоединится к кластеру.

[0013] Передача данных может включать поиск по идентификатору узла, с использованием первого узла, оконечного устройства связи для второго узла; и передачу данных из первого узла в это оконечное устройство связи.

[0014] Оконечному устройству связи и идентификатору узла может соответствовать запись в карте сети, связывающей идентификаторы узлов для всех серверных узлов в кластере серверов с соответствующими оконечными устройствами связи, и каждый серверный узел в кластере узлов может хранить локально и постоянно обновлять свою собственную версию карты сети.

[0015] Карта сети может обеспечивать возможность каждому из серверных узлов в кластере серверов передавать данные любому из остальных серверных узлов в кластере серверов без использования центрального сервера.

[0016] Данные могут быть записаны локально на первом узле, и способ может включать также модификацию данных с использованием первого узла, причем передача данных из первого узла на второй узел составляет часть процесса синхронизации данных на первом и втором узлах после модификации этих данных первым узлом.

[0017] Данные могут содержать информацию версии, сформированную с использованием причинного механизма формирования версий (causality versioning mechanism), причем на первом и втором узлах могут храниться разные версии данных, и синхронизация данных может включать сравнение информации версий, записанных на первом и втором узлах, и принятие на обоих узлах тех данных, для которых информация версии указывает на то, что это наиболее свежие данные.

[0018] Данные могут содержать идентификатор первого узла, информацию состояния контрольных сообщений первого узла, информацию состояния приложений первого узла, а также информацию версии, и передача данных может включать распространение данных по всем серверным узлам в кластере серверов с использованием протокола Gossip, по которому осуществляется обмен данными между парами серверных узлов в кластере.

[0019] Данные могут распространяться периодически по всем серверным узлам в кластере серверов.

[0020] Данные могут быть переданы на второй узел, когда первый узел присоединяется к кластеру.

[0021] На каждом из серверных узлов в кластере серверов может храниться локально домен с записями, которые могут быть модифицированы любым из узлов, и способ может включать также формирование информации версии с использованием причинного механизма формирования версии, так что информация версии указывает, какой из серверных узлов самым последним модифицировал одну из записей.

[0022] Информация о состоянии приложения может содержать хеш-значение высшего уровня, сгенерированное путем хеширования всех записей в домене.

[0023] Способ может также включать сравнение, с использованием второго узла, указанного хеш-значения высшего уровня с хеш-значением высшего уровня, сгенерированного путем хеширования версии соответствующего домена, хранимого локально на втором узле; и, если хеш-значения высшего уровня отличаются, синхронизацию доменов на первом и втором узлах с использованием информации версий.

[0024] На первом узле может храниться локально запись статуса, которая может быть модифицирована только первым узлом, и информация версии содержит номер версии, который первый узел увеличивает на единицу всякий раз, когда он модифицирует запись статуса.

[0025] Информация о состоянии приложений может содержать пару параметров записи статуса, содержащую идентификатор записи статуса, который идентифицирует запись статуса, и номер версии.

[0026] Способ может также включать сравнение, с использованием второго узла, номера версии, полученного от первого узла, с номером версии соответствующей записи статуса, хранимой локально на втором узле; и если номера версий отличаются, обновление записи статуса, хранимой локально на втором узле, записью статуса, хранимой локально на первом узле.

[0027] Обновление записи статуса может включать передачу из первого узла на второй узел дополнительных записей статуса, хранимых локально на первом узле, которые были модифицированы одновременно с записью статуса.

[0028] Первый и второй узлы могут составлять по меньшей мере часть группы серверных узлов в кластере, в которой первый узел может передавать данные полностью упорядоченным образом всем серверным узлам в группе, и передача данных может включать передачу первым узлом данных всем серверным узлам в группе.

[0029] Данные могут включать изменяемые данные, генерируемые в процессе работы системы физической защиты.

[0030] Данные могут также содержать потоковое видео, передаваемое с другого серверного узла в кластере серверов через первый узел на второй узел.

[0031] В настоящем изобретении также предлагается система физической защиты, в которой осуществляется совместное использование данных, причем система содержит множество серверных узлов, в том числе первый узел и второй узел, и первый узел содержит процессор соединенный, с возможностью обмена информацией, с машиночитаемым носителем информации, на котором записаны программы, выполнение которых процессором обеспечивает осуществление способа, включающего: выборку идентификатора узла, идентифицирующего второй узел, причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов; и передачу данных на второй узел.

[0032] В настоящем изобретении также предлагается машиночитаемый носитель с постоянным хранением информации, содержащий программы, исполнение которых процессором обеспечивает осуществление способа совместного использования данных в системе физической защиты, содержащей множество серверных узлов, причем способ включает: выборку с использованием одного из серверных узлов ("первый узел") идентификатора узла, идентифицирующего другой серверный узел ("второй узел"), причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов; и передачу данных из первого узла на второй узел.

[0033] В настоящем изобретении также предлагается способ взаимодействия с дистанционно управляемым дисплеем в системе физической защиты, содержащей множество серверных узлов, причем способ включает: передачу из одного из серверных узлов ("второй узел"), который может обмениваться информацией с дистанционно управляемым дисплеем, на другой серверный узел ("первый узел"), который может обмениваться информацией с клиентским дисплеем, данных состояния изображения, характеризующих изображение, отображаемое на дистанционно управляемом дисплее; и отображение на клиентском дисплее по меньшей мере части изображения, отображаемого на дистанционно управляемом дисплее. В одном из вариантов ни один из серверных узлов не является центральным шлюзовым сервером, и в альтернативном варианте по меньшей мере один из серверных узлов является центральным шлюзовым сервером.

[0034] Способ может также включать передачу из первого узла на второй узел сообщения на изменение изображения на дистанционно управляемом дисплее; и обновление изображения на дистанционно управляемом дисплее в соответствии с сообщением, переданным из первого узла на второй узел.

[0035] Первый и второй узлы, а также по меньшей мере еще один узел из множества серверных узлов могут составлять кластер серверов, и первый и второй узлы могут составлять по меньшей мере часть группы серверных узлов в кластере, в которой второй узел может передавать данные состояния изображения полностью упорядоченным образом всем другим серверным узлам в группе, и передача данных состояния изображения может включать передачу вторым узлом данных всем другим серверным узлам в группе.

[0036] Первый и второй узлы, а также по меньшей мере еще один узел из множества серверных узлов могут составлять кластер серверов, и первый и второй узлы могут составлять по меньшей мере часть группы серверных узлов в кластере, в которой первый узел может передавать сообщение на изменение состояния дистанционно управляемого дисплея полностью упорядоченным образом всем другим серверным узлам в группе, и первый узел может передавать сообщение на изменение состояния дистанционно управляемого дисплея всем другим серверным узлам в группе.

[0037] Способ может включать также передачу из второго узла на первый узел уведомления о том, что изображение дистанционно управляемого дисплея доступно для управления.

[0038] Передача уведомления может включать его распространение по всем серверным узлам в кластере серверов с использованием протокола Gossip, по которому осуществляется обмен данными между парами серверных узлов в кластере.

[0039] Способ может включать также, перед передачей состояния дистанционно управляемого дисплея на управляющий дисплей, выборку с использованием второго узла идентификатора первого узла, причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов.

[0040] Информация о составе кластера может содержать: идентификатор узла, однозначным образом идентифицирующий каждый серверный узел в кластере серверов; и идентификатор кластера, однозначным образом идентифицирующий кластер серверов, к которому принадлежат серверные узлы.

[0041] Каждый серверный узел в кластере серверов может хранить локально и постоянно обновлять свою собственную версию информации о составе кластера.

[0042] В настоящем изобретении предлагается также система физической защиты, содержащая: клиентский дисплей; дистанционно управляемый дисплей; и множество серверных узлов, один из которых ("первый узел") может обмениваться информацией с клиентским дисплеем, и другой серверный узел ("второй узел") может обмениваться информацией с дистанционно управляемым дисплеем, причем второй узел сконфигурирован для передачи на первый узел данных состояния изображения, характеризующих изображение, отображаемое на дистанционно управляемом дисплее, и первый узел сконфигурирован для отображения на клиентском дисплее по меньшей мере части изображения, отображаемого на дистанционно управляемом дисплее. В одном из вариантов ни один из серверных узлов не является центральным шлюзовым сервером, и в альтернативном варианте по меньшей мере один из серверных узлов является центральным шлюзовым сервером.

[0043] В настоящем изобретении предлагается также система физической защиты, содержащая: клиентское устройство с клиентским дисплеем; дистанционно управляемый дисплей; и множество серверных узлов, один из которых ("первый узел") может обмениваться информацией с клиентским устройством, и другой серверный узел ("второй узел") может обмениваться информацией с дистанционно управляемым дисплеем, причем второй узел сконфигурирован для передачи на первый узел данных состояния изображения, характеризующих изображение, отображаемое на дистанционно управляемом дисплее, и первый узел сконфигурирован для отображения на клиентском дисплее по меньшей мере части изображения, отображаемого на дистанционно управляемом дисплее. В одном из вариантов ни один из серверных узлов не является центральным шлюзовым сервером, и в альтернативном варианте по меньшей мере один из серверных узлов является центральным шлюзовым сервером.

[0044] Дистанционно управляемый дисплей может быть подсоединен ко второму узлу непосредственно или же опосредованно, например, через дистанционно управляемое клиентское устройство или рабочую станцию.

[0045] В настоящем изобретении также предлагается машиночитаемый носитель с постоянным хранением информации, содержащий программы, исполнение которых процессором обеспечивает осуществление способа взаимодействия с дистанционно управляемым дисплеем в системе физической защиты, содержащей множество серверных узлов, причем способ включает: передачу из одного из серверных узлов ("второй узел"), который может обмениваться информацией с дистанционно управляемым дисплеем, на другой серверный узел ("первый узел"), который может обмениваться информацией с клиентским дисплеем, данных состояния изображения, характеризующих изображение, отображаемое на дистанционно управляемом дисплее; и отображение на клиентском дисплее по меньшей мере части изображения, отображаемого на дистанционно управляемом дисплее.

[0046] В настоящем изобретении также предлагается способ совместного использования изображения ("совместно используемое изображение") в системе физической защиты, содержащей множество серверных узлов, причем способ включает: передачу из первого клиентского устройства на один из серверных узлов ("первый узел") данных состояния изображения, характеризующих совместно используемое изображение, как оно отображается первым клиентским устройством; передачу данных состояния изображения из первого узла во второе клиентское устройство через другой серверный узел ("второй узел"); обновление изображения на дисплее второго клиентского устройства с использованием данных состояния изображения для показа совместно используемого изображения; передачу обновленных данных состояния изображения из второго клиентского устройства на второй узел после изменения совместно используемого изображения на втором клиентском устройстве; причем обновленные данные состояния изображения характеризуют совместно используемое изображение, как оно отображается на втором клиентском устройстве; передачу обновленных данных состояния изображения из второго узла в первое клиентское устройство через первый узел; и обновление изображения на дисплее первого клиентского устройства с использованием обновленных данных состояния изображения для показа совместно используемого изображения. В одном из вариантов ни один из серверных узлов не является центральным шлюзовым сервером, и в альтернативном варианте по меньшей мере один из серверных узлов является центральным шлюзовым сервером.

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

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

[0049] Способ может включать также, перед показом совместно используемого изображения на дисплее второго клиентского устройства, передачу из первого клиентского устройства во второе клиентское устройство через первый и второй узлы уведомления о том, что совместно используемое изображение, как оно отображается первым клиентским устройством, доступно для совместного использования вторым клиентским устройством.

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

[0051] Способ может включать также, перед передачей первым узлом данных состояния во второе клиентское устройство через второй узел, выборку с использованием первого узла идентификатора узла, идентифицирующего второй узел, причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов.

[0052] Информация о составе кластера может содержать: идентификатор узла, однозначным образом идентифицирующий каждый серверный узел в кластере серверов; и идентификатор кластера, однозначным образом идентифицирующий кластер серверов, к которому принадлежат серверные узлы.

[0053] Каждый серверный узел в кластере серверов может хранить локально и постоянно обновлять свою собственную версию информации о составе кластера.

[0054] В настоящем изобретении предлагается также система физической защиты, содержащая: первое клиентское устройство с дисплеем; второе клиентское устройство с дисплеем; и множество серверных узлов, один из которых ("первый узел") может обмениваться информацией с дисплеем первого клиентского устройства, и другой серверный узел ("второй узел") может обмениваться информацией с дисплеем второго клиентского устройства, причем первое и второе клиентские устройства, а также первый и второй узлы сконфигурированы для: передачи из первого клиентского устройства на первый узел данных состояния изображения, характеризующих совместно используемое изображение, как оно отображается на дисплее первого клиентского устройства; передачи данных состояния изображения из первого узла во второе клиентское устройство через второй узел; обновления изображения на дисплее второго клиентского устройства с использованием данных состояния изображения для показа совместно используемого изображения; передачи обновленных данных состояния изображения из второго клиентского устройства на второй узел после изменения совместно используемого изображения на втором клиентском устройстве; причем обновленные данные состояния изображения характеризуют совместно используемое изображение, как оно отображается на втором клиентском устройстве; передачи обновленных данных состояния изображения из второго узла в первое клиентское устройство через первый узел; и обновления изображения на дисплее первого клиентского устройства с использованием обновленных данных состояния изображения для показа совместно используемого изображения. В одном из вариантов ни один из серверных узлов не является центральным шлюзовым сервером, и в альтернативном варианте по меньшей мере один из серверных узлов является центральным шлюзовым сервером.

[0055] В настоящем изобретении предлагается также машиночитаемый носитель с постоянным хранением информации, содержащий программы, исполнение которых процессором обеспечивает осуществление способа совместного использования изображения ("совместно используемое изображение") в системе физической защиты, содержащей множество серверных узлов, причем способ включает: передачу из первого клиентского устройства на один из серверных узлов ("первый узел") данных состояния изображения, характеризующих совместно используемое изображение, как оно отображается первым клиентским устройством; передачу данных состояния изображения из первого узла во второе клиентское устройство через другой серверный узел ("второй узел"); обновление изображения на дисплее второго клиентского устройства с использованием данных состояния изображения для показа совместно используемого изображения; передачу обновленных данных состояния изображения из второго клиентского устройства на второй узел после изменения совместно используемого изображения на втором клиентском устройстве; причем обновленные данные состояния изображения характеризуют совместно используемое изображение, как оно отображается на втором клиентском устройстве; передачу обновленных данных состояния изображения из второго узла в первое клиентское устройство через первый узел; и обновление изображения на дисплее первого клиентского устройства с использованием обновленных данных состояния изображения для показа совместно используемого изображения.

[0056] В вышеприведенном изложении существа изобретения могут не описываться все его возможные аспекты. Другие аспекты, особенности и достоинства настоящего изобретения будут очевидны специалистам в данной области техники после ознакомления с нижеприведенным описанием конкретных вариантов его осуществления.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0057] Нижеописанные прилагаемые чертежи иллюстрируют один или несколько типичных вариантов осуществления изобретения.

[0058] Фигура 1 - блок-схема распределенной системы физической защиты по одному из вариантов осуществления изобретения.

[0059] Фигура 2 - блок-схема, иллюстрирующая использование набора протоколов в системе фигуры 1.

[0060] Фигура 3 - диаграмма последовательности унифицированного языка моделирования (UML, от англ. Unified Modeling Language), иллюстрирующая обмен установочными параметрами между разными пользователями системы фигуры 1.

[0061] Фигура 4 - диаграмма последовательности языка UML, иллюстрирующая способ распространения информации о состоянии между разными пользователями системы фигуры 1.

[0062] Фигура 5 - диаграмма последовательности языка UML, иллюстрирующая способ совместного использования изображения разными пользователями системы фигуры 1.

[0063] Фигура 6 - диаграмма последовательности языка UML, иллюстрирующая совместное использование потокового видео разными пользователями системы фигуры 1.

[0064] Фигура 7 - изображение, отображаемое одному из пользователей системы, показанной на фигуре 1.

[0065] Фигура 8 - блок-схема алгоритма обмена данными в системе физической защиты по одному из вариантов осуществления изобретения.

[0066] Фигура 9 - блок-схема алгоритма присоединения к группе в автоматическом режиме по одному из вариантов осуществления изобретения.

[0060] Фигура 10 - диаграмма последовательности языка UML, иллюстрирующая совместное использование изображения с дистанционно управляемого дисплея пользователями системы фигуры 1.

[0068] Фигура 11 - блок-схема алгоритма взаимодействия с дистанционно управляемым дисплеем в системе физической защиты, которая содержит множество серверных узлов, по другому варианту осуществления изобретения.

[0069] Фигура 12 - блок-схема алгоритма совместного использования изображения в системе физической защиты, которая содержит множество серверных узлов, по другому варианту осуществления изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0070] Указания направления, такие как "верхний", "нижний", "вверх", "вниз", "вертикально" и "в сторону", в настоящем описании используются только для целей указания относительного расположения, и не должны рассматриваться как какие-либо ограничения в положении каких-либо деталей в процессе использования, или их расположения в комплексе или относительно окружающих объектов. Кроме того, термин "соединять", а также его производные, такие как "соединенный", "соединения", как они используются в настоящем описании, означают непосредственное или опосредованное соединение, если в явной форме не указано иное. Например, если первое устройство соединено со вторым устройством, то соединение может быть непосредственным или опосредованным, через другие устройства или соединительные элементы. Аналогично, если первое устройство соединено со вторым устройством с возможностью обмена информацией, то соединение может быть непосредственным или опосредованным, с помощью других устройств или соединительных элементов.

[0071] Когда система наблюдения расширяется, и количество видеокамер превысит определенную величину, работа системы с использованием одного сервера становится невозможной или практически невозможной ввиду ограничений его вычислительной мощности и возможностей по хранению информации. Соответственно, для включения в систему большого количества видеокамер необходимо вводить в нее дополнительные серверы. В результате возникает ряд проблем.

[0072] Например, у пользователя системы наблюдения может появиться необходимость увидеть изображение, наблюдаемое другим пользователем, или просматривать потоковое видео, которое поступает в систему из видеокамеры, или которое записано на сервере системы, даже если этот пользователь не подсоединен непосредственно к этой видеокамере или к этому серверу, соответственно. Аналогично, у пользователя может возникнуть необходимость в доступе к состоянию других пользователей (например, подключен ли к системе другой пользователь) и к событиям, происшедшим в системе (например, был ли включен сигнал тревоги), даже если они имели место на сервере, к которому пользователь не подсоединен непосредственно. В традиционной системе наблюдения, которая расширяется путем добавления новых серверов, обычный способ обеспечения вышеуказанных возможностей заключается во введении в систему центрального шлюзового сервера. Центральный шлюзовой сервер направляет системные события, состояния пользователей, изображения и потоковые видео с одного сервера на другой сервер системы, в результате чего пользователь имеет возможность получать доступ или просматривать эти состояния, события, изображения и потоковые видео вне зависимости от того, к какому серверу непосредственно подключен этот пользователь. Однако в случае использования центрального шлюзового сервера система наблюдения становится уязвимой, поскольку в случае отказа этого сервера дальнейший обмен информацией событий, состояний, полей зрения и потокового видео становится невозможным. Использование центрального шлюзового сервера также увеличивает стоимость системы наблюдения, поскольку в этом случае в систему вводится дополнительное оборудование, которое должно обеспечивать специализированные функции шлюзового сервера.

[0073] Пользователю может быть также необходимо, чтобы общие установочные параметры (например, информация доступа пользователей в форме логинов, паролей, прав доступа и т.п.) были синхронизированы по всем серверам системы. В традиционной системе наблюдения, которая может быть расширена путем добавления новых серверов, вышеуказанные функциональные возможности обеспечиваются либо путем экспорта установочных параметров из одного сервера на другие серверы, либо путем использования центрального сервера управления, в котором хранятся все эти установочные параметры, и другие серверы при необходимости могут получать из него всю эту информацию. Экспорт установочных параметров вручную связан с проблемами, такими как сравнительно большие задержки синхронизации, трудности в использовании и установке, и, кроме того, большие задержки синхронизации ухудшают возможности системного резервирования. Использование центрального сервера управления связано с такими же проблемами, что и использование вышеописанного центрального шлюзового сервера.

[0074] Некоторые варианты, рассмотренные в настоящем описании, относятся к распределенной системе физической защиты, такой как система наблюдения, в которой возможен обмен данными, такими как информация изображений, потокового видео, системных событий, состояния пользователей и пользовательских установочных параметров, в автоматическом режиме между несколькими серверами системы без необходимости использования центрального сервера, такого как шлюзовой сервер или сервер управления, описанные выше. Эти варианты относятся к одноранговым системам наблюдения, в которых пользователи подсоединяются через клиентские устройства к серверным узлам, таким как сетевые видеомагнитофоны, видеокамеры и серверы. Серверные узлы группируются в кластеры, так что каждый серверный узел в кластере может использовать данные совместно с другими серверными узлами кластера. Для совместного использования данных на каждом серверном узле работают сервисные процессы, которые обеспечивают обмен данными с использованием набора протоколов, в результате чего обмен данных между серверными узлами осуществляется по-разному в зависимости от типа данных: изображения, потоковое видео, системные события, состояния пользователей или пользовательские установочные параметры. Такие варианты иллюстрируются на фигурах 1-10.

[0075] В других вариантах некоторые технологии, используемые для совместного использования изображений разными серверными узлами, применимы к интегрированным сетям (то есть, сетям, содержащим центральный сервер) и к одноранговым сетям, таким как сети, схемы которых приведены на фигурах 1-9. Такие варианты иллюстрируются на фигурах 10 и 11.

[0076] На фигуре 1 приведена схема одного из вариантов распределенной системы физической защиты в форме системы 100 наблюдения. Система 100 содержит: три клиентских устройства 102а, 102b, 102с (совместно указываются как "клиентские устройства 102"), шесть серверов 104а-104f (вместе указываются как "серверы 104"), три видеокамеры 106а, 106b, 106с, которые являются серверными узлами (вместе указываются как "видеокамеры 106 узлов") и пять видеокамер 114, которые не являются узлами.

[0077] Каждая из видеокамер 106 и каждый из серверов 104 содержит процессор 110 и запоминающее устройство 112, которые соединены друг с другом с возможностью обмена информацией, причем запоминающее устройство 112 содержит программы, выполнение которых процессором 110 обеспечивает осуществление вариантов способов, рассмотренных в настоящем описании. Серверы 104 и видеокамеры 106 узлов сгруппированы в три кластера 108а, 108b, 108с (вместе указываются как "кластеры 108"): серверы 104а, 104b, 104с соединены друг с другом с возможностью обмена информацией и формируют первый кластер 108а; серверы 104d, 104е, 104f соединены друг с другом с возможностью обмена информацией и формируют второй кластер 108b; и три видеокамеры 106 узлов соединены друг с другом с возможностью обмена информацией и формируют третий кластер 108с. Серверы 104а, 104b, 104с являются участниками первого кластера 108а; серверы 104d, 104е, 104f являются участниками второго кластера 108b; и видеокамеры 106а, 106b, 106с узлов являются участниками третьего кластера 108с.

[0078] Каждый сервер 104 и каждая видеокамера 106 являются серверными узлами, каждый из которых "знает" о наличии других участников своего кластера 108 и может обмениваться с ними информацией; в отличие от этого видеокамеры 114 не являются серверными узлами и "знают" лишь о наличии серверов 104а, 104b, 104с, 104d, 104f, к которым они подсоединены непосредственно. В варианте, схема которого приведена на фигуре 1, серверные узлы "знают" обо всех других участниках кластера 108, поскольку имеют доступ к информации о составе кластера, в которой указаны все серверные узлы кластера 108. Информация о составе кластера хранится в каждом из серверных узлов, в результате чего обеспечивается возможность каждому из серверных узлов подключаться снова в автоматическом режиме к своему кластеру 108 в случае перезагрузки этого узла в процессе работы системы 100. Далее, если в явной форме не указано иное, указание "узел" эквивалентно указанию "серверный узел".

[0079] Хотя в рассматриваемом варианте ни один из кластеров 108 не участвует в обмене информацией между кластерами, однако в альтернативных вариантах (здесь не рассматриваются) участники разных кластеров могут обмениваться информацией между собой. В рассматриваемом варианте серверы 104, представляющие собой стандартные предлагаемые на рынке серверы, а также видеокамеры 106, 114 производятся компанией Avigilon™ Corporation (г. Ванкувер, Канада), однако в альтернативных вариантах могут использоваться и другие подходящие типы серверов 108 и видеокамер 106, 114.

[0080] Первое клиентское устройство 102а соединено с возможностью обмена информацией с первым и вторым кластерами 108а, 108b посредством соединения с первым и четвертым серверами 104а, 104d, которые входят в состав кластеров 108а, 108b, соответственно; второе клиентское устройство 102b соединено с возможностью обмена информацией со всеми тремя кластерами 108 посредством соединения со вторым и четвертым серверами 104b, 104d, и с первой видеокамерой 106а, которые входят в состав кластеров 108а, 108b, 108с, соответственно; и третье клиентское устройство 102с соединено с возможностью обмена информацией со вторым и третьим кластерами 108b, 108с посредством соединения с пятым сервером 104е и второй видеокамерой 106b, которые входят в состав кластеров 108b, 108с, соответственно. Как это будет описано ниже более подробно, в любом из кластеров 108а, 108b, 108с на каждом узле работают сервисные процессы, которые обеспечивают возможность каждому узлу обмениваться информацией с каждым другим узлом с использованием набора 200 протоколов (см. фигуру 2), в результате чего узлы могут использовать совместно данные, которые могут быть изображениями, потоковым видео, системными событиями, состояниями пользователей, пользовательскими установочными параметрами или любыми другими данными, с использованием распределенной обработки данных, то есть, без использования центрального сервера. Каждый узел имеет доступ к информации о составе кластера, которая идентифицирует все узлы, входящие в состав одного кластера 108, и за счет возможности доступа к этой информации все узлы кластера 108 могут пользоваться ею совместно и осуществлять ее синхронизацию.

[0081] На фигуре 2 приведена блок-схема набора 200 протоколов, используемых узлами системы 100. Набор 200 протоколов распределяется между тремя уровнями и содержит протоколы, сводная информация по которым приведена в Таблице 1.

[0082] Ниже дается описание функции и работы каждого протокола из набора 200.

Транспортный уровень

[0083] Транспортный уровень соответствует Уровню 4 модели взаимодействия открытых систем (OSI) и отвечает за обеспечение надежной передачи данных между узлами на уровни поддержки кластеров, синхронизации данных и приложений. Транспортный уровень в системе 100 включает протоколы UDP 202 и TCP/HTTP 204.

Уровень поддержки кластера

[0084] Уровень поддержки кластеров включает протоколы, используемые для обнаружения узлов, подтверждения существования узлов, проверки работоспособности узлов, определения того, что некоторый узел является участником одного из кластеров 108, и определения маршрутизации данных между узлами.

Протокол 206 Discovery

[0085] Протокол 206 Discovery разработан на основе версии 1.1 протокола WS-Discovery, опубликованной организацией по продвижению протоколов структурированной информации (OASIS), полное содержание которой включается здесь ссылкой в настоящую заявку. В рассматриваемом варианте XML-форматирование, использованное в опубликованном стандарте, заменено кодировкой Google™ Protobuf.

[0086] Протокол 206 Discovery обеспечивает возможность каждому узлу в системе 100 идентифицировать другие узлы в этой системе путем многоадресной передачи сообщений зондирования (Probe) этим другим узлам с ожиданием ответа от них. В других вариантах узел может передавать приветственное сообщение (Hello) при вхождении в систему 100 для предупреждения других узлов о своем присутствии, и, таким образом, в этом случае исключается необходимость передачи этими другими узлами сообщений зондирования. Сообщения зондирования и приветственные сообщения указаны в протоколе WS-Discovery, опубликованном OASIS.

Протокол 208 Gossip

[0087] Протокол 208 Gossip является "эпидемическим" протоколом, в котором данные распространяются от одного из узлов по всем другим узлам кластера 108 путем осуществления случайного обмена данными между парами узлов в кластере 108. По протоколу 208 Gossip состояние узлов системы определяется по передаваемым периодическим контрольным сообщениям, которые обеспечивают возможность узлам определять, когда один из узлов кластера 108 неожиданно отключается (например, при отказе сервера). По протоколу 208 Gossip также передается информация состояния приложения, такая как хеш-значения высшего уровня, используемые протоколом 216 Consistency, и идентификаторы записей статуса, а также номера их версий, используемые протоколом 218 Status для определения необходимости осуществления синхронизации данных между двумя узлами, как это будет описано ниже более подробно. Информация, распространяемая по протоколу 208 Gossip, в конечном счете, поступает на все узлы кластера 108 путем периодических обменов информацией между узлами.

[0088] Обмен информацией между любыми двумя узлами кластера 108 по протоколу 208 Gossip включает два дистанционных вызова процедур (RPC), осуществляемых с первого узла (узел А) для выполнения на втором узле (узел В) одного кластера 108. В этом случае последовательность действий будет следующей:

1. Узел А передает в узел В сообщение GreetingReq (запрос информации), содержащее перечень сводных данных (справок) по всем узлам в кластере 108, которые известны узлу А. Справки по каждому узлу содержат уникальный идентификатор узла и информацию версии, которая увеличивается на единицу каждый раз, когда изменяется состояние контрольного сообщения или приложения для этого узла. Информация версии может быть, например, одномерным номером версии или многомерным вектором версии. Использование вектора версии обеспечивает возможность записи в сводных данных истории изменений состояния, которым подвергался узел.

2. Узел В передает в узел А сообщение GreetingRsp (ответ), которое содержит:

a) перечень справок в отношении узлов, по которым узлу В необходима дополнительная информация от узла А, и которые узел В определяет из информации версии, полученной в составе сообщения GreetingReq;

b) перечень справок для узлов, о которых узлу А неизвестно, что они входят в состав кластера 108;

c) перечень состояний контрольных сообщений и/или приложений для узлов, по которым узел А сможет обновить свою устаревшую информацию; и

d) перечень узлов, которые по информации узла А входят в кластер 108, однако узлу В известно, что они удалены из кластера 108.

3. Затем узел А передает узлу В сообщение ClosureReq (запрос завершения), в котором узел А передает:

a) перечень справок в отношении узлов, по которым узлу А необходима дополнительная информация от узла В (например, узел А может запросить информацию в отношении узлов, о которых узлу А было неизвестно, пока узел В не передал узлу А сообщение GreetingRsp);

b) перечень состояний для узлов, по которым узел В сможет обновить свою устаревшую информацию; и

c) перечень узлов, которые по информации узла В входят в кластер 108, однако узлу А известно, что они удалены из кластера 108.

4. Затем узел В передает узлу А сообщение ClosureRsp (подтверждение завершения), в котором узел В передает:

a) перечень состояний, который обеспечивает возможность узлу А обновить свою устаревшую информацию по узлам, которые были указаны в сообщении ClosureReq узла А; и

b) перечень узлов, которые были удалены из кластера 108 с момента передачи сообщения GreetingRsp.

[0089] после того как узлы А и В обменялись сообщениями RPC, они будут иметь идентичные перечни активных узлов, которые включают самые свежие версии состояния контрольных сообщений и приложений для всех узлов в кластере 108, о которых было известно узлам А и В до обмена этими сообщениями, и которые не были удалены из состава кластера 108.

Протокол 210 Node

[0090] Протокол 210 Node отвечает за формирование схемы сетевой топологии системы 100, в результате чего для каждого узла обеспечивается карта сети, позволяющая ему обмениваться информацией с каждым другим узлом системы 100. В некоторых вариантах карта сети представляет собой таблицу маршрутизации. Карта сети содержит информацию по оконечным устройствам, в частности, адрес (IP/FQDN), номер порта и протокол, с использованием которого можно получить доступ к узлу по IP-сети, соединяющей узлы.

[0091] Решение указанных задач протокол 210 Node обеспечивает тремя способами:

1. Посредством обмена записями данных (описан подробно ниже).

2. Посредством протокола 206 Discovery, который активизирует протокол 210 Node, когда узел присоединяется к системе 100 или выходит из нее. Когда узел присоединяется к системе 100, с ним выполняется обмен записями данных.

3. В ручном режиме по запросу пользователя.

[0092] Обмен записями данных включает периодическое осуществление нижеописанного дистанционного вызова процедур (RPC) для целей формирования карт сети для узлов:

1. Запрос обмена записями данных, в котором узел А передает в узел В свои данные и перечень известных ему других узлов с информацией по ним, после чего узел В обновляет свою карту сети в соответствии с полученной информацией.

2. Ответ на запрос, в котором узел В передает в узел А свои данные и перечень известных ему других узлов с информацией по ним, после чего узел А обновляет свою карту сети в соответствии с полученной информацией.

[0093] Запросы RPC осуществляются поверх протокола 204 TCP/HTTP.

[0094] Для снижения используемой при этом пропускной способности обмен информацией об узлах осуществляется между узлами А и В только тогда, когда информация узла, переданная в последнем обмене, изменилась.

[0095] Обмен записями данных осуществляется после того, как протокол 206 Discovery извещает протокол 210 Node о том, что узел присоединился к системе 100, поскольку протокол 206 Discovery указывает оконечные устройства для связи с узлом, однако при этом не гарантируется, что узел может быть доступен через эти оконечные устройства. Например, оконечные устройства не могут быть использованы из-за установленного средства сетевой защиты. Выполнение обмена записями данных для узла, идентифицированного с использованием протокола 206 Discovery, подтверждает, могут ли быть использованы фактически оконечные устройства связи.

[0096] Протокол 210 Node может также обеспечивать подтверждение доступности указанного оконечного UDP-устройства связи, однако протокол 210 Node в рассматриваемом варианте не обеспечивает возможность обмена записями данных поверх протокола 202 UDP.

[0097] Для любого заданного узла в кластере 108 карта сети связывает идентификаторы узлов с оконечными устройствами связи для каждого узла этого кластера 108. Соответственно, в соответствии с другими протоколами из набора 200, обеспечивающими обмен информацией с протоколом 210 Node, может обеспечиваться доставка сообщений в любой другой узел в кластере 108 только лишь по идентификатору этого узла.

Протокол 212 Membership

[0098] Протокол 212 Membership гарантированно обеспечивает, что каждый узел кластера 108 поддерживает информацию о составе кластера для всех узлов, входящих в кластер 108, и обеспечивает возможность каждому узлу входить и выходить из кластера 108 с использованием вызовов RPC. Информация о составе кластера распространяется между узлами кластера 108 для совместного использования с помощью протокола 218 Status. Каждый узел в кластере 108 поддерживает свой собственный вариант информации о составе кластера и с использованием протокола 218 Status получает информацию о составе кластера 108, поддерживаемую другими его узлами. Как это будет описано ниже более подробно, варианты информации о составе кластера, поддерживаемые двумя разными узлами, могут не совпадать, поскольку вариант информации о составе кластера, записанный на одном узле и не обновленный на текущий момент, может быть еще не синхронизирован с другими участниками кластера 108.

[0099] Для каждого узла информация о составе кластера содержит:

1. Перечень всех узлов, входящих в состав кластера 108, в котором каждый узел представлен:

a) идентификатором узла, уникальным среди всех узлов системы 100;

b) состоянием узла, которое может быть одним из следующих состояний:

i) Discover: узел является членом кластера 108, однако он не синхронизирован с другими членами этого кластера с момента начальной загрузки;

ii) Joining: узел находится в процессе присоединения к кластеру 108;

iii) Syncing: узел находится в процессе синхронизации данных с использованием протоколов 214 Synchrony, 216 Consistency, 218 Status с кластером 108, к которому он присоединился;

iv) Valid: узел завершил синхронизацию информации о составе кластера и является действующим узлом кластера 108; и

v) TimedOut: узел не реагирует на запросы и больше не является активным участником кластера 108 (узел остается участником кластера 108, пока не будет удален пользователем);

c) идентификатором сеанса;

d) номером версии информации о составе кластера, когда узел присоединился к кластеру 108; и

e) номером версии информации о составе кластера, когда она была изменена в последний раз.

2. Перечень всех узлов, которые были удалены из кластера 108, причем каждый такой удаленный узел представлен:

a) идентификатором этого узла; и

b) версией информации о составе кластера этого узла, когда узел был удален.

[00100] В рассматриваемом варианте узел всегда является участником кластера 108, который содержит по меньшей мере его самого, причем кластер 108, содержащий только один узел, указывается как "одиночный кластер". Кроме того, хотя в рассматриваемом варианте информация о составе кластера содержит вышеуказанный перечень участников и перечень удаленных узлов, в альтернативных вариантах (не описываются) информация о составе кластера может иметь иное содержание, например, в одном из таких альтернативных вариантов информация о составе кластера не содержит перечень удаленных узлов, а в другом таком варианте состояние узла может быть охарактеризовано другими параметрами.

[00101] Когда узел А должен действовать в качестве нового серверного узла, и ему необходимо присоединиться к кластеру 108, содержащему узел В, узел А обменивается информацией с узлом В, и выполняются следующие действия:

1. Узел А передает в узел В секретное слово кластера, которое в рассматриваемом варианте, представляет собой пароль, который необходим узлу В, прежде чем он даст разрешение другому узлу присоединиться к кластеру 108. Секретное слово кластера обеспечивается для узла А одним из клиентских устройств 102. Поскольку узел В управляет доступом узла А в кластер 108, то узел В действует в качестве "узла управления составом кластера".

2. Узлы А и В обмениваются своей информацией о составе кластера. Версии информации о составе кластера на узлах А и В обновляются для включения идентификаторов узла А и всех узлов кластера 108, к которому присоединяется узел А.

3. Состояние узла А изменяется на "Joining", и осуществляется процесс его присоединения к кластеру.

4. После присоединения к кластеру состояние узла А изменяется на "Syncing", и осуществляется обмен данными между узлом А и кластером 108, к которому он присоединился. Узел В также обновляет версию информации о составе кластера, записанную на всех других узлах кластера 108, с использованием протокола 218 Status. Процесс обновления версий информации о составе кластера, записанной в узле А и в других участниках кластера 108, к которому присоединяется узел А, указывается как "синхронизация" версий информации о составе кластера, записанной во всех этих узлах.

5. После завершение синхронизации состояние узла А изменяется на "Valid".

Уровень синхронизации данных

[00102] Уровень синхронизации данных включает протоколы, которые обеспечивают возможность передачи данных между узлами в кластере. Протоколы уровня синхронизации данных используют напрямую протоколы транспортного уровня и уровня поддержки кластеров.

Протокол 214 Synchrony

[00103] Протокол 214 Synchrony используется для передачи данных в форме сообщений из узла А в узел В в системе 100 таким образом, что эти сообщения поступают на узел В в том порядке, в котором их передает узел А. Служебные процессы, обеспечивающие передачу данных с использованием протокола 214 Synchrony, работают на выделенных потоках процесса ввода/вывода с высоким приоритетом.

[00104] В рассматриваемом варианте протокол 214 Synchrony представляет собой реализацию технологии виртуальной синхронизации, известной как протокол Totem, описанный в публикации "The Totem Multiple-Ring Ordering and Topology Maintenance Protocol", Agarwal D.A., Moser L.E., Melliar-Smith P.M., Budhia R.K., ACM Transactions on Computer Systems, 1998, стр. 93-132, полное содержание которой включается здесь ссылкой в настоящую заявку. В соответствии с протоколом 214 Synchrony узлы объединяются в группы, которые указываются далее в настоящем описании как "кольца синхронизации", и узел в любом кольце синхронизации может передавать полностью упорядоченные сообщения другим узлам этого кольца. Протокол 214 Synchrony содержит следующие модификации протокола Totem:

1. Протокол 214 Synchrony использует как идентификатор служебного процесса, так и идентификатор кольца для идентификации кольца синхронизации. Идентификатор служебного процесса идентифицирует все копии заданного кольца синхронизации, в то время как идентификатор кольца идентифицирует определенную копию заданного кольца синхронизации. Например, каждый раз, когда узел присоединяется к кольцу синхронизации или выходит из него, идентификатор кольца изменяется, а идентификатор служебного процесса не меняется. Идентификатор служебного процесса обеспечивает узлу возможность многоадресной передачи полностью упорядоченных сообщений группе узлов с этим идентификатором служебного процесса (то есть, группе узлов, которые принадлежат одному кольцу синхронизации).

2. В протоколе Totem в некоторых случаях, когда узлы не передают сообщения, кольцо синхронизации, известное этим узлам, не отражает последнюю конфигурацию кольца, которая формируется, когда узлы начинают обмен сообщениями. Протокол 214 Synchrony обеспечивает возможность узлам обмениваться друг с другом зондирующими сообщениями для формирования актуальных конфигураций колец синхронизации перед обменом другими сообщениями.

3. Протокол Totem лишь обеспечивает возможность передачи упорядоченных сообщений на все узлы, формирующие часть кольца синхронизации. В отличие от этого протокол 214 Synchrony использует модуль Dispatch, который извлекает сетевой уровень из протокола 214 Synchrony путем обеспечения интерфейса для: широковещательной передачи всем узлам, которые могут быть доступны в системе 100; многоадресной передачи любой группе узлов в системе 100 с использованием перечня идентификаторов узлов-получателей; и одноадресной передачи одному узлу в системе 100 с использованием идентификатора этого узла. Модуль Dispatch также поддерживает мультиплексирование служебных процессов в одном IP-порту, используя фильтрацию сообщений и маршрутизацию по идентификатору служебного процесса. Исходящие сообщения узла направляются в подгруппу узлов, имеющих один и тот же идентификатор служебного процесса, если это не многоадресная передача.

4. В соответствии с протоколом 214 Synchrony используются фрагментированные сообщения, и полезная пользовательская информация разбивается на фрагменты с последующим слиянием, чтобы избежать проблем, связанных с максимальным размером блоков передачи, примерно 1500 байтов.

5. Протокол 214 Synchrony модифицирует использование узлами сообщений Join, которые в протоколе Totem используются узлами для присоединения к кольцу синхронизации:

a) сообщения Join передаются узлами лишь в том случае, когда они имеют наименьший идентификатор узла в текущей группе рабочих узлов кольца синхронизации;

b) другие узлы осуществляют одноадресную передачу сообщений Join узлам с наименьшим идентификатором узла в текущей группе рабочих узлов;

c) сообщения Join содержат идентификатор служебного процесса, и узлы, не входящие в состав соответствующего кольца синхронизации, не отвечают.

Эти модификации протокола Totem способствуют снижению общей пропускной способности, используемой узлами для присоединения к кольцам синхронизации.

6. В соответствии с протоколом 214 Synchrony осуществляется обнаружение и занесение "черный список" узлов, которые не могут присоединиться к кольцу синхронизации из-за некоторых типов ошибок в конфигурации сети. Например, узел, который может передавать сообщения другим узлам, но не может принимать сообщения от них, будет виден другим узла только на этапе передачи зондирующих сообщений, поскольку другие сообщения по рассматриваемому варианту передаются только по запросу, и, соответственно, этот узел будет занесен в "черный список".

7. В соответствии с протоколом 214 Synchrony осуществляется шифрование полезной пользовательской информации и удостоверение аутентичности сообщений.

8. Протокол 214 Synchrony ограничивает время, в течение которого каждый узел может пользоваться правом доступа, указанным в протоколе Totem, в частности, в рассматриваемом варианте каждый узел может пользоваться правом доступа в течение 15 мс.

9. В протоколе 214 реализуется алгоритм предотвращения перегрузки, совместимый с протоколом TCP.

[00105] Как это будет описано ниже более подробно, протокол Synchrony используется в системе 100 для приложения 222 совместной используемых изображений и взаимодействия и для приложения 224 общих событий и тревожных сигналов, причем данные, используемые совместно участниками кластера 108 в этих приложениях 222 и 224, распространяются быстро и в известном порядке.

Протокол 216 Consistency

[00106] Протокол 216 Consistency используется для периодического распространения данных в автоматическом режиме по всем узлам кластера 108, так что данные, которые используются совместно с использованием протокола 216 Consistency, в конечном счете, будут синхронизированы на всех узлах кластера 108. Типы данных, которые используются совместно с помощью протокола 216 Consistency, описываются более подробно ниже, в разделах, относящихся к приложению 226 общих установочных параметров и приложению 228 общих пользовательских объектов. Данные, используемые совместно в рамках протокола 216 Consistency, записаны в базе данных каждого узла, и каждая запись в базе данных содержит пару ключ-величина, в которой ключ однозначно идентифицирует величину, и ключи независимы друг от друга. Протокол 216 Consistency обеспечивает синхронизацию данных на узлах с согласованием параллельных модификаций, которые могут выполняться разными узлами на разных базах данных. Как это будет описано ниже более подробно, в соответствии с протоколом 216 Consistency эта функция выполняется следующим образом: во-первых, обеспечивается уведомление о том, что базы данных не синхронизированы; во-вторых, выявляются конкретные записи баз данных, которые не синхронизированы; и, в-третьих, определяется, какая версия записи наиболее свежая, синхронизированная и поддерживаемая.

[00107] Для согласования параллельных модификаций, которые определяют, когда в базы данных вносятся изменения, каждому узлу, присоединяющемуся к кластеру 108, назначается причинный механизм формирования версий, используемый для записи, когда узел вносит изменения в данные, и для определения, были ли эти изменения внесены до или после изменений этих же данных, выполненных другими узлами кластера 108. В рассматриваемом варианте каждый узел в качестве причинного механизма формирования версий использует счетчик дерева интервалов (ITC). Однако в альтернативных вариантах могут использоваться и другие механизмы формирования версий, такие как векторные счетчики и векторы версий. В системе 100 также реализуется часы глобального времени (UTC), которые синхронизируются между разными узлами с использованием сетевого протокола службы времени, для определения порядка выполнения изменений, когда счетчики ITC двух или более узлов идентичны. Счетчики ITC описаны более подробно в публикации "Interval tree clocks: a logical clock for dynamic systems", P. Almeida, C. Baquero и V. Fonte, Princi. Distri. Sys., Lecture Notes in Comp. Sci., том 5401, стр. 259-274, 2008, полное содержание которой вводится здесь ссылкой в настоящую заявку.

[00108] Указатель, синхронизация которого обеспечивается протоколом 216 Consistency между узлами, делится на секции, каждая из которых указывается как домен конечного согласования (ECD). Протокол 216 Consistency обеспечивает синхронизацию каждого домена ECD независимо от других доменов ECD. Каждая запись базы данных внутри домена ECD указывается как запись конечного согласования (ЕСЕ). Каждая запись ЕСЕ содержит: ключ; метку времени из счетчиков ITC и UTC, которые обновляются всякий раз при модификации записи ЕСЕ; хеш-значение записи ЕСЕ для использования, например, функции Murmurhash; и признак удаления, который добавляется, когда запись ЕСЕ удаляется.

[00109] Хеш-значение используется для сравнения соответствующих доменов ECD и записей ЕСЕ на двух разных узлах для определения их идентичности. При сравнении двух соответствующих доменов ECD сравниваются хеш-значения высшего уровня для этих ECD. Хеш-значение высшего уровня для домена ECD на заданном узле формируется путем хеширования всех записей ЕСЕ в этом домене. Если хеш-значения высшего уровня совпадают, то домены ECD идентичны, в противном случае в соответствии с протоколом 216 Consistency делается вывод о том, что домены ECD отличаются. Для выявления отличающихся записей ЕСЕ в доменах ECD, хеш-значения на обоих узлах выбирают в порядке последовательного уменьшения диапазонов записей ЕСЕ. Интервалы, на которых выбирают хеш-значения, в конечном счете уменьшаются в достаточной степени, чтобы можно было выделить и идентифицировать на двух узлах отличающиеся записи ЕСЕ. Например, для определения и сравнения хеш-значений интервалов доменов ECD может использоваться двунаправленный перечень пропусков.

[00110] Два узла, осуществляющие обмен информацией с использованием протокола 216 Consistency, могут использовать следующие вызовы RPC:

1. SetEntries: передает на узел новые или обновленные записи ЕСЕ, и узел вводит их в соответствующие домены ECD.

2. GetEntries: передает ключ или диапазон ключей на узел, который возвращает записи ЕСЕ, соответствующие одному или нескольким ключам.

3. SynEntries: передает на узел ключ или диапазон ключей, и затем два узла сравнивают хеш-значения в порядке последовательного уменьшения диапазонов записей ЕСЕ для выявления отличающихся записей на двух узлах, как это уже описывалось. Если записи ЕСЕ отличаются, узлы осуществляют слияние записей, так что одни и те же записи сохраняются на узлах путем сравнения временных меток счетчиков ITC; если эти временные метки совпадают, то узлы сравнивают временные метки счетчиков UTC, связанные с записями ЕСЕ. Эти временные метки используются как информация версии, которая обеспечивает возможность двум узлам принять наиболее свежие записи ЕСЕ, используя эту информацию версии.

[00111] Когда узел изменяет записи ЕСЕ, он обычно вызывает процедуру SynEntries для информирования других узлов в кластере 108 об изменении этих записей. Если некоторые узлы в кластере 108 недоступны (например, они находятся в режиме офлайн), то вместо процедуры SynEntries используется протокол 208 Gossip для передачи хеш-значений высшего уровня в эти узлы, когда они снова будут работать в режиме онлайн. Как указывалось выше при описании использования протокола 208 Gossip в кластере 108, каждый узел хранит свое хеш-значение высшего уровня, которое распространяется по другим узлам вместе с идентификатором узла, информацией версии и состоянии контрольных сообщений с использованием протокола 208 Gossip. Когда другой узел принимает это хеш-значение, он сравнивает его со своим собственным хеш-значением высшего порядка. Если хеш-значения высшего порядка совпадают, то записи ЕСЕ на обоих узлах идентичны, в противном случае, записи ЕСЕ отличаются.

[00112] Если записи ЕСЕ отличаются, то вне зависимости от того, что это обстоятельство определено с использованием процедуры SynEntries или протокола 208 Gossip, узел, запустивший процедуру SynEntries или принявший хеш-значение высшего уровня, осуществляет синхронизацию записей ЕСЕ.

Протокол 218 Status

[00113] Как это уже указывалось, протокол 208 Gossip обеспечивает распространение по кластеру 108 идентификаторов записей статуса и номеров их версий ("пара параметров статуса") для узлов в кластере 108. Идентификаторы записей статуса могут представлять, например, различные типы информации о статусе в форме записей статуса, например: объем доступной памяти узла; устройства (например, видеокамеры 114, не являющиеся узлами), подсоединенные к этому узлу; клиентские устройства 102, подсоединенные к этому узлу; и информация о составе кластера. Когда один из узлов принимает эти данные в соответствии с протоколом 208 Gossip, он сравнивает номер версии из этой пары параметров статуса с номером версии соответствующей записи статуса, которая хранится на этом узле. Если номера версии отличаются, то в соответствии с протоколом 218 Status запускается вызов RPC (синхронизация) с узлом, из которого была получена пара параметров статуса, для обновления соответствующей записи состояния.

[00114] Запись статуса, синхронизированная с использованием протокола 218 Status, однозначно идентифицируется маршрутом и идентификатором узла. В отличие от данных, синхронизированных с использованием протокола 216 Consistency, узел, который описывается записью статуса, является единственным узлом, которому разрешено модифицировать запись статуса или пару параметров статуса. Соответственно, в отличие от синхронизации доменов ECD и записей ЕСЕ с использованием протокола 216 Consistency версия записи статуса для узла А, хранящаяся локально на этом узле, всегда будет самой свежей версией записи статуса.

[00115] Если узел А модифицирует одновременно множество записей статуса, протокол 218 Status обеспечивает синхронизацию всех модифицированных записей статуса для узла В, когда узел В вызывает процедуру Sync RPC. Соответственно, одновременно измененные записи могут зависеть друг от друга, поскольку они будут переданы вместе на узел В для анализа. В отличие от вышеописанного каждая запись ЕСЕ, синхронизированная с использованием протокола 216 Consistency, синхронизируется независимо от других записей, так что они не могут зависеть друг от друга, поскольку узел В не может исходить из получения записей в каком-либо определенном порядке.

Приложения

[00116] На каждом узле в системе 100 работают служебные процессы, реализующие вышеописанный набор 200 протоколов. Хотя в рассматриваемом варианте для каждого из протоколов 202-218 используется один служебный процесс, однако в других вариантах (здесь не рассматриваются) для реализации набора 200 протоколов может использоваться большее или меньшее количество служебных процессов. Каждый узел самостоятельно реализует набор 200 протоколов, и, соответственно, система 100 является распределенной системой, на работу которой меньше влияет отказ одного из узлов, что существенно отличает эту систему от традиционных систем физической защиты с использованием центрального сервера. Например, если происходит отказ одного из узлов ("отказавший узел") системы 100, на каждом из остающихся узлов служебный процесс, реализующий протокол 218 Status ("служебный процесс Status") будет определять отключение отказавшего узла путем контроля состояния контрольных сообщений отказавшего узла и будет передавать выявленный отказ в служебные процессы, реализующие протоколы 210 Node и 212 Membership на каждом из других узлов ("служебный процесс Node" и "служебный процесс Membership", соответственно). Затем на каждом узле служебные процессы, реализующие протоколы 214 Synchrony и 216 Consistency ("служебный процесс Synchrony" и "служебный процесс Consistency", соответственно) будут прекращать обмен данными с отказавшим узлом, пока он не возвратится в режим онлайн и не присоединится снова к своему кластеру 108.

[00117] Ниже описываются различные приложения 220-230, которые могут быть реализованы в системе 100. Приложения 220-230 могут быть реализованы в различных вариантах способа 800 совместного использования данных, блок-схема которого приведена на фигуре 8. Способ 800 начинается на стадии 802 с переходом на стадию 804, на которой первый узел системы 100 осуществляет доступ к идентификатору узла, идентифицирующему второй узел системы 100. Первый и второй узлы являются участниками одного кластера 108. Идентификатор узла, к которому осуществляет доступ первый узел, является частью информации о составе кластера, которая идентифицирует всех участников кластера 108. Информация о составе кластера доступна для всех участников кластера 108. В рассматриваемых вариантах каждый участник кластера 108 хранит локально свою собственную версию информации о составе кластера, которая постоянно обновляется, однако в альтернативных вариантах (здесь не рассматриваются) информация о составе кластера может храниться отдельно от узлов в центральном устройстве. После выборки идентификатора второго узла первый узел на стадии 806 передает данные второму узлу, после чего способ 800 заканчивается на стадии 808. Например, при использовании вышеописанного служебного процесса Node служебные процессы Synchrony и Consistency, работающие на первом узле, могут передавать данные на второй узел с использованием идентификатора второго узла и с передачей служебному процессу Node задачи связывания конечного устройства связи второго узла с его идентификатором. Передача данных из первого узла на второй узел на стадии 806 может включать часть двухстороннего обмена данных таким образом, как происходит обмен данными в соответствии с протоколом 208 Gossip.

Приложения 226 общих установочных параметров и 228 общих пользовательских объектов

[00118] В процессе работы системы 100 постоянно записываемая информация передается между узлами кластера 108. Примеры такой информации, обновляемой в режиме реального времени, которую приложения 226 общих установочных параметров и 228 общих пользовательских объектов распространяют между узлами, включают общие установочные параметры, такие как правила реакции на системные события, такие как включение сигнала тревоги, и пользовательские объекты, такие как имена пользователя, пароли и темы. Этот тип данных ("данные согласования") распространяется между узлами с использованием протокола 216 Consistency, причем, в общем случае, данные согласования - это данные, которые не должны распространяться в режиме реального времени или с полным упорядочиванием, и они постоянно записываются каждым узлом. Однако в альтернативных вариантах (здесь не рассматриваются) данные согласования могут не записываться постоянно.

[00119] На фигуре 3 показана блок-схема 300 последовательности унифицированного языка моделирования (UML-последовательности), в которой данные согласования в форме пользовательских установок распространяются между первым 302а и вторым 302b пользователями (вместе "пользователи 302"). Пользователи 302, первый 102а и второй 102b клиентские устройства, а также первый 104а и второй 104b серверы, которые представляют собой первый и второй узел в данном примере, являются объектами на блок-схеме 300. Серверы 104а, 104b формируют часть одного кластера 108а. Поскольку серверы 104а, 104b обмениваются информацией с клиентскими устройствами 102а, 102b не напрямую, то для передачи данных между двумя серверами 104а, 104b и, соответственно, между двумя пользователями 302 используется протокол 216 Consistency. Хотя в рассматриваемом варианте описывается только совместное использование установочных параметров, в альтернативном варианте (здесь не рассматривается) пользователи 302 аналогичным образом могут совместно использовать пользовательские объекты.

[00120] Блок-схема 300 содержит два больших блока 332а, 332b. В первом блоке 332а первый пользователь 302а передает в первое клиентское устройство 102а команду (сообщение 304) на открытие секции установочных параметров, и затем клиентское устройство 102а выполняет процедуру SettingsOpenView() (сообщение 306), которая обеспечивает передачу этих установочных параметров в первый сервер 104а. Одновременно второй пользователь 302b аналогичным образом передает команду во второе клиентское устройство 102b (сообщения 308 и 310). Во втором блоке 332b пользователи 302 одновременно редактируют свои установочные параметры. Первый пользователь 302а редактирует свои установочные параметры путем запуска первым клиентским устройством 102а процедуры UTEditSetting() (сообщение 312), после чего первое клиентское устройство 102а обновляет установочные параметры, записанные на первом сервере 104а, путем запуска на этом сервере процедуры SettingsUpdateView() (сообщение 314). Затем первый сервер 104а запускает процедуру ConsistencySetEntries() (сообщение 316), которая выполняет процедуру SetEntries и передает установочные данные, введенные первым пользователем 302а, во второй сервер 104b. Затем второй сервер 104b передает полученные установочные параметры во второе клиентское устройство 102b путем вызова процедуры SettingsNotifyViewUpdate() (сообщение 318), после чего второе клиентское устройство 102b обновляет информацию второго пользователя 302b (сообщение 320). Одновременно второй пользователь 302b аналогичным образом модифицирует установочные параметры и передает их в первый сервер 104а с использованием протокола 216 Consistency (сообщения 322, 324, 326, 328 и 330). Каждый из серверов 104а, 104b постоянно записывает пользовательские установочные параметры, так чтобы их не нужно было повторно синхронизировать между серверами 104а, 104b в случае перезагрузки одного из серверов.

Приложение 224 общих событий и сигналов тревоги

[00121] В процессе работы системы 100 информация, постоянно формируемая в режиме реального времени, передается между узлами кластера 108. Примерами такой информации, которую в режиме реального времени приложение 224 общих событий и сигналов тревоги распространяет между узлами, являются: состояние тревоги (то есть, в системе 100 включен сигнал тревоги); системные события, такие как обнаружение движения в следующих ситуациях: когда устройство (такое как видеокамера 106, являющаяся узлом) передает цифровые данные остальным участникам системы 100, или устройство (такое как датчик движения) подсоединено к системе 100, или устройство осуществляет текущую запись, или сигнал тревоги был введен или подтвержден пользователями 302, или один из пользователей 302 осуществляет проверку системы 100, или один из серверов 104 неисправен, или устройство, подсоединенное к системе, неисправно, или была совершена транзакция в точке продаж; а также уведомления, передаваемые серверным узлом в клиентское устройство, такие как уведомления об изменении установок/данных, о состоянии текущей записи, уведомления об обновлении шкалы времени, и результаты запросов базы данных. В рассматриваемом варианте данные, передаваемые между узлами с использованием протокола 214 Synchrony, которые указываются как "данные синхронизации", формируются в динамическом режиме и сохраняются узлами.

[00122] На фигуре 4 приведена диаграмма 400 последовательности UML, на которой уведомление о сигнале тревоги распространяется между серверами 104 с использованием протокола 214 Synchrony. На диаграмме 400 указаны следующие объекты: одна из видеокамер 114, не являющаяся узлом, три сервера 104 в первом кластере 108а и второе клиентское устройство 102b, присоединенное к одному из серверов 104 в первом кластере 108а.

[00123] В первых трех блоках 402 диаграммы 400 каждый из серверов 104 присоединяется к кольцу синхронизации, указанному как "ServerState", так что состояние любого из серверов 104 может быть передано в любой другой сервер 104, и в рассматриваемом варианте будет передаваться состояние "AlarmStateTriggered" (включен сигнал тревоги), что означает, что был включен сигнал тревоги на одном из серверов 104 в связи с событием, которое обнаружено видеокамерой 114. В блоке 404 второй сервер 104b задается в качестве главного ("master") для приложения сигналов тревоги, что означает, что именно второй сервер 104b определяет, удовлетворяет ли входная информация видеокамеры 114 критерию перехода в состояние AlarmStateTriggered, и передает в другие серверы 104а, 104с кольца синхронизации сообщение для их перехода также в состояние AlarmStateTriggered.

[00124] Первый пользователь 302b подключается к третьему серверу 104с после того, как серверы 104 присоединились к кольцу синхронизации ServerState (сообщение 406). После подключения пользователя 302b третий сервер 104с присоединяется к другому кольцу синхронизации, указанному как "ClientNotification" (описывается ниже более подробно), и это кольцо используется для передачи состояний системы пользователю 302b, в то время как кольцо синхронизации ServerState используется для передачи информации только между серверами 104. Видеокамера 114, не являющаяся узлом, передает цифровую информацию, например, информацию, которая показывает, что было открыто окно или открыта дверь, в первый сервер 104а (сообщение 410), после чего первый сервер 104а проверяет, удовлетворяет ли эта получаемая им цифровая информация набору правил, для определения необходимости включения сигнала тревоги в системе 100 (сообщение 412). В рассматриваемом варианте первый сервер 104а определяет, что должен быть включен сигнал тревоги, и, соответственно, вызывает процедуру AlarmTriggerQ, которая предупреждает второй сервер 104b о необходимости изменения состояний. Затем второй сервер 104b изменяет состояния на AlarmStateTriggered (сообщение 416) и передает сообщение в кольцо синхронизации ServerState, которое передает в другие два сервера 104а, 104с команды на изменение состояний также на AlarmStateTriggered (блок 418). После передачи команд в другие серверы 104а, 104с второй сервер 104b выполняет процедуру AlarmTriggerNotification() (сообщение 420), которая обеспечивает присоединение второго сервера 104b к кольцу синхронизации ClientNotification (блок 422), и передает сообщение в кольцо синхронизации ClientState, которое вызывает переход третьего сервера 104с, который является другим сервером в кольце синхронизации ClientState, в состояние NotifyAlarmTriggered (извещение о включенном сигнале тревоги) (блок 424). После перехода третьего сервера 104с в это состояние он напрямую информирует о включении сигнала тревоги второе клиентское устройство 102b, которое транслирует это сообщение второму пользователю 302b и ожидает подтверждения им сигнала тревоги (сообщения 426). После подтверждения пользователем 302b сигнала тревоги второй сервер 104b, соответственно, изменяет состояния на AlarmStateAcknowledged (подтверждение состояния сигнала тревоги) (сообщение 428) и затем передает сообщение в кольцо синхронизации ServerState, чтобы другие два сервера 104а, 104с также выполнили соответствующее изменение состояния (блок 430). Затем второй сервер 104b изменяет состояние снова на NotifyAlarmAcknowledged (подтверждение уведомления о сигнале тревоги) (сообщение 432) и передает сообщение в третий сервер 104с через кольцо синхронизации ClientNotification для обеспечения соответствующего изменения его состояния (блок 434). Затем третий сервер 104с уведомляет клиентское устройство 102с о том, что система 100 подтвердила сигнал тревоги (сообщение 436), и клиентское устройство 102с ретранслирует это сообщение второму пользователю 302b (сообщение 438).

[00125] В альтернативном варианте (здесь не рассматривается), в котором происходит отказ второго сервера 104b, и он не может более работать в качестве главного сервера для кольца синхронизации, система 100 автоматически задает другой сервер 104 для работы в качестве главного сервера для этого кольца. Главный сервер кольца синхронизации - это единственный сервер 104, которому разрешается вызывать изменение состояния других узлов этого кольца, когда оно используется для распространения уведомлений о сигнале тревоги между узлами.

[00126] На фигуре 7 приведено изображение 700, представляемое пользователям 302 при подтверждении состояния тревоги в соответствии с диаграммой 400 фигуры 4. Изображение 700 содержит поля 702а, 702b и 702с (вместе "поля 702"), на которых которые в режиме реального времени выводится потоковое видео, поступающее из видеокамеры 114, не являющейся узлом, а также индикаторы 704 сигналов тревоги, указывающие на включение сигнала тревоги на основании информации, получаемой от видеокамеры 114, и кнопки 706 подтверждения, которые нажимает второй пользователь 302b для подтверждения включения сигнала тревоги.

Приложение 222 общих изображений и взаимодействия

[00127] Пользователям 302 системы 100 может также понадобиться обмен друг с другом изображениями 700 и возможность взаимодействия, например, путем обмена сообщениями и переговоров друг с другом через систему 100 при обмене изображениями 700. Это приложение 222 совместно используемых изображений и взаимодействия позволяет пользователям 302 обмениваться данными, такими как состояние изображения и уведомлениями сервер-клиент, такими как сообщения пользователей, и обмениваться запросами. Этот тип данных является данными синхронизации, которые распространяются в режиме реального времени.

[00128] На фигуре 5 приведена диаграмма 500 последовательности UML, на которой изображения 700 распространяется между пользователями 302 с использованием протокола 214 Synchrony. Диаграмма 500 содержит шесть объектов: первый 302а и второй 302b пользователи, первое 102а и второе 102b клиентские устройства, с которыми связаны, соответственно, первый 302а и второй 302b пользователи, а также первый 104а и второй 104b серверы, к которым подсоединены, соответственно, первое 102а и второе 102b клиентские устройства.

[00129] Первый пользователь 302а подключается к первому серверу 104а через первое клиентское устройство 102а (сообщение 502), после чего первый сервер 104а присоединяется к кольцу синхронизации ClientNotification (блок 504). Аналогично, второй пользователь 302b подключается ко второму серверу 104b через второе клиентское устройство 102b (сообщение 506), после чего второй сервер 104b также присоединяется к кольцу синхронизации ClientNotification (блок 508).

[00130] Затем первый пользователь 302а вводит сообщение для первого клиентского устройства 102а, в котором указано, что он хочет передать его изображение 700 для совместного использования. Первый пользователь 302а осуществляет это действие путем нажатия соответствующей кнопки (сообщение 510), в результате чего первое клиентское устройство 102а открывает изображение 700, которое должен быть передано для совместного использования ("совместно используемое изображение 700"), на первом сервере 104а (сообщение 512). Первый сервер 104а создает сеанс совместно используемого изображения (сообщение 514) и затем передает идентификатор сеанса в первое клиентское устройство 102а (сообщение 516).

[00131] В блоке 518 каждое клиентское устройство 102 присоединяется к кольцу синхронизации, которое обеспечивает им возможность получить совместно используемое изображение 700. Первый сервер 104а присоединяется к кольцу синхронизации SharedViewl в блоке 520. Одновременно первое клиентское устройство 102а передает в первый сервер 104а команду на передачу объявления другому серверу 104b по протоколу 214 Synchrony о том, что изображение 700 первого пользователя 302а может быть использовано совместно путем передачи в первый сервер 104а перечня пользователей и идентификатора сеанса (сообщение 522). Первый сервер 104а выполняет это путем передачи сообщения во второй сервер 104b по кольцу синхронизации ClientNotify, в результате чего второй сервер 104b переходит в состояние NotifyViewSession (уведомление о сеансе совместно используемого изображения) (блок 524). В состоянии NotifyViewSession второй сервер 104b побуждает второе клиентское устройство 102b передать команду второму пользователю 302b на получение изображения 700 первого пользователя 302а (сообщения 526 и 528), и подтверждение второго пользователя 302b ретранслируется во второй сервер 104b (сообщения 530 и 532). Затем второй сервер 104b присоединяется к кольцу синхронизации SharedViewl (блок 534), которое используется для распространения изображения 700 первого пользователя 302а.

[00132] Во втором блоке 519 каждый пользователь 302 обновляет совместно используемое изображение 700, и эти обновления распространяются между пользователями в автоматическом режиме. Первый пользователь 302а увеличивает изображение первого поля 702а, так чтобы оно занимало все изображение 700 (сообщение 536), и первое клиентское устройство 102а ретранслирует на первый сервер 104а это увеличение первого поля 702а первым пользователем 302а. Первый сервер 104а передает увеличенные детали изображения на второй сервер 104b путем передачи их по кольцу синхронизации SharedViewl (блок 540). Соответственно, второй сервер 104b обновляет совместно используемое изображение 700, отображаемое на втором клиентском устройстве 102b (сообщение 542), и затем обновленное изображение 700 отображается второму пользователю 302b (сообщение 544). Одновременно второй пользователь 302b панорамирует второе поле 702b на совместно используемом изображении 700 (сообщение 546), и второе клиентское устройство 102b ретранслирует на второй сервер 104b, как второй пользователь 302b осуществил панорамирование этого поля 702b (сообщение 548). Затем второй сервер 104b передает детали изображения на первый сервер 104а путем передачи их по кольцу синхронизации SharedViewl (блок 550). Соответственно, первый сервер 104а обновляет совместно используемое изображение 700, отображаемое на первом клиентском устройстве 102а (сообщение 552), и затем обновленное совместно используемое изображение 700 отображается первому пользователю 302а (сообщение 556).

[00133] После выполнения действий второго блока 519 первый пользователь 302а закрывает свое изображение 700 (сообщение 556), и это ретранслируется на первый сервер 104а (сообщение 558). Соответственно, первый сервер 104а выходит из кольца синхронизации SharedViewl (сообщение и блок 560). Аналогично, второй пользователь 302b закрывает свое изображение 700, в результате чего второй сервер 104b выходит из кольца синхронизации SharedViewl (сообщения 562 и 564, а также сообщение и блок 566).

[00134] В примере, показанном на фигуре 5, пользователи 302 панорамируют и увеличивают масштаб совместно используемого изображения 700. В альтернативных вариантах (здесь не рассматриваются) пользователи 302 могут модифицировать совместно используемого изображения 700 и другими способами. Например, пользователи 302 могут изменять расположение полей 702; задавать режим передачи "живого" или записанного видео, и в этом случае пользователи 302 также могут пользоваться традиционными функциями "пауза", "воспроизведение" или "переход"; а также отображать пользовательские объекты, такие как карты или веб-страницы, вместе с информацией по этим объектам, например, с историей их изменений. В этих альтернативных вариантах примеры информации дополнительных состояний, которая синхронизируется с использованием кольца синхронизации, включают режимы "пауза", "воспроизведение" или "переход", а также историю пользовательского объекта.

[00135] Хотя вышеприведенное описание относится к реализации приложения 222 совместно используемых изображений и взаимодействия в одноранговой системе 100 физической защиты, схема которой приведена на фигуре 1, однако это приложение 222 может быть реализовано также и в интегрированной системе физической защиты, содержащей множество серверов 104 и центральный шлюзовый сервер. Пример этого более общего варианта иллюстрируется на фигуре 12, на которой приведена блок-схема способа 1200 совместного использования изображения в системе физической защиты, которая содержит множество серверных узлов. Выполнение способа 1200 начинается на стадии 1202 с переходом на стадию 1204, на которой данные состояния изображения, представляющие изображение, отображаемое первым клиентским устройством (таким как, например, первое клиентское устройство 102а), которое должно быть распространено, передаются в первый серверный узел (такой как, например, первый сервер 104а, и данные состояния вида передаются ему в сообщении 538). На стадии 1206 данные состояния изображения ретранслируются с первого серверного узла во второе клиентское устройство (такое как, например, второе клиентское устройство 102b) через второй серверный узел (такой как, например, второй сервер 104b, и данные состояния изображения передаются через блок 540 в сообщении 538). Затем на стадии 1208 второе клиентское устройство обновляет изображение на дисплее, используя данные состояния изображения, для показа передаваемого изображения (такого как, например, изображение, передаваемое сообщением 544) В ответ на изменение совместно используемого изображения на втором клиентском устройстве, в частности, изменение, происшедшее в результате взаимодействия с пользователем на втором клиентском устройстве (с использованием сообщения 546) на стадии 1210 обновленные данные состояния изображения передаются из второго клиентского устройства на второй серверный узел (с использованием сообщения 548). Обновленные данные состояния изображения представляют совместно используемое изображение, как оно отображается на втором клиентском устройстве. Обновленные данные состояния изображения передаются из второго серверного узла на первое клиентское устройство через первый серверный узел на стадии 1212 (блок 550 и сообщение 552), и на стадии 1214 изображение на дисплее первого клиентского устройства обновляется для показа совместно используемого изображения, измененного на втором клиентском устройстве, с использованием обновленных данных состояния изображения (сообщение 554). Выполнение способа 1200 заканчивается на стадии 1216. В альтернативном варианте, в котором используется интегрированная система с центральным шлюзовым сервером, все данные состояния вида могут маршрутизироваться через этот центральный сервер.

Приложение 225 распространения дистанционно управляемого изображения

[00136] Пользователям 302 системы 100 может быть также необходима возможность просматривать и контролировать изображение на дисплее, который непосредственно или опосредованно присоединен к одному из серверов 104, которым пользователи не могут управлять напрямую, то есть, пользователи 302 могут управлять им через другие серверы (такой дисплей указывается как "дистанционно управляемый дисплей", и изображение на таком дисплее указывается как "дистанционно управляемое изображение"). Например, дистанционно управляемый дисплей может быть установлен на стене перед пользователями 302 и подсоединен к кластеру 108 серверов через один из серверов 104 в кластере 108, в то время как пользователи 302 могут быть подсоединены к кластеру 108 через другие серверы 104 этого кластера. Ниже со ссылкой на фигуру 10 описывается, как приложение 225 распространения дистанционно управляемого изображения позволяет пользователям 302 просматривать и управлять этим изображением, несмотря на то что никто из пользователей 302 не подсоединен напрямую к серверу 104, управляющему этим изображением. Данные изображения, которые передаются между серверами 104 для обеспечения указанной функциональной возможности, - это данные синхронизации, которые передаются между серверами в режиме реального времени.

[00137] На фигуре 10 приведена диаграмма 1000 последовательности UML, на которой дистанционно управляемое изображение дублируется для первого пользователя 302а с использованием протокола 214 Synchrony. Диаграмма 1000 содержит шесть объектов: первый пользователь 302а; первое клиентское устройство 102а, к которому подсоединен первый пользователь 302а и которое содержит дисплей ("клиентский дисплей"), с которым взаимодействует первый пользователь 302а; первый 104а и второй 104b серверы; программа 1004 монитора, работающая в аппаратном комплексе, таком как необслуживаемое клиентское устройство 102, соединенное со вторым сервером 104b и с дистанционно управляемым дисплеем; а также администратор 1002, который задает установки программы 1004 монитора. В одном из альтернативных вариантов (здесь не рассматривается) дистанционно управляемый дисплей может быть непосредственно подсоединен ко второму серверу 104b, и программа 1004 монитора может работать на этом сервере.

[00138] Как показано на фигуре 10, администратор 1002 создает экземпляр 1004 программы монитора (сообщение 1006), которая автоматически подсоединяется логически ко второму серверу 104b (сообщения 1008 и 1010). Экземпляр 1004 программы монитора обеспечивает возможность получения дистанционно управляемого изображения на втором сервере 104b путем вызова процедуры SharedViewOpen(viewState), где viewState - данные состояния изображения, характеризующие дистанционно управляемое изображение (сообщение 1012). Затем второй сервер 104b создает сеанс совместно используемого изображения (сообщение 1014) путем запуска процедуры SharedViewSessionCreate() и передает соответствующий идентификатор сеанса в экземпляр программы монитора (сообщение 1016). После получения идентификатора сеанса экземпляр 1004 программы монитора присоединяется к кольцу синхронизации SharedView1 (блок 1020), которое используется для передачи данных о состоянии изображения между другими серверами 104 кластера 108, являющимися участниками кольца синхронизации SharedView1.

[00139] После присоединения к кольцу синхронизации SharedView1 экземпляр 1004 программы монитора передает на другие серверы 104 в кластере 108 уведомление о том, что дистанционно управляемое изображение доступно для просмотра и управления. Экземпляр 1004 программы монитора осуществляет это путем вызова процедуры RegisterMonitor(sessionId) на втором сервере 104b (сообщение 1018), в результате чего идентификатор сеанса, относящегося к дистанционно управляемому изображению, должен быть зарегистрирован в каталоге изображений (блок 1022). Каталог изображений распространяется между другими серверами 104 кластера 108 с использованием протокола 216 Consistency.

[00140] После того как каталог изображений распространен между другими серверами 104 в кластере 108, они могут осуществлять доступ к этому каталогу для определения дистанционно управляемых изображений, которые доступны для просмотра и управления. После того как первый сервер 104а получит каталог изображений, первый пользователь 302а через первое клиентское устройство 102а подсоединяется логически к первому серверу 104а, получая доступ к кластеру 108 (сообщение 1024) и к каталогу изображений. Первый пользователь 302а вводит команду в первое клиентское устройство 102а на отображение дистанционно управляемого изображения путем вызова процедуры UIDisplayMonitor(sessionId) (сообщение 1026), в результате чего первое клиентское устройство 102а передает идентификатор сеанса дистанционно управляемого изображения в первый сервер 104а с инструкциями на открытие дистанционно управляемого изображения (сообщение 1028). Первый сервер 104а подтверждает получение инструкций из первого клиентского устройства 102а (сообщение 1030) и затем присоединяется к кольцу синхронизации SharedView1 (блок 1032) для получения в автоматическом режиме данных о состоянии изображения, описывающих текущее изображение на дистанционно управляемом дисплее (сообщение 1034), причем первый сервер 104а будет автоматически уведомляться о любых последующих изменениях дистанционно управляемого изображения.

[00141] Затем первый пользователь 302а осуществляет панорамирование одного из полей дистанционно управляемого изображения, как оно отображается на клиентском дисплее (сообщение 1036), и первое клиентское устройство 102а ретранслирует это действие и указатель поля, которое панорамируется, в первый сервер 104а путем вызова процедуры SharedViewUpdate(action=pan, panelId=2) (сообщение 1038). Первый сервер 104а передает обновленные данные состояния изображения на все серверы 104, которые являются участниками кольца синхронизации SharedView1 (блок 1040), в результате чего все эти серверы 104 получают возможность воспроизведения обновленного варианта дистанционно управляемого изображения. Второй сервер 104b получает эти обновленные данные состояния изображения и ретранслирует их в экземпляр 1004 программы монитора путем вызова процедуры NotifySharedViewUpdate(action=pan, params, panelId=2) (сообщение 1042). Затем экземпляр 1004 программы монитора обновляет дистанционно управляемое изображение для осуществления модификации, выполненной первым пользователем 302а (сообщение 1044).

[00142] В примере, показанном на фигуре 10, первый пользователь 302а осуществляет панорамирование одного из полей дистанционно управляемого изображения. В альтернативных вариантах (здесь не рассматриваются) первый пользователь 302а может модифицировать дистанционно управляемое изображение и другими способами. Например, первый пользователь 302а может: изменять расположение одного или нескольких полей дистанционно управляемого изображения; задавать режим передачи "живого" или записанного видео, и в этом случае пользователь 302а также может пользоваться традиционными функциями "пауза", "воспроизведение" или "переход"; а также отображать пользовательские объекты, такие как карты или веб-страницы, вместе с информацией по этим объектам, например, с историей их изменений. В этих альтернативных вариантах примеры информации дополнительных состояний, которая синхронизируется с использованием кольца синхронизации, включают режимы "пауза", "воспроизведение" или "переход", а также историю пользовательского объекта.

[00143] В другом альтернативном варианте (здесь не рассматривается) приложение 225 распространения дистанционно управляемого изображения может быть использовано для создания составного изображения, содержащего матрицу, составленную из n×m дистанционно управляемых изображений. Например, для случая n=m=2, когда имеется четыре дистанционно управляемых дисплея, первый пользователь 302а может управлять всеми четырьмя такими дисплеями одновременно для формирования одного большого виртуального дисплея. Затем полученный один видеоряд может быть увеличен, так чтобы каждое дистанционно управляемое изображение занимало один квадрант дисплея, то есть, изображения всех четырех дистанционно управляемых дисплеев могут быть показаны на одном дисплее. В этом варианте экземпляры 1004 программы монитора для дистанционно управляемых дисплеев могут обмениваться информацией с кластером 108 серверов через один из четырех серверов 104.

[00144] Хотя на фигуре 10 показан лишь первый пользователь 302а, в альтернативных вариантах (здесь не рассматриваются) дистанционно управляемое изображение может быть доступно для просмотра и управления нескольким пользователям 302 путем присоединения их к кольцу синхронизации SharedView1. В вышеописанном примере составного дисплея, содержащего матрицу n×m дистанционно управляемых дисплеев, составной дисплей может быть установлен в помещении для одновременного просмотра несколькими пользователями 302, каждый из которых имеет возможность управления каждым из дистанционно управляемых дисплеев.

[00145] Хотя вышеприведенное описание относится к реализации приложения 225 распространения дистанционно управляемых изображений в системе 100 физической защиты, схема которой приведена на фигуре 1, однако это приложение 225 может быть реализовано и в интегрированной системе физической защиты, содержащей множество серверов 104 и центральный шлюзовый сервер. Пример этого, более общего, варианта иллюстрируется на фигуре 11, на которой приведена блок-схема способа 1100 взаимодействия с дистанционно управляемым дисплеем в системе физической защиты, которая содержит множество серверных узлов. Способ начинается на стадии 1102 с переходом на стадию 1104, на которой второй серверный узел (такой как второй сервер 104b), который может обмениваться информацией с дистанционно управляемым дисплеем, передает на первый серверный узел (такой как первый сервер 104а) данные состояния изображения, которые характеризуют дистанционно управляемое изображение (через кольцо синхронизации, блоки 1020 и 1032 фигуры 10). Затем следует переход на стадию 1106, на которой по меньшей мере часть дистанционно управляемого изображения отображается на клиентском дисплее (обновление клиентского дисплея в соответствии с сообщением 1034 фигуры 10). В альтернативном варианте, в котором используется интегрированная система с центральным шлюзовым сервером, все данные состояния изображения могут маршрутизироваться через этот центральный сервер.

Приложение 220 потоков кластера

[00146] Один из пользователей 302 может также захотеть просматривать потоковое видео с одной из видеокамер 106, 114, если двухточечное соединение между этим пользователем 302 и этой видеокамерой 106, 114 отсутствует, и в этом случае приложение 220 потоков кластера может обеспечить такую возможность. На фигуре 6 приведена диаграмма 600 последовательности UML, на которой потоковое видео поступает из видеокамеры 114, не являющейся узлом, первому пользователю 302а через первый 104а и второй 104b серверы и первое клиентское устройство 102а. Диаграмма UML содержит пять объектов: первый пользователь 302а, первое клиентское устройство 102а, первый 104а и второй 104b серверы, также видеокамера 114, не являющаяся узлом. Первое клиентское устройство 102а может непосредственно обмениваться информацией с первым сервером 104а, однако не может обмениваться информацией непосредственно со вторым сервером 104b. Однако первый 104а и второй 104b серверы могут непосредственно обмениваться информацией друг с другом. Кроме того, в то время как второй сервер 104b и видеокамера 114 могут непосредственно обмениваться информацией друг с другом, первый сервер 104а и видеокамера 114 не могут обмениваться информацией непосредственно.

[00147] Второй сервер 104b сначала устанавливает сеанс с видеокамерой 114, так чтобы потоковое видео передавалось из нее во второй сервер 104b. Второй сервер 104b сначала задает сеанс протокола поточной передачи в режиме реального времени (RTSP) с видеокамерой 114 (сообщения 602 и 604) и передает в видеокамеру 114 команду на передачу видео (сообщения 606 и 608). После этого видеокамера 114 начинает поточную передачу (сообщение 610).

[00148] Первый пользователь 302а устанавливает соединение с первым клиентским устройством 102а (сообщение 612) и затем вводит в него команду на открытие окна, в которое выводится потоковое видео (сообщение 614). Затем первое клиентское устройство 102а вызывает процедуру LookupRoute() (поиск маршрута) для определения сервера 104, с которым необходимо соединиться, и поскольку первое клиентское устройство 102а не может соединиться непосредственно со вторым сервером 104b, оно устанавливает соединение RTSP с первым сервером 104а (сообщение 618). После этого первый сервер 104а вызывает процедуру LookupRoute() для определения узла, с которым необходимо соединиться для получения доступа к видео в режиме реального времени, и определяет, что необходимо соединиться со вторым сервером 104b (сообщение 620). Затем первый сервер 104а устанавливает соединение RTSP со вторым сервером 104b (сообщение 622), который возвращает идентификатор сеанса на первый сервер 104а (сообщение 624). Первый сервер 104а ретранслирует идентификатор сеанса в первое клиентское устройство 102а (сообщение 626). Используя этот идентификатор сеанса, первое клиентское устройство 102а передает команду на второй сервер 104b на запуск воспроизведения RTSP-видео (сообщения 628-634), и второй сервер 104b передает потоковое видео первому пользователю 302а через второй сервер 104b, первый сервер 104а и первое клиентское устройство 102а (сообщения 636-640).

[00149] В то время как на фигуре 6 видео маршрутизируется от одной из видеокамер 114, соединенной с одним из серверов 104 в кластере 108, на другие серверы 104 в этом кластере 108, в альтернативных вариантах (здесь не рассматриваются) видео может также маршрутизироваться от одной из видеокамер 106, являющейся узлом, в кластере 108 через другие видеокамеры 106 этого же кластера 108.

Перезагрузка

[00150] В рассматриваемом варианте информация о составе кластера постоянно обновляется и хранится локально на каждом из узлов кластера. Когда один из узлов перезагружается, он снова присоединяется в автоматическом режиме к кластеру 108, участником которого он был до перезагрузки. Этот процесс иллюстрируется на фигуре 9, на которой приведена блок-схема способа 900. После выполнения стадии 806 один из узлов в кластере 108 перезагружается (стадия 902). После перезагрузки этот узел обращается к информации о составе кластера, записанной в постоянной памяти, которая идентифицирует кластер 108, участником которого этот узел был до перезагрузки (стадия 904), и затем снова присоединяется к этому кластеру 108 (стадия 906) с последующим возвращением на стадию 808. Достоинством возвращения узлов в кластер 108 после перезагрузки в автоматическом режиме является то, что система 100 восстанавливается после перезапуска одного или нескольких входящих в нее серверов. Поскольку каждый узел сохраняет данные согласования в постоянном запоминающем устройстве, то после возвращения узла в кластер 108 будет синхронизироваться лишь та часть данных согласования, которая изменилась с момента выхода узла из кластера 108, что обеспечивает экономию пропускной способности системы.

[00151] В то время как в настоящем описании были рассмотрены некоторые иллюстративные варианты осуществления изобретения, возможны также и другие варианты. Например, хотя в рассмотренном варианте видеокамеры 106, являющиеся узлами, и видеокамеры 114, не являющиеся узлами, отличаются друг от друга, в альтернативных вариантах (здесь не рассматриваются) одна видеокамера может одновременно быть видеокамерой 106 и видеокамерой 114. Например, как показано на фигуре 1, первая видеокамера 106а представляет собой узел, который является участником третьего кластера 108с, однако если первая видеокамера 106а была бы также подсоединена непосредственно к пятому серверу 104е, однако при этом хранила бы лишь свою информацию о составе кластера для третьего кластера 108с, то первая видеокамера оставалась бы участником третьего кластера 108с и одновременно действовала бы как видеокамера 114, не являющейся узлом, с точки зрения пятого сервера 104е.

[00152] Процессор, используемый в вышеописанных вариантах, может быть, например, микропроцессором, микроконтроллером, программируемым логическим контроллером, программируемой пользователем вентильной матрицей или специализированной интегральной микросхемой. Примеры машиночитаемых носителей информации относятся к долговременным запоминающим устройствами и включают носители на оптических дисках, такие как CD-ROMs и DVD, магнитные носители, такие как жесткие диски и другие типы носителей на магнитных дисках, полупроводниковые приборы, такие как устройства флэш-памяти, ЗУ с произвольным доступом и ЗУ, доступные только для чтения.

[00153] Предполагается, что любая часть любого варианта, рассмотренного в настоящем описании, может быть реализована или объединена с любой частью любого другого варианта, также рассмотренного в описании.

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

[00155] В то время как в настоящем описании были рассмотрены некоторые конкретные варианты осуществления изобретения, следует понимать, что возможны и другие варианты, которые охватываются объемом настоящего изобретения. Любому специалисту в данной области техники будет понятно, что возможны различные модификации и адаптации вариантов, рассмотренных в настоящем описании.

1. Способ совместного использования данных в системе физической защиты, содержащей множество серверных узлов, причем способ включает:

(a) обращение, с использованием одного из серверных узлов ("первый узел"), к идентификатору узла, идентифицирующего другой серверный узел ("второй узел"), причем первый и второй узлы составляют по меньшей мере часть кластера серверов, и идентификатор узла составляет по меньшей мере часть информации о составе кластера, идентифицирующей все, и доступные для всех, серверные узлы в кластере серверов;

(b) передачу данных из первого узла на второй узел; и

(c) добавление нового серверного узла к кластеру серверов, причем добавление включает:

(i) обмен версии информации о составе кластера, хранящейся на новом серверном узле, с версией информации о составе кластера, хранящейся на одном из серверных узлов, который уже является частью кластера серверов ("узел управления составом кластера"); и

(ii) синхронизацию версии информации о составе кластера, хранящейся на новом серверном узле, с версиями информации о составе кластера, хранящимися на всех серверных узлах, которые составляют часть кластера, прежде чем новый серверный узел присоединится к кластеру.

2. Способ по п. 1, в котором:

(a) кластер серверов содержит по меньшей мере три серверных узла; или

(b) способ включает:

(i) обращение, с использованием второго узла, к идентификатору узла, идентифицирующего первый узел; и

(ii) передачу дополнительных данных из второго узла на первый узел.

3. Способ по п. 1, в котором серверные узлы содержат видеокамеры, сетевые видеомагнитофоны и серверы управления доступом.

4. Способ по п. 1, в котором информация о составе кластера содержит:

(a) идентификатор узла, однозначным образом идентифицирующий каждый серверный узел в кластере серверов; и

(b) идентификатор кластера, однозначным образом идентифицирующий кластер серверов, к которому принадлежат серверные узлы.

5. Способ по п. 4, в котором каждый серверный узел в кластере серверов хранит локально и постоянно обновляет свою собственную версию информации о составе кластера.

6. Способ по п. 5, включающий также:

(a) перезагрузку одного из серверных узлов ("перезагруженный серверный узел") в кластере серверов; и

(b) после возвращения перезагруженного серверного узла в режим онлайн использование этого узла для осуществления следующих действий:

(i) обращение к идентификатору кластера, идентифицирующего кластер серверов; и

(ii) повторное присоединение к кластеру серверов в автоматическом режиме.

7. Способ по п. 5, в котором передача данных включает:

(a) поиск по идентификатору узла, с использованием первого узла, оконечного устройства связи для второго узла; и

(b) передачу данных из первого узла в оконечное устройство связи,

причем оконечное устройство связи и идентификатор узла содержат записи в карте сети, связывающей идентификаторы узлов для всех серверных узлов в кластере серверов с соответствующими оконечными устройствами связи, и каждый серверный узел в кластере узлов хранит локально и постоянно обновляет свою собственную версию карты сети.

8. Способ по п. 7, в котором карта сети обеспечивает возможность каждому из серверных узлов в кластере серверов передавать данные любому из остальных серверных узлов в этом кластере без использования центрального сервера.

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

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

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

11. Способ по п. 10, в котором:

(a) данные периодически распространяются по всем серверным узлам в кластере узлов; или

(b) данные передаются на второй узел, когда первый узел присоединяется к кластеру.

12. Способ по п. 10, в котором на каждом из серверных узлов в кластере серверов локально хранится домен с записями, которые могут быть модифицированы любым из узлов, и способ включает также формирование информации версии с использованием причинного механизма формирования версии, так что информация версии указывает, какой из серверных узлов самым последним модифицировал одну из записей.

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

(a) сравнение, с использованием второго узла, указанного хеш-значения высшего уровня с хеш-значением высшего уровня, сгенерированным путем хеширования версии соответствующего домена, хранимого локально на втором узле; и

(b) если хеш-значения высшего уровня отличаются, синхронизацию доменов на первом и втором узлах с использованием информации версий.

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

15. Способ по п. 14, включающий также:

(a) сравнение, с использованием второго узла, номера версии, полученного от первого узла, с номером версии соответствующей записи статуса, хранимой локально на втором узле; и

(b) если номера версий отличаются, обновление записи статуса, хранимой локально на втором узле, записью статуса, хранимой локально на первом узле.

16. Способ по п. 15, в котором обновление записи статуса включает передачу из первого узла на второй узел дополнительных записей статуса, хранимых локально на первом узле, которые были модифицированы вместе с записью статуса.

17. Способ по п. 5, в котором:

(a) первый и второй узлы составляют по меньшей мере часть группы серверных узлов в кластере, в которой первый узел может передавать данные с полным сохранением порядка сообщений всем серверным узлам в группе, и передача данных может включать передачу первым узлом данных всем серверным узлам в группе, или

(b) данные содержат потоковое видео, передаваемое с другого серверного узла в кластере серверов через первый узел на второй узел.

18. Способ по п. 17, в котором данные содержат изменяемые данные, генерируемые в процессе работы системы физической защиты.

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

20. Машиночитаемый носитель с постоянным хранением информации, содержащий программы и инструкции, исполнение которых процессором обеспечивает осуществление способа совместного использования данных в системе физической защиты, содержащей множество серверных узлов, по любому из пп. 1-18.