ES2353225T3 - Sistema de distribuciã“n y sincronizaciã“n de correo electrã“nico (e-mail) de acceso directo con notificaciã“n de fuera de cobertura. - Google Patents
Sistema de distribuciã“n y sincronizaciã“n de correo electrã“nico (e-mail) de acceso directo con notificaciã“n de fuera de cobertura. Download PDFInfo
- Publication number
- ES2353225T3 ES2353225T3 ES08150922T ES08150922T ES2353225T3 ES 2353225 T3 ES2353225 T3 ES 2353225T3 ES 08150922 T ES08150922 T ES 08150922T ES 08150922 T ES08150922 T ES 08150922T ES 2353225 T3 ES2353225 T3 ES 2353225T3
- Authority
- ES
- Spain
- Prior art keywords
- coverage
- messages
- worker
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/58—Message adaptation for wireless communication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un sistema de comunicaciones (20) que comprende: un motor (22) de red, capaz de funcionar para comunicarse con una pluralidad de dispositivos de comunicaciones inalámbricos y móviles (38) suscritos por un usuario, y capaz de funcionar para determinar cuándo un dispositivo de comunicaciones inalámbrico y móvil (38) está fuera de cobertura o se ha desconectado o apagado y es incapaz de comunicarse con el motor (22) de red; y un servidor de acceso directo (42), capaz de funcionar con el motor (22) de red para consultar o examinar buzones de correo electrónico (48) de usuarios y recuperar mensajes electrónicos de los buzones de correo electrónicos, e impulsar o hacer pasar cualesquiera mensajes electrónicos a través del motor (22) de red a dispositivos de comunicaciones inalámbricos y móviles (38) suscritos por usuario y seleccionados, caracterizado por que dicho servidor de acceso directo (42) es capaz de funcionar para suspender el examen de los buzones de correo electrónico de usuario cuando se ha determinado que un dispositivo de comunicaciones inalámbrico y móvil (38) asociado con el usuario está fuera de cobertura o se ha desconectado y es incapaz de comunicarse, a fin de conservar los recursos de examen dentro del servidor de acceso directo (42).
Description
Sistema de distribución y sincronización de
correo electrónico ("email") de acceso directo con notificación
de fuera de cobertura.
Esta Solicitud está basada en la Solicitud
provisional previa depositada con Número de Serie 60/911.611,
depositada el 13 de abril de 2007.
La presente invención se refiere al campo de los
sistemas de comunicaciones y, más particularmente, a sistemas de
comunicaciones de correo electrónico ("email") y a métodos
relacionados.
El correo electrónico ("email") se ha
convertido en una parte integral de las comunicaciones de empresa y
personales. De esta forma, muchos usuarios tienen múltiples cuentas
de correo electrónico para uso laboral y doméstico. Además, con la
creciente disponibilidad de dispositivos celulares e inalámbricos de
red de área local (LAN -"local area network") que son capaces
de enviar y recibir correos electrónicos, muchos usuarios acceden
de forma inalámbrica a correos electrónicos desde buzones de correo
almacenados en diferentes servidores de almacenamiento de correo
electrónico (por ejemplo, un servidor de almacenamiento de correo
electrónico corporativo, Yahoo, Hotmail, AOL, etc.).
Con todo, la distribución y la sincronización a
través de múltiples buzones de correo y por redes inalámbricas
puede ser ciertamente un desafío, particularmente cuando esto se
hace a gran escala, para un gran número de usuarios. Por ejemplo,
pueden configurarse diferentes cuentas de correo electrónico de un
modo distinto y con criterios de acceso no uniformes. Por otra
parte, conforme los correos electrónicos se reciben en el
dispositivo de comunicaciones inalámbrico, pueden seguir estando
presentes copias de los correos electrónicos en los buzones de
correo de origen, lo que puede hacer que sea difícil para los
usuarios mantener su correo electrónico organizado.
Un sistema particularmente ventajoso de
distribución y sincronización de correo electrónico del tipo de
"impulsión" se divulga en la Patente norteamericana Nº
6.779.019, que se ha asignado al presente Asignatario y se
incorpora, por la presente, aquí como referencia. Este sistema
impulsa o hace avanzar elementos de datos seleccionados por el
usuario desde un sistema principal o anfitrión a un dispositivo de
comunicaciones inalámbrico y móvil, al detectar la ocurrencia de
uno o más desencadenantes de suceso definidos por el usuario. El
usuario puede entonces desplazar (o archivar) los elementos de
datos hasta una carpeta particular dentro de la jerarquía de
carpetas almacenada en el dispositivo de comunicaciones inalámbrico
y móvil, o bien puede llevar a cabo alguna otra operación del
sistema sobre un elemento de datos. La programación o software que
opera en el dispositivo y en el sistema anfitrión sincroniza
entonces la jerarquía de carpetas del dispositivo con una jerarquía
de carpetas del sistema anfitrión, y cualesquiera acciones llevadas
a cabo sobre los elementos de datos en el dispositivo son entonces
reproducidas automáticamente en los mismos elementos de datos
almacenados en el sistema anfitrión, con lo que se elimina así la
necesidad de que el usuario repita o reproduzca manualmente acciones
en el sistema anfitrión que se han ejecutado en el dispositivo de
comunicaciones inalámbrico y móvil.
El anterior sistema aporta, ventajosamente, una
gran comodidad a los usuarios de los dispositivos de comunicación
de correo electrónico inalámbricos para organizar y gestionar sus
mensajes de correo electrónico. Con todo, pueden desearse
características de comodidad y de eficiencia adicionales en los
sistemas de distribución y sincronización de correo electrónico a
medida que continúa creciendo en popularidad el uso del correo
electrónico.
El documento US 2005/0041652 A1 (Teamon Systems,
Inc.) divulga un sistema de comunicación que puede incluir al menos
un dispositivo de almacenamiento de datos destinado a almacenar
mensajes para usuarios respectivos, así como una pluralidad de
dispositivos de comunicaciones inalámbricos, cada uno de los cuales
está asociado con un usuario respectivo para el acceso a los
mensajes almacenados en el al menos un dispositivo de almacenamiento
de datos. Por otra parte, el sistema de comunicaciones puede,
adicionalmente, incluir un motor de consulta o examen adaptativo
destinado a examinar el al menos un dispositivo de almacenamiento de
datos en busca de mensajes almacenados, y a proporcionar los
mensajes examinados a los dispositivos móviles de los respectivos
usuarios. El motor de examen adaptativo puede, ventajosamente,
aprender respectivas configuraciones de uso de los usuarios para
cada dispositivo móvil, así como cambiar una velocidad de
transmisión respectiva de examen para dispositivo móvil basándose en
las mismas.
El documento US 2007/0072589 A1 (Teamon Systems,
Inc.) divulga un sistema para dotar a un dispositivo de
comunicaciones inalámbrico y móvil de la capacidad para presentar
visualmente características específicas de cuenta o de dispositivo.
El sistema incluye una base de datos para almacenar una pluralidad
de características de presentación visual para diferentes
portadores inalámbricos, proveedores de servicios de correo
electrónico, y tipos de dispositivo. Un módulo de configuración
accede a la base de datos y carga las características de
presentación visual de al menos uno de entre el portador
inalámbrico, el proveedor de servicios de correo electrónico o el
tipo de dispositivo, en el dispositivo móvil, al hacer posible que
el dispositivo móvil acceda al correo electrónico desde una posición
distante o remota.
Los aspectos principales de la invención objeto
de la presente se establecen en las reivindicaciones independientes.
Características subsidiarias de las principales se establecen en las
reivindicaciones dependientes.
Un sistema de comunicaciones incluye un motor de
red que se comunica con una pluralidad de dispositivos de
comunicaciones inalámbricos y móviles de abonado, y es capaz de
funcionar para determinar cuándo un dispositivo de comunicaciones
inalámbrico y móvil está fuera de cobertura o desconectado y es
incapaz de comunicarse con el motor de red. Un servidor de acceso
directo es capaz de funcionar con el motor de red y consulta o
examina los buzones de correo de los usuarios para recuperar
mensajes electrónicos de los buzones de correo, e impulsa o hace
avanzar cualesquiera mensajes electrónicos por medio del motor de
red con el fin de seleccionar dispositivos de comunicaciones
inalámbricos móviles suscritos por el usuario.
El servidor de acceso directo suspende el examen
de esos buzones de correo electrónico de un usuario cuando se ha
determinado que un dispositivo de comunicaciones inalámbrico y móvil
asociado con un usuario se encuentra fuera de cobertura o
desconectado y es incapaz de comunicarse, a fin de preservar los
recursos de examen dentro del servidor de acceso directo.
Otros objetos, características y ventajas se
pondrán de manifiesto de forma evidente por la descripción detallada
que sigue, al considerarla a la luz de los dibujos que se acompañan,
en los cuales:
La Figura 1 es un diagrama de bloques
esquemático de un sistema de distribución y sincronización de correo
electrónico ("email") de acceso directo, de acuerdo con
ejemplos no limitativos.
La Figura 2 es un diagrama de arquitectura o
estructura de red para mensajes, destinado a mensajes para entregar
en mano (MTH -"message to handheld").
La Figura 3 es un diagrama de arquitectura de
red para mensajes entregados en mano (MFH -"message from
handheld").
La Figura 4 es un diagrama de bloques que
muestra una estructura de directorio y otros componentes que se
utilizan en el sistema de correo electrónico de acceso directo que
se muestra en la Figura 1.
La Figura 5 es un diagrama de bloques que
muestra componentes básicos de un Gestor de Asignación de Recursos,
tal y como se utiliza en el sistema de correo electrónico de acceso
directo que se ha mostrado en la Figura 1.
La Figura 6 es un diagrama de bloques que
muestra los componentes básicos que operan con el módulo de SOAP
[Protocolo de Objetos de Acceso Simple -"Simple Object Access
Protocol"] que se muestra en el sistema de correo electrónico de
acceso directo de la Figura 1.
La Figura 7 es un diagrama de bloques que
muestra los componentes básicos que operan con el Servidor de
Suceso, según se muestra en el sistema de acceso directo de la
Figura 1.
La Figura 8 es un diagrama de bloques que
muestra componentes que interactúan con el Representante de Acceso
Directo ("Direct Access Proxy") que se muestra en el sistema de
correo electrónico de acceso directo de la Figura 1.
La Figura 9 es un diagrama de bloques que
muestra los componentes básicos que operan con el Representante de
Acceso Directo para soporte de SMTP [Protocolo de Transferencia de
Correo Simple -"Simple Mail Transfer Protocol"].
La Figura 10 es un diagrama de bloques que
muestra los componentes básicos del Representante de Acceso Directo
con el Proveedor de Correo de IMAP [Protocolo de Acceso a Mensajes
de Internet -"Internet Message Access Protocol"].
La Figura 11 es un diagrama de flujo que muestra
las etapas funcionales para IDLE de IMAP [extensión de IMAP para
aviso y sincronización a la llegada de un correo].
La Figura 12 es un diagrama de bloques que
muestra los componentes básicos del Organizador Temporal de Fuente
("Source Scheduler") y la interacción entre los
componentes.
La Figura 13 es un diagrama de flujo que
muestras las etapas básicas para el soporte libre de IMAP.
\newpage
La Figura 14 es un diagrama de bloques que
muestra los componentes básicos de un Organizador Temporal de Fuente
para el Representante de Acceso Directo.
La Figura 15 es un diagrama secuencial que
muestra transacciones entre la Plataforma de Oficina Móvil y el
trabajador para la notificación de situación fuera de cobertura.
La Figura 16 es un diagrama de bloques
esquemático que ilustra un dispositivo de comunicaciones inalámbrico
y móvil proporcionado a modo de ejemplo, que puede ser utilizado con
el sistema de correo electrónico de Acceso Directo mostrado en la
Figura 1.
Se describirán a continuación diferentes
realizaciones de una forma más completa, en lo que sigue, con
referencia a los dibujos que se acompañan, en los cuales se
muestran realizaciones preferidas. Pueden exponerse muchas formas
diferentes y las realizaciones descritas no deben interpretarse como
limitadas a las realizaciones que se exponen aquí. En lugar de
ello, estas realizaciones se proporcionan de forma tal, que esta
divulgación será exhaustiva y completa, y abarcará plenamente el
ámbito para los expertos de la técnica. Los mismos números de
referencia aluden a elementos similares en todas ellas.
En la Figura 1 se muestran los componentes del
sistema de correo electrónico de Acceso Directo 20. El motor 22 de
cliente de web o de red tiene diversos componentes. El trabajador 24
es un agente de procesamiento o tratamiento que es responsable de
la mayor parte del tratamiento en el motor 22, e incluye soporte de
servidor de SMTP [Protocolo de Transferencia de Correo Simple
-"Simple Mail Transfer Protocol"], o de HTTP [Protocolo de
Transferencia de Hipertexto -"HyperText Transfer Protocol"].
Este determina la información de situación fuera de cobertura
(O.C.
-"out-of-coverage"), como se explicará más adelante. Acepta correo electrónico procedente del representante de DA y de dispositivos de encaminamiento de correo externos, formatea el correo electrónico en CMIME, y lo envía al agente 26 de acceso o puerta y a otros componentes. El agente 26 de puerta actúa como una capa de transporte entre la infraestructura del sistema de correo electrónico y el resto del motor 22. El dispositivo de encaminamiento 28 de correo electrónico es un MTA (Agente de Transferencia de Correo -"Mail Transfer Agent") y es el responsable de remitir los mensajes al almacén 30 de correo, el cual está destinado a abonados anfitriones. Es también el responsable de aceptar/remitir notificaciones de correo electrónico.
-"out-of-coverage"), como se explicará más adelante. Acepta correo electrónico procedente del representante de DA y de dispositivos de encaminamiento de correo externos, formatea el correo electrónico en CMIME, y lo envía al agente 26 de acceso o puerta y a otros componentes. El agente 26 de puerta actúa como una capa de transporte entre la infraestructura del sistema de correo electrónico y el resto del motor 22. El dispositivo de encaminamiento 28 de correo electrónico es un MTA (Agente de Transferencia de Correo -"Mail Transfer Agent") y es el responsable de remitir los mensajes al almacén 30 de correo, el cual está destinado a abonados anfitriones. Es también el responsable de aceptar/remitir notificaciones de correo electrónico.
El almacén 30 de correo es un almacén de mensaje
de MIME [Extensiones de Correo por Internet de Múltiples Propósitos
-"Multipurpose Internet Mail Extensions"] que reside o está
radicado en un sistema de almacenamiento central con el fin de
proporcionar soporte a características de MORE/remisión/respuesta y
de visión de anexo. El servidor 32 de anexo proporciona un servicio
de peticiones de conversión de documentos/anexo procedentes de los
trabajadores.
El símbolo "dir" que se ha añadido a una
línea ilustra que se ha efectuado una consulta en directorio con el
fin de determinar la instancia del servicio a la que se ha de
llamar, por ejemplo, de la que puede recuperar el representante de
DA un correo electrónico para código de entrada/libro de servicio
particular. El símbolo "f", añadido a un componente, ilustra
que este se registra a sí mismo con un directorio de PDS [servicio
de directorio de PWP -"PWP directory service"]. El añadido
triangular en los componentes de WAP [Protocolo de Aplicaciones
Inalámbricas -"Wireless Application Protocol"] y de HTML
[Lenguaje de Etiquetado de Hipertexto -"HyperText Markup
Language"] ilustra que se trata de un cliente de un Servicio de
Despliegue de Recursos.
El retransmisor 34 opera con la Red de
Comunicaciones Inalámbrica 36, tal como una red celular o WLAN [Red
de Área Local de Banda Ancha -"Wideband Local Area Network"], y
coopera con un Agente 26 de Puerta utilizando el GUID [Identificador
Único Global -"Global Unique Identifier"]. La Red 36 se
comunica con uno o más dispositivos de comunicación inalámbricos 38,
tales como dispositivos de comunicaciones inalámbricos y
portátiles.
La plataforma de oficina móvil 40 tiene
diferentes componentes. El representante de DA (DA) 42 incluye un
servicio por medio del cual se entregan a, o se recuperan de, el
trabajador 24 los mensajes de fuente integrados. Es el responsable
de las fuentes de consulta o examen tales como los buzones de
correo, de las notificaciones de la fuente de tratamiento, así como
de la recuperación y actualización de los mensajes de fuente a
través del representante universal 44. El representante universal
(UP -"universal proxy") 44 abstrae el acceso con el de
desencadenar almacenamientos de correo electrónico en un protocolo
común. El servidor 46 de suceso es un procedimiento de poco peso en
un servidor que recibe notificaciones de fuentes externas (ISP
[Proveedor de Servicios de Internet -"Internet Service
Provider"] y SMC [Compilador de Máquina de Estado -"State
Machine Compiler"]) y de buzones de correo de diferentes
usuarios, y los procesa o trata de forma asíncrona sin bloquear el
remitente de las notificaciones. Las fuentes de correo integradas
48, como proveedores de servicios de correo electrónico, incluyen
ejemplos no limitativos tales como Yahoo!, Gmail, IMAP [Protocolo de
Acceso a Mensajes de Internet -"Internet Message Access
Protocol"], POP [Protocolo de Oficina de Correos -"Post Office
Protocol"], Lotus Notes, y Exchange. Los servidores de SMTP 49
están asociados con los proveedores de servicios de correo
electrónico según se explica con mayor detalle más adelante. La
salida de servicio 50 del motor es un servicio de altas
prestaciones ubicado en el servidor, capaz de validar un gran número
de fuentes integradas de forma concurrente. Este motor 50 se
utiliza en un procedimiento de integración de fuentes con el fin de
validar los ajustes de acceso a un buzón de correo electrónico. El
SOAP 52 es una interfaz primaria para interrogación, actualización
y modificación de datos contenidos en las bases de datos central y
de partición, 54 y 58. También implementa lógica comercial que
dispara o desencadena otros flujos de trabajo dentro del sistema
(por ejemplo, enviar o borrar libros de servicio). La base de datos
central 54 almacena extensos datos de todo sistema relacionados con
sitios/portadores, proveedores de buzón de correo (AOL. Yahoo),
libros de servicio, dispositivos y cuentas de usuario. La base de
datos de partición 58 es un almacén de datos primario para los
usuarios. Almacena datos para un conjunto fijo de usuarios. El
directorio 56 es un sistema responsable de la asignación,
localización y distribución de los usuarios y de sus cargas de
trabajo asociadas a través de las instancias de servicio. El gestor
de asignación de fuente (SAM -"source assignment manager") 60
asigna fuentes al representante de DA 42 para los propósitos de
detección de correo (consulta o examen, suscripción, etc.). El PDS
(servicio de directorio de PWP -"PWP directory service") 62 es
un registro de servidores de PWP [páginas web personales
-"Personal Web Pages"] y es el responsable del equilibrado de
la carga de clientes del conectador de correo (MC -"mail
connector") a través de las instancias de servidor de PWP.
Se utilizan cualesquiera del servidor de PWP y
los componentes de conectador de correo, conjuntamente, para
acceder a buzones de correo cuando el sistema es incapaz de acceder
directamente a una fuente de correo externa (por ejemplo, la fuente
se encuentra detrás de un cortafuegos corporativo). El Sistema de
Despliegue de Recursos (RDS -"Resource Deployment System") 64
permite el despliegue dinámico de nuevos recursos específicos de
marca y de lenguaje.
Existen también diversos componentes de UI/web.
El representante de HTML 70 proporciona una interfaz de usuario de
HTML para que los usuarios gestionen su cuenta. El representante de
WAP 72 proporciona una interfaz de usuario de WML [Lenguaje de
Etiquetado Inalámbrico -"Wireless Markup Language"] y XHTML
[HTML Extendido -"eXtended HTML"] con el fin de que los
usuarios gestionen su cuenta. El representante 74 de WEB ADMIN
[administrador de red] y de ADMIN [administrador] proporciona una
interfaz de usuario de HTML para que los portadores lleven a cabo
funciones administrativas en sus cuentas de cliente. Se ha
desplegado un cliente de sobremesa por medio de un CD de
dispositivo, que permite al usuario integrar fuentes con una UI
Win32 nativa. Un cliente de dispositivo permite al usuario integrar
fuentes utilizando una UI basada en Java, instalada en el
dispositivo. Puede también tener lugar el aporte o
aprovisionamiento (PRV) 76. También se ha ilustrado el servidor de
SMTP interno 77, capaz de funcionar con una tabla 78 de base de
datos y asociado con la MOP [Programación Orientada al Mensaje
-"Message Oriented Programming"]. Un organizador temporal 104
de fuente y un módulo de conexión Libre de IMAP
("IMAP-Idle") 120 se muestran y explican con
mayor detalle más adelante.
Como se muestra en la Figura 2, existen dos
recorridos o caminos de mensaje posibles para los mensajes para
entregar en mano (MTH -"message to handheld"). El primer camino
es por medio de un dispositivo de encaminamiento de correo externo,
a través de un SMTP. Este camino se utiliza para todas las fuentes
de BBM y soportadas en el sistema anfitrión. Todos los mensajes
llegarán al motor 22 de red a través del dispositivo de
encaminamiento 28 de correo, el cual realizará una consulta en
directorio y, a continuación, remitirá el mensaje al trabajador 24
apropiado. El trabajador 24 tratará el mensaje y enviará el mensaje
al agente 26 de puerta menos ocupado. Por último, el agente 26 de
puerta suministrará el mensaje el retransmisor 34, el cual enviará,
a su vez, el mensaje al dispositivo 38.
El segundo camino es a través de los
representantes Universal y de DA, 44 y 42. Este camino se utiliza
para todas las fuentes integradas. Cuando el representante de DA 42
detecta un nuevo correo procedente de una fuente integrada, el
representante de DA 42 recuperará y cargará el mensaje a través del
Representante Universal 44, llevará a cabo una consulta en
directorio para encontrar el trabajador adecuado, y hará llegar el
mensaje al trabajador. El trabajador realizará entonces la misma
operación que hizo para el correo soportado en el sistema
anfitrión.
Tal como se muestra en la Figura 3, existen dos
rutas de encaminamiento posibles para un mensaje entregado en mano
(MFH -"message from handheld"). La primera es enviarlo a través
de un dispositivo de encaminamiento 28 de correo. Este camino se
utiliza para fuentes soportadas en el sistema anfitrión. Este camino
se utilizará también para un subconjunto de fuentes integradas que
no requiere una capacidad funcional mayor que la del envío de
correo. El Retransmisor 34 recibirá el mensaje proveniente del
dispositivo 38 y remitirá, a continuación, el mensaje al agente 26
de puerta. El agente 26 de puerta llevará a cabo una consulta en
directorio y enviará el mensaje al trabajador 24 apropiado. El
trabajador 24 descodificará, a continuación, el mensaje y lo enviará
al dispositivo de encaminamiento 28, el cual, a su vez, entregará el
mensaje al buzón de correo de destino.
El segundo camino es a través del representante
de DA 42. Se precisa este camino para las fuentes integradas que
requieren más capacidades funcionales que las que proporciona el
envío de correo. Por ejemplo, las fuentes de Google requieren que
los mensajes se envíen a través de servidores de SMTP con el fin de
proporcionar soporte a una carpeta enviada. Siguiendo el mismo
camino hasta el trabajador que el correo soportado en el sistema
anfitrión, el trabajador realizará una consulta en directorio y
enviará el mensaje al representante de DA 42 apropiado. El
representante de DA 42 compondrá entonces una petición en HTTP Mail
(Correo de HTTP) al objeto enviar un mensaje, que se impulsará o
hará pasar al representante universal 44, el cual traducirá la
petición en HTTPMail a un formato apropiado para enviar el correo,
ya sea a través de un dispositivo de encaminamiento de correo
externo, ya sea a través de un protocolo dependiente del tipo de
fuente (por ejemplo, HTTPMail para intercambio). Cualquiera de los
dispositivos de encaminamiento puede ser externo.
El trabajador 24 constituye un componente
principal del motor 22 de red. El trabajador 24 es el responsable
de la conversión de mensajes entre MIME y CMIME, de la encriptación
o cifrado y la desencriptación o descifrado de los mensajes, de la
compresión y la descompresión de los mensajes, y de la vista de los
anexos. El trabajador 24 hará posible la afinidad con el usuario.
Las ventajas de esto son que el sistema tiene una plantilla global
de trabajadores, en lugar de dividir los usuarios por celdas. Esto
permitirá que los trabajadores se ordenen en escala o jerarquía
horizontalmente según un criterio de N + 1. También permitirá un
mejor uso de un límite de trabajos pendientes por cada libro de
servicio. Asimismo, reducirá el tamaño de la memoria caché del
usuario dentro del trabajador.
Los trabajadores 24 se registrarán con el
Directorio 56. Para todos los MHT, el dispositivo de encaminamiento
de correo contactará con el Directorio 56 con el fin de determinar a
qué trabajador 24 se han de encaminar los mensajes. Para todos los
MFH, los agentes 26 de puerta contactarán con el Directorio 56 con
el fin de determinar a qué trabajador se han de encaminar los
mensajes. El Directorio 56 equilibrará en carga a los usuarios a
través de los trabajadores 24. El sistema se ve simplificado por el
hecho de tener sólo un componente a cargo de la afinidad de usuario
y del equilibrado de la carga. Los trabajadores implementarán los
filtros principales.
El trabajador 24 almacenará una memoria caché en
una memoria de todos los registros de usuario conocidos. Esta
memoria caché reducirá el número de peticiones de "Obtener Libro
de Servicio" dirigidas al representante de DA 42. El trabajador
24 proporcionará soporte a una notificación de HTTP para extraer un
registro de su memoria caché (enviado cuando se actualiza un
registro). Existirá un tiempo de expiración rígido o inflexible
para cada registro de memoria caché. Este tiempo de expiración
forzará un registro a ser extraído de la memoria caché después de
un intervalo de tiempo preestablecido (aproximadamente un día, pero
esto es configurable). El propósito de este tiempo de expiración es
extraer registros sin utilizar de la memoria caché cuando un
usuario se equilibra en cara para otro trabajador. El tiempo de
expiración rígido también proporcionará protección contra
notificaciones perdidas (registros caducos).
El trabajador 24 aceptará mensajes a través de
dos protocolos, el SMTP y el HTTP, tal y como se ilustra por las
referencias 24a y 24b. Todos los mensajes para un mensajero
("Messenger") de dispositivo y fuentes soportadas en el
sistema anfitrión, llegarán a través de SMTP. Los mensajes llegarán
a cualesquiera dispositivos de encaminamiento 28 de correo. El
dispositivo de encaminamiento 28 de correo consultará el trabajador
apropiado 24 en el Directorio 56 y encaminará el mensaje hasta el
trabajador correspondiente por medio de SMTP. Todos los mensajes
para fuentes integradas serán enviados al trabajador a través de
HTTP. El mensaje será entregado en forma de notificación de correo
nuevo. La notificación incluirá también el mensaje de MIME, en vez
de solo un identificador de mensaje. Ambos protocolos implementarán
una Confirmación (ACK -"Acknowledgement") retardada. El
trabajador 24 no dará ACK de la fuente entrante hasta que, bien el
mensaje haya sido entregado al dispositivo 38, ó bien el mensaje
haya sido paginado en disco sobre un temporizador. El trabajador no
bloqueará, típicamente, ningún hilo o vínculo mientras espera a que
se envíe la ACK. El representante de DA 42 no bloqueará,
típicamente, su vínculo con el cliente mientras aguarda a recibir la
ACK.
Los almacenes de trabajo se guardarán en un
dispositivo de almacenamiento central. El trabajador 24 implementará
el paradigma de ACK retardada que se implementó en un mensajero de
dispositivo. Bajo este paradigma, el trabajador 24 no almacenará
los mensajes de CMIM de inmediato, sino que, en lugar de ello,
organizará temporalmente un temporizador para inscribir en disco el
trabajo. En el caso de que el trabajo se haya completado antes de
que se dispare el temporizador, el temporizador es entonces
cancelado y el trabajo no se inscribe en disco. Si el trabajo no se
completa antes de que se dispare el temporizador, entonces el
trabajo es inscrito en disco. El trabajo 24 no dará ACK de la
fuente del mensaje (SMTP o HTTP) hasta que, bien el trabajo se haya
completado, o bien el trabajo se haya paginado en disco. Si el
trabajador 24 sufre un fallo antes de se haya dado ACK del trabajo
(se haya completado o paginado), entonces la fuente de origen del
mensaje es la responsable de reintentar llevar a cabo el trabajo.
Si el trabajador sufre un fallo una vez que se ha dado ACK del
trabajo, entonces el trabajador es el responsable de reintentar el
trabajo, al recuperar el trabajo de CMIME del disco. El método de
recuperación ser utilizará para usuarios de Messenger, correo
soportado por el sistema anfitrión, así como fuentes de correo
integradas.
Toda la recuperación en el trabajador 24 se
realizará por medio del almacén de trabajos de CMIME. Cuando un
trabajador 24 se pone en marcha, escaneará o explorará su almacén de
trabajos en busca de cualesquiera trabajados que estuviesen en
curso cuando el trabajador se desactivó o apagó previamente. El
trabajador 24 proseguirá, entonces, reanudando el tratamiento de
estos trabajos. Con esta estrategia, es posible que acceda más de un
trabajador al mismo buzón de correo. Todos los mensajes nuevos para
el buzón de correo serán entregados al trabajador activo en ese
momento (a través del componente de Directorio). Sin embargo,
cualesquiera trabajados en curso serán tratados por el trabajador
original. Esto puede conducir a que los usuarios superen su límite
de trabajo pendiente, ya que cada trabajador gestiona su propio
límite. Sin embargo, esto únicamente ocurrirá mientras los trabajos
están siendo recuperados, y no afectará a los trabajos nuevos.
El agente 26 de acceso o puerta es el
responsable de la codificación/descodificación de GME de los
mensajes de CMIME, enviando mensajes al retransmisor y recibiendo
mensajes de este. El agente 24 de puerta puede, opcionalmente,
comprimir y encriptar o cifrar mensajes MTH.
Un mensaje para entregar en mano (MTA) es el
responsable de aceptar mensajes al interior del sistema para
cuentas de corro soportadas en el sistema anfitrión, y de remitirlos
a un trabajador apropiado. El MTA permitirá preguntas al directorio
a través de una interfaz de LDAP [Protocolo Ligero de Acceso a
Directorios -"Lightweight Directory Access Protocol"]
estándar, que utilizará los MTA construidos en mecanismos de
consulta para la reescritura de envoltorio. La necesidad de
software externo para actuar como intermediario o interfaz con el
directorio será eliminada, lo que reducirá la complejidad global. El
MTA tendrá la capacidad de tapar/limitar las conexiones desde el
canal de entrada o desde el de entrega, el cual puede ser
sintonizado para adherirse al perfil de conexión del Almacén de
Correo de MIME.
El Almacén de Correo de MIME 30 consistirá en
una solución de almacenamiento central que sea compartida por todos
los trabajadores. Puede añadirse al trabajador un almacén de mensaje
de MIME. Este dará soporte a MORE/REMISIÓN/RESPUESTA y a la vista de
anexo. El almacén de correo residirá en un dispositivo de
almacenamiento central, por medio de una NetApp u otra SAN [Red de
Área de almacenamiento -"Storage Area Network"], a fin de
permitir a cualquier trabajador acceder a cualquier mensaje desde
cualquier usuario y dar soporte al equilibrado de carga dinámico de
los usuarios entre trabajadores. Puede haber un buzón de correo por
cada libro de servicio. Algunos mensajes pueden no necesitar ser
almacenados en el almacén de correo. Los mensajes que son más
pequeños que punto de truncamiento de MORE y que no contienen
anexos, no necesitan ser almacenados en el almacén 30 de correo.
Los mensajes que no son almacenados en el almacén de correo pueden
ser entregados al dispositivo 38 con una etiqueta o indicador que
le dice al dispositivo que remita los mensajes con su contenido
original, en vez de por su ID de referencia. Esta optimización
reducirá la carga sobre cualquier almacén central.
Puede utilizarse la NettApp u otra aplicación
para conseguir una solución de almacenamiento central. Es posible
que una única NettApp no sea capaz de manejar la carga de todo el
espacio de usuarios. Cuando esto ocurre, puede añadirse otra
NettApp a la infraestructura. A fin de dar cabida a esta, puede
añadirse una nueva columna a la base de datos de usuario, la cual
describirá en qué punto de soporte reside el buzón de correo. Es
posible utilizar un esquema de equilibrado de carga para determinar
qué NettApp se ha de utilizar a la hora de añadir un nuevo buzón de
correo. Antes de que el motor 22 pueda acceder al almacén de correo
para un buzón de correo dado, consultará, primeramente, el punto de
soporte en la base de datos y, a continuación, procederá a acceder
al buzón de correo. Esto permitirá al sistema ordenar en escala o
jerarquía las NettApps horizontalmente utilizando una metodología de
regulación en escala de N + 1.
El almacén 30 de correo es capaz de almacenar
mensajes utilizando un ID de referencia como su identificador único
o exclusivo. No está garantizado que los ID de referencia sean
únicos a través de todos los libros de servicio. En consecuencia,
cada libro de servicio debe tener su propio buzón. Se utiliza el ID
de referencia porque todas las peticiones de MORE/REMISIÓN/RESPUESTA
y de anexo incluyen el ID de referencia original.
Los mensajes son, típicamente, comprimidos antes
de ser guardados en disco, en el Almacén de Correo de MIME 30.
Ensayos de comportamiento han demostrado que una biblioteca de
compresión viable es la compresión de LZO [una librería de
compresión de datos]. El uso de la compresión de LZO reducirá la
carga en la red, la carga en el almacén central, así como el
espacio de almacén total requerido. Esto permitirá al sistema
proporcionar soporte al mismo número de usuarios al tiempo que
utiliza menos soporte físico o hardware en el almacén central. La
compresión de LZO puede configurarse de forma que se
active/desactive. Algunos mensajes pueden no beneficiarse de la
compresión (por ejemplo, los mensajes con anexos JPEG). El almacén
30 de Correo puede implementar optimizaciones con el fin de
determinar qué mensajes deben ser comprimidos y cuáles no deben ser
comprimidos, basándose en la naturaleza del contenido del mensaje.
Esta optimización puede reducir la carga sobre la CPU (unidad
central de procesamiento -"central processing unit")
anfitriona.
Cada buzón de correo puede tener un índice de
autoenvejecimiento que realizará un seguimiento de la cuota de uso
y dictará el orden en que los mensajes deben ser eliminados del
dispositivo de almacenamiento cuando se supera la cuota. El almacén
30 de correo almacenará el correo tanto soportado por el sistema
anfitrión como integrado. La cuota para los buzones de correo
integrado será pequeña (suficiente para almacenar, en promedio, el
producto de un día de correo).
Cuando se añade un mensaje al almacén de correo,
la cuota es analizada y, si se alcanza el límite, entonces se
eliminan uno o más mensajes del buzón de correo para liberar el
suficiente espacio para el nuevo mensaje.
El almacén de datos se divide en una base de
datos central 54 y en múltiples bases de datos de partición 58.
Lógicamente, la base de datos central 54 contiene todos los datos a
lo largo y ancho del sistema, así como un directorio de todas las
cuentas de usuario. Físicamente, la base de datos central 54 puede
ser dividida en diferentes bases de datos. Los datos de cuenta de
usuario contienen la suficiente información como para consultar la
cuenta, en virtud de varios id externos (por ejemplo, SUBID, PIN,
Buzón de correo ("Mailbox")), para determinar qué base de
datos de partición 58 contiene los datos de usuario detallados.
Los datos de todo el sistema almacenados en una
base de datos central pueden incluir información acerca de:
- a)
- Sitios/portadores, por ejemplo, tmobile, cingular;
- b)
- Proveedores de buzón de correo (aol, yahoo);
- c)
- Libros de servicio;
- d)
- Información del dispositivo; y
- e)
- Relaciones de correspondencia de Buzón de correo soportadas en el sistema anfitrión.
\vskip1.000000\baselineskip
Se accede a la base de datos central 54 por el
componente de SOAP 52 y por el Directorio 56. La base de datos
central debe aumentarse de escala para manejar un número siempre
creciente de usuarios. Se almacena una cantidad mínima de datos en
la base de datos central, y las cargas de petición se limitan por la
dotación de memoria caché de sus datos en el componente de
Directorio 56.
Una base de datos de partición 58 contiene datos
relativos a una cuenta de usuario y fuentes integradas, tales como:
fuentes integradas, reglas de aviso, firma y elementos similares. La
base de datos de partición contiene también algunos datos globales
reproducidos desde la base de datos central 54 con el fin de
mantener la carga de la base de datos central 54 en el mínimo, por
ejemplo, libros de servicio. Al grueso de los datos contenidos en
la base de datos de partición 58 se encuentra en el seguimiento de
los UID de mensaje para cada fuente integrada. Esta tabla es
actualizada, potencialmente, cada vez que se examina una fuente. Se
accede a la base de datos de partición por medio del SOAP52 y del
representante de DA 42. La base de datos de partición es el
principal mecanismo de regulación en escala del almacén de datos.
Esta se encarga de un número fijo de usuarios. A medida que el
número de usuarios crece, pueden añadirse más particiones, lo que
permite al sistema regularse en escala.
El directorio 56 es un sistema responsable de
asignar y determinar un usuario para una instancia de servicio para
servicios que requieren un cierto grado de afinidad con el usuario.
Las asignaciones se distribuyen uniformemente a lo largo y ancho de
todas las instancias de servicio de un tipo particular. Siempre que
se haya de enviar una petición a un servicio, debe determinarse la
instancia de servicio para el Directorio. El Directorio 56
distribuye las afinidades uniformemente a través de todas las
instancias de servicio de un tipo particular. El Directorio
proporciona soporte al Representante de DA y a las consultas de
Trabajador. Pueden asignarse a la instancia de Representante de DA
usuarios de la partición a los que está dando servicio. Puede
asignarse cualquier usuario al Trabajador.
El directorio 56 es realmente un sistema de
Nodos de Directorio. Cada nodo comparte el cometido de almacenar
relaciones de correspondencia de instancia de usuario a servicio,
así como la carga de petición de red asociada con las consultas. La
estrategia es asignar un valor de remezcla a cada nodo. Conforme se
realiza cada consulta en directorio, la clave de consulta es
remezclada hasta obtener uno de los valores de remezcla, y se remite
la consulta a la instancia de directorio a la que se asigna ese
valor de remezcla, a fin de determinar la relación de
correspondencia. Si no existe una relación de correspondencia para
la consulta, entonces la determinación implicará una asignación a
una instancia de servicio.
En la Figura 4, el Directorio 56 se ha
representado con tres componentes lógicos: el Dispositivo de
encaminamiento 80 para remezclar la clave de consulta y remitirla a
la instancia de directorio apropiada; la Memoria caché 82, que
almacena las relaciones de correspondencia; y el Registro 84, que
carga balances a través de las instancias de servicio
registradas.
El dispositivo de encaminamiento 80 tiene una
lista de nodos de directorio y el valor de remezcla con el que se
han hecho corresponder. El valor de remezcla es, simplemente, una
enumeración desde 0 a N - 1, donde N es el número de nodos. Cada
nodo tendrá exactamente la misma tabla. La función del Dispositivo
de encaminamiento 80 es remezclar la clave de consulta entrante
hasta obtener un valor de remezcla, y remitir la petición al nodo
al que se ha asignado ese valor de remezcla. Si el valor de remezcla
se ha asignado a este nodo, entonces la consulta se hace en una
Memoria caché 82 del nodo.
La Memoria caché 82 contiene una lista de
relaciones de correspondencia entre claves de consulta e instancias
de servicio. Para el representante de DA, la clave de consulta es el
PIN [Número de Identificación Personal -"Personal Identification
Number"]. Para un Trabajador, ésta es bien el PIN o bien la
Dirección de Correo Electrónico. Para el trabajador, existen dos
claves que identifican al usuario y que pueden ser utilizadas como
clave de consulta. Estas dos claves se remezclarán, probablemente,
en valores diferentes y provocarán que se creen dos relaciones de
correspondencia para el mismo usuario. A causa de esto, una de las
claves debe ser designada como la clave primaria, y todas las
consultas efectuadas a través de una clave secundaria darán como
resultado una clave primaria, la cual puede ser entonces utilizada
en una consulta para determinar la instancia de servicio.
Todas las instancias de servicio crean y
mantienen una conexión con el Registro 84 para registrar su
servicio. Esta conexión se utiliza también para detectar fallos de
instancia de servicio. El Registro 84 es también el responsable de
distribuir asignaciones a lo largo de instancias de servicio.
El Directorio 56 proporciona soporte a dos
interfaces de LDAP y a una interfaz de LBAC [control de acceso
basado en etiqueta -"Label-Based Access
Control"] Extendida. La interfaz de LDAP se ha proporcionado para
que el dispositivo de encaminamiento de correo lleve a cabo
consultas de Trabajador por dirección de correo electrónico. El
dispositivo de encaminamiento de correo proporciona soporte a
consultas de LDAP y se encargará de hacer funcionar tanto de la
interfaz de LDAP como sea necesario para su implementación.
Cuando el representante de DA 42 descubre y
descarga un nuevo mensaje desde una fuente integrada, pregunta al
Directorio 56 por el Trabajador 24 que se encargará de los mensajes
para el usuario asociado. La pregunta contiene el PIN que remezcla
el dispositivo de encaminamiento 80 de Directorio. Si el resultado
de la remezcla es su id de remezcla asignado, entonces procesará o
tratará la petición; en caso contrario, remitirá la petición a la
instancia de Directorio que está a cargo de ese resultado de
remezcla. El Directorio que se encarga de ese resultado de remezcla
comprobará, en ese momento, su conjunto de relaciones de
correspondencia para ver si existe una relación de correspondencia
establecida para ese PIN. Si no existe ninguna relación de
correspondencia, entonces se selecciona un trabajador con el menor
número de relaciones de correspondencia y se asigna al PIN. El
trabajador es entonces devuelto al cliente. Un procedimiento similar
se produce para PIN para el Representante de DA 42.
Cuando el dispositivo de encaminamiento 28 de
correo recibe un mensaje, pregunta al Directorio por el trabajador
que se encargará de los mensajes para el usuario asociado. La
pregunta contiene la dirección de correo electrónico que remezcla
el Directorio. Si el resultado de la remezcla es su id de remezcla,
entonces éste procesará la petición. En caso contrario, remitirá la
petición a la instancia de Directorio que es responsable para ese
resultado de remezcla. El Directorio que se encarga de ese resultado
de remezcla comprobará a continuación su conjunto de relaciones de
correspondencia para comprobar si existe una relación de
correspondencia para esa dirección de correo electrónico; si no es
así, se realizará una búsqueda en base de datos para recuperar el
PIN asociado. Se llevará a cabo seguidamente una consulta
de PIN para Trabajador. Una vez completada la consulta, el valor puede ser guardado en memoria caché y devuelto.
de PIN para Trabajador. Una vez completada la consulta, el valor puede ser guardado en memoria caché y devuelto.
El Gestor de Asignación 60 de Fuente, según se
muestra en la Figura 5, es el responsable de garantizar que se está
dando servicio a las fuentes de una partición por parte de una
instancia de Representante de DA 42. El Gestor de Asignación 60 de
Fuente garantiza de forma activa que cada fuente es asignada por el
directorio a un representante de DA 42, y que se notifica al
representante de DA de que cada fuente a la que ha de dar
servicio.
El componente de Directorio 56 es el responsable
de asignar fuentes, mediante pin o número de identificación
personal, a representantes de DA 42. Las asignaciones de
representante de DA deben realizarse de forma proactiva, a fin de
que comience el proceso de examen, y deben ocuparse de las
condiciones que resultan de la pérdida de una asignación cuando una
instancia de Directorio sufre un fallo. Debe asegurarse de que todas
las fuentes estén siendo examinadas, y debe garantizar que las
fuentes borradas dejan de ser examinadas de una forma regulada en
el tiempo. El componente de Directorio 56 también garantiza que
únicamente está dando servicio un solo representante de DA a una
fuente particular cualquiera. Las fuentes susceptibles de ser
suscritas y que son elegibles para suscripción (por ejemplo, que no
están suspendidas) son suscritas. Las operaciones deben ser capaces
de efectuar un seguimiento del estado de las colas de examen y de
otras medidas de "salud".
La base de datos de partición 58 coloca un sello
temporal en cada fuente, que especifica la última vez que se cambió
la fuente. Se proporcionan dos indagaciones. La primera indagación
da como resultado toda la lista de fuentes con campos relacionados
con el servicio a la fuente (por ejemplo, indicadores de examen),
así como un sello temporal que puede utilizarse en la segunda
indagación. La segunda indagación, dado un sello temporal desde la
última indicación, arroja como resultado todas las fuentes cambiadas
desde la última indagación, así como otro sello temporal para uso en
la siguiente indagación.
Un gestor de examen, como parte del
representante de DA y del organizador temporal de fuente, mantiene
una lista de todas las fuentes pertenecientes a su partición
configurada. Para cada fuente de la lista, efectúa un seguimiento
de los datos relacionados con el servicio a la fuente, para los
propósitos de actualizaciones de detección, inserciones y borrados.
Por otra parte, la asignación de representante de DA es supervisada
con el fin de permitir notificaciones de reasignación y/o
disminución de la reasignación (debido a fallos en el directorio).
Puede también efectuarse el seguimiento de un sello temporal. El
sello temporal es un valor que es devuelto por la base de datos y
que puede utilizarse para recuperar fuentes que han cambiado desde
la última pregunta o indagación.
Al arrancar, un Gestor de Examen se registra con
el Directorio 56 y realiza una pregunta a la base de datos de
partición configurada con el fin de recuperar todas las fuentes y
los datos relevantes que hacen funcionar la lógica de servicio de
cada fuente. El PIN de las fuentes se hace pasar en uno o más lotes
al servicio de Directorio para localizar el representante de DA que
dará servicio a cada fuente. Esta información es almacenada. A
continuación, se envía una notificación a cada representante de DA
al que se han asignado una o más fuentes, que contiene las fuentes a
las que ha de dar servicio el representante de DA.
Con el fin de garantizar que se está dando
servicio a las fuentes, el Gestor de Examen pregunta, a intervalos
configurados, a la base de datos de partición 58 para recuperar
todas las fuentes que pueden ser nuevas o cambiadas, basándose en
un sello temporal devuelto por la última pregunta. El nuevo sello
temporal puede ser utilizado en la siguiente pregunta. La lista de
fuentes se compara con los resultados de la indagación al objeto de
determinar qué fuentes han sido cambiadas, o bien borradas o
insertadas. Para las fuentes insertadas, se llama al Directorio a
fin de recuperar la asignación de representante de DA. Se envía un
mensaje a todos los representantes de DA que tienen cambios o
añadidos a una o más fuentes a las que están dando servicio.
Se utilizan notificaciones de SOAP para
asegurarse de que, cuando una fuente es actualizada, borrada o
insertada, se le dará servicio de forma inmediata o en tiempo real
de acuerdo con el nuevo estado de las fuentes. El módulo de SOAP
envía notificaciones al Gestor de Examen mediante la realización de
una consulta en el directorio sobre el Gestor de Examen de la
partición a la que pertenece la fuente. El Gestor de Examen envía
entonces una notificación al representante de DA que está dando
servicio a la fuente. Las Notificaciones de SOAP se realizan a
través de una Interfaz de HTTP que implementará el Gestor de
Examen.
Cuando se detecta un fallo del Directorio, se le
notifica de ello al Gestor de Examen por parte del directorio. El
Gestor de Examen supone que puede haberse establecido una nueva
relación de correspondencia de todas sus fuentes. Todas las fuentes
son entonces consultadas en el directorio, en uno o más lotes. Si el
Gestor de Examen está realizando un seguimiento de la asignación de
representante de DA, entonces puede sugerir al Directorio el
representante de acceso directo para el que debe establecerse una
relación de correspondencia con la fuente con el fin de reducir la
cantidad de reasignación.
Cuando un representante de DA falla o se
recupera un representante de DA, las fuentes pueden ser reasignadas.
La reasignación de recuperación es causada por la necesidad de
reequilibrar la carga. Cuando se produce uno de estos sucesos, se
le notifica de ello al Gestor de Asignación 60 de Fuente
perteneciente a la partición de DA que ha fallado/recuperada, por
parte del Directorio. El Gestor de Examen se asegura de que todas
las fuentes son asignadas a un representante de DA y que el
representante de DA tiene conocimiento de ello. Esto se hace
repitiéndolo para todas las fuentes, y realizando una consulta en
directorio y notificando a los representantes de DA qué fuentes han
sido reasignadas/no asignadas.
El componente de SOAP 52 proporciona una
interfaz de SOAP para preguntar sobre, actualizar, modificar y
borrar información procedente tanto de la base de datos central
como de la de partición. El componente de SOAP 52 existe con el fin
de minimizar el número de conexiones a las bases de datos,
proporcionar abstracción a la posición física (central frente a
partición) y al esquema de los datos, e implementar lógica comercial
para notificar a los componentes los cambios de datos que pueden
desencadenar otros flujos de trabajo tales como:
- a)
- Cambios de PIN (a saber, representante de DA, Trabajador y Directorio);
- b)
- Mensaje de Bienvenida de creación de cuenta a través del representante de DA;
- c)
- El añadido de fuente integrada envía un libro de servicio a través de DA; y
- d)
- Peticiones de suscripción.
\vskip1.000000\baselineskip
También proporciona API [Interfaz de
Programación de Aplicaciones -"Application Programming
Interface"] para permitir la integración con sistemas externos e
implementa lógica simple de estimación de aprovisionamiento a través
de reglas de base de datos y salida de servicio de motor.
Las interfaces se agrupan por su funcionamiento
y también por los requisitos de los subsistemas externos. El aporte
de interfaces específicas para cada uno de los subsistemas minimiza
el efecto sobre otros sistemas cuando uno de los sistemas requiere
un cambio. Las interfaces se definen como Servicios de web y se
distribuyen como WSDL [Lenguaje de Descripción de Servicios Web
-"Web Services Description Language"], de tal manera que los
subsistemas externos sean tales, que no se imponga ningún requisito
de plataforma o de lenguaje en el subsistema externo.
La salida de servicio 50 de motor alberga un
motor de agregación 80, tal como se muestra en la Figura 6. El
motor de agregación 90 es un componente capaz de validar, examinar y
descargar frente a un gran número de fuentes de correo externas de
forma concurrente. Este recibe instrucciones para hacerlo así en
forma de lotes. Para llevar esto a cabo, utiliza Java y un hilo o
vínculo para manejar todas las peticiones contenidas en un lote. La
Salida de Servicio 50 de Motor se utiliza por su capacidad para
validar fuentes. Por lo que respecta al examen y la descarga, estos
cometidos se dejan al Representante de DA 42.
Haciendo referencia a la Figura 6, la validación
es un procedimiento que tiene lugar durante el simple
aprovisionamiento. Cuando el usuario introduce la dirección de
correo electrónico y la palabra de paso para que sea integrada una
cuenta, se envía una petición al componente de SOAP 52 para crear el
buzón de correo de la fuente. Como parte del procedimiento de
creación, el componente de SOAP aplica las credenciales a un
conjunto de reglas aprendidas y almacenadas en la base de datos 52
para producir un conjunto de evaluaciones. Estas evaluaciones se
componen de una dirección de servidor, una palabra de paso (según se
aporta), un protocolo y una identificación de acceso, de forma
similar al procedimiento establecido en la Patente norteamericana
asignada en común Nº 6.959.325, cuya descripción se incorpora aquí
como referencia en su totalidad. La base de datos central 54 es
interrogada para seleccionar un motor 90. Las evaluaciones son
entonces agrupadas en lotes y enviadas a la salida de servicio 50
del motor para su validación. La salida de servicio 50 del motor
suministra las "evaluaciones" al motor de agregación 90, el
cual se conecta e inicia el procedimiento de introducción de
identificación de acceso frente a todos los servidores, de acuerdo
con el protocolo evaluado. A continuación, espera las respuestas.
Los resultados de la introducción de identificación de acceso son
recogidos y se formula un resultado que es devuelto al componente
de SOAP 52. Si el resultado de la validación no es satisfactorio, el
usuario puede ser dirigido a una pantalla de aprovisionamiento más
avanzada. En caso contrario, se crea el buzón de voz de fuente.
El Servidor 46 de Suceso es un procedimiento que
actúa como una cola de mensajes para las notificaciones de HTTP
procedentes de fuentes externas (ISP y SMC). Los mensajes son
tratados de forma asíncrona para que no bloqueen la fuente. El
tratamiento del mensaje implica despacharlo al servicio apropiado.
El servidor de suceso se utiliza también internamente para enviar al
exterior una petición de suscripción por medio de SOAP.
La Figura 7 ilustra una nueva petición de correo
procedente de una fuente externa 96 que es entregada al
representante de DA 42, así como una petición de suscripción
procedente del Representante de DA 42 que es entregada al SOAP y a
la fuente externa 96.
El Servidor de Suceso 46 es accesible desde la
Internet, y se accede a él a través de una agrupación de BigIP. Con
el fin de añadir capacidad, pueden añadirse instancias de Servidor
de Suceso adicionales a la agrupación de BigIP. El número de
instancias requeridas depende del número de usuarios que tienen
fuentes susceptibles de suscripción.
Cuando el sistema es incapaz de acceder
directamente a una fuente de correo externa (por ejemplo, un
cortafuego corporativo), se utilizan el Conectador 100 de Correo y
el Servidor de PWP 102 conjuntamente para acceder al buzón de
correo. El conectador 100 de correo es una aplicación/servicio
basado en Win32 que un usuario instala, como parte del
procedimiento de integración de fuente, dentro de una red en la que
es posible acceder a la fuente. Es capaz de acceder a un buzón de
correo de intercambio a través de MAPI [Interfaz de Programación de
Aplicaciones de Mensajes -"Message Application Programming
Interface"], y a un buzón de correo de Lotus Notes a través de
"Notes API". El Servidor de PWP 102 actúa como un punto de
encuentro entre el Representante Universal (UP -"Universal
Proxy") 44 y el Conectador 100 de Correo. El Conectador 100 de
Correo se conecta, típicamente, a un Servidor de PWP 102 que
aguarda tratar peticiones procedentes del UP 44. El Servidor de PWP
garantiza que el conectador de peticiones y el UP, para una fuente
dada, están hablando con el mismo Servidor de PWP. Es también
responsable de distribuir las fuentes para todas las instancias del
Servidor de PWP. Para las fuentes que requieren y utilizan el
Conectador 100 de Correo, el Representante Universal 44 envía todas
las peticiones de correo de HTTP al Servidor de PWP 102,
conjuntamente con el GUID de PWP que identifica al cliente.
El representante universal 44 proporciona acceso
a las fuentes de correo externas 48 a través de una interfaz de
Correo de HTTP mejorada. El UP 44 da soporte a las siguientes
fuentes de correo, en un ejemplo no limitativo:
- a)
- IMAP con implementaciones especiales para AOL/Compuserve, Yahoo;
- b)
- POP con implementaciones especiales para MSN, RPA, Gmail;
- c)
- Conectador de Correo para el acceso a Domino y Exchange;
- d)
- Hotmail; y
- e)
- Acceso de web a Outlook.
\vskip1.000000\baselineskip
El acceso a una fuente de correo está demarcado
o delimitado por una Sesión de HTTP. Toda la información necesaria
para acceder a la fuente de correo viene proporcionada por la
petición inicial de la Sesión. Con el fin de traducir la petición
de Correo de HTTP al protocolo apropiado, existe un conjunto de
objetos denominados conectadores. Hay un conectador para cada tipo
de fuente de correo.
El representante de DA 42 es el conducto para
enviar un recibir correos electrónicos entre el motor 22 y las
fuentes de correo integradas 48. De manera adicional, el
representante de DA es el responsable de detectar correo nuevo
procedente de fuentes de correo externas y de impulsarlo o hacerlo
avanzar hasta el motor 22. Se utilizan tres mecanismos de detección
para el examen, la suscripción al buzón de correo para
notificaciones, y las conexiones permanentes a las fuentes.
También proporciona al motor el acceso a los
datos de Usuario. Trata los mensajes de MFH para fuentes integradas
(correo nuevo, respuesta, remisión, borrado). Y también hace avanzar
libros de servicio hasta el motor.
El Representante de DA 42 proporciona una
interfaz de HTTP sincrónica. Todas las peticiones de cliente son
inmediatamente dispuestas en cola y respondidas por medio de una
Respuesta de HTTP con la referencia 200. Cuando sea aplicable, la
petición especifica una dirección de HTTP a la que debe ser enviada
la "respuesta" en otra petición de HTTP. Cuando se envían
peticiones por duplicado por el mismo componente, éstas se dejan
caer una por una. Pueden manejarse diferentes peticiones de forma
asincrónica por el representante de DA 42. Estas incluyen:
- a)
- Recuperación de información de usuario (Motor 22);
- b)
- Recuperación de mensaje procedente de una fuente integrada (Motor 22);
- c)
- Nueva notificación de correo desde fuente suscrita (Servidor 46 de Suceso);
- d)
- Envío de libros de servicio, Mensajes de PIN y Cambio de PIN (SOAP); y
- e)
- Asignación de Fuente (SAM) 60.
\vskip1.000000\baselineskip
El representante de DA 42 es el responsable de
detectar activamente cambios en las fuentes asignadas a él por el
Gestor de Asignación 60 de Fuente. El representante de DA mantiene
un conjunto de fuentes 102 que organiza temporalmente para dar
servicio. Cada fuente tiene un cierto nivel o grado de examen. Se
realiza un menor examen para las fuentes que dan soporte a la
suscripción o a una notificación basada en una conexión. La Figura
8 ilustra, a un nivel alto, los componentes de la detección de
correo, incluyendo un organizador temporal 104 de fuente, destinado
a organizar temporalmente diferentes fuentes 102, así como también
un gestor 106 de suceso, como parte del representante de DA 42 y de
las fuentes Libres de IMAP.
El examen de las fuentes se organiza
temporalmente a intervalos regulares (habitualmente de 15 minutos).
En ocasiones, se expedita un examen de fuente si la heurística
determina que es probable encontrar nuevo correo. Existen tres
tipos de exámenes. El "IgnorarExamenAntiguo"
("IgnoreOldPoll") trabaja como un examen que recupera todos
los ID de mensajes procedentes de la fuente y los inscribe en la
base de datos de Partición 58. El propósito de esto es impedir la
detección de correo nuevo en ciertos puntos lógicos, tales como una
fuente que se acaba de integrar o el usuario al que se ha levantado
la suspensión.
El examen completo recupera todos los id de
mensaje de un buzón de correo de fuente con el fin de realizar una
reconciliación completa frente a todos los id de mensaje (UID) que
han encontrado los exámenes previos. Para cada nuevo UID que se
encuentra, el mensaje es recuperado y enviado al motor 22 para su
entrega al dispositivo 38. Para los UID no encontrados (borrados),
el UID es eliminado de la base de datos. Los nuevos UID son también
inscritos en la base de datos. El representante de DA 42 lleva a
cabo un examen completo en una fuente cuando se ha almacenado algo
más que el valor en la base de datos desde el último examen
completo, o cuando se ha inhabilitado un examen rápido para esta
fuente.
El Examen Rápido recupera sólo una "página"
de los ID de mensaje de fuente cada vez. Se detiene una vez que
encuentra un UID que ya ha visto. Llegado a este punto, supone que
ha encontrado todos los nuevos mensajes. Los nuevos mensajes son
entonces recuperados y enviados al Motor 22 para ser entregados al
dispositivo. No se inscriben nuevos UID en la base de datos.
Para los tipos de fuente que proporcionan
soporte a un mecanismo de notificación a través de una suscripción
(por ejemplo, Yahoo, Google), el representante 42 comprueba
periódicamente que estas fuentes se han suscrito en
correspondencia. Si una fuente se encuentra en un estado en el que
debe haberse suscrito, se envía una petición de suscripción; en caso
contrario, no se hace nada.
Algunos tipos de fuentes (IMAP IDLE) dan soporte
a un mecanismo de notificación por medio de una conexión permanente
a la fuente. El representante es el responsable de asegurarse de que
estas conexiones se creen, gestionen y destruyan de manera
apropiada.
El representante de DA 42 se comunica con el
trabajador 24 a través de una interfaz de HTTP. El trabajador
responde a la petición con una ACK [confirmación
-"acknowledgement"] con respecto al éxito de la petición (por
ejemplo, se ha aceptado de forma satisfactoria). Cuando se detecta
nuevo correo, el representante de DA impulsa o hace avanzar un
correo de cada vez, y aguarda a la ACK. Puesto que la ACK puede
llevar algún tiempo, el hilo o vínculo de examen no es bloqueado en
espera de la ACK. Si se da una NACK [no confirmación] para un
mensaje, el representante de DA dejará de impulsar o hacer pasar el
correo nuevo que se encontró, y tan sólo inscribirá los UID de
correo impulsados con éxito en la base de datos. Para los propósitos
de reintento, el representante de DA se asegurará de que se ha
programado un examen para la fuente en un lapso razonable de tiempo
(por ejemplo, en 15 minutos).
El representante de DA 42 no necesita acceder a
la Internet, si bien accede a la base de datos de Partición 58, al
SOAP 52, al Servidor 44 de Suceso, al Directorio 56, al Trabajador
24 y a su UP configurado 44 (por lo común, el anfitrión local). El
representante de DA se ocupa de un número fijo de usuarios para una
partición particular. El número de usuarios que un representante de
DA puede manejar se calcula midiendo su rendimiento. Cuantos más
usuarios se hayan asignado a una partición, más representantes de DA
desplegará el sistema. La carga se distribuye uniformemente entre
los representantes de DA a través de los componentes de
Directorio.
Un Servidor de Despliegue de Recursos (RDS
-"Resource Deployment Server") 64 permite que se desplieguen
dinámicamente recursos específicos de marca y de lenguaje. Los
recursos están compuestos, típicamente, de Juegos de Recursos de
Java, archivos XSTL e Imágenes, si bien no están limitados por
éstos. Cualquier archivo puede ser desplegado a través del RDS,
siempre y cuando la ubicación especificada en el sistema de objetivo
sea bien conocida (por ejemplo, directorio de plantilla,
web-inf/clases, etc.).
Un paquete de despliegue de recursos consiste en
un contenedor que contiene uno o más contenedores de recursos y un
archivo descriptor que describe cada contenedor de recursos y el
modo como ha de ser desplegado. En esencia, describe a qué
directorio bien conocido se ha de expandir un contenedor de
recursos, y qué versión de los recursos representa el contenedor de
recursos.
Un Gestor de Sobremesa es una aplicación que
proporciona una interfaz de usuario para la configuración de
cuentas de correo electrónico. El cliente de Sobremesa proporcionado
por el sistema "se enchufa" dentro del Gestor de Sobremesa y
proporciona una UI específica para la configuración de fuentes
integradas. Una API de Gestión proporciona una interfaz de SOAP
para la creación de cuentas y para la integración de fuentes de
correo electrónico. Un gestor de Sobremesa proporciona una interfaz
de usuario para integrar y gestionar cuentas de correo electrónico.
Se procurará un aprovisionamiento tanto simple como avanzado.
Cualesquiera apps [aplicaciones]
manejadas en Java pueden utilizar TCP (HTTP) como su transporte.
Esto permite el uso de API de dispositivo ya existentes que
proporcionan y gestionan todos los aspectos del tráfico de TCP
(HTTP) hacia y desde el dispositivo. Dentro del envoltorio de HTTP
existirá un componente de datos de XML [Lenguaje de Etiquetado
Extensible -"eXtensible Markup Language"].
Existen también dos aspectos del SMTP utilizado
con el sistema. Los proveedores de servicios desean que el correo
limitado exteriormente para sus usuarios vaya a través de sus
servidores de SMTP 49. El sistema, según se ha descrito, quiere
utilizar los servidores de correo de ISP para evitar problemas tales
como el "marcado como correo-basura o
spam". El sistema puede utilizar, y utiliza, en parte, su
propio servidor de SMTP interno 77 para confinar exteriormente el
correo en la actualidad. Los usuarios finales no siempre pueden
saber o recordar sus servidores de SMTP cuando están configurando su
buzón de correo integrado. La configuración del sistema hace
posible la especificación de un servidor de SMTP 49 dada una
combinación de protocolos de
correo-acceso-servidor. Una vez que
se ha integrado un buzón de correo, si la integración coincide con
una combinación dada (servidor, protocolo), es posible utilizar el
servidor de SMTP 49 especificado en la configuración. El sistema
puede, potencialmente, utilizar otros parámetros en el futuro. Para
proveedores de servicios que pueden especificar un servidor de
SMTP, el sistema puede automáticamente utilizar sus servidores de
SMTP 49 para sus usuarios. Los usuarios no tienen por qué pasar por
etapas adicionales para configurar sus servidores de SMTP. Esta
implementación trabajará automáticamente para buzones de voz de
dominio soportado por el sistema anfitrión, ya que estos utilizan,
típicamente, un servidor de acceso a correo específico del proveedor
de correo. Cabe la posibilidad de implementar una evaluación
automática de servidores de SMTP en el caso de que el sistema trate
de enviar un correo electrónico a una dirección de servidor
conocida, a través de un servidor de SMTP "evaluado",
utilizando las credenciales de acceso a correo.
El sistema habrá configurado automáticamente el
servidor de SMTP 49 incluso cuando el sistema no tenga una
configuración preexistente. La lógica de evaluación puede incluir el
usuario del servidor de acceso a correo de los usuarios o el
servidor de mezcla de su dominio de correo de ID de correo
electrónico (DNS). Es posible extender la solución para permitir a
los usuarios especificar sus servidores de SMTP 49. Si el
servidor-dominio del servidor de SMTP coincide con
el servidor-dominio del servidor de acceso a correo,
el sistema "aprenderá" esta información y tratará de utilizar
esto para otros usuarios que también utilizan el servidor de acceso
a correo.
Para los proveedores de servicios que pueden
especificar un servidor de SMTP 49, el sistema utilizará
automáticamente su servidor de SMTP para sus usuarios. Los usuarios
no tienen por qué pasar por etapas adicionales para configurar sus
servidores de SMTP. Esta implementación trabajará automáticamente
para buzones de correo de dominio soportado en el sistema
anfitrión, puesto que estos también utilizan un servidor de acceso a
correo específico del proveedor de correo. El sistema puede también
implementar una evaluación automática de servidores de SMTP cuando
el sistema trata de enviar un correo electrónico a una dirección
conocida a través de un servidor de SMTP "evaluado",
utilizando las credenciales de acceso a correo. Si funciona, el
sistema automáticamente configura el servidor de SMTP incluso
cuando el sistema no tiene una configuración preexistente. La lógica
de evaluación puede incluir el uso del servidor de acceso a correo
de los usuarios o un servidor max de su dominio de correo de
ID de correo electrónico (DNS).
Existen diferencias con la técnica anterior que
utiliza el sistema como se ha descrito. Una versión del Outlook
Express (terminal de sobremesa de correo de Windows en vivo
-"Windows Live Mail Desktop") configura automáticamente un
servidor de POP/SMTP para una dirección de correo electrónico dada,
para ISP populares. El WLMD [terminal de sobremesa de correo de
Windows en vivo -"Windows Live Mail Desktop"] se configura
automáticamente en una dirección de correo electrónico de usuario.
Una "KnowledgeBase" (Base de Conocimiento) para ISP popular es
descargada de los servidores y utilizada cuando la dirección de
correo electrónico del usuario coincide con la encontrada en la
"KnowledgeBase".
El sistema entrega un protocolo de servidor de
fuente integrada y un protocolo SMTP externo envía el correo
electrónico. El sistema configura el servidor de SMTP 49. El usuario
envía el correo y consulta el correo de envío externo del usuario
del servidor de SMTP. El sistema se sirve de sus propios servidores
de SMTP internos para enviar el correo electrónico, lo que permite
al sistema configurar de forma preliminar un servidor de SMTP
externo 49 para el envío del correo electrónico. La configuración se
realiza de antemano con un proveedor de servicios y, una vez que se
ha configurado cualquier sistema en forma de correo de envío, un
usuario del dispositivo envía el correo a un servidor externo y el
dispositivo mira en un servidor de SMTP externo para obtener la
información necesaria. A diferencia del Outlook Express, dado que se
trata de un servidor de acceso a correo, trata de hacerse una idea
de qué servidor utilizar. El correo de sobremesa de Windows, por
ejemplo, para Comcast, tiene una lista de servidores de SMTP
populares (los ISP populares están también en la lista).
El sistema puede implementar servidores de
invitado y utilizar lógica de averiguación automática.
El Soporte de SMTP de ISP puede ser añadido para
obtener un conjunto configurable de ISP. El Soporte de SMTP de ISP
puede dar soporte a una autorización basada en srcmbox.login
(identificación de acceso.srcmbox) y en srcmbox.password
(palabra de paso.srcmbox). El Soporte de SMTP de ISP puede dar
soporte a conexiones por SSL [capa de conexión segura -"Secure
Socket Layer"] cuando se configura.
La Figura 9 ilustra aspectos básicos de los
componentes según se han descrito. Se ha ilustrado el representante
de DA 42, que es susceptible de hacerse funcionar con el
representante de UP 44 como un componente 52 de salida de servicio y
SOAP, a modo de "Soapservlet", incluyendo una memoria caché. Se
ilustra el proveedor 48 de servicios de correo, que es susceptible
de hacerse funcionar con el representante de UP 44. Una tabla 112 de
base de datos que forma parte del servidor y de la plataforma 40 de
oficina móvil, se ha titulado "SmtpProviders" (Proveedores de
Smtp), con datos enviados a la memoria caché del SOAP 52. El buzón
de correo 114 de fuente ("Sourcemailbox") es susceptible de
hacerse funcionar con el SOAP 52 para comunicarse en relación con el
servidor y protocolo.
Puede haber una nueva tabla de base de datos y
un procedimiento almacenado en la Base de Datos Central, "Soap
Servlet" (Salida de Servicio de SOAP), Representante de DA ("DA
Proxy"), UpServlet. La tabla 112 se ha añadido para permitir la
configuración/especificación de sus servidores de STMP de ISP,
conocida como "SmtpProvider". La tabla 112 de StmpProvider se
utilizará para almacenar información de servidor de SMTP para un
servidor/Nombre de Protocolo ("protocolName") del srcMbox 114.
Si no se ha especificado en esta tabla un servidor/Nombre de
protocolo para un srcMbox, se utilizarán los servidores de SMTP
internos para enviar el correo.
Tal como se muestra en la Figura 9, la base de
datos incluirá una tabla 112 de SmtpProvider y datos relativos al
servidor, tales como el nombre de anfitrión ("hostname") o
dirección de IP (Protocolo de Internet -"Internet Protocol") de
servicio de correo de srcMbox; el Nombre de protocolo, tal como el
protocolo de srcMbox utilizado por los ajustes de servidor
especificado, incluyendo, como ejemplo no limitativo:
\vskip1.000000\baselineskip
bit 0: utilizar SSL
- 0 = no utilizar SSL;
- 1 = utilizar SLL;
bits 1-15: sin utilizar.
\vskip1.000000\baselineskip
Otra información de la tabla está relacionada
con el "smtpServer" como nombre de anfitrión de servidor de
SMTP, y con la "smtpPort" como, por ejemplo, puerta de SMTP
(defecto = 25). Otros datos se referirán a ajustes, descripción y
elementos de datos creados y modificados. Existirán procedimientos
almacenados, tales como el "sSmtpProviderMapping"
(establecimiento de relaciones de correspondencia de proveedor de
sSmtp) que es utilizado por la Salida de Servicio de SOAP para
seleccionar todas las filas de la tabla de smtpProvider.
El sistema modificará el
"SendMessageHandler" (Gestor de Mensajes de Envío) para que
incluya el smtpServer, la smtpPort, y el booleano de "useSSL"
(utilizar SSL) en peticiones de envío de correo electrónico que son
enviadas a la Salida de Servicio 52. El sistema modificará la Salida
de Servicio de SOAP 52 de manera que incluya el smtpServer, la
smtpPort y el booleano de useSSL en una respuesta "UserInfo"
(información de usuario).
La salida de Servicio de SOAP 52 guardará en
memoria caché los datos de Proveedor de SMTP hasta obtener un
objeto único. Puede añadirse una orden de Gestor de Salida de
Servicio ("clearSMTPProvCache" -"despejar la memoria caché
de proveedor de SMTP") para permitir el refrescamiento dinámico
de esta memoria caché sin que sea necesario un reinicio de la
Salida de Servicio de SOAP. Los datos pueden ser almacenados en un
Conjunto de relaciones de correspondencia ("Map") y,
típicamente, no debe haber más de varios cientos de entradas en esta
tabla.
El sistema proporciona soporte a una
auto-configuración de buzón de correo integrado,
dada una dirección de correo electrónico de usuario. Esto se hace
utilizando el dominio de correo de la dirección de correo
electrónico y confrontándolo con la base de conocimiento del
sistema. El sistema construye su propia base de conocimiento
basándose en la evaluación (en el dominio de correo) y en el
aprendizaje de las integraciones anteriores. Para los proveedores
de correo que dan soporte a los dominios albergados en el sistema
anfitrión, existen diversos dominios soportados en el sistema
anfitrión, cada uno de los cuales es utilizado por un pequeño
conjunto de usuarios. Por otra parte, el dominio de correo del
usuario puede no coincidir con el dominio de correo del servidor de
acceso al correo. Por ejemplo, el ID de correo electrónico puede ser
[email protected] y el servidor de acceso al correo
electrónico puede ser server.register.com.
El sistema no trabajará para la mayoría de los
usuarios de dominio soportados en el sistema anfitrión, ya que el
conjunto de la audiencia es un mayor número de dominios, cada uno
con un número más pequeño de usuarios, en oposición a un número
mayor de usuarios para un número más pequeño dominios. La adición de
una entrada de configuración a la base de conocimiento será también
embarazosa, ya que el número de entradas aumentaría de forma
explosiva.
El sistema simplifica la integración de dominios
de correo soportados en el sistema anfitrión. El sistema mantiene
una base de conocimiento de registros de MX [intercambio de correo
-"mail exchange"] procedentes del DNS y se confronta con la
base de conocimiento para recuperar la configuración de acceso al
correo para ese buzón de correo.
Esto permite al sistema configurar
automáticamente un buzón de correo integrado para todos los dominios
soportados en el sistema anfitrión, pertenecientes a un ISP, con
independencia de si otro usuario procedente de un dominio
especificado soportado en el sistema anfitrión tiene integrado su
buzón de correo. Esto también hace posible que la base de
conocimiento únicamente contenga una entrada para todos los dominios
soportados en el sistema anfitrión, pertenecientes a un proveedor
de correo, lo que simplifica enormemente la base de conocimiento.
El sistema puede utilizar, potencialmente, una solución similar
también para la recuperación de servidores de SMTP (configuración
de STMP limitada exteriormente frente a configuración de acceso a
correo limitada interiormente), con lo que se amplía la solución a
la configuración de otros servicios, no solo el acceso al correo. En
el futuro, el sistema puede implementar la estimación basándose en
patrones de registros de MX, si es que no hay coincidencias en la
base de conocimiento. El sistema puede también aprender por sí mismo
en la base de conocimiento, ampliando de esta la base de
conocimiento. En el futuro, el sistema puede también extender las
consultas a otros aspectos del DNS (o a algún otro servicio), y
recupera del DNS la dirección de IP, realizando una consulta de PTR
[pagar por leer -"pay to read"] para ver si va a un dominio
diferente y utiliza un servidor dentro de ese dominio.
Un registro de intercambio de correo (MX
-"mail exchange") puede constituir una entrada en una base de
datos de nombres de dominio que identifica un servidor de correo
que es responsable de hacerse cargo del correo electrónico para el
nombre de dominio. Pueden introducirse diferentes registros de MX
para cualquier nombre de dominio individual que esté utilizando más
de un servidor de correo. Puede obtenerse la prioridad por un
número de preferencia, el cual indica el orden en el que pueden
utilizarse los servidores de correo. Esto permitirá la posibilidad
de servidores de correo primario y de refuerzo. De esta forma, un
registro de MX establece una relación de correspondencia de un
nombre de dominio con una lista de servidores de intercambio de
correo para ese dominio.
Otros tipo de relación de correspondencia desde
un nombre hacia una dirección de IP es un registro de dirección (A
-"address"), por ejemplo, del nombre de anfitrión a una
relación de correspondencia de dirección de IP. Típicamente, en los
registros de MX de la técnica anterior, el número de preferencia más
pequeño tiene la prioridad más alta.
Debe comprenderse que, si bien el sistema de DNS
proporciona soporte a diferentes tipos de sistemas de registro, el
registro A es, típicamente, un conjunto de relaciones de
correspondencia directas entre un nombre y una o más direcciones de
IP. El registro de MX se utiliza, por lo común, para encaminar
tráfico de correo electrónico, por ejemplo, para el encaminamiento
de correos electrónicos de un nombre de dominio particular a un
servidor particular que puede ser diferente del que se encuentra en
los registros A. Típicamente, el registro de MX es un buen
indicador de adónde está el servidor de nombre de dominio de correo
electrónico encaminando el correo, y puede ser utilizado para
comprobar si se produce una coincidencia, pero también para mejorar
la lógica de estimación, tal y como se explicará más adelante. Si
el registro de MX no coincide, podría haber un fallo y el sistema
puede no tratar de autentificar, sino que pediría a un usuario que
reintrodujera los parámetros de dirección de correo electrónico
particulares. El sistema y el método pueden tomar una porción tras
la @ y realizar una indagación de DNS en la Internet en busca de los
registros de MX y A. Pueden extraerse un cierto número de registros
de MX, de manera que se escoge el mejor para cumplir con lo aportado
y determinar de qué servidor se ha de extraer el correo,
especialmente cuando una compañía tiene varios servidores con
diferentes registros de MX actuando como respaldos o refuerzos. Esto
es importante para los nombres de dominio personalizados o de
ostentación. Si existe un registro A, puede haber o no una
introspección adicional en lo que se ha aportado, si bien en
algunos casos puede utilizarse el registro A para determinar una
dirección válida. Es también posible realizar diversas predicciones
o pronósticos, según se explica más adelante. En caso contrario, se
indica al usuario que se trata de una dirección no válida.
Se producen mejoras en el
IMAP-Idle. El IMAP-Idle se describe
en la RFC [Petición de comentarios -"Request For Comments"]
2177, la cual se incorpora aquí como referencia en su totalidad.
Existen ciertas ventajas en cuanto a los límites de conexión de
IMAP-Idle atendiendo a criterios basados en el
usuario y a criterios basados en el servidor, así como ventajas para
estos. Hay dos problemas que acomete esta mejora en el
IMAP-Idle.
En primer lugar, un sistema principal o
anfitrión único, tal como el AOL, puede tener una cantidad X de
usuarios y permitir una cantidad Y de conexiones de TCP simultáneas
(siendo X > Y). Si los X usuarios de AOL proporcionan soporte a
IMAP-Idle, se realizarán intentos de conexión para
los X usuarios, incluso aunque solo se dé soporte a Y conexiones.
Si esto no se acometiera, otros sistemas anfitriones serían
incapaces de realizar otras conexiones de TCP con el sistema
anfitrión.
En segundo lugar, una cuenta de correo
electrónico de IMAP de un único usuario tan solo puede dar soporte
a una conexión simultánea de TCP. En el caso de que se utilice una
segunda conexión para recuperar datos de usuario de la misma
cuenta, la primera conexión o la segunda conexión pueden ser
desactivadas o desconectadas con o sin aviso. Suponiendo que esto
no se tuviera en cuenta, la integración de correo fallaría de forma
indefinida.
Se ha implementado en el sistema un gestor de
conexión de Java de IMAP-Idle, Debido a que hay
tantos límites de conexión de TCP que varían de un dominio a otro,
no es deseable establecer un límite de conexión de TCP limitado
externamente y codificado en soporte físico para estos dominios. En
lugar de ello, se introduce un gestor de conexión de
IMAP-Idle con el fin de gestionar los fallos de
conexión de IMAP-Idle. Si una conexión de
IMAP-Idle sufre una anotación de fallo, la gestión
por parte del gestor de IMAP-Idle se incrementa en
uno hasta que alcanza un límite. Si se alcanza o supera el límite,
la fuente se marca como "inhabilitada" para
IMAP-Idle, de manera que la fuente no será conectada
para establecer una conexión de IMAP-Idle. En
consecuencia, si el dominio A tiene un límite D establecido y el
sistema se conecta con éxito en el instante D, todos los intentos
de conexión subsiguientes de IMAP-Idle y examen
fallarán. Al marcar fuentes como no válidas para este tipo de
conexión, se garantiza que todas las fuentes tienen acceso a este
dominio. En el caso de que se cayese la conexión de
IMAP-Idle, el sistema determina si se ha caído
mientras estaba en progreso un examen de correo electrónico
(conexión secundaria). Si es así, la cuenta se marca como
"inhabilitada" para IMAP-Idle, de manera que
no se realizarán suscripciones en la cuenta en el futuro, con lo que
se preservan recursos y se mejora la experiencia de entrega de
correo electrónico para el usuario.
La definición de IMAP-Idle
establece que el servidor de IMAP presenta visualmente el término
IDLE cuando se pregunta al servidor por las capacidades a las que
da soporte. Si el servidor afirma dar soporte a
IMAP-Idle pero no consigue entrar en el estado
IDLE, el sistema trata, de forma continua, de establecer conexiones
de IMAP-Idle cuando una no es posible. Se ha
implementado un gestor de IMAP-Idle que comprueba el
resultado de la tentativa de establecer una conexión de
IMAP-Idle. Si la conexión falla X veces seguidas, la
característica de IMAP-Idle será inhabilitada, de
tal manera que el sistema puede dejar de intentar conectarse a un
servicio al que no se da soporte o que se ha configurado
incorrectamente.
Son éstos casos en los que el servidor de correo
electrónico informa de las capacidades IDLE de IMAP pero no
consigue entrar realmente en el estado IDLE. En este caso, el gestor
de IDLE de IMAP efectuará un seguimiento del número de intentos de
establecer una conexión de IDLE de IMAP con ese servidor y, si el
fallo supera un umbral previamente especificado, entonces el
sistema puede dejar de tratar de conectarse a un servicio al que no
se ha proporcionado soporte.
El entorno de examen del sistema puede tratar de
examinar la cuenta en un intervalo razonable, esperando encontrar
nuevos mensajes de correo. Si el nuevo correo está disponible, es
descargado y enviado al usuario a través de su dispositivo. Si esta
cuenta es susceptible de ser suscrita (se da soporte a
IMAP-Idle), el sistema puede reducir la cantidad de
conexiones y de intentos de conexión con el sistema anfitrión, el
cual no acepta elevadas tasas o velocidades de conexión. El sistema
puede minimizar la cantidad de datos enviados a través de la
Internet y produce un sistema de entrega rápida del correo
electrónico.
La conexión de IMAP-Idle es
capaz de supervisar la cuenta con respecto a los cambios que se
producen y cargar de inmediato nueva información cuando se presenta
un suceso. Esto permite que el sistema se salte exámenes vacíos o
sin contenido (innecesarios) para una fuente que no ha recibido
ningún correo nuevo. El salto de las consultas o exámenes ahora
transferencia de datos y cualesquiera tentativas de conexión o
conexión de TCP innecesarias, así como también entrega de correo
electrónico de forma inmediata o en tiempo real. Esta
implementación se centraliza y representa como una suscripción, en
contraposición a los sistemas PALM y MS, que están basados en el
dispositivo y en la aplicación.
El IDLE de IMAP es una expansión o ampliación
opcional del protocolo de acceso a correo electrónico de IMAP que
permite al servidor enviar actualizaciones de mensaje nuevo al
cliente en tiempo real. En lugar de hacer que se compruebe el
programa de correo electrónico del sistema en busca de correo nuevo
cada pocos minutos, el IDLE de IMAP permite al servidor notificar
el programa de correo electrónico una vez que han llegado nuevos
mensajes. El sistema puede ver el correo entrante de inmediato. El
uso de IDLE de IMAP es conocido. Sin embargo, la diferencia con
respecto al PALM es que el sistema implementa este en el sistema, al
igual que con el representante de DA 42, no en el dispositivo.
Los servidores de IMAP se ajustan para permitir
una conexión de TCP de 30 minutos antes de que puedan desconectarlos
de acuerdo con el FRC de IMAP. Si el sistema ha de mantener una
conexión de IMAP-Idle indefinidamente, debe
encontrar un método para evitar esto sin perderse nuevos sucesos de
correo producidos por la conexión de IMAP-Idle
entretanto. Debido a que se conocen diversos dominios de Internet
para desconectar conexiones de TCP antes de 30 minutos, el sistema
se vuelve a suscribir cada X minutos, siendo X susceptible de
reconfigurarse. A fin de suscribir el sistema rápidamente, este
genera una "recogida y carga de datos" con el fin de comprobar
si se ha recibido correo nuevo antes de reentrar en el IDLE (estado
suscrito o abonado). Esto garantiza que la conexión se mantiene
viva y que no se pierden nuevos sucesos de correo electrónico.
De acuerdo con ejemplos no limitativos, el
protocolo de IMAP es actualizado con una nueva orden IDLE, con cuya
utilización los clientes se sitúan en un modo "libre". En este
modo, un servidor de IMAP envía cambios de buzón de correo a modo
de respuestas no etiquetadas al cliente "libre", tal como
cuando se añaden nuevos mensajes o cuando son borrados. Los clientes
se salen de este modo "libre" emitiendo un "DONE"
(HECHO).
La MOP 40, como servidor de Acceso Directo,
proporciona soporte en la actualidad a un modelo de
suscripción/notificación para entrega de correo en tiempo real. En
este modelo, un buzón de correo - proveedor notifica a la MOP de
cuándo lleva un correo nuevo a un buzón de correo. No existe ninguna
conexión persistente entre la MOP 40 y el proveedor de correo.
Al dar soporte a IDLE de IMAP, la MOP 40 puede
facilitar a los proveedores de correo dar soporte a la entrega de
correo en tiempo real. A fin de dar soporte a IDLE de IMAP, la MOP
necesitará mantener una conexión persistente con el proveedor de
correo. La conexión utilizada en esta implementación de
IMAP-Idle se utilizará tan solo para detectar nuevo
correo y notificar que la fuente relacionada está lista para ser
examinada. Todos los trabajos previos de MTH y de MFH permanecen
como trabajo completado por la cola de trabajo del representante de
DA y por su salida de servicio de UP. El sistema da soporte a
notificaciones en tiempo real para todas las fuentes de IMAP que
proporcionan soporte a la capacidad de IDLE.
Las suscripciones externas son suscripciones
persistentes hechas con proveedores de correo externos tales como
Yahoo y Gmail. Se producen fallos de identificación de acceso de
Idle después de haberse recibido un intento de introducción de
identificación de acceso no válida que trata de inicializar una
conexión de IMAP-Idle. La recepción de este fallo
aumentará en uno el cómputo de fallos de introducción de
identificación de acceso ya existente.
Un cómputo de fallos de suscripción libre
incluirá todos los errores relacionados con la conexión y con
órdenes cuando se trata de establecer un estado libre o inactivo
para una fuente de IMAP particular. Típicamente, no se incluyen en
la cuenta características de la identificación de acceso.
Con el fin de dar soporte a IDLE de IMAP, el
sistema mantendrá una "ConexiónLibreImap"
("ImapIdleConnection") 120 para cada usuario en el
Representante de DA 42, según se muestra en la Figura 10.
La ConexiónLibreImap 120 descubre la presencia
de nuevo correo y esto desencadena o dispara el mecanismo de examen
normal que pasa por la Salida de Servicio de UP, la cual seguirá
siendo utilizada para el examen y para todas las operaciones de
MFH. La creación de ConexionesLibresImap 120 en el Representante de
DA ayuda a que el sistema de examen contenido en el Representante
de DA mantenga el seguimiento de estas conexiones para cada fuente.
Una "BombaES" ("IOPump") 122 sirve como gestor de conexión
para todas las ConexionesLibresImap 120.
A diferencia de las suscripciones externas que
se conservan en la base de datos, las suscripciones de
IMAP-Idle se consideran transitorias y se encuentran
solo en la memoria del Representante de DA.
El Organizador Temporal 104 de Fuente y el
Representante de DA mantienen el seguimiento de las suscripciones
IDLE de IMAP. A diferencia de las suscripciones externas, que se
mantienen en la tabla de SrcMbox con un "Idsuscripción"
("subscriptionId"), estas suscripciones se encuentran en la
memoria. Una vez que se ha realizado un examen con éxito, el
Organizador Temporal 104 de Fuente determina si una fuente capaz de
IMAP-IDLE no ha sido aún suscrita. El Organizador
Temporal de Fuente 104 crea una ConexiónIdleImap para este buzón de
correo 114 de fuente, e inicia el procedimiento de suscripción. Las
fuentes que se marcan con "inhabilitarSuscripción"
("disableSubscribe") 115 no se suscribirán.
Después de cada examen, el Organizador Temporal
104 de Fuente actualiza la suscripción en una ConexiónLibreImap.
Las actualizaciones a una "MarcaAguaalta"
("highWaterMark"), tal como se muestra en el diagrama de flujo
de la Figura 11, permiten a la ConexiónLibreImap descubrir
apropiadamente los nuevos mensajes cuando se cierra una conexión
"libre". Adicionalmente, esto permitirá que una
ConexiónLibreImap recoja cualesquiera cambios en el buzón de correo
de fuente como actualizaciones en los datos de buzón de correo de
fuente, tales como el servidor/usuario/palabra de paso.
La Figura 11 ilustra introducción de
identificación de acceso, determinación e IDLE con el fin de mostrar
la conexión de IMAP-Idle a la hora de descubrir
nuevos correos.
Es posible realizar una optimización para las
fuentes de IMAP-IDLE, a fin de cambiar de inmediato
el "siguienteExamen" ("nextPoll") a después de 6 horas.
Para las suscripciones externas, el sistema puede cambiar el
siguienteExamen solo después del siguiente examen si quiere captar
cualesquiera correo nuevos entre el último examen y una petición de
suscripción con éxito. La ConexiónLibreImap es capaz de descubrir
cualquier nuevo correo desde el último examen. Como resultado de
ello, es posible realizar esta optimización.
Si el Organizador Temporal 104 de Fuente
descubre que una fuente no debe ser consultada o examinada ya más,
se lo notifica a cualquier ConexiónLibreImap 120 existente para que
detenga cualesquiera notificaciones adicionales y limpie o despeje
la ConexiónLibreImap.
Se le notifica al Organizador Temporal 104 de
Fuente acerca de cuándo la ConexiónLibreImap 120 descubre nuevo
correo en el buzón de correo. El Organizador Temporal de Fuente
organiza temporalmente un examen al recibir dicha notificación. En
el caso de que la ConexiónLibreImap 120 no pueda ponerse en el modo
libre, le notifica al Organizador Temporal de Fuente que la
suscripción ha fracasado. Algunos de los fallos son fallos de
identificación de acceso Libres y el resto son fallos de
suscripciones Libres.
Tal como se muestra en el diagrama de flujo de
la Figura 11, para utilizar la conexión de IMAP-Idle
120, el Organizador Temporal 104 de Fuente debe primero determinar
si la Fuente de IMAP es susceptible de ser suscrita. Con el fin de
determinar esto, el Representante de DA realiza una llamada de
vuelta al Organizador Temporal de Fuente una vez completado un
examen para esta fuente. La llamada de vuelta lista nuevas
propiedades tales como la marca de agua alta y la susceptibilidad de
suscripción.
Si ocurre que la fuente es susceptible de
suscribirse, entonces el organizador temporal de fuente creará un
nuevo trabajo de suscripción y lo añadirá a la cola de tratamiento
de Representante de DA. Estos trabajos son manejados por los
gestores de suscripción y de reversión de la suscripción.
La primera tarea de los gestores es determinar
el recurso que se ha de utilizar para completar su trabajo. Para la
ConexiónLibreImap, ese recurso es el Organizador Temporal de Fuente.
El gestor hace una llamada al Organizador Temporal de fuente con el
fin de suscribir o abonarse a esta fuente específica, y se
proporciona un código de respuesta para el éxito o el fracaso de ese
procedimiento, tal como se muestra en la Figura 11.
Se realiza una llamada de vuelta al completarse
el trabajo de suscripción. En el caso de que la suscripción haya
tenido éxito, la etiqueta o indicador de disponibilidad de
suscripción se anulará y se marcará la fuente como una fuente
suscrita.
La Figura 12 es un diagrama que muestra el
organizador temporal 110 de fuente y la cola de examen 140 cuando
una fuente ya ha sido marcada como disponible para suscripción por
la llamada de vuelta previa desde el examen al Organizador Temporal
de Fuente. La cola de examen 140, se ilustran la cola de trabajo 142
de representante de DA y el servidor 144 de nombre, que trabajan
conjuntamente, tal como se muestra.
Si una ConexiónLibreImap 120 se encuentra con un
error de conexión o un error a la hora de emitir órdenes, le
notifica al Organizador Temporal 104 de Fuente que la suscripción ha
fallado al devolver un fallo de suscripción libre. El Organizador
Temporal de Fuente mantiene el seguimiento del error y hace que el
siguiente examen se dirija a esa fuente dentro de 15 minutos desde
el último examen. Si el "Cómputofallos" ("failureStreak")
para este error supera un límite considerable, esta fuente se
marcará con un bit de ajuste de "inhabilitarSuscripción"
("disableSubscribe").
En el caso de que la ConexiónLibreImap descubra
un fallo de introducción de identificación de acceso, devuelve un
fallo de identificación de acceso libre al Organizador Temporal de
Fuente. El Organizador Temporal de Fuente incrementa el cómputo
existente de fallos de identificación de acceso en la fuente.
Cualquier fuente con un Cómputofallos > 0 no será susceptible de
suscripción. Los fallos de identificación de acceso no tendrán como
resultado un bit de "inhabilitarSuscripción" permanente.
Algunas implementaciones del protocolo de IMAP
exhiben una situación de competencia o carrera. Si un buzón de
correo recibe un correo nuevo después de que el cliente se haya
situado en un estado seleccionado y antes de que se haya emitido una
orden libre, el sistema devolverá una respuesta de "existe"
carente de indicador o etiqueta, indicando la presencia de un nuevo
correo. La Figura 13 ilustra un diagrama de flujo del método.
El sistema mitiga esto al emitir de forma
inmediata una orden "libre" una vez que el sistema recibe una
repuesta para una orden de "recogida y carga de datos". El
sistema reconoce la respuesta de "recogida y carga de datos" de
forma asincrónica después de que se haya emitido la orden
"libre". La situación de carrera no se evita por completo, sino
que se reduce a un intervalo muy corto, que se espera sea de menos
de un segundo.
Este problema se mitiga adicionalmente por el
mecanismo originalmente diseñado para restablecer temporizadores de
vencimiento de IMAP. A fin de restablecer el temporizador de
vencimiento, el objeto de ConexiónLibreImap emitirá un
"HECHO", para salir del estado de funcionamiento libre de IMAP,
seguido de un "FETCH" ["recogida y carga de datos"] para
restablecer el temporizador y comprobar si se ha recibido nuevo
correo. Si se perdió correo durante la situación previa de carrera
o como consecuencia de una implementación libre defectuosa, será
captado aquí. Esto se llevará a cabo cada 5 minutos, pero será
susceptible de configurarse.
El Organizador Temporal de Fuente mantiene un
seguimiento del nuevo correo descubierto en las reconexiones. Si
descubre sucesivamente correo nuevo solo al reconectarse y llega
hasta un límite configurable (valor por defecto es de 0 a
infinito), realiza una llamada de vuelta al Organizador Temporal de
Fuente (él mismo), inhabilitando la suscripción, y marca
adicionalmente "inhabilitarSuscripción" de la fuente. En
notificaciones de correo nuevo, la ConexiónLibreImap informa al
Organizador Temporal de Fuente sobre si el hallazgo procede de una
reconexión (examen) o de una notificación libre.
Estableciendo el valor por defecto en infinito,
la conexión existente proporciona una alternativa de examen más
ligera y es, por tanto, aún aceptable.
Si el Organizador Temporal de Fuente descubre
correo nuevo durante los exámenes de reserva, mantiene el
seguimiento de los cómputos de "nuevoCorreoEnReserva"
("newMailOnFallback"). Si llega a un máximo configurable, a
fuente de IMAP-Idle se marcará con
"inhabilitarSuscripción", que se mantiene en la base de datos.
Para las suscripciones externas, se deshará la suscripción de estas
y se volverán a suscribir en un siguiente examen. El valor por
defecto para este límite es 3.
De manera adicional, para mejorar la experiencia
del usuario, el Organizador Temporal de Fuente cambia el siguiente
examen por el valor por defecto de 15 minutos cuando se halla nuevo
correo en un examen de reserva. Para las suscripciones externas, se
deshará la suscripción de estas y se volverán a suscribir en la
siguiente consulta o examen. El sistema puede, por tanto,
encaminarse cuando las suscripciones quedan fuera de
sincronismo.
Si un proveedor de correo restringe el número de
conexiones permitidas, el sistema hallará estas limitaciones como
fallos de conexión normales, lo que tiene como resultado que se
marca el buzón de correo como "inhabilitarSuscripción". Esto es
también válido para el AOL.
Similarmente a los POP [Protocolos de Oficina de
Correos -"Post Office Protocols"], los servidores de IMAP
pueden también devolver errores "de buzón de correo bloqueado".
Si la ConexiónLibreIMAP devuelve un error de "buzón de correo
bloqueado", se deshace o revierte inmediatamente la suscripción
de la fuente y esta se marca como "inhabilitarSuscripción". Por
otro lado, si se devuelve como error "buzón de correo
bloqueado" durante los exámenes normales, el Organizador Temporal
de Fuente lo reconoce y, si hay una ConexiónLibreImap ya existente
para la fuente, deshace la suscripción de esta, y marca la fuente
con "inhabilitarSuscripción".
Si una conexión de IMAP-Idle
está desconectada mientras el organizador temporal de fuente está
tratando una nueva notificación de correo, el organizador temporal
incrementará el cómputo de fallos de suscripción de IMAP y
proseguirá con la siguiente fuente. Suponiendo que el examen ha
tenido éxito, la fuente será marcada como disponible para suscrición
o no disponible para suscripción por el mecanismo de consulta o
examen. Si el examen no ha tenido éxito, el organizador temporal de
fuente continuará examinando esta fuente cada 15 minutos.
Si falla una conexión de examen mientras existe
una conexión de IMAP-Idle, el organizador temporal
deshará la suscripción de la fuente, incrementará el cómputo de
fallos y expedirá el examen. Al proporcionar un mecanismo para
restablecer o restituir los cómputos de fallos, el sistema no
incurrirá en problemas a largo plazo y encontrará todas las fuentes
en "inhabilitarSuscripción".
El sistema puede evitar la situación de carrera
de IMAP-Idle utilizando otra conexión para comprobar
si hay nuevos correos una vez que las conexiones de
IMAP-Idle se han situado en un modo libre. Esto
puede hacerse también desencadenando un examen adicional cada vez
que se entra en el modo libre. Algunos servidores pueden cerrar los
servidores mucho más a menudo, y el sistema no necesariamente quiere
realizar un examen en cada cierre de conexión. El sistema entra en
un modo libre cada vez que se cierra una conexión. El sistema puede
emitir órdenes de "recogida y carga de datos" y de
"funcionamiento libre" de forma simultánea, con lo que se
reduce aún más el estado
de carrera.
de carrera.
La supervisión de IMAP-Idle se
utiliza para supervisar la salud de la característica. Los
siguientes campos permitirán a un gestor determinar si un
organizador de fuente particular es capaz de abonarse a fuentes de
IMAP y cómo fluctúa la cantidad de suscripciones (errores recibidos)
durante los intervalos de examen. Puede hacerse un seguimiento de
diferentes campos, tales como:
- número de conexiones libres (acumulativo);
- tiempo para suscribirse (acumulativo);
- número de peticiones de suscripción (acumulativo);
- nueva notificación de correo - libre (acumulativo);
- nueva notificación de correo - reconexión (acumulativo);
- fallos de identificación de acceso (acumulativo);
- buzón de correo bloqueado (acumulativo);
- conexiones perdidas (acumulativo);
- órdenes de IMAP fallidas (acumulativo);
- pérdida de estado libre (acumulativo);
- examen fallido (acumulativo); y
- cuántos bits de inhabilitarSuscripción se establecieron (acumulativo).
\vskip1.000000\baselineskip
En lo que sigue se dan más detalles referentes
al examen y detalles relativos a las notificaciones de estado fuera
de cobertura con el fin de ahorrar recursos en el Representante de
DA.
La MOP 40 y los trabajadores 24, según se
muestra en la Figura 15 y se explica con mayor detalle más adelante,
interactúan para suspender el examen de fuentes de correo
electrónico basándose en el hecho de que los dispositivos de
usuario se encuentran fuera de cobertura o han sido apagados o
desconectados. Esto permite evitar un examen innecesario cuando un
usuario o usuaria no puede, en cualquier caso, recibir su correo.
Sin embargo, los problemas se presentan a la hora de designar un
abonado como fuera de cobertura, en tanto en cuanto las
notificaciones a los trabajadores 24 de situación en cobertura o
fuera de cobertura pueden no llegar en orden. Es más, existe la
posibilidad de que tales notificaciones se pierdan, tal como ocurre
cuando hay un suceso de fallo de trabajador. Una operación especial
de examen "seguro frente a fallos" ("failsafe") para
fuentes que están fuera de cobertura, permite a los trabajadores
corregir el estado de MOP si se produce una situación de error o
"situación de carrera" que no se había detectado de otro
modo.
Debe comprenderse que existen constantemente
fuentes que son atribuidas a una cuenta cuyo dispositivo de mano
está fuera de cobertura (o desconectado). En la actualidad, estas
fuentes siguen siendo examinadas en busca de correo nuevo incluso
cuando se encuentran fuera de cobertura. Este examen no es útil, ya
que no se puede entregar el correo al dispositivo cuando este se
encuentra fuera de alcance. En consecuencia, el examen consume
anchura de banda y utiliza los recursos del sistema
innecesariamente.
\newpage
\global\parskip0.900000\baselineskip
De acuerdo con ejemplos no limitativos, el
organizador temporal 104 de fuente recibe una petición de contención
de retransmisión por medio del Representante de DA 42 para cada
dispositivo 38 que se encuentra fuera de cobertura. El propósito de
manejar peticiones de contención de retransmisión en la MOP es:
1) ahorrar anchura de banda y no examinar
fuentes que están fuera de cobertura;
2) reanudar el examen de fuentes cuando un
usuario vuelve a estar en cobertura; y
3) reducir el número de mensajes que deben
guardarse en la memoria caché del disco de los trabajadores.
\vskip1.000000\baselineskip
Un dispositivo 38 que entra y sale de cobertura
(esto podría suceder si alguien se encuentra cerca de una señal
débil) tiene como resultado que se producen las peticiones de
contención de retransmisión con relativa frecuencia para el
trabajador. No hay seguridad de que estas peticiones no queden fuera
de servicio alguna vez a lo largo del recorrido o camino hasta el
trabajador 24. Por otra parte, la naturaleza asincrónica del motor
22 de cliente de web, la MOP 40 y los protocolos de retransmisión
ubicados dentro del retransmisor 34 se encaminan a un número
ilimitado de frecuencias y magnifican la posibilidad de una
situación de carrera entre las notificaciones fuera de cobertura y
las notificaciones dentro de cobertura. El trabajador 24 necesita,
bien mantener las notificaciones en un sincronismo o bien detectar y
desestimar cualesquiera notificaciones fuera de sincronismo.
Existe también el problema de un suceso de fallo
de un trabajador, con el que se da la posibilidad de que la
notificación dentro de cobertura procedente del retransmisor 34 se
"pierda" y la MOP 40 no reciba la notificación. Si no hay
mensajes en su cola de trabajo cuando el trabajador vuelve a estar
en línea, éste no marcará la cola como dentro de cobertura y, por lo
tanto, no los enviará a la MOP en una notificación dentro de
cobertura. En este caso, la fuente seguirá estando marcada como
fuera de cobertura en la MOP y, potencialmente, nunca será examinada
en busca de un correo de fuente entrante. Esencialmente, el problema
es que el trabajador 24 únicamente tiene conocimiento de los
usuarios que tienen mensajes que se están tratando. Si, por alguna
razón, se han completado todos los trabajos existentes en el
trabajador pero la MOP tiene el usuario etiquetado como fuera de
cobertura, no hay forma de que el trabajador 24 sepa a quién ha de
examinar o consultar el estatus (el usuario no existe por lo que
respecta al trabajador). El trabajador únicamente solicita al
usuario información cuando entran en el sistema nuevos trabajos. En
este "caso de situación de carrera" no llegará correo nuevo
porque la MOP ha dejado de examinar y el usuario seguirá estando
marcado como fuera de cobertura.
A fin de evitar la situación que se acaba de
describir, la MOP 40 lleva a cabo periódicamente un "examen seguro
ante fallos" para todas las fuentes susceptibles de ser
examinadas y que se encuentren fuera de cobertura (una fuente
susceptible de ser examinada no está suspendida ni de otro modo
inhabilitada). En otras palabras, el trabajador 24 corregirá la MOP
en el caso de que se haya producido una situación de carrera o una
situación de error que no se detectase de otra manera.
Un modo de hacer esto es de tal manera que el
Representante de DA de MOP 42 examine el trabajador para saber su
estatus de fuera de cobertura. Este examen es desencadenado por el
intervalo de examen para el buzón de correo de fuente, por parte del
organizador temporal 104 de fuente. Si el trabajador sabe que este
usuario se encuentra aún fuera de cobertura, informará de ello como
tal en cualquier caso, esto es, está enviando mensajes a un usuario
dentro de cobertura o no tiene conocimiento del usuario en absoluto,
e informará de un estatus fuera de cobertura. Esta solución tiene
las siguientes ventajas: a) en la mayoría de los casos, el
flujo/examen de correo se reanudará inmediatamente tan pronto como
el usuario vuelva a estar en cobertura, b) si el sistema se pierde
notificaciones o queda fuera de servicio, el sistema tendrá un
examen seguro ante fallos que pueda descubrir/notificar estatus y
sincronizarse de forma relativamente rápida en caso necesario, y c)
en el caso de que un trabajador sufra un fallo, el Representante de
DA examinará el trabajador 24 al que se reasignará el usuario
situado fuera de cobertura, y el trabajador informará del estado en
cobertura, ya que no sabe nada acerca de este usuario.
La base de datos 58 de partición pone un sello
temporal en cada fuente, que especifica la última vez que se cambió
la fuente. Se proporcionan dos indagaciones. La primera indagación
simplemente devuelve la lista completa de fuentes dentro de la
partición y puede utilizarse un sello temporal en la segunda
indagación. La segunda indagación, dado un sello temporal desde la
última indagación, devuelve todas las fuentes cambiadas desde la
última indagación, y otro sello temporal destinado a utilizarse en
la siguiente indagación.
A continuación siguen detalles de la MOP 40
relativos al examen, a fin de comprender mejor el procedimiento de
notificación de situación fuera de cobertura.
El Gestor de Asignación 60 de Fuente es un
servicio del nivel de partición, que es el responsable de garantizar
que se está dando servicio a todas las fuentes de una partición.
El SAM [Gestor de Asignación de Fuente
-"Source Assignment Manager"] 60 mantiene una lista de todas
las fuentes pertenecientes a su partición configurada. Para cada
fuente contenida en la lista, efectúa un seguimiento de datos
relativos a la identificación de forma unívoca de cada fuente. Por
otra parte, se efectúa un seguimiento de la asignación de
Representante de DA 42 y de la asignación de nodo de directorio con
el fin de hacer posibles las notificaciones de reasignación y/o
disminuir las notificaciones de reasignación debido al Representante
de DA y al fallo de directorio.
\global\parskip1.000000\baselineskip
Se realiza también el seguimiento de un sello
temporal. El sello temporal es un valor devuelto por la base de
datos y que puede ser utilizado para recuperar fuentes que se han
cambiado desde el último examen. El SAM mantiene el "SrcMboxId"
y el "MboxAcctId", además del PIN y el "IdLibroServicio"
("ServiceBookId") ya que el "SrcMboxId" y el
"MboxAcctId" el son propiedades de una fuente, en
contraposición al PIN y al IdLibroServicio, y ayudan al SAM a
verificar la identidad de una fuente después de que haya cambiado un
pin o número de identificación personal.
Cuando se inicia el sistema, es responsabilidad
del Gestor de Asignación de Fuente (SAM) comenzar la asignación de
todas las fuentes a representantes de DA. Lo que sigue es una
secuencia de las etapas para asignar todas las fuentes:
1) Registrar en el Directorio las notificaciones
de sucesos. El SAM registrará los sucesos de DA y de fallo de
directorio.
2) Apelar a la DB [base de datos
-"database"] de la partición para adquirir una lista de todas
las fuentes existentes. La base de datos también devolverá una
etiqueta o sello temporal que puede ser utilizado para indagar
acerca de cualesquiera fuentes nuevas o cambiadas.
3) Para cada fuente, apelar al Directorio de uno
o más lotes con el fin de obtener asignaciones de Representante de
DA y guardar en memoria caché esta información.
4) Agrupar las fuentes por el Representante de
DA al que se hayan asignado.
5) Realizar una llamada por lotes a cada
Representante de DA que contiene fuentes asignadas.
6) Cada Representante de DA, al recibir las
asignaciones, añade las fuentes a su cola de fuentes.
\vskip1.000000\baselineskip
Periódicamente, el SAM 60 preguntará a la base
de datos por todas las fuentes que son nuevas o se han cambiado,
utilizando el sello temporal que se devolvió en respuesta a la
indagación realizada al comienzo. Expenderá entonces notificaciones
al representante de DA para cada una de estas fuente. Este paso es
necesario para "garantizar" que se están examinando todas las
fuentes. Por defecto, se llevará a cabo un barrido cada 15 minutos
desde el barrido previo. Este intervalo será configurable. El SAM
guardará en memoria caché la información de asignación de
Representante de DA. Las ventajas de hacerse con esta información
son como sigue:
1) En el caso de un fallo de Representante de
DA, le permite al SAM realizar una consulta en directorio solo para
las fuentes asignadas al Representante de DA que ha fallado. En caso
contrario, el SAM tendrá que efectuar una consulta en base de datos
para encontrar las fuentes que han cambiado desde la última
indagación, utilizando el sello temporal devuelto por la última
indagación.
2) En el caso de un fallo de Directorio, le
permite al SAM sugerir al directorio con qué Representante de DA
debe establecer una relación de correspondencia para cada fuente con
el fin de reducir la cantidad de reasignación.
3) En ambos tipos de fallos (Representante de DA
y Directorio 56), se evita un conflicto entre bases de datos para
encontrar todas las fuentes cambiadas desde el último sello temporal
en la partición, puesto que la información está guardada en la
memoria caché. El Representante de DA 42 es el responsable de dar
servicio a, y gestionar, las fuentes que le han sido asignadas por
parte del SAM 60. El Organizador Temporal 104 de Fuente gestiona y
da servicio a las fuentes y puede iniciar las suscripciones. El
Organizador Temporal 104 de Fuente mantiene todas las fuentes que se
han de examinar en una cola de prioridad basándose en una pila de
prioridades. La cola está siempre ordenada en el orden en que se han
de examinar las fuentes. La cabecera de la cola es el último
elemento con respecto al ordenamiento especificado, que es
"nextPollTime" ("siguienteTiempoExamen").
\vskip1.000000\baselineskip
El organizador temporal tomará cada fuente de la
cabecera de una cola, a fin de examinarla, ajusta su
"TiempoúltimaRecogida" ("lastPickedTime") como
"Ahora" ("Now") y se presenta a la cola de tratamiento.
Calculará entonces el siguienteTiempoExamen y lo insertará de
vuelta en la cola. La fuente también se marcará como "en
progreso". Una vez que se ha completado el trabajo de examen por
parte del DA, llamará de vuelta al organizador temporal para que
informe de la ultimación del tratamiento utilizando el método de
interfaz de resultadoExamen ("pollResult") (). La llamada de
vuelta se utilizará para despejar o poner a cero el estado "en
progreso" de la fuente. Si una fuente que está aún "en
progreso" llega a tener que examinarse, esto significará que el
Representante de DA está corriendo por detrás y no ha llegado
todavía a las proximidades del último trabajo de examen, y será
empujado de vuelta a la cola con un nuevo siguienteTiempoExamen.
Una fuente será sometida a la cola de
tratamiento de Representante de DA para su examen en el caso de que
tenga un siguienteTiempoExamen <= Ahora. En caso contrario, el
organizador temporal permanecerá libre o inactivo. Dicha situación
indicará que el sistema está corriendo por delante de su organizador
temporal de examen. En lugar de permanecer libre o inactivo, el
organizador temporal puede permitir que continúe el examen, incluso
si este está corriendo por delante. Sin embargo, con el fin de
evitar intentos de examen demasiado frecuentes a los servidores
remotos, puede definirse una propiedad que especifique cuán lejos
por delante puede correr el sistema. Por ejemplo, si esta se ajusta
en 5 minutos, garantizará que hay al menos 10 minutos entre dos
exámenes sucesivos, suponiendo que se ha establecido el intervalo de
examen normal en 15 minutos; es decir, las fuentes con
(siguienteTiempoExamen - tiempoCarreraPordelante
("runAheadTime")) <= Ahora se organizarán temporalmente para
su examen.
El procedimiento de "expedir" un examen en
una fuente significará desplazar la fuente hacia la cabecera de la
cola con el fin de que sea examinada antes de su siguiente examen
programado u organizado temporalmente. Para las cuentas "no
válidas" que cambian su estado a "válidas" debido a acciones
externas, esto significará desplazar el siguienteTiempoExamen a
"ahora", en tanto que para fuentes que han visto correo nuevo
en el examen en curso en ese momento, significará desplazar el
siguienteTiempoExamen a "ahora + x", donde x es, póngase por
caso, 3 minutos.
El representante de DA recibe notificaciones del
Gestor de Asignación de Fuente, el cual especifica una lista de
fuentes que añadir, eliminar o actualizar desde el organizador
temporal de fuente. La notificación puede también especificar que
se trata de una notificación "de refresco", por cuanto que
listará todas las fuentes a las que se ha de dar servicio por parte
del Representante de DA, lo que significa que la lista vigente en
ese momento de fuentes a las que se está dando servicio debe ser
eliminada. La notificación "de refresco" será utilizada por un
SAM de refuerzo cuando asuma las funciones del SAM primario debido a
un fallo. Se utilizará el método de interfaz notificaciónDesdeSAM
("notificationFromSAM") () para actualizar el organizador
temporal en este caso.
Las notificaciones de "NuevoCorreo"
("NewMail") procedentes del ServidorSuceso ("EventServer")
46 para fuentes suscritas harán que la fuente sea expedida en
"ahora" en el organizador temporal. Si se recibe una
notificación de NuevoCorreo para una fuente suscrita que tiene
puesto el indicador o etiqueta "en progreso", ya sea debido a
dos o más notificaciones de NuevoCorreo sucesivas procedentes del
Servidor de Suceso, ya sea debido a que su siguienteTiempoExamen
<= Ahora como consecuencia de su inactividad, entonces la fuente
se marcará como "PendienteExpediciónExamen"
("ExpeditePollPending") y se expedirá cuando se complete el
trabajo de examen en curso en ese momento.
Una vez que se ha completado un trabajo de
examen, cuando el gestor de examen llama de vuelta al organizador
temporal para informar de la ultimación del trabajo, se creará una
nueva suscripción para las fuentes que no estén suscritas en ese
momento pero que satisfacen los criterios de ser "susceptibles de
suscripción", y se añadirá a la cola de tratamiento de DA tan
solo si el sistema puede introducir una identificación de acceso con
éxito para entrar en el buzón de correo.
A continuación siguen detalles del procedimiento
de notificación de situación fuera de servicio.
El Organizador Temporal 104 de Fuente recibe una
petición de contención de retransmisión para cada fuente o
dispositivo que se encuentra fuera de cobertura. El propósito de
manejar peticiones de contención de retransmisión en la MOP es:
1) Ahorrar anchura de banda y no consultar o
examinar fuentes que se encuentran fuera de cobertura.
2) Reanudar el examen de las fuentes cuando un
usuario vuelve a entrar en cobertura.
3) Reducir el número de mensajes que deben ser
guardados en la memoria caché del disco en los Trabajadores 24.
\vskip1.000000\baselineskip
En el motor 22, los mensajes son
almacenados/dispuestos en cola y entregados al Retransmisor 34 sobre
la base de un PIN/SB. Por otra parte, el Retransmisor implementa la
contención según un criterio por mensaje. Así, cada mensaje
entregado al Retransmisor 34 puede ser retenido o "contenido"
si el usuario se encuentra fuera de cobertura. Cada cola de
mensajes del trabajador (es decir, el combo PIN/SB) mantiene el
seguimiento de estos mensajes contenidos en su transmisión y
determina si el usuario se encuentra dentro o fuera de cobertura.
En consecuencia, cada cola enviará una etiqueta o indicador de
"fuera de cobertura" o "dentro de cobertura" a la MOP
40.
El indicador de contención se encuentra en el
nivel de la fuente en lugar de en el nivel de usuario debido a que
no implica la desmultiplexación de los múltiples niveles de fuente
hasta obtener un único nivel de usuario, y hace que la situación de
carrera de la actualización sea más fácil de controlar. La MOP 40
recibe una notificación por cada fuente que tiene al menos un
mensaje pendiente en el trabajador. El trabajador puede permitir que
se envíe al dispositivo al menos un trabajo para cada libro de
servicio (11 libros de servicio como máximo). Puede haber 11
actualizaciones de un representante de DA en este ejemplo no
limitativo cada vez que el dispositivo se encuentra dentro y fuera
de cobertura.
Si el trabajador 24 acepta MTH procedentes del
Representante de DA 42 mientras un dispositivo está fuera de
cobertura, esos mensajes NO se pierden. Cuando el dispositivo vuelve
a estar en cobertura, los mensajes son retomados y enviados al
dispositivo. El Trabajador los conservará hasta que el dispositivo
esté nuevamente en cobertura o hasta que expiren algunos trabajos
previamente enviados, por ejemplo, 7 días después, desde un Agente
de Puerta 26, a fin de dejar espacio para que se envíe o expida el
(los) siguiente(s) trabajo(s) pendiente(s).
En lo que sigue se describe la naturaleza de la
retención o contención de retransmisión en el Motor 22:
1) El trabajador 24 tiene x mensajes (siendo x
> 0) que ha convertido y entregado al Retransmisor.
2) El Retransmisor retiene y mensajes (siendo y
> 0). En teoría, x = y, pero no tiene por qué ser así, dada la
naturaleza poco fiable de este protocolo desde el Lado del
Retransmisor.
3) De los y mensajes, 1 se marca como trabajo de
CONSERVACIÓN. Un trabajo de CONSERVACIÓN se retoma periódicamente
(cada 4 horas) como medida de seguridad. En consecuencia, se colocan
de nuevo y - 1 mensajes en la cola y la cola se marca como "fuera
de cobertura". Los y - 1 mensajes no se vuelven a entregar
mientras estén en este estado, y no se facilita ningún nuevo mensaje
entrante para su entrega. Los mensajes son colocados en la cola del
Trabajador.
4) Dos sucesos pueden indicar un estado
"dentro de cobertura":
- a)
- el Retransmisor notifica que el usuario ha entrado de nuevo en cobertura, o
- b)
- el trabajo de CONSERVACIÓN periódicamente refacilitado llega de vuelta como ENTREGADO. La cola se marca como "en cobertura" y los mensajes de la cola son refacilitados (siguiendo el "número máximo de trabajos asignados por regla PIN/SB", como es habitual).
\vskip1.000000\baselineskip
Un dispositivo que entra y sale de cobertura
(esto podría suceder si un dispositivo se encuentra cerca de una
señal débil) tiene como resultado que el Retransmisor 34 realiza
peticiones de retención o contención de forma relativamente
frecuente al Trabajador. No hay seguridad de que estas peticiones
nunca lleguen a quedar fuera de servicio en el camino hasta el
Trabajador. Por otra parte, debido a la naturaleza asincrónica del
Motor 22, la MOP y los protocolos de Retransmisión se encaminan a
numero ilimitado de secuencias y magnifican la posibilidad de una
situación de carrera entre las notificaciones de fuera de cobertura
y las notificaciones dentro de cobertura. El trabajador necesita,
bien mantener las notificaciones en sincronismo o bien detectar y no
hacer caso de las notificaciones que no están en sincronismo.
Existe también el problema de un suceso de fallo
de un Trabajador, con la posibilidad de que la notificación dentro
de cobertura procedente del Retransmisor 34 se "pierda" y la
MOP 40 no reciba la notificación. Si no existen mensajes en su cola
de trabajos cuando el trabajador vuelve a estar conectado o en
línea, no marcará la cola como dentro de cobertura y, por tanto, no
enviará a la MOP una notificación dentro de cobertura. En este
caso, la fuente permanecerá marcada como fuera de cobertura en la
MOP y, potencialmente, nunca será examinada en busca de correo de
fuente entrante. Esencialmente, el problema es que el Trabajador
solo tiene conocimiento acerca de usuarios que tienen mensajes que
se están siendo procesados o tratados. Si, por alguna razón, todos
los trabajos dentro del Trabajador se han completado pero la MOP
tiene al usuario etiquetado como fuera de cobertura, no hay manera
de que el Trabajador sepa a quién examinar para averiguar el
estatus, debido a que el usuario no existe por lo que respecta al
Trabajador. El Trabajador 24 únicamente solicita información de
usuario cuando llegan al sistema nuevos trabajos, pero en este
"caso de situación de carrera", no entrará ningún correo nuevo
puesto que la MOP ha dejado de examinar y el usuario permanecerá
marcado como fuera de cobertura.
Con el fin de evitar la situación anteriormente
descrita, la MOP lleva a efecto periódicamente un "examen seguro
ante fallos" para todas las fuentes susceptibles de examinarse y
que estén fuera de cobertura, de tal manera que una fuente
susceptible de examinarse no esté suspendida o de otro modo
inhabilitada. El Trabajador 24 corregirá la MOP si se hubiera
producido una situación de carrera o situación de error que no
hubiese sido detectada de otra manera.
Una forma de hacer esto es que el Representante
de DA 42 de MOP examine al Trabajador 24 por lo que respecta al
estatus fuera de cobertura. Este examen es desencadenado por el
intervalo de examen para el buzón de correo de fuente por parte del
Organizador Temporal 104 de Fuente. Si el Trabajador sabe que este
usuario está aún fuera de cobertura, lo notificará como tal en
cualquier caso, esto es, está enviando mensajes a un usuario dentro
de cobertura o no tiene conocimiento del usuario en absoluto, e
informará de un estatus fuera de cobertura. Esta solución tiene las
siguientes ventajas: a) en la mayoría de los casos, el flujo/examen
de correo se reanudará inmediatamente tan pronto como el usuario
vuelva a estar en cobertura, b) si se pierden notificaciones o
quedan fuera de servicio, el sistema tendrá un examen seguro ante
fallos que pueda descubrir/notificar estatus y sincronizarse de
forma relativamente rápida en caso necesario, y c) en el caso de que
un Trabajador sufra un fallo, el Representante de DA examinará el
trabajador 24 al que se reasignará el usuario situado fuera de
cobertura, y el trabajador informará del estado en cobertura, ya que
no sabe nada acerca de este usuario.
El Organizador Temporal 104 de Fuente dispara
periódicamente el Representante de DA 42 para enviar una
notificación de "disparar y olvidar" al Trabajador 24. En
respuesta, si el Trabajador determina que la fuente está bajo
cobertura, actualiza el estatus de notificación de fuera de
cobertura en "falso", con lo que se indica que la fuente está
de nuevo en un estatus dentro de cobertura. En el caso de que la
notificación de "disparo y olvido" se pierda o de que el
Trabajador esté fuera de funcionamiento, entonces el trabajador
enviará una actualización de notificación de dentro de cobertura a
la MOP y el estado de la fuente permanecerá fuera de cobertura.
La Figura 15 es un diagrama secuencial de las
transacciones de comunicación de notificación.
\newpage
Todas las fuentes de una cuenta deben ser
consideradas fuera de cobertura en el caso de que una fuente de la
cuenta reciba una notificación de contención desde el retransmisor.
Parte de esta optimización puede implementarse en la MOP para
marcar todas las fuentes que están fuera de cobertura. Sin embargo,
el mayor beneficio se obtendría, probablemente, si el motor 22 se
optimizase de manera que considerase las retenciones de
retransmisión en el nivel de cuenta y ligase las colas entre sí en
el nivel de cuenta. De otro modo, cualesquiera mensajes que ya están
en la cola continuarán siendo reintentados.
El trabajador no necesita responder con una
"ACK [CONFIRMACIÓN -``ACKNOWLEDGEMENT''] de fuera de cobertura"
cuando el MPO lo examina en busca de fuentes fuera de cobertura.
Tan solo tiene que responder para tener una marca de MOP dentro de
cobertura. Esto ahorrará algo de la información de encabezamiento de
procesar peticiones y respuestas de fuera de cobertura.
Componentes proporcionados a modo de ejemplo de
un dispositivo de comunicaciones inalámbrico móvil y de mano 1000
que puede ser utilizado de acuerdo con semejante sistema, se
describen adicionalmente en el ejemplo proporcionado más adelante,
con referencia a la Figura 1. El dispositivo 1000 incluye, de modo
ilustrativo, un alojamiento 1200, un cuadro o placa de teclas 1400
y un dispositivo de salidas 1600. El dispositivo de salida mostrado
es un dispositivo de presentación visual 1600, que es,
preferiblemente, un LCD [dispositivo de presentación visual de
cristal líquido -"liquid cristal display"] de gráficos
completo. Otros tipos de dispositivos de salida pueden utilizarse
de forma alternativa. Un dispositivo de tratamiento 1800 está
contenido dentro del alojamiento 1200 y está acoplado entre una
placa de teclas 1400 y el dispositivo de presentación visual 1600.
El dispositivo de tratamiento 1800 controla el funcionamiento del
dispositivo de presentación visual 1600, así como el funcionamiento
global del dispositivo móvil 1000, en respuesta al accionamiento de
las teclas de la placa de teclas 1400 por parte del usuario.
El alojamiento 1200 puede ser alargado
verticalmente, o bien puede tener otros tamaños y adoptar otras
formas (incluyendo estructuras de alojamiento de concha de almeja).
La placa de teclas puede incluir una tecla de selección de modo u
otro hardware o software para conmutar entre la entrada de texto y
la entrada de telefonía.
Además del dispositivo de tratamiento 1800, en
la Figura 6 se muestran esquemáticamente otras partes del
dispositivo móvil 1000. Estas incluyen un subsistema de
comunicaciones 1001; un subsistema de comunicaciones de corto
alcance 1020; el teclado 1400 y el dispositivo de presentación
visual 1600, conjuntamente con otros dispositivos de entrada/salida
1060, 1080, 1100 y 1120; así como dispositivos de memoria 1160, 1180
y diversos otros subsistemas 1201 de dispositivo. El dispositivo
móvil 1000 es, preferiblemente, un dispositivo de comunicaciones de
RF de doble sentido que tiene capacidades de comunicaciones de voz y
de datos. Además, el dispositivo móvil 1000 tiene, preferiblemente,
la capacidad de comunicarse con otros sistemas informáticos a través
de la Internet.
El software de sistema operativo ejecutado por
el dispositivo de tratamiento 1800 es, preferiblemente, almacenado
en un dispositivo de almacenamiento permanente, tal como la memoria
1160 de tipo flash o de refrescamiento por impulsos, si bien
puede ser almacenado en otros tipos de dispositivos de memoria,
tales como una memoria de solo lectura (ROM -"read only
memory") o elemento de almacenamiento similar. Además, el
software del sistema, las aplicaciones de dispositivo específicas,
o partes de los mismos, pueden ser almacenados temporalmente en un
dispositivo de almacenamiento volátil, tal como la memoria de acceso
aleatorio (RAM -"random access memory") 1180. Las señales de
comunicaciones recibidas por el dispositivo móvil pueden ser también
almacenadas en la RAM 1180.
El dispositivo de tratamiento 1800, además de
sus funciones de sistema operativo, permite la ejecución de
aplicaciones de software 1300A-1300N en el
dispositivo 1000. Un conjunto predeterminado de aplicaciones que
controlan operaciones básicas del dispositivo, tales como
comunicaciones de datos y de voz 1300A y 1300B, puede ser instalado
en el dispositivo 1000 durante su fabricación. Además, una
aplicación de gestor de información personal (PIM -"personal
information manager") puede ser instalada durante la fabricación.
El PIM es, preferiblemente, capaz de organizar y gestionar
elementos de datos, tales como correo electrónico, sucesos de
calendario, correos o mensajes de voz, citas y elementos de tarea.
La aplicación de PIM es también, preferiblemente, capaz de enviar y
recibir elementos de datos a través de una red inalámbrica 1401.
Preferiblemente, los elementos de datos de PIM son integrados sin
discontinuidades, sincronizados y actualizados a través de la red
inalámbrica 1401, estando los elementos de datos
correspon-
dientes del usuario del dispositivo almacenados en, o asociados con, un sistema informático principal o anfitrión.
dientes del usuario del dispositivo almacenados en, o asociados con, un sistema informático principal o anfitrión.
Las funciones de comunicación, incluyendo
comunicaciones de datos y de voz, se llevan a cabo por medio del
subsistema de comunicaciones 1001 y, posiblemente, a través del
subsistema de comunicaciones de corto alcance. El subsistema de
comunicaciones 1001 incluye un receptor 1500, un transmisor 1520 y
una o más antenas 1540 y 1560. Además, el subsistema de
comunicaciones 1001 también incluye un módulo de tratamiento, tal
como un procesador de señal digital (DSP -"digital signal
processor") 1580, y osciladores locales (LO -"local
oscillators") 1601. El diseño y la implementación específicos
del subsistema de comunicaciones 1001 dependen de la red de
comunicaciones en la que está destinado a operar el dispositivo
móvil 1000. Por ejemplo, un dispositivo móvil 1000 puede incluir un
subsistema de comunicaciones 1001 diseñado para funcionar con las
redes de comunicaciones de datos móviles Mobitex^{TM}, Data
TAC^{TM} o del Servicio General de Radio en Paquetes (GPRS
-"General Packet Radio Service"), y está también diseñado para
funcionar con cualquiera de una variedad de redes de comunicaciones
de voz, tales como AMPS, TDMA, CDMA, WCDMA, PCS, GSM, EDGE, etc.
Otros tipos de redes de datos y de voz, tanto independientes como
integradas, pueden también utilizarse con el dispositivo móvil 1000.
El dispositivo móvil 1000 puede también adaptarse a otras normas de
comunicación tales como sGSM, 3GPP, UMTS, etc.
Los requisitos de acceso de red varían
dependiendo del tipo de sistema de comunicación. Por ejemplo, en las
redes Mobitex y DataTAC, los dispositivos móviles son registrados
en la red utilizando un número de identificación personal único o
exclusivo o PIN asociado con cada dispositivo. En las redes de GPRS,
sin embargo, el acceso a la red está asociado con un abonado o
usuario de un dispositivo. Un dispositivo de GPRS requiere, por
tanto, un módulo de identidad de abonado, comúnmente referido como
tarjeta de SIM ("subscriber identity module"), para operar en
una red de GPRS.
Cuando se han completado los procedimientos de
registro o activación de red requeridos, el dispositivo móvil 1000
puede enviar y recibir señales de comunicación a través de la red de
comunicación 1401. Las señales recibidas desde la red de
comunicaciones 1401 por la antena 1540 son encaminadas al receptor
1500, el cual hace posible la amplificación de la señal, la
conversión de frecuencia en sentido descendente, la filtración, la
selección de canal, etc., y puede también proporcionar conversión
de digital a analógica. La conversión de digital a analógica de la
señal recibida hace posible que el DSP 1580 lleve a cabo funciones
de comunicaciones más complejas, tales como la desmodulación y la
descodificación. De un modo similar, las señales que se han de
transmitir a la red 1401 son tratadas (por ejemplo, moduladas y
codificadas) por el DSP 1580 y se proporcionan entonces al
transmisor 1520 para su conversión de digital a analógica, su
conversión de frecuencia en sentido ascendente, su filtración,
amplificación y transmisión a la red (o redes) de comunicación 1401
a través de la antena 1560.
Además de tratar las señales de comunicaciones,
el DSP 1580 hace posible el control del receptor 1500 y del
transmisor 1520. Por ejemplo, las ganancias aplicadas a las señales
de comunicaciones en el receptor 1500 y en el transmisor 1520 pueden
ser controladas de forma adaptativa por medio de algoritmos de
control de ganancia automáticos implementados en el DSP 1580.
En el modo de comunicaciones de datos, una señal
recibida, tal como un mensaje de texto o descarga de página web, es
tratada por el subsistema de comunicaciones 1001 y se introduce en
el dispositivo de tratamiento 1800. La señal recibida es entonces
tratada adicionalmente por el dispositivo de tratamiento 1800 para
su suministro como salida al dispositivo de presentación visual
1600, ó, alternativamente, a algún otro dispositivo de E/S
[Entrada/Salida -"Input/Output"] auxiliar 1060. Un usuario de
dispositivo puede también componer elementos de datos, tales como
mensajes de correo electrónico, utilizando la placa de teclas 1400
y/o algún otro dispositivo de E/S auxiliar 1060, tal como una
almohadilla táctil, un conmutador basculante, una ruedecilla o algún
otro tipo de dispositivo de entrada. Los elementos de datos
compuestos pueden ser entonces transmitidos a través de la red de
comunicaciones 1401 por medio del subsistema de comunicaciones
1001.
En un modo de comunicaciones de voz, el
funcionamiento global del dispositivo es sustancialmente similar al
modo de comunicaciones de datos, a excepción de que las señales
recibidas son suministradas como salida a un altavoz 1100, y las
señales para transmisión son generadas por un micrófono 1120. Pueden
también implementarse en el dispositivo 1000 subsistemas de E/S de
voz o de audio alternativos, tales como un subsistema de grabación
de mensajes de voz. Además, el dispositivo de presentación visual
1600 puede ser también utilizado en el modo de comunicaciones de
voz, por ejemplo, para presentar visualmente la identidad de una
parte llamante, la duración de una llamada de voz u otra información
relacionada con la llamada de voz.
El subsistema de comunicaciones de corto alcance
permite la comunicación entre el dispositivo móvil 1000 y otros
sistemas o dispositivos próximos, que no han de ser necesariamente
dispositivos similares. Por ejemplo, el subsistema de
comunicaciones de corto alcance pude incluir un dispositivo de
infrarrojos y circuitos y componentes asociados, o bien un módulo
de comunicaciones Bluetooth^{TM} para hacer posible la
comunicación con sistemas y dispositivos similarmente
capacitados.
Muchas modificaciones y realizaciones diferentes
de la invención vendrán a la mente de un experto de la técnica que
disfruta del beneficio de las enseñanzas presentadas en las
anteriores descripciones y en los dibujos asociados. En
consecuencia, se comprende que la invención no ha de estar limitada
por las realizaciones específicas divulgadas, y es la intención que
esas modificaciones y realizaciones estén incluidas dentro del
ámbito de las realizaciones que se acompañan.
Claims (16)
-
\global\parskip0.930000\baselineskip
1. Un sistema de comunicaciones (20) que comprende:- un motor (22) de red, capaz de funcionar para comunicarse con una pluralidad de dispositivos de comunicaciones inalámbricos y móviles (38) suscritos por un usuario, y capaz de funcionar para determinar cuándo un dispositivo de comunicaciones inalámbrico y móvil (38) está fuera de cobertura o se ha desconectado o apagado y es incapaz de comunicarse con el motor (22) de red; y
- un servidor de acceso directo (42), capaz de funcionar con el motor (22) de red para consultar o examinar buzones de correo electrónico (48) de usuarios y recuperar mensajes electrónicos de los buzones de correo electrónicos, e impulsar o hacer pasar cualesquiera mensajes electrónicos a través del motor (22) de red a dispositivos de comunicaciones inalámbricos y móviles (38) suscritos por usuario y seleccionados, caracterizado por que dicho servidor de acceso directo (42) es capaz de funcionar para suspender el examen de los buzones de correo electrónico de usuario cuando se ha determinado que un dispositivo de comunicaciones inalámbrico y móvil (38) asociado con el usuario está fuera de cobertura o se ha desconectado y es incapaz de comunicarse, a fin de conservar los recursos de examen dentro del servidor de acceso directo (42).
\vskip1.000000\baselineskip
- 2. El sistema de comunicaciones (20) de acuerdo con la reivindicación 1, en el cual dicho motor (22) de red comprende, de manera adicional, un módulo de trabajador (24) capaz de funcionar para aceptar correo electrónico procedente del servidor de acceso directo (42) y de cualesquiera dispositivos de encaminamiento de correo, y formatear el correo electrónico para su comunicación a través de una red de comunicaciones (36), y un módulo de retransmisor (34), capaz de funcionar para recibir mensajes del módulo de trabajador (24) y hacer pasar los mensajes a dispositivos de comunicaciones inalámbricos y móviles (38) a través de la red de comunicaciones (36).
- 3. El sistema de comunicaciones (20) de acuerdo con la reivindicación 2, en el cual dicho módulo de retransmisor (34) es capaz de funcionar para retener o hacer pasar de vuelta mensajes al módulo de trabajador (24) cuando un dispositivo de comunicaciones inalámbrico y móvil (38) está fuera de cobertura o desconectado y los mensajes no pueden hacerse llegar a dicho dispositivo.
- 4. El sistema de comunicaciones (20) de acuerdo con la reivindicación 3, en el cual dicho módulo de retransmisor (34) es capaz de funcionar para hacer pasar de vuelta mensajes a un módulo de trabajador (24) según un criterio por mensaje, de tal manera que cada mensaje que el trabajador entrega al módulo de retransmisor (34) puede hacerse pasar de vuelta al módulo de trabajador (24).
- 5. El sistema de comunicaciones (20) de acuerdo con la reivindicación 3, en el cual dicho módulo de trabajador (24) es capaz de funcionar para mantener un registro del número de mensajes que se han hecho pasar de vuelta desde el módulo de retransmisor (34), y para determinar, a partir del número de mensajes que se han hecho pasar de vuelta, si el dispositivo de comunicaciones inalámbrico y móvil (38) para el que se han hecho pasar de vuelta los mensajes pretendidos, está fuera de cobertura.
- 6. El sistema de comunicaciones (20) de acuerdo con la reivindicación 1, en el cual dicho motor (22) de red es capaz de funcionar para enviar una etiqueta o indicador de fuera de cobertura o de dentro de cobertura al servidor de acceso directo (42), indicando que el dispositivo de comunicaciones inalámbrico y móvil (38) al que están destinados los correos electrónicos está fuera de cobertura o desconectado.
- 7. El sistema de comunicaciones (20) de acuerdo con la reivindicación 1, en el cual dicho servidor de acceso directo (42) es capaz de funcionar para reanudar el examen de los buzones de correo electrónico (48) para los que ha sido suspendido el examen cuando el dispositivo de comunicaciones inalámbrico y móvil (38) asociado del usuario está dentro de cobertura o conectado y es capaz de reanudar las comunicaciones.
- 8. El sistema de comunicaciones (20) de acuerdo con la reivindicación 1, en el cual dicho servidor de acceso directo (42) es capaz de funcionar para examinar de forma segunda frente a fallo dicho motor (22) de red con respecto al estatus de dispositivos de comunicaciones inalámbricos y móviles (38) que se consideran fuera de cobertura o apagados y dentro de cobertura.
- 9. El sistema de comunicaciones (20) de acuerdo con la reivindicación 8, en el cual dicho servidor de acceso directo (42) comprende un módulo (104) organizador temporal de fuente, capaz de funcionar para organizar temporalmente un intervalo de examen de buzones de correo electrónico (48), de tal manera que dicho examen seguro frente a fallos es disparado o desencadenado por dicho intervalo de examen.
- 10. El sistema de comunicaciones (20) de acuerdo con la reivindicación 9, en el cual dicho motor de red (22) comprende, adicionalmente, un módulo de trabajador (24), capaz de funcionar para aceptar correo electrónico procedente del servidor de acceso directo (42) y de cualesquiera dispositivos de encaminamiento de correo electrónico, y formatear correo electrónico para su comunicación a través de una red de comunicaciones, de tal manera que dicho módulo (104) organizador temporal de fuente se comunica con dicho módulo de trabajador (24) para enviar notificaciones a dicho módulo de trabajador en forma de examen seguro frente a fallos.
\global\parskip1.000000\baselineskip
- 11. Un método de comunicaciones que comprende:
- determinar cuándo un dispositivo de comunicaciones inalámbrico y móvil (38) suscrito por un usuario está fuera de cobertura o desconectado y es incapaz de comunicarse con un motor (22) de red como módulo que impulsa o hace pasar correos electrónicos recibidos desde un servidor de acceso directo (42) a un dispositivo de comunicaciones inalámbrico y móvil (38);
- consultar o examinar buzones de correo electrónico (48) del usuario desde el servidor de acceso directo (42);
- recuperar mensajes electrónicos desde los buzones de correo electrónico (48);
- hacer pasar cualesquiera mensajes electrónicos a través del motor (22) de red, hasta un dispositivo de comunicaciones inalámbrico y móvil (38) suscrito por un usuario;
- determinar cuándo el dispositivo de comunicaciones inalámbrico y móvil (38) está fuera de cobertura o desconectado y es incapaz de comunicarse, caracterizado por:
- suspender el examen de los buzones de correo electrónico (48) pertenecientes al usuario si se determina que el dispositivo de comunicaciones inalámbrico y móvil (38) está fuera de cobertura o desconectado y es incapaz de comunicarse.
\vskip1.000000\baselineskip
- 12. El método de acuerdo con la reivindicación 11, que comprende adicionalmente formatear correo electrónico para su comunicación dentro de un módulo de trabajador (24) que acepta correo electrónico procedente del servidor de acceso directo (42), y recibir mensajes de correo electrónico dentro de un módulo de retransmisor (34) desde el módulo de trabajador (24), y hacer pasar los mensajes desde el módulo de retransmisor (34) al dispositivo de comunicaciones inalámbrico y móvil (38) a través de una red de comunicaciones (36).
- 13. El método de acuerdo con la reivindicación 12, que comprende adicionalmente retener o hacer pasar de vuelta mensajes al módulo de trabajador (24) desde el módulo de retransmisor (34) cuando un dispositivo de comunicaciones inalámbrico y móvil (38) se encuentra fuera de cobertura o desconectado y los mensajes no pueden hacerse pasar a dicho dispositivo.
- 14. El método de acuerdo con la reivindicación 13, que comprende adicionalmente hacer pasar de vuelta mensajes según un criterio por mensaje.
- 15. El método de acuerdo con la reivindicación 13, que comprende adicionalmente mantener un registro del número de mensajes que se han hecho pasar de vuelta desde el módulo de retransmisor (34), y determinar, a partir del número de mensajes que se han hecho pasar de vuelta, si el dispositivo de comunicaciones inalámbrico y móvil (38) en el que se han hecho pasar de vuelta los mensajes deseados se encuentra fuera de cobertura o desconectado.
- 16. El método de acuerdo con la reivindicación 11, que comprende adicionalmente enviar una etiqueta o indicador de fuera de cobertura o de dentro de cobertura al servidor de acceso directo (42), indicando que el dispositivo de comunicaciones inalámbrico y móvil (38) al que están destinados los correos electrónicos está fuera de cobertura o desconectado.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US91161107P | 2007-04-13 | 2007-04-13 | |
| US911611P | 2007-04-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2353225T3 true ES2353225T3 (es) | 2011-02-28 |
Family
ID=39535349
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08150922T Active ES2353225T3 (es) | 2007-04-13 | 2008-01-31 | Sistema de distribuciã“n y sincronizaciã“n de correo electrã“nico (e-mail) de acceso directo con notificaciã“n de fuera de cobertura. |
Country Status (7)
| Country | Link |
|---|---|
| US (4) | US8626841B2 (es) |
| EP (4) | EP1981231B1 (es) |
| AT (4) | ATE445955T1 (es) |
| CA (3) | CA2628765C (es) |
| DE (3) | DE602008002621D1 (es) |
| ES (1) | ES2353225T3 (es) |
| HK (3) | HK1123412A1 (es) |
Families Citing this family (66)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070266098A1 (en) * | 2005-05-05 | 2007-11-15 | Raz Gordon | System and method for emailing an entity using its non-email attributes |
| US7805489B2 (en) * | 2006-06-27 | 2010-09-28 | Research In Motion Limited | Electronic mail communications system with client email internet service provider (ISP) polling application and related methods |
| ATE445955T1 (de) | 2007-04-13 | 2009-10-15 | Teamon Systems Inc | Direktzugangs-e-mail-verteilungs- und synchronisationssystem mit imap-idle- implementierung |
| US7900149B2 (en) * | 2007-06-08 | 2011-03-01 | Apple Inc. | Methods and systems for editing of web pages in an application capable of displaying web page content |
| US8914009B2 (en) | 2007-07-27 | 2014-12-16 | Blackberry Limited | Administration of wireless systems |
| US9270682B2 (en) | 2007-07-27 | 2016-02-23 | Blackberry Limited | Administration of policies for wireless devices in a wireless communication system |
| EP2031910A3 (en) * | 2007-07-27 | 2009-04-29 | Research In Motion Limited | Administration of wireless devices in a wireless communication system |
| US8086677B2 (en) * | 2007-07-27 | 2011-12-27 | Research In Motion Limited | Information exchange in wireless servers |
| EP2424194B1 (en) * | 2007-07-27 | 2017-04-19 | BlackBerry Limited | Method and system for resource sharing |
| ES2346165T3 (es) | 2007-07-27 | 2010-10-11 | Research In Motion Limited | Aparato y metodos para el funcionamiento de un servidor inalambrico. |
| EP2112842B1 (en) | 2007-07-27 | 2013-08-21 | Research In Motion Limited | Wireless communication systems |
| EP2034776B1 (en) | 2007-07-27 | 2013-02-13 | Research In Motion Limited | Wireless communication system installation |
| DE602008004389D1 (de) | 2007-07-27 | 2011-02-24 | Research In Motion Ltd | Vorrichtung und Verfahren zur Koordination von drahtlosen Systemen |
| EP2031909B1 (en) * | 2007-07-27 | 2011-02-16 | Research In Motion Limited | Remote control in a wireless communication system |
| US8346874B2 (en) * | 2008-01-22 | 2013-01-01 | Microsoft Corporation | Mail object migration |
| US7984100B1 (en) * | 2008-04-16 | 2011-07-19 | United Services Automobile Association (Usaa) | Email system automatically notifying sender status and routing information during delivery |
| US8516095B2 (en) | 2008-05-23 | 2013-08-20 | Research In Motion Limited | Remote administration of mobile wireless devices |
| US8135392B2 (en) | 2008-06-06 | 2012-03-13 | Apple Inc. | Managing notification service connections and displaying icon badges |
| US9516116B2 (en) * | 2008-06-06 | 2016-12-06 | Apple Inc. | Managing notification service connections |
| US8504001B2 (en) | 2008-08-12 | 2013-08-06 | Apple Inc. | Unified settings for multiple account types |
| US9305288B2 (en) * | 2008-12-30 | 2016-04-05 | Ford Global Technologies, Llc | System and method for provisioning electronic mail in a vehicle |
| US20100190439A1 (en) * | 2009-01-29 | 2010-07-29 | Ford Global Technologies, Llc | Message transmission protocol for service delivery network |
| CA2693724C (en) | 2009-02-20 | 2014-05-06 | Research In Motion Limited | Caching email unique identifiers |
| US9407686B2 (en) * | 2009-02-27 | 2016-08-02 | Blackberry Limited | Device to-device transfer |
| US8065361B2 (en) | 2009-02-27 | 2011-11-22 | Research In Motion Limited | Apparatus and methods using a data hub server with servers to source and access informational content |
| US8880619B2 (en) * | 2009-03-24 | 2014-11-04 | Blackberry Limited | Direct access electronic mail (email) distribution and synchronization system with trusted or verified IMAP-Idle implementation |
| KR101649623B1 (ko) * | 2009-06-11 | 2016-08-19 | 엘지전자 주식회사 | 이동단말기 및 그의 이메일 관리방법 |
| US8620365B2 (en) * | 2009-07-20 | 2013-12-31 | Halter's Chop Chop | Method for handling an electronic request with the aid of an intermediary entity |
| EP2296327A1 (en) * | 2009-09-10 | 2011-03-16 | Research in Motion Limited | Automatic integration of a mail server with internet server (IS) |
| EP2362593B1 (en) * | 2010-02-05 | 2012-06-20 | Research In Motion Limited | Communications system including aggregation server for determining updated metadata of e-mail messages and related methods |
| US20110225228A1 (en) * | 2010-03-11 | 2011-09-15 | Ford Global Technologies, Llc | Method and systems for queuing messages for vehicle-related services |
| US8767707B2 (en) * | 2010-04-23 | 2014-07-01 | Blackberry Limited | Monitoring a mobile data service associated with a mailbox |
| US9043390B2 (en) * | 2010-05-14 | 2015-05-26 | Blackberry Limited | Communication system with PIM entry synchronization and related methods |
| US8718632B2 (en) | 2010-08-26 | 2014-05-06 | Ford Global Technologies, Llc | Service delivery network |
| CA2810852C (en) * | 2010-09-10 | 2016-06-21 | David Jaray Hanson | System and method for providing a plurality of prioritised email domain names |
| US20120221951A1 (en) * | 2010-09-28 | 2012-08-30 | Adam Kidron | Discovery platform apparatuses, methods and systems |
| US8516062B2 (en) | 2010-10-01 | 2013-08-20 | @Pay Ip Holdings Llc | Storage, communication, and display of task-related data |
| US8918467B2 (en) * | 2010-10-01 | 2014-12-23 | Clover Leaf Environmental Solutions, Inc. | Generation and retrieval of report information |
| KR20120079645A (ko) * | 2011-01-05 | 2012-07-13 | 삼성전자주식회사 | 인스턴트 메신저에서 메시지 폴링 방법 및 장치 |
| US9372733B2 (en) * | 2011-08-30 | 2016-06-21 | Open Text S.A. | System and method for a distribution manager |
| US10860563B2 (en) | 2012-01-06 | 2020-12-08 | Microsoft Technology Licensing, Llc | Distributed database with modular blocks and associated log files |
| US9753999B2 (en) * | 2012-01-06 | 2017-09-05 | Citus Data Bilgi Islemieri Ticaret A.S. | Distributed database with mappings between append-only files and repartitioned files |
| US9048428B2 (en) | 2012-03-07 | 2015-06-02 | Microsoft Technology Licensing, Llc | Enabling communication between source and target mail transfer agents |
| AU2013243223A1 (en) * | 2012-04-04 | 2014-09-25 | Not Now Pty Ltd | An electronic message management system |
| US9654426B2 (en) | 2012-11-20 | 2017-05-16 | Dropbox, Inc. | System and method for organizing messages |
| US9729695B2 (en) | 2012-11-20 | 2017-08-08 | Dropbox Inc. | Messaging client application interface |
| US9935907B2 (en) | 2012-11-20 | 2018-04-03 | Dropbox, Inc. | System and method for serving a message client |
| US9189503B2 (en) | 2012-12-06 | 2015-11-17 | Microsoft Technology Licensing, Llc | Database scale-out |
| US9137094B1 (en) | 2012-12-12 | 2015-09-15 | Google Inc. | Method for setting DNS records |
| US9491268B2 (en) * | 2013-03-01 | 2016-11-08 | Infinite Convergence Solutions, Inc. | Method and devices for session timeout management |
| US20140289428A1 (en) * | 2013-03-20 | 2014-09-25 | Microsoft Corporation | Dynamic Intervals for Synchronizing Data |
| US9391940B2 (en) * | 2013-06-25 | 2016-07-12 | Cellco Partnership | Typing indicator for IMAP messaging |
| US9680782B2 (en) | 2013-07-29 | 2017-06-13 | Dropbox, Inc. | Identifying relevant content in email |
| US9961125B2 (en) | 2013-07-31 | 2018-05-01 | Microsoft Technology Licensing, Llc | Messaging API over HTTP protocol to establish context for data exchange |
| US10440066B2 (en) | 2013-11-15 | 2019-10-08 | Microsoft Technology Licensing, Llc | Switching of connection protocol |
| US9787769B2 (en) | 2014-08-04 | 2017-10-10 | Oracle International Corporation | Power and network traffic optimization in communication synchronization |
| US10230670B1 (en) | 2014-11-10 | 2019-03-12 | Google Llc | Watermark-based message queue |
| US10530724B2 (en) * | 2015-03-09 | 2020-01-07 | Microsoft Technology Licensing, Llc | Large data management in communication applications through multiple mailboxes |
| US11157970B1 (en) * | 2015-05-01 | 2021-10-26 | Groupon, Inc. | Apparatus, method, and computer program product for providing synchronous delivery of active media and electronic marketing communications |
| US10587708B2 (en) | 2016-03-28 | 2020-03-10 | Microsoft Technology Licensing, Llc | Multi-modal conversational intercom |
| US10171410B2 (en) * | 2016-03-28 | 2019-01-01 | Microsoft Technology Licensing, Llc | Cross-mode communiation |
| US11487512B2 (en) | 2016-03-29 | 2022-11-01 | Microsoft Technology Licensing, Llc | Generating a services application |
| US9531785B1 (en) * | 2016-06-16 | 2016-12-27 | Ox Software Gmbh | Ad hoc injection of IMAP objects |
| US11212338B1 (en) * | 2018-01-23 | 2021-12-28 | Amazon Technologies, Inc. | Managed scaling of a processing service |
| CN108768775B (zh) * | 2018-05-30 | 2022-01-14 | 努比亚技术有限公司 | 信息处理方法、电子设备及计算机存储介质 |
| US11968093B1 (en) * | 2022-09-20 | 2024-04-23 | Gen Digital Inc. | Efficient scaling of a domain name system service architecture |
Family Cites Families (59)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US2305808A (en) | 1938-09-16 | 1942-12-22 | Marzetti Manlio | Device for needle change in talking machines |
| US2307908A (en) | 1939-05-29 | 1943-01-12 | Clara E Campbell | Combined chair, chaise longue, and bed |
| US2306708A (en) | 1940-12-17 | 1942-12-29 | Mendel Alfred | Bullet shield for firearms |
| US5987498A (en) | 1996-02-16 | 1999-11-16 | Atcom, Inc. | Credit card operated computer on-line service communication system |
| US7383549B1 (en) * | 1997-01-08 | 2008-06-03 | Broadcom Corporation | Processor sharing technique for communications and other data processing on a same processor |
| US6208717B1 (en) * | 1997-03-03 | 2001-03-27 | Unisys Corporation | Method for migrating or altering a messaging system |
| US6219694B1 (en) | 1998-05-29 | 2001-04-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device having a shared electronic address |
| US6779019B1 (en) | 1998-05-29 | 2004-08-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device |
| WO1999065256A2 (en) * | 1998-06-10 | 1999-12-16 | Logica, Inc. | System and method for delivering e-mail notification to mobile phones |
| EP1093696A1 (en) * | 1998-07-06 | 2001-04-25 | Nokia Corporation | Voice mail server, mobile station and method for voice mail message transmission |
| US7966372B1 (en) * | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
| US7222228B1 (en) * | 2000-06-14 | 2007-05-22 | Netwolves Corporation | System and method for secure management or remote systems |
| US7546351B1 (en) * | 2000-08-17 | 2009-06-09 | Mxgo | Methods and systems for filtering, sorting, and dispatching messages to wired and wireless devices |
| US7584251B2 (en) * | 2000-08-28 | 2009-09-01 | Brown Scott T | E-mail messaging system and method for enhanced rich media delivery |
| ES2334329T3 (es) * | 2000-09-19 | 2010-03-09 | Research In Motion Limited | Sistema y metodo para empujar informacion desde un sistema anfrition a un dispositivo movil de comunicacion de datos en una red de datos inalambrica. |
| US20020091774A1 (en) * | 2001-01-08 | 2002-07-11 | Kokoro Imamura | Method and system for retrieving electronic mail for a plurality of users over a single device |
| US7020687B2 (en) * | 2001-05-18 | 2006-03-28 | Nortel Networks Limited | Providing access to a plurality of e-mail and voice message accounts from a single web-based interface |
| AUPS281802A0 (en) * | 2002-06-06 | 2002-06-27 | Arc-E-Mail Ltd | A storage process and system |
| AU2002322897B2 (en) | 2002-08-14 | 2007-04-26 | Huawei Technologies Co., Ltd. | Method and apparatus for pushing e-mail to wireless communication devices |
| JP2004086495A (ja) * | 2002-08-26 | 2004-03-18 | Toyota Motor Corp | 電子メールの送受信方法および電子メール送受信装置 |
| ES2292676T3 (es) * | 2002-11-25 | 2008-03-16 | T-Mobile Deutschland Gmbh | Metodo y sistema para facilitar el acceso a una cuenta de correo electronico a traves de una red de comunicacon movil. |
| US20040225525A1 (en) * | 2003-05-05 | 2004-11-11 | Weitzman Vernon L. | Automatic contacts replication system and software |
| ATE366022T1 (de) | 2003-05-30 | 2007-07-15 | Research In Motion Ltd | System und verfahren zur dienstbereitsstellung für ein kommunikationsgerät |
| EP1652395A2 (en) * | 2003-07-31 | 2006-05-03 | Koninklijke KPN N.V. | A method and system to enable email services for mobile devices |
| US8200775B2 (en) * | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Enhanced syndication |
| US7289495B2 (en) | 2003-08-07 | 2007-10-30 | Teamon Systems, Inc. | Communications system providing adaptive polling based upon user usage patterns and related methods |
| US7111047B2 (en) * | 2003-08-08 | 2006-09-19 | Teamon Systems, Inc. | Communications system providing message aggregation features and related methods |
| US6959325B2 (en) * | 2003-08-11 | 2005-10-25 | Teamon Systems, Inc. | System and method for generating configurations used for accessing electronic mailboxes |
| US7373386B2 (en) * | 2003-08-11 | 2008-05-13 | Research In Motion Limited | System and method for configuring access to electronic mailboxes |
| US7603419B2 (en) | 2003-08-11 | 2009-10-13 | Teamon Systems, Inc. | System and method for automatically learning mailbox configuration conventions |
| US7107310B2 (en) * | 2003-08-11 | 2006-09-12 | Teamon Systems, Inc. | Communications system providing enhanced client-server communications and related methods |
| US7289975B2 (en) * | 2003-08-11 | 2007-10-30 | Teamon Systems, Inc. | Communications system with data storage device interface protocol connectors and related methods |
| US7624147B2 (en) | 2003-09-04 | 2009-11-24 | Sierra Wireless, Inc. | Efficient notification of new electronic mail arrival |
| US20050097180A1 (en) * | 2003-10-31 | 2005-05-05 | Aaron Abdelhak | System and method for improved customized portal web pages |
| US20050108075A1 (en) * | 2003-11-18 | 2005-05-19 | International Business Machines Corporation | Method, apparatus, and program for adaptive control of application power consumption in a mobile computer |
| US7184753B2 (en) * | 2004-01-22 | 2007-02-27 | Research In Motion Limited | Mailbox pooling pre-empting criteria |
| US7206816B2 (en) * | 2004-01-29 | 2007-04-17 | Teamon Systems, Inc. | System and method of polling electronic mailboxes |
| US7162223B2 (en) * | 2004-02-17 | 2007-01-09 | Teamon Systems, Inc. | System and method for notifying users of an event using alerts |
| US7043240B2 (en) * | 2004-02-24 | 2006-05-09 | Teamon Systems, Inc. | Communications system with interface for enabling communication of alerts to mobile wireless communications devices |
| US8601049B2 (en) * | 2004-03-04 | 2013-12-03 | The United States Postal Service | System and method for providing centralized management and distribution of information to remote users |
| WO2005100222A1 (ja) * | 2004-04-07 | 2005-10-27 | Mitsubishi Denki Kabushiki Kaisha | エレベータ呼び登録システム |
| US7519708B2 (en) * | 2004-04-08 | 2009-04-14 | At&T Intellectual Property I, L.P. | Guest account life cycle |
| EP1733520B1 (en) * | 2004-04-09 | 2014-01-15 | Telecom Italia S.p.A. | Method and communications network for managing electronic mail services |
| US7849142B2 (en) * | 2004-05-29 | 2010-12-07 | Ironport Systems, Inc. | Managing connections, messages, and directory harvest attacks at a server |
| US20060085429A1 (en) * | 2004-10-15 | 2006-04-20 | Nokia Corporation | Acknowledged delivery of full email state change to mobile email clients after involuntary disconnects |
| CA2493907A1 (en) * | 2005-01-24 | 2006-07-24 | Oz Communications | Wireless e-mail system |
| US7647380B2 (en) * | 2005-01-31 | 2010-01-12 | Microsoft Corporation | Datacenter mail routing |
| CA2621523C (en) * | 2005-09-27 | 2010-07-13 | Nathan Provo | System for transforming application data using xslt extensions to render templates from cache and related methods |
| US8296369B2 (en) * | 2005-09-27 | 2012-10-23 | Research In Motion Limited | Email server with proxy caching of unique identifiers |
| US8307036B2 (en) * | 2005-09-27 | 2012-11-06 | Research In Motion Limited | Email server with enhanced least recently used (LRU) cache |
| US8494491B2 (en) | 2005-09-28 | 2013-07-23 | Research In Motion Limited | System and method for provisioning a mobile wireless communications device to display account or device-specific characteristics |
| US8756317B2 (en) * | 2005-09-28 | 2014-06-17 | Blackberry Limited | System and method for authenticating a user for accessing an email account using authentication token |
| US8117267B2 (en) | 2005-09-29 | 2012-02-14 | Teamon Systems, Inc. | System and method for provisioning an email account using mail exchange and address records |
| US20070078934A1 (en) | 2005-09-30 | 2007-04-05 | Teamon Systems, Inc. | System and method for provisioning an email account hosted on an assured email service provider |
| US8291020B2 (en) | 2006-03-27 | 2012-10-16 | Research In Motion Limited | Wireless email communications system providing subscriber account update features and related methods |
| US7805489B2 (en) * | 2006-06-27 | 2010-09-28 | Research In Motion Limited | Electronic mail communications system with client email internet service provider (ISP) polling application and related methods |
| US8031594B2 (en) * | 2006-09-29 | 2011-10-04 | At&T Intellectual Property I, L.P. | System and method of providing communications services |
| US8155678B2 (en) * | 2006-10-05 | 2012-04-10 | Research In Motion Limited | Email system providing account provisioning based upon device-supported markup language and related methods |
| ATE445955T1 (de) | 2007-04-13 | 2009-10-15 | Teamon Systems Inc | Direktzugangs-e-mail-verteilungs- und synchronisationssystem mit imap-idle- implementierung |
-
2008
- 2008-01-31 AT AT08150924T patent/ATE445955T1/de not_active IP Right Cessation
- 2008-01-31 EP EP20080150922 patent/EP1981231B1/en active Active
- 2008-01-31 DE DE200860002621 patent/DE602008002621D1/de active Active
- 2008-01-31 US US12/023,067 patent/US8626841B2/en active Active
- 2008-01-31 US US12/023,079 patent/US8407298B2/en active Active
- 2008-01-31 US US12/023,058 patent/US8572185B2/en active Active
- 2008-01-31 EP EP20080150921 patent/EP1981230B1/en active Active
- 2008-01-31 DE DE200860000204 patent/DE602008000204D1/de active Active
- 2008-01-31 AT AT08150921T patent/ATE523006T1/de not_active IP Right Cessation
- 2008-01-31 AT AT08150922T patent/ATE482554T1/de not_active IP Right Cessation
- 2008-01-31 EP EP20080150924 patent/EP1981232B1/en active Active
- 2008-01-31 ES ES08150922T patent/ES2353225T3/es active Active
- 2008-04-10 CA CA 2628765 patent/CA2628765C/en active Active
- 2008-04-11 CA CA 2625444 patent/CA2625444C/en active Active
- 2008-04-11 AT AT08154385T patent/ATE481805T1/de not_active IP Right Cessation
- 2008-04-11 US US12/101,173 patent/US9118506B2/en active Active
- 2008-04-11 CA CA 2625680 patent/CA2625680C/en active Active
- 2008-04-11 EP EP20080154385 patent/EP1981234B1/en active Active
- 2008-04-11 DE DE200860002465 patent/DE602008002465D1/de active Active
-
2009
- 2009-02-05 HK HK09101040A patent/HK1123412A1/xx unknown
- 2009-03-23 HK HK09102787A patent/HK1122160A1/xx unknown
- 2009-03-24 HK HK09102809A patent/HK1122442A1/xx unknown
Also Published As
| Publication number | Publication date |
|---|---|
| DE602008002465D1 (de) | 2010-10-28 |
| ATE482554T1 (de) | 2010-10-15 |
| US20080256204A1 (en) | 2008-10-16 |
| ATE445955T1 (de) | 2009-10-15 |
| CA2625444C (en) | 2010-07-13 |
| EP1981231B1 (en) | 2010-09-22 |
| EP1981232A1 (en) | 2008-10-15 |
| HK1123412A1 (en) | 2009-06-12 |
| ATE481805T1 (de) | 2010-10-15 |
| EP1981234A1 (en) | 2008-10-15 |
| EP1981230A1 (en) | 2008-10-15 |
| US20080256203A1 (en) | 2008-10-16 |
| CA2628765A1 (en) | 2008-10-13 |
| US8407298B2 (en) | 2013-03-26 |
| US20080256179A1 (en) | 2008-10-16 |
| HK1122442A1 (en) | 2009-05-15 |
| EP1981234B1 (en) | 2010-09-15 |
| US9118506B2 (en) | 2015-08-25 |
| DE602008002621D1 (de) | 2010-11-04 |
| EP1981231A1 (en) | 2008-10-15 |
| US8626841B2 (en) | 2014-01-07 |
| CA2625680C (en) | 2010-10-05 |
| EP1981232B1 (en) | 2009-10-14 |
| HK1122160A1 (en) | 2009-05-08 |
| DE602008000204D1 (de) | 2009-11-26 |
| CA2628765C (en) | 2012-01-24 |
| US8572185B2 (en) | 2013-10-29 |
| US20080256202A1 (en) | 2008-10-16 |
| CA2625680A1 (en) | 2008-06-30 |
| CA2625444A1 (en) | 2008-08-26 |
| EP1981230B1 (en) | 2011-08-31 |
| ATE523006T1 (de) | 2011-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2353225T3 (es) | Sistema de distribuciã“n y sincronizaciã“n de correo electrã“nico (e-mail) de acceso directo con notificaciã“n de fuera de cobertura. | |
| US8756317B2 (en) | System and method for authenticating a user for accessing an email account using authentication token | |
| ES2374652T3 (es) | Método y sistema para distribuir mensajes electrónicos a un dispositivo inalámbrico de procesamiento de datos. | |
| US8307036B2 (en) | Email server with enhanced least recently used (LRU) cache | |
| US20130007164A1 (en) | Email server with proxy caching of unique identifiers | |
| US20080046591A1 (en) | System and Method for Pushing Information from a Host System to a Mobile Data Communication Device | |
| EP1718015B1 (en) | Storing, sending and receiving text message threads on a wireless communication device | |
| US7826406B2 (en) | Storing, sending and receiving text message threads on a wireless communication device | |
| US20110060801A1 (en) | Automatic integration of a mail server with internet server (is) | |
| US20060086798A1 (en) | Deferred email message system and service | |
| US20060031334A1 (en) | Methods and systems for forwarding electronic communications to remote users | |
| US7987235B2 (en) | System and method for delayed acknowledgment of client requests in electronic mail system | |
| ES2334329T3 (es) | Sistema y metodo para empujar informacion desde un sistema anfrition a un dispositivo movil de comunicacion de datos en una red de datos inalambrica. | |
| US20070073815A1 (en) | Email server with proxy caching of message identifiers and related methods | |
| US20070038777A1 (en) | Conversation message server | |
| ES2348310T3 (es) | Sistema y método para visualizar características específicas de cuentas dispositivos. | |
| EP1929740A1 (en) | System and method for authenticating a user for accessing an email account using authentication token | |
| EP1929728A1 (en) | Email server with least recently used cache | |
| CN103701688B (zh) | 消息队列服务器及其垃圾邮件信息处理方法 | |
| CA2626043C (en) | Direct access electronic mail (email) distribution and synchronization system with out-of-coverage notification | |
| AU2005100538A4 (en) | Conversation message server | |
| WO2007040504A1 (en) | Email server with proxy caching of unique identifiers |