MXPA03011674A

MXPA03011674A - Metodo para conducir datos entre un servidor y un cliente.

Info

Publication number: MXPA03011674A
Application number: MXPA03011674A
Authority: MX
Inventors: Eric Gray Ronald
Original assignee: Microsoft Corp
Priority date: 2003-01-03
Filing date: 2003-12-16
Publication date: 2005-02-25
Also published as: KR20040062891A; JP4438989B2; CA2452527A1; US7620688B2; KR101021385B1; EP1631024B1; AU2003268611B2; AU2003268611A1; MY137065A; EP1631024A3; DE60335218D1; RU2331920C2; EP1631025A2; CN100433733C; JP2004215279A; EP1631025B9; CA2841691A1; CA2452527C; CN1518304A; TW200421802A

Abstract

Un sistema y metodo para comunicaciones mejoradas entre cliente y servidor, mas particularmente, un protocolo mejorado que puede ser usado para la comunicacion entre un cliente y un servidor, tales como en un ambiente de correo electronico. Se proporcionan muchas funciones para las comunicaciones mejoradas. Un servidor de correo electronico puede proporcionar el mejor cuerpo de mensaje disponible para un mensaje de correo electronico, puede transferir un objeto de datos entero si la propiedad o propiedades solicitadas no estan bien definidas dentro del objeto de datos, puede proporcionar datos de avance para su uso al rastrear el avance de la descarga, y puede enviar informacion de error para un objeto de datos que tiene un error. Los cambios de correo electronico pueden optimizarse en un componente de servidor de correo electronico, aun si los cambios de correo electronico ocurrieron en otro componente de servidor de correo electronico. Un servidor de correo electronico puede mantener una tabla de cambios que ocurren en carpetas en un almacen de datos asociado, y puede notificar a un componente de cliente de correo electronico suscrito de los cambios que ocurren en la tabla.

Description

MÉTODO PARA CONDUCIR DATOS ENTRE UN SERVIDOR Y UN CLIENTE Referencia a la Solicitud Relacionada Esta solicitud reclama el beneficio de la solicitud de Patente de los Estados Unidos de Norteamérica 60/437,869, con número de expediente interno 220635, presentada el 3 de enero de 2003, titulada "SISTEMA Y MÉTODO PARA COMUNICACIONES DE SERVIDOR CLIENTE MEJORADAS", e incorporadas en la presente mediante referencia. Campo de la Invención Esta invención es pertinente en general a redes de computadoras, y más particularmente, a los métodos para comunicarse entre aplicaciones de cliente y servidor tales como aplicaciones de correo electrónico. Antecedentes de la Invención El correo electrónico se ha vuelto un método importante para comunicación. Los sistemas de correo electrónico típicamente incluyen un componente servidor (por ejemplo, Microsoft Exchange Server) y un componente cliente (por ejemplo, Microsoft Outlook o Microsoft Outlook Express) . Estos componentes típicamente son aplicaciones de software que se configuran para ejecutarse en dispositivos de computación (por ejemplo, servidores, computadoras personales, laptops, y PDAs) . Frecuentemente, con el fin de facilitar las comunicaciones, un cliente y un servidor, tales como el componente cliente y un componente servidor de un sistema de correo electrónico, acuerdan un protocolo de comunicaciones. El protocolo establece las reglas definiendo el comportamiento esperado de cada parte durante las comunicaciones, por ejemplo, la secuencia esperada de solicitud y respuesta. Protocolos sofisticados tienen reglas para manejar el comportamiento inesperado. Conforme mejoran los componentes de cliente y servidor, las versiones mejoradas se distribuyen a los usuarios finales. Con el fin de aprovechar las nuevas características de los componentes y las nuevas características de la red, frecuentemente se necesita inventar un protocolo nuevo de comunicaciones . Cuando la base instalada de los componentes de servidor es significativa, un componente cliente puede tener la capacidad de comunicarse, vía un conjunto de protocolos, con versiones previas seleccionadas de componentes de servidor. Frecuentemente es el caso que los últimos protocolos construidos pueden construirse sobre protocolos anteriores en vez de reemplazarlos completamente. En este caso, el último protocolo puede construirse a partir de elementos de protocolo que pueden habilitarse o deshabilitarse con el fin de simular los protocolos anteriores. Igualmente, cuando la base instalada de los componentes de cliente es significativa, un componente de servidor puede tener la capacidad de comunicarse, vía un protocolo, con versiones previas seleccionadas de los componentes del cliente. La invención proporciona un sistema y método asi. Estas y otras ventajas de la invención, asi como las características inventivas adicionales, serán aparentes a partir de la descripción de la invención proporcionada en la presente . Compendio de la Invención La presente invención proporciona un sistema y método para comunicaciones mejoradas de cliente y servidor. Más particularmente, la invención se dirige a un protocolo mejorado que puede ser usado para la comunicación entre un cliente y un servidor. La invención tiene relevancia particular en un ambiente de servidor de correo electrónico, pero las características descritas en la presente se pueden utilizar en otras redes de cliente servidor. De acuerdo con un aspecto de la presente invención, un componente de servidor de correo electrónico puede someter información de error para un objeto de datos que tiene un error en vez de fallar un conjunto entero de respuestas debido a un error en una. El componente de servidor de correo electrónico puede recibir, de un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar un objeto de datos de correo electrónico que tiene un error. Como respuesta a la solicitud y la indicación, el componente de servidor de correo electrónico puede recuperar la pluralidad de objetos de datos de correo electrónico, y, para cada uno de los objetos de datos de correo electrónico, si no se presenta error al abrir el objeto de datos de correo electrónico, transmitir el objeto de datos de correo electrónico al componente de cliente de correo electrónico. Sin embargo, si se presenta un error al abrir el objeto de datos de correo electrónico, el componente de servidor de correo electrónico transmite un mensaje de error al componente de cliente de correo electrónico. De conformidad con otro aspecto de la presente invención, un componente de servidor de correo electrónico puede proporcionar datos de avance a un componente de cliente de correo electrónico de manera que el componente de cliente de correo electrónico puede rastrear el avance de una descarga desde el componente de servidor de correo electrónico. El componente de cliente de correo electrónico envía una solicitud de una pluralidad de objetos de datos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar los datos en modo avance. Como respuesta a la solicitud y a la indicación, el componente de servidor de correo electrónico recupera la pluralidad de objetos de datos de correo electrónico, y proporciona datos en modo de avance al componente de cliente de correo electrónico junto con la pluralidad de objetos de datos. Los datos en modo de avance pueden incluir un tamaño de la pluralidad de objetos de datos de correo electrónico, el tamaño de cada uno de los objetos, el número de los objetos, si los objetos son información asociada con loas carpetas, información adicional, o cualquier combinación de estos puntos. De conformidad con todavía otro aspecto de la presente invención, una solicitud enviada por un componente de cliente de correo electrónico puede indicar que no hay límite para el tamaño de una respuesta a la solicitud, permitiendo que el componente de servidor de correo electrónico llene una memoria intermedia, si es necesario. El componente de cliente de correo electrónico envía una pluralidad de subsolicitudes dentro de una solicitud, cada una de las subsolicitudes solicitando una operación a un componente de servidor de correo electrónico y que incluye información de tamaño. Como respuesta a cada subsolicitud, si la información de tamaño incluye un límite de tamaño dentro de un rango esperado por el componente de servidor de correo electrónico, entonces el componente de servidor de correo electrónico limita una respuesta al límite de tamaño. Si la información de tamaño incluye un límite de tamaño fuera de un rango esperado por el componente de servidor de correo electrónico, entonces el componente de servidor de correo electrónico busca un nuevo límite de tamaño en la información del tamaño. El nuevo límite de tamaño puede ser arbitrario, tal como "llenar la memoria intermedia disponible". Breve Descripción de los Dibujos La Figura 1 es un diagrama esquemático de computadoras conectadas por una red. La Figura 2 es un diagrama esquemático que ilustra un sistema de computadora ejemplar utilizable para implementar una modalidad de la invención. La Figura 3 es un diagrama esquemático que representa un ambiente con múltiples versiones tanto de componentes de cliente de correo electrónico como de componentes de servidor de correo electrónico. La Figura 4 es un diagrama de protocolo que muestra un ejemplo de un procedimiento de negociación de protocolo entre un componente de cliente de correo electrónico y un componente de servidor de correo electrónico. La Figura 5 es un diagrama esquemático que muestra una red de correo electrónico ejemplar en la cual los componentes de cliente de correo electrónico y los componentes de servidor de correo electrónico tienen memorias intermedias de comunicación de tamaño fijo. La Figura 6A es un diagrama de protocolo que muestra un protocolo de ejemplo que requiere dos ciclos de solicitud-respuesta para completar una operación de transferencia rápida. La Figura 6B es un diagrama de protocolo que muestra un protocolo de ejemplo que requiere un solo ciclo de solicitud-respuesta para completar una operación de transferencia rápida. La Figura 7A es un diagrama de flujo que representa un procedimiento de ejemplo para enviar un cuerpo de mensaje de correo electrónico a un componente de cliente de correo electrónico . La Figura 7B es un diagrama de flujo que representa un procedimiento para enviar un cuerpo de mensaje de correo electrónico a un componente de cliente de correo electrónico de acuerdo con un aspecto de la presente invención. La Figura 8A es un diagrama en secuencia que ilustra un modo de transferencia de articulo completo. La Figura 8B es un diagrama en secuencia que ilustra un modo de transferencia de primero encabezados. La Figura 8C es un diagrama en secuencia que ilustra un modo de transferencia de solamente encabezados. La Figura 8D es un diagrama en secuencias que ilustra una excepción a un modo de transferencia de primero encabezados o sólo encabezados. La Figura 9 es un diagrama esquemático que muestra un componente de servidor de correo electrónico en el hogar del componente de cliente de correo electrónico que cambia en el tiempo. La Figura 10 es un diagrama de protocolo que muestra un protocolo de ejemplo para sincronizar carpetas de correo electrónico entre un componente de cliente de correo electrónico y un componente de servidor de correo electrónico . La Figura 11A es un diagrama de flujo que representa un procedimiento de ejemplo para optimizar parte de un stateblob. La Figura 11B es un diagrama de flujo que representa un procedimiento para optimizar parte de un stateblob de acuerdo con la presente invención. La Figura 12 es un diagrama esquemático que ilustra una jerarquía de carpetas de correo electrónico. La Figura 13 es un diagrama de protocolo que muestra un protocolo de ejemplo para sincronizar y mantener la sincronización de un almacén de mensajes de correo electrónico de acuerdo con un aspecto de la presente invención . La Figura 14A es un diagrama de protocolo que muestra un protocolo de ejemplo para comunicar información de error a nivel operación remota (ROP) . La Figura 14B es un diagrama de protocolo que muestra un protocolo de ejemplo para comunicar información de error en una base por mensaje de acuerdo con un aspecto de la presente invención. La Figura 15A es un diagrama de flujo que representa un procedimiento para generar información de error a nivel ROP. La Figura 15B es un diagrama de flujo que representa un procedimiento para generar información de error en una base por mensaje de acuerdo con un aspecto de la presente invención. La Figura 16A es un diagrama de protocolo que muestra un protocolo de ejemplo para llevar a cabo una operación de transferencia rápida. La Figura 16B es un diagrama de protocolo que muestra un protocolo de ejemplo para proporcionar información de avance cuando se lleva a cabo una operación de transferencia rápida de acuerdo con un aspecto de la presente invención. La Figura 17? es un diagrama de flujo que representa un procedimiento para canalizar un conjunto de mensaj es . La Figura 17B es un diagrama de flujo que representa un procedimiento para canalizar un conjunto de mensajes junto con información de avance de acuerdo con un aspecto de la presente invención.

La Figura 18 es un diagrama esquemático de múltiples componentes de clientes de correo electrónico que son notificados como resultado de un cambio al mismo objeto de datos en un componente de servidor de correo electrónico. La Figura 19A es un diagrama de flujo que representa un procedimiento para notificar a múltiples suscriptores . La Figura 19B es un diagrama de flujo que representa un procedimiento para notificar a múltiples suscriptores de acuerdo con un aspecto de la presente invención . La Figura 20 es un diagrama de flujo que representa un procedimiento para proporcionar un mensaje de correo electrónico que utiliza una página de código deseado de acuerdo con un aspecto de la presente invención. Descripción Detallada de la Invención Antes de proceder a la descripción de las distintas modalidades de la invención, se proporcionará una descripción de un ambiente de computadora y de red en el cual se pueden practicar las distintas modalidades de la invención. Aunque no se requiere, la presente invención se puede implementar por programas que son ejecutados por una computadora. En general, los programas incluyen rutinas, objetos, componentes, estructuras de datos y similares que realizan tareas particulares o implementan tipos de datos abstractos particulares. El término programa" como se usa en la presente puede connotar un solo módulo de programa o múltiples módulos de programa que actúan en concierto. El término "computadora" como se usa en la presente incluye cualquier dispositivo que electrónicamente ejecuta uno o más programas, tales como las computadoras personales (PCs) , dispositivos de mano, sistemas multiprocesadores, electrónicos de consumidor programables basados en microprocesadores, computadoras personales en red, minicomputadoras, computadoras personales en tableta, computadoras centrales, aparatos eléctricos de consumidor que tienen un microprocesador o microcontrolador, ruteadores, puertos, cubos y similares. La invención también puede emplearse en ambientes de computación distribuida, en donde las tareas son realizadas por dispositivos de procesamiento remotos que están enlazados a través de una red de comunicaciones. En un ambiente de computación distribuida, los programas se pueden localizar tanto en dispositivos de almacenamiento de memoria locales como remotos. Un ejemplo de un ambiente en red en el cual se puede usar la invención se describirá ahora con referencia a la Figura 1. La red de ejemplo incluye varias computadoras 10 que se comunican entre si sobre una red 11, representada por una nube. La red 11 puede incluir muchos componentes muy conocidos, tales como ruteadores, puertos, cubos, etcétera y permite a las computadoras 10 comunicarse vía medios alámbricos y/o inalámbricos. Cuando interactúan entre sí sobre la red 11, una o más de las computadoras pueden actuar como clientes, servidores o iguales con respecto a las otras computadoras. De conformidad con lo anterior, las distintas modalidades de la invención pueden practicarse en clientes, servidores, iguales o combinaciones de las mismas, aunque los ejemplos específicos contenidos en la presente no se refieren a todos estos tipos de computadoras. Haciendo referencia a la Figura 2, se muestra un ejemplo de una configuración básica para una computadora en la cual toda o parte de la invención descrita en la presente se puede implementar. En su configuración más básica, la computadora 10 típicamente incluye cuando menos una unidad de procesamiento 14 y memoria 16. La unidad de procesamiento 14 ejecuta instrucciones para llevar a cabo tareas de acuerdo con distintas modalidades de la invención. Para llevar a cabo estas tareas, la unidad de procesamiento 14 puede transmitir señales electrónicas a otras partes de la computadora 10 y a dispositivos fuera de la computadora 10 para causar algún resultado. Dependiendo de la configuración exacta y del tipo de computadora 10, la memoria 16 puede ser volátil (tal como memoria de acceso directo (RAM) ) , no volátil (tal como memoria de sólo lectura (ROM) o memoria instantánea) o alguna combinación de ambas. Esta configuración más básica se muestra en la Figura 2 mediante la línea punteada 18. De manera adicional, la computadora también puede tener características/funcionalidad adicional. Por ejemplo, la computadora 10 también puede incluir almacenamiento adicional (removible 201 y/o no removible 202) incluyendo, pero sin limitarse a, discos o cinta magnética y óptica. El medio de almacenamiento de computadora incluye medios volátiles y no volátiles, removibles y no removibles implementados en cualquier método o tecnología para el almacenamiento de la información, incluyendo instrucciones ejecutables por computadora, estructuras de datos, módulos de programas, u otros datos. Los medios de almacenamiento de computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria instantánea, CD-ROM, disco versátil digital (DVD) u otro almacenamiento óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda ser usado para almacenar la información deseada y al cual pueda ser accesado por la computadora 10. Cualquiera de estos medios de almacenamiento por computadora puede ser parte de la computadora 10. La computadora 10 preferiblemente también contiene conexiones de comunicación 205 que permiten al dispositivo comunicarse con otros dispositivos. Una conexión de comunicaciones es un ejemplo de un medio de comunicación.

