RESISTENCIA DE SESIÓN EN UNA RED INALÁMBRICA
CAMPO DE LA INVENCIÓN Esta invención se refiere a persistencia de sesión. Más específicamente, la invención se refiere a métodos y sistemas para persistencia de sesión en una red de comunicación inalámbrica.
ANTECEDENTES DE LA INVENCIÓN Incrementos en el número de dispositivos de cómputo móviles, tales como dispositivos de cómputo inalámbricos, acoplados con prevalencia creciente de redes empresariales corporativas ha resultado en la necesidad de un acceso transparente, confiable a las aplicaciones orientadas a red desde dispositivos de cómputo inalámbricos .
SUMARIO DE LA INVENCIÓN Las redes empresariales incluyen aplicaciones empresariales, que se ejecutan típicamente en servidores empresariales. Estas aplicaciones empresariales contienen lógica comercial que realiza funciones tales como contabilidad, programación de producción, seguimiento de información de cliente y mantenimiento de cuentas. La demanda en crecimiento de acceso a redes empresariales, así
como otras redes de cómputo corporativas que proporcionan servicios a una gran cantidad de usuarios, ha incitado el desarrollo de redes privadas virtuales ("VPN") . Una VPN es una red de comunicación privada típicamente utilizada dentro de una compañía para comunicarse sobre una red pública. El tráfico de mensajes de VPN se lleva cabo en infraestructura de red pública utilizando protocolos estándares. Con frecuencia, las VPN utilizan protocolos de tunelización criptográfica para proporcionar la confidencialidad necesaria, autentificación de emisor e integridad de mensajes para lograr la privacidad necesaria. El uso de una VPN puede extender la conectividad geográfica, mejorar la seguridad, reducir los costos operacionales de una red de área extensa ("WAN") tradicional, proporcionar soporte con trabajadores a distancia, y muestran buenos ahorros considerables. Mejoras en la computación móvil se han presentado simultáneamente con los avances de redes descritos en lo anterior. Un desarrollo es el IP Móvil. El IP Móvil es un protocolo de comunicación estándar de Fuerzas de Tareas de Diseño en Internet ("IETF") que se diseña para permitir que usuarios de dispositivos móviles se muevan de una red a otra mientras mantienen su dirección permanente de IP. Los métodos de conexión de redes han evolucionado para permitir una comunicación fuerte sobre redes de datos
alámbricas tradicionales poco confiables. A un mayor grado, la conflabilidad incrementada sobre tales redes tradicionalmente poco confiables se ha logrado por el desarrollo de protocolos confiables orientados a conexión, de extremo a extremo, tales como el Protocolo de Control de Transmisión (TCP), como se especifica en el IETF RFC 793. El TCP está diseñado para realizar una transmisión de datos de extremo a extremo confiable al comunicarse en una sesión. El TCP garantiza una distribución confiable y en orden de datos de emisor a receptor. El TCP también distingue los datos de múltiples aplicaciones concurrentes que se ejecutan en el mismo ordenador central. Muchas de las aplicaciones de conexión de redes comerciales se han desarrollado para interconectarse con TCP, debido a que el motor de TCP es un motor de protocolo de transporte exitoso y ampliamente utilizado. Como un protocolo orientado a conexión, TCP requiere indicaciones periódicas del estado de la conexión, tal como por ejemplo, la recepción de transmisiones de confirmación ("ACK") . Sin estas indicaciones, la sesión se termina. Protocolos de transporte tales como TCP se optimizan para redes de comunicación de datos alámbricas e incrementa mayormente la conflabilidad de la transmisión de datos sobre tal red. Las aplicaciones de conexión de redes, tales como aplicaciones de conexión de redes que utilizan
funcionalidad de VPN y IP Móvil, se han desarrollado para utilizar la conflabilidad del TCP orientado a conexión al grado que, con frecuencia, estas aplicaciones de conexión de redes requieren el uso de sesiones de TCP para realizar completamente los beneficios de la aplicación. Cuando se injertan en tecnología inalámbrica, sin embargo, tales aplicaciones de conexión de redes sufren disminuciones de rendimiento. Las redes inalámbricas se caracterizan por períodos prolongados de "conexión intermitente" provocada por retardos prolongados de transferencia o desconexión temporal de una Red de Área de Radio ("RAN") . En tecnología inalámbrica, por lo tanto, las sesiones con frecuencia se terminan prematuramente debido a las interrupciones temporales en las comunicaciones inherentes en la conexión de redes inalámbrica la cual evita que indicaciones periódicas del estado de conexión se reciban. De este modo, un problema es la forma de mantener las comunicaciones salientes a pesar de la falta de conexión, un problema referido como persistencia de sesión de TCP. Muchas de las aplicaciones de conexión de redes comerciales, por ejemplo, requieren sesiones de TCP/IP o circuitos virtuales privados. Algunas aplicaciones tratan extremadamente muy poco con la prioridad de una conexión de TCP, algunas veces incluso requiriendo un reinicio total de la máquina. Por lo tanto, se requiere un medio para
mantener una conexión de TCP vigente cuando los participantes experimenten periodos prolongados de desconexión. Estos problemas han sido dirigidos por el desarrollo de nueva tecnología. Por ejemplo, la Patente Norteamericana No.
5,566,225 por Hass et al. ("la patente 225"), la material objeto total de la cual se incorpora en la presente para referencia, describe un sistema para mantener una sesión de TCP sobre una red inalámbrica entre un dispositivo móvil de usuario final y un ordenador central. El sistema para la persistencia de sesión de TCP descrito en la patente 225 utiliza un "Agente Local" ejecutado en el dispositivo móvil de usuario final y un "Agente de Red" ejecutado en un procesador en la red inalámbrica o en el ordenador central para simular el modo operativo de la sesión de TCP al detectar una condición inoperable de un enlace inalámbrico. La patente ?225, sin embargo, no dirige la integración de persistencia de TCP en redes de comunicación con servidores intermediarios . La Patente Norteamericana No. 6,546,425 por
Hanson et al. ("la patente 25"), la materia objeto completa de la cual se incorpora en la presente para referencia, describe la persistencia de sesión de TCP en una red de Servidor de Administración de Movilidad ("servidor de movilidad") con intermediarios. Por ejemplo,
la patente 25 describe un servidor de movilidad que proporciona prioridades de sesión configurables por el usuario para "Sistemas Finales Móviles" (es decir, clientes móviles), una administración de política móvil por usuario para manejar el consumo de recursos de red, y dirige la administración de clientes móviles. La Figura 1 es una implementación ilustrativa de la patente 25. En el sistema ilustrado, el servidor 120 de movilidad mantiene el estado de cada uno de los clientes 102 móviles y maneja la administración de sesión compleja requerida para mantener conexiones persistentes en la red y para otros procesos, tales como ejecución de procesos en un sistema 138 central. Si un cliente 102 móvil se vuelve inalcanzable, suspende o cambia la dirección de red, el servidor 120 de movilidad mantiene la conexión en el sistema 138 central al confirmar la recepción de datos y pone en cola las solicitudes sobre el motor 128 de UDP y el motor 130 de TCP en la pila de protocolo, como se explica además en lo siguiente. Esta representación por el servidor 120 de movilidad permite que la Aplicación 104 de Red en el cliente 102 móvil mantenga una conexión continua aunque pueda perder temporalmente su conexión 136 inalámbrica. El servidor 120 de movilidad también maneja direcciones para clientes 102 móviles, y en este respecto cada cliente 102 móvil se proporciona con una dirección de intermediario en
la red primaria, conocida como la "dirección virtual" del cliente 102 móvil. El servidor 120 de movilidad mapea las direcciones virtuales, las cuales permanecen constantes, en direcciones actuales de "punto presencia" de los clientes 102 móviles conforme el sistema móvil cambia de una interconexión de red a otra. En la patente M25, la persistencia de sesión de
TCP se implementa sobre el motor de protocolo de transporte o (por ejemplo, el motor de TCP) a través de una Interfaz 108 de Controlador de Transporte ("TDI") que utiliza un Interceptor 110 Móvil. El Interceptor 110 Móvil intercepta ciertas llamadas en la interfase TDI 108 y las enruta mediante llamadas de procedimiento remotas ("RPC") y los Protocolos de Movilidad de Internet al controlador 120 de movilidad sobre la red utilizando los protocolos de transporte estándares. Tales protocolos de transporte estándares pueden incluir TCP como proporcionado por un motor 114 de TCP, y el Protocolo de Datagrama de Usuario ("UDP"), un protocolo sin conexión proporcionado por un motor 112 de UDP. Una llamada de procedimiento remota es un tipo de protocolo que permite a una programa en una computadora ejecutar un programa en una computadora de servidor. El Interceptor 110 Móvil de este modo puede interceptar toda la actividad de red y reenviarla al servidor 120 de movilidad utilizando operaciones de RPC en
lugar de operaciones de TCP. El Interceptor 110 Móvil funciona en forma transparente con características del sistema operativo para permitir que las sesiones de aplicación del lado del cliente permanezcan activas cuando el cliente 102 móvil pierde contacto con la red. El servidor 120 de movilidad opera efectivamente como una imagen espejo, trabajando con el sistema 138 central en una forma similar al sistema operativo en el cliente 102 móvil. De este modo, operaciones separadas de RPC reemplazan las operaciones de TCP para la RA . Aunque la patente 25 describe un medio de interconexión de redes persistente con intermediarios, su implementación del medio de persistencia sobre el motor de TCP es poco manejable. En una implementación actualmente disponible en el mercado, por ejemplo, esta arquitectura permite persistencia de sesión al enganchar la interfaz de programa de aplicación ("API"), de conexión lógica de red, un conjunto de rutinas, protocolos y herramientas para conectar una aplicación a un protocolo de red, para redirigir llamadas de aplicación de TCP desde aplicaciones comerciales a una TDI 108 específicamente diseñada. La interfaz de programa de aplicación de conexión lógica de red se implementa en el sistema de la Figura 1 como Windows Sockets (Conexiones Lógicas de Red para Windows) ("Winsock"), 1.1/2.0 106, una API que permite al software
de red de Windows acceder a servicios de red tal como TCP. El TDI 108 termina la llamada de TCP y abre una conexión lógica de red de UDP en el servidor. Enganchar una API de conexión lógica de red para redirigir las llamadas de TCP de una aplicación a una controladora de propiedad no se comprueba relati amente, con frecuencia es problemática y requiere configuración extensa. La TDI 108 debe re-implementar el comportamiento de TCP que esperan las aplicaciones orientadas a TCP, tal como la generación de confirmación, pausa de confirmación, detección de duplicados y reordenación de segmentos. Tal implementación extensiva, además, con frecuencia limita el número de aplicaciones disponibles para utilizarse por el Servidor 120 de Administración y Movilidad.
BREVE DESCRIPCIÓN DE LAS FIGURAS Las modalidades de los aspectos inventivos de esta descripción se entenderán mejor con referencia a la siguiente descripción detallada, cuando se lea junto con las figuras anexas, en las cuales: La Figura 1 ilustra una persistencia de TCP sobre una red de acuerdo con la técnica anterior; la Figura 2 ilustra un sistema para la persistencia de sesión de TCP entre un sistema central y un cliente en un dispositivo de cómputo móvil sobre una red
con servidores intermediarios de acuerdo con las modalidades de la presente invención; la Figura 3 es un diagrama de flujo de datos que ilustra un método para la persistencia de sesión de TCP entre un sistema central y un cliente en un dispositivo de cómputo móvil sobre una red con servidores intermediarios de acuerdo con modalidades de la presente invención la Figura A ilustra la transferencia de información entre capas del modelo de protocolo de red de Interconexión de Sistemas Abiertos de la Organización Internacional de Estándares ( "ISO/OSI" ) ; la Figura 5 es un diagrama de transmisión de datos que ilustra la persistencia de TCP en el lado de cliente móvil de una conexión inalámbrica de acuerdo con la modalidades de la presente invención; y la Figura 6A y la Figura 6B son diagramas de transmisión de datos que ilustran la persistencia de sesión de TCP de acuerdo con modalidades de la presente invención en el lado del servidor de movilidad/ordenador central de una conexión inalámbrica sobre una interrupción en la conexión inalámbrica.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La presente descripción evita la finalización de una sesión de comunicación entre dos dispositivos
(entidades), donde la sesión de comunicación está siendo llevada a cabo, por lo menos en parte, sobre una red inalámbrica, y se presenta una interrupción temporal en la comunicación. Para facilidad de explicación, se debe observar que la siguiente descripción y ejemplos se refieren específicamente a TCP, sin embargo, cualquier otros protocolos de transporte orientados a conexión pueden utilizarse (por ejemplo, un protocolo de transmisión de control de corriente). De este modo, más específicamente en una modalidad, la presente descripción evita la finalización prematura de una sesión de TCP cuando se presenta una interrupción temporal en la comunicación, a través de persistencia de sesión al hacer que un primer dispositivo genere una señal estándar de TCP de modo que el primer dispositivo "crea" que las señales generadas se transmitieron desde el segundo dispositivo en la sesión y que la sesión aun está "vigente". Estas señales sólo se generan cuando una interrupción en la comunicación de red se detecta. Una interrupción en la comunicación de red puede ser detectada al identificar cuando las señales que se esperan sean recibidas por un dispositivo no se detectan. En la persistencia de sesión de TCP, estas señales esperadas pueden ser señales de confirmación. Las señales de confirmación son paquetes de control enviados por la capa de transporte del primer dispositivo acoplado
en la sesión de TCP en la capa de transporte del segundo dispositivo acoplado en la sesión de TCP para confirmar la recepción de una transmisión desde el segundo dispositivo. De este modo, al recibir las señales, el segundo dispositivo "cree" que el primer dispositivo aun está en comunicación con el segundo dispositivo y que la sesión de TCP entre los mismos no debe ser terminada. Significativamente, y en contradicción de la técnica anterior como se discute en los Antecedentes de esta descripción, el controlador de persistencia de sesión se localiza bajo la capa de TCP en el primer y el segundo dispositivos (y un servidor no se necesita) o bajo la capa de TCP en el servidor y el primer dispositivo (si el segundo dispositivo no puede ser modificado con la presente invención), para simular señales sin interrumpir la interconexión estándar entre los programas de nivel de aplicación y la capa de transporte en el primer dispositivo, el segundo dispositivo y el servidor (si está presente). En otras palabras, el controlador de persistencia de sesión simula las señales en una capa de modelo de protocolo de red de ISO/OSI bajo la capa de transporte, como se describirá en detalle adicional en lo siguiente. Esta configuración permite la utilización completa de la capa de TCP por la aplicación a través de la interconexión estándar.
Por ejemplo, la persistencia de sesión de TCP puede implementarse , en algunas modalidades, al simular en la capa de TCP del segundo dispositivo las señales de confirmación de la capa de TCP del primer dispositivo. La persistencia de sesión de TCP también puede implementarse al simular en la capa de TCP del primer dispositivo las señales de confirmación de la capa de TCP del segundo dispositivo. En una implementación , las señales de confirmación de cada dispositivo se simulan en el otro dispositivo. Al colocar el controlador de persistencia de sesión bajo la capa de TCP, las aplicaciones pueden utilizar las llamadas de TCP para iniciar comunicaciones de red. Debido a que muchas, incluso todas, las aplicaciones comerciales se diseñan para utilizar TCP como el protocolo de capa de transporte para conexión de redes, interconectar estas aplicaciones a una capa de TCP se configura fácilmente y resulta en redes de comunicación confiables, debido a la prueba extensa de estas configuraciones. Además, cambios y actualizaciones en software de aplicación son continuos debido a que la capa de aplicación y la capa de transporte son cada una autónomas. La Figura 2 ilustra un sistema para la persistencia de sesión de TCP entre un primer dispositivo 202 y un segundo dispositivo 236 sobre una red con servidores intermediarios. El término "red con servidores
intermediarios" indica una red sobre la cual comunicaciones entre el primer dispositivo 202 y el segundo dispositivo 236 son representadas por un servidor 216 que tiene una aplicación de servidor 220 intermediario instalada y ejecutándose en el mismo. La red con servidores intermediarios de la Figura 2 se implementa al conectar el segundo dispositivo 236 al servidor 216 a través de una red 246 alámbrica y conectando el primer dispositivo 202 al servidor 216 a través de una red 235 inalámbrica que tiene una conexión 234 inalámbrica. Tal representación se explica en lo siguiente adicionalmente con respecto a la Figura 3. Aunque la presente descripción se refiere a un servidor que representa comunicaciones entre un primer dispositivo 202 en una red inalámbrica y un segundo dispositivo en una red alámbrica, otras implementaciones de la presente invención pueden incluir un servidor que representa comunicaciones entre dos dispositivos, de los cuales cada uno es una red inalámbrica o dos dispositivos inalámbricos que incorporan la presente invención, de este modo eliminando la necesidad del servidor completamente. El primer dispositivo 202, el servidor 216 y el segundo dispositivo 236 se implementan cada uno a cierto grado como módulos de software instalados y ejecutándose en una computadora, es decir, un dispositivo de cómputo autónomo, con cada uno incluyendo por lo menos un
procesador o "CPU" (no mostrada) asi como una memoria de computadora (no mostrada), que incluye memoria de acceso aleatorio volátil ("RAM") y alguna forma o formas de memoria de computadora no volátil tal como una unidad de disco duro, una unidad de disco óptimo, o un espacio de memoria de sólo lectura programable eléctricamente borrable (también conocida como memoria vEEPROM' o 'Flash'). La memoria de computadora se conecta a través de un bus en el procesador y en otros componentes de la computadora. De este modo, los módulos de software son instrucciones de programación almacenadas en una memoria de computadora. El segundo dispositivo 236 comprende el software instalado y que se ejecuta en una computadora, que incluye uno o más servicios 238 de red que realizan tareas o información de acceso. En un modelo de conexión de redes empresarial, el segundo dispositivo 236 puede incluir lógica comercial para realizar operaciones comerciales de una compañía y aplicaciones para acceder a la información confidencial de una compañía. El servidor 220 intermediario, una de las diversas aplicaciones 218 de red que se ejecutan en la capa de aplicación de ISO/OSI en el servidor 216 pero que podrían ejecutarse en el espacio del módulo central, permite al primer dispositivo 202 conectarse indirectamente o acceder a otros servicios 238 de red en el segundo
dispositivo 236 mediante el servidor 216. El servidor 216 también permite que la funcionalidad adicional se agregue a la red como se discute en lo siguiente. De este modo, en una modalidad, aunque en operación normal el primer dispositivo 202 y el segundo dispositivo 236 se comuniquen continuamente entre si en forma transparente, las comunicaciones se implementan realmente entre el primer dispositivo 202 y el segundo dispositivo 236 a través de una primera sesión de TCP entre el primer dispositivo 202 y el servidor 216 y una segunda sesión de TCP entre el servidor 216 y el segundo dispositivo 236. Estas sesiones de TCP incluyen transmisiones formadas de solicitudes de datos, respuestas a esas solicitudes, y señales para la operación de la sesión. Una sesión de TCP parece que se inicia entre el primer dispositivo 202 y el segundo dispositivo 236 por esos dispositivos, pero la sesión realmente es interceptada por el servidor 216, y divida en dos sesiones de TCP descritas en lo anterior. Alternativamente, sólo una sesión TCP puede utilizarse entre el primer dispositivo y el segundo dispositivo. El primer dispositivo 202 se conecta a los servicios 238 de red, por lo tanto, al iniciar una sesión de TCP con el servidor 220 intermediario como se describe en lo anterior y después solicita una conexión, archivo u otro recursos disponible en el segundo dispositivo 136. El
servidor 220 intermediario, una vez conectado al segundo dispositivo 236 especificado, proporciona el recurso al obtener el recurso del segundo dispositivo 136 o al dar servicio al recurso desde una ubicación designada en la memoria. Cada uno del servidor 216, el primer dispositivo 202 y el segundo dispositivo 236 incluyen componentes de software de aplicación (aplicaciones 218 de red, aplicaciones 204 de red, y servicios 238 de red, respectivamente) que operan en la capa de aplicación del modelo de protocolo de red de ISO/OSI que realiza operaciones de alto nivel que involucran comunicación entre aplicaciones de software y servicios de red de capa inferior de modo que la red pueda interpretar una solicitud de aplicación y la aplicación pueda interpretar los datos enviados desde la red. Cada uno del servidor 216, el primer dispositivo 202 y el segundo dispositivo 236 de la Figura 2 también incluye una capa de TCP (206, 222 y 240) y una capa de IP (208, 224 y 242), y una Interfaz de Programación de Aplicación de Especificación de Interfaz de Controlador de Red ("API") de ("NDIS") (212, 228, 244) que forman porciones de una pila de comunicación de red (205, 221 y 239) para facilitar comunicaciones de red. Los componentes del software de aplicación (aplicaciones 218 de red,
aplicaciones 204 de red y servicios 238 de red) realizan llamadas de aplicación de TCP en sus capas de TCP respectivas (206, 222, 240) para transmitir información a otros componentes de software de aplicación sobre la red. Típicamente, la información se transmite desde el componente de software de aplicación hasta la capa de TCP en una corriente continua de bytes. Las capas 206, 222 y 240 de TCP implementan TCP el cual, como se describe en lo anterior, utiliza comprobación de errores para asegurar una distribución confiable y en orden de los paquetes de datos a la aplicación apropiada que se ejecuta en la computadora de recepción. Las capas 208, 224 y 242 de IP que se ejecutan en cada entidad implementan la capa de IP que asegura la distribución de los paquetes de datos al dirigir el paquete con una dirección de IP única de la máquina. La API de NDIS (212, 228 y 244) es una interfaz de tarjeta de red que proporciona el 'medio funcional y de procedimiento para transferir datos entre entidades de red a través de la tarjeta de red de la computadora y la Ethernet a la tarjeta de red de la entidad correspondiente. La API de NDIS dirige los paquetes de datos al utilizar un esquema del direccionamiento físico, tal como una dirección de Control de Acceso a Medios ("MAC") la cual se codifica permanentemente en la mayor parte del equipo de conexión de
redes al momento de su fabricación. Aunque el servidor 216, el primer dispositivo 202, y el segundo dispositivo 236 de las modalidades descritas en la Figura 2 incluyen cada uno una API de NDIS como una interfaz de tarjeta de red, modalidades alternativas del sistema de la Figura 2 pueden incluir el uso de cualquier filtro de red (por ejemplo, Linux) y aun encontrarse muy bien dentro del alcance de la invención como se define en las reivindicaciones. Como es importante para modalidades de la invención, el servidor 216 se acopla con la red a través de uno o más controladores 226 de persistencia de sesión en la pila 221 de comunicación de red. El o los controladores 226 de persistencia de sesión de la Figura 2 son un módulo de software que monitorea las comunicaciones de red para detectar una interrupción, y para crear señales para mantener la persistencia de TCP, como se explicará adicionalmente en detalle en lo siguiente. El controlador 226 de persistencia de sesión se acopla con la capa 222 de TCP mediante la capa de IP en el servidor 216. Todas las comunicaciones bajo la capa 222 de TCP pasan a través del controlador 226 de persistencia de sesión, como se explicará en detalle adicional posteriormente. La capa 224 de IP además se acopla con la red a través de la API de NDIS 228. La pila de TCP/IP y la API de NDIS 228 se discuten en detalle adicional en lo siguiente. En algunas
modalidades, el controlador 226 de persistencia de sesión se ejecuta en un procesador separado independiente del procesador en el servidor 216. En otras modalidades, el controlador 226 de persistencia de sesión puede implementarse como hardware o una combinación de hardware y software. Todas las modalidades son controladores 226 de persistencia de sesión tan pretendidos como dentro del alcance de la presente invención. Para realizar esta función de persistencia de sesión de TCP, el controlador 226 de persistencia de sesión incluye instrucciones de programación de computadora para generar una o más señales de TCP adaptadas para ser interpretadas por la capa 240 de TCP en el segundo dispositivo 236 como siendo transmitido desde el primer dispositivo 202. En una modalidad, el controlador 226 de persistencia de sesión genera y envía un anuncio publicitario sin ventanas 230 ("ZWA") hacia arriba de la pila de protocolo en la capa 222 de TCP y ZWA 232 hacia debajo de la pila de protocolo y a través de la red cableada en la capa 240 de TCP en el segundo dispositivo 236 para "convencer" a las capas 222 y 240 de TCP que la capa 206 de TCP aun está conectada y mantiene una sesión de TCP entre el primer dispositivo 202 y el segundo dispositivo 236. Tales ZWA 230 simuladas se generan bajo la capa de transporte a partir de una perspectiva de modelo de
protocolo de red ISO/OSI, equiparable con modalidades de la invención, como se explicará en detalle adicional posteriormente . El primer dispositivo 202 también contiene un controlador 210 de persistencia de sesión, el cual de igual forma genera una o más señales de TCP, en la pila 205 de comunicación de red. Las señales de TCP del controlador 210 de persistencia de sesión se adaptan para ser interpretadas por la capa 206 de TCP en el primer dispositivo 202 como siendo transmitidas desde el segundo dispositivo 236. El controlador 210 de persistencia de sesión de este modo se habilita similarmente para generar y enviar ZWA 214 hacia arriba de la pila de protocolo en la capa 206 de TCP para "convencer" a la capa 206 de TCP que una capa 240 de TCP (o 222) aun está conectada, para mantener una sesión de TCP entre el primer dispositivo 202 y el segundo dispositivo 236. Con una descripción básica del sistema a la mano, ahora se pone atención a la Figura 3, la cual establece un diagrama de flujo que ilustra un método para mantener la persistencia de sesión de TCP sobre una red de acuerdo con una modalidad de la presente invención. Para consistencia, los números de referencia de la Figura 2 se utilizan a través de la descripción del diagrama de flujo de la Figura 3. El método comienza al representar comunicaciones de red
mediante un servidor 216 (etapa 302) . Como se observa en lo anterior, esto puede ser llevado a cabo al utilizar un servidor 220 intermediario en el servidor 216 para implementar VPN e IP Móvil para la red de comunicación como se explica en la sesión Antecedente de esta descripción. La funcionalidad de IP Móvil implementada en el' presente método puede incluir funciones implementadas por las especificaciones Móvil IPv4, Móvil IPv6, o cualquier otra especificación de IP Móvil conocida por aquellos con experiencia en la técnica. En una implementación preferida de IP Móvil, cada dispositivo inalámbrico (por ejemplo, el primer dispositivo 202) siempre es identificado por su dirección local, independientemente de su punto actual de unión a la Internet. Adicionalmente, mientras el primer dispositivo 202 se localiza lejos de la casa, se asocia también con una dirección "para entregar", la cual proporciona información sobre su punto actual de unión al Internet, como se conoce bien. En breve, la etapa 302 de representación también puede proporcionar registrar la dirección para entrega y otras particularidades básicas de red típicamente como pueden presentarse entre un primer dispositivo 202 y un segundo dispositivo 236. Como se discute en lo anterior, una VPN es una red de comunicación privada típicamente utilizada dentro de una compañía para comunicarse sobre una red pública. Con
frecuencia, las VPN utilizan protocolos de tunelización criptográfica para proporcionar la confidencialidad necesaria, autentificación del emisor, e integridad de mensajes para lograr privacidad. Por consiguiente, la etapa 302 de representación en algunas implementaciones puede incluir transmitir datos utilizando un protocolo de tunelización criptográfica, es decir, un protocolo de red encriptado el cual encapsula un protocolo o sesión dentro de otra. En tal implementación de VPN, el sistema puede requerir que todo el tráfico pase a través del túnel mientras la VPN está activa para mejorar la seguridad sobre redes no seguras. Transmitir datos utilizando un protocolo de tunelización criptográfica también puede incluir proporcionar otra funcionalidad de VPN, tal como por ejemplo, direccionamiento privado. Como se describe en lo anterior, la persistencia de sesión de TCP de acuerdo con la presente descripción incluye utilizar controladores 210, 226 de persistencia de sesión para simular transmisiones esperadas de TCP durante una desconexión temporal. En el rendimiento de esta tarea, y como se muestra en la Figura 3, los controlares 210 y 226 de persistencia de sesión incluyen instrucciones de programación de computadora para monitorear las comunicaciones de red (304) entre el primer dispositivo 202 y el segundo dispositivo 236; detectar (306) una
interrupción temporal en la comunicación de red; y con la detección de una interrupción temporal (307) evitar que la capa de transporte transmita la sesión durante la interrupción temporal (310), como se explica en detalle adicional en lo siguiente. Durante la etapa de monitoreo (304), los controlares 210 y 226 de persistencia de sesión en el primer dispositivo 202 y el servidor 216, respectivamente, operan para detectar una interrupción en la comunicación de red. Debido a que una sesión de TCP continúa siempre y cuando las señales esperadas de una capa de TCP se reciban por la otra capa de TCP, esta etapa 304 de monitoreo puede comprender pasar en forma transparente las señales recibida de TCP y detectar una falla para recibir una señal esperada de TCP. En algunas implementaciones , los paquetes de datos de TCP se reciben en los controladores de persistencia de sesión y después se manejan en la capa de TCP. En modalidades alternativas, los paquetes de datos de TCP sólo son monitoreados hasta que se detecta una interrupción en la comunicación, en cuyo momento el controlador de persistencia de sesión ingresa un estado activado y se inserta a si mismo en la pila para hacer que todos los paquetes de datos de TCP pasen a través del controlador de persistencia de sesión. Una señal útil para este propósito de monitoreo es una señal de "ACK" la cual confirma la
recepción de un paquete transmitido. Por consiguiente, durante una sesión, cuando una primera capa de TCP envía un paquete de TCP a una segunda capa de TCP, espera la devolución de una señal de ACK. Un cronómetro de la capa de envío de TCP provocará una pausa si una confirmación no se recibe dentro de un tiempo de ida y vuelta razonable, y los datos (probablemente perdidos) entonces se retransmitirán. Después de una cantidad de tiempo configurada, o un número configurable de reintentos, la capa de envío de TCP termina la sesión. Los controladores 210 y 226 de persistencia de sesión, en el primer dispositivo 202 y el servidor 216 respectivamente, evitan esta finalización al responder a una interrupción temporal detectada en la comunicación. Para el controlador de persistencia de sesión, la interrupción temporal en la comunicación también puede ser detectada como una cantidad de tiempo configurable o un número de reintentos configurable sin recibir una confirmación esperada. La cantidad de tiempo configurable y el número de intentos configurable para el controlador de persistencia de sesión, sin embargo, cada una son menor que la capa de TCP, lo cual permite que el controlador de persistencia de sesión evite la finalización de la sesión de TCP. Los controladores 210, 226 de persistencia de sesión pueden detectar alternativamente una interrupción temporal en la comunicación a través de una indicación
externa. Una indicación externa puede ser cualquier entrada externa de la cual el módulo de persistencia de sesión debe inferir una interrupción en la comunicación, tal como por ejemplo, una interrupción de hardware, un evento de software, o una notificación de cambio de política. Una vez que se ha detectado una interrupción (etapa 306), la siguiente etapa (310) en el método de la Figura 3 es para evitar que la capa de transporte finalice la sesión durante la interrupción temporal por ejemplo, al simular señales de modo que el sistema persista en mantener el primer dispositivo 202 y el segundo dispositivo 236 enlazados, a pesar de la interrupción temporal. De este modo, simular las señales 312 de TCP se lleva a cabo utilizando los controladores 210, 226 de persistencia de sesión, los cuales simulan una sesión de comunicación de datos continua entre el primer dispositivo 202 y el segundo dispositivo 236 a pesar de la interrupción temporal. Como se observa previamente, en las modalidades de la invención, los controladores 210 y 226 de persistencia de sesión se encuentran por debajo de las capas 206 y 222 de TCP, respectivamente, significando que cada simulación de las señales se presenta en niveles de ISO/OSI bajo aquellos de las capas 206 y 222 de TCP, con los beneficios de que las aplicaciones pueden utilizar llamadas de TCP para iniciar comunicaciones de red
incrementado la conflabilidad de la red con servidores intermediarios y realizando actualización de la red más fácil . En una modalidad, la etapa de simulación (310) comprende generar, en uno o más controladores 210, 226 de persistencia de sesión una o más señales 312 de TCP adaptadas para ser interpretadas por el segundo dispositivo 236 como viniendo del primer dispositivo 202 o interpretadas por el primer dispositivo 202 como viniendo del segundo dispositivo 236. Las señales 312 de TCP indican que una memoria intermedia asignada para recibir los datos entrantes en el segundo dispositivo está llena (por ejemplo, Z A) . En respuesta a una señal de ZWA, una capa de TCP deja de enviar los paquetes de datos, pero aun mantiene la sesión de TCP. Nuevamente, la señal de ZWA se genera en un nivel en la pila de ISO/OSI bajo la capa de TCP. La Figura 4 ilustra la transferencia de información entre capas del modelo de protocolo de red de ISO/OSI, el cual es una guia que proporciona una infraestructura para desarrollar estándares para servicios de conexión de redes y protocolos, en dos diferentes nodos 400 y 401. El modelo de protocolo tiene siete capas. De arriba a abajo, son como sigue: la capa 402 de aplicación (capa siete), la capa 404 de presentación (capa seis), la capa 406 de sesión (capa cinco), la capa 408 de transporte
(capa cuatro), la capa 410 de red (capa tres), la capa 412 de enlace de datos (capa dos), y la capa 414 física (capa uno) . Cada capa utiliza los servicios de la capa siguiente y proporciona un servicio a la capa anterior. Una capa en un nodo 400 se comunica con la capa equivalente en un nodo 401 diferente. Los datos se propagan desde una capa de protocolo en un primer dispositivo hasta la misma capa de protocolo en un segundo dispositivo al manejar los datos hacia la siguiente capa más baja, la cual a su vez maneja los datos en la capa siguiente. Los datos se transforman físicamente en otro nodo en la capa 1, la capa física. Los datos entonces se pasan desde una capa a la siguiente hasta que alcanza su destino. Cada capa agrega información en un encabezado conforme pasa datos, y utiliza la información al remover el encabezado en la misma forma hacia arriba. Los lectores con experiencia en la técnica reconocerán que ninguna red se implementa exactamente como lo muestra el modelo de protocolo. En la práctica, las capas cinco y seis con frecuencia se omiten. Cuando se describe una primera capa como estando bajo una segunda capa, significa que la primera capa es cualquier capa que esté numéricamente por debajo de la segunda capa. El controlador 440 de persistencia de sesión de la presente invención se implementa bajo la capa 408 de transporte. Por lo tanto, reside en cualquier capa menor que la cuarta capa (de
transporte), por ejemplo, la capa 410 de red, la capa 412 de enlace de datos o una capa entre las mismas (por ejemplo, lo que se conoce por aquellos con experiencia en la técnica como capa 2.5) . En contraste, el medio de persistencia de la patente M25 430, por ejemplo, opera sobre la capa 408 de transporte. También se debe observar que incluso la presente descripción se refiere como una "capa" que realiza una función para facilidad de explicación, se debe entender por alguien con experiencia en la técnica que los protocolos o dispositivos dentro de la capa realmente pueden realizar la función. Por ejemplo, la capa de transporte tiene un protocolo de transporte que es implementado por un motor de protocolo de transporte o dispositivo similar. Para explicación adicional de las modalidades de la invención, la Figura 5 establece un diagrama de llamadas que ilustra la transmisión de datos sobre la red de la Figura 2 de acuerdo con el método descrito en la Figura 3. Debido a que la persistencia de sesión se activa en el primer dispositivo en la red inalámbrica y el segundo dispositivo en la red alámbrica de la Figura 2, la Figura 5, la Figura 6A y la Figura 6B ilustran la transmisión de señales en ambos de estos lados. En cada uno de los diagramas de llamadas, la transmisión de paquetes de datos desde un módulo a otro se ilustra en una secuencia
cronológica de arriba a abajo de las Figuras. La Figura 5, que ilustra la persistencia de sesión de TCP en el lado del primer dispositivo 202 de la conexión 234 inalámbrica, primero muestra (505) la transmisión de paquetes de datos en una sesión de TCP cuando no existe ninguna interrupción en la conexión 234 inalámbrica en el primer dispositivo 202 y el servidor 216. Como puede observarse, en tal caso, una corriente de bytes fluye desde la aplicación 204 del primer dispositivo hasta la aplicación 218 de la red de servidor a través de los diversos intermediarios ilustrados en la Figura 2. Específicamente, la aplicación 204 del primer dispositivo envía una corriente de bytes de 8 bits, o corriente 517 de byte, a la capa 206 de TCP en el primer dispositivo para su distribución a través de la red. La capa 206 de TCP en el primer dispositivo almacena la corriente 517 de bytes en una memoria intermedia y comienza a construir segmentos, o paquetes de datos de TCP, que contienen los datos de la corriente 517 de bytes, comenzando con el primer paquete 518 de datos de TCP. Cada paquete se le da un número de secuencia. La capa 206 de TCP en el primer dispositivo pasa el paquete 518 de datos de TCP resultante a la capa 208 de Protocolo de Internet (no mostrada). En algunas modalidades, el paquete 518 de datos de TCP se envía desde la capa 208 de Protocolo de Internet (no mostrada) en el
controlador 216 de persistencia de sesión para su distribución desde el controlador 210 de persistencia de sesión a través de la red 235 inalámbrica hasta el controlador 226 de persistencia de sesión en el servidor 216. En modalidades alternativas, el controlador de persistencia de sesión sólo monitorea el paquete 518 de datos, el cual se envía desde la capa 208 de Protocolo de Internet (no mostrada) a través de la red inalámbrica, hasta que se activa como se describe en lo anterior. Ambas implementaciones se incluyen en la siguiente discusión que se refiere al controlador 210, 226 de persistencia de sesión que pasa los paquetes de datos. El controlador 226 de persistencia de sesión pasa los paquetes de datos a la capa 222 de TCP en el servidor la cual comprueba para asegurarse que ningún paquete de datos se pierda y que los paquetes de datos estén en orden correcto al analizar el número de secuencia en cada paquete. La capa 222 de TCP en el servidor distribuye la información en corriente 519 de bytes a las aplicaciones 218 de red. La capa 222 de TCP en el servidor reenvía una confirmación, ACK 520 de TCP, para el paquete 518 de datos de TCP exitosamente recibido. En contraste, cuando existe una interrupción en la conexión 234 inalámbrica (507), el paquete 522 de datos de TCP del controlador 210 de persistencia de sesión o la capa 208 de Protocolo de Internet (no mostrada) permanece
sin confirmar después de cierto periodo de tiempo, incluso después de algunos reintentos (524 , 526) . Como se discute en lo anterior, esta es una ocurrencia común en una red inalámbrica, debido al alto potencial de un rompimiento en la conexión 234 inalámbrica. Por consiguiente, para evitar una finalización de sesión de TCP la cual de otra forma puede ser provocada por la capa 206 de TCP en el primer dispositivo que excede un número predeterminado de intentos, el controlador 210 de persistencia de sesión cuenta el número de intentos por cada paquete de datos de TCP. Al exceder un número configurable de reintentos (528) para un paquete de datos (el cual es menor que el número predeterminado de intentos requeridos para finalizar la sesión TCP) , el controlador 210 de persistencia de sesión envía una ZWA 214 a la capa 206 de TCP en el primer dispositivo. La ZWA 214 le dice a la capa 206 de TCP de envío en el primer dispositivo para que deje de enviar debido a que la ventana de la memoria intermedia del proceso de TCP de recepción está llena, pero para mantener la conexión/sesión abierta. La capa 206 de TCP de envío en el primer dispositivo responde a la ZWA 214 al cesar la transmisión y probar periódicamente la conexión al transmitir una sonda 532 de anuncio publicitario con ventana. Si la capa de TCP en el servidor recibe una sonda de anuncio publicitario de ventana, la conexión TCP puede
restablecerse. El controlador 210 de persistencia de sesión por lo tanto bloquea la sonda 532 de anuncio publicitario de ventana y transmite continuamente los paquetes 534 que mantienen vigente el TCP al controlador 226 de persistencia de sesión en el servidor 216. La transmisión de los paquetes 534 que mantienen vigente el TCP permite una sonda de reconexión sin el riesgo de reestablecer la conexión/sesión de TCP. Los paquetes que mantienen vigente al TCP también son mensajes válidos de TCP que utilizan funcionalidad estándar de TCP, de modo que utilizar los paquete que mantienen vigente el TCP evita la sobrecarga de administración adicional de conexión de TCP. El controlador 210 de persistencia de sesión también transmite una ZWA 214' en respuesta a cada sondeo de anuncio publicitario de ventana para continuar concillando la capa 206 de TCP de envío en el primer dispositivo. Aunque la reconexión que utiliza los paquetes 534 que mantiene vigente el TCP se describe en lo anterior, la reconexión puede llevarse a cabo al enviar cualquier mensaje detectable por un controlador de persistencia por sesión. Una vez que se restablecen las comunicaciones, el controlador 226 de persistencia de sesión en el servidor 216 ahora será capaz de responder a uno de los paquetes 534 que mantiene vigente el TCP continuamente transmitidos al transmitir una ACK 538 que mantiene vigente el TCP
nuevamente a través de la red 235 inalámbrica al controlador 210 de persistencia de sesión. La ACK 538 que mantiene vigente al TCP informa al controlador 210 de persistencia de sesión que la conexión 234 inalámbrica se ha restablecido. El controlador 210 de persistencia de sesión, con la recepción de la ACK 538 de vigencia envía el anuncio 540 de ventana previo a la capa 206 de TCP en el primer dispositivo, el cual dice a la capa 206 de TCP en el primer dispositivo que continúe retransmitiendo los datos perdidos tomando en cuenta el tamaño de la ventana de memoria intermedia que simuló en el anuncio 540 de ventana previo. Los datos perdidos ahora se transmiten como el paquete 542 de datos de TCP, los cuales, se vuelven comunicaciones ahora restablecidas, se propaga como normal entre la aplicación 204 en el primer dispositivo 202 y la capa 222 de TCP en el servidor 216 (que resulta en la ACK 544 de TCP), y mediante la corriente 543 de bytes, a la aplicación 218 de servidor. Habiendo descrito el diagrama de llamadas en el lado del primer dispositivo 202 de la conexión inalámbrica, el protocolo de persistencia de sesión de TCP funciona en forma similar para preservar una sesión de TCP en el lado del servidor 216 de movilidad/segundo dispositivo 236 de la conexión 234 inalámbrica. El servicio 238 de red en el segundo dispositivo 236 y las aplicaciones 218 de red en el
servidor 216 de movilidad transmiten una corriente de bytes a sus capas 240 y 222 de TCP respectivas. La pila de protocolo en el segundo dispositivo 236 transmite paquetes de datos sobre la red 246 alámbrica a la pila de protocolo en el servidor 216, el cual a su vez transmite los paquetes de datos sobre la conexión 235 inalámbrica a la pila de protocolo en el primer dispositivo 202. Cada capa de TCP de transmisión espera una ACK de TCP para confirmar una transmisión exitosa, como se describe en lo anterior. La mayor parte de los aspectos de la persistencia de sesión de TCP en el lado del servidor 216 de movilidad/segundo dispositivo 236 de la conexión 234 inalámbrica son similares a aquel del lado del primer dispositivo, y por lo tanto, no se describirá en un detalle. Aspectos de la persistencia de sesión de TCP en el lado del servidor 216/segundo dispositivo 236 con la interrupción de las comunicaciones de red, sin embargo, se describen en detalle directamente en lo siguiente. La Figura 6A y la Figura 6B, por lo tanto, muestran la persistencia de sesión de TCP con una interrupción en la conexión 234 inalámbrica. La Figura 6A y la Figura 6B muestran dos respuestas por el controlador 226 de persistencia de sesión en la misma interrupción detectada en la comunicación. El paquete 622 de datos de TCP del controlador 210 de persistencia de sesión permanece
sin confirmar después de cierto periodo de tiempo, incluso después de varios reintentos (624, 626) . La Figura 6A, que ilustra la persistencia de sesión de TCP para la sesión de TCP entre el servidor 216 de movilidad y el primer dispositivo 202, muestra que el controlador 226 de persistencia de sesión cuente el número de reintentos por cada paquete de datos de TCP. Al exceder un numero configurable de reintentos (628) para un paquete de datos (el cual es menor que el número predeterminado de intentos requeridos para finalizar la sesión de TCP) , el controlador 226 de persistencia de sesión envía una Z A 230 a la capa 222 de TCP del servidor de movilidad. La ZWA 230 dice a la capa 222 de TCP del servidor de movilidad de envío que deje de enviar debido a que la ventana de la memoria intermedia del proceso de TCP de recepción está llena, pero que mantenga abierta la conexión/sesión. La capa 222 de TCP de servidor de movilidad de envío responde a la ZWA 230 al cesar la transmisión y probar periódicamente la conexión al transmitir una sonda 632 de anuncio publicitario de ventana. Regresando ahora a la Figura 6B, el controlador 226 de persistencia de sesión también envía una ZWA 232 a la capa 240 de TCP en el segundo dispositivo a través de la red 246 alámbrica. La ZWA 232 dice a la capa 240 de TCP de envío en el segundo dispositivo que deje de enviar debido a
que la ventana de memoria intermedia del proceso de TCP de recepción está llena, pero que mantenga abierta la conexión/sesión. La capa 240 del TCP de envío en el segundo dispositivo responde a la ZWA 232 al cesar la transmisión y probar periódicamente la conexión al transmitir una sonda 662 de anuncio publicitario de ventana. Cesar la transmisión es importante debido a que el servidor 216 de movilidad no puede transmitir, y continuar transmitiendo sobrecargará la memoria intermedia en el servidor 220 intermediario, provocando pérdida de datos. Regresando ahora a la Figura 6A, el controlador 226 de persistencia de sesión recibe la sonda 632 de anuncio publicitario de ventana y continuamente transmite paquetes 634 que mantienen vigente el TCP al controlador 210 de persistencia de sesión en el servidor 216. El controlador 226 de persistencia de sesión también transmite una ZWA 230' en respuesta a cada sondeo de anuncio publicitario de ventana para continuar concillando la capa 222 de TCP de envío en el servidor de movilidad. Regresando ahora a la Figura 6B, el controlador
226 de persistencia de sesión recibe la sonda 662 de anuncio publicitario de ventana. El controlador 226 de persistencia de sesión también transmite una ZWA 232' en respuesta a cada sondeo de anuncio publicitario de ventana para continuar concillando la capa 240 de TCP de envío en
el segundo dispositivo. Regresando a la Figura 6A, una vez que se restablecen las comunicaciones, el controlador 210 de persistencia de sesión en el servidor 216 será capaz de responder a uno de los paquetes 234 para mantener vigente el TCP continuamente transmitido al transmitir una ACK 638 para mantener vigente el TCP nuevamente a través de la red 235 inalámbrica al controlador 226 de persistencia de sesión. La ACK 638 para mantener vigente el TCP informa al controlador 226 de persistencia de sesión que la conexión 234 inalámbrica se ha restablecido. El controlador 226 de persistencia de sesión, con la recepción de ACK 638 de vigencia, envía el anuncio 640 de ventana previo a la capa 222 de TCP en el servidor, el cual dice a la capa 222 de TCP de servidor que continúe retransmitiendo los datos perdidos, tomando en cuenta el tamaño de la ventana de memoria intermedia que se simuló en el anuncio 640 de ventana previo. El anuncio de ventana previo es el anuncio de ventana que declara el tamaño de la memoria intermedia al momento que se perdió la comunicación. Los datos perdidos ahora se retransmiten como un paquete de datos de TCP, y se retoman la comunicaciones normales. Regresando nuevamente a la Figura 6B, el controlador 226 de persistencia de sesión con la recepción de la ACK 638 de vigencia, también envía el anuncio 680 de
ventana previo a la capa 640 de TCP en el segundo dispositivo, el cual dice a la capa 240 de TCP en el segundo dispositivo que continúe retransmitiendo los datos perdidos tomando en cuenta el tamaño de la ventana de memoria intermedia que se simuló en el anuncio 640 de ventana previo. El segundo dispositivo retoma los paquetes de TCP de transmisión, y se retoman comunicaciones normales . Se debe entender que los conceptos inventivos descritos en la presente tienen capacidad de muchas modificaciones. Al grado en que las modificaciones caigan dentro del alcance de las reivindicaciones anexas y sus equivalentes, se pretenden para ser cubiertas por esta patente .