СИСТЕМА И СПОСОБ УСОВЕРШЕНСТВОВАННОЙ СИНХРОНИЗАЦИИ МЕЖДУ СЕРВЕРОМ И КЛИЕНТОМ Российский патент 2009 года по МПК G06F13/00 H04L12/58 

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

Эта заявка на изобретение испрашивает приоритет заявки на патент США № 60/437869, зарегистрированной в досье патентного поверенного 3 января 2003 года под номером 220635, которая имеет название "SYSTEM AND METHOD FOR IMPROVED CLIENT SERVER COMMUNICATIONS" ("Система и способ усовершенствованной связи клиент-сервер") и включена сюда путем ссылки.

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

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

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

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

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

На Фиг.1 показана схема компьютеров, подключенных к сети.

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

На Фиг.3 показана схема вычислительной среды, содержащей клиентские компоненты электронной почты и серверные компоненты электронной почты множества различных версий.

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

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

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

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

На Фиг.7А приведена схема последовательности операций, на которой показан пример процедуры передачи основного содержимого ("тела") сообщения электронной почты в клиентский компонент электронной почты.

На Фиг.7Б приведена схема последовательности операций, на которой показана процедура передачи основного содержимого ("тела") сообщения электронной почты в клиентский компонент электронной почты согласно аспекту настоящего изобретения.

На Фиг.8А приведена схема последовательности передачи, на которой показан режим передачи элементов данных целиком.

На Фиг.8Б приведена схема последовательности передачи, на которой показан режим первоочередной передачи заголовков.

На Фиг.8В приведена схема последовательности передачи, на которой показан режим передачи только заголовков.

На Фиг.8Г приведена схема последовательности передачи, на которой показан режим передачи, являющийся исключением по отношению к режиму первоочередной передачи заголовков или к режиму передачи только заголовков.

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

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

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

На Фиг.11Б приведена схема последовательности операций, на которой показана процедура оптимизации части большого двоичного объекта, характеризующего состояние (stateblob) согласно настоящему изобретению.

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

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

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

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

На Фиг.15А приведена схема последовательности операций, на которой показана процедура генерации информации об ошибках на уровне ДВО.

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

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

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

На Фиг.17А приведена схема последовательности операций, на которой показана процедура потоковой передачи набора сообщений.

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

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

На Фиг.19А приведена схема последовательности операций, на которой показана процедура передачи уведомлений множеству абонентов.

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

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

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

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

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

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

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

Компьютер 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, содержащее информацию о версии клиента, например, в виде метки (отметки) версии клиентского компонента. В ответ на сообщение 403 серверный компонент 402 электронной почты посылает сообщение 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 серверный компонент 502 электронной почты осуществляет обработку каждой ДВО в надлежащем порядке, а соответствующий результат записывают в буфер 505. Каждая ДВО создает некоторый результат. Этот результат может содержать данные, запрошенные клиентским компонентом 501 электронной почты, например, определенный набор сообщений электронной почты. Серверный компонент 502 электронной почты осуществляет текущий контроль буфера 505 и в том случае, когда он почти полон (например, когда оставшийся объем памяти равен менее 8 кБ), серверный компонент 502 электронной почты записывает любые необработанные ДВО в конец буфера 505 и осуществляет передачу содержимого буфера 505 в буфер 506. После этого клиентский компонент 501 электронной почты начинает новый цикл запросов-ответов путем записи необработанных ДВО в буфер 503 для их повторной подачи в серверный компонент 502 электронной почты в тот момент, когда снова произойдет заполнение буфера 503.

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

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

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

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

Понятно, что ДВО, изображенные на Фиг.6А и Фиг.6Б и на всех аналогичных чертежах в данной заявке на изобретение, показаны схематично, то есть они могут быть реализованы на практике в виде последовательности ДВО, если иной вариант не оговорен особо.

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

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

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

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

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

В сети электронной почты одной из типичных задач протокола является обеспечение передачи объектов данных, например, сообщений электронной почты, между клиентскими компонентами электронной почты и серверными компонентами электронной почты. Другими примерами таких объектов данных являются папки электронной почты, которые могут содержать сообщения электронной почты и иные объекты данных, а также объекты данных, представляющие собой информацию, связанную с папками (ИСП) (FAI), которая может, например, содержать правила обработки сообщений электронной почты или определять то, каким образом будут отображены объекты данных, содержащиеся в папке. Объекты данных могут быть "непрозрачными" по отношению к клиентскому компоненту электронной почты; то есть, в клиентском компоненте электронной почты может отсутствовать какое-либо средство интерпретации содержимого объекта данных. В альтернативном варианте объекты данных могут содержать именованные свойства, например, сообщение электронной почты может содержать признаки, имеющие наименования "кому", "от кого", "тема", "важность", " основное содержимое 1", "основное содержимое 2", "основное содержимое 3", "вложение 1", "вложение 2" и так далее.

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

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

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

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

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