Los medios de comunicación típicamente abarcan instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluye cualquier medio de entrega de información. A manera de ejemplo, y no de limitación, el término "medios de comunicación" incluye medios alámbricos tales como una red alámbrica o conexión directa cableada, así como medios inalámbricos tales como medios acústicos, de radiofrecuencia, infrarrojos y otros medios inalámbricos. El término "medio legible por computadora" como se usa en la presente incluye tanto medios de almacenamiento en computadora como medios de comunicación . La computadora 10 también puede tener dispositivos de entrada 204 tales como un teclado, ratón, pluma, dispositivo de entrada de voz, dispositivo de entrada táctil, etcétera. También pueden incluirse dispositivos de salida 203 tales como una pantalla visual 20, altavoces, una impresora, etcétera. Todos estos dispositivos son muy conocidos en la técnica y no necesitan ser comentados en la presente . La presente invención se dirige a un sistema y método para comunicaciones mejoradas de cliente y servidor, y más particularmente se dirige a un protocolo mejorado que se pueda usar para la comunicación entre un cliente y un servidor. La invención tiene relevancia particular para un ambiente de servidor de correo electrónico, pero las características descritas en la presente pueden ser utilizadas en otras redes de cliente servidor. Sin embargo, para facilidad de descripción, la invención se describe con referencia a un ambiente de correo electrónico de cliente/servidor . La presente invención se puede implementar en un ambiente de cliente/servidor que tiene dos o más versiones de aplicaciones o componentes de cliente, y/o dos o más versiones de aplicaciones o componentes de servidor. Con este fin, la Figura 3 ilustra un diagrama en bloques que muestra versiones múltiples de componentes tanto de cliente como de servidor en un ambiente de correo electrónico en red. En general, los componentes de cliente y servidor se configuran para que sean compatibles hacia atrás. Esto es, un componente ds cliente es capaz de comunicarse con versiones recientes y anteriores de componentes de servidor, y viceversa. Se establece un conjunto de protocolos para comunicarse entre las múltiples versiones. El conjunto de protocolos puede constituir muchos protocolos diferentes, cada uno siendo autocontenido . De manera alternativa, un conjunto de componentes de protocolo puede estar disponible, y componentes particulares se usan para configurar protocolos particulares dentro del conjunto de protocolos.

En cualquier caso, el ambiente de correo electrónico en red mostrado en la Figura 3, un componente de cliente de correo electrónico de la versión más reciente 303 se comunica mejor con una versión más reciente de componente de servidor de correo electrónico 306 utilizando un protocolo 307. Sin embargo, el componente de servidor de correo electrónico más reciente 306 también es capaz de comunicarse con componentes de cliente de correo electrónico de versión previa seleccionada, por ejemplo, el componente de cliente de correo electrónico 302 y el componente de cliente de correo electrónico 301, usando otros protocolos (por ejemplo los protocolos 308 y 309 en la Figura 3) en un conjunto de protocolos. El componente de cliente de correo electrónico 303 también es capaz de comunicarse con componentes de servidor de correo electrónico de versión previa seleccionada, por ejemplo el componente de servidor de correo electrónico 305 y el componente de servidor de correo electrónico 304, usando protocolos tales como los protocolos 310 y 311. Generalmente, como se usa en la presente, para los propósitos de describir el protocolo de la presente invención, un componente de correo electrónico (servidor o cliente) "más reciente", o una versión más reciente de un componente de correo electrónico (servidor o cliente) , es un componente de servidor o cliente que está consciente de la nueva o las nuevas características que se están describiendo, y puede utilizar, implementar, y/o actuar sobre esas características. Aunque los términos se usan en todo este documento para describir los componentes de cliente y servidor que toman en cuenta los distintos aspectos del protocolo de la presente invención, los términos también incluyen componentes que toman en cuenta solamente el aspecto particular que está siendo descrito, o más de un aspecto que está siendo descrito. Igualmente, un componente de correo electrónico "previo" o una versión previa de un componente de correo electrónico es un componente que no toma en cuenta, o no puede actuar sobre los aspectos del protocolo de la presente invención. Un procedimiento de negociación de protocolo frecuentemente se usa para establecer un protocolo entre un cliente y un servidor (por ejemplo, el componente de servidor de correo electrónico de versión más reciente 306 y el componente de cliente de correo electrónico de la versión más reciente 303) . Aunque son conocidas estas negociaciones de protocolo, se proporciona una breve descripción de un procedimiento de una negociación de protocolo entre el componente de cliente de correo electrónico 401 (Figura 4) y un componente de servidor de correo electrónico 402 (también Figura 4) para el beneficio del lector. Anteriormente en una sesión de comunicación entre un componente de cliente de correo electrónico 401 y un componente de servidor de correo electrónico 402, el componente de cliente de correo electrónico 401 envía al componente de servidor de correo electrónico 402 un mensaje 403 que incluye información de versión de cliente, por ejemplo, en forma de una estampa de versión de componente de cliente. El componente de servidor de correo electrónico 402 responde el mensaje 403 con el mensaje 404 que incluye la información de la versión del servidor, por ejemplo, en forma de una estampa de versión de componente de servidor. La información de versión de cliente y servidor puede ser usada en una variedad de formas para intentar establecer comunicación entre el componente de cliente de correo electrónico 401 y el componente de servidor de correo electrónico 402. Por ejemplo, se puede usar información de versiones para seleccionar un protocolo conveniente para las comunicaciones continuadas, o para determinar si otras comunicaciones todavía son posibles. Al establecer un protocolo, se puede usar información de la versión para permitir y/o deshabilitar los aspectos o componentes de protocolo disponibles específicos, por ejemplo . Un componente de servidor de correo electrónico puede recibir y procesar solicitudes de múltiples componentes de clientes de correo electrónico en paralelo. Cuando se muestra un solo cliente, a menos que se establezca explícitamente de otra manera, es únicamente para simplificar las figuras y la explicación acompañante. La red de correo electrónico de la presente invención utiliza intercambios de solicitud y respuesta para pasar consultas y datos entre componentes de cliente y servidor en la red. En la práctica, el desempeño de un protocolo puede ser afectado por el mecanismo de transporte de la red de comunicaciones subyacente usado para implementar las comunicaciones entre los clientes y servidores en una red de correo electrónico. Por ejemplo, en una red de correo electrónico que utiliza llamadas de procedimiento remotas (RPCs) como el mecanismo de transporte de red de comunicaciones subyacente, puede ser mucho más eficiente hacer una sola llamada de procedimiento remoto de tamaño mayor (por ejemplo, 32 kilobytes) que hacer varias llamadas de procedimiento remotos de tamaño menor (por ejemplo, 2 kilobytes) . Una manera conocida para mejorar el desempeño en esta red de correo electrónico es almacenar en memoria intermedia múltiples solicitudes y/o respuestas para su transmisión en una sola llamada de procedimiento remoto. Como un ejemplo, la Figura 5 muestra intercambio de solicitud de respuesta entre un componente de cliente de correo electrónico 501 y un componente de servidor de correo electrónico 502. El componente de cliente de correo electrónico 501 y el componente de servidor de correo electrónico 502 cada uno tiene las memorias intermedias de comunicación de tamaño fijo 503, 504, 505 y 506. Las memorias intermedias 503, 504, 505 y 506 son áreas reservadas de la memoria para mantener datos temporalmente. El componente de cliente de correo electrónico 501 comienza un ciclo de solicitud-respuesta rellenando la memoria intermedia 503 con una o más subsolicitudes u operaciones remotas (ROP) antes de transmitir el contenido de la memoria intermedia 503 a la memoria intermedia 504. Después de haber recibido en la memoria intermedia 504. cada operación remota se procesa en orden por el componente de servidor de correo electrónico 502 y el resultado correspondiente se escribe en la memoria intermedia 505. Cada operación remota produce algún resultado. El resultado puede incluir datos solicitados por el componente de cliente de correo electrónico 501, por ejemplo un conjunto particular de mensajes de correo electrónico. El componente del servidor de correo electrónico 502 verifica la memoria intermedia 505 y cuando está casi llena (por ejemplo, que le restan menos de 8 kilobytes) , el componente del servidor de correo electrónico 502 describe cualquier operación remota no procesada en el extremo de la memoria intermedia 505 y transmite a la memoria intermedia 505 a la memoria intermedia 506. El componente de cliente de correo electrónico 501 comienza entonces un nuevo ciclo de solicitud-respuesta escribiendo las operaciones remotas en la memoria intermedia 503 para su remisión al componente de servidor de correo electrónico 502 cuando la memoria intermedia 503 queda llena de nuevo . El tamaño de una respuesta típicamente es más grande en promedio que el tamaño de una solicitud. Por esta razón, el tamaño de las memorias intermedias de respuesta 505 y 506 típicamente se configuran para que sean más grandes que el tamaño de las memorias intermedias de solicitud 503 y 504. En una modalidad de la invención, el tamaño óptimo de las memorias intermedias de respuesta 505 y 506 se determinó que es de 96 kilobytes para un tamaño de 32 kilobytes de las memorias intermedias de solicitud 503 y 504, una proporción de 3 a 1. En una modalidad, el componente de cliente de correo electrónico es capaz de configurar el tamaño de cualquiera de las memorias intermedias 503, 504, 505 y 506. Algunas redes de correo electrónico que utilizan memorias intermedias, por ejemplo la red de correo electrónico mostrada en la Figura 5, pueden emplear un modo de transferencia rápida entre un componente de cliente de correo electrónico y un componente de servidor de correo electrónico. El modo de transferencia rápida incluye solicitudes, tales como operaciones remotas, por un cliente que se dividen en cuando menos dos clases: solicitudes que dan como resultado una inicialización de una fuente de transferencia de datos rápida al servidor, y solicitudes que dan como resultado la transferencia eficiente de datos desde la fuente de datos de transferencia rápida al cliente. La fuente de datos de transferencia rápida puede ser, por ejemplo, una tabla de base de datos. La fuente de datos de transferencia rápida sirve como un almacén temporal listo de datos que permite que solicitudes posteriores para los datos sean atendidas con menos retraso de lo que de otro modo seria posible. Algunas veces la segunda clase de solicitud en modo de transferencia rápida busca lograr una transferencia eficiente de datos especificando explícitamente el tamaño de la respuesta, por ejemplo, el tamaño de la respuesta puede fijarse al tamaño de la memoria intermedia de recepción del cliente entera menos el sobrante de la respuesta. La Figura 6A muestra una operación de transferencia rápida que tiene cuando menos dos ciclos de solicitud-respuesta. En una primera solicitud 601 una operación remota (por ejemplo, FXPrepare) inicializa una fuente de datos de transferencia rápida en el servidor 502. En el servidor, sólo se procesa el FXPrepare (es decir, la fuente de datos de transferencia rápida se inicializa) y su resultado se retorna en una primera respuesta 602. En una segunda solicitud 603 una operación remota (por ejemplo, FXGetBuffer) solicita al servidor llenar la memoria intermedia 505 a partir de la fuente de datos rápidos. El servidor vacía la fuente de datos rápidos en la memoria intermedia, y devuelve el resultado en una segunda respuesta 604. Si la memoria intermedia de salida 505 para el componente de servidor de correo electrónico se llena antes de que la fuente de datos rápidos se vacie, se pueden requerir operaciones remotas FXGetBuffer adicionales. La Figura 6B muestra una operación de transferencia rápida que sólo tiene un solo ciclo de solicitud-respuesta. En una primera solicitud 605, ambas FXPrepare y FXGetBuffer se procesan mediante el componente de servidor de correo electrónico 502 y los resultados de arabas operaciones son devueltas en la primera respuesta 605. El resultado de FXPrepare está disponible para FXGetBuffer en el componente de servidor de correo electrónico 502 debido a que parte de cada memoria intermedia 503, 504, 505 y 506 se define explícitamente como una tabla de datos compartida. Es deseable reducir el número de ciclos de solicitud-respuesta debido a que da como resultado una transferencia más eficiente de datos. Una operación de transferencia rápida que tiene más de un solo ciclo de solicitud-respuesta puede presentarse cuando la memoria intermedia 505 está demasiado llena para mantener el resultado de una operación remota FXGetBuffer . Se apreciará que las operaciones remotas de la Figura 6A y 6B y las Figuras parecidas en toda esta solicitud son esquemáticas porque pueden ser implementadas en la práctica por una serie de operaciones remotas a menos que se establezca específicamente alguna otra cosa. Típicamente, el tamaño de un resultado de operación remota es diferente del tamaño de una solicitud de operación remota. No siempre es posible predecir el tamaño de un resultado de operación remota. Cuando se usan técnicas de compresión de datos para reducir el tamaño de un resultado de operación remota, es todavía más difícil predecir el tamaño de un resultado de operación remota. No pudiendo predecir el tamaño de un resultado de operación remota se puede evitar el ajuste manual de un protocolo para minimizar el número de ciclos de solicitud respuesta requeridos para completar operaciones de cliente particulares, por ejemplo, para asegurar que todos los nuevos mensajes sean descargados al cliente en un solo ciclo de solicitud-respuesta. De acuerdo con un aspecto de la presente invención, el número de ciclos de solicitud-respuesta se minimiza automáticamente especificando que las operaciones remotas clave (por ejemplo, FXGetBuffer) están libres del requerimiento de predecir el tamaño de su resultado. En vez de eso, estas operaciones remotas son procesadas por el componente de servidor de correo electrónico 502 hasta que se alcanza el límite de la memoria intermedia 505 (que es el mismo que la memoria intermedia 506) .

