СПОСОБ СИНХРОНИЗАЦИИ БАЗ ДАННЫХ МЕЖДУ ДВУМЯ ПУНКТАМИ С ИСПОЛЬЗОВАНИЕМ ТРАНСПОРТНОГО ПРОТОКОЛА Российский патент 2022 года по МПК H04J3/06 H04L45/02 H04L69/40 

Перекрестные ссылки на родственные заявки

Настоящая заявка на выдачу патента испрашивает приоритет предварительной заявки на выдачу патента США No. 62/655,625, поданной 10 апреля 2018 авторами Дин Чен и др. под названием «Способ синхронизации баз данных между двумя пунктами с использованием транспортного протокола» (Dean Cheng, et al., “Point-to-Point Database synchronization Over a Transport Protocol,”) предварительной заявки на выдачу патента США No. 62/782,993, поданной 20 декабря 2018 авторами Дин Чен и др. под названием «Способ синхронизации баз данных между двумя пунктами с использованием транспортного протокола» (Dean Cheng, et al., “Point-to-Point Database synchronization Over a Transport Protocol,”), которые включены сюда посредством ссылки.

Область техники, к которой относится изобретение

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

Уровень техники

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

Сущность изобретения

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

В качестве опции, для какого-либо из предшествующих аспектов, другая реализация этого аспекта содержит, при управлении синхронизацией локальной базы данных с соседней базой данных, передачу, посредством передатчика в локальном узле, информации записей в соседнюю базу данных по целевой линии связи в сообщениях в единицах данных протокола регистрации локальной линии связи (Link-Local Registration Protocol Data Unit (LRPDU)). Информация базы данных сохранена в записях. Информацией о версиях записей (например, управляющей информацией) обмениваются посредством единиц LRPDU, передаваемых по целевой линии связи. Следовательно, сообщения в единицах LRPDU могут действовать в качестве механизма для индикации соседнему узлу, что записи базы данных были обновлены, и наоборот. В таком случае, сообщения в единицах LRPDU могут быть использованы для управления синхронизацией баз данных.

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

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

В качестве опции, для какого-либо из предшествующих аспектов, в другой реализации этого аспекта приветственное сообщение представляет собой приветственную единицу LRPDU, и эта приветственная единица LRPDU представляет целевую линию связи и виде идентификатора «Мое шасси» (My Chassis identifier (ID)), идентифицирующего локальный узел, и идентификатора «Мой порт» (My Port ID), идентифицирующего целевой порт в локальном узле, идентификатора «Соседнее шасси» (Neighbor Chassis ID), идентифицирующего соседний узел, и идентификатора «Соседний порт» (Neighbor Port ID), идентифицирующего целевой порт в соседнем узле. Эта целевая линия связи может быть специфицирована идентификатором (ID) шасси и идентификатором (ID) порта, который представляет целевой порт на каждом конце целевой линии связи. Этот подход позволяет однозначно идентифицировать целевую линию связи, и, следовательно, указать каждый из узлов - локальный узел и соседний узел, где может находиться соответствующий узел для целей передачи и приема единиц LRPDU.

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

В качестве опции, для какого-либо из предшествующих аспектов, другая реализация этого аспекта дополнительно содержит, определение, посредством процессора в локальном узле, что все обновленные записи в локальной базе данных подтверждены (квитированы) базой данных регистратора посредством сообщений в единицах LRPDU, где оповещение приложения о том, что локальная база данных синхронизирована с базой данных регистратора, инициируют на основе определения, что все обновленные записи в локальной базе данных квитированы базой данных регистратора посредством сообщений в единицах LRPDU. Заявитель может определить, что каждая запись квитирована, и сообщить приложению, когда все записи будут квитированы, и, следовательно, синхронизация между локальной базой данных и базой данных регистратора завершена.

В качестве опции, для какого-либо из предшествующих аспектов, в другой реализации этого аспекта совокупность сообщений в единицах LRPDU, квитирующих сообщения записей в единицах LRPDU, содержит сообщение с парциальным списком (Partial List) в единицах LRPDU, это сообщение с парциальным списком в единицах LRPDU содержит по меньшей мере один заголовок записи, квитирующий по меньшей мере одну обновленную запись. Сообщение с парциальным списком в единицах LRPDU действует в качестве квитирующего сообщения. Такое сообщение с парциальным списком в единицах LRPDU передано регистратором и обозначает для заявителя, что регистратор выполнил обновление, запрошенное сообщением записи в единицах LRPDU.

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

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

В качестве опции, для какого-либо из предшествующих аспектов, в другой реализации этого аспекта совокупность сообщений в единицах LRPDU, квитирующих сообщения записей в единицах LRPDU, содержит сообщение с полным списком (Complete List) в единицах LRPDU, это сообщение с полным списком в единицах LRPDU содержит заголовки записей, относящиеся ко всем записям базы данных регистратора. Это сообщение с полным списком в единицах LRPDU может передаваться регистратором через заданные промежутки времени. Сообщение с полным списком в единицах LRPDU содержит информацию о текущем состоянии базы данных регистратора. Следовательно, заявитель может использовать сообщение с полным списком в единицах LRPDU для того, чтобы определить, когда записи были приняты регистратором, а квитирующее сообщение было пропущено, и когда обновления записей не были приняты регистратором. Тогда заявитель может затем устранить погрешности синхронизации путем передачи дополнительных сообщений записей в единицах LRPDU на основе содержания сообщений с полным списком в единицах LRPDU.

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

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

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

В одном из вариантов, настоящее изобретение содержит способ, осуществляемый в локальном узле, способ содержит: генерацию, посредством процессора в локальном узле, кода разъединенности для приложения, этот код разъединенности указывает, что обмен приветственными сообщениями в единицах данных протокола регистрации локальной линии связи (в единицах LRPDU) не состоялся; прием, в процессоре, команды от приложения с целью поддержания локальной базы данных в запоминающем устройстве локального узла, несмотря на код разъединенности; прием, посредством приемника в локальном узле, сообщения с полным списком в единицах LRPDU от базы данных регистратора из соседнего узла после успешного обмена приветственными сообщениями в единицах LRPDU, это сообщение с полным списком в единицах LRPDU содержит заголовки для всех записей в базе данных регистратора; и сравнение, посредством процессора, заголовков записей из сообщения с полным списком в единицах LRPDU с заголовками записей в базе данных заявителя с целью ресинхронизации базы данных заявителя с базой данных регистратора. Этот механизм позволяет сохранять и поддерживать пару баз данных, несмотря на потерю соединения. Когда происходит потеря соединения, заявителю сообщают об этом и позволяют выбрать, будет ли он заново устанавливать синхронизацию после восстановления соединения (например, путем повторной передачи всех записей), или он будет восстанавливать синхронизацию после восстановления соединения. Пару баз данных можно поддерживать путем передачи сообщения с полным списком после повторного соединения посредством обмена приветствиями. База данных заявителя может затем сравнить заголовки записей из базы данных регистратора с заголовками записей из базы данных заявителя для определения, какие именно (если вообще какие-либо) обновления были утрачены из-за потери соединения. Затем база данных заявителя может передать повторно только утраченные обновления вместо того, чтобы повторно передавать весь список записей базы данных заявителя регистратору. Такой подход может уменьшить использование ресурсов сети связи и сократить время восстановления синхронизации, когда появится соединение между заявителем и регистратором.

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

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

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

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

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

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

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

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

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

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

Эти и другие варианты будут лучше понятны из последующего подробного описания, рассматриваемого в сочетании с прилагаемыми чертежами и Формулой изобретения.

Краткое описание чертежей

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

Фиг. 1 представляет упрощенную схему примера реализации собственной системы для сети синхронизации баз данных.

Фиг. 2 представляет упрощенную схему примера реализации прокси-системы для сети синхронизации баз данных.

Фиг. 3 представляет упрощенную схему примера системы баз данных для синхронизации баз данных.

Фиг. 4 представляет диаграмму протокола для примера способа управления синхронизацией баз данных.

Фиг. 5 иллюстрирует пример кодирования приветственного сообщения в единицах данных протокола регистрации локальной линии связи (в единицах LRPDU).

Фиг. 6 иллюстрирует пример кодирования сообщения записи в единицах LRPDU.

Фиг. 7 иллюстрирует пример кодирования сообщения с парциальным списком в единицах LRPDU.

Фиг. 8 иллюстрирует пример кодирования сообщения с полным списком в единицах LRPDU.

Фиг. 9 представляет логическую схему примера способа установления пары баз данных.

Фиг. 10 представляет логическую схему примера способа управления синхронизацией пары баз данных.

Фиг. 11 представляет логическую схему примера способа поддержания синхронизации баз данных, несмотря на прерывания соединения.

Фиг. 12 представляет упрощенную схему примера элемента сети связи для управления синхронизацией баз данных.

Фиг. 13 представляет упрощенную схему примера устройства для установления пары баз данных.

Фиг. 14 представляет упрощенную схему примера устройства для управления синхронизацией пары баз данных.

Фиг. 15 представляет упрощенную схему примера устройства для поддержания синхронизации баз данных, несмотря на прерывания соединения.

Подробное описание

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

Для поддержки синхронизации баз данных могут быть использованы стандартизированные протоколы связи. Такие протоколы связи могут быть конфигурированы для поддержания согласованности баз данных стандартизированным способом. Например, протокол регистрации локальной линии связи (Link-local Registration Protocol (LRP)) представляет собой стандарт, специфицирующий протоколы, процедуры и управляемые объекты для копирования регистрационной базы данных с одного конца на другой конец линии связи между двумя пунктами и для копирования изменений в части базы данных. Протокол LRP может быть оптимизирован для баз данных размером порядка одного МегаБайта. Протокол LRP синхронизации баз данных (LRP Database Synchronization (LRP-DS)) может быть использован для установления связи между базами данных. Протокол LRP-DS использует приветственные сообщения способом, аналогичным протоколу связи от одной промежуточной системы к другой промежуточной системе (Intermediate System to Intermediate System (IS-IS)), для установления соседства между узлами. Затем может быть использован протокол LRP транспорта баз данных (LRP Database Transport (LRP-DT)) для передачи (транспорта) данных, которые несут сообщения записей, генерируемых протоколом LRP-DS, способом, аналогичным сообщениям описания состояния линии связи (Link State Advertisement (LSA)), передаваемым по протоколу IS-IS. Протокол LRP-DS управляет, таким образом, синхронизацией баз данных от имени соответствующих приложений.

Здесь рассмотрены механизмы для усовершенствования функциональных возможностей протокола LRP-DS. Например, протокол LRP-DS может быть усовершенствован для автоматического установления пар баз данных для синхронизации. Такая пара баз данных содержит базу данных заявителя, расположенную в первом узле, и базу данных регистратора, расположенную во втором узле. Такие узлы могут также называться локальным узлом и соседним узлом, соответственно, для ясности обсуждения. Когда в базе данных заявителя сделаны обновления, протокол LRP-DS передает эти обновления в базу данных регистратора для поддержания синхронизации. Для связи в одном направлении локальный узел содержит базу данных заявителя, и соседний узел содержит базу данных регистратора. Для двусторонней связи локальный узел содержит базу данных заявителя для синхронизации с базой данных регистратора, находящейся в соседнем узле, а соседний узел содержит базу данных заявителя для синхронизации с базой данных регистратора, расположенной в локальном узле. В любом случае, пара (ы) баз данных может быть установлена автоматически посредством обмена приветственными сообщениями в единицах данных протокола регистрации локальной линии связи (единиц LRPDU). Эти приветственные сообщения в единицах LRPDU содержат идентификатор (AppId) соответствующего приложения и указание целевой линии связи, обозначенной идентификатором «Мое шасси» ID, идентифицирующим локальный узел, идентификатором «Мой порт» ID, идентифицирующим целевой порт в локальном узле, идентификатором «Соседнее шасси» ID, идентифицирующим соседний узел, и идентификатором «Соседний порт» ID, идентифицирующим целевой порт в соседнем узле. После обмена приветственными сообщениями локальный узел и соседний узел могут автоматически создать пару из базы данных заявителя и базы данных регистратора для идентифицированного приложения и осуществить корреляцию таких пар баз данных на основе целевой линии связи.

Протокол LRP-DS, работающий в компоненте, называемом порталом, может также быть использован для автоматического информирования приложения, когда базы данных станут синхронизированы после одного или нескольких обновлений. Например, когда в базе данных заявителя сделано какое-либо обновление, в базу данных регистратора передают сообщение записи в единицах LRPDU для индикации записи (ей) в базе данных, которая была обновлена, и последовательный номер (а) (например, номера версий) такой обновленной записи (ей). База данных регистратора отвечает сообщением с парциальным списком в единицах LRPDU, которое квитирует осведомленность об обновленных записях и которое может быть передано по протоколу LRP-DT. Когда сообщение с парциальным списком в единицах LRPDU принято, портал инициирует маркировку указанных записей в базе данных заявителя в качестве квитированных. Здесь можно обмениваться несколькими единицами LRPDU записей и единицами LRPDU парциального списка. Когда все записи в базе данных заявителя маркированы в качестве квитированных, портал может передать приложению индикацию того, что базы данных синхронизированы.

В другом примере, протокол LRP-DS может быть использован для поддержания синхронизации между базами данных, несмотря на прерывание связи. Приветственными сообщениями в единицах LRPDU можно обмениваться периодически. Когда обмен приветственными сообщениями в единицах LRPDU не состоялся (оказался неуспешным), портал может уведомить об этом приложение. Заявитель может выбрать ликвидацию спаривания и создание новой пары баз данных после восстановления соединения, для чего вновь загружает записи базы данных в новую базу данных регистратора. Заявитель может также выбрать поддержание текущей пары баз данных. Когда портал принимает индикацию, что спаривание баз данных следует поддерживать и сохранять, портал прерывает дальнейшую передачу сообщений записи в единицах LRPDU. После восстановления обмена приветственными сообщениями в единицах LRPDU регистратор передает сообщение с полным списком в единицах LRPDU заявителю. Сообщение с полным списком в единицах LRPDU содержит заголовки записей для всех записей в базе данных регистратора. База данных заявителя может сравнивать заголовки записей, входящих в это сообщение, с полным списком в единицах LRPDU с заголовками записей, сохраняемых в базе данных заявителя, для определения рассогласований каких-либо записей. Это может случиться, когда сообщения записи в единицах LRPDU оказываются утрачены из-за потери соединения. База данных заявителя может тогда передать сообщения записи в единицах LRPDU, содержащие любые обновления записей, сделанные с момента фиксации состояния записей, входящих в сообщение с полным списком в единицах LRPDU. Обычно результатом является передача меньшего числа записей в единицах LRPDU, чем было без быстрой передачи полного списка в единицах LRPDU. Этот портал может также уведомить приложение, когда базы данных будут синхронизированы. Эти и другие примеры вариантов обсуждаются более подробно со ссылками на следующие чертежи.

На Фиг. 1 представлена упрощенная схема примера реализации собственной системы для сети 100 связи для синхронизации баз данных. Сеть 100 связи для синхронизации баз данных содержит собственную систему 110 и собственную систему 130, соединенные сетью 171 связи Интернет-протокола (Internet Protocol (IP)). Эти собственная система 110 и собственная система 130 содержит одну или несколько баз данных 120 и 122, соответственно, для синхронизации. Для ясности обсуждения, одна из собственных систем 110 или 130 называется здесь локальной при обсуждении в отношении операций источника, имеющих место в первой системе, а другая называется здесь соседней при обсуждении в отношении операций адресата, имеющих место во второй системе. Следовательно, каждая из собственных систем 110 и 130 может быть локальной, соседней или и такой, и другой в зависимости от контекста. Следует также отметить, что термины «локальная» и «соседняя», как они используются здесь, являются относительными и применяемыми для четкого различения между первым узлом и вторым узлом, а также могут быть использованы взаимозаменяемо при обсуждении работы одной и той же сети связи с разных точек зрения.

Собственная система 110 представляет собой вычислительный компонент, содержащий приложение 111, портал 113, целевой порт 141 и базы 120 данных. Приложение 111 представляет собой компьютерную программу, работающую для распределения информации по меньшей мере между собственной системой 110 и/или прокси-систему и собственной системой 130 и/или прокси-системой. Прокси-системы обсуждаются в отношении Фиг. 2 ниже. Например, приложение 111 может содержать оперируемую пользователем программу с резервным файлом, синхронизированную с системой облачного хранилища информации. Приложение 111 загружает данные в приложение 131 и/или скачивает данные из приложения 131. Для простоты показаны только два приложения 111 и 131, но приложение 111 может синхронизироваться с любым числом других приложений.

Портал 113 представляет собой экземпляр интерфейса портала, который вместе с экземплярами конечных автоматов заявителя и/или регистратора и базами 120 данных ассоциирован с одним приложением 111. Например, этот портал 113 выполняет протокол LRP (например, протокол LRP-DS и/или протокол LRP-DT) от имени приложения 111. Этот портал 113 принимает уведомления от приложения 111 и/или баз 120 данных, выполняет операции соответствующего протокола LRP и передает соответствующие уведомления об этих операциях приложению 111 и/или базам 120 данных. Например, портал 113 выполняет протокол LRP-DS посредством управления передачей сообщений в единицах LRPDU. Этот портал 113 выполняет протокол LRP-DT посредством передачи и приема данных, таких как записи баз 120 данных, при обмене с соответствующим порталом 133, например, через соединение 170 протокола управления передачей (Transmission Control Protocol (TCP)). В некоторых примерах, приложение 111 в собственной системе 110 поддерживает отдельный портал 113 и соответствующие базы 120 данных в каждом из нескольких целевых портов 114 в собственной системе 110.

Собственная система 110 может также применять протокол обнаружения 161 на уровне линии связи (Link Layer Discovery Protocol (LLDP)) в целевом порте 141. В альтернативном варианте, собственная система 110 поддерживает управляемое системным администратором хранилище информации, содержащее данные, эквивалентные данным, генерируемым протокол LLDP 161.

Базы 120 данных содержат одно или несколько хранилищ информации, сохраняющих файлы для приложения 111. Файлы в базах 120 данных хранятся в виде записей. Запись представляет собой подмножество информации из базы 120 данных, передаваемое в виде единого блока от заявителя к регистратору в соответствии с протоколом LRP, выполняемым в портале 113. Каждая запись содержит данные, номер записи, идентифицирующий эти данные, и последовательный номер. Этот последовательный номер идентифицирует текущую версию записи. Например, последовательный номер может быть реализован в виде счетчика, указывающего число раз, когда обновлялась соответствующая запись. Совокупность баз 120 данных может содержать базу данных заявителя, базу данных регистратора или обе. «Заявитель» является одной из двух ролей (вместе с «регистратором»), какие может играть приложение 111 в отношении портала 113. Заявитель управляет базой 120 данных, которую протокол LRP копирует в базу регистратора в соседнем портале 133. «Регистратор» является одной из двух ролей (вместе с «заявителем»), какие может играть приложение 111 в отношении портала 113. Регистратор принимает копию базы 122 данных, которую протокол LRP копирует из базы заявителя, в соседнем портале 133. В такой ситуации, совокупность баз 120 данных, может содержать базу данных заявителя для загрузки записей в базу 122 данных, базу данных регистратора для скачивания записей из базы 122 данных или обе такие базы данных для двусторонней передачи и обмена записями с базами 122 данных.

Целевой порт 141 представляет собой порт связи в собственной системе 110. Портал 113 и ассоциированные с ним базы 120 данных заявителя и регистратора ассоциированы с единственным целевым портом 141. Целевой порт 141 может быть ассоциирован более чем с одним порталом 113, если такие порталы 113 обслуживают разные приложения 111. Целевой порт 141 предоставляет доступ к линии связи, которая соединяется с одним или несколькими другими целевыми портами 151 (например, в других системах).

Собственная система 130 по существу аналогична собственной системе 110. Собственная система 130 содержит портал 133, приложение 131, базу 122 данных и целевой порт 151, которые могут быть аналогичны порталу 113, приложению 111, базе 120 данных и целевому порту 141, соответственно.

Собственные системы 110 и 130 обнаруживают одна другую для установления пар баз 120 и 122 данных посредством протокола LLDP 161. Этот протокол LLDP 161 представляет собой протокол уровня линии связи, описываемый в стандарте 802.1AB, разработанном Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers (IEEE)) и используемый сетевыми устройствами для объявления их идентичности, функциональных возможностей и соседей в сети связи. В частности, собственные системы 110 и 130 могут объявить одна для другой о своих приложениях 111 и 131, а также о функциональных возможностях протокола LRP-DS и протокола LRP-DT через целевые порты 141 и 151 с использованием протокола LLDP 161. Адреса для использования протоколом LRP-DT при передаче сообщений в единицах LRPDU могут быть определены посредством протокола LLDP 161 вместе с предпочтениями для использования либо протокола 160 управления Edge (Edge Control Protocol (ECP)), либо протокола управления передачей (TCP) для передачи этих сообщений в единицах LRPDU. Протокол ECP 160 представляет собой протокол сети связи, определяемый стандартом IEEE Standard 802.1Q-2014. Протокол TCP 170 определен в документе «Запрос комментариев» (Request For Comment (RFC)) 793, выпущенном Рабочей группой инженеров Интернет (Internet Engineering Task Force (IETF)). Любой из этих протоколов может быть использован для передачи сообщений в единицах LRPDU. Если используется протокол ECP 160, пакеты этого протокола ECP проходят через целевые порты 141 и 151. Если используется протокол TCP 170, пакеты единиц LRPDU могут проходить через целевые порты 141, 151 или через какие-либо другие порты двух собственных систем 110 и 130.

Сообщения в единицах LRPDU действуют в качестве управляющих сообщений, указывающих обновления записей в базах 120 и/или данных, квитирование и другую управляющую информацию, относящуюся к синхронизации баз данных. Совокупность сообщений в единицах LRPDU, обсуждаемых здесь содержит приветственные сообщения в единицах LRPDU, сообщения записей в единицах LRPDU, сообщения с парциальным списком в единицах LRPDU, сообщения с полным списком в единицах LRPDU и сообщения с запросом получения полного списка в единицах LRPDU. Однако могут быть использованы и другие сообщения в единицах LRPDU, как потребуется для принудительной синхронизации баз 120 и 122 данных. Используя сообщения в единицах LRPDU, порталы 113 и 133 могут обмениваться записями баз 120 и 122 данных с целью синхронизации этих баз 120 и 122 данных. Например, обмен записями между базами 120 и 122 данных в единицах LRPDU может осуществляться через соединение 170 протокола TCP. Такое соединение 170 протокола TCP представляет собой сеанс связи между двумя пунктами для использования с целью обмена данными. Соединение 170 протокола TCP может проходить между целевыми портами 141 и 151 или между другими портами, в зависимости от примера. Соединение 170 протокола TCP может проходить через одну или несколько IP-сетей 171 связи, представляющих собой три сети связи уровня модели взаимодействия открытых систем (Open Systems Interconnection (OSI)), поддерживающие связь между двумя пунктами. Как обсуждается ниже со ссылками на чертежи, компоненты, перечисленные выше, могут быть использованы порталами 113 и/или 133 для управления синхронизацией баз 120 и 122 данных от имени приложений 111 и/или 131, частично через целевые порты 141 и 151.

На Фиг. 2 представлена упрощенная схема примера реализации прокси-системы для сети 200 связи для синхронизации баз данных. Сеть 200 связи для синхронизации баз данных содержит прокси-систему 210, прокси-систему 230, ведомую систему 240 и ведомую систему 250. Такая сеть 200 связи для синхронизации баз данных аналогична сети 100 связи для синхронизации баз данных, однако целевые порты 241 и 251 перенесены из собственных систем на ведомые системы 240 и 250, соответственно. Как используется здесь, прокси-система 210 и/или 230 представляет собой вычислительный компонент, содержащий по меньшей мере приложение 211, которое по существу аналогично приложению 111. Например, прокси-система 210 содержит по меньшей мере приложение 211, работающее для распределения информации между прокси-системой 210 и собственной системой и/или прокси-системой 230. Прокси-система 210 может также содержать портал 213 и/или базы 220 данных, которые по существу аналогичны порталу 113 и базе 120 данных, соответственно.

Ведомая система 240 может представлять собой компонент связи, такой как маршрутизатор, коммутатор и т.п., и может быть оконечной станцией, такой как видеокамера, механический привод или персональный компьютер. Ведомая система 240 связана с прокси-системой 210 посредством сетевого соединения. Ведомая система содержит по меньшей мере один целевой порт 241, который по существу аналогичен целевому порту 141. Компонент связи содержит несколько целевых портов 241. Прокси-система 210 и ведомая система 240 функционируют совместно способом, по существу аналогичным собственной системе 110. Благодаря расположению целевого порта 241 в ведомой системе 240 вместо прокси-системы 210, приложение 211, портал 213 и/или базы 220 данных могут быть выгружены в устройство (прокси-систему 210), которое может располагаться в сети связи, отдельной от сети связи, где находится ведомая система 240. Это создает гибкость при реализации, обеспечивая в то же время по существу такие же функциональные возможности.

Прокси-система 230 по существу аналогична прокси-системе 210 и содержит портал 233, приложение 231 и базы 222 данных, которые могут быть по существу аналогичны порталу 213, приложению 211 и базам 220 данных, соответственно. Ведомая система 250 связана с прокси-системой 230 и содержит целевой порт 251, который может быть по существу аналогичен целевому порту 241. Ведомые системы 240 и 250 используют протокол LLDP 261 для обмена сообщения протокола LLDP между целевыми портами 241 и 251 способом, аналогичным протоколу LLDP 161. Эти ведомые системы 250 и 240 могут передавать такие сообщения порталам 233 и 213 соответственно. Информация о записях, входящих в сообщения протокола LLDP, может быть использована для установления передач и приема записей из баз 220 и/или 222 данных с целью синхронизации через сеть 271 IP-протокола. Эта сеть 271 IP-протокола может быть по существу аналогичной сеть 171 IP-протокола. Такие записи могут быть переданы через соединение 270 протокола TCP, по существу аналогичное соединению 170 протокола TCP.

Следует отметить, что в пределах объема настоящего изобретения могут быть также использованы различные комбинации сетей 100 и 200 связи для синхронизации баз данных. Например, собственная система 110 может быть использована для синхронизации баз 120 данных с прокси-системой 230 и ведомой системой 250. Далее, собственная система 130 может быть использована для синхронизации баз 122 данных с прокси-системой 210 и ведомой системой 240. Для маршрутизации связи между собственными системами, прокси-системами и/или ведомыми системами могут быть использованы разнообразные ретрансляционные системы (например, маршрутизаторы и/или мосты). Такие компоненты могут иметь различные функциональные возможности, как обсуждается ниже. В любом устройстве связи приложения 111, 131, 211 и/или 231 могут обмениваться информацией между заявителем и регистратором в базах 120, 122, 220 и 222 данных через различные целевые порты 141, 151, 241 и 251, принадлежащие одной и той же системе.

На Фиг. 3 представлена упрощенная схема примера системы 300 баз данных для синхронизации баз данных. Система 300 баз данных может быть использована для реализации собственной системы 110, собственной системы 130, прокси-системы 210 и/или прокси-системы 230. Система 300 баз данных содержит приложение 311, которое по существу аналогично приложению 111, 131, 211 и/или 231. В частности, приложение 311 представляет собой программу, использующую данные для синхронизации с удаленной системой, такой как соседняя база данных. Это приложение организует портал 313, который по существу аналогичен порталу 113, 133, 213 и/или 233. Этот портал 313 выполняет протокол LRP (например, протокол LRP-DS и/или протокол LRP-DT) от имени приложения 311. Следовательно, портал 313, среди других процедур, управляет передачей сообщений в единицах LRPDU и записей для целей синхронизации. Портал 313 взаимодействует с приложением 311 и базами 320 данных, которые по существу аналогичны базам 120, 122, 220 и/или 222 данных. Совокупность баз 320 данных может содержать базу данных заявителя 321 и/или базу данных регистратора 325.

Заявитель 321 представляет собой конечный автомат и соответствующее пространство запоминающего устройства, конфигурированное для загрузки копий логически сохраняемых данных в регистратор, находящийся в соседней базе данных. Регистратор 325 представляет собой конечный автомат и соответствующее пространство запоминающего устройства, конфигурированное для приема копий удаленно сохраняемых данных от заявителя, находящегося в соседней базе данных. Следовательно, база 320 данных может содержать заявителя 321 для загрузки данных с целью синхронизации, регистратор 325 для скачивания данных с целью синхронизации, либо и для загрузки, и для скачивания в случае двусторонней синхронизации. Каждый из объектов - заявитель 321 и регистратор 325, ассоциирован с порталом 313 для обеспечения достижения управляющими сообщениями и данными запланированных пунктов назначения. Портал 313 дополнительно ассоциирован с целевым портом для обеспечения того, чтобы указанные сообщения были приняты в запланированных для них порталах-адресатах (например, в портале 313).

Данные в базах 320 данных сохранены в виде записей. Запись является наименьшей единицей данных, которая может быть передана и принята для целей синхронизации. Размеры записей могут быть конфигурированы приложением 311. Меньший размер записей создает сложность, но больший размер записей в результате ведет к передаче большего объема данных, когда осуществляется обновление записи.

Заявитель 321 содержит локальные записи 323 и заголовки 324 локальных записей. Локальные записи 323 представляют собой записи, содержащие данные, используемые локально приложением 311. Заголовки записей составляют заданную группу статусной информации, относящейся к соответствующим записям. Например, каждый из заголовков 324 локальных записей содержит номер записи, последовательный номер и/или контрольную сумму для соответствующих локальных записей 323. Номер записи обозначает соответствующую запись 323. Последовательный номер содержит информацию о версии. Например, последовательный номер может содержать счетчик, указывающий число раз, когда соответствующая запись была модифицирована. Контрольная сумма представляет собой информацию для проверки ошибок и может содержать число, представляющее сумму правильного числа цифр в соответствующем множестве данных для передачи. Например, контрольная сумма может обозначать сумму правильного числа цифр в номере записи и в последовательном номере. В такой ситуации, когда происходит обновление локальной записи 323, соответствующий заголовок 324 локальной записи может быть передан посредством сигнализации для обозначения записи, которая была обновлена, и версии (например, последовательного номера) этого обновления.

Регистратор 325 содержит соседние записи 326 и заголовки 327 соседних записей. Эти соседние записи 326 и заголовки 327 соседних записей аналогичны локальным записям 323 и заголовкам 324 локальных записей, соответственно, но относятся к данным, используемым приложением в соседнем узле/системе.

Соответственно, локальная база данных 320 может содержать базу данных заявителя 321 для сохранения локальных записей 323 с целью передачи в базу данных регистратора в соседней базе данных. Локальная база 320 данных может также содержать базу данных регистратора 325 для приема соседних записей 326 из базы данных заявителя, расположенного в соседней базе данных. Такая передача записей может быть осуществлена с использованием сообщений в единицах LRPDU. Например, сообщение записи в единицах LRPDU может быть передано из портала 313, когда происходит модификация локальных записей 323. Сообщение записи в единицах LRPDU содержит соответствующие заголовки 324 для уведомления регистратора, расположенного в соседней базе данных, о локальных записях 323, которые были обновлены, и о текущем порядковом номере обновления. Портал 313 может принять соответствующий частичный список записей из соседнего узла, который (список) подтверждает (квитирует) осведомленность об обновлениях локальных записей. Портал 313 может также установить передачу данных с порталом, находящимся в соседнем узле, для передачи обновленных локальных записей 323. Аналогично, заявитель, находящийся в соседнем узле, может передать сообщение записи в единицах LRPDU порталу 313, через соседний портал, для индикации изменений в соседней записи 326. Сообщение записей в единицах LRPDU из соседнего узла содержит заголовки обновленных соседних записей 327. Регистратор 325 может затем ответить через портал 313 посредством сообщения с парциальным списком в единицах LRPDU, содержащего заголовки 327 обновленных соседних записей для индикации осведомленности об обновлениях в соседней базе данных. Портал 313 может также управлять передачей данных обновленных соседних записей 326 из соседнего узла регистратору 325. Эти и другие схемы передачи сообщений для обмена записями и заголовками записей между заявителями 321 и регистраторами 325 с целью синхронизации баз данных обсуждаются ниже со ссылками на чертежи.

На Фиг. 4 представлена диаграмма протокола для примера способа 400 управления синхронизацией баз данных. Способ 400 может быть реализован собственной системой 110 и/или 130, прокси-системой 210 и/или 230 в сочетании с ведомой системой 240 и/или 250, и/или системой 300 баз данных. Способ 400 представляет механизмы для создания и поддержания пары баз данных, содержащей заявителя и регистратора. Процедура управления парой баз данных содержит поддержание синхронизации между базой данных заявителя и базой данных регистратора. Способ 400 осуществляется посредством приложения, локального портала, управляющего базой данных заявителя, расположенной в локальном узле, и соседнего портала, управляющего базой данных регистратора, расположенной в соседнем узле.

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

Соответственно, когда локальный портал принимает приветственные сообщения 403 в единицах LRPDU, этот локальный портал определяет, что идентификатор AppId ассоциирован с приложением для осуществления синхронизации баз данных. Затем локальный портал устанавливает локальную базу данных в запоминающем устройстве, расположенном в локальном узле, в качестве части пары баз данных для использования приложением. В этом примере, локальная база данных содержит заявителя. Далее, когда соседний портал принимает приветственные сообщения 401 в единицах LRPDU, этот соседний портал определяет, что идентификатор AppId ассоциирован с приложением для синхронизации баз данных. Соседний портал затем устанавливает соседнюю базу данных в запоминающем устройстве, расположенном в соседнем узле, в качестве части пары баз данных. В этом примере, соседняя база данных содержит регистратор. Каждый из порталов - локальный портал и соседний портал, ассоциирует пару баз данных с целевой линией связи. Локальный портал может тогда управлять синхронизацией локальной базы данных заявителя с соседней базой данных регистратора посредством целевой линии связи. Процедура управления синхронизацией локальной базы данных заявителя с соседней базой данных регистратора содержит передачу информации записей в соседнюю базу данных посредством целевой линии связи в сообщениях в единицах LRPDU, как обсуждается ниже. Следует отметить, что сообщения в единицах LRPDU могут всегда быть переданы по целевой линии связи с целью обеспечения того, что такие сообщения достигнут соответствующего портала.

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

Локальный портал может передать сообщение 407 записи в единицах LRPDU в базу данных регистратора, расположенную в соседнем узле, через соседний портал. Это сообщение 407 записи в единицах LRPDU указывает обновление записи, хранящейся в базе данных заявителя. В частности, сообщение 407 записи в единицах LRPDU содержит заголовки записей, относящиеся к записям в базе данных заявителя, обновленным посредством изменения 405 записи. Такие заголовки записей содержат номер записи и последовательный номер для каждой обновленной записи. В некоторых примерах, сообщение 407 записи в единицах LRPDU также содержит обновленные записи. В других примерах, обновленные записи передают от заявителя регистратору посредством отдельного сеанса связи и/или с использованием отдельного протокола связи, такого как протокол TCP и/или протокол LRP-DT. Следует отметить, что локальный портал может продолжать передавать дополнительные сообщения записей в единицах LRPDU по мере обновления записей, не дожидаясь получения квитирования.

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

Как отмечено выше, локальный портал может передать дальнейшие сообщения 407 записи в единицах LRPDU, не дожидаясь получения соответствующих сообщений 409 с парциальным списком в единицах LRPDU. Следовательно, различные обновления записей могут оставаться неподтвержденными (не квитированными), даже если были приняты конкретные сообщения 409 с парциальным списком в единицах LRPDU. Однако в некоторых случаях все сообщения 409 с парциальным списком в единицах LRPDU могут быть приняты для всех соответствующих сообщений 407 записи в единицах LRPDU, например, из-за паузы в обновлениях у заявителя. Когда это происходит, база данных заявителя и база данных регистратора оказываются синхронизированы. Локальный портал может проверять статус квитирования записей в базе данных заявителя каждый раз, когда будет принято сообщение 409 с парциальным списком в единицах LRPDU. Следовательно, когда базы данных синхронизированы, локальный портал может определить, что все обновленные записи в базе данных заявителя были подтверждены (квитированы) базой данных регистратора посредством сообщений в единицах LRPDU. На основе определения, что все обновленные записи в базе данных заявителя квитированы базой данных регистратора посредством сообщений в единицах LRPDU, локальный порт может передать квитанцию 411 для всех записей с целью уведомить приложение, что база данных заявителя синхронизирована с базой данных регистратора. Эта квитанция 411 для всех записей может представлять собой индикацию в форме заданного кода, переданного приложению для верификации синхронизации.

В качестве опции, локальный портал может быть конфигурирован для поддержания таймера ожидания для каждого сообщения 407 записи в единицах LRPDU. В таком случае, локальный портал может генерировать уведомление 412 о неуспехе для приложения, когда промежуток времени таймера ожидания для сообщения 407 записи в единицах LRPDU истечет, а соответствующее сообщение 409 с парциальным списком в единицах LRPDU получено не будет. Не подтвержденное (не квитированное) сообщение 407 записи в единицах LRPDU может не быть автоматически передано повторно локальным порталом. Соседний портал и/или соответствующий целевой порт может иметь буфер приема с ограниченным объемом. Автоматическая повторная передача может в результате привести к переполнению буфера из-за присутствия в нем других сообщений записей в единицах LRPDU 407. Соответственно, приложение может определить, как ему продолжать, например, передать повторно неподтвержденное сообщение 407 записи в единицах LRPDU, продолжить ожидание, «откатиться» назад к соответствующему обновлению записей в базе данных заявителя и т.п.

Соседний портал передает сообщения 413 с полным списком в единицах LRPDU от имени регистратора. Такие сообщения 413 с полным списком в единицах LRPDU содержат заголовки записей для всех записей в базе данных регистратора (но не сами записи). Сообщения 413 с полным списком в единицах LRPDU могут передаваться периодически и приниматься заявителем через локальный портал. Сообщение 413 с полным списком в единицах LRPDU может служить квитанцией для подтверждения одного или нескольких ранее переданных сообщений 407 записей в единицах LRPDU, например, если сообщение 409 с парциальным списком в единицах LRPDU не было принято локальным порталом/заявителем. Кроме того, сообщение 413 с полным списком в единицах LRPDU также может быть использовано заявителем для определения ситуации, когда сообщение 407 записи в единицах LRPDU не было принято регистратором. Например, заявитель может сравнить заголовки записей, входящие в сообщение 413 с полным списком в единицах LRPDU с заголовками записей в базе данных заявителя. Когда заголовки записей в базе данных заявителя согласуются с заголовками записей, входящими в сообщение 413 с полным списком в единицах LRPDU, заявитель может определить, что все обновления записей были приняты регистратором, и передать квитанцию 411 для всех записей. Если заголовки записей в базе данных заявителя не согласуются с заголовками записей, входящими в сообщение 413 с полным списком в единицах LRPDU, заявитель может определить, что определенные обновления записей не были приняты регистратором, и передать их повторно.

Способ 400 управляет также другими случаями. Например, может произойти прерывание 415 соединения. Такое прерывание 415 соединения может быть результатом выхода из строя узла или линии связи между целевыми портами для локального портала и соседнего портала. Прерывание 415 соединения может также возникать следствие перегрузки трафика данных. Обмен приветственными сообщениями в единицах LRPDU, такими как приветственные сообщения 401 и 403 в единицах LRPDU осуществляется периодически, так что порталы становятся осведомленными о прерывании 415 соединения, когда такой обмен не происходит. Когда обмен приветственными сообщениями не состоялся (неуспех), локальный портал генерирует код 416 разъединенности для приложения. Этот код 416 разъединенности указывает приложению, что обмен приветственными сообщениями в единицах LRPDU не состоялся, и что произошло прерывание 415 соединения. Заявитель тогда может определить действие, которое нужно осуществить в ответ на прерывание 415 соединения. Например, приложение может принять решение заново установить пару баз данных после восстановления соединения, в каком случае осуществление способа 400 запускается снова после обмена приветственными сообщениями 401 и 403 в единицах LRPDU.

В качестве другого примера, приложение может принять решение сохранить прежнюю пару баз данных и заново установить соединение. В случае успешности, этот подход избегает необходимости повторно передавать все записи из базы данных заявителя в базу данных регистратора. Приложение может передать команду 417 поддерживать базы данных локальному порталу. Следовательно, локальный портал может принять эту команду 417 поддерживать базы данных от приложения для поддержания базы данных заявителя в запоминающем устройстве в локальном узле, несмотря на код 416 разъединенности. Когда локальный портал примет команду поддерживать пару баз данных, этот локальный портал прекращает передачу сообщений 407 записей в единицах LRPDU до тех пор, пока сообщение 418 с полным списком в единицах LRPDU не будет принято от базы данных регистратора через соседний портал. Например, локальный портал может выполнить начальную установку (сброс) таймеров оповещения в базе данных заявителя после безуспешного (не состоявшегося) обмена приветственными сообщениями в единицах LRPDU (например, в случае прерывания 415 соединения) для предотвращения передачи сообщений записи в единицах LRPDU до тех пор, пока не будет принято сообщение 418 с полным списком в единицах LRPDU.

Соседний портал осуществляет аналогичную процедуру с использованием приложения в соседнем узле. После успешного обмена приветственными сообщениями в единицах LRPDU регистратор, через соседний портал, передает сообщение 418 с полным списком в единицах LRPDU. Это сообщение 418 с полным списком в единицах LRPDU по существу аналогично сообщению 413 с полным списком в единицах LRPDU, и, следовательно, содержит все заголовки записей для базы данных регистратора. Если приложение в каком-либо узле - в локальном узле или в удаленном узле, делает выбор заново установить пару баз данных, тогда выполнение способа 400 запускается снова. Например, если соседний портал выполняет начальную установку (сброс) базы данных регистратора, а локальный портал не производит начальной установки (сброса) базы данных заявителя, тогда сообщение 418 с полным списком в единицах LRPDU оказывается пустым, и заявитель повторно передает все записи. В качестве другого примера, если соседний портал не выполняет начальную установку (сброс) базы данных регистратора, а локальный портал производит начальную установку (сброс) базы данных заявителя, тогда сообщение 418 с полным списком в единицах LRPDU содержит заголовки записей, которые не согласуются с базой данных заявителя, и происходит начальная установка (сброс) пары баз данных. Однако если оба приложения выбирают поддержание пары баз данных, тогда сообщение 418 с полным списком в единицах LRPDU содержит заголовки записей, которые являются такими же или аналогичными (например, из-за потерянных сообщений 407 записей в единицах LRPDU) заголовкам записей в базе данных заявителя. В этом случае заявитель может определить необходимые этапы для возобновления синхронизации между базами данных пары.

Соответственно, локальный портал может принять сообщение 418 с полным списком в единицах LRPDU из базы данных регистратора, расположенной в соседнем узле, после успешного объема приветственными сообщениями. Сообщение 418 с полным списком в единицах LRPDU содержит заголовки записей для всех записей в базе данных регистратора. Локальный портал и/или база данных заявителя может тогда сравнить заголовки записей, входящих в сообщение 418 с полным списком в единицах LRPDU, с заголовками записей в базе данных заявителя с целью возобновления синхронизации базы данных заявителя с базой данных регистратора. В первом случае, локальный портал может определить, что нет рассогласования между заголовками записей в базе данных заявителя и заголовками записей из базы данных регистратора, как они входят в сообщение 418 с полным списком в единицах LRPDU. В таком случае пара баз данных оказывается синхронизированной. В таком случае, на основе определения, что рассогласований нет, портал может уведомить приложение, что база данных заявителя синхронизирована с базой данных регистратора, например, путем передачи квитанции 411 для всех записей. Во втором случае, локальный портал может определить рассогласование между одним или несколькими заголовками записей в базе данных заявителя и одним или несколькими заголовками записей, входящими в сообщение 418 с полным списком в единицах LRPDU. Это может произойти, если сообщение 407 записи в единицах LRPDU утрачено во время прерывания 415 соединения. Этот портал может сравнивать заголовки записей для определения, какие именно записи не были переданы в базу данных регистратора. Локальный портал тогда может передать сообщение 407 записи в единицах LRPDU в базу данных регистратора через соседний портал. Это сообщение 407 записи в единицах LRPDU содержит заголовки обновленных записей, как нужно для обработки рассогласования. В любом случае, пара баз данных становится синхронизированной без начальной установки (сброса) пары баз данных и повторной передачи всех записей базы данных заявителя.

В качестве опции, локальный портал может также запросить, от имени заявителя, сообщение 421 с полным списком в единицах LRPDU. Это позволяет заявителю проверить синхронизацию баз данных по требованию. В таком случае, локальный портал передает сообщение 419 с запросом получения полного списка в единицах LRPDU в базу данных регистратора через соседний портал. Соседний портал и/или регистратор принимает это сообщение 419 с запросом получения полного списка в единицах LRPDU и передает сообщение 421 с полным списком в единицах LRPDU заявителю через локальный портал. Это сообщение 421 с полным списком в единицах LRPDU по существу аналогично сообщениям 418 и 413 с полным списком в единицах LRPDU. Локальный портал, и, следовательно, заявитель, может затем принять сообщение 421 с полным списком в единицах LRPDU от базы данных регистратора в ответ на сообщение 419 с запросом получения полного списка в единицах LRPDU. В таком случае, заявитель может сравнить заголовки записей, входящих в сообщение 421 с полным списком в единицах LRPDU, с заголовками записей в базе данных заявителя, чтобы определить, синхронизирована ли пара баз данных, и/или определить, какие записи следует передать регистратору для синхронизации пары баз данных.

Следует отметить, что сообщения в единицах LRPDU и уведомления способа 400 иллюстрируются с целью описания разнообразных примеров функциональных возможностей настоящего изобретения. Такие сообщения/уведомления могут быть использованы в различных комбинациях. Например, обмен приветственными сообщениями 401 и 403 в единицах LRPDU, равно как сообщениями 413, 418 и 421 с полным списком в единицах LRPDU может происходить периодически на основе сигналов заданных таймеров, равно как на основе триггерных событий, как обсуждается выше. Далее, изменения 405 записи вместе с передаваемыми в результате таких изменений сообщениями 407 записей в единицах LRPDU и сообщениями 409 с парциальным списком в единицах LRPDU могут происходить многократно во время нормальной работы базы данных заявителя с вмешательством со стороны или без такого вмешательства. Кроме того, передачи квитанции 411 для всех записей, уведомления 412 о неуспехе, кода 416 разъединенности и команды 417 поддерживать базы данных могут быть запущены, когда возникают соответствующие обстоятельства. В такой ситуации, порядок сообщений в единицах LRPDU и уведомлений, показанный на Фиг. 4, является всего лишь примером, и его не следует считать ограничивающим, если не указано иное.

Кроме того, любое число единиц LRPDU могут быть соединены последовательно в одной единице данных протокола LRP-DT в системе с протоколом управления Edge (Edge Control Protocol Data Unit (ECPDU)), вплоть до максимального размера двух уровней в кадре. Одна единица LRPDU может не быть разделена по нескольким единицам LRP-DT ECP ECPDU. При использовании протокола TCP, размер единицы LRPDU может быть ограничено полем длиной шестнадцать бит.

Фиг. 5 иллюстрирует пример кодирования приветственного сообщения 500 в единицах LRPDU, который может реализовать приветственное сообщение 401 и/или 403 в единицах LRPDU. В такой ситуации приветственное сообщение 500 в единицах LRPDU может быть использовано для поддержания синхронизации пары баз данных в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250 и/или в системе 300 баз данных.

Приветственное сообщение 500 в единицах LRPDU кодировано в формате TLV. Например, формат TLV, используемый здесь, может поддерживать поля данных размером до шестидесяти пяти тысяч пятисот тридцати пяти октетов. Приветственное сообщение 500 в единицах LRPDU содержит поле «Тип» (Type) 501 типа. Это поле «Тип» 501 имеет длину в один октет и сдвиг нуль октетов. Полю «Тип» 501 может быть присвоено значение единицы для индикации приветственного сообщения 500 в единицах LRPDU. Приветственное сообщение 500 в единицах LRPDU также содержит поле «Длина» (Length) 503. Это поле «Длина» 503 имеет длину в два октета и сдвиг в один октет. Поле «Длина» 503 может содержать целое число размеров два октета, с самыми старшими восемью битами в первом октете (сдвиг 1), содержащими длину поля данных (например, остальной части сообщения). Таким образом, когда в поле «Длина» 503 в формате TLV записан нуль, это означает, что поле данных отсутствует. Поле «Длина» 503 в приветственном сообщении 500 в единицах LRPDU, (октеты один и два после поля типа) содержит указание длины всех полей фиксированной длины плюс всех величин TLV в поле данных.

Остальные данные имеют длину от нуля до шестидесяти пяти тысяч пятисот тридцати пяти октетов со сдвигом в три октета для первого поля данных. Поле данных приветственного сообщения 500 в единицах LRPDU содержит информацию, передаваемую одним экземпляром конечного автомата передачи приветствия у заявителя, у регистратора и/или у соответствующего портала. Это приветственное сообщение 500 в единицах LRPDU содержит несколько полей фиксированного размера, за которыми следует ряд величин TLV в пределах поля данных. Иными словами, десятый октет после поля «Длина» 503 в формате TLV может быть полем типа другой единицы LRPDU.

Приветственное сообщение 500 в единицах LRPDU также содержит поле «идентификатор AppId» 505. Это поле 505 содержит идентификатор AppId, обозначающий приложение, ассоциированное с передающим порталом. Поле идентификатора AppId содержит идентификатор, уникальный в пределах организации, (Organizationally Unique Identifier (OUI)) или идентификатор компании (Company Identifier (CID)) длиной в три октета и частичный идентификатор приложения (Application Sub-ID) длиной в один октет и со сдвигом в три октета из общего числа четыре октета. Следует отметить, что владелец идентификатора OUI или CID несет ответственность за управление использованием идентификатора Application Sub-ID. Следует также отметить, что идентификатор AppId используется в целом ряде контекстов, включая переменные конечных автоматов, а не только в приветственном сообщении 500 в единицах LRPDU.

Приветственное сообщение 500 в единицах LRPDU также содержит поле «Статус приветствия» 507 (Hello Status). Это поле «Статус приветствия» 507 представляет собой четырехбитовое номерное поле, расположенное в старших битах октета и содержащее одну из следующих величин: статус приветствия - обзор (hello status looking (hsLooking)), статус приветствия - соединение (hello status connecting (hsConnecting)) и статус приветствия - соединенный (hello status connected (hsConnected)). Величина hsLooking может быть установлена для индикации того, что соответствующий портал еще не принял успешный запрос на создание полного портала. Величина hsConnecting может быть установлена для индикации того, что соответствующий портал принял успешный запрос на создание полного портала и приветственное сообщение 500 в единицах LRPDU 500 со статусом hsLooking. В этом случае портал готов к приему всех единиц LRPDU. Величина hsConnected может быть установлена для индикации, что соответствующий портал «открыт» (включен) и готов к передаче данных приложения. В этом случае порталу разрешено передать все единицы LRPDU. Поле «Статус приветствия» 507 может также содержать поле «Статус ошибки» 508 (Error Status). Это поле «Статус ошибки» 508 может содержать четыре бита информации, расположенные в младших битах октета, и может указывать ошибки, такие как переполнение базы данных.

Приветственное сообщение 500 в единицах LRPDU также содержит поле «Номер моего портала» 509 (My Portal Number) Это поле «Номер моего портала» 509 содержит четырехоктетный номер, идентифицирующий передающий портал. Идентифицирующий номер является уникальным по всем порталам, совместно использующим один и тот же экземпляр протокола LRP-DT. Это поле имеет длину в четыре октета, поскольку прокси-система может осуществлять доверенные (прокси) функции для любого числа ведомых систем, каждая из которых содержит большое число целевых портов. Далее, прокси-система может создать соединение протокола TCP с другой, аналогичной прокси-системой. Каждая прокси-система использует одну величину параметра «Номер моего портала» для каждого целевого порта, для которого эта прокси-система является доверенным представителем. Поле «Номер моего портала» 509 используется в других сообщениях в единицах LRPDU для идентификации того, с какой парой целевых портов 141, 151, 241 и 251 и, таким образом, с каким порталом 113, 133, 213 и 233, и в конечном итоге, с какой базой 120, 122, 220 и 222 данных, ассоциирована какая-либо конкретная единица LRPDU записи, единица LRPDU частичного списка, единица LRPDU полного списка или единица LRPDU запроса полного списка.

Приветственное сообщение 500 в единицах LRPDU также содержит поле «Время приветствия» 511 (Hello Time). Это поле «Время приветствия» 511 содержит два октета, представляющих «время жизни» приветственного сообщения в единицах LRPDU. Первый октет поля «Время приветствия» 511 представляет собой самый старший октет шестнадцати-битового числа секунд (от нуля до шестидесяти пяти тысяч пятисот тридцати пяти или от тридцати до шестидесяти пяти тысяч пятисот тридцати пяти), в течение которых приветственное сообщение 500 в единицах LRPDU. Это поле может не быть передано с величиной между единицей и двадцатью девятью включительно.

Совокупность первых четырех величин TLV в приветственном сообщении500 в единицах LRPDU содержит по одному идентификатору каждого типа из группы идентификаторов «Мое шасси» ID TLV 513, «Мой порт» ID TLV 515, «Соседнее шасси» ID TLV 517 и «Соседний порт» ID TLV 519, в любом порядке. После этого следует либо нуль, либо одна из величин TLV «Информация о приложении» (Application Information) 521.

Поле типа для идентификатора «Мое шасси» ID TLV 513 устанавливают равным величине typeMyChassisId. Поле данных для этого идентификатора «Мое шасси» ID TLV 513 содержит величину, специфицированную для передачи идентификатора шасси по протоколу LLDP Chassis ID TLV с использованием экземпляра протокола LLDP, названного в запросе создания полного портала, создавшего портал, передающий идентификатор «Мое шасси» ID TLV 513. В частности, идентификатор «Мое шасси» ID TLV 513 содержит величину, идентифицирующую локальный узел (например, машину), действующий в качестве передатчика для приветственного сообщения 500 в единицах LRPDU. Такой локальный узел содержит собственную систему или ведомую систему, используемую для установления и/или поддержания пары баз данных (например, содержащей или связанной с локальным регистратором, локальным заявителем или с обоими).

Поле типа для идентификатора «Мой порт» ID TLV 515 устанавливают равным величине typeMyPortId. Поле данных для этого идентификатора «Мой порт» ID TLV 515 содержит такую же величину, какая была специфицирована для передачи идентификатора порта по протоколу LLDP Port ID TLV с использованием экземпляра протокола LLDP, названного в запросе создания полного портала, создавшего портал, передающий идентификатор «Мой порт» ID TLV 515. В частности, идентификатор «Мой порт» ID TLV 515 содержит величину, идентифицирующую целевой порт в локальном узле, пытающемся установить и/или поддерживать пару баз данных (например, в собственной системе или в ведомой системе). Идентификатор ID шасси и идентификатор ID порта совместно однозначно представляют локальную половину целевой линии связи для передачи сообщений в единицах LRPDU.

Поле типа для идентификатора «Соседнее шасси» ID TLV 517 устанавливают равным величине typeNeighborChassisId. Поле данных для этого идентификатора «Соседнее шасси» ID TLV 517 имеет такой же формат, как поле данных для идентификатора «Мое шасси» ID TLV 513, и содержит идентификатор ID шасси для соседнего портала, с которым ассоциирован локальный портал. В частности, идентификатор «Соседнее шасси» ID TLV 517 содержит величину, идентифицирующую соседний узел (например, машину), действующий в качестве адресата приветственного сообщения 500 в единицах LRPDU. Такой соседний узел содержит собственную систему или ведомую систему, используемую для установления и/или поддержания пары баз данных (например, содержащей или связанной с соседним регистратором, соседним заявителем или с обоими).

Поле типа для идентификатора «Соседний порт» ID TLV 519 устанавливают равным величине typeNeighborPortId. Поле данных для этого идентификатора «Соседний порт» ID TLV 519 имеет такой же формат, как поле данных для идентификатора «Мой порт» ID TLV 515, и содержит идентификатор ID порта соседнего портала, с которым ассоциирован указанный локальный портал. В частности, идентификатор «Соседний порт» ID TLV 519 содержит величину, идентифицирующую целевой порт в сетевом узле, используемый для установления и/или поддержания пары баз данных (например, в собственной системе или в ведомой системе). Идентификаторы «Соседнее шасси» ID и «Соседний порт» ID совместно однозначно представляют соседнюю половину целевой линии связи для передачи сообщений в единицах LRPDU. Следовательно, приветственное сообщение 500 в единицах LRPDU представляет целевую линию связи в виде совокупности идентификатора «Мое шасси» ID, идентифицирующего локальный узел, идентификатора «Мой порт» ID, идентифицирующего целевой порт в локальном узле, идентификатора «Соседнее шасси» ID, идентифицирующего соседний узел, и идентификатора «Соседний порт» ID, идентифицирующего целевой порт в соседнем узле.

Параметр «Информация о приложении» (Application Information) TLV 521 устанавливают равным величине typeAppInfo. Поле данных для «Информации о приложении» TLV 521 содержит информацию, поступающую из запроса создания активного портала. Эти данные представляют приложению у адресата посредством индикации статуса портала на обращенном к адресату конце соединения протокола LRP-DT. Эти данные могут быть непрозрачными и неинтерпретируемыми протоколом LRP. «Информация о приложении» TLV 521 является опцией.

Соответственно, поле «Тип» 501 составляет один октет со сдвигом нуль октетов, поле «Длина» 503 составляет два октета со сдвигом на один октет, поле идентификатора AppId 505 составляет четыре октета со сдвигом на три октета, поле «Статус приветствия» 507 составляет один октет со сдвигом на семь октетов, поле «Номер моего портала» 509 составляет четыре октета со сдвигом на восемь октетов, поле «Время приветствия» 511 составляет два октета со сдвигом на двенадцать октетов и остальные поля TLV 513-521 имеют переменные длины со стартовым сдвигом в четырнадцать октетов.

Фиг. 6 иллюстрирует пример кодирования сообщения 600 записи в единицах LRPDU, которое может реализовать сообщение 407 записи в единицах LRPDU. В такой ситуации сообщение 600 записи в единицах LRPDU может быть использовано для поддержания синхронизации пары баз данных в собственной системе 110 и/или 130, прокси-системе 210 и/или 230, ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Сообщение 600 записи в единицах LRPDU содержит поле «Тип» 601 и поле «Длина» 603, аналогичные полям «Тип» 501 и «Длина» 503, соответственно. Поле «Тип» 601 может содержать величину два для указания сообщения 600 записи в единицах LRPDU (например, typeRecordLRPDU), и поле «Длина» 603 содержит указание длины сообщения 600 записи в единицах LRPDU. Первые два октета в поле данных в сообщении записи в единицах LRPDU представляют собой поле «Номер моего портала» 609 и кодируют идентификатор ID шасси, идентификатор ID порта и идентификатор appId для передающего портала. Поле имеет такую же величину, как соответствующее поле, переданное в приветственном сообщении 500 в единицах LRPDU для того же самого портала. После этого следуют нуль (ни одной) или несколько записей в поле «Запись» (Record) 630.

Каждая запись содержит поле «Номер записи» (Record Number) 631, поле «Последовательный номер» (Sequence number) 633, поле «Контрольная сумма» (Checksum) 635 и, в качестве опции, поле «Длина данных» (Data Length) 637 и поле «Данные приложения» (Application Data) 639. Поле «Номер записи» 631 содержит данные, указывающие запись в базе данных заявителя, которая была обновлена. Поле «Последовательный номер» 633 содержит данные, указывающие номер версии и/или число изменений, ассоциированных с соответствующей записью. Поле «Контрольная сумма» 635 содержит данные для коррекции ошибок, такие как двух-октетная величина, вычисленная на основе значений, входящих в соответствующую запись (например, значений в поле «Номер записи» 631, в поле «Последовательный номер» 633, в поле «Длина данных» 637 и/или в поле «Длина приложения» 639). Поле «Длина данных» 637, когда оно присутствует, обозначает длину данных в соответствующей записи и/или длину поля «Данные приложения» 639. Поле «Длина приложения» 639, когда оно присутствует, содержит обновленную запись при передаче из базы данных заявителя в базу данных регистратора.

Соответственно, сообщение 600 записи в единицах LRPDU может содержать один или несколько номеров записей, обозначающих обновленные записи в базе данных заявителя, и один или несколько последовательных номеров, идентифицирующих обновления, входящих в обновленные записи в базе данных заявителя. Далее, поле «Тип» 601 занимает один октет со сдвигом в нуль октетов, поле «Длина» 603 занимает два октета со сдвигом в один октет, поле «Номер моего портала» 609 занимает четыре октета со сдвигом в три октета, и поле «Запись» 630 имеет переменную длину со сдвигом в семь октетов. Кроме того, каждая запись содержит поле «Номер записи» 631 из четырех октетов со сдвигом в нуль октетов, поле «Последовательный номер» 633 из четырех октетов со сдвигом в четыре октета, поле «Контрольная сумма» 635 из двух октетов со сдвигом в восемь октетов, поле «Длина данных» 637 из двух октетов со сдвигом в десять октетов и поле «Данные приложения» 639 размером от нуля до шестидесяти пяти тысяч пятисот тридцати пяти или от тридцати до шестидесяти пяти тысяч пятисот двадцати октетов и со сдвигом в двенадцать октетов, где сдвиги в записи измеряют от начала записи.

Фиг. 7 иллюстрирует пример кодирования сообщения 700 с парциальным списком в единицах LRPDU, которое может реализовать сообщение 409 с парциальным списком в единицах LRPDU. В таком случае, сообщение 700 с парциальным списком в единицах LRPDU может быть использовано для поддержания синхронизации пары баз данных в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Сообщение 700 с парциальным списком в единицах LRPDU содержит поле «Тип» 701 и поле «Длина» 703, которые аналогичны полю «Тип» 501 и полю «Длина» 503, соответственно. Поле «Тип» 701 может содержать величину три для индикации сообщения 700 с парциальным списком в единицах LRPDU (например, typePartialListLRPDU), и поле «Длина» 703 содержит длину сообщения 700 с парциальным списком в единицах LRPDU.

Первые два октета в поля данных сообщения 700 с парциальным списком в единицах LRPDU составляют поле «Номер моего портала» 709, которое кодирует идентификатор ID шасси, идентификатор ID порта и идентификатор appId приложения для передающего портала. Это такая же величина, как величина, передаваемая в приветственном сообщении 500 в единицах LRPDU для того же самого портала. После этого присутствуют нуль или более полей «Заголовок записи» (Record header) 730, которые по существу аналогичны полям «Запись» 630, но не содержат данных записей. В частности, каждое поле «Заголовок записи» 730 содержит поле «Номер записи» 731, поле «Последовательный номер» 733 и поле «Контрольная сумма» 735, которые по существу аналогичны полю «Номер записи» 631, полю «Последовательный номер» 633 и полю «Контрольная сумма» 635, соответственно. Далее, поле «Номер записи» 731 и поле «Последовательный номер» 733 содержат величины, добавленные регистратором, осуществляющим согласование величин соответствующих поле «Запись» 630 в сообщении 600 записи в единицах LRPDU 600 (например, как это включил в сообщение 600 записи в единицах LRPDU заявитель). Следовательно, поля «Заголовок записи» 730 квитируют прием полей «Запись» 630.

Следовательно, сообщение 700 с парциальным списком в единицах LRPDU квитирует сообщение 600 записи в единицах LRPDU, и это сообщение 700 с парциальным списком в единицах LRPDU содержит по меньшей мере одно поле «Заголовок записи» 730, квитирующее по меньшей мере одну обновленную запись 630. Далее поле «Заголовок записи» 730 содержит номер записи в поле «Номер записи» 731, указывающий обновленную запись (например, в поле «Запись» 630) и последовательный номер в поле «Последовательный номер» 733, идентифицирующий обновление, входящее в обновленную запись (например, в поле «Запись» 630).

Фиг. 8 иллюстрирует пример кодирования сообщения 800 с полным списком в единицах LRPDU, которое может реализовать сообщение 413, 418 и/или 421 с полным списком в единицах LRPDU. В таком случае, сообщение 800 с полным списком в единицах LRPDU может быть использовано для поддержания синхронизации пары баз данных в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Сообщение 800 с полным списком в единицах LRPDU содержит поле «Тип» 801 и поле «Длина» 803, которые аналогичны полю «Тип» 501 и полю «Длина» 503, соответственно. Поле «Тип» 801 может содержать величину четыре для индикации сообщения 800 с полным списком в единицах LRPDU (например, typeCompleteListLRPDU), и поле «Длина» 803 содержит указание длины сообщения 800 с полным списком в единицах LRPDU.

Первые два октета в поле данных сообщения 800 с полным списком в единицах LRPDU представляют собой поле «Номер моего портала» 809, которое кодирует идентификатор ID шасси, идентификатор ID порта и идентификатор appId приложения для передающего портала. Это такая же величина, как величина, передаваемая в приветственном сообщении 500 в единицах LRPDU для того же самого портала. После этого следует поле «Номер первой записи» 823 и поле «Номер последней записи» 825, каждое из которых имеет длину четыре октета, и эти поля содержат наименьший номер записи и наибольший номер записи, соответственно, охватываемые рассматриваемым сообщением 800 с полным списком в единицах LRPDU. Например, поле «Номер первой записи» 823 и поле «Номер последней записи» 825 содержат номер первой записи и номер последней записи, сохраняемых регистратором.

За этим следуют нуль или более полей «Заголовок записи» 830, которые по существу аналогичны полям «Заголовок записи» 730. Однако поля «Заголовок записи» 830 содержат заголовки всех записей, присутствующих в базе данных регистратора, в противоположность случаю, когда участвуют только заголовки записей для квитированных обновленных записей. Каждое поле «Заголовок записи» 830 содержит поле «Номер записи» 8731, поле «Последовательный номер» 833 и поле «Контрольная сумма» 835, которые по существу аналогичны полю «Номер записи» 731, полю «Последовательный номер» 733 и полю «Контрольная сумма» 735, соответственно.

Каждое поле «Номер записи» 831, передаваемое в сообщении 800 с полным списком в единицах LRPDU, содержит величину, которая не меньше величины в поле «Номер первой записи» 823 и не больше величины в поле «Номер последней записи» 825. Поле «Номер первой записи» 823 и поле «Номер последней записи» 825 позволяют полный список записей, известных регистратору, разбить между более чем одним сообщением 800 с полным списком в единицах LRPDU. Пары из первого и последнего номеров записей во всех сообщениях 800 с полным списком в единицах LRPDU содержат полный список записей, который может охватывать все возможные номера записей от нуля до четырех миллиардов двухсот девяноста четырех миллионов девятисот шестидесяти семи тысяч двухсот девяносто пяти.

Фиг. 9 представляет логическую схему примера способа 900 для установления пары баз данных, например, в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Способ 900 использует сигнализацию из способа 400, такую как приветственные сообщения 401, 403 и/или 500 в единицах LRPDU. Способ 900 обсуждается с точки зрения локального узла, оперирующего базой данных заявителя, для ясности обсуждения, но может также осуществляться целиком или частично в узле, оперирующем регистратором (например, в локальном узле или в соседнем узле).

Осуществление способа 900 начинается, когда локальный узел желает установить пару баз данных для синхронизации с соседним узлом. В блоке 901 локальный узел принимает приветственное сообщение. Это приветственное сообщение содержит идентификатор AppId и указание целевой линии связи между целевым портом для локального узла и целевым портом для соседнего узла. Когда локальный узел является собственной системой, целевой порт расположен в локальном узле. Когда локальный узел является прокси-системой, целевой порт расположен в ведомой системе. Приветственное сообщение может представлять собой приветственное сообщение в единицах LRPDU, такое как приветственное сообщение 401, 403 и/или 500 в единицах LRPDU. Далее, приветственное сообщение в единицах LRPDU может представлять целевую линию связи посредством идентификатора «Мое шасси» ID, идентифицирующего локальный узел или соответствующий ведомый узел, идентификатора «Мой порт» ID, идентифицирующего целевой порт в локальном узле или в соответствующем ведомом узле, идентификатора «Соседнее шасси» ID, идентифицирующего соседний узел или соответствующий ведомый узел, и идентификатора «Соседний порт» ID, идентифицирующего целевой порт в соседнем узле или в соответствующем ведомом узле. Для завершения приветственного обмена, соответствующее приветственное сообщение также передают от локального узла соседнему узлу. Такое приветственное сообщение может быть по существу аналогичным приветственному сообщению, принятому локальным узлом с другим «Номером моего портала». Например, приветственное сообщение, переданное из локального узла, содержит поле «Номер моего портала», ассоциированное с локальным узлом, а приветственное сообщение, принятое в локальном узле, содержит поле «Номер моего портала», ассоциированное с соседним узлом. Такие сообщения могут быть переданы в любом порядке.

В блоке 903, локальный узел и/или соответствующий портал определяет, что идентификатор AppId ассоциирован с приложением для осуществления синхронизации баз данных. На основе такого определения, что идентификатор AppId ассоциирован с синхронизацией баз данных, устанавливают локальную базу данных в запоминающем устройстве в локальном узле в блоке 905. Эта локальная база данных представляет собой часть пары баз данных для использования указанным приложением. Рассматриваемая пара баз данных содержит соседнюю базу данных, установленную в соседнем узле (например, посредством портала в соседнем узле). В некоторых примерах, локальная база данных может представлять собой базу данных заявителя для сохранения локальных записей с целью передачи в базу данных регистратора в соседней базе данных. В некоторых примерах, локальная база данных содержит базу данных регистратора для приема соседних записей из базы данных заявителя, находящейся в соседней базе данных. В некоторых примерах, локальная база данных содержит и базу данных заявителя, и базу данных регистратора.

В блоке 907, пару баз данных ассоциируют с целевой линией связи (например, в собственной системе и/или от ведомой системы к прокси-системе). Такое ассоциирование обеспечивают, чтобы сообщения в единицах LRPDU, направленные заявителю/регистратору, достигли правильного портала, либо потому, что портал находится в локальном узле с целевым портом, либо потому, что целевой порт находится в ведомой системе, конфигурированной для пересылки таких сообщений в прокси-систему, содержащую указанный портал и работающую в локальном узле.

В блоке 909, локальный узел/портал начинать управлять синхронизацией локальной базы данных с соседней базой данных посредством целевой линии связи. Такое управление может осуществляться путем передачи информации записей в соседнюю базу данных по целевой линии связи в сообщениях в единицах LRPDU. Такая информация записей может содержать записи, заголовки записей или комбинацию записей и заголовков. Например, такие сообщения в единицах LRPDU могут представлять собой другие приветственные сообщения 500 в единицах LRPDU, сообщения 600 записи в единицах LRPDU, сообщения 700 с парциальным списком в единицах LRPDU, сообщения 800 с полным списком в единицах LRPDU и/или какие-либо сообщения в единицах LRPDU из способа 400.

На Фиг. 10 представлена логическая схема примера способа 1000 управления синхронизацией пары баз данных, например, после завершения выполнения способа 900. Способ 1000 может быть реализован в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Способ 1000 использует сигнализацию из способа 400. Далее, способ 1000 может использовать сообщения в единицах LRPDU, такие как приветственные сообщения 500 в единицах LRPDU, сообщения 600 записи в единицах LRPDU, сообщения 700 с парциальным списком в единицах LRPDU, сообщения 800 с полным списком в единицах LRPDU и/или комбинации таких сообщений. Способ 1000 обсуждается с точки зрения локального узла, оперирующего базой данных заявителя, для ясности обсуждения, но может также работать полностью или частично в узле, оперирующем регистратором (например, в локальном узле или в соседнем узле).

В блоке 1001, приложение заменяет одну или несколько записей в базе данных заявителя. Соответственно, портал в локальном узле передает одно или несколько сообщений записи в единицах LRPDU в базу данных регистратора, расположенную в соседнем узле, например, через соседний портал. Сообщения записей в единицах LRPDU указывают обновления для записей, хранящихся в базе данных заявителя, расположенной в локальном узле, и могут также содержать такие обновленные записи. Например, сообщения записей в единицах LRPDU могут содержать один или несколько номеров записей, указывающих обновленные записи в базе данных заявителя, и один или несколько последовательных номеров, идентифицирующих обновления в обновленных записях в базе данных заявителя. Обновленные записи могут также быть маркированы как неподтвержденные (не квитированные) в базе данных заявителя.

В блоке 1003, портал принимает одно или несколько сообщений в единицах LRPDU, квитирующих сообщения записей в единицах LRPDU из блока 1001. В некоторых примерах, совокупность сообщений в единицах LRPDU, квитирующих сообщения записей в единицах LRPDU, содержит сообщение с парциальным списком в единицах LRPDU. Это сообщение с парциальным списком в единицах LRPDU содержит по меньшей один заголовок записи, квитирующий по меньшей мере одну обновленную запись из блока 1001. Этот по меньшей мере один заголовок записи содержит номер записи, указывающий обновленную запись (и) из блока 1001, и последовательный номер, идентифицирующий обновление (я), входящее в обновленную запись из блока 1001. В некоторых примерах, совокупность сообщений в единицах LRPDU, квитирующих сообщения записи в единицах LRPDU, может содержать сообщение с полным списком в единицах LRPDU. Это сообщение с полным списком в единицах LRPDU содержит заголовки записей относительно всех записей, хранящихся в базе данных регистратора. Далее, это сообщение с полным списком в единицах LRPDU содержит поле с номером первой записи, обозначающее первую запись, хранящуюся в базе данных регистратора, и поле с номером последней записи, обозначающее последнюю запись, хранящуюся в базе данных регистратора. Кроме того, заголовки записей содержат номера записей, обозначающих записи, хранящиеся в базе данных регистратора, и последовательные номера, идентифицирующие обновления, входящие в записи, хранящиеся в базе данных регистратора.

В блоке 1005, по меньшей мере одну обновленную запись маркируют в базе данных заявителя как квитированную базой данных регистратора на основе заголовков записей, входящих в сообщение (я) с парциальным списком и/или с полным списком в единицах LRPDU из блока 1003.

В блоке 1007, портал/заявитель может определить все обновленные записи в базе данных заявителя, квитированные базой данных регистратора посредством сообщений в единицах LRPDU. На основе определения в блоке 1007, что все обновленные записи в базе данных заявителя квитированы базой данных регистратора посредством сообщений в единицах LRPDU, портал/заявитель уведомляет приложение, что база данных заявителя синхронизирована с базой данных регистратора, в блоке 1009.

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

Блок 1013 также является опцией. В некоторых примерах, этот портал/заявитель может быть конфигурирован для передачи в базу данных регистратора сообщения с запросом получения полного списка в единицах LRPDU. Регистратор/соседний портал отвечает посредством сообщения с полным списком в единицах LRPDU. По этой причине, портал/заявитель в локальном узле принимает сообщение с полным списком в единицах LRPDU от базы данных регистратора в ответ на сообщение с запросом получения полного списка в единицах LRPDU.

На Фиг. 11 представлена логическая схема примера способа 1100 поддержания синхронизации баз данных, несмотря на прерывание соединения, например, после осуществления способа 900 и во время/после осуществления способа 1000. Способ 1100 может быть осуществлен в собственной системе 110 и/или 130, в прокси-системе 210 и/или 230, в ведомой системе 240 и/или 250, и/или в системе 300 баз данных. Способ 1100 использует сигнализацию из способа 400. Далее, способ 1100 может использовать сообщения в единицах LRPDU, такие как приветственные сообщения 500 в единицах LRPDU, сообщения 600 записей в единицах LRPDU, сообщения 700 с парциальным списком в единицах LRPDU, сообщения 800 с полным списком в единицах LRPDU и/или комбинации таких сообщений. Способ 1100 обсуждается с точки зрения локального узла, оперирующего базой данных заявителя, для ясности обсуждения, но может также быть осуществлен в целом или частично в узле, оперирующем регистратором (например, в локальном узле или в соседнем узле).

Осуществление способа 1100 начинается, когда обмен приветственными сообщениями в единицах LRPDU оказывается неуспешным (не состоялся), что указывает на прерывание соединения. В блоке 1101, генерируют код разъединенности для приложения. Этот код разъединенности указывает, что обмен приветственными сообщениями в единицах LRPDU оказывался неуспешным (не состоялся). Это также указывает, что дополнительные сообщения в адрес соседнего узла/регистратора вероятно приняты не будут, и что ранее не подтвержденные (не квитированные) сообщения могут не достигнуть регистратора.

Заявитель может определить, что нужно выполнить возврат в начальное положение (сброс) пары баз данных после повторного установления соединения. В таком случае используется способ 900. Однако заявитель может также определить, что нужно заново синхронизировать текущую базу данных заявителя с базой данных регистратора, когда будет вновь установлено соединение. В таком случае, в блоке 1103 портал принимает команду от приложения для поддержания базы данных заявителя в запоминающем устройстве, расположенном в локальном узле, несмотря на код разъединенности.

В блоке 1105, портал выполняет начальную установку (сброс) таймеров оповещения в базе данных заявителя после безуспешного обмена приветственными сообщениями. Это предотвращает передачу сообщения записи в единицах LRPDU до тех пор, пока не будет принято сообщение с полным списком в единицах LRPDU после повторного установления соединения.

Приветственные сообщения в единицах LRPDU могут передаваться периодически в попытках повторного установления соединения. Когда база данных регистратора после разъединения примет приветственное сообщение в единицах LRPDU, регистратор отвечает сообщением с полным списком в единицах LRPDU. Соответственно, в блоке 1107, заявитель/портал после успешного обмена приветственными сообщениями в единицах LRPDU принимает сообщение с полным списком в единицах LRPDU из базы данных регистратора, расположенной в соседнем узле. Это сообщение с полным списком в единицах LRPDU содержит заголовки записей для всех записей, находящихся в базе данных регистратора.

В блоке 1109, портал/заявитель сравнивает заголовки записей из сообщения с полным списком в единицах LRPDU с заголовками записей, хранящимися в базе данных заявителя, для восстановления синхронизации базы данных заявителя с базой данных регистратора. В частности, в блоке 1111 портал/заявитель определяет, имеет ли место рассогласование записей между заголовками записей, входящих в сообщения с полным списком в единицах LRPDU, и заголовками записей в базе данных заявителя.

Когда портал/заявитель определит рассогласование между одним или несколькими заголовками записей в базе данных заявителя и одним или несколькими заголовками записей из сообщения с полным списком в единицах LRPDU, способ 1100 переходит к блоку 1113. Рассогласование указывает, что по меньшей мере одно предшествующее сообщение записи в единицах LRPDU было утрачено. Следовательно, заявитель определяет, какие обновления записей не представлены в сообщении с полным списком в единицах LRPDU. В блоке 1113, заявитель/портал передает одно или несколько сообщений записи в единицах LRPDU в адрес базы данных регистратора. Эти сообщения записи в единицах LRPDU содержат заголовки обновленных записей, что нужно для рассмотрения рассогласования и синхронизации пары баз данных.

Когда портал/заявитель определит, что нет рассогласования между заголовками записей в базе данных заявителя и заголовками записей в базе данных регистратора, способ 1100 переходит к блоку 1115. На основе такого определения, что рассогласования нет, в блоке 1115 портал/заявитель может уведомить приложение, что база данных заявителя синхронизирована с базой данных регистратора.

На Фиг. 12 представлена упрощенная схема примера узла 1200 сети связи для управления синхронизацией баз данных в соответствии с одним из вариантов настоящего изобретения. Этот узел 1200 сети связи является подходящим для реализации рассмотренных примеров/вариантов, как описывается здесь. Например, узел 1200 сети связи может быть использован для осуществления собственной системы 110/130, прокси-системой 210/230, ведомой системы 240/250, комбинаций таких систем, и/или какого-либо локального узла и/или соседнего узла, описываемых здесь. Например, такой узел 1200 сети связи может осуществлять систему 300 базу данных.

Узел 1200 сети связи содержит порты 1220 нисходящей линии, порты 1250 восходящей линии и/или приемопередающие модули (Tx/Rx) 1210, имеющие передатчики и/или приемники для передачи данных в восходящем направлении и/или в нисходящем направлении по сети связи. Узел 1200 сети связи содержит также процессор 1230, имеющий логический модуль и/или центральный процессор (central processing unit (CPU)) для обработки данных, и запоминающее устройство 1232 для сохранения данных. Узел 1200 сети связи может также содержать опто-электрические (optical-to-electrical (OE)) компоненты, электрооптические компоненты (electrical-to-optical (EO)) и/или компоненты радиосвязи, соединенные с портами 1250 восходящей линии и/или портами 1220 нисходящей линии для передачи данных по оптическим или радио сетям связи. Узел 1200 сети связи может также содержать устройства ввода и/или вывода (I/O) для передачи данных к пользователю и от него. К устройствам ввода/вывода (I/O) могут относиться устройства вывода, такие как дисплей для представления видеоданных, громкоговорители для вывода аудиоданных и т.д. К устройствам ввода/вывода (I/O) могут также относиться устройства ввода, такие как клавиатура, мышь, трекбол и т.д., и/или соответствующие интерфейсы для сопряжения с такими устройствами вывода.

Процессор 1230 реализован посредством аппаратуры и программного обеспечения. Этот процессор 1230 может быть реализован в виде одного или нескольких кристаллов процессоров CPU, ядер (например, как в многоядерном процессоре), программируемых пользователем вентильных матриц (field-programmable gate array (FPGA)), специализированных интегральных схем (application specific integrated circuit (ASIC)) и цифровых процессоров сигнала (digital signal processor (DSP)). Процессор 1230 имеет связь с портами 1220 нисходящей линии, модулями Tx/Rx 1210, портами 1250 восходящей линии и запоминающим устройством 1232. Этот процессор 1230 содержит модуль 1214 протокола LRP-DS. Такой модуль 1214 протокола LRP-DS реализует описываемые здесь варианты изобретения, такие как способы 400, 900, 1000, 1100 и/или какой-либо другой способ/механизм, описываемый здесь. Далее, модуль 1214 протокола LRP-DS может передавать, принимать и/или обрабатывать сообщения в единицах LLPDU, такие как приветственные сообщения 500 в единицах LRPDU, сообщения 600 записей в единицах LRPDU, сообщения 700 с парциальным списком в единицах LRPDU, сообщения 800 с полным списком в единицах LRPDU и/или комбинации таких сообщений. Например, модуль 1214 протокола LRP-DS может быть использован для установления соединения с применением приветственных сообщений в единицах LRPDU и установления пары баз данных для синхронизации. В качестве другого примера модуль 1214 протокола LRP-DS может быть использован для уведомления приложения, когда все записи у заявителя будут квитированы регистратором и/или для уведомления приложения, когда регистратор не сможет квитировать какое-либо обновление записи. В качестве еще одного примера, модуль 1214 протокола LRP-DS может быть использован для возобновления синхронизации пары баз данных после разъединения без того, чтобы передавать все записи от заявителя к регистратору. Следовательно, этот модуль 1214 протокола LRP-DS улучшает функциональные возможности узла 1200 сети связи. Далее, модуль 1214 протокола LRP-DS решает проблемы управления запоминающим устройством, специфичные для компьютерной техники. Кроме того, модуль 1214 протокола LRP-DS осуществляет преобразование узла 1200 сети связи в другое состояние. Этот модуль 1214 протокола LRP-DS может быть реализован в виде команд, хранящихся в запоминающем устройстве 1232 и выполняемых процессором 1230 (например, в виде компьютерного программного продукта, сохраняемого на энергонезависимом носителе информации).

Запоминающее устройство 1232 содержит запоминающие устройства одного или нескольких типов, такие как диски, устройства с записью на ленту, твердотельные диски, постоянные запоминающие устройства (ПЗУ (read only memory (ROM))), запоминающие устройства с произвольной выборкой (ЗУПВ (random access memory (RAM))), флэш-память, троичное ассоциативное запоминающее устройство (ternary content-addressable memory (TCAM)), статическое ЗУПВ (static random-access memory (SRAM)) и т.д. Запоминающее устройство 1232 может быть использовано в качестве запоминающего устройства с переполнением данных для сохранения программ, когда эти программы выбраны для исполнения, и для сохранения команд и данных, считываемых при выполнении программ.

На Фиг. 13 представлена упрощенная схема примера устройства 1300 для установления пары баз данных. Это устройство 1300 может быть использовано для осуществления способа 400 и/или способа 900. Устройство 1300 содержит приемный модуль 1301 для приема приветственного сообщения, содержащего идентификатор AppId и указание целевой линии связи между локальным узлом и соседним узлом. Это устройство 1300 также содержит решающий модуль 1303 для определения, что идентификатор AppId ассоциирован с приложением для синхронизации баз данных. Устройство 1300 также содержит модуль 1305 установления пары баз данных для установления локальной базы данных в локальном узле в качестве части пары баз данных для использования приложением, эта пара баз данных содержит соседнюю базу данных, расположенную в соседнем узле. Устройство 1300 содержит также ассоциирующий модуль 1307 для ассоциирования пары баз данных с целевой линией связи. Устройство содержит также модуль 1309 управления синхронизацией, осуществляющий синхронизацию локальной базы данных с соседней базой данных с использованием целевой линии связи.

На Фиг. 14 представлена упрощенная схема примера устройства 1400 для управления синхронизацией пары баз данных. Это устройство 1400 может быть использовано для осуществления способа 400 и/или способа 1000. Устройство 1400 содержит передающий модуль 1401 для передачи одного или нескольких сообщений записи в единицах LRPDU в адрес базы данных регистратора в соседнем узле, где эти сообщения записи в единицах LRPDU указывают обновления для записей, хранящихся в базе данных заявителя в локальном узле. Устройство 1400 также содержит приемный модуль 1403 для приема одного или нескольких сообщений в единицах LRPDU, квитирующих сообщения записи в единицах LRPDU. Устройство 1400 также содержит модуль 1405 запоминающего устройства для маркировки по меньшей одной обновленной записи в базе данных заявителя в качестве квитированной базой данных регистратора. Это устройство 1400 также содержит решающий модуль 1407 для определения, что все обновленные записи из базы данных заявителя квитированы базой данных регистратора посредством сообщений в единицах LRPDU. Устройство 1400 также содержит модуль 1409 генерации уведомлений с целью уведомления приложения о том, что база данных заявителя синхронизирована с базой данных регистратора, на основе определения, что все обновленные записи в базе данных заявителя квитированы базой данных регистратора посредством сообщений в единицах LRPDU.

Фиг. 15 представлена упрощенная схема примера устройства 1500 для поддержания синхронизации баз данных, несмотря на прерывание соединения. Это устройство 1500 может быть использовано для осуществления способа 400 и/или способа 1100. Устройство 1500 содержит модуль 1501 уведомления о разъединенности для генерации кода разъединенности для приложения, где этот код разъединенности обозначает, что обмен приветственными сообщениями в единицах LRPDU не состоялся (был неуспешным). Это устройство 1500 также содержит командный модуль 1503 для приема команды от приложения с целью поддержания базы данных заявителя в запоминающем устройстве в локальном узле, несмотря на код разъединенности. Устройство 1500 также содержит приемный модуль 1505 для приема сообщения с полным списком в единицах LRPDU от базы данных регистратора, расположенной в соседнем узле, после успешного обмена приветственное сообщение, где такое сообщение с полным списком в единицах LRPDU содержит заголовки записей для всех записей, сохраняемых в базе данных регистратора. Это устройство 1500 также содержит модуль 1507 сравнения записей для осуществления сравнения заголовков записей, входящих в сообщение с полным списком в единицах LRPDU, с заголовками записей, сохраняемых в базе данных заявителя, с целью восстановления синхронизации базы данных заявителя с базой данных регистратора.

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

Первый компонент считается напрямую связанным со вторым компонентом, когда между этими первым и вторым компонентами нет никаких промежуточных компонентов, за исключением линии связи, дорожки или другого носителя. Первый компонент считается непрямо связанным со вторым компонентом, когда между этими первым и вторым компонентами присутствуют промежуточные компоненты, отличные от линии связи, дорожки или другого носителя. Термин «связанный» и его варианты охватывают как прямую связь, так и непрямую связь. Термин «около» означает некий диапазон, охватывающий ±10% от последующего числа, если специально не указано иначе.

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

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

Изобретение относится к управлению базами данных. Технический результат заключается в обеспечении возможности синхронизации баз данных между двумя пунктами с использованием транспортного протокола. Способ содержит прием, в приемнике локального узла, приветственного сообщения, содержащего идентификатор приложения (AppId) и указание целевой линии связи между целевым портом локального узла и целевым портом соседнего узла, определение, процессором в локальном узле, идентификатора AppId, ассоциированного с приложением для осуществления синхронизации баз данных, установление локальной базы данных в запоминающем устройстве в локальном узле в качестве части пары баз данных для использования указанным приложением, эта пара баз данных содержит соседнюю базу данных, расположенную в соседнем узле, ассоциирование, процессором, рассматриваемой пары баз данных с целевой линией связи и синхронизацию локальной базы данных с соседней базой данных с использованием целевой линии связи. 8 н. и 18 з.п. ф-лы, 15 ил.

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

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

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

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

ассоциирование, процессором, рассматриваемой пары баз данных с целевой линией связи; и

синхронизация локальной базы данных с соседней базой данных с использованием целевой линии связи.

2. Способ по п. 1, отличающийся тем, что процедура управления синхронизацией локальной базы данных с соседней базой данных содержит передачу, посредством передатчика из локального узла, информации записей в адрес соседней базы данных по целевой линии связи в сообщениях в единицах данных протокола регистрации локальной линии связи (link-local registration protocol data unit (в единицах LRPDU)).

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

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

5. Способ по какому-либо из пп. 1-4, отличающийся тем, что приветственное сообщение представляет собой приветственную единицу LRPDU, и тем, что эта приветственная единица LRPDU представляет целевую линию связи посредством идентификатора «Мое шасси» (ID), идентифицирующего локальный узел, идентификатора «Мой порт» ID, идентифицирующего целевой порт в локальном узле, идентификатора «Соседнее шасси» ID, идентифицирующего соседний узел, и идентификатора «Соседний порт» ID, идентифицирующего целевой порт в соседнем узле.

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

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

прием, в приемнике локального узла, одного или нескольких сообщений в единицах LRPDU, квитирующих сообщения записей в единицах LRPDU;

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

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

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

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

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

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

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

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

14. Способ по какому-либо из пп. 1-13, дополнительно содержащий:

передачу, посредством указанного передатчика, сообщения с запросом получения полного списка в единицах LRPDU в адрес базы данных регистратора; и

прием, посредством указанного приемника, сообщения с полным списком в единицах LRPDU от база данных регистратора в ответ на сообщение с запросом получения полного списка в единицах LRPDU.

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

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

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

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

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

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

17. Способ по какому-либо из пп. 1-16, дополнительно содержащий:

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

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

18. Способ по какому-либо из пп. 1-17, дополнительно содержащий:

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

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

19. Способ по п. 1, дополнительно содержащий способ по какому-либо из пп. 6 и 15.

20. Способ по п. 6, дополнительно содержащий способ по п. 15.

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

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

23. Локальный узел, содержащий:

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

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

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

ассоциирующее устройство, для ассоциирования пары баз данных с целевой линией связи; и

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

24. Локальный узел, содержащий:

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

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

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

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

25. Локальный узел, содержащий:

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

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

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

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

26. Локальный узел по какому-либо из пп. 23-25, дополнительно содержащий устройство для осуществления способа по какому-либо из пп. 1-20.