На Фиг.7Б показана часть процедуры, используемой в серверном компоненте электронной почты наиболее новой версии согласно настоящему изобретению. На этапе 704 осуществляют анализ протокольного запроса, приводящего к выполнению этой подпрограммы, используемой серверным компонентом электронной почты, на наличие флага НАИЛУЧШИЙ_ВАРИАНТ_ОСНОВНОГО_СОДЕРЖИМОГО (BEST_BODY). Флаг из этого примера и иные используемые здесь флаги применяют для того, чтобы серверный компонент электронной почты получил сведения о том, что клиентский компонент электронной почты является компонентом наиболее новой версии и желает выполнить функцию, соответствующую флагу. Также могут быть использованы и другие способы оповещения. Например, в случае обнаружения клиентского компонента электронной почты наиболее новой версии функция может быть выполнена по умолчанию.

В любом случае, если флаг НАИЛУЧШИЙ_ВАРИАНТ_ОСНОВНОГО_СОДЕРЖИМОГО (BEST_BODY) не обнаружен, то на этапе 704 выполняют переход к этапу 701 и продолжают процедуру так, как указано в описании Фиг.7А.

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

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

ДВО могут быть использованы для обеспечения дублирования папок электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты. Запрос на синхронизацию папки может быть выдан, например, посредством ДВО СинхронизироватьПапку (SynchFolder). В тех случаях, когда клиентский компонент электронной почты способен осуществлять визуальное отображение нестандартных форматов основного содержимого сообщения электронной почты, в ДВО СинхронизироватьПапку (SynchFolder) может быть установлен флаг НАИЛУЧШИЙ_ВАРИАНТ_ОСНОВНОГО_СОДЕРЖИМОГО (BEST_BODY), указывающий, что серверный компонент электронной почты может выбрать наилучший формат из доступных вариантов основного содержимого сообщения электронной почты вместо того, чтобы посылать в сервер запрос на возврат основного содержимого сообщения электронной почты в стандартном формате. Серверный компонент электронной почты может осуществлять надлежащую обработку ДВО как с наличием флага НАИЛУЧШИЙ_ВАРИАНТ_ОСНОВНОГО_СОДЕРЖИМОГО (BEST_BODY), так и без него, за счет всего лишь незначительного его усложнения. Для обеспечения обмена данными с серверами предыдущих версий и наиболее новых версий ДВО могут содержать, например, параметры, указанные в приведенной ниже таблице:

 ДВО, которая может быть использована в протоколе для связи с серверами предыдущих версийДВО, которая может быть использована в протоколе для связи с серверами наиболее новых версийИдентификатор ДВО (ROP ID)СинхронизироватьПапку (SynchFolder)СинхронизироватьПапку (SynchFolder)Новые параметрыНе доступныФлаг
НАИЛУЧШИЙ_ВАРИАНТ_ ОСНОВНОГО_СОДЕРЖИМОГО (BEST_BODY): при его установке серверный компонент электронной почты выбирает наилучший вариант основного содержимого сообщения электронной почты для его передачи в клиентский компонент электронной почты. Отсутствует необходимость в преобразовании основного содержимого сообщения электронной почты в заранее заданный стандартный формат.

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

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

Примером одного из способов реализации этого аспекта настоящего изобретения является использование флага, например, флага ИГНОРИРОВАТЬ_РЕЖИМ_ПО_НАЛИЧИЮ_ИСП (IGNORE_MODE_ON_FAI), который может входить в состав ДВО синхронизации, например, вышеописанной ДВО СинхронизироватьПапку (SynchFolder). Серверный компонент электронной почты может осуществлять надлежащую обработку ДВО как при наличии флага ИГНОРИРОВАТЬ_РЕЖИМ_ПО_НАЛИЧИЮ_ИСП (IGNORE_MODE_ON_FAI), так и без него, за счет всего лишь незначительного его усложнения. Для обеспечения дублирования папки электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты ДВО могут содержать параметры, указанные в приведенной ниже таблице:

 ДВО, которая может быть использована в протоколе для связи с серверами предыдущих версийДВО, которая может быть использована в протоколе для связи с серверами наиболее новых версийИдентификатор ДВО (ROP ID)СинхронизироватьПапку (SynchFolder)СинхронизироватьПапку (SynchFolder)Новые параметрыНе доступныФлаг