Como un ejemplo , en un ambiente que incluye múltiples versiones de componentes de servidor de correo electrónico, se pueden definir operaciones remotas separadas para componentes de servidor de versión previa y componentes de servidor de versión reciente. Las versiones recientes están libres del requerimiento de predecir el tamaño de su resultado. Las características para estas operaciones remotas se establecen en la siguiente tabla: Las operaciones remotas para los componentes de servidor de versión previa son similares en construcción a las operaciones remotas de la técnica anterior, existentes. Esto es, las operaciones remotas predicen y dictan un tamaño en la memoria intermedia de salida (por ejemplo, la memoria intermedia de envío 505) que debe ser reservado para sostener una respuesta. En contraste, el tamaño dictado para la memoria intermedia de salida para una versión más reciente de un componente de servidor no se predice, sino en vez de eso se fija en un valor más allá de lo esperado por los componentes del servidor de la versión previa, por ejemplo, a un valor mayor de 32 KB. El hecho de que el tamaño de la memoria intermedia de salida se defina más allá de un valor esperado por el componente de servidor señala que el componente de servidor busca un nuevo parámetro de límite de tamaño, el cual puede ser, por ejemplo, un llenado de la memoria intermedia de salida para el componente de servidor. Estas características automáticamente minimizan el número de ciclos de solicitud-respuesta, con sólo un pequeño implemento en la complejidad de un componente de servidor de correo electrónico que procesa las operaciones remotas. Nótese que el orden de los parámetros mostrados en la tabla anterior y en tablas parecidas en toda esta solicitud no necesariamente se correlacionan con el orden en que, por ejemplo, los parámetros son transmitidas sobre la red o almacenados en la memoria ya sea por un componente de cliente de correo electrónico o un componente de servidor de correo electrónico, a menos que se acompañe por una declaración explícita al contrario. Además, los parámetros no cambiados pueden ser omitidos por razones de claridad. En una red de correo electrónico, uno de los deberes típicos del protocolo es lograr la transferencia de objetos de datos, por ejemplo, mensajes de correo electrónico, entre los componentes de cliente de correo electrónico y los componentes de servidor de correo electrónico. Otros ejemplos de estos objetos de datos incluyen carpetas de correo electrónico que pueden contener mensajes de correo electrónico y otros objetos de datos, y objeto de datos de información asociada con carpetas (FAI) los cuales pueden, por ejemplo, contener reglas para procesar mensajes de correo electrónico, o definir de qué manera los objetos de datos contenidos por una carpeta serán exhibidos. Los objetos de datos pueden ser opacos a un componente de cliente de correo electrónico; esto es un componente de cliente de correo electrónico puede no tener medios para interpretar el contenido del objeto de datos. Alternativamente, los objetos de datos pueden estar compuestos de propiedades nombradas, por ejemplo, un mensaje de correo electrónico puede comprender propiedades llamadas "a", "desde", "asunto", "importancia", "cuerpo 1", "cuerpo 2", "cuerpo 3", "anexo 1", "anexo 2", y así sucesivamente. Una ventaja de las redes de correo electrónico donde los objetos de datos pueden estar compuestos de propiedades nombradas sobre redes de correo electrónico donde los objetos de datos son opacos es el potencial para mejorar el desempeño del protocolo debido a la capacidad del protocolo para transferir sólo parte del objeto de datos. Tener propiedades nombradas permite que propiedades particulares del objeto de datos sean transmitidas sin transmitir el objeto de datos entero. Por ejemplo, un mensaje de correo electrónico puede estar compuesto de un conjunto de propiedades de encabezado y un conjunto de propiedades de cuerpo. La necesidades de un componente de cliente de correo electrónico pueden ser tales que un protocolo puede transferir las propiedades de encabezado primero y luego las propiedades de cuerpo después o no en absoluto. Esta característica permite que un usuario vea la información de encabezado para varios mensajes antes de que todos los mensajes por entero sean descargados. Usando esta característica, se puede obtener un control de grano más fino sobre la utilización de la anchura de banda por el componente cliente, el cual puede efectuar positivamente el desempeño del protocolo. Además, un componente de cliente puede usar esta característica para dar como resultado una utilización más baja de la anchura de banda (por ejemplo, los cuerpos pueden ser descargados para solamente encabezados seleccionados) , lo cual es particularmente deseable en ambientes con anchura de banda menor. El desempeño del protocolo no necesariamente aumenta si el componente de servidor se configura para enviar propiedades de cuerpo y encabezado en dos ciclos separados de solicitud-respuesta (es decir, uno para el encabezado y otro para el cuerpo) . Por ejemplo, si las necesidades del componente de cliente de correo electrónico fueran tales que requiriera ambas propiedades de encabezado y cuerpo al mismo tiempo, entonces el desempeño del protocolo podría ser disminuido hacia una situación en donde un solo ciclo de solicitud-respuesta podría recuperar tanto el encabezado como el cuerpo. De este modo, el simple acto de habilitar a los objetos de datos para estar compuestos de propiedades nombradas no es en sí mismo suficiente para dar como resultado automáticamente un desempeño de protocolo mejorado. Lograr el desempeño de protocolo mejorado depende de la elección de las propiedades que pueden conformar un objeto de datos y de qué manera pueden ser usados por un protocolo. Esta elección puede depender de varios factores incluyendo las necesidades de los componentes de cliente de correo electrónico de la versión más reciente y la versión previa, y las necesidades de los componentes de servidor de correo electrónico más recientes y de versión previa. Ejemplos de necesidades de componentes de cliente de correo electrónico incluyen satisfacer diferentes niveles de urgencia para la exhibición de diferente información y el cumplimiento de preferencias establecidas por un usuario de componente de cliente de correo electrónico. Ejemplos de necesidades de componente de servidor de correo electrónico incluyen un almacenamiento y recuperación eficiente de datos y procesamiento eficiente de solicitudes de protocolo. Los ambientes de correo electrónico de la técnica anterior convencionales utilizan objetos de datos que pueden estar compuestos de propiedades nombradas, por ejemplo, un mensaje de correo electrónico que puede incluir un cómputo de encabezados y un conjunto de cuerpos de propiedades nombradas de manera que los dos conjuntos puedan ser solicitados y/o procesados por separado. Otro ejemplo de la técnica anterior es un mensaje de correo electrónico en donde el conjunto de cuerpos de propiedades nombradas incluye múltiples versiones del cuerpo de mensaje de correo electrónico, por ejemplo, en múltiples formatos de mensajes de correo electrónico tales como texto llano, lenguaje marcador de hipertexto (HTML), formato de texto rico (RTF) y asi sucesivamente. En esta situación, los componentes de servidor de correo electrónico de la técnica anterior pueden responder a una solicitud de protocolo para el cuerpo de mensaje de correo electrónico en una variedad de formas. La respuesta de complejidad menor puede ser enviar todas las versiones del cuerpo del mensaje de correo electrónico pero esta respuesta puede dar como resultado una utilización de anchura de banda aumentada. La Figura 7A representa parte de un procedimiento que un componente de servidor de correo electrónico de versión previa (técnica anterior) si usa para responder a esta situación. En el paso 701, el componente de servidor de correo electrónico examina el formato de cada cuerpo del mensaje de correo electrónico. Si uno de los formatos es un formato estándar predeterminado (por ejemplo, RTF) , entonces el procedimiento se mueve hacia el paso 703 y el cuerpo del mensaje de correo electrónico de formato estándar es enviado al componente de cliente de correo electrónico solicitante. Si ninguno de los formatos es un formato estándar predeterminado, entonces el paso 701 se ramifica al paso 702 en donde una de las versiones del cuerpo del mensaje de correo electrónico se convierte en formato estándar. El subprocedimiento representado por la Figura 7? también se puede usar cuando sólo hay una sola versión de un cuerpo de mensaje de correo electrónico pero el cuerpo del mensaje de correo electrónico puede no estar en formato estándar que es requerido por un protocolo. La Figura 7B representa parte del procedimiento usado por un componente de servidor de correo electrónico de versión más reciente de acuerdo con la presente invención. En el paso 704, una solicitud de protocolo es resultado de un subprocedimiento que está siendo usado por un componente de servidor de correo electrónico se examina para determinar un marcador de MEJOR_CUERPO (BEST_BODY) . El marcador en este ejemplo y los otros marcadores usados en la presente se usan para que el componente de servidor de correo electrónico sepa que el componente de cliente de correo electrónico es una versión más reciente y desea implementar la función asociada con el marcador. Otras indicaciones se pueden usar. Por ejemplo, la función se puede implementar por omisión si se detecta un componente de cliente de correo electrónico más reciente . En cualquier caso, si no se encuentra el marcador de MEJOR_CUERPO, entonces el paso 704 se ramifica al paso 701, y continúa como se describe con referencia a la Figura 7A. Si se encuentra el marcador, el procedimiento se mueve al paso 705, en donde se selecciona el mejor cuerpo de mensaje de correo electrónico para enviar al componente de cliente de correo electrónico solicitante. Si sólo hay un solo cuerpo de mensaje de correo electrónico asociado con el mensaje de correo electrónico solicitado, entonces éste será el mejor. Si hay varios cuerpos de mensajes de correo electrónico, por ejemplo, con diferentes formatos, entonces el componente de servidor de correo electrónico elige el mejor entre ellos de acuerdo, por ejemplo, con un rango predeterminado de formatos de cuerpos de mensaje de correo electrónico (por ejemplo, RTF, HTML, texto llano) . El proceso entonces continúa con el paso 703, en donde el cuerpo de mensaje de correo electrónico elegido se envía al componente de cliente de correo electrónico. En esta modalidad, el componente de cliente de correo electrónico puede ser capaz de exhibir múltiples formatos de cuerpo de mensaje de correo electrónico de este modo liberando el componente de servidor de correo electrónico del requisito de convertir los cuerpos de mensaje de correo electrónico a formato estándar. Además, el componente de cliente de correo electrónico puede convertir el mejor cuerpo de mensaje de correo electrónico en un diferente formato, si se desea. Debido a que el componente de servidor de correo electrónico es relevado de la tarea de convertir cuerpos de mensajes de correo electrónico, la presente invención proporciona desempeño mejorado. Además, un componente de servidor de correo electrónico de versión más reciente puede responder a solicitud de protocolo a partir de un componente de cliente de correo electrónico de versión previa con solamente un aumento moderado en complejidad. Las operaciones remotas pueden ser usadas para lograr la réplica de una carpeta de correo electrónico entre un componente de servidor de correo electrónico y un componente de cliente de correo electrónico. Una solicitud para sincronizar una carpeta que puede ser, por ejemplo, mediante una operación remota SynchFolder. Cuando un componente de correo electrónico de cliente es capaz de desplegar formatos de cuerpos de mensaje de correo electrónico no estándares, puede fijar el marcador MEJOR_CUERPO en la operación remota SynchFolder para indicar que el componente de servidor de correo electrónico puede seleccionar el mejor formato entre los cuerpos de mensaje de correo electrónico disponibles, en vez de requerir que el servidor regrese un cuerpo de mensaje de correo electrónico en un formato estándar. Un componente de servidor de correo electrónico puede adecuadamente precisar las operaciones remotas tanto con o sin el marcador MEJOR_CUERPO con sólo un aumento moderado en complejidad. Las operaciones remotas para comunicarse con los servidores de versión previa y de versión más reciente pueden incluir, por ejemplo, las características presentadas en la siguiente tabla: ROP que puede ser ROP que puede ser usada por usada por un protocolo el protocolo para comunicarse para comunicarse con con la mayoría de los servidores de versión servidores de versión reciente previa ROP ID SynchFolder SynchFolder Nuevos parámetros n/a Marcador MEJOR_CUERPO; si se establece, el componente de servidor de correo electrónico elige el mejor cuerpo de mensaje de correo electrónico para enviarlo al componente de cliente de correo electrónico. La conversión del cuerpo de mensaje de correo electrónico a un formato estándar predeterminado es necesaria.

Las Figuras 8A-8C muestran diferentes modos existentes de transferir un conjunto de mensajes de correo electrónico entre un componente de servidor de correo electrónico y un componente de cliente de correo electrónico. Para cada modo, cada mensaje de correo electrónico tiene propiedades nombradas incluyendo un conjunto de encabezado y un conjunto de cuerpo, y varios mensajes de correo electrónico están contenidos en una carpeta. La Figura 8A ilustra un modo de transferencia de articulo entero. La ilustración muestra un primer encabezado de mensaje de correo electrónico 801 que es transferido y luego un primer cuerpo de mensaje de correo electrónico 802 antes de un segundo encabezado de mensaje de correo electrónico 803 y luego un segundo cuerpo de mensaje de correo electrónico 804 y asi sucesivamente hasta que el conjunto de mensajes de correo electrónico han sido transferidos. La Figura 8B ilustra un primer modo de transferencia de encabezados. En este modo, un primer encabezado de mensaje de correo electrónico 805 se transfiere y luego un segundo encabezado de mensaje de correo electrónico 806 y asi sucesivamente hasta que todos los encabezados de mensajes de correo electrónico han sido transferidos y solamente entonces se transfiere un primer cuerpo de mensaje de correo electrónico 807 y luego un segundo cuerpo de mensaje de correo electrónico 808 y asi sucesivamente hasta que el conjunto de mensajes de correo electrónico se han transferido. La Figura 8C ilustra un modo de transferencia sólo de encabezados. Como el nombre lo sugiere, sólo los encabezados de mensajes de correo electrónico 809 son transferidos como respuesta a una solicitud para transferir un conjunto de mensajes de correo electrónico. Los cuerpos de mensaje de correo electrónico 810 solamente serán transferidos como respuesta a una solicitud explícita adicional. En cualquiera de estos modos, la secuencia de transferencia puede ser interrumpida temporalmente por una solicitud de componente de cliente de correo electrónico de prioridad mayor, por ejemplo, para un cuerpo de mensaje de correo electrónico particular. Una carpeta de correo electrónico es un ejemplo de un objetivo para una solicitud de transferir un conjunto de mensajes de correo electrónico. Sin embargo, una carpeta de correo electrónico puede contener objetos de datos distintos de los mensajes de correo electrónico. Como se discuti anteriormente, se definen frecuentemente modos de transferencia con referencia a encabezados de mensajes de correo electrónico y cuerpos de mensaje de correo electrónico, tales como los modos de transferir primero los encabezados y transferir solamente encabezados. En estos modos de transferencia, un intento para transferir objetos de datos para los cuales un conjunto de encabezados de propiedades nombradas y/o un conjunto de cuerpos de propiedades nombradas pueden no estar bien definidos y pueden dar como resultado una falla del protocolo. Un aspecto de la invención evita esta situación proporcionando los objetos de datos para los cuales un conjunto de encabezado y/o cuerpo de propiedades nombradas no está bien definido, siempre puede ser transferido en total en vez de en parte. Esta modalidad se puede ilustrarse mediante el ejemplo de la Figura 8D. En este ejemplo, la transferencia entre un componente de servidor de correo electrónico y un componente de cliente de correo electrónico puede estar ocurriendo en el modo sólo encabezados. De conformidad con lo anterior, un primer encabezado de mensaje de correo electrónico 811 se transfiere y luego el objeto de datos 812 se vuelve el siguiente candidato para la transferencia. El conjunto de encabezado de propiedades nombradas no está bien definido para el objeto de datos 812, tal como FAI, de manera que el objeto de datos entero se transfiere. Un siguiente candidato para la transferencia si tiene un conjunto de encabezado bien definido de propiedades nombradas (es decir, el objeto de datos candidato si posee todas las propiedades nombradas explícitamente definidas por el componente de cliente de correo electrónico como perteneciente al conjunto de encabezados de propiedades nombradas) y de este modo sólo se transfiere un encabezado de mensaje de correo electrónico 813.

Un ejemplo de una manera para implementar este aspecto de la presente invención es usando un marcador, tal como IGNORAR_MODO_EN_FAI (IGNORE_MODE_ON_FAI ) , que puede ser incluido en una operación remota de sincronización, tal como la operación remota SynchFolder descrita anteriormente. Un componente de servidor de correo electrónico puede adecuadamente procesar operaciones remotas tanto con como sin un marcador IGNORAR_MODO_EN_FAI con sólo un aumento moderado en complejidad. Las operaciones remotas pueden incluir las características presentadas en la tabla más adelante para lograr la réplica de una carpeta de correo electrónico entre un componente de servidor de correo electrónico y un componente de cliente de correo electrónico: ROP que puede ser ROP que puede ser usada por usada por un protocolo el protocolo para comunicarse para comunicarse con con la mayoría de los servidores de versión servidores de versión reciente previa ROP ID SynchFolder SynchFolder Nuevos n/a Marcador parámetros IGNORAR__MODO_EN_FAI : si está fijo, entonces para los objetos de datos, tales como FAI, que no tienen un conjunto bien definido de propiedades nombradas del encabezado y/o cuerpo, el componente de servidor de correo electrónico puede responder a una solicitud de transferencia con el objeto de datos entero independientemente del modo de transferencia prevaleciente.

Los mensajes de correo electrónico típicamente se dirigen a uno o más usuarios en una red de correo electrónico. Un mensaje de correo electrónico puede considerarse entregado si es aceptado por un componente de servidor de correo electrónico para su almacenamiento. Una red de correo electrónico puede tener varios componentes de servidor de correo electrónico. Típicamente, un protocolo de red de correo electrónico tiene alguna estrategia para limitar el número de componentes de servidor de correo electrónico que un usuario de red de correo electrónico debe verificar para determinar nuevos mensajes. Un ejemplo común es la estrategia de servidor doméstico que proporciona que los mensajes de correo electrónico dirigidos a un usuario de la red de correo electrónico particular, sólo serán aceptados por un componente de servidor de correo electrónico particular, llamado el servidor doméstico del usuario. En este caso, un componente de cliente de correo electrónico puede configurarse para considerar solamente el servidor doméstico cuando, por ejemplo, periódicamente se verifica para determinar si hay mensajes de correo electrónico nuevos o registrar la notificación de mensajes de correo electrónico nuevos . La Figura 9 muestra que aún un simple ejemplo de estrategia de servidor doméstico puede tener complicaciones . En el ejemplo ilustrado por la Figura 9, un componente de servidor de correo electrónico particular 901 primero se designa como el servidor del hogar para un usuario de red de correo electrónico particular. Durante el tiempo, el servidor doméstico designado para el usuario se cambia a diferentes componentes de servidor de correo electrónico 903 y 905, típicamente por razones administrativas. Los componentes del servidor de correo electrónico 901, 903 y 905 pueden, por ejemplo, ser típicamente diferentes, o lógicamente diferentes, o ser diferentes versiones. El componente de cliente de correo electrónico 902 puede comunicarse solamente con el componente de servidor de correo electrónico 901 del tiempo T0 hasta el tiempo Ti, luego el componente de cliente de correo electrónico 904 puede comunicarse solamente con el componente de servidor de correo electrónico 903 hasta el tiempo T2, y entonces el componente de cliente de correo electrónico 906 puede comunicarse solamente con el componente de servidor de correo electrónico 905. Los componentes de cliente de correo electrónico 902, 904 y 906 pueden ser iguales o diferentes. Los componentes de servidor de correo electrónico 901 y 903 pueden existir o no existir después del tiempo 2. Estas complicaciones son particularmente relevantes a la réplica de almacenamiento de mensajes de correo electrónico que se discute enseguida. Los mensajes de correo electrónico pueden ser almacenados por un componente de servidor de correo electrónico en un almacenamiento de mensajes de correo electrónico explícito el cual puede, por ejemplo, implementarse usando tecnologías de base de datos muy conocidas. Un componente de servidor de correo electrónico puede tener uno o más de estos almacenes de mensajes. Un usuario de red de correo electrónico puede tener un almacenamiento de mensajes doméstico. Cambiar los almacenes de mensajes domésticos puede tener algunos efectos como se describió para cambiar servidores domésticos. Algunos protocolos de red de correo electrónico incluyen una capacidad para replicar partes de un almacén de mensajes de correo electrónico para una instalación de almacenamiento local para un componente de cliente de correo electrónico. La réplica de partes de un almacén de mensajes de correo electrónico remotos a una instalación de almacenamiento de correo electrónico local puede mejorar el desempeño del protocolo y/o el desempeño percibido del protocolo mediante, por ejemplo, replicar todos los mensajes nuevos de correo electrónico a la instalación de almacenamiento de correo electrónico local por adelantado de la solicitud explícita de un usuario de la red de correo electrónico para verlos. Esta réplica puede también proporcionar funcionalidad de componente de cliente de correo electrónico adicional, por ejemplo, habilitando a un usuario de red de correo electrónico para ver un mensaje de correo electrónico durante las interrupciones de conectividad de la red. En un ambiente de red de correo electrónico, la réplica simple puede rápidamente volverse ineficiente. Por ejemplo, si un componente de servidor de correo electrónico tiene un mensaje de correo electrónico asociado con un usuario de red de correo electrónico particular y este mensaje ya ha sido replicado en el componente de cliente para el usuario de red, y un nuevo mensaje llega para ese usuario de red de correo electrónico, entonces todavía se requiere que dos mensajes de correo electrónico deban ser enviados como respuesta a una simple solicitud de réplica. Si este mensaje de correo electrónico nuevo llega después de la réplica de los dos mensajes de correo electrónico, entonces todavía se requiere que tres mensajes de correo electrónico deban ahora ser enviados como respuesta a una simple solicitud de réplica y así sucesivamente. Algunos protocolos de red de correo electrónico han proporcionado una réplica aumentada de almacenes de mensajes de correo electrónico para aliviar este problema. En una réplica aumentada, sólo cambios a un almacén de mensaje de correo electrónico que ocurrieron después de una réplica de aumento exitosa deben ser enviadas como respuesta a una solicitud de réplica, por ejemplo, cuando el único cambio desde la última réplica de incremento exitosa es la llegada de un nuevo mensaje de correo electrónico, entonces solamente el nuevo mensaje de correo electrónico necesita ser enviado como respuesta a una solicitud de réplica de incremento. La Figura 10 muestra un ejemplo más detallado de un protocolo que proporciona la réplica incrementada. Un almacén de mensaje de correo electrónico puede subdividirse en carpetas de correo electrónico. Cada carpeta de correo electrónico puede replicarse independientemente de las demás, proporcionando un control de grano más fino sobre el proceso de réplica. En este ejemplo, el proceso de réplica aumentado se denomina sincronización debido a que incluye la propagación de cambios del componente de clientes de correo electrónico 501 hasta el componente de servidor de correo electrónico 502 asi como del componente de servidor de correo electrónico 502 al componente de cliente de correo electrónico 501. Siguiendo una solicitud de sincronización 1001, se procesa una operación remota SynchFolder mediante el componente del servidor de correo electrónico 502. La operación remota incluye un parámetro de identificación de carpeta (no mostrado) y un parámetro stateblob0. El parámetro de identificación de carpeta identifica una carpeta de correo electrónico que es el objetivo de la solicitud de sincronización 1001. El parámetro stateblobo contiene información que permite que el componente de servidor de correo electrónico 502 determine cuáles cambios, si los hay, han ocurrido en la carpeta de correo electrónico desde que por última vez fue sincronizada. Si la solicitud 1001 representa la primera solicitud de sincronización para la carpeta objetivo por el componente de cliente de correo electrónico 501, entonces el componente de servidor de correo electrónico 502 determina si la carpeta de correo electrónico objetivo en el almacén de mensajes de correo electrónico ha cambiado en comparación con una carpeta vacia. Como respuesta 1002 a la solicitud 1001, el componente de servidor de correo electrónico 502 envia cualquier cambio al componente de cliente de correo electrónico 501 incluyendo cualquier mensaje de correo electrónico y/u otros objetos de datos que han sido añadidos a la carpeta objetivo y una lista de cualquier mensaje de correo electrónico y/u otros objetos de datos que han sido borrados de la carpeta objetivo. El componente de servidor de correo electrónico 502 también crea un modo statebloba que representa el estado de la carpeta objetivo como estará en el componente de cliente de correo electrónico 501 inmediatamente después de la sincronización y también envía ese stateblobi como respuesta 1002. Cuando el componente de cliente de correo electrónico 501 envía la siquiente solicitud de sincronización 1003 para la misma carpeta que en la solicitud 1001, entonces la solicitud 1003 incluirá como un parámetro el mismo stateblobi que fue regresado con respuesta 1002. Como antes, el componente de servidor de correo electrónico 502 usará la información contenida en stateblobi para determinar qué cambios, si los hay, se han presentado en la -carpeta objetivo y enviar esos cambios junto con un nuevo stateblob2 creado de nuevo al componente de cliente de correo electrónico 501 como respuesta a 1004. Si el objeto de datos stateblob es grande de tamaño, puede afectar adversamente el desempeño del protocolo debido a que se envía hacia y desde un componente de servidor de correo electrónico con, por ejemplo, toda solicitud de sincronización de carpeta de correo electrónico. En algunos protocolos de red de correo electrónico que proporcionan sincronización de carpetas de correo electrónico, el stateblob puede, en gran parte, conformarse de un conjunto de objetos de datos de cambio de identificación de mensaje que identifican cambios en los mensajes de correo electrónico que han sido enviados en un componente de cliente de correo electrónico. Un cambio de mensaje de correo electrónico puede decirse que ha sido visto por un componente de cliente y/o servidor de correo electrónico cuando el mensaje de correo electrónico cambiado se transfiere a ese componente. Una meta del objeto de datos de identificación de cambio de mensaje puede ser identificar unívocamente un cambio a un mensaje de correo electrónico en el contexto de una red de correo electrónico entera. En una red de correo electrónico que emplea una estrategia de servidor doméstico, un servidor doméstico del usuario puede ser responsable de asociar un objeto de datos de identificación de cambio de mensaje con un cambio de mensaje de correo electrónico previamente no visto. Por ejemplo, un servidor doméstico puede emplear objetos de datos de identificación de cambios de mensaje que comprenden un objeto de datos de identificación de servidor y un número de serie. Un objeto de datos de identificación de servidor puede identificar unívocamente un componente de servidor de correo electrónico en el contexto de una red de correo electrónico entera usando técnicas muy conocidas tales como identificadores globalmente únicos. Cuando estos identificadores por si mismo son de tamaño grande, el objeto de datos de identificación de servidor puede en vez de eso ser un índice en una tabla de consulta de identificadores mantenida por el componente de servidor de correo electrónico. El número de serie puede ser proporcionado por un contador, por ejemplo, de anchura de seis bytes, local en un componente de servidor de correo electrónico, que se incrementa siempre que el componente de servidor de correo electrónico acepta un mensaje de correo electrónico previamente no visto para su almacenamiento. Para propósitos de discusión, un objeto de datos de identificación de cambios de mensaje puede ser representado mediante, por ejemplo, wSi:l" en donde Si representa el objeto de datos de identificación de servidor para el primer componente de servidor de correo electrónico y ?1' representa un número de serie. ün conjunto de objeto de datos de identificación de cambios de mensaje puede representarse mediante, por ejemplo, "Si:l, Si:2, Si:3" en donde "Si:l", Si: 2" y vSi:3" son objetos de datos de identificación de cambios de mensaje consecutivos empleados por un componente de servidor de correo electrónico con el identificador de servidor Si- Cuando se conforma un stateblob, en gran parte, a partir de un conjunto de objetos de datos de identificación de cambios de mensaje que representan cambios de mensaje de correo electrónico vistos por un componente de cliente de correo electrónico (un conjunto de cambios de mensaje vistos") , se han desarrollado algunas técnicas para codificar el conjunto con el fin de reducir su tamaño, por ejemplo, el conjunto vSi: 1, Si:2, Si : 3, Si : 4" se puede codificar como "Si: 1-4". Además, un componente de servidor de correo electrónico puede asegurar que los números de serie que usa siempre están aumentando. En este caso un conjunto de cambios de mensajes vistos no contiguo, por ejemplo, "Si:l, Si:3, Si:5, Si:7", se puede codificar como "Si:l-7", esto es, como un rango que incluye los números de serie mínimo y máximo, sin pérdida de funcionalidad. En un escenario representado por la Figura 9, un conjunto de cambios de mensajes vistos puede incluir los objetos de datos de identificación de cambios de mensaje que fueron creados por los componentes de servidor de correo electrónico (por ejemplo, Si, S2) distintos del servidor doméstico actual (por ejemplo, S3) . Un objeto de datos de identificación de cambios de mensaje creados por el servidor doméstico actual puede ser denominado un identificador de cambios de mensaje original, un objeto de datos de identificación de cambios de mensaje creado por otros componentes de servidor de correo electrónico puede ser denominado un identificador de cambios de mensaje extraño. Los protocolos de red de correo electrónico para comunicarse con componentes de servidor de correo electrónico de versiones previas no han proporcionado la optimización de secuencias de identificación de cambios de mensaje extraños no contiguos como un rango que incluyen los números de serie mínimo y máximo en una base de componente de servidor de correo electrónico por componente de servidor de correo electrónico. La siguiente tabla ilustra un beneficio de incluir esta optimización en una modalidad de la presente invención: Una modalidad de la presente invención utiliza operaciones remotas que incluyen las características presentadas en la tabla más adelante para lograr la sincronización de una carpeta de correo electrónico entre un componente de servidor de correo electrónico y un componente de cliente de correo electrónico. Un componente de servidor de correo electrónico puede implementar la técnica de codificación stateblob mejorada con sólo un aumento moderado en complejidad.

Resultado de operación Resultado de operación remota que puede ser remota que puede ser usada usada por un protocolo por un protocolo cuando se cuando se comunica con comunica con los servidores de servidores de versión versión más reciente previa ROP ID SynchFolder SynchFolder Parámetros sin stateblob: optimización stateblob: optimización cambio usados en que no incluye conjuntos mejorada incluyendo conjuntos un nuevo modo no contiguos de objetos de no contiguos de objetos de datos datos de identificación de de identificación de cambio de cambio de mensaje mensaje extraño extraños.

La Figura 11A y la Figura 11B representan una diferencia entre un subprocedimiento que puede ser usado por un servidor de versión previa y un servidor de versión más reciente, respectivamente, para responder a una operación remota SynchFolder. La Figura 11A muestra los pasos 1102, 1102 y 1103. En el paso 1101, se construye un conjunto de cambios de mensaje vistos inicial. En el paso 1102, los miembros del conjunto de cambios de mensaje vistos que son objetos de datos de identificación de cambio de mensajes originales se optimizan. En el paso 1103, el conjunto de cambios de mensajes vistos optimizados se añade al objeto de datos stateblob que puede ser enviado con una respuesta a un componente de cliente de correo electrónico que solicitó la sincronización. La Figura 11B incluye el paso adicional 1104 que muestra que los miembros del conjunto de cambios de mensajes vistos que son objetos de datos de identificación de cambios de mensaje extraños también están siendo optimizados antes del conjunto de cambios de mensajes vistos, ahora con optimización mejorada, se añade al objeto de datos stateblob en el paso 1103. Aunque subdividir un almacén de mensajes de correo electrónico en carpetas de correo electrónico proporciona un control de grano más fino sobre el proceso de sincronización, no proporciona automáticamente un mejoramiento en el desempeño del protocolo y puede dar como resultado una degradación en el desempeño del protocolo. Por ejemplo, algunos protocolos requieren que cada carpeta de almacén de mensaje se sincronice por separado. Cada operación de sincronización típicamente tiene un restante y ese restante puede ser significativo. Las operaciones de sincronización que utilizan objetos de datos stateblob son un ejemplo de operaciones que pueden tener un restante significativo. En el caso de sincronizar un almacén de mensaje entero, los protocolos que requieren que cada carpeta de almacén de mensajes se sincronice por separado pueden compararse con desventaja con protocolos que requieren menos operaciones de sincronización . Sincronizar un almacén de mensajes entero y mantener la sincronización es una meta deseable para un componente de cliente de correo electrónico. Los componentes de cliente de correo electrónico de la técnica anterior convencionales han buscado lograr esta meta aún cuando diera como resultado un impacto significativamente adverso sobre el desempeño del protocolo. Un aspecto de la presente invención es que es capaz de minimizar el impacto del protocolo adverso al mismo tiempo que logra esta meta utilizando una tabla de jerarquías más profundas. Los componentes de servidor de correo electrónico de la técnica anterior convencionales no han sido capaces de proporcionar una tabla de jerarquías profunda .

Cuando los almacenes de mensajes de correo electrónico se subdividen en carpetas de correo electrónico, esas carpetas de correo electrónico se pueden organizar en jerarguias. La Figura 12 muestra un ejemplo de una jerarguia de carpetas de correo electrónico. En la Figura 12, la carpeta 1204 es una subcarpeta de la carpeta 1203. La carpeta 1203 es, a su vez, una subcarpeta de la carpeta 1202. La carpeta 1201 es una carpeta raíz. üna carpeta raíz no es una subcarpeta de ninguna otra carpeta. Todas las demás carpetas son miembros de la jerarguia de carpetas enraizadas en la carpeta 1201. Típicamente, cada carpeta en la jerarquía de carpetas no tiene referencia directa a ninguna otra carpeta. üna carpeta puede solamente tener referencia directa a sus subcarpetas . Una carpeta también puede tener referencia directa a cualquier carpeta de la cual sea una subcarpeta. En muchos casos, puede ser que la única carpeta para la cual toda carpeta tenga una referencia directa es la carpeta raíz de la jerarquía. Una tabla de jerarquía profunda puede contener información acerca de toda carpeta en una jerarquía de carpetas . Cada carpeta puede tener una línea en la tabla de jerarquías profunda. La información en la tabla de jerarquías profunda es tal que puede ser usada para determinar si el contenido de una carpeta de correo electrónico ha cambiado durante un período de tiempo particular. La determinación de cambio a una carpeta de correo electrónico durante un periodo de tiempo particular se puede implementar usando una comparación simple de una copia de una fila de la carpeta tomada al comienzo del periodo de tiempo, contra una copia de esa fila de la carpeta tomada al final del periodo de tiempo. En una modalidad, cada linea de la tabla de jerarquía profunda incluye los siguientes atributos : Los atributos de una fila de carpeta de correo electrónico en una tabla de jerarquía profunda se pueden actualizar siempre que se haga un cambio del contenido de una carpeta. Para la implementación eficiente de una actualización de tabla de jerarquía profunda, los solicitantes han encontrado que es útil hacer referencia rápida y directa a la tabla de jerarquía profunda. En un mínimo, los solicitantes han encontrado que deberá haber un número pequeño y predecible de niveles de indirección cuando tratan de accesar a la tabla de jerarquía profunda. Por ejemplo, posicionando una tabla de jerarquía profunda a un nivel arbitrario en una jerarquía de carpetas no proporcionará un número predecible de niveles de indirección. En una modalidad de la presente invención, la tabla de jerarquías profunda se puede asociar con la carpeta raíz de una jerarquía de carpetas de almacén de mensajes de correo electrónico del usuario de la red de correo electrónico por esta razón. Las comunicaciones entre un componente de cliente de correo electrónico y un componente de servidor de correo electrónico se pueden dividir en sesiones de comunicaciones. La pérdida de una sincronización de almacenamiento de mensajes de correo electrónico puede presentarse entre las sesiones, por ejemplo, durante una interrupción de conectividad de red. Con el fin de reestablecer la sincronización de almacén de mensajes de correo electrónico al comienzo de una sesión de comunicaciones, algunos protocolos para comunicarse con los componentes del servidor de correo electrónico de versión previa emplearon una operación remota SynchFolder para cada carpeta en la jerarquía de carpetas. Típicamente, el contenido de algunas de las carpetas no habrá cambiado entre las sesiones. Una operación remota SynchFolder con una carpeta sin cambio como su objetivo da como resultado una "sincronización nula". Aunque una "sincronización nula" no dé como resultado que ningunos cambios de carpetas se transfieran a un componente de cliente de correo electrónico, todavía tiene un restante asociado con ella, por ejemplo, un objeto de datos stateblob, que puede ser significativo. La Figura 13 ilustra una modalidad de la invención que evita estos resultados de "sincronización nula" utilizando una tabla de jerarquía profunda. En una primera solicitud 1301, el componente de cliente de correo electrónico 501 envía una operación remota (por ejemplo, GetHierarchyTable) solicitando una tabla de jerarquía profunda al componente de servidor de correo electrónico 502. En una primera respuesta 1302, una copia de la tabla de jerarquía profunda se proporciona al componente de cliente de correo electrónico 501. Típicamente, el componente de cliente de correo electrónico 501 tendrá una copia previa de la tabla de jerarquía profunda. El componente de cliente de correo electrónico 501 puede determinar rápidamente cuáles carpetas en el almacén de mensajes de correo electrónico del usuario en el componente de servidor de correo electrónico 502 han cambiado utilizando una comparación fila por fila de las dos copias. Enseguida, se emplean operaciones remotas (por ejemplo, SynchFolder) para sincronizar solamente las carpetas que han cambiado. La solicitud 1303 y la respuesta 1304 se pueden repetir conforme sea necesario para sincronizar las carpetas cambiadas. Después de la sincronización exitosa, la copia del componente de cliente de correo electrónico de la tabla de jerarquía profunda puede ser actualizada para coincidir con la copia más reciente que fue enviada como respuesta 1302. Si el componente de cliente de correo electrónico 501 no tiene una copia previa de la tabla de jerarquía profunda, entonces todas las carpetas que tienen una fila en la copia más reciente se pueden sincronizar. En cuanto se ha establecido la sincronización de un almacén de mensaje de correo electrónico de un usuario, la sincronización se puede mantener repitiendo periódicamente el inicio de los pasos de sesiones descritos anteriormente (es decir, escrutar el componente de servidor de correo electrónico), pero este esquema tiene desventajas. Por ejemplo, el período de escrutinio puede ser mucho más corto que un período entre los cambios para un almacén de mensajes de correo electrónico de un usuario. En este caso, relativamente muchas de las comparaciones de la tabla de jerarquía profunda indicarán que ninguna carpeta ha cambiado. Estas comparaciones son, en efecto, esfuerzo perdido, de manera que un protocolo que pueda evitarlos puede ser más eficiente . Algunas redes de correo electrónico incluyen una instalación para que un componente de cliente de correo electrónico se suscriba para ser notificado por un componente de servidor de correo electrónico cuando, por ejemplo, el contenido de una carpeta de correo electrónico particular cambie. Algunos componentes de cliente de correo electrónico de versión previa sí usan esta instalación para mantener la sincronización de un almacén de mensajes de correo electrónico de un usuario creando una suscripción por separado para las notificaciones de cambio asociadas con cada carpeta en la jerarquía de carpetas de un usuario. En una modalidad de la presente invención, un componente de cliente de correo electrónico puede crear solamente una sola suscripción para notificaciones de cambio asociadas con la tabla de jerarquía profunda. Una sola suscripción es más eficiente debido a que se requieren menos operaciones remotas para establecerla y se consumen menos recursos del lado del servidor . Con más referencia en la Figura 13, cuando un componente de cliente de correo electrónico de versión más reciente 501, de acuerdo con un aspecto de la presente invención, emplea una operación remota de GetHierarchyTable en una primera solicitud 1301 al comienzo de una sesión de comunicaciones con un componente de servidor de correo electrónico 502, el componente de cliente de correo electrónico 501 se suscribe automáticamente para cambiar notificaciones asociadas con una tabla de jerarquía profunda que es devuelta como respuesta 1302. Cuando ocurre un cambio a una carpeta de correo electrónico en el almacén de mensajes de correo electrónico de un usuario en el componente de cliente de correo electrónico, por ejemplo, se añade un mensaje de correo electrónico a la carpeta, la tabla de jerarquía profunda también se actualiza como se describió previamente. El cambio a la tabla de jerarquía profunda dispara una alerta de notificación 1305 a un componente de cliente de correo electrónico 501. Cuando una alerta de notificación se da como respuesta a la suscripción colocada por la solicitud 1301, no es parte de un ciclo de solicitud-respuesta explícito. De este modo, el uso del sistema de notificación proporcionado por la presente invención da como resultado un restante mucho menor para una red de correo electrónico . Una sola suscripción puede dar como resultado muchas notificaciones. En una modalidad, la alerta se entrega usando un mecanismo de transporte de red sin conexión, por ejemplo, User Datagram Protocol/Internet Protocol (ÜDP/IP) , pero se puede usar cualquier mecanismo de transporte de red conveniente. Como respuesta a la alerta, el componente de cliente de correo electrónico 501 envía una solicitud 1306 que contiene una operación remota (por ejemplo, ObtenerNotificación (GetNotification) ) al componente de servidor de correo electrónico 502. Como respuesta 1307, cualquier fila cambiada de la tabla de jerarquía profunda (es decir, las filas correspondientes a una carpeta cambiada que disparó la notificación) se envían al componente de cliente de correo electrónico 501. El componente de cliente de correo electrónico 501 emplea entonces operaciones remotas (por ejemplo, SynchFolder) para sincronizar solamente las carpetas que han cambiado. Múltiples componentes de cliente de correo electrónico se pueden suscribir para notificaciones de cambio asociadas con el mismo objeto de datos (por ejemplo, la misma carpeta de correo electrónico) , por ejemplo, para proporcionar funcionalidad colaborativa . Como se ilustra por la Figura 18, los componentes de cliente de correo electrónico 1801, 1802 y 1803 se suscriben para las notificaciones de cambio asociadas con el mismo objeto de datos (no mostrado) localizado en el componente de servidor 1804. El componente de cliente de correo electrónico 1803 envía una operación remota 1805 al componente de servidor de correo electrónico 1804 que da como resultado un cambio al objeto de datos. Como resultado del cambio, el componente de servidor de correo electrónico 1804 envía afuera notificaciones de cambio 1806, 1807 y 1808 a los componentes de cliente de correo electrónico 1801, 1802 y 1803. Las notificaciones de cambio pueden llevar poca información más allá de identificar el objeto de datos que ha cambiado de manera que, por ejemplo, puede no haber manera de que un componente de cliente de correo electrónico determine que fue la causa de un cambio particular. Si el objeto de datos es, por ejemplo, una carpeta de correo electrónico, las notificaciones de cambio 1806, 1807 y 1808 pueden dar como resultado cada componente de cliente de correo electrónico 1801, 1802 y 1803 iniciando la sincronización para la carpeta cambiada. Ya que el componente de cliente de correo electrónico 1803 fue, en este ejemplo, responsable del cambio, el resultado será una "sincronización nula". Por las razones previamente discutidas puede ser deseable eliminar las sincronizaciones que dan como resultado una "sincronización nula". Sin embargo, el comportamiento de las notificaciones descritas puede no siempre ser indeseable y en algunos componentes de cliente de correo electrónico pueden depender de esto. Un aspecto de la presente invención es proporcionar la capacidad de que un componente de cliente de correo electrónico configure una comportamiento de notificaciones de los componentes de servidor de correo electrónico de versión más reciente con el fin de mejorar el desempeño del protocolo mientras que al mismo tiempo proporcione componentes de cliente de correo electrónico de versión previa con comportamiento de notificaciones sin cambio . La Figura 19? representa el comportamiento de notificaciones que puede ser proporcionado por los componentes de servidor de correo electrónico de versión previa. La Figura 19B representa el comportamiento de notificación configurable de acuerdo con un aspecto de la presente invención. Si se desea, un componente de cliente de correo electrónico más reciente puede indicar a un componente de servidor de correo electrónico que es capaz del comportamiento de notificación en la Figura 19B, por ejemplo suministrando un marcador con una solicitud, en el ejemplo mostrado en la Figura 19B, un marcador de IGNORAR_PROPIO (IGNORE_OWN) . En el paso 1901, se selecciona el siguiente candidato del conjunto de suscriptores para ser notificado. En el paso 1904, se examina la suscripción para el marcador IGNORE_O N. Si el marcador no está presente, el paso 1904 se ramifica al paso 1902, donde se envía una notificación al suscriptor candidato. Si se encuentra el marcador, el paso 1904 se ramifica al paso 1905, en donde se examina de nuevo la suscripción para determinar si el suscriptor disparó esta notificación. Se puede hacer esta determinación, por ejemplo, examinando un identificador de sesión de comunicaciones ("identificador de sesión") de la sesión que se usó para colocar la suscripción. Un identificador de sesión, por ejemplo, puede comprende un identificador único global y un número en serie de seis bytes. La notificación también se examina para determinar la identificación de sesión asociada con su causa. Si las dos coinciden, entonces se suprime la notificación. El resultado es que un componente de cliente de correo electrónico que causó una notificación no recibirá también esa notificación. El subprocedimiento continúa al paso 1903, que se describe enseguida. Si el suscriptor no disparó la notificación, entonces la identificación de sesión asociada con la suscripción no es igual que la identificación de sesión asociada con la causa de la notificación, y el paso 1905 se ramifica al paso 1902, donde se envía la notificación. El proceso entonces continúa al paso 1903, donde se toma una determinación de si hay más suscriptores para ser notificados. Si los hay, el subprocedimiento regresa al paso 1901, de otro modo este subprocedimiento termina. Como se declaro anteriormente, un componente de cliente de correo electrónico que utiliza almacenamiento caché de mensaje de correo electrónico puede solicitar, por ejemplo via una operación remota, la sincronización de mensajes u otros objetos de datos entre un almacén de datos de cliente local y el almacén de datos disponible en el componente de servidor de correo electrónico. El componente de cliente de correo electrónico puede de manera similar solicitar que mensajes sean copiados del almacén de servidor al almacén de cliente. En cualquier caso, la solicitud puede hacerse usando un modo de transferencia rápida. Típicamente, cuando los mensajes u otros datos tales como archivos son solicitados para la sincronización o copia, la solicitud (por ejemplo, operación remota) incluye una indicación de todos los mensajes para los cuales se desea la sincronización. Esta lista se puede construir automáticamente por un componente de servidor de correo electrónico mediante, por ejemplo, utilizar una característica stateblob descrita anteriormente. Para los componentes de servidor de correo electrónico de versión previa (técnica anterior), un error en un mensaje u objeto de datos en una solicitud de operación remota causaría una falla en todos los artículos en la solicitud. Este proceso se muestra en la Figura 14?, donde una solicitud que contiene una operación remota (por ejemplo, FXPrepare) se transmite en el paso 1401 con un conjunto de identificación de mensajes diseñado para copiar o para sincronizar. Un mecanismo de transferencia rápida se establece en el componente de servidor de correo electrónico 502, y un identificador de transferencia rápida se transmite al componente de cliente de correo electrónico 501 en el paso 1402. El componente de cliente de correo electrónico 501 solicita entonces copiar o sincronizar los objetos de datos a través de una solicitud que contiene, por ejemplo, una operación remota FXGetBuffer (paso 1403) . Se presenta un error con uno o más de los mensajes u otros objetos de datos cuando el componente de servidor de correo electrónico 502 intenta abrir los mensajes solicitados. Ejemplos de errores incluyen un mensaje o un objeto de dato que está corrupto, una falla de servidor, el componente de servidor de correo electrónico 502 con la memoria llena. O un virus detectado para el objeto de datos. Después del error, el componente de servidor de correo electrónico 502 envía un error fatal de operación remota en los datos conducidos al componente de cliente de correo electrónico 501 en el paso 1404. Como tal, la sincronización falla, los mensajes dentro del conjunto de identificaciones de mensaje no se sincronizan ni se copian, y el stateblob o la información de actualización similar no es recibida por el componente de cliente de correo electrónico 501. El componente de cliente de correo electrónico 501 tiene entonces que solicitar la sincronización o copia de los objetos de datos en otro momento. Es posible que. Si no se fija un error en el componente de servidor de correo electrónico 502, los mensajes de error puede continuar siendo enviados, y los mensajes dentro del conjunto de identificadores de mensajes pueden nunca ser sincronizados ni copiados . De acuerdo con un aspecto de la presente invención, en vez de un error fatal de operación remota, un componente de servidor de correo electrónico más reciente puede enviar información de error con respecto al objeto de datos particular (por ejemplo, un mensaje de correo electrónico) de manera que sólo falle la sincronización para ese objeto de datos. Esta función permite que los mensajes u otros objetos de datos dentro de una operación remota u otra solicitud sean transmitidos o sincronizados o copiados aún si un mensaje u otro objeto de datos que tiene un error se incluye dentro de la respuesta. Como un ejemplo de cómo manejar un error especifico de objeto, un componente de servidor de correo electrónico más reciente puede enviar un mensaje de error en una corriente de datos para el objeto de datos que tiene un error de objeto. En este ejemplo, para facilidad de referencia, el error se conoce como FXErrorlnfo. Si se desea, como se describe adicionalmente más adelante, FXErrorlnfo puede incluir información tal como la identificación de mensaje para el objeto de datos que tiene el error, una información adicional con respecto a por qué falló el mensaje. La Figura 14B muestra una sincronización en la cual se presenta un error en un mensaje M3. El error da como resultado una respuesta FXGetBuffer 1405 que incluye el mensaje Mi y el mensaje M2, seguido por FXErrorInfo, y luego el mensaje M4. La información FXErrorInfo permite que el componente de cliente de correo electrónico 501 sepa cuál mensaje tuvo un error, y sincronice todos los demás mensajes dentro de la respuesta. Si el mensaje de error FXErrorInfo incluye información acerca de la razón de error, la información puede actuar al respecto de conformidad con el componente de cliente por ejemplo, exhibiendo un mensaje de error al usuario. La siguiente tabla muestra un ejemplo del formato que puede tomar el FXErrorInfo: FXErrorlnfo Nombre de Tipo de Atributo Notas Atributo Versión WORD La versión de esta estructura Código de error DWORD Identificación MID El tipo MID de mensaje comprende un identificador único global (GUID) y un número de serie de seis bytes. Esta es la identificación de mensaje del mensaje que causo el error. Cero más atributos puede añadirse aquí. Tamaño de Campo ULONG El tamaño del Auxiliar arreglo a seguir. Campo Auxiliar Arreglo de BYTES Un arreglo no estructurado para comunicar detalles de error.

Como puede verse, el formato de ejemplo incluye un atributo de versión, un código de error, y una identificación de mensaje. Además, si se desea, se pueden añadir uno o más atributos. Además, como se declaró anteriormente, un campo auxiliar se puede definir para comunicar detalles de error. Como tal, un atributo se puede definir para dictar el tamaño de campo de los detalles de error (por ejemplo, un arreglo) y se puede proporcionar un campo, el cual puede ser, por ejemplo, un arreglo no estructurado para comunicar los detalles de error. Como se declaró anteriormente, los detalles de error se pueden manejar como se desee por el componente de cliente de correo electrónico 501. El FXErrorInfo permite que la sincronización de la primera respuesta se complete, por ejemplo dando como resultado un stateblob u otra información proporcionada al componente de cliente de correo electrónico 501. Debido a que el componente de cliente de correo electrónico ahora se sincroniza a través del mensaje M , la siguiente solicitud 1406 para la sincronización puede dar como resultado una respuesta 1407 que tiene los mensajes después de M4 (por ejemplo, 5 y M6) · Al indicar que un componente de cliente de correo electrónico 501 es una versión más reciente, y asi es capaz de manejar el mensaje FXErrorInfo, se puede definir una bandera, por ejemplo, FXRecoverMode, que puede transmitirse con una operación remota que solicita la sincronización o la copia. Se pueden usar otras indicaciones para el componente de cliente de correo electrónico 501 para comunicar al componente de servidor de correo electrónico 502 que es capaz de manejar el mensaje de FXErrorInfo. Cuando el componente de servidor de correo electrónico 502 envía uno o más mensajes u otros objetos de datos al componente de cliente de correo electrónico 501, la corriente de datos para el componente de cliente de correo electrónico pueden separarse o definirse mediante etiquetas de propiedades (por ejemplo, ptags) . Por ejemplo, una lista de mensajes puede incluir para cada mensaje un ptag de mensaje inicial y un ptag de mensaje final. Entre los ptags incial y final puede haber una ptag de lista de propiedades y una ptag de temas, que pueden tener una propiedad de una cadena. El ptag de tema puede ser seguido por el mismo tema. Otras etiquetas de propiedades se pueden incluir. En el caso en donde se presenta un error al transmitir un mensaje, el FXErrorInfo se puede proporcionar como un ptag, y puede tener propiedades binarias tales como se definen por la tabla anterior. Un ejemplo de corriente de datos se presenta enseguida que tiene tanto un mensaje con éxito como un mensaje en el cual se presenta un error. En el caso en el que se presenta error, el ptag del mensaje final no se usa para ese mensaje particular ni el ptag FXErrorInfo es el último ptag para ese mensaje. ptagMensajeListalnicio ptagMensaj eListalnicio ptagPropLista ptagAsunto [PT_CADENA] "Re: Su correo electrónico" ptagMensaj eFin ptagMensaj e nicio ptagFXErrorlnfo [PT_BINARIO] [Contenido como se describe mediante la tabla] ptagMensagelnicio ptagMensaj eFin ptagMensa eListaFin La Figura 15A muestra los pasos que un componente de servidor de correo electrónico 502 puede utilizar para transferir mensajes a un componente de cliente de correo electrónico de versión previa 501. Comenzando en el paso 1501, se prepara este conjunto de mensajes, por ejemplo colocando el conjunto de mensajes en el almacén de datos de transferencia rápida. En el paso 1502, el mensaje comienza su conexión hacia fuera, por ejemplo inmediatamente después de haber sido colocado, en la memoria intermedia de envió del componente de servidor de correo electrónico 502. Si se presenta un error cuando está saliendo el mensaje, entonces un error fatal de operación remota sale del componente de cliente de correo electrónico 501 en el paso 1504. Entonces termina el subprocedimiento . Si, cuando está saliendo el mensaje, no se presenta un error, entonces en el paso 1503 se toma una determinación de si hay más mensajes en el conjunto. Si los hay, entonces el proceso regresa al paso 1502, en donde el siguiente mensaje es sacado. Si no, entonces termina el subprocedimiento.

La Figura 15B muestra un procedimiento para manejar un conjunto de mensajes por una versión más reciente de un componente de servidor de correo electrónico 502. Los pasos realizados son diferentes dependiendo de si el componente de cliente de correo electrónico es una versión más reciente o una versión previa. Los pasos 1501, 1504 son pasos realizados con un componente de cliente de correo electrónico de versión previa, y son iguales a los pasos que tienen los mismos numerales de referencia en el párrafo anterior. Si, en el paso 1502, se encuentra un error al conducir el mensaje, entonces se toma una determinación en el paso 1505 y la solicitud incluye un marcador, tal como FXRecoverMode . Si la solicitud contiene el marcador, entonces el componente de cliente de correo electrónico 501 es una versión más reciente, y el paso 1505 se ramifica al paso 1506, donde el FXErrorlnfo se sale hacia el componente de cliente de correo electrónico 501. El proceso puede continuar al paso 1503. Si la solicitud no incluye el marcador, entonces el paso 1505 se ramifica al paso 1504, donde se conduce hacia fuera un error fatal de operación remota. Entonces termina el subprocedimiento . Como puede verse, la presencia del marcador en la solicitud permite que el proceso de conducción continúe permitiendo la salida del FXErrorlnfo desde fallar y enviar un error fatal de operación remota. El marcador es enviado por una versión más reciente de un componente de cliente de correo electrónico 501. Las versiones previas de los componentes de cliente de correo electrónico no incluyen el marcador, y de este modo un error da como resultado la salida de un error fatal de operación remota, como se describió anteriormente . Si se desea, en una modalidad alternativa, el mensaje de error (por ejemplo, FXErrorInfo) puede ser enviado para propiedades particulares de un mensaje u otro objeto de datos en vez de para un mensaje entero. Por ejemplo, FXErrorInfo puede ser enviado para el cuerpo de un mensaje, o para un anexo a un mensaje. El componente de cliente de correo electrónico 501 puede entonces sincronizar o copiar propiedades que se envían con éxito sin un error, y sólo las propiedades que tienen errores no se sincronizan ni se copian . Algunas veces, un mensaje u otro objeto de datos pueden ser del tamaño suficiente para que se extienda a múltiples respuestas de FXGetBuffer. Para manejar estos mensajes, el componente de cliente de correo electrónico 501 puede incluir lógica de regresar hacia atrás de manera que pueda disponer de cualquier mensaje recibido parcialmente y luego proceder a recibir adecuadamente otros mensajes después de recibir un mensaje de error. A veces, puede ser deseable que un componente de cliente de correo electrónico esté provisto de retroalimentación con respecto al avance de la copia o sincronización de objetos de datos tales como mensajes de correo electrónico. De acuerdo con un aspecto de la presente invención, una versión más reciente de un componente de cliente de correo electrónico 501 puede indicar que es capaz de mane ar modos de avance, por ejemplo enviando un marcador, tal como un PR0GRES0_M0D0 (PR0GRESS_M0DE) a un componente de servidor de correo electrónico 502 cuando se solicita la sincronización o copia de objetos de datos. Como respuesta, una versión más reciente de un componente de servidor de correo electrónico 502 puede enviar una variedad de información junto con mensajes, tales como el -tamaño total de todos los mensajes, el número total de mensajes, y el tamaño total de cada mensaje, o cualquier otra combinación de éstas. Por ejemplo, como se muestra en la Figura 16A, para una versión previa de componente de cliente de correo electrónico 501, como respuesta a una solicitud de transferencia rápida (1601 y 1603) para un conjunto de mensajes, el componente de cliente de correo electrónico 501 recibe los mensajes. En la Figura 16A, los mensajes son recibidos en dos respuestas 1604 y 1606. En los componentes de cliente de correo electrónico de versión previa 501 que utilizan un mecanismo de transferencia rápida, no se proporciona una indicación de avance de los mensajes que están siendo conducidos hacia el cliente. Sin embargo, como se muestra en la Figura 16B, es una respuesta 1607 a una solicitud de un mensaje establecido por el componente de cliente de correo electrónico, el componente de servidor de correo electrónico 502 puede proporcionar un número total de objetos de datos para ser transferidos, y el tamaño total de todos los objetos de datos para ser transferidos. Esta información es representada por "Paii" en la Figura 16B. Una versión más reciente de un componente de servidor de correo electrónico 502 también puede suministrar el tamaño de cada mensaje, indicado mediante "??, P2, P3,..." en la Figura 16B. Además, si se desea, la información asociada con cada mensaje y con el grupo entero de mensajes puede incluir información adicional con respecto a que si cada mensaje es FAI o un mensaje de correo electrónico real. En una modalidad, la información representada por "Paii" en la Figura 16B siempre se mide como respuesta a una solicitud de transferencia rápida, aún si cero objetos de datos son transferidos con el fin de simplificar el procesamiento de la corriente de datos. Un ejemplo de un formato para el tamaño y el número de todos los objetos de datos que están siendo transferidos se muestra en la siguiente tabla.

IncrSyncProgressMode Nombre de Atributo Tipo de Atributo Notas Versión WORD La versión de (por ejemplo, un esta estructura. entero de 16 bits) cAssocMsgs DWORD El número de (por e emplo, un objetos de datos entero de 32 FAI que van a bits) ser transferidos . UTotalAssocMsgSize QWORD El tamaño total (por ejemplo, un de los objetos entero de 64 de datos FAI bits) para ser transferidos . cNormalMsgs DWORD El número de mensajes de correo electrónico para ser transferidos . UTotalNormalMsgSize QWORD El tamaño total de todos los mensajes de correo electrónico para ser transferidos .

Como puede verse, atributos separados pueden definirse para el número de objetos de datos FAI, el tamaño total de todos los objetos de datos FAI, el número de mensajes de correo electrónico para ser transferidos, y el tamaño total de todos los mensajes de correo electrónico para ser transferidos . Otras combinaciones y atributos adicionales se pueden añadir al formato como se desee.

La siguiente tabla muestra un formato para el tamaño y otra información que puede ser suministrada con cada mensaje .

Como se puede verse, el formato incluye el tamaño del siguiente mensaje y si el siguiente mensaje es o no FAI . Las Figuras 17A y 17B muestran los pasos para conducir un conjunto de mensajes de acuerdo con una versión previa de los componentes de correo electrónico, y una versión más reciente de los componentes de correo electrónico, respectivamente. Los pasos en la Figura 17A son similares a los pasos 1501-1503 en la Figura 15A. Para la Figura 17B, el marcador PROGRESO_MODO ha sido enviado, por ejemplo con una operación remota, mediante cuando menos un componente de correo electrónico más reciente 501. Después de que el conjunto de mensajes se prepara en el paso 1701, se toma una determinación de si el marcador está presente. Si es asi, entonces los totales de los datos de avance se envían en el paso 1702, y el proceso entonces sigue al paso 1503, en donde el primer mensaje es conducido. Si el marcador no está presente, entonces el paso 1701 se ramifica directamente al paso 1502. Después de que el primer mensaje es conducido, el proceso avanza al paso 1703, en donde se toma una determinación si el marcador está disponible. Si es asi, entonces el paso 1703 se ramifica al paso 1704, en donde se conducen los datos de avance por mensaje. El proceso entonces sigue al paso 1503, descrito anteriormente. Si el marcador no está disponible, el paso 1703 se ramifica directamente al paso 1503. Un ejemplo de la corriente de datos para un componente de servidor más reciente que envía datos a un componente de cliente más reciente se presenta más adelante. La corriente de datos es similar a la corriente de datos descrita anteriormente, pero adicionalmente incluye ptags datos de totales de avance (ptaglncrSyncProgressMode) , lo cual puede tener, por ejemplo, propiedades binarias. Además, para cada mensaje, los datos de avance por mensaje se suministran, por ejemplo, como: ptagIncrSyncProgresoModoPerMsg . PtaglncrSyncProgresoModo [PT__BINARIO] [Contenido como se describe por la tabla] ptagMensaj eListalnicio PtagIncrSyncProgresoModoPerMsg [ PT_BINARIO] [Contenido como se describe por la tabla] ptagMensajelnicio ptagPropLista ptagAsunto [PT_CADENA] "Re: Su correo electrónico" ptagMensaj eFin PtagIncrSyncProgresoModoPerMsg [PT_BINARIO] [Contenido como se describe por la tabla] ptagMensajelnicio ptagMensajeFin PtagIncrSyncProgresoModoPerMsg [PT_BINARIO] [Contenido como se describe por la tabla] ptagMensajelnicio ptagMensaj eFin ptagMensajeListaFin En el ejemplo mostrado, los ptags incluyendo los datos de totales de avance (ptaglncrSyncProgresoModo) y los ptags para los datos de avance de mensaje (ptaglncrSyncProgresoModoPerMgs) se localizan antes de la lista de mensajes, y antes de cada mensaje, respectivamente. Sin embargo, la estructura de la conducción de los objetos de datos se puede revisar de manera que los datos de avance se puedan incluir dentro de los mensajes o dentro de la lista de mensajes. También se posible revisar la estructura de la conducción de los objetos de datos con el fin de eliminar ptags que delimitan los mensajes y/o listas de mensajes completamente . ün componente de cliente de correo electrónico que recibe los datos de avance puede utilizar estos datos para determinar el avance de la sincronización o copia de los objetos de datos a partir del componente de servidor de correo electrónico, y puede utilizar los datos de avance por mensaje para determinar el avance de cada mensaje individual. Esta información puede ser útil, por ejemplo, para monitorear información en tiempo real acerca del avance de una sincronización . Hay varios conjuntos de caracteres diferentes que se pueden usar para almacenar un mensaje de correo electrónico u otros objetos de datos. Por ejemplo, ASCII es el usado más comúnmente para almacenar caracteres de idioma inglés. Sin embargo, el ASCII no es suficiente para almacenar caracteres para todos los idiomas, debido a que se basa en caracteres de 8 bits. De este modo el código ASCII se puede usar para solamente 256 caracteres, lo cual es suficiente para el inglés pero no suficiente para idiomas que tienen más caracteres. Por otro lado, Unicode es un conjunto de caracteres que utiliza 16 bits (dos bytes) para cada carácter, y por lo tanto es capaz de incluir más caracteres que el ASCII. Unicode puede tener 65,536 caracteres, y por lo tanto se puede usar para codificar casi todos los idiomas del mundo. Unicode incluye el conjunto de caracteres ASCII dentro de él . En general, las versiones previas de los componentes de cliente de correo electrónico 501 tienen una página de código diseñada, o conjunto de caracteres y/o lenguaje asociado con las mismas. Por ejemplo, una versión particular de un componente de cliente de correo electrónico 501 puede tener una página de código de alemán, y otra versión puede tener una página de código ANSI. A veces, puede ser deseable para un componente de cliente de correo electrónico 501 recibir correos electrónicos en conjunto de caracteres distintos de la página de código designado. De acuerdo con un aspecto de la presente invención, un componente de cliente más reciente puede forzar a un componente de servidor de correo electrónico para proporcionar todos los correos electrónicos en Unicode. En cuanto son recibidos los correos electrónicos por el componente de cliente de correo electrónico 501, los correos electrónicos Unicode pueden ser convertidos a la página de código de cliente, o pueden alternativamente mantenerse en formato Unicode . Para indicar que un componente de cliente de correo electrónico 501 pide que los correos electrónicos le sean proporcionados en Unicode, el componente de cliente de correo electrónico 501 puede, por ejemplo, proporcionar un marcador, tal como FORCEUNICODE, al componente de servidor de correo electrónico 502. El marcador se puede proporcionar con una solicitud, tal como una operación remota. Si el componente de servidor de correo electrónico 502 es una versión más reciente, el componente de servidor de correo electrónico 502 puede proporcionar una versión Unicode del correo electrónico, si está disponible, o puede convertir mensajes de correo electrónico en otros conjuntos de caracteres en Unicode . La Figura 20 muestra los pasos para proporcionar un conjunto de caracteres particulares para un mensaje de acuerdo con un aspecto de la presente invención. Comenzando en el paso 2001, el componente de servidor de correo electrónico 502 recupera un mensaje de su almacén de datos. En el paso 2002, se toma una determinación de si está presente el marcador FORCEUNICODE. Si no es asi, entonces el paso 2002 se ramifica al paso 2003, en donde el componente de servidor de correo electrónico 502 proporciona el mensaje de correo electrónico en la página de código designada del componente de cliente de correo electrónico, convirtiéndolo si es necesario. Si está presente el marcador FORCEUNICODE entonces el paso 2002 se ramifica al paso 2004, en donde se toma una determinación de si el mensaje se almacena como Unicode. Si es asi, el paso 2004 se ramifica al paso 2005, en donde el mensaje se proporciona al componente de cliente de correo electrónico 501 en el conjunto de caracteres Unicode. Si el mensaje no es almacenado en Unicode, entonces el paso 2004 se ramifica al paso 2006 en donde el mensaje se convierte en Unicode, y entonces el proceso continúa al paso 2005, en donde el mensaje se proporciona al componente de cliente de correo electrónico en Unicode. Todas las referencias, incluyendo las publicaciones, solicitudes de patente, y patentes, citados en la presente y mediante la presente incorporadas por referencia al mismo grado que si cada referencia fuera individualmente y específicamente indicada para ser incorporada por referencia y fuera presentada por entero en la presente. El uso de los términos "un" y "una" y "el", "la", "los" y similares referentes en el contexto para describir la invención (especialmente en el contexto de la siguientes reivindicaciones) se considerará que cubren tanto el singular como el plural, a menos que se indique otra cosa en la presente o claramente el texto lo contradiga. Los términos "comprende", "tiene", "incluyendo" y "conteniendo" se considerará como términos de extremos abiertos (es decir, que significa "incluyendo, pero sin limitarse a,") a menos que se anote otra cosa. La citación de rangos de valores en la presente únicamente pretende servir como método económico de referirse individualmente a cada valor separado que cabe dentro del rango, a menos que se indique otra cosa en la presente, y cada valor separado se incorpora en la especificación como si se citara individualmente en la presente. Todos los métodos descritos en la presente se pueden realizar en cualquier orden conveniente a menos que se indique otra cosa en la presente o de otro modo se contradiga claramente por contexto. El uso de cualquier y todos los ejemplos o el lenguaje ejemplar (por ejemplo, "tal como") proporcionado en la presente, pretende únicamente iluminar mejor la invención y no poner una limitación en el alcance de la invención a menos que se reclame otra cosa. Ningún lenguaje en la especificación deberá considerarse como indicador de elemento no reclamado como esencial a la práctica de la invención. Las modalidades preferidas de esta invención se describen en la presente, incluyendo el mejor modo conocido por los inventores para llevar a cabo la invención. Las variaciones de esas modalidades preferidas pueden ser aparentes para los expertos en la técnica después de la lectura de la descripción anterior. Los inventores esperan que los expertos empleen estas variaciones como sea adecuado, y los inventores pretenden que la invención se practique de otro modo que como se describe específicamente en la presente. De conformidad con lo anterior, esta invención incluye todas las modificaciones equivalentes de la materia objeto citada en las reivindicaciones anexas a la presente como lo permite la ley aplicable. Más aún, cualquier combinación de los elementos anteriormente descritos en todas las variaciones posibles de los mismos está abarcado por la invención a menos que se indique otra cosa en la presente o se contradiga claramente otra cosa por el contexto.

Claims

REIVINDICACIONES

1. Un paquete de datos incorporado en un medio legible por computadora que comprende: un primer campo de datos que identifica un componente de cliente de correo electrónico; un segundo campo de datos que incluye una solicitud de una pluralidad de objetos de datos de correo electrónico; y un tercer campo de datos que incluye una indicación de que el componente de cliente de correo electrónico es capaz de manejar un objeto de datos del correo electrónico que tiene un error.

2. El paquete de datos de la reivindicación 1, en donde la indicación comprende un marcador incluido con la solicitud.

3. El paquete de datos de la reivindicación 1, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localiza los objetos de datos de correo electrónico.

4. El paquete de datos de la reivindicación 1, en donde la solicitud comprende una solicitud de una copia de mensajes de correo electrónico.

5. ün medio legible por computadora que tiene instrucciones ejecutables por computadora, las instrucciones comprenden: recibir, a partir de un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de datos correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar un objeto de datos de correo electrónico que tiene un error; y como respuesta a la solicitud y a la indicación, recuperar la pluralidad de objetos de datos de correo electrónico; y para cada uno de los objetos de datos de correo electrónico : si no se presenta el error al abrir el objeto de datos de correo electrónico, transmitir el objeto de datos de correo electrónico al componente de cliente de correo electrónico, y si se presenta un error al abrir el objeto de datos de correo electrónico, transmitir un mensaje de error al componente de cliente de correo electrónico.

6. El medio legible por computadora de la reivindicación 5, en donde el mensaje de error comprende información de la versión del objeto de datos de correo electrónico .

7. El medio legible por computadora de la reivindicación 6, en donde la información de la versión comprende un entero de 16 bits.

8. El medio legible por computadora de la reivindicación 5, en donde el mensaje de error comprende información de identificación del objeto de datos de correo electrónico.

9. El medio legible por computadora de la reivindicación 8, en donde la información de identificación comprende un entero de 32 bits.

10. El medio legible por computadora de la reivindicación 8, en donde la información de identificación comprende un identificador único globalmente (GUID) y un número de serie de 6 bytes.

11. El medio legible por computadora de la reivindicación 5, en donde el mensaje de error comprende información con respecto al error.

12. El medio legible por computadora de la reivindicación 11, en donde la información con respecto al error incluye el tamaño y un arreglo para comunicar detalles de error.

13. El medio legible por computadora de la reivindicación 5, en donde la indicación comprende un marcador incluido con la solicitud.

14. El medio legible por computadora de la reivindicación 5, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localizan los objetos de datos de correo electrónico.

15. El medio legible por computadora de la reivindicación 5, en donde la solicitud comprende una solicitud de una copia de los mensajes de correo electrónico.

16. Un medio legible por computadora que tiene instrucciones ejecutables por computadora, las instrucciones comprenden: enviar, desde un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de datos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar un objeto de datos de correo electrónico que tiene un error; y para cada uno de los objetos de datos de correo electrónico : si el objeto de datos de correo electrónico no contiene un error, recibir el objeto de datos de correo electrónico y copiar el objeto de datos de correo electrónico en el componente de cliente de correo electrónico, y si el objeto de datos de correo electrónico si contiene un error, recibir un mensaje de error.

17. El medio legible por computadora de la reivindicación 16, en donde el mensaje de error comprende una identificación para el objeto de datos de correo electrónico.

18. El medio legible por computadora de la reivindicación 16, en donde el mensaje de error comprende información con respecto al error.

19. El medio legible por computadora de la reivindicación 16, en donde la indicación comprende un marcador incluido con la solicitud.

20. El medio legible por computadora de la reivindicación 16, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localizan los objetos de datos de correo electrónico.

21. El medio legible por computadora de la reivindicación 16, en donde la solicitud comprende una solicitud de una copia de mensajes de correo electrónico.

22. Un paquete de datos incorporado en un medio legible por computadora que comprende: un primer campo de datos que identifica información de identificación con respecto a un objeto de datos de correo electrónico; y un segundo campo de datos que incluye un código de error para el objeto de datos de correo electrónico.

23. El paquete de datos de la reivindicación 22, que además comprende un tercer campo de datos que representa información de versión del objeto de datos de correo electrónico.

24. El paquete de datos de la reivindicación 23, en donde el tercer campo de datos comprende un entero de 16 bits .

25. El paquete de datos de la reivindicación 22, que además comprende un tercer campo de datos que representa información de identificación para el objeto de datos de correo electrónico.

26. El paquete de datos de la reivindicación 25, en donde el tercer campo de datos comprende un entero de 32 bits .

27. El paquete de datos de la reivindicación 25, en donde el tercer campo de datos comprende un identificador único globalmente (GUID) y un número de serie de seis bytes.

28. El paquete de datos de la reivindicación 22, que además comprende un tercer campo de datos que incluye información con respecto a un error relacionado con el código de error.

29. El paquete de datos de la reivindicación 28, en donde la información con respecto al error incluye un tamaño de un arreglo para comunicar detalles de error.

30. ün paquete de datos incorporado en un medio legible por computadora que comprende: un primer campo de datos que identifica un componente de cliente de correo electrónico un segundo campo de datos que incluye una solicitud de una pluralidad de objetos de datos de correo electrónico; un tercer campo de datos que incluye una indicación de que el componente de cliente de correo electrónico es capaz de manejar datos en modo de avance.

31. El paquete de datos de la reivindicación 30, en donde los datos en modo avance incluye un tamaño de cada uno de los objetos de datos de correo electrónico.

32. El paquete de datos de la reivindicación 30, en donde la indicación comprende un marcador incluido con la solicitud.

33. El paquete de datos de la reivindicación 30, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localizan los objetos de datos de correo electrónico.

34. El paquete de datos de la reivindicación 30, en donde la solicitud comprende una solicitud de una copia de mensajes de correo electrónico.

35. El paquete de datos de la reivindicación 30, en donde los datos en modo avance incluye el tamaño de la pluralidad de los objetos de datos.

36. El paquete de datos de la reivindicación 30, en donde los datos en modo avance incluyen los números de objetos de información asociada a la carpeta (FAI) de una pluralidad.

37. El paquete de datos de la reivindicación 36, en donde los datos en modo avance incluye el tamaño de los objetos de información asociada a la carpeta totales (FAI) en la pluralidad.

38. El paquete de datos de la reivindicación 30, en donde los datos en modo avance incluyen el número de mensajes de correo electrónico en la pluralidad de objetos de datos de correo electrónico.

39. El paquete de datos de la reivindicación 38, en donde los datos en modo avance incluyen el tamaño de los mensajes de correo electrónico totales en la pluralidad.

40. El paquete de datos de la reivindicación 30, en donde los datos en modo avance además incluyen si cada objeto es un objeto de información asociada a carpeta (FAI) .

41. Un medio legible por computadora que tiene instrucciones ejecutables por computadora, las instrucciones comprenden : recibir, a partir de un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de datos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar datos en modo avance; como respuesta a la solicitud y a la indicación, recuperar la pluralidad de objetos de datos de correo electrónico; y proporcionar datos en modo avance al componente de cliente de correo electrónico junto con la pluralidad de objetos de datos, los datos en modo avance comprenden una serie de cada uno de los objetos de datos de correo electrónico .

42. El medio legible por computadora de la reivindicación 41, en donde la indicación comprende un marcador incluido con la solicitud.

43. El medio legible por computadora de la reivindicación 41, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localizan los objetos de datos de correo electrónico.

44. El medio legible por computadora de la reivindicación 41, en donde la solicitud comprende una solicitud de una copia de mensajes de correo electrónico.

45. El medio legible por computadora de la reivindicación 41, en donde los datos en modo avance además incluyen el tamaño de la pluralidad de los objetos de datos.

46. El medio legible por computadora de la reivindicación 41, en donde los datos en modo avance además incluyen el número de objetos de información asociada a la carpeta (FAI) en la pluralidad.

47. El medio legible por computadora de la reivindicación 46, en donde los datos en modo avance además incluyen el tamaño de los objetos de información asociada a la carpeta totales (FAI) en la pluralidad.

48. El medio legible por computadora de la reivindicación 41, en donde los datos en modo avance además incluyen el número de mensajes de correo electrónico en la pluralidad de objetos de datos de correo electrónico.

49. El medio legible por computadora de la reivindicación 48, en donde los datos en modo avance además incluyen el tamaño de los mensajes de correo electrónico totales en la pluralidad.

50. El medio legible por computadora de la reivindicación 41, en donde los datos en modo avance además incluyen si cada objeto es un objeto de información asociada a carpeta (FAI) .

51. Un medio legible por computadora que tiene instrucciones ejecutables por computadora, las instrucciones comprenden : recibir, a partir de un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de datos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar datos en modo avance; como respuesta a la solicitud y a la indicación, recuperar la pluralidad de objetos de datos de correo electrónico; y proporcionar datos en modo avance al componente de cliente de correo electrónico junto con la pluralidad de objetos de datos, los datos en modo avance comprenden un tamaño de la pluralidad de los objetos de datos de correo electrónico .

52. El medio legible por computadora de la reivindicación 51, en donde la indicación comprende un marcador incluido con la solicitud.

53. El medio legible por computadora de la reivindicación 51, en donde la solicitud comprende una solicitud de sincronización de una carpeta en la cual se localizan los objetos de datos de correo electrónico.

54. El medio legible por computadora de la reivindicación 51, en donde la solicitud comprende una solicitud de una copia de mensajes de correo electrónico.

55. El medio legible por computadora de la reivindicación 51, en donde los datos en modo avance además incluyen el tamaño de cada uno de la pluralidad de los objetos de datos.

56. El medio legible por computadora de la reivindicación 51, en donde los datos en modo avance además incluyen el número de objetos de información asociada a la carpeta (FAX) en la pluralidad.

57. El medio legible por computadora de la reivindicación 56, en donde los datos en modo avance además incluyen el tamaño de los objetos de información asociada a la carpeta total (FAI) en la pluralidad.

58. El medio legible por computadora de la reivindicación 51, en donde los datos en modo avance además incluyen el número de mensajes de correo electrónico en la pluralidad de objetos de datos de correo electrónico.

59. El medio legible por computadora de la reivindicación 58, en donde los datos en modo avance además incluyen el tamaño de los mensajes de correo electrónico totales en la pluralidad.

60. El medio legible por computadora de la reivindicación 51, en donde los datos en modo avance además incluyen si cada objeto es un objeto de información asociada a carpeta (FAI) .

61. Un método implementado por computadora que comprende : enviar, a partir de un componente de cliente de correo electrónico, una solicitud de una pluralidad de objetos de datos de correo electrónico y una indicación de que el componente de cliente de correo electrónico es capaz de manejar datos en modo avance; en un componente de servidor de correo electrónico, como respuesta a la solicitud y la indicación, recuperar la pluralidad de objetos de datos de correo electrónico y datos en modo avance para la pluralidad de objetos de datos de correo electrónico; y en el componente de cliente de correo electrónico, recibir los datos en modo avance y utilizar los datos en modo avance para monitorear el avance de la transmisión de la pluralidad de objetos de datos al componente de cliente de correo electrónico.

62. El método de la reivindicación 61, en donde los datos en modo avance comprenden un tamaño de la pluralidad de objetos de datos de correo electrónico.

63. El método de la reivindicación 61, en donde los datos en modo avance comprenden el tamaño de cada uno de la pluralidad de objetos de datos.

64. El método de la reivindicación 61, en donde los datos en modo avance comprenden el número de objetos de información asociada a la carpeta (FAI) en la pluralidad.

65. El método de la reivindicación 64, en donde los datos en modo avance comprenden el tamaño de los objetos de información asociada a la carpeta total (FAI) en la pluralidad.

66. El método de la reivindicación 61, en donde los datos en modo avance comprenden el número de mensajes de correo electrónico en la pluralidad de objetos de datos de correo electrónico.

67. El método de la reivindicación 66, en donde los datos en modo avance comprenden el tamaño de los mensajes de correo electrónico totales en la pluralidad.

68. El método de la reivindicación 61, en donde los datos en modo avance además incluyen si cada objeto es un objeto de información asociada a la carpeta (F7AI) .

69. ün medio legible por computadora que tiene instrucciones ejecutables por computadora, las instrucciones comprenden: recibir, a partir de un componente de cliente de correo electrónico, una pluralidad de subsolicitudes dentro de una solicitud, cada una de las subsolicitudes solicitando una operación en un componente de servidor de correo electrónico y que incluye información de tamaño; y como respuesta a cada subsolicitud: si la información de tamaño incluye un limite de tamaño dentro de un rango esperado por el componente de servidor de correo electrónico, entonces limitar una respuesta al limite del tamaño; y si la información de tamaño incluye un limite de tamaño fuera del rango esperado por el componente de servidor de correo electrónico, entonces buscar un nuevo limite de tamaño en la información de tamaño.

70. El medio legible por computadora de la reivindicación 69, que además comprende, si la información de tamaño incluye un limite de tamaño fuera del rango esperado por el componente del servidor de correo electrónico, llenar una memoria intermedia para el componente de servidor de correo electrónico con la respuesta.

71. Un método implementado por computadora, que comprende : en un componente de cliente de correo electrónico: crear una pluralidad de subsolicitudes dentro de una solicitud, cada una de las subsolicitudes solicitando una operación en un componente de servidor de correo electrónico e incluyendo información de tamaño; y enviar la solicitud a un componente de servidor de correo electrónico; en un componente de servidor de correo electrónico: recibir la solicitud; y como respuesta a cada subsolicitud: si la información de tamaño incluye un limite de tamaño dentro del rango esperado por el componente de servidor de correo electrónico, entonces limitar una respuesta al limite de tamaño, y si la información de tamaño incluye un limite de tamaño fuera del rango esperado por el componente de servidor de correo electrónico, entonces buscar un nuevo limite de tamaño en la información de tamaño.

72. El método de la reivindicación 71, que además comprende, si la información de tamaño incluye un limite de tamaño fuera de un rango esperado por el componente de servidor de correo electrónico, llenar una memoria intermedia para el componente del servidor de correo electrónico con la respuesta.