СПОСОБ ПОТОКОВОЙ ПЕРЕДАЧИ ДАННЫХ МЕЖДУ СЕРВЕРОМ И КЛИЕНТОМ Российский патент 2008 года по МПК G06F17/00 H04L12/58 

Ссылка на родственную заявку

Данная заявка испрашивает приоритет патентной заявки США № 60/437869 «SYSTEM AND METHOD FOR IMPROVED CLIENT SERVER COMMUNICATIONS», дело поверенного №220635, поданной 3 января 2003 года и содержание которой включено сюда по ссылке.

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

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

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

Электронная почта стала важным способом связи. Системы электронной почты обычно включают в себя серверный компонент (например, сервер обмена Microsoft Exchange Server) и клиентский компонент (например, Microsoft Outlook или Microsoft Outlook Express). Эти компоненты обычно представляют собой программные приложения, которые конфигурируются для выполнения на вычислительных устройствах (например, на серверах, персональных компьютерах, лэптопах и «карманных» компьютерах (PDA)).

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

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

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

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

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

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

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

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

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

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

Фиг.1 - схема компьютеров, соединенных в сеть;

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

Фиг.3 - схема, иллюстрирующая среду с множеством версий как клиентских компонентов электронной почты, так и серверных компонентов электронной почты;

Фиг.4 - диаграмма протокола, где показан пример процедуры согласования протокола между клиентским компонентом электронной почты и серверным компонентом электронной почты;

Фиг.5 - схема, где показана примерная сеть электронной почты, в которой клиентские компоненты электронной почты и серверные компоненты электронной почты имеют буферы связи (обмена) фиксированного размера;

Фиг.6А - диаграмма протокола, показывающая примерный протокол, который требует два цикла запрос-ответ для завершения операции быстрой пересылки;

Фиг.6В - диаграмма протокола, показывающая примерный протокол, который требует одного цикла запрос-ответ для завершения операции быстрой пересылки;

Фиг.7А - блок-схема последовательности операций, иллюстрирующая примерную процедуру для посылки тела сообщения электронной почты на клиентский компонент электронной почты;

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

Фиг.8А - последовательная диаграмма, иллюстрирующая режим пересылки объекта целиком;

Фиг.8В - последовательная диаграмма, иллюстрирующая режим пересылки с заголовками вначале;

Фиг.8С - последовательная диаграмма, иллюстрирующая режим пересылки только заголовков;

Фиг.8D - последовательная диаграмма, иллюстрирующая режим пересылки c исключением в режиме пересылки заголовков вначале или пересылки только заголовков;

Фиг.9 - схема, где показан изменяющийся во времени собственный серверный компонент электронной почты клиентского компонента электронной почты;

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

Фиг.11А - блок-схема, показывающая примерную процедуру для оптимизации части «блоба» (большого двоичного объекта) состояния (stateblob);

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

Фиг.12 - схема, иллюстрирующая иерархию папок электронной почты;

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

Фиг.14А - схема протокола, демонстрирующая примерный протокол для передачи информации об ошибках на уровне ROP;

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

Фиг.15А - блок-схема, демонстрирующая процедуру для создания информации об ошибках на уровне ROP;

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

Фиг.16А - схема протокола, где показан примерный протокол для выполнения операции быстрой пересылки;

Фиг.16В - схема протокола, где показан примерный протокол для предоставления информации о ходе выполнения при выполнении операции быстрой пересылки согласно одному аспекту настоящего изобретения;

Фиг.17А - блок-схема, иллюстрирующая процедуру для потоковой передачи набора сообщений;

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

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

фиг.19А - блок-схема, где показана процедура уведомления множества абонентов;

фиг.19В - блок-схема, где показана процедура уведомления множества абонентов согласно одному аспекту настоящего изобретения;

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

Подробное описание изобретения

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

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

Обратимся к фиг.2, где показан пример базовой конфигурации для компьютера, на котором можно реализовать описанное здесь изобретение в целом либо его части. В наиболее общем случае компьютер 10 обычно включает в себя по меньшей мере один блок 14 обработки (процессор) и память 16. Блок 14 обработки выполняет команды для реализации задач согласно различным вариантам изобретения. При выполнении указанных задач блок 14 обработки может передавать электронные сигналы на другие части компьютера 10 и устройства, находящиеся вне компьютера 10, для получения конкретного результата. В зависимости от конкретной конфигурации и типа компьютера 10 память 16 может быть энергозависимой (к примеру, ОЗУ), энергонезависимой (к примеру, ПЗУ или флэш-память), либо представлять собой некоторую комбинацию этих двух вариантов. Такая базовая конфигурация показана на фиг.2 пунктирной линией 18. Вдобавок, компьютер также может иметь дополнительные признаки/функциональные возможности. Например, компьютер 10 может также включать в себя дополнительное запоминающее устройство (съемное 201 и/или несъемное 202) и в том числе, но не только, магнитные или оптические диски или ленту. Компьютерная запоминающая среда включает в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или по любой технологии, используемой для запоминания информации, в том числе выполняемых компьютером команд, структур данных, программных модулей или других данных. Компьютерная запоминающая среда включает в себя, но не только: ОЗУ, ПЗУ, СППЗУ (стираемое программируемое ПЗУ), флэш-память, ПЗУ на компакт-диске, цифровой универсальный диск (DVD) либо другое оптическое запоминающее устройство, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства либо любой другой носитель, который можно использовать для запоминания необходимой информации и который может быть доступен компьютеру 10. Любой из указанных компьютерных носителей может составлять часть компьютера 10.

Предпочтительно, чтобы компьютер 10 также содержал соединения 205 для связи, которые позволяют устройству осуществлять связь с другими устройствами. Соединение для связи является примером среды для связи. Среда для связи обычно воплощает считываемые компьютером команды, структуры данных, программные модули либо другие данные в модулированном сигнале данных, таком как сигнал несущей, либо другом механизме транспортировки, и включает в себя любую среду для доставки информации. В качестве примера, но не как ограничение, термин «среда для связи» включает в себя проводную среду, такую как проводная сеть или прямое проводное соединение, и беспроводную среду, такую как акустическая, радиочастотная (RF), инфракрасная и другие беспроводные среды. Используемый здесь термин «считываемый компьютером носитель» включает в себя как компьютерную запоминающую среду, так и среду для связи.

Компьютер 10 может также иметь устройства 204 ввода, такие как клавиатура, мышь, перо, устройство речевого ввода, сенсорное устройство ввода и т.п. Также в компьютере могут быть устройства 203 вывода, такие как дисплей 20, динамики, принтер и т.п. Все эти устройства хорошо известны специалистам в данной области техники и обсуждать их далее нет необходимости.

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

Настоящее изобретение можно реализовать в среде клиент/сервер, имеющей две или более версий клиентских приложений или компонентов, и/или две или более версий серверных приложений или компонентов. С этой целью на фиг.3 показана блок-схема, демонстрирующая множество версий клиентских и серверных компонентов в сетевой среде электронной почты. В общем случае клиентские и серверные компоненты сконфигурированы таким образом, чтобы они были обратно совместимыми. То есть, клиентский компонент способен осуществлять связь с последними легальными версиями серверных компонентов, и наоборот. Для осуществления связи между множеством версий утвержден набор протоколов. Набор протоколов может образовать несколько различных протоколов, каждый из которых является автономным. В альтернативном варианте можно иметь набор протокольных компонентов и использовать конкретные компоненты для конфигурации конкретных протоколов в наборе протоколов. В любом случае в сетевой среде электронной почты, показанной на фиг.3, клиентский компонент 303 электронной почты, имеющий самую последнюю версию, осуществляет связь наилучшим образом с серверным компонентом 306 электронной почты, имеющим саму последнюю версию, с использованием протокола 307. Однако серверный компонент 306 электронной почты, имеющий самую последнюю версию, способен также осуществлять связь с выбранными клиентскими компонентами электронной почты, имеющими предыдущие версии, например с клиентским компонентом 302 электронной почты и клиентским компонентом 301 электронной почты, используя другие протоколы (например, протоколы 308 и 309 на фиг.3) из набора протоколов. Клиентский компонент 303 электронной почты способен также осуществлять связь с выбранными серверными компонентами электронной почты, имеющими предыдущие версии, например с серверным компонентом 305 электронной почты и серверным компонентом 304 электронной почты, используя такие протоколы, как протоколы 310 и 311.

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

Для установки протокола между клиентом и сервером (например, серверным компонентом 306 электронной почты, имеющим самую последнюю версию, и клиентским компонентом 303 электронной почты, имеющим самую последнюю версию) часто используют процедуру согласования протокола. Хотя указанные согласования протокола известны, для удобства читателей ниже кратко описывается процедура согласования протокола между клиентским компонентом 401 электронной почты (фиг.4) и серверным компонентом 402 электронной почты (также фиг.4). Ранее при сеансе связи между клиентским компонентом 401 электронной почты и серверным компонентом 402 электронной почты клиентский компонент 401 электронной почты посылал на серверный компонент 402 электронной почты сообщение 403, которое включает в себя информацию о версии клиента, например, в виде штампа (отметки) версии клиентского компонента. Серверный компонент 402 электронной почты реагирует на сообщение 403 сообщением 404, которое включает в себя информацию о версии сервера, например, в виде штампа (отметки) версии серверного компонента.

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

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

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

В качестве примера на фиг.5 показан обмен запросами и ответами между клиентским компонентом 501 электронной почты и серверным компонентом 502 электронной почты. Как клиентский компонент 501 электронной почты, так и серверный компонент 502 электронной почты имеют буферы 503, 504, 505 и 506 связи с фиксированными размерами. Буферы 503, 504, 505 и 506 представляют собой резервные области памяти для временного хранения данных. Клиентский компонент 501 электронной почты начинает цикл запрос-ответ, заполняя буфер 503 одним или несколькими подзапросами или удаленными операциями (ROP, УОП) перед передачей содержимого буфера 503 в буфер 504.

После приема в буфере 504 каждая ROP обрабатывается по порядку серверным компонентом 502 электронной почты, а соответствующий результат записывается в буфер 505. Каждая операция ROP дает некоторый результат. Этот результат может включать в себя данные, запрошенные клиентским компонентом 501 электронной почты, например конкретный набор сообщений электронной почты. Серверный компонент 502 электронной почты непрерывно контролирует буфер 505 и, когда тот становится почти полным (например, остается менее 8 килобайт), серверный компонент 502 электронной почты записывает необработанные ROP в конец буфера 505 и передает содержимое буфера 505 в буфер 506. Затем клиентский компонент 501 электронной почты начинает новый цикл запрос/ответ, записывая необработанные ROP в буфер 503 для повторного представления серверному компоненту 502 электронной почты, когда буфер 503 будет вновь заполнен.

Размер ответа в среднем обычно больше, чем размер запроса. По этой причине размер буферов 505 и 506 ответов обычно конфигурируется таким образом, чтобы он был больше размера буферов 503 и 504 запросов. В одном варианте изобретения оптимальный размер буферов 505 и 506 ответов был определен равным 96 килобайт при размере 32 килобайта для буферов 503 и 504 запросов, то есть с отношением 3 к 1. В одном варианте клиентский компонент электронной почты способен конфигурировать размер любого из буферов 503, 504, 505 и 506.

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

На фиг.6А показана операция быстрой пересылки, имеющая по меньшей мере два цикла запрос-ответ. В первом запросе 601 удаленная операция ROP (например, FXPrepare) инициализирует на сервере 502 источник данных для быстрой пересылки. На этом сервере обрабатывается только FXPrepare (то есть, инициализируется источник данных для быстрой пересылки), и полученный результат возвращается обратно в первом ответе 602. Во втором запросе 603 удаленная операция ROP (например, FXGetBuffer) запрашивает сервер, чтобы тот заполнил буфер 505 источника данных для быстрой пересылки. Сервер разгружает источник быстрых данных в буфер и возвращает результат во втором ответе 604. Если выходной буфер 505 для серверного компонента электронной почты заполняется до того, как будет полностью разгружен (опустошен) источник быстрых данных, то могут понадобиться дополнительные операции FXGetBuffer ROP.

На фиг.6В показана операция быстрой пересылки, имеющая только один цикл запрос-ответ. В первом запросе 605 серверный компонент 502 электронной почты обрабатывает как FXPrepare, так и FXGetBuffer, и результаты обеих операций возвращаются обратно в первом ответе 606. Результат операции FXPrepare доступен операции FXGetBuffer на серверном компоненте 502 электронной почты, поскольку часть каждого буфера 503, 504, 505 и 506 задана в явном виде как совместно используемая таблица данных. Желательно сократить количество циклов запрос-ответ, поскольку это приводит к более эффективной пересылке данных. Операция быстрой пересылки, имеющая более одного цикла запрос-ответ, может выполняться тогда, когда буфер 505 заполнен настолько, что не может вместить результат FXGetBuffer ROP.

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

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

Согласно одному аспекту настоящего изобретения количество циклов запрос-ответ минимизируется автоматически следующим образом: на ключевые операции ROP (например, FXGetBuffer) не распространяют требование предсказания размера их результата. Вместо этого указанные ROP обрабатываются серверным компонентом 502 электронной почты до тех пор, пока не будет полностью заполнен буфер 505 (такой же, как буфер 506). Например, в среде, которая включает в себя множество версий серверных компонентов электронной почты, можно определить операции ROP отдельно для серверных компонентов, имеющих предыдущие версии, и отдельно для серверных компонентов, имеющих последние версии. На последние версии не распространяется требование предсказания размера их результата. Характеристики для этих ROP представлены далее в следующей таблице:

 ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими предыдущие версии ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими самую последнюю версиюИдентификатор (ID) ROPFXGetBufferFXGetBufferПараметры, используемые во множестве режимовТребуемый размер: размер, который должен зарезервировать сервер в своем выходном буфереТребуемый размер: устанавливается равным значению ниже максимального, ожидаемого по предыдущей версии, например, больше 32 килобайт. Это является сигналом для сервера на поиск нового предельного размера ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими предыдущие версии ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими самую последнюю версию  ПараметрНовые параметрыНе доступныПредельный размер: информирует сервер о пределе, до которого сервер может заполнить свой выходной буфер

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

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

В сети электронной почты одной из типовых функций протокола является обеспечение пересылки объектов данных, например сообщений электронной почты между клиентскими компонентами электронной почты и серверными компонентами электронной почты. Дополнительные примеры указанных объектов данных включают в себя папки электронной почты, которые могут содержать сообщения электронной почты и другие объекты данных, а также объекты данных с информацией, относящейся к папке (FAI), которые могут, например, содержать правила для обработки сообщений электронной почты, либо определять, каким образом будут отображаться объекты данных, содержащиеся в папке. Объекты данных могут быть непрозрачными для клиентского компонента электронной почты; то есть, у клиентского компонента электронной почты могут отсутствовать средства интерпретации содержимого объекта данных. В альтернативном варианте объекты данных могут содержать именованные свойства, например сообщение электронной почты может содержать свойства под названием «к» (to), «от» (from), «тема» (subject), «важность» (importance), «тело 1» (body 1), «тело 2» (body 2), «тело 3» (body 3), «вложение 1» (attachment 1), «вложение 2» (attachment 2) и т.д.

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

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

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

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

На фиг.7А показана часть процедуры, которая используется серверным компонентом электронной почты, имеющим предыдущую (известную) версию, для формирования ответа в указанной ситуации. На этапе 701 серверный компонент электронной почты анализирует формат каждого тела сообщения электронной почты. Если один из форматов представляет собой заданный стандартный формат (например, RTF), то тогда процедура переходит к этапу 703, и тело сообщения электронной почты посылается запрашивающему клиентскому компоненту электронной почты в стандартном формате. Если ни один из форматов не соответствует заданному стандартному формату, то тогда от этапа 701 переходят к этапу 702, где одна из версий тела сообщения электронной почты преобразуется в стандартный формат. Подпроцедура, изображенная на фиг.7А, также может быть использована тогда, когда имеется только одна версия тела сообщения электронной почты, но тело сообщения электронной почты может не иметь стандартный формат, как того требует протокол.

На фиг.7В показана часть процедуры, используемой серверным компонентом электронной почты, имеющим самую последнюю версию, согласно настоящему изобретению. На этапе 704 протокольный запрос, который вызвал эту подпроцедуру, используемую серверным компонентом электронной почты, анализируется на предмет наличия флага BEST_BODY (наилучшее тело). Флаг в этом примере, а также применяемые здесь другие флаги указывают серверному компоненту электронной почты о том, что клиентский компонент электронной почты имеет самую последнюю версию и требует реализации функции, связанной с данным флагом. Могут быть использованы и другие индикации, например указанная функция может быть реализована по умолчанию, если обнаружен клиентский компонент электронной почты, имеющий самую последнюю версию.

В любом случае, если флаг DEST_BODY не обнаружен, то тогда от этапа 704 переходят к этапу 701, и процедура продолжается, как было описано со ссылкой на фиг.7А.

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

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

Удаленные операции (ROP) можно использовать для обеспечения дублирования папки электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты. Запрос на синхронизацию папки может быть выполнен, например, с помощью операции SynchFolder ROP. Там, где клиентский компонент электронной почты способен отображать нестандартные форматы тела сообщения электронной почты, он может установить флаг BEST_BODY в SynchFolder ROP, указывая тем самым, что этот серверный компонент электронной почты может выбрать среди имеющихся тел сообщения электронной почты наилучший формат, вместо того, чтобы потребовать от сервера вернуться к телу сообщения электронной почты в стандартном формате. Серверный компонент электронной почты может правильно обрабатывать удаленные операции (ROP) как с флагом BEST_BODY, так и без него при весьма умеренном возрастании сложности. Операции ROP для осуществления связи с серверами, имеющими предыдущие версии и самую последнюю версию, могут, например, включать в себя характеристики, показанные в представленной ниже таблице:

 ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими предыдущие версии ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими самую последнюю версиюИдентификатор (ID) ROPSynchFolderSynchFolderНовые параметры Не доступныФлаг BEST_BODY: если установлен, то серверный компонент электронной почты выбирает для посылки клиентскому компоненту электронной почты наилучшее тело сообщения электронной почты. Преобразование тела сообщения электронной почты в заданный стандартный формат не требуется.

На фиг.8А-8С показано несколько различных существующих режимов пересылки набора сообщений электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты. Для каждого режима каждое сообщение электронной почты имеет именованные свойства, в том числе набор заголовков и набор тел, а несколько сообщений электронной почты находятся в папке. На фиг.8А показан режим пересылки полного объекта. Из этой фигуры видно, что пересылается заголовок 801 первого сообщения электронной почты, а затем тело 802 первого сообщения электронной почты перед заголовком 803 второго сообщения электронной почты, после чего пересылают тело 804 второго сообщения электронной почты и так до тех пор, пока не будет переслан весь набор сообщений электронной почты. На фиг.8В показан режим пересылки "сначала заголовки". В этом режиме пересылается заголовок 805 первого сообщения электронной почты, а затем заголовок 806 второго сообщения и так до тех пор, пока не будут пересланы все заголовки электронных сообщений, и только затем пересылается тело 807 первого сообщения электронной почты, потом тело 808 второго сообщения электронной почты и так далее, пока не будет переслан весь набор сообщений электронной почты. На фиг.8С показан режим пересылки только заголовков. Когда предлагается имя, в ответ на запрос на пересылку набора сообщений электронной почты пересылаются только заголовки 809 сообщений электронной почты. Тела 810 сообщений электронной почты будут пересылаться только в ответ на дополнительный запрос в явном виде. В любом из этих режимов последовательность пересылки может быть временно нарушена запросом от клиентского компонента электронной почты, имеющим более высокий приоритет, например для особого тела сообщения электронной почты.

Примером цели (назначения) запроса для пересылки набора сообщений электронной почты является папка электронной почты. Однако папка электронной почты может содержать объекты данных, отличные от сообщений электронной почты. Как описано выше, режимы пересылки часто определяют со ссылками на заголовки сообщений электронной почты и тела сообщений электронной почты, такие как режимы пересылки "сначала заголовки" и режим пересылки только заголовков. В указанных режимах пересылки попытка переслать объекты данных, для которых набор заголовков именованных свойств и/или набор тел именованных свойств не может быть вполне ("хорошо") определен, может вызвать сбой протокола. Один аспект изобретения позволяет избежать этой ситуации, обеспечивая возможность пересылки объектов данных, для которых набор заголовков и/или тел именованных свойств не является "хорошо" (полностью) определенным, всегда в целом, а не по частям. Этот вариант можно проиллюстрировать примером, показанным на фиг.8D. В этом примере пересылка между серверным компонентом электронной почты и клиентским компонентом электронной почты может происходить в режиме пересылки только заголовков. Соответственно, пересылается заголовок 811 первого сообщения электронной почты, а затем следующим кандидатом для пересылки становится объект данных 812. Набор заголовков именованных свойств для объекта 812 данных, такого как FAI, не является "хорошо" определенным, так что пересылается весь объект данных в целом. Следующий кандидат для пересылки имеет "хорошо" определенный набор заголовков именованных свойств (то есть, объект данных - кандидат обладает всеми именованными свойствами, определенными в явном виде клиентским компонентом электронной почты как принадлежащие набору заголовков именованных свойств) и поэтому пересылается только заголовок 813 сообщения электронной почты.

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

 ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими предыдущие версии ROP, которая может быть использована протоколом для осуществления связи с серверами, имеющими самую последнюю версиюИдентификатор (ID) ROPSynchFolderSynchFolderНовые параметры Не доступныФлаг IGNORE_MODE_ON_FAI: если установлен, то для объектов данных, таких как FAI, которые не имеют полностью определенный набор именованных свойств заголовков и/или тел, серверный компонент электронной почты может реагировать на запрос на пересылку, используя весь объект данных в целом независимо от превалирующего режима пересылки.

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

На фиг.9 показано, что даже в случае простой стратегии на основе собственного сервера могут возникнуть сложности. В примере, показанном на фиг.9, конкретный серверный компонент 901 электронной почты сначала обозначен как собственный сервер для конкретного пользователя сети электронной почты. Через некоторое время этот обозначенный собственный сервер для данного пользователя переключается на другие серверные компоненты электронной почты 903 и 905 обычно по административным причинам. Серверные компоненты 901, 903 и 905 электронной почты могут, например, физически либо логически отличаться друг от друга или представлять собой разные версии. Клиентский компонент 902 электронной почты может осуществлять связь только с серверным компонентом 901 электронной почты с момента времени Т₀ по момент времени Т₁, после чего клиентский компонент 904 электронной почты может осуществлять связь только с серверным компонентом 903 электронной почты до момента времени Т₂, а затем клиентский компонент 906 электронной почты может осуществлять связь только с серверным компонентом 905 электронной почты. Клиентские компоненты 902, 904 и 906 электронной почты могут быть одинаковыми или разными. Серверные компоненты 901 и 903 электронной почты могут существовать, а могут и не существовать после момента времени Т₂. Эти сложности особенно влияют на дублирование хранения сообщений электронной почты, которое обсуждается ниже.

Сообщения электронной почты могут быть сохранены на серверном компоненте электронной почты в явном виде в хранилище сообщений электронной почты, которое может быть реализовано, например, с использованием хорошо известных технологий построения баз данных. Серверный компонент электронной почты может иметь одно или несколько указанных хранилищ сообщений. Пользователь сети электронной почты может иметь собственное ("домашнее") хранилище сообщений. Изменение собственных хранилищ сообщений может вызвать те же эффекты, что были описаны для случая изменения собственных серверов.

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

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

На фиг.10 показан более подробный пример протокола, обеспечивающего инкрементное дублирование. Хранилище сообщений электронной почты можно разбить на папки электронной почты. Каждую папку электронной почты можно продублировать независимо от других, обеспечивая управление процессом дублирования на уровне более мелких структурных единиц. В данном примере процесс инкрементного дублирования назван синхронизацией, поскольку он включает в себя распространение изменений от клиентского компонента 501 электронной почты на серверный компонент 502 электронной почты, а также от серверного компонента 502 электронной почты на клиентский компонент 501 электронной почты. После запроса 1001 на синхронизацию, серверный компонент 501 электронной почты обрабатывает SynchFolder ROP. Операция ROP включает в себя параметр folderID (не показан) и параметр stateblob₀. Параметр folderID идентифицирует папку электронной почты, которая является назначением запроса 1001 на синхронизацию. Параметр stateblob₀ содержит информацию позволяющую серверному компоненту 502 электронной почты определить, какие появились изменения в папке электронной почты, если это имело место, с момента последней синхронизации. Если запрос 1001 представляет собой первый запрос на синхронизацию для папки, намеченной клиентским компонентом 501 электронной почты, то тогда серверный компонент 502 электронной почты определяет, изменилась ли намеченная (назначенная) папка электронной почты в хранилище сообщений электронной почты по сравнению с пустой папкой. В ответе 1002 на запрос 1001 серверный компонент 502 электронной почты посылает изменения на клиентский компонент 501 электронной почты, в том числе сообщения электронной почты и/или другие объекты данных, которые были добавлены в намеченную папку, а также список сообщений электронной почты и/или других объектов данных, которые были удалены из намеченной папки. Серверный компонент 502 электронной почты также создает новый stateblob₁, представляющий собой состояние намеченной папки, каким оно будет на клиентском компоненте 501 электронной почты сразу после синхронизации, а также посылает этот stateblob₁ в ответе 1002. Когда клиентский компонент 501 электронной почты посылает следующий запрос 1003 на синхронизацию для той же папки, что и в запросе 1001, то тогда запрос 1003 будет включать в себя в качестве параметра тот же самый stateblob₁, который был возвращен вместе с ответом 1002. Как и ранее, серверный компонент 502 электронной почты будет использовать информацию, содержащуюся в stateblob₁ для определения того, какие изменения, если они имеются, появились в намеченной папке, и пошлет эти изменения вместе с вновь созданным параметром stateblob₂ обратно на клиентский компонент 501 электронной почты в ответе 1004.

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

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

С целью обсуждения объект данных changeID сообщения может быть представлен, например, как «S₁:1», где 'S₁' представляет объект данных serverID для первого серверного компонента электронной почты, а '1' представляет порядковый номер. Набор объектов данных changeID сообщения может быть представлен, например, как «S₁:1, S₁:2, S₁:3», где «S₁:1», «S₁:2» и «S₁:3» - объекты данных changeID последовательных сообщений, используемые серверным компонентом электронной почты вместе с severID S₁.

Для случая, когда stateblob по большей части выполнен в виде набора объектов данных changeID сообщения, представляющих изменения сообщений электронной почты, увиденные клиентским компонентом электронной почты (набор «увиденные изменения сообщения»), был разработан ряд способов кодирования этого набора с целью сокращения его размера; например, набор «S₁:1, S₁:2, S₁:3, S₁:4» может быть закодирован в виде «S₁:1-4». Вдобавок, серверный компонент электронной почты может обеспечить, чтобы порядковые номера, которые он использует, всегда возрастали. В этом случае прерывистый набор увиденных изменений сообщения, например, «S₁:1, S₁:3, S₁:5, S₁:7» может быть закодирован в виде «S₁:1-7», то есть в виде диапазона, включающего в себя минимальный и максимальный порядковые номера, без потери функциональных возможностей. В сценарии, изображенном на фиг.9, набор "увиденные изменения сообщения" может включать в себя объекты данных changeID сообщения, которые были созданы серверными компонентами электронной почты (например, S₁, S₂), отличными от текущего собственного сервера (например, S₃). Объект данных changeID сообщения, созданный текущим собственным сервером, можно назвать местным changeID сообщения, объект данных changeID сообщения, созданный другими серверными компонентами электронной почты, можно назвать внешним changeID сообщения. Сетевой протокол электронной почты для осуществления связи с серверными компонентами электронной почты, имеющими предыдущие версии, не обеспечивает оптимизацию прерывистых последовательностей внешних changeID сообщения в виде диапазона, включающего в себя минимальный и максимальный порядковые номера по каждому серверному компоненту электронной почты.

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

 Оптимизация, используемая сервером, имеющим предыдущую версию (текущий собственный сервер S₃)Оптимизация, используемая сервером, имеющим самую последнюю версию (текущий собственный сервер S₃)Набор "увиденные изменения сообщения" перед оптимизациейS₁:1, S₁:3, S₁:5, S₁:7
S₂:1, S₂:3, S₂:5, S₂:7
S₃:1, S₃:3, S₃:5, S₃:7Набор "увиденные изменения сообщения" после оптимизацииS₁:1, S₁:3, S₁:5, S₁:7
S₂:1, S₂:3, S₂:5, S₂:7
S₃:1-7S₁:1-7
S₂:1-7
S₃:1-7

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

 ROP, которая может быть использована протоколом при осуществлении связи с серверами, имеющими предыдущие версии ROP, которая может быть использована протоколом при осуществлении связи с серверами, имеющими самую последнюю версиюИдентификатор (ID) ROPSynchFolderSynchFolderНеизменяемые параметры, используемые в новом режимеStateblob: оптимизация, не включающая в себя прерывистые наборы внешних объектов данных changeID сообщенияStateblob: улучшенная оптимизация, включающая в себя непрерывные наборы внешних объектов данных changeID сообщения

На фиг.11А и 11В показано различие между подпроцедурой, которая может быть использована сервером, имеющим предыдущие версии, и сервером, имеющим самую последнюю версию, соответственно при реагировании на SynchFolder ROP. На фиг.11А показаны этапы 1101, 1102 и 1103. На шаге 1101 формируется начальный набор "увиденные изменения сообщения". На этапе 1102 элементы набора "увиденные изменения сообщения", которые представляют собой местные объекты данных changeID сообщения, оптимизируются. На этапе 1103 оптимизированный набор "увиденные изменения сообщения" добавляется к объекту данных stateblob, который может быть послан вместе с ответом на клиентский компонент электронной почты, запросивший синхронизацию. Фиг.11В включает в себя дополнительный этап 1104, на котором демонстрируются элементы набора "увиденные изменения сообщения", являющиеся внешними объектами данных changeID сообщения, которые также оптимизируются до того, как набор "увиденные изменения сообщения" теперь с улучшенной оптимизацией, добавлен на этапе 1103 к объекту данных stateblob.

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

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

Там, где хранилища сообщений электронной почты разбиты на папки электронной почты, эти папки электронной почты могут быть организованы в виде иерархических структур. На фиг.12 показан пример иерархии электронных папок. На фиг.12 папка 1204 является подпапкой папки 1203. В свою очередь, папка 1203 является подпапкой папки 1202. Папка 1201 является корневой папкой. Корневая папка не является подпапкой никакой другой папки. Все другие папки являются элементами иерархии папок, имеющей в качестве корня папку 1201. Обычно каждая папка в иерархии папок не имеет прямую ссылку к любой другой папке. Папка может только иметь прямую ссылку на свои подпапки. Папка может также иметь прямую ссылку на любые папки, для которых она является подпапкой. Во многих случаях может оказаться, что корневой папкой иерархии является только та папка, для которой каждая папка имеет прямую ссылку.

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

Имя атрибутаТип атрибутаПримечанияИдентификатор (ID) папки FIDТип FID содержит глобальный уникальный идентификатор (GUID) и шестибайтовый порядковый номер. Это значение можно использовать для уникальной идентификации папки электронной почты в контексте сети электронной почты.PR_LOCAL_COMMIT_TIME_MAXОтметка времениЭта отметка времени обновляется всякий раз, когда модифицируется содержимое папки.PR_DELETED_COUNT_TOTALQWORDЭто значение представляет собой отсчет общего количества объектов, когда-либо удаленных из папки.

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

Осуществление связи между клиентским компонентом электронной почты и серверным компонентом электронной почты может быть разделено на сеансы связи. Между сеансами связи, например, во время прерывания сетевых соединений может произойти потеря синхронизации хранилища сообщений электронной почты. Для того чтобы вновь установить синхронизацию хранилища сообщений электронной почты к началу сеанса связи, в некоторых протоколах для осуществления связи с серверными компонентами электронной почты, имеющими предыдущие версии, использовалась операция SynchFolder ROP для каждой папки в иерархии папок. Обычно содержимое некоторых папок между сеансами не изменяется. Операция SynchFolder ROP с неизменной папкой в качестве цели этой операции приводит к «нулевой синхронизации». Хотя «нулевая синхронизация» не приводит к каким-либо изменениям папки, пересылаемым на клиентский компонент электронной почты, это связано с дополнительными расходами ресурсов, например, для объекта данных stateblob, которые могут быть весьма значительными. На фиг.13 показан вариант изобретения, в котором удается избежать результатов указанной «нулевой синхронизации» путем использования таблицы глубокой иерархии. В первом запросе 1301 клиентский компонент 501 электронной почты посылает на серверный компонент электронной почты удаленную операцию (ROP) (например, GetHierarchyTable), запрашивая таблицу глубокой иерархии. В первом ответе 1302 клиентскому компоненту 501 электронной почты предоставляют копию таблицы глубокой иерархии. Обычно клиентский компонент 501 электронной почты будет иметь предыдущую копию таблицы глубокой иерархии. Клиентский компонент 501 электронной почты может быстро определить, какие папки в хранилище сообщений электронной почты пользователя в серверном компоненте 502 электронной почты изменились, путем использования построчного сравнения двух копий. Далее используют операции ROP (например, SynchFolder) для синхронизации только тех папок, которые претерпели изменение. Запрос 1303 и запрос 1304 можно повторить, если это необходимо для синхронизации измененных папок. После успешной синхронизации копия таблицы глубокой иерархии у клиентского компонента электронной почты может быть обновлена, чтобы соответствовать самой последней копии, посланной в ответе 1302. Если клиентский компонент 501 электронной почты не имеет предыдущую копию таблицы глубокой иерархии, то тогда могут быть синхронизированы все папки, имеющие строку в самой последней копии.

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

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

Вновь обратимся к фиг.13, где при использовании клиентским компонентом 501 электронной почты, имеющим самую последнюю версию согласно одному аспекту настоящего изобретения, в первом запросе 1301 операции GetHierarchyTable ROP в начале сеанса связи с серверным компонентом 502 электронной почты клиентский компонент 501 электронной почты автоматически подписывается на уведомления об изменениях, связанные с таблицей глубокой иерархии, которая пересылается обратно в ответе 1302. При появлении изменения в папке электронной почты в хранилище сообщений электронной почты пользователя на стороне клиентского компонента электронной почты, например при добавлении в папку сообщения электронной почты, таблица глубокой иерархии также обновляется, как было описано ранее. Изменение в таблице глубокой иерархии инициирует предупреждение 1305 об уведомлении клиентскому компоненту 501 электронной почты. Хотя предупреждение об уведомлении происходит в ответ на подписку, размещенную запросом 1301, оно не является частью явного цикла запрос-ответ. Таким образом, использование системы уведомления, предлагаемой в настоящем изобретении, приводит к гораздо меньшим дополнительным затратам ресурсов сети электронной почты.

Одна подписка может привести к множеству уведомлений. В одном варианте предупреждение доставляется путем использования механизма сетевой транспортировки без установления соединения, например протокола дейтаграмм пользователя/протокола Интернет (UDP/IP), но при этом следует заметить, могут быть использованы любые подходящие механизмы сетевой транспортировки. В ответ на предупреждение клиентский компонент 501 электронной почты посылает запрос 1306, содержащий ROP (например, GetNotification) на серверный компонент 502 электронной почты. В ответе 1307 на клиентский компонент 501 электронной почты посылаются измененные строки таблицы глубокой иерархии (то есть, строки, соответствующие измененной папке, которая инициировала уведомление). Затем клиентский компонент 501 электронной почты использует операции ROP (например, SynchFolder) для синхронизации только тех папок, которые претерпели изменение.

Множество клиентских компонентов электронной почты могут подписаться на уведомления об изменениях, связанные с одним и тем же объектом данных (например, с одной и той же папкой электронной почты), к примеру, чтобы обеспечить общие функциональные возможности. Как показано на фиг.18, клиентские компоненты 1801, 1802 и 1803 электронной почты имеют подписку на уведомления об изменениях, связанные с одним и тем же объектом данных (не показан), находящимся в серверном компоненте 1804 электронной почты. Клиентский компонент 1803 электронной почты посылает ROP 1805 на серверный компонент 1804 электронной почты, что приводит к изменению в объекте данных. В результате этого изменения серверный компонент 1804 электронной почты высылает уведомления 1806, 1807 и 1808 об изменениях на клиентские компоненты 1801, 1802 и 1803 электронной почты. Уведомления об изменениях могут нести небольшой объем информации, дополнительно идентифицирующей объект данных, который изменился, так что, например, клиентский компонент электронной почты возможно не сможет определить, в чем была причина конкретного изменения. Если объектом данных является, например, папка электронной почты, то уведомления 1806, 1807 и 1808 об изменениях могут привести к инициированию синхронизации для измененной папки в каждом клиентском компоненте 1801, 1802 и 1803 электронной почты. Поскольку в этом примере ответственным за изменение был клиентский компонент 1803 электронной почты, результатом будет «нулевая синхронизация».

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

На фиг.19А показан режим уведомления, который может быть обеспечен серверными компонентами электронной почты, имеющими предыдущие версии. На фиг.19В показан конфигурируемый режим уведомления согласно одному аспекту настоящего изобретения. Если это потребуется, то клиентский компонент электронной почты, имеющий самую последнюю версию, может указать серверному компоненту электронной почты, что он способен реализовать режим уведомления по фиг.19В, например, путем предоставления вместе с запросом флага; в примере, показанном на фиг.19В, - это флаг IGNORE_OWN.На этапе 1901 из набора уведомляемых подписчиков выбирают следующего кандидата. На этапе 1904 анализируют подписку на предмет наличия флага IGNORE_OWN. Если этот флаг отсутствует, то выполняется переход от этапа 1904 к этапу 1902, где подписчику-кандидату посылается уведомление. Если флаг обнаружен, то выполняется переход от этапа 1904 к этапу 1905, где вновь анализируют подписку, чтобы определить, инициировал ли подписчик данное уведомление. Это определение может быть выполнено, например, путем анализа идентификатора сеанса связи («ID сеанса») для сеанса, который был использован для размещения подписки. Идентификатор ID сеанса может, например, содержать глобальный уникальный идентификатор и шестибайтовый порядковый номер. Также уведомление анализируют на предмет ID сеанса, связанного с его причиной. Если они совпадают, то тогда уведомление запрещается. В результате этого клиентский компонент электронной почты, который вызвал уведомление, также не получит это уведомление. Затем подпроцедура переходит к этапу 1903, описанному ниже.

Если подписчик не инициировал уведомление, то тогда ID сеанса, связанный с подпиской, не совпадает с ID сеанса, связанного с причиной уведомления, и от этапа 1905 переходят к этапу 1902, где посылается уведомление. Затем процесс переходит к этапу 1903, где определяют, есть ли еще подписчики, требующие уведомления. Если они есть, то подпроцедура возвращается к этапу 1901; в противном случае эта подпроцедура заканчивается.

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

Обычно при запросе на синхронизацию или копирование сообщений либо других данных, таких как файлы, запрос (например, ROP), включает в себя индикацию всех сообщений, для которых требуется синхронизация. Этот список может быть автоматически сформирован серверным компонентом электронной почты, например, путем использования вышеописанного признака stateblob. Для серверных компонентов электронной почты, имеющих предыдущие версии (известный уровень техники), ошибка в одном сообщении или объекте данных в запросе ROP вызовет отказ всех элементов в запросе. Этот процесс показан на фиг.14А, где на этапе 1401 передается запрос, содержащий ROP (например, FXPrepare) вместе с набором ID сообщений, предназначенным для копирования или синхронизации. На серверном компоненте 502 электронной почты установлен механизм быстрой пересылки, и на этапе 1402 на клиентский компонент 501 электронной почты передается ID быстрой пересылки. Затем клиентский компонент 501 электронной почты запрашивает копирование или синхронизацию объектов данных через запрос, содержащий, например, FXGetBuffer ROP (шаг 1403). Ошибка появляется с одним или несколькими сообщениями или другими объектами данных, когда серверный компонент 502 электронной почты пытается открыть запрошенные сообщения. Примеры ошибок включают в себя разрушающееся сообщение или объект данных, отказ сервера, нехватку памяти для серверного компонента 502 электронной почты, либо вирус, обнаруженный в объекте данных.

После появления ошибки серверный компонент 502 электронной почты на этапе 1404 посылает неисправимую ошибку ROP в данных, переданных потоком на клиентский компонент 501 электронной почты. Таким образом, синхронизация не происходит, сообщения в наборе ID сообщений не синхронизируются или не копируются, и клиентский компонент 501 электронной почты не принимает информацию stateblob или аналогичную информацию для обновления. Затем клиентский компонент 501 электронной почты должен запросить синхронизацию или копирование объектов данных в другое время. Возможно, что, если ошибка на серверном компоненте 502 электронной почты не зафиксирована, то может продолжаться посылка сообщений об ошибке, и сообщения в наборе ID сообщений никогда не могут быть синхронизированы или скопированы.

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

На фиг.14В показана синхронизация для случая, когда ошибка появляется в сообщении M₃. Эта ошибка вызывает ответ FXGetBuffer (1405), включающий в себя сообщение М₁, и сообщение М₂, за которым следует FXErrorInfo, а затем сообщение М₄. Информация FXErrorInfo позволяет клиентскому компоненту 501 электронной почты узнать, какое сообщение имело ошибку, и синхронизировать все другие сообщения в ответе. Если FXErrorInfo сообщения об ошибке включает в себя информацию о причине ошибки, то на эту информацию может соответственно отреагировать клиентский компонент, например, путем отображения пользователю сообщения об ошибке.

В следующей таблице показан пример формата, который может принять FXErrorInfo:

FXErrorInfoИмя атрибутаТип атрибутаПримечанияВерсияWORDВерсия данной структуры.Код ошибкиDWORD ID сообщенияMIDТип MID содержит глобальный уникальный
идентификатор (GUID) и шестибайтовый
порядковый номер.
Это ID того сообщения,
которое вызвало ошибку.......Сюда может быть добавлен ноль или более атрибутов.

FXErrorInfoИмя атрибутаТип атрибутаПримечанияРазмер вспомогательного поляULONGРазмер массива, который следует далееВспомогательное полеМассив BYTEНеструктурированный массив для передачи деталей ошибки

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

FXErrorInfo позволяет завершить синхронизацию первого ответа, например, предоставляя в результате клиентскому компоненту 501 электронной почты stateblob или другую информацию. Поскольку клиентский компонент электронной почты теперь синхронизирован через сообщение М₄, следующий запрос 1406 на синхронизацию может в результате привести к ответу 1407, имеющему сообщения после сообщения М₄ (например, М₅ и М₆).

Для индикации того, что клиентский компонент 501 электронной почты имеет самую последнюю версию и таким образом способен обработать сообщение FXErrorInfo, можно определить флаг, например, FXRecoverMode, который может передаваться вместе с удаленной операцией (ROP), запрашивающей синхронизацию или копирование. Для передачи на серверный компонент 502 электронной почты, который способен обрабатывать сообщение FXErrorInfo, можно использовать другие индикации для клиентского компонента 501 электронной почты.

Когда серверный компонент 502 электронной почты посылает одно или несколько сообщений либо другие объекты данных на клиентский компонент 501 электронной почты, поток данных на клиентский компонент электронной почты может быть выделен или задан тегами свойств (например, ptags). Например, список сообщений может включать в себя тег ptag стартового сообщения и тег ptag конечного сообщения для каждого сообщения. Между стартовым и конечным тегами ptag может быть ptag списка свойств и ptag темы, которые могут иметь свойства строки. За тегом ptag темы может следовать сама тема. Также могут быть и другие теги свойств.

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

На фиг.15А показаны этапы, которые может использовать серверный компонент 502 электронной почты для пересылки сообщений на клиентский компонент 501 электронной почты, имеющий предыдущую версию. Вначале на этапе 1501 готовится набор сообщений, например, путем помещения набора сообщений в хранилище данных для быстрой пересылки. На этапе 1502 начинается потоковая передачи сообщения, например, сразу после его помещения в буфер пересылки серверного компонента 502 электронной почты. Если при потоковой передаче сообщения появляется ошибка, то на этапе 1504 выполняется потоковая передача неисправимой ошибки ROP на клиентский компонент 501 электронной почты. Затем эта подпроцедура заканчивается. Если при потоковой передаче сообщения ошибка не появляется, то тогда на этапе 1503 определяют, есть ли еще сообщения в наборе. Если они есть, то процесс циклически возвращается к этапу 1502, где выполняется потоковая передача следующего сообщения. Если сообщений больше нет, то тогда данная подпроцедура заканчивается.

На фиг.15В показана процедура для обработки набора сообщений серверным компонентом 502 электронной почты, имеющим самую последнюю версию. Выполняемые этапы отличаются в зависимости от того, имеет ли клиентский компонент электронной почты самую последнюю версию либо предыдущую версию. Этапы 1501-1504 выполняются с клиентским компонентом электронной почты, имеющим предыдущую версию, причем эти этапы аналогичны этапам, имеющим те же ссылочные позиции в предыдущем разделе.

Если на этапе 1502 при потоковой передаче сообщения обнаружена ошибка, то тогда на этапе 1505 определяют, содержит ли запрос флаг, к примеру, FXRecoverMode. Если запрос содержит этот флаг, то тогда клиентский компонент 501 электронной почты имеет самую последнюю версию, и выполняется переход от этапа 1505 к этапу 1506, где выполняется потоковая передача FXErrorInfo на клиентский компонент 501 электронной почты. Затем процесс может продолжаться на этапе 1503. Если запрос не содержит упомянутый флаг, то тогда от этапа 1505 переходят к этапу 1504, где выполняется потоковая передача неисправимой ошибки ROP. Затем данная подпроцедура заканчивается.

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

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

Иногда сообщение или другой объект данных может иметь достаточный размер, который перекрывает множество ответов FXGetBuffer. Для обработки таких сообщений клиентский компонент 501 электронной почты может иметь логические средства возврата (rollback logic), так что он может удалить любое частично принятое сообщение, а затем перейти к правильному приему дальнейших сообщений после приема сообщения об ошибке. Иногда может понадобиться, чтобы клиентский компонент электронной почты имел обратную связь, информирующую о ходе выполнения копирования или синхронизации объектов данных, таких как сообщения электронной почты. Согласно одному аспекту настоящего изобретения клиентский компонент 501 электронной почты, имеющий самую последнюю версию, может указывать, что он способен обрабатывать режимы выполнения, например посылая флаг, такой как PROGRESS_MODE, на серверный компонент 502 электронной почты при запросе синхронизации или копирования объектов данных. В ответе серверный компонент 502 электронной почты, имеющий самую последнюю версию, может посылать вместе с сообщениями разнообразную информацию, такую как общий размер всех сообщений, общее количество сообщений и общий размер каждого сообщения, причем либо что-то одно, либо любую их комбинацию.

Например, как показано на фиг.16А, для предыдущей версии клиентского компонента 501 электронной почты в ответ на запрос (1601 и 1603) на быструю пересылку для набора сообщений клиентский компонент 501 электронной почты принимает эти сообщения. На фиг.16А сообщения принимаются в двух ответах 1604 и 1606. В клиентских компонентах 501 электронной почты, имеющих предыдущие версии, где используется механизм быстрой пересылки, индикация о ходе потоковой передачи сообщений клиенту не была предусмотрена.Однако, как показано на фиг.16В, в ответе 1607 на запрос для набора сообщений от клиентского компонента электронной почты серверный компонент 502 электронной почты может предоставить общее количество передаваемых объектов данных и общий размер всех передаваемых объектов данных. Эта информация на фиг.16В представлена как «P_all». Серверный компонент 502 электронной почты, имеющий самую последнюю версию, может также предоставить размер каждого сообщения, указанный как «P₁, P₂, P₃...» на фиг.16В. Вдобавок, если это необходимо, то информация, связанная с каждым сообщением и со всей группой сообщений в целом, может включать в себя дополнительную информацию, касающуюся того, является ли каждое сообщение информацией FAI либо действительным сообщением электронной почты. В одном варианте с целью упрощения обработки потока данных информация, представленная на фиг.16В как «P_all», посылается в ответ на запрос быстрой пересылки всегда, даже если пересылаются нулевые объекты данных.

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

IncrSyncProgressModeИмя атрибутаТип атрибутаПримечанияВерсияWORD
(например, 16-разрядное целое число)Версия данной структурыcAssocMsgsDWORD
(например, 32-разрядное целое число)Количество пересылаемых объектов данных FAI. llTotalAssocMsgSizeQWORD
(например, 64-разрядное целое число)Общий размер всех пересылаемых объектов данных FAI.IncrSyncProgressModeИмя атрибутаТип атрибутаПримечанияcNormalMsgsDWORDКоличество пересылаемых сообщений электронной почты. llTotalNormalMsgSizeQWORDОбщий размер всех пересылаемых сообщений электронной почты.

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

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

IncrSyncProgressModePerMsgИмя атрибутаТип атрибутаПримечанияРазмер сообщенияLONGРазмер следующего сообщения.Флаг FAIBOLLУказывается, если следующее сообщение представляет собой FAI.

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

На фиг.17А и 17В показаны этапы для потоковой передачи набора сообщений согласно предыдущей версии компонентов электронной почты и самой последней версии компонентов электронной почты соответственно. Этапы на фиг 17А аналогичны этапам 1501-1503 на фиг.15А. Для фиг.17В флаг PROGRESS_MODE был послан, например, с ROP клиентским компонентом 501 электронной почты, имеющим самую последнюю версию. После подготовки набора сообщений на этапе 1701 определяется присутствие указанного флага. Если флаг установлен, то тогда на этапе 1702 посылаются итоговые данные о ходе выполнения, и процесс переходит к этапу 1502, где выполняется потоковая передача первого сообщения. Если флаг отсутствует, то тогда от этапа 1701 выполняется переход непосредственно к этапу 1502.

После выполнения потоковой передачи первого сообщения процесс переходит к этапу 1703, где определяется наличие упомянутого флага. Если флаг имеется, то от этапа 1703 переходят к этапу 1704, где выполняется потоковая передача данных о ходе выполнения по каждому сообщению. Затем процесс переходит к этапу 1503, описанному ранее. Если флаг отсутствует, то от этапа 1703 переходят непосредственно к этапу 1503.

Ниже приведен пример потока данных для серверного компонента самой последней версии, посылающего данные на клиентский компонент самой последней версии. Этот поток данных аналогичен потоку данных, описанному выше, но дополнительно включает в себя теги ptags для итоговых данных о ходе выполнения (ptagIncrSyncProgressMode), которые могут иметь, например, двоичные свойства. Вдобавок, для каждого сообщения предоставляются данные о ходе выполнения по каждому сообщению, например, в виде ptagIncrSyncProgressModePerMsg.

В показанном примере теги ptags, включающие в себя итоговые данные о ходе выполнения (ptagIncrSyncProgressMode) и теги ptags для данных о ходе выполнения по каждому сообщению (ptagIncrSyncProgressModePerMsg), расположены перед списком сообщений и перед каждым сообщением соответственно. Однако структуру потоковой передачи объектов данных можно скорректировать таким образом, что данные о ходе выполнения могут находиться в сообщениях или в списке сообщений. Кроме того, можно скорректировать структуру потоковой передачи объектов данных с целью исключения тегов ptags, разграничивающих сообщения и/или списки сообщений в целом.

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

Имеется несколько наборов различных символов, которые можно использовать для запоминания сообщения электронной почты или других объектов данных. Например, самым известным из наборов, используемых для запоминания символов английского языка, является код ASCII. Однако код ASCII недостаточен для запоминания символов всех языков, поскольку он основан на 8-разрядных символах. Следовательно, код ASCII можно использовать только для 256 символов, что достаточно для английского языка, но не достаточно для языков, имеющих больше символов. С другой стороны, код Unicode представляет собой набор символов, где используется 16 битов (2 байта) на каждый символ, и, следовательно, он может включать в себя больше символов, чем ASCII. Unicode может иметь 65536 символов, и поэтому его можно использовать для кодирования почти всех языков мира. Unicode включает в себя набор символов ASCII.

В общем случае предыдущие версии клиентских компонентов 501 электронной почты имеют выделенную кодовую страницу или набор символов и/или язык, связанный с ними. Например, конкретная версия клиентского компонента 501 электронной почты может иметь кодовую страницу немецкого языка, а другая версия может иметь кодовую страницу ANSI. Иногда клиентскому компоненту 501 электронной почты возможно понадобиться принимать сообщения электронной почты в наборах символов, отличных от выделенной кодовой страницы. Согласно одному аспекту настоящего изобретения клиентский компонент, имеющий самую последнюю версию, может потребовать, чтобы серверный компонент электронной почты предоставлял все сообщения электронной почты в коде Unicode. Как только клиентский компонент 501 получит сообщения электронной почты, эти сообщения электронной почты в коде Unicode могут быть преобразованы в клиентскую кодовую страницу либо в альтернативном варианте могут быть сохранены в формате Unicode.

Для указания того, что клиентский компонент 501 электронной почты вызывает сообщения, представляемые в коде Unicode, клиентский компонент 501 электронной почты может, например, предоставить флаг, такой как FORCEUNICODE, серверному компоненту 502 электронной почты. Этот флаг может быть предоставлен с запросом, таким как ROP. Если серверный компонент 502 электронной почты имеет самую последнюю версию, то серверный компонент 502 электронной почты может передавать электронную почту по версии Unicode, если она доступна, либо может преобразовать сообщения электронной почты в других наборах символов в код Unicode.

На фиг.20 показаны этапы для предоставления конкретного набора символов для сообщения согласно одному аспекту настоящего изобретения. Сначала на этапе 2001 серверный компонент 502 электронной почты извлекает сообщение из хранилища данных. На этапе 2002 определяют, имеется ли флаг FORCEUNICODE. Если нет, то тогда от этапа 2002 переходят к этапу 2003, где серверный компонент 502 электронной почты предоставляет сообщение электронной почты в заданной кодовой странице клиентского компонента электронной почты, с преобразованием, если это необходимо.

Если флаг FORCEUNICODE присутствует, то тогда от этапа 2002 переходят к этапу 2004, где определяют, хранится ли сообщение в коде Unicode. Если это так, то от этапа 2004 переходят к этапу 2005, где клиентскому компоненту 501 электронной почты предоставляется сообщение в наборе символов Unicode. Если сообщение записано в коде, отличном от Unicode, то тогда от этапа 2004 переходят к этапу 2006, где это сообщение преобразуется в Unicode, а затем процесс переходит к этапу 2005, где клиентскому компоненту электронной почты предоставляется сообщение в коде Unicode.

Все ссылки, в том числе на указанные здесь публикации, патентные заявки и патенты, включены сюда по ссылке в равной степени, как если бы для каждой из них было специально и в отдельности указано, что она включена сюда по ссылке, и изложена здесь со всей полнотой. Использование (в английском оригинале описания) терминов «а» и «an» и «the» и аналогичных объектов ссылки в контексте описания изобретения (особенно в контексте нижеследующей формулы изобретения) должны трактоваться как в единственном, так и во множественном смысле. Термины «содержащий», «имеющий», «включающий в себя» должны трактоваться как термины, допускающие добавление (то есть, означающие «включающий в себя, но не только»), если не указано иное. Диапазоны значений в этом описании упомянуты лишь для того, чтобы иметь возможность краткого обращения к каждому отдельному значению, лежащему в данном диапазоне, если не указано иное, причем каждое отдельное значение включено в описание, как будто оно упомянуто в индивидуальном порядке. Все описанные здесь способы могут быть реализованы в любом подходящем порядке, если не указано иное либо это не противоречит контексту в других отношениях. Использование любого и всех примеров либо примерных формулировок (типа "such as" (такой как)) преследует только иллюстративные цели и ни коим образом не является ограничением объема изобретения, если не заявлено иное. Ни одна из формулировок в данном описании не должна трактоваться как указание на какой-либо не заявленный элемент, существенный для практического воплощения изобретения.

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

Изобретение относится к системе и способу для усовершенствованной связи клиента и сервера, в частности усовершенствованному протоколу, который можно использовать для связи между клиентом и сервером в среде электронной почты. Техническим результатом является улучшение связи между клиентом и сервером, в частности создание усовершенствованного протокола, который можно использовать для связи между клиентом и сервером. Сервер электронной почты может предоставить наилучшее тело сообщения, доступное для сообщения электронной почты; пересылать объект данных в целом, если запрошенное свойство или свойства не вполне определены в объекте данных; предоставлять данные о ходе выполнения для использования при слежении за ходом загрузки; посылать информацию об ошибке для объекта данных, имеющего ошибку. Изменения электронной почты можно оптимизировать на серверном компоненте электронной почты даже в том случае, если изменения электронной почты появились на другом серверном компоненте электронной почты. Сервер электронной почты может поддерживать таблицу изменений, которые появляются в папках в связанном с ними хранилище данных, и может по подписке уведомлять клиентский компонент электронной почты об изменениях, которые появились в таблице. 2 н. и 12 з.п. ф-лы, 31 ил.

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

первое поле данных, идентифицирующее клиентский компонент электронной почты;

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

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

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

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

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

в ответ на запрос и индикацию - извлечение множества объектов данных электронной почты; и

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

если клиентский компонент электронной почты не способен обрабатывать данные режима выполнения - выдачу на клиентский компонент электронной почты множества запрошенных объектов данных электронной почты (FAI).