ИГНОРИРОВАТЬ_ РЕЖИМ_ПО_НАЛИЧИЮ_ИСП (IGNORE_MODE_ON_FAI): при его установке для информационных объектов, например, ИСП, не содержащих строго определенного набора именованных свойств заголовка и/или основного содержимого, серверный компонент электронной почты может отвечать на запрос на выполнение передачи путем передачи всего информационного объекта целиком вне зависимости от существующего режима передачи.

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

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

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

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

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

На Фиг.10 более подробно показан пример протокола, обеспечивающего возможность инкрементного дублирования. Хранилище для сообщений электронной почты может быть подразделено на папки электронной почты. Дублирование каждой папки электронной почты может быть осуществлено независимо от других, что обеспечивает более тонкое управление процессом дублирования. В этом примере процесс инкрементного дублирования именуют синхронизацией, поскольку он содержит операцию передачи изменений из клиентского компонента 501 электронной почты в серверный компонент 502 электронной почты, а также из серверного компонента 502 электронной почты в клиентский компонент 501 электронной почты. После получения запроса 1001 на выполнение синхронизации серверный компонент 502 электронной почты выполняет обработку ДВО СинхронизироватьПапку (SynchFolder). Эта ДВО содержит параметр ИДпапки (идентификатор папки (folderID)) (на чертеже не показан) и параметр большой_двоичный_объект_характеризующий_состояние0 (stateblob0). Параметр ИДпапки (folderID) идентифицирует папку электронной почты, которая является целевой для запроса 1001 на выполнение синхронизации. Параметр большой_двоичный_объект_характеризующий_состояние0 (stateblob0) содержит информацию, позволяющую серверному компоненту 502 электронной почты определить то, произошли ли изменения в папке электронной почты со времени выполнения ее последней синхронизации и какие именно. Если запрос 1001 представляет собой самый первый запрос на выполнение клиентским компонентом 501 электронной почты синхронизации целевой папки, то серверный компонент 502 электронной почты определяет, произошло ли изменение целевой папки электронной почты в хранилище для сообщений электронной почты по сравнению с пустой папкой. В качестве ответа 1002 на запрос 1001 серверный компонент 502 электронной почты передает сведения о любых изменениях в клиентском компоненте 501 электронной почты, включая любые сообщения электронной почты и/или иные объекты данных, добавленные в целевую папку, и перечень любых сообщений электронной почты и/или иных объектов данных, удаленных из целевой папки. Серверный компонент 502 электронной почты также создает новый параметр большой_двоичный_объект_характеризующий_состояние1 (stateblob1), отображающий состояние целевой папки в клиентском компоненте 501 электронной почты непосредственно после выполнения синхронизации, а также осуществляет передачу этого параметра большой_двоичный_объект_характеризующий_состояние1 (stateblob1) в ответе 1002. Когда клиентский компонент 501 электронной почты посылает следующий запрос 1003 на выполнение синхронизации той же самой папки, что и в запросе 1001, то запрос 1003 будет содержать в качестве параметра тот же самый большой_двоичный_объект_характеризующий_состояние1 (stateblob1), который был возвращен в ответе 1002. Как и ранее, серверный компонент 502 электронной почты использует информацию, содержащуюся в параметре большой_двоичный_объект_характеризующий_состояние1 (stateblob1), для определения того, произошли ли изменения в целевой папке и какие именно, и осуществляет передачу сведений об этих изменениях вместе с вновь созданным параметром большой_двоичный_объект_характеризующий_состояние2 (stateblob2) обратно в клиентский компонент 501 электронной почты в ответе 1004.

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

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

Для целей обсуждения, объект данных ИДизменения сообщения (message changeID) может быть представлен, например, как "S₁:1", где 'S₁' представляет собой объект данных ИДсервера (serverID) для первого серверного компонента электронной почты, а '1' представляет собой порядковый номер. Набор объектов данных ИДизменения сообщения (message changeID) может быть представлен, например, как "S₁:1, S₁:2, S₁:3", где "S₁:1", "S₁:2" и "S₁:3" являются последовательными объектами данных ИДизменения сообщения (message changeID), которые использует серверный компонент электронной почты, имеющий ИДсервера (serverID), равный S₁.

Для тех случаев, в которых большой двоичный объект, характеризующий состояние, состоит, в основном, из набора объектов данных ИДизменения сообщения (message changeID), отображающих изменения сообщения электронной почты, замеченные клиентским компонентом электронной почты (набор "Замеченные Изменения Сообщения"), было разработано несколько способов кодирования этого набора для уменьшения его объема, например, набор "S₁:1, S₁:2, S₁:3, S₁:4" может быть закодирован как "S1:1-4". Кроме того, серверный компонент электронной почты может гарантировать то, что используемые им порядковые номера всегда увеличиваются. В этом случае независимый набор "Замеченные Изменения Сообщения", например, "S₁:1, S₁:3, S₁:5, S₁:7", может быть закодирован как "S₁:1-7", то есть как интервал, включающий минимальный порядковый номер и максимальный порядковый номер, без потери функциональных возможностей.

В сценарии, изображенном на Фиг.9, набор "Замеченные Изменения Сообщения" может содержать иные объекты данных типа ИДизменения сообщения (message changeID), созданные серверными компонентами электронной почты (например, S₁, S₂), нежели те, которые созданы текущим базовым сервером (например, S₃). Объект данных ИДизменения сообщения (message changeID), созданный текущим базовым сервером, может быть назван собственным объектом данных ИДизменения сообщения (message changeID), а объект данных ИДизменения сообщения (message changeID), созданный другими серверными компонентами электронной почты, может быть назван чужим объектом данных ИДизменения сообщения (message changeID). Протоколы сети электронной почты, обеспечивающие обмен информацией с серверными компонентами электронной почты предыдущих версий, не обеспечивают оптимизацию чужих независимых последовательностей объектов данных «ИДизменения сообщения» (message 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,_{S1:3,S1:5,S1:7
S2:1,S2:3,S2:5,S2:7
S3:1-7}S₁:1-7
S₂:1-7
S₃:1-7

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

 Результат ДВО, который может быть использован в протоколе при обмене информацией с серверами предыдущих версийРезультат ДВО, который может быть использован в протоколе при обмене информацией с серверами наиболее новых версийИдентификатор ДВО (ROP ID)СинхронизироватьПапку (SynchFolder)СинхронизироватьПапку (SynchFolder)Неизменные параметры, используемые в новом режимебольшой двоичный объект, характеризующий состояние: оптимизация, при которой оптимизацию независимых наборов чужих информационных объектов типа ИДизменения сообщения (message changeID) не производят.большой двоичный объект, характеризующий состояние: усовершенствованная оптимизация, в том числе, независимых наборов чужих информационных объектов типа ИДизменения сообщения (message changeID).

На Фиг.11А и Фиг.11Б показано различие между подпрограммой, которая может быть использована, соответственно, в сервере предыдущей версии и в сервере наиболее новой версии для ответа на ДВО СинхронизироватьПапку (SynchFolder). На Фиг.11А показаны этапы 1101, 1102 и 1103. При выполнении этапа 1101 создают исходный набор "Замеченные Изменения Сообщения". На этапе 1102 осуществляют оптимизацию элементов набора "Замеченные Изменения Сообщения", представляющие собой собственные объекты данных ИДизменения сообщения (message changeID). На этапе 1103 оптимизированный набор "Замеченные Изменения Сообщения" добавляют к объекту данных, представляющему собой большой двоичный объект, характеризующий состояние, который может быть передан вместе с ответом в клиентский компонент электронной почты, выдавший запрос на выполнение синхронизации. Фиг.11Б содержит дополнительный этап 1104, на котором показано, что также осуществляют оптимизацию тех элементов набора "Замеченные Изменения Сообщения", которые являются чужими объектами данных ИДизменения сообщения (message changeID), и которую выполняют перед этапом 1103, при которой набор "Замеченные Изменения Сообщения", подвергнутого теперь усовершенствованной оптимизации, добавляют к объекту данных, представляющему собой большой двоичный объект, характеризующий состояние.

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

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

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

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

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

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

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

На Фиг.13 показан вариант осуществления изобретения, предотвращающий такие результаты "нулевой синхронизации" за счет использования таблицы глубокой иерархии. В первом запросе 1301 клиентский компонент 501 электронной почты осуществляет передачу в серверный компонент 502 электронной почты ДВО (например, ПолучитьТаблицуИерархическойСтруктуры (GetHierarchyTable)), запрашивающей получение таблицы глубокой иерархии. В первом ответе 1302 осуществляют передачу копии таблицы глубокой иерархии в клиентский компонент 501 электронной почты. Как правило, клиентский компонент 501 электронной почты содержит предыдущую копию таблицы глубокой иерархии. Клиентский компонент 501 электронной почты может быстро определить то, какие именно папки, содержащиеся в хранилище сообщений электронной почты пользователя в серверном компоненте 502 электронной почты, были подвергнуты изменению путем использования последовательного построчного сравнения строк двух копий. Затем осуществляют синхронизацию только тех папок, в которых произошли изменения, с использованием ДВО (например, СинхронизироватьПапку (SynchFolder)). При необходимости, запрос 1303 и ответ 1304 могут быть повторены для обеспечения синхронизации измененных папок. После успешного выполнения синхронизации может быть выполнено обновление копии таблицы глубокой иерархии в клиентском компоненте электронной почты таким образом, чтобы она соответствовала самой новой копии, переданной в ответе 1302. Если в клиентском компоненте 501 электронной почты отсутствует предыдущая копия таблицы глубокой иерархии, то может быть выполнена синхронизация всех папок, имеющих строку в самой новой копии.

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

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

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

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

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

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

На Фиг.19А показан режим передачи уведомлений, который может быть обеспечен серверными компонентами электронной почты предыдущих версий. На Фиг.19Б показан режим передачи уведомлений с перестраиваемой конфигурацией согласно одному из аспектов настоящего изобретения. При необходимости клиентский компонент электронной почты наиболее новой версии может указать серверному компоненту электронной почты, что он способен перейти в режим передачи уведомлений, показанный на Фиг.19Б, например, путем передачи вместе с запросом флага, которым в примере, показанном на Фиг.19Б, является флаг ИГНОРИРОВАТЬ_СОБСТВЕННЫЙ (IGNORE_OWN).

На этапе 1901 производят выбор следующего возможного абонента из набора подписавшихся абонентов, которым передают уведомления. На этапе 1904 производят анализ подписки на наличие флага ИГНОРИРОВАТЬ_СОБСТВЕННЫЙ (IGNORE_OWN). Если флаг отсутствует, то на этапе 1904 переходят к этапу 1902, на котором осуществляют передачу уведомления абоненту, претендующему на его получение (кандидату). Если флаг обнаружен, то от этапа 1904 переходят к этапу 1905, на котором снова производят анализ подписки для определения того, действительно ли это уведомление инициировано данным абонентом. Эта операция определения может быть выполнена, например, путем анализа идентификатора сеанса связи ("ИДсеанса" ("sessionID")), соответствующего тому сеансу связи, который был использован для размещения подписки. Идентификатор "ИДсеанса" ("sessionID") может содержать, например, глобально уникальный идентификатор и шестибайтовый порядковый номер. Уведомление также анализируют на соответствие идентификатора "ИДсеанса" ("sessionID") инициатору уведомления. Если эти два идентификатора совпадают, то передачу уведомления не производят. Это приводит к тому, что клиентский компонент электронной почты, инициировавший уведомление, также не получит это уведомление. Затем в подпрограмме переходят к выполнению этапа 1903, описание которого приведено ниже.

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

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

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

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

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

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

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

В приведенной ниже таблице показан пример формата, который может иметь ИнформацияОбОшибкеВП (FXErrorInfo):

ИнформацияОбОшибкеВП (FXErrorInfo)Наименование атрибутаТип атрибутаПримечанияВерсияСЛОВО (WORD)Версия этой структуры.Код ошибкиСЛОВО УДВОЕННОЙ ДЛИНЫ (DWORD) Идентификатор сообщенияИДС (MID)Тип идентификатора сообщения (ИДС) содержит глобально уникальный идентификатор (GUID) и шестибайтовый порядковый номер. Он представляет собой идентификатор сообщения, вызвавшего ошибку... Сюда может быть добавлено ноль или большее количество атрибутов.Длина вспомогательного поляULONGОбъем следующего массиваВспомогательное полеМассив типа БАЙТ (BYTE)Неструктурированный массив для передачи подробных данных об ошибке.

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

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

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

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

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

ptagMessageListStart (тег свойств начала перечня сообщений)

ptagMessageStart (тег свойств начала сообщения)

ptagPropList (тег свойств списка свойств)

ptagSubject [PT_STRING] (тег свойств темы [ПРИЗНАК_СТРОКА])

"Re: Your email" ("Ответ: Ваша электронная почта")

...

ptagMessageEnd (тег свойств конца сообщения)

ptagMessageStart (тег свойств начала сообщения)

...

ptagFXErrorInfo [PT_BINARY]

(тег свойств ИнформацияОбОшибкеВП [ПРИЗНАК_БИНАРНЫЙ])

[Содержимое описано в таблице]

ptagMessageStart (тег свойств начала сообщения)

...

ptagMessageEnd (тег свойств конца сообщения)

ptagMessageListEnd (тег свойств конца перечня сообщений)

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

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

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

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

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

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

Иногда может оказаться желательным, чтобы клиентскому компоненту электронной почты были предоставлены данные обратной связи о ходе выполнения операции копирования или синхронизации объектов данных, например, сообщений электронной почты. Согласно одному из аспектов настоящего изобретения, клиентский компонент 501 электронной почты наиболее новой версии может указывать, что он способен осуществлять обработку в режимах индикации хода выполнения операции, например, путем передачи в серверный компонент 502 электронной почты флага, например, РЕЖИМ_ИНДИКАЦИИ_ХОДА_ВЫПОЛНЕНИЯ (PROGRESS_MODE), при запросе синхронизации или копирования объектов данных. В ответ серверный компонент 502 электронной почты наиболее новой версии может передавать вместе с сообщениями разнообразную информацию, например, данные об общем объеме всех сообщений, об общем количестве сообщений и об общем объеме каждого сообщения, либо какие-либо одни из этих данных, либо любую их совокупность.

Например, как показано на Фиг.16А, для клиентского компонента 501 электронной почты предыдущей версии, в ответ на запрос (1601 и 1603) на выполнение быстрой передачи набора сообщений клиентский компонент 501 электронной почты принимает сообщения. Как показано на Фиг.16А, сообщения получают в виде двух ответов 1604 и 1606. В клиентских компонентах 501 электронной почты предыдущих версий, использующих способ быстрой передачи, индикатор хода выполнения операции потоковой передачи сообщений клиенту отсутствует.

Однако, как показано на Фиг.16Б, в ответе 1607 на выданный клиентским компонентом электронной почты запрос на получение набора сообщений серверный компонент 502 электронной почты может предоставлять данные об общем количестве передаваемых объектов данных и об общем объеме всех передаваемых объектов данных. Эта информация изображена на Фиг.16Б как "P_общ" (P_all). Серверный компонент 502 электронной почты наиболее новой версии может также предоставлять данные об объеме каждого сообщения, которые обозначены на Фиг.16Б как "P₁, P₂, P₃, ...". Кроме того, при необходимости, информация, соответствующая каждому сообщению и всей группе сообщений, может содержать дополнительную информацию о том, является ли каждое сообщение информацией, связанной с папками, (ИСП) или действительно представляет собой сообщение электронной почты. В одном из вариантов осуществления изобретения в ответ на запрос на выполнение быстрой передачи всегда осуществляют передачу информации, изображенной на Фиг.16Б как "P_общ" (P_all), даже в случае передачи нулевых объектов данных, что обеспечивает упрощение обработки потока данных.

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

IncrSyncProgressMode
(Приращение при синхронизации в режиме индикации хода выполнения передачи)Наименование атрибутаТип атрибутаПримечанияВерсияСЛОВО (WORD)
(например, 16-битовое целое число)Версия этой структурыcAssocMsgsСЛОВО УДВОЕННОЙ ДЛИНЫ (DWORD)
(например, 32-битовое целое число)Количество передаваемых объектов данных ИСПIITotalAssocMsgSizeСЛОВО УЧЕТВЕРЕННОЙ ДЛИНЫ (QWORD)
(например, 64-битовое целое число)Общий объем всех передаваемых объектов данных ИСПcNormalMsgsСЛОВО УДВОЕННОЙ ДЛИНЫ (DWORD)Количество передаваемых сообщений электронной почтыIITotalNormalMsgSizeСЛОВО УЧЕТВЕРЕННОЙ ДЛИНЫ (QWORD)Общий объем всех передаваемых сообщений электронной почты.

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

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

IncrSyncProgressModePerMsg
(Приращение при синхронизации в режиме индикации хода выполнения передачи сообщения)Наименование атрибутаТип атрибутаПримечанияОбъем сообщенияДЛИНА (LONG)Объем следующего сообщенияФлаг ИСПЛОГИЧЕСКИЙ (BOOL)Указывает, является ли следующее сообщение ИСП.

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

На Фиг.17А и Фиг.17Б показаны операции потоковой передачи набора сообщений, соответственно, для компонентов электронной почты предыдущих версий и компонентов электронной почты наиболее новой версии. Операции, показанные на Фиг.17А, аналогичны операциям 1501-1503 из Фиг.15А. На Фиг.17Б клиентским компонентом 501 электронной почты наиболее новой версии передан флаг РЕЖИМ_ИНДИКАЦИИ_ХОДА_ВЫПОЛНЕНИЯ (PROGRESS_MODE), например, вместе с ДВО. После того, как выполнена подготовка набора сообщений, на этапе 1701 определяют наличие флага. В случае его наличия выполняют этап 1702, при котором осуществляют передачу данных о ходе выполнения всей операции передачи, после чего переходят к выполнению этапа 1502, на котором осуществляют потоковую передачу первого сообщения. Если флаг отсутствует, то от этапа 1701 выполняют переход непосредственно к этапу 1502.

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

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

PtagIncrSyncProgressMode [PT_BINARY]

[Содержимое описано в таблице]

ptagMessageListStart

PtagIncrSyncProgressModePerMsg [PT_BINARY]

[Содержимое описано в таблице]

ptagMessageStart

ptagPropList

ptagSubject [PT_STRING]

"Ответ: Ваша электронная почта"("Re: Your email")

...

ptagMessageEnd

PtagIncrSyncProgressModePerMsg [PT_BINARY]

[Содержимое описано в таблице]

ptagMessageStart

...

ptagMessageEnd

PtagIncrSyncProgressModePerMsg [PT_BINARY]

[Содержимое описано в таблице]

ptagMessageStart

...

ptagMessageEnd

ptagMessageListEnd

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

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

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

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

Для указания того, что клиентский компонент 501 электронной почты требует предоставления сообщений электронной почты в формате Уникод, клиентский компонент 501 электронной почты может, например, осуществлять передачу флага в серверный компонент 502 электронной почты, например, флага ПРИНУДИТЕЛЬНАЯ_ПЕРЕДАЧА_В_ФОРМАТЕ_УНИКОД (FORCEUNICODE). Передача флага может быть осуществлена вместе с запросом, которым является, например, ДВО. Если серверный компонент 502 электронной почты является компонентом наиболее новой версии, то серверный компонент 502 электронной почты может осуществлять передачу сообщений электронной почты в формате Уникод при наличии таких сообщений, или может осуществлять преобразование сообщений электронной почты из других наборов символов в Уникод.

На Фиг.20 показаны этапы предоставления конкретного набора символов для сообщения согласно одному из аспектов настоящего изобретения. Процедуру начинают с этапа 2001, на котором серверный компонент 502 электронной почты извлекает сообщение из своего запоминающего устройства данных. На этапе 2002 определяют наличие флага ПРИНУДИТЕЛЬНАЯ_ПЕРЕДАЧА_В_ФОРМАТЕ_УНИКОД (FORCEUNICODE). Если он отсутствует, то от этапа 2002 выполняют переход к этапу 2003, на котором серверный компонент 502 электронной почты предоставляет сообщение электронной почты в формате заданной кодовой страницы клиентского компонента электронной почты, при необходимости осуществляя его преобразование.

В случае наличия флага ПРИНУДИТЕЛЬНАЯ_ПЕРЕДАЧА_В_ФОРМАТЕ_УНИКОД (FORCEUNICODE) от этапа 2002 выполняют переход к этапу 2004, на котором определяют, действительно ли сообщение запомнено в формате Уникод. Если это так, то на этапе 2004 выполняют переход к этапу 2005, на котором осуществляют передачу сообщения в клиентский компонент 501 электронной почты в виде набора символов Уникода. Если сообщение сохранено не в формате Уникод, то на этапе 2004 выполняют переход к этапу 2006, на котором осуществляют преобразование сообщения в Уникод, а затем переходят к этапу 2005, на котором осуществляют передачу сообщения в клиентский компонент электронной почты в формате Уникод.

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

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

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

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

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

осуществляют подписку на получение таблицы, относящейся к

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

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

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