MXPA04006408A

MXPA04006408A - Equilibrio de carga de red con manipulacion de conexion.

Info

Publication number: MXPA04006408A
Application number: MXPA04006408A
Authority: MX
Inventors: Sanjay N Kaniyar
Original assignee: Microsoft Corp
Priority date: 2003-06-30
Filing date: 2004-06-29
Publication date: 2006-07-24
Also published as: EP1494422A3; DE602004018065D1; ATE416551T1; CN1607781A; AU2004202403B2; JP2005027304A; KR101169073B1; KR20050002608A; TW200508963A; HK1069940A1; US20050055435A1; JP4583091B2; MY140059A; EP1494422A2; TWI366131B; BRPI0402571A; CA2470420A1; AU2004202403A1; CN1607781B; EP1494422B1

Abstract

En una implementacion ilustrativa de dispositivo, un dispositivo incluye: un emigrante de conexion que esta configurado para emigrar conexiones lejos del dispositivo; el emigrante de conexion capaz de precipitar una compilacion de estado de protocolo para una conexion a traves de una pila de conexion; el emigrante de conexion adaptado para agregar el estado de protocolo compilado con datos para la conexion a un estado de conexion agregada: el emigrante de conexion ademas capaz de hacer que el estado de conexion agregada sea enviado a un dispositivo objetivo. En una implementacion ilustrativa de medios, instrucciones ejecutables por un procesador dirigen al dispositivo a realizar acciones que incluyen: obtener por lo menos una porcion de un par de fuente/destino de un paquete; tener acceso a una tabla de mapa de encapsulacion; extraer un identificador de flujo de la entrada de mapa de encapsulacion; extraer un identificador de flujo de la entrada de mapa de encapsulacion; y reemplazar parte del paquete con el identificador de flujo para producir un paquete encapsulado.

Description

EQUILIBRIO DE CARGA DE RED CON MANIPULACION DE CONEXION SOLICITUDES DE PATENTE RELACIONADAS Esta Solicitud no Provisional de E.U.A. para Título de Patente (i) es una continuación en parte de la Solicitud no Provisional de E.U.A. copendiente para Título de Patente NO. 10/610,506 (presentada el 30 de Junio del 2003), (ii) es una continuación en parte de la Solicitud no Provisional de E.U.A. copendiente para Título de Patente No. 10/610,519 (presentada el 30 de Junio de del 2003), y (iii) es una continuación en parte de la Solicitud no Provisional de E.U..A. copendiente para Título de Patente No. 10/610,321 (presentada el 30 de Junio del 2003). Específicamente, esta Solicitud no Provisional de E.U.A. para Título de Patente es una continuación en parte de, y de esta manera se incorpora aquí por referencia en toda la descripción de, Solicitud no Provisional de E.U.A. copendiente para Título de Patente No. 10/610,506, presentada el 30 de Junio del 2003, e intitulada "Equilibrio de Carga de Red Flexible". Específicamente, esta Solicitud no Provisional de E.U.A. para Título de Patente también es una continuación en parte de, y de esta manera se incorpora aquí por referencia en toda la descripción de, Solicitud no Provisional de E.U.A. copendiente para Título de Patente No. 10/610,519, presentada el 30 de Junio del 2003, e intitulada "Equilibrio de Carga de Red con Información de Estado de Huésped". Específicamente, esta Solicitud no Provisional de E.U.A. para Titulo de Patente también es una continuación en parte de, y de esta manera se incorpora aquí por referencia en toda la descripción de, Solicitud no Provisional de E.U.A. copendiente para Título de Patente No. 10/610,321, presentada el 30 de Junio del 2003, e intitulada "Equilibrio de Carga de Red con Información de Sesión".

CAMPO DE LA INVENCION Esta descripción se refiere en general al equilibrio de carga de red y en particular, a manera de ejemplo pero no de limitación, al equilibrio de carga de red con manipulación de conexión, tal como migración de conexión con tunelización y/o migración de conexión junto con equilibrio de carga de nivel de aplicación.

ANTECEDENTES La comunicación, y muchas facetas de la vida que involucran la comunicación, se han visto enormemente impactadas por el Internet. El Internet permite que la información sea comunicada entre dos personas y/o entidades rápida y relativamente en forma fácil. El Internet incluye muchos nodos de red que están enlazados en conjunto, de manera que la información puede ser transferida entre ellos. Algunos nodos de red pueden ser enrutadores que propagan un paquete de un enlace hacia otro, pueden ser computadoras de cliente individuales, pueden ser redes personales para diferentes entidades (por ejemplo, intranets para negocios), y así sucesivamente. Para este caso de red personal, así como para otros, los paquetes que llegan a un nodo o nodos de Internet son distribuidos a otros nodos dentro de la red personal. Dicha red personal puede estar formada, por ejemplo, de un grupo de servidores que cada uno trabaja sobre los paquetes que llegan a la red personal. Un negocio, universidad, u oficina de gobierno, etc., puede recibir muchos paquetes en un marco corto de tiempo en su red personal. Con el fin de responder en una forma a tiempo y de reducir la probabilidad de rechazo o pérdida de los paquetes que llegan, la red personal puede basarse en múltiples servidores que pueden trabajar cada uno en los paquetes que llegan, simultáneamente. Los paquetes que llegan por lo regular son preguntas que se refieren a cierta información, tales como un documento, un artículo de catálogo, una página web, etc. Los paquetes que llegan también pueden referirse a una transacción económica entre un cliente y un comerciante. Son posibles otros propósitos para los paquetes de una comunicación a base de paquetes. A diferencia, los paquetes que llegan son distribuidos entre diferentes servidores de un grupo de servidores para adaptarse una rápida llegada de los paquetes y/o intercambios de comunicación complejos. La distribución de los paquetes que llegan entre diferentes servidores de un grupo de servidores por lo regular se denomina equilibrio de carga de red. En otras palabras, se puede realizar una operación de equilibrio de carga en los paquetes a medida que llegan a un nodo o nodos del Internet, cuando el nodo o nodos constituyen una red personal y/o cuando se conectan la red personal al Internet.

Dicha operación de equilibrio de carga se logra utilizando hardware dedicado que afronta la red personal en el nodo o nodos que conectan la red personal al Internet y/o que proporcionan una presencia para una red personal a través del Internet. El hardware físico que realiza la operación de equilibrio de carga usualmente es duplicado en su total para realizar la redundancia y mejorar la disponibilidad de la operación de equilibrio de carga. Para incrementar la capacidad de operaciones de equilibrio de carga, el hardware más potente que replica la totalidad del hardware de equilibrio de carga previo, y de esta manera su capacidad operacional, es substituido por el hardware de equilibrio de carga previo. Dicho escalamiento de las capacidades operacionales del equilibrio de carga, por lo tanto, está confinado a incrementar la energía de hardware a través de su sustitución. Para implementar una operación de equilibro de carga, el hardware usualmente realiza una distribución de circuito cíclico (asignación de ida y vuelta) de la llegada de solicitudes de conexión. En otras palabras, las solicitudes de conexión de llegada son distribuidas a servidores en una forma de repetición, lineal con una sola solicitud de conexión siendo distribuida a cada servidor. Esta distribución de equilibrio de carga de circuito cíclico de conexiones típicamente se utiliza sin considerar la condición de la red personal o la naturaleza de una solicitud de conexión que llega. Si una operación de equilibrio de carga se extiende más allá de una distribución de circuito cíclico, éstos y otros factores solamente son considerados al grado en que pueden ser inferidos del tráfico de red y/o de un nivel de congestión de la red personal. Por consiguiente, existe la necesidad de esquemas y/o técnicas que mejoran el equilibrio de carga de red y/o las opciones asociadas con el mismo.

COMPENDIO DE LA INVENCION En una primera implementación ilustrativa de dispositivo, un dispositivo incluye: un emigrante de conexión que está configurado para emigrar conexiones lejos del dispositivo; el emigrante de conexión capaz de precipitar una compilación de estado de protocolo para una conexión a través de una pila de protocolo; el emigrante de conexión adaptado para agregar el estado de protocolo compilado con datos para la conexión a un estado de conexión agregado de la conexión; el emigrante de conexión además capaz de hacer que el estado de conexión agregado sea enviado a un dispositivo objetivo. En una primera implementación ilustrativa de medios, uno o más medios accesibles por un procesador incluye instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen a un dispositivo a realizar acciones que incluyen: recibir un estado de conexión para una conexión; inyectar el estado de conexión para la conexión a una pila de red; y continuar la conexión usando el estado de conexión inyectado.

En una segunda implementación ilustrativa de medios, uno o más medios accesibles por procesador incluye instrucciones ejecutables por procesador que, cuando se ejecutan, dirigen a un dispositivo para realizar acciones que incluyen: obtener por lo menor una porción de untar de fuente/destino de un paquete de entrada; tener acceso a una tabla de mapa de encapsulación utilizando por lo menos la porción obtenida del par de fuente/destino para ubicar una entrada de mapa de encapsulación; extraer un ¡dentificador de flujo de la entrada de mapa de encapsulación localizada; y reemplazar parte del paquete de entrada con el identif icador de flujo extraído para producir un paquete encapsulado. En una segunda implementación ilustrativa de dispositivo, un dispositivo incluye: un tunelista que está configurado para tunelizar paquetes hacia el dispositivo; el tunelista teniendo acceso a una tabla de mapa de encapsulación, la tabla de mapa de encapsulación incluyendo una pluralidad de entradas de mapa de encapsulación, cada entrada de mapa de encapsulación enlazando un ¡dentificador de flujo a por lo menos una porción de un par de fuente/destino; el tunelista adaptado para aceptar un paquete encapsulado que tiene un ¡dentificador de flujo particular; el tunelista capaz de ver un par de fuente/destino particular en una entrada de mapa de encapsulación particular utilizando el ¡dentificador de flujo particular; en donde el tunelista además está adaptado para desencapsular el paquete encapsulado reemplazando al ¡dentificador de flujo particular con por lo menos parte del par de fuente/destino particular. En la presente se describen otro método, sistema, aspecto, aparato, interfase de programación de aplicación (API), dispositivo, medios, disposición, etc., implementaciones.

BREVE DESCRIPCION DE LOS DIBUJOS Los mismos números se utilizan a través de los dibujos para hacer referencia a aspectos, características y componentes similares y/o correspondientes. La Figura 1 es un paradigma de equilibrio de carga de red ilustrativo que muestra una infraestructura de equilibrio de carga y múltiples huéspedes. La Figura 2 es un paradigma de equilibrio de carga de red ilustrativo que muestra múltiples unidades de equilibrio de carga y múltiples huéspedes. La Figura 3 ilustra una unidad de equilibrio de carga ilustrativa que tiene una funcionalidad separada y un huésped ilustrativo. La Figura 4 ¡lustra una infraestructura de equilibrio de carga de red ilustrativa que tiene funcionalidad separada de clasificación y de envío. La Figura 5 es un diagrama de flujo que muestra un método ilustrativo para escalar la infraestructura de equilibrio de carga de red a diferentes configuraciones. La Figura 6 ilustra una primera configuración de infraestructura de equilibrio de carga de red ilustrativa desde una perspectiva de dispositivo. La Figura 7 muestra una segunda configuración de infraestructura de equilibrio de carga de red ilustrativa a partir de una perspectiva de dispositivo. Las Figuras 8A y 8B muestran las primera y segunda configuraciones de infraestructura de equilibrio de carga de red ilustrativas a partir de una perspectiva de componente. Las Figuras 9A y 9B ilustran las primera y segundas configuraciones de infraestructura de equilibrio de carga de red ilustrativas a partir de una perspectiva de recursos. La Figura 10 ilustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de estado huésped. La Figura 11 es un diagrama de flujo que muestra un método ilustrativo para el equilibrio de carga de red involucra información de estado huésped. La Figura 12 muestra un aspecto de equilibrio de carga de red ilustrativo que involucra información de salud y de carga. La Figura 13A es una tabla de salud y carga ilustrativa como se muestra en la Figura 12. La Figura 13B es una memoria caché de salud y carga consolidada ilustrativa como se muestra en la Figura 12. La Figura 14 es un diagrama de flujo que muestra un método ilustrativo para el equilibrio de cara de red que involucra información de salud y carga.

La Figura 15 ilustra un protocolo de mensaje ilustrativo para comunicaciones entre los huéspedes y las unidades de equilibrio de carga que se muestran en la Figura 12. La Figura 16 ilustra un esquema de transmisión de mensaje ilustrativo para comunicaciones entre los huéspedes y las unidades de equilibrio de carga que se muestran en la Figura 12. Las Figuras 17A y 17B muestran escenarios de almacenamiento proxi de información de salud y carga ilustrativos para tablas de salud y de carga de la Figura 13A y para memorias caché de salud y carga consolidadas de la Figura 13B, respectivamente. La Figura 18 ilustra un procedimiento de distribución de huésped objetivo ilustrativo que utiliza información de salud y de carga. La Figura 19 ilustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de sesión. La Figura 20 ¡lustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de sesión de comunicación utilizando notificaciones y mensajes. La Figura 21 es un diagrama de flujo que muestra un método ilustrativo para el equilibrio de carga de red que involucra información de sesión de comunicación utilizando notificaciones y mensajes. La Figura 22 muestra un aspecto ilustrativo para administrar información de sesión en múltiples unidades de equilibrio de carga. La Figura 23A es una tabla de sesión ilustrativa como se muestra en la Figura 20. La Figura 23B es una tabla de administrador de átomo distribuida (DAM) ilustrativa (DAMT) como se muestra en la Figura 22. La Figura 24 es un diagrama de flujo que muestra un método ilustrativo para administrar información de sesión en múltiples unidades de equilibrio de carga. La Figura 25 muestra una infraestructura de equilibrio de carga de red ilustrativa que tiene funcionalidad de enrutamiento de solicitud. La Figura 26 es un diagrama de flujo que ilustra un método ilustrativo para enrutar paquetes de entrada con respecto a (i) información de sesión y (ii) información de salud y carga. La Figura 27 ilustra un flujo de enrutamiento de tráfico en ausencia de fallas. La Figura 28 ilustra un flujo de enrutamiento de tráfico ilustrativo en presencia de falla(s). La Figura 29 muestra procedimientos de falla para una alta disponibilidad de la infraestructura de equilibrio de carga de red. La Figura 30 muestra una implementación operacional ilustrativa de la interacción de enrutamiento de tráfico con información de salud y carga. La Figura 31 muestra mecanismos de alta disponibilidad ilustrativos para la infraestructura de equilibrio de carga de red. La Figura 32 muestra un aspecto ilustrativo del equilibrio de carga de red de nivel de aplicación con migración de conexión. La Figura 33 es un diagrama de flujo que ilustra un método ilustrativo para emigrar una conexión de un primer dispositivo hacia un segundo dispositivo. La Figura 34 ilustra un aspecto ilustrativo para la migración de conexión desde la perspectiva de un dispositivo de origen. La Figura 35 muestra un aspecto ilustrativo para la migración de conexión a partir de la perspectiva de un dispositivo objetivo. La Figura 36 ilustra un aspecto ilustrativo de un procedimiento de descarga para una migración de conexión. La Figura 37 muestra un aspecto ilustrativo para un procedimiento de carga para una migración de conexión. La Figura 38 muestra un aspecto ilustrativo a una tunelización de paquete entre un expedidor huésped. La Figura 39 es un diagrama de flujo que muestra un método ilustrativo para la tunelización de paquetes entre un primer dispositivo y un segundo dispositivo. La Figura 40 ilustra un ambiente de operación de cómputo ilustrativo (o dispositivo general) que es capaz de (total o parcialmente) implementar por lo menos un aspecto del equilibrio de carga de red como se describe aquí.

DESCRIPCION DETALLADA Paradigmas Ilustrativos de Equilibrio de Carga de Red Esta sección describe paradigmas o modelos ilustrativos el equilibrio de carga de red y se utiliza para proporcionar bases, ambientes, contextos, etc., para las descripciones en las siguientes secciones. Esta sección principalmente hacer referencia a las Figura 1-3. La Figura 1 es un paradigma de equilibrio de carga de red 100 ilustrativo que muestra una infraestructura de equilibrio de carga 106 y múltiples huéspedes 108. El paradigma de equilibro de carga de red 100 ilustrativo incluye múltiples cliente 102(1), 102(2) ... 102(m) y múltiples huéspedes 108(1), 108(2) ... 108(n), así como una red 104 y una infraestructura de equilibro de carga 106. Cada uno de los clientes 102 puede ser cualquier dispositivo que sea capaz de comunicación de red, tal como una computadora, una estación móvil, un aparato de entretenimiento, otra red, etc. Los clientes 102 también se pueden referir a una persona y/o entidad que esté operando como un dispositivo de cliente. En otras palabras, los clientes 102 pueden comprender clientes lógicos que son usuarios y/o máquinas. La red 104 puede se puede formar a partir de una o más redes, tales como el Internet, una Intranet, una red telefónica con cables o inalámbrica, etc. A continuación se describen ejemplos adicionales de dispositivos para clientes 102 y tipos/topologías de red para la red 104 haciendo referencia a la Figura 40 en la sección intitulada "Ambiente Operativo Ilustrativo Para La Computadora U Otro Dispositivo". Los clientes 102 individuales son capaces de comunicarse con uno o más huésped 108, y viceversa, a través de la red 104 mediante la infraestructura de equilibrio de carga 106. Los huéspedes 108 alojan una o más aplicaciones para la interacción/comunicación con los clientes 102, para utilizarse por los clientes 102, etc. Cada huésped 108 puede corresponder a un servidor y/o un dispositivo, múltiples servidores y/o múltiples dispositivos, parte de un servidor y/o parte de un dispositivo, alguna combinación de éstos, etc. Las implementaciones particulares para los huéspedes 108 se describen más adelante en el contexto de diferentes situaciones de equilibrio de carga de red. (Sin embargo, el soporte de extremo posterior para huéspedes 108 generalmente no se muestra por claridad). Además, otros ejemplos adicionales de dispositivos para huéspedes 108 también se describen más adelante con referencia a la Figura 40 en la sección intitulada "Ambiente de Operación Ilustrativo para la Computadora u Otro dispositivo". La infraestructura de equilibrio de carga 106 se puede alcanzar o se puede localizar a través de la red 104 en una o más direcciones de protocolo Internet (IP) virtuales. Las comunicaciones de los clientes 102 (u otros nodos) que son dirigidas a la dirección IP virtual de la infraestructura de equilibrio de carga 106 son recibidas ahí y enviadas a un huésped 108. La infraestructura de equilibrio de carga 106 está compuesta de componentes de hardware y/o software (no explícitamente mostrados en la Figura 1). Aunque la infraestructura de equilibrio de carga se muestra como una elipse integral, la infraestructura para efectuar el equilibrio de carga también puede ser distribuida a otros aspectos del paradigma de equilibrio de carga de red 100 ilustrativo. Por ejemplo, los componentes de software de la infraestructura de equilibrio de carga 106 pueden ser localizados en uno o más de los huéspedes 108 como se describe más adelante. Ejemplos de arquitecturas para la Infraestructura de equilibrio de carga 106 se describen más delante con referencia a la Figura 40 en la sección intitulada "Ambiente de Operación Ilustrativo para Computadora u Otro Dispositivo". Como se Indicó en (1), uno o más de los huésped 108 pueden proporcionar información de estado huésped de los huéspedes 108 para la infraestructura de equilibrio de carga 106. Esta información de estado huésped puede ser de aplicación específica. Ejemplos de dicha información de estado huésped se describe más adelanta e incluyen información de salud y/o carga, información de sesión, etc., para los huéspedes 108. Una implementaclón particular que incluye proporcionar información de salud y/o carga de los huéspedes 108 a la infraestructura de equilibrio de carga 106 se describe más adelante en la sección intitulada "manejo de salud y carga ilustrativo". En (2), se envía una solicitud del cliente 102 (1) a través de la red 104 a la infraestructura de equilibrio de carga 106 en su dirección de IP virtual. El contenido, formato, etc, de una solicitud de un cliente 102 dependen de la aplicación a la cual está dirigida la solicitud, y el término "solicitud" implícitamente puede incluir una respuesta o respuestas de huésped(es) 108, dependiendo del contexto. Los tipos de solicitudes de cliente incluyen, pero no se limitan a: 1. Solicitudes de OBTENER protocolo de transferencia de hipertexto (HTTP) de un cliente que utiliza un programa navegador. Dependiendo de la aplicación (y más específicamente, del localizador uniforme de recursos (URL) de las solicitudes), puede ser mejor darle servicio a las solicitudes a través de diferentes grupos de huéspedes, y la existencia de un estado de "sesión" de cliente en los huéspedes puede reforzar esas solicitudes de clientes específicos que serán enrutados a huéspedes específicos. Las solicitudes pueden ser a través de una conexión de capa de receptáculos segura (SSL) (o de otra manera codificada). 2. - Las conexiones de red privada virtuales (VPN) (por ejemplo, los huéspedes están en un grupo de servidores de VPN). En este caso, la "solicitud" puede ser considerada como una conexión de protocolo de tunelización de dos capas (L2TP) o de protocolo de tunelización de punto a punto (PPTP) (el último es una combinación de una conexión de control de protocolo de control de transmisión (TCP) y tráfico de datos de encapsulacion de enrutamiento genérico asociado (GRE). 3. - Conexiones terminales de servidor (por ejemplo, los huéspedes son un grupo de servidores terminales". 4. - Solicitudes de propietario en la forma de conexiones de TCP individuales (una por solicitud) empleado un protocolo de aplicación específica de propietario. 5. - Solicitudes simples de protocolo de acceso a objeto (SOAP). 6. - Solicitudes de comunicación de tiempo real que involucran información de control a través de una conexión de TCP y medios sensibles a la latencia que corren a través del protocolo de tiempo real (RTP) De esta manera, las solicitudes pueden tener muchas diversas formas de aplicación específica. En ciertas implementaciones descritas, la infraestructura de equilibrio de carga 106 puede hacer decisiones de envío de aplicación específica. En (3), la infraestructura de equilibrio de carga 106 envía la solicitud de 102 (1) al huésped 108 (2) (en este ejemplo). La infraestructura de equilibrio de carga 106 puede considerar uno o más de muchos factores cuando se selecciona un huésped 108 al cual se va a enviar la solicitud, dependiendo de que implementaciones descritas aquí se van a emplear. Por ejemplo, la infraestructura de equilibrio de carga 106 puede tomar en cuenta: la información de salud y/o carga de la aplicación de cada huésped 108, la información de sesión con relación a clientes 102 (1) según almacenada en un huésped 108, etc. La Figura 2 es un paradigma de equilibrio de carga de red ilustrativo 200 que muestra múltiples unidades de equilibro de carga 106 y múltiples huéspedes 108. Específicamente, la infraestructura de equilibrio de carga 106 se muestra como múltiples unidades de equilibrio de carga 106(1), 106(2) ... 106(u) en el paradigma de equilibrio de carga de red 200 ilustrativo. Además, se ilustran dos enrutadores y/o conmutadores 202 (1 ) y 202 (2). El enrutador/conmutadores 202, si están presentes, se pueden considerar como parte de o separados de la infraestructura de equilibrio de carga 106 (de la Figura 1). El enrutador/conmutadores 202 son responsables de dirigir todas las solicitudes y paquetes individuales que son recibidas de la red 104 a la dirección(es) de IP virtual (VIP) compartidas de las unidades de equilibrio de carga 106. Si un primer enrutador/conmutador 202 falla, el segundo enrutador/conmutador 202 puede tomar el primero. Aunque se ilustran dos enrutadores/conmutadores 202, alternativamente se pueden emplear más de dos enrutadores/conmutadores 202. El enrutador/conmutadores 202 pueden ser ignorantes de la infraestructura de equilibrio de carga o estar al pendiente del equilibrio de carga. Si el enrutador/conmutadores 202 no están al pendiente del equilibrio de carga, una de las dos opciones ilustrativas puede ser empleada: para una primera opción, una unidad de equilibrio de carga 106 es "asignada" a la dirección de VIP compartida, y todo el tráfico de la red es enviado a ésta. Esta única unidad de equilibrio de carga 106 después finalmente vuelve a distribuir el tráfico a través de las otras unidades de equilibrio de carga 106. Sin embargo, existen emisiones de cuello de botella y de falla con esta primera opción (la cual puede ser mitigada si múltiples direcciones de VIP son compartidas y son divididas entre múltiples unidades de equilibrio de carga 106). Para una segunda opción, el enrutador/conmutadores 202 son "enviados por engaño" a dirigir el tráfico de red para todas las unidades de equilibrio de carga 106, que deciden individualmente que tráfico deben aceptar cada una para el equilibrio de carga. Sin embargo, existen emisiones de duplicación de esfuerzo y funcionamiento/compatibilidad de conmutador ineficientes con esta segunda opción. Por otro lado, si el enrutador/conmutadores 202 están pendientes del equilibrio de carga, el enrutador/conmutadores 202 pueden hacerse para distribuir el tráfico de red de entrada entre múltiples de unidades de equilibrio de carga 106 (por ejemplo, en una forma de circuito cíclico). Se debe entender que dichos enrutadores/conmutadores 202 que están al pendiente del equilibrio de carga son capaces de realizar funciones de equilibrio de carga a un nivel rudimentario (por ejemplo, en hardware). Por ejemplo, los enrutadores/conmutadores 202 que están al pendiente del equilibrio de carga pueden realizar una simple afinidad de sesión a base de dirección de IP, de manera que todos los paquetes de una dirección de IP de fuente específica son dirigidos a una misma unidad de equilibrio de carga 106. Cada unidad de equilibrio de carga 106 ilustrada en forma separada de las unidades de equilibrio de carga 106, puede representar un dispositivo físico, múltiples dispositivos físicos, o parte de un solo dispositivo físico. Por ejemplo, unidad de equilibro de carga 106 (1) puede corresponder a un servidor, dos servidores, o más. Alternativamente, la unidad de equilibrio de carga 106 (1) y la unidad de equilibrio de carga 106 (2) en conjunto pueden corresponder a un solo servidor. Una unidad de equilibrio de carga 106 ilustrativa se describe más adelante a partir de una perspectiva funcional con referencia a la Figura 3. En la Figura 2 se ilustran dos trayectorias de solicitud ilustrativas [1] y [2]. Para la trayectoria de solicitud [1], el cliente 102 (2) transmite una solicitud a través de la red 104 que llega al enrutador/conmutador 202 (1). El enrutador/conmutador 202 (1 ) dirige el paquete(s) de la solicitud que se originó del cliente 102 (2) a la unidad de equilibrio de carga 106 (1). La unidad de equilibrio de carga 106 (1) después envía el paquete(s) de la solicitud al huésped 108 (1) de acuerdo con alguna funcionalidad de equilibrio de carga (por ejemplo, política). Para la trayectoria de solicitud [2], el cliente 102 (m) transmite una solicitud a través de la red 104 que llega al enrutador/conmutador 202 (2). El enrutador/conmutador 202 (2) dirige el paquete(s) de la solicitud que se originó del cliente 102 (m) a la unidad de equilibrio de carga 106 (u). La unidad de equilibrio de carga 106 (u) después envía el paquete(s) de la solicitud del huésped 108 (n) de acuerdo con alguna funcionalidad de equilibrio de carga. La funcionalidad de equilibrio de carga ilustrativa se describe más adelante con referencia a la Figura 3. La Figura 3 ilustra una unidad de equilibrio de carga 106 ilustrativa que tiene funcionalidad separada y un huésped ilustrativo 108. La unidad de equilibrio de carga 106 incluye siente (7) bloques funcionales 302-314. Estos bloques funcionales de la unidad de equilibrio de carga pueden ser realizados por lo menos parcialmente utilizando software. El huésped 108 incluye una o más aplicaciones 316. En una implementación descrita, la unidad de equilibrio de carga 106 incluye un expedidor 302, un clasificador 604, un enrutador de solicitud 306, un rastreador de sesión 308, un emigrante de conexión 310, un tunelista 312, y un manejador de salud y carga 314. El manejador de salud y carga 314 está ubicado parcialmente en los huéspedes 108 y parcialmente los dispositivos de las unidades de equilibrio de carga 106. El manejador de salud y carga 314 verifica la salud y/o carga (o más generalmente el estado) de los huéspedes 108, de manera que su información de salud y/o carga se puede utilizar para la funcionalidad de equilibrio de carga (por ejemplo, cuando se hacen decisiones de equilibrio de carga. Las implementaciones ilustrativas para el manejador de salud y carga 314 se describen más adelante, particularmente en la sección intitulada "Manejo de Salud y Carga Ilustrativo". El rastreador de sesión 308 también puede ser ubicado parcialmente en los huéspedes 108 y parcialmente en los dispositivos de las unidades de equilibrio de carga 106. El rastreador de sesión 308 verifica las sesiones que son establecidas por los clientes 102, de manera que las reconexiones/continuaciones de sesiones previamente establecidas pueden ser facilitadas por la funcionalidad de equilibrio de carga. Por ejemplo, algunas aplicaciones mantienen datos de sesión de cliente de aplicación específica en los huéspedes (lo cual también es un tipo de información de estado de huésped). Estas aplicaciones típicamente esperan que los clientes utilicen el mismo huésped durante el término de cualquier sesión dada. Los tipos ilustrativos de sesiones incluyen: (i) una conexión de TCP (la cual es, estrictamente hablando, una sesión); (¡i) una sesión SSL; (iii) una sesión de IP segura (IPsec), (iv) una sesión a base de galleta de HTPP; y así sucesivamente. Aunque el rastreador de sesión 308 se ilustra como un bloque discreto en la unidad de equilibrio de carga 106, la funcionalidad de rastreo de sesión del rastreador de sesión 308 en realidad puede ser implementada a un nivel global. En otras palabras, la afinidad de sesión es soportada a través de las múltiples unidades de equilibrio de carga 106. El rastreador de sesión 308 incluye una base de datos centralizada y/o una base de datos distribuida de información de sesión con el fin de conservar la afinidad de sesión. Las implementaciones ilustrativas para el rastreador de sesión 308, con un énfasis en un aspecto de base de datos distribuido, se describen más adelante, particularn ente en la sección intitulada "Rastreo de Sesión Ilustrativo". El clasificador 304 utiliza los datos adquiridos y mantenidos por el manejador de salud y carga 314 y/o el rastreador de sesión 308, posiblemente junto con otros factores, para clasificar solicitudes de entrada. En otras palabras, un clasificador 304 selecciona un huésped objetivo 108 para cada solicitud de entrada de un cliente 102. El expedidor 302 envía solicitudes del cliente (y/o sus paquetes) de acuerdo con el huésped 108 objetivo según seleccionado por el clasificador 304. El expedidor 302 y clasificador 304 pueden operar en una base por paquete. Las implementaciones ilustrativas para el expedidor 302 y clasificador 304 se describen más adelante, particularmente en las secciones intituladas "Aspectos Ilustrativo para Equilibrio de Carga de Red Flexible" y "Clasificación, Envío y Enrutamiento de Solicitud, Ilustrativos". El enrutador de solicitud 306, en contraste con las implementaciones por paquete del expedidor 302 y clasificador 304, puede actuar como un proxi para una aplicación que corre en un huésped 108. Por ejemplo, en enrutador de solicitud 306 puede terminar conexiones de TCP, analizar (por lo menos parcialmente) cada solicitud lógica de un cliente 102, y volver a presentar cada solicitud lógica al huésped 108 objetivo. Consecuentemente, cada solicitud lógica de un cliente 102 puede ser dirigida a un huésped 108 diferente, dependiendo de las escisiones hechas por el enrutador de solicitud 306. Además, el enrutador de solicitud 306 puede realizar pre-procesamiento en una conexión (por ejemplo, descodificación críptica de SSL) o puede elegir absorber ciertas solicitudes (por ejemplo, ya que el enrutador de solicitud 306 mantiene una memoria caché de respuesta), arbitrariamente puede modificar solicitudes antes de enviarlas a los huéspedes 108, etc. Las implementaciones ilustrativas para el enrutador de solicitud 306 también se describen más adelante, en particular en las secciones intituladas "Aspecto Ilustrativo al Equilibro de Carga de Red Flexible" y "Clasificación, Envío, Y Enrutamiento De Solicitudes, Ilustrativos".

El emigrante de conexión 310 permite que una conexión sea inicialmente terminada en la unidad de equilibro de carga 106 y después emigre, de manera que la conexión subsecuentemente termine en el huésped 108. Esta migración de conexión puede facilitar el equilibrio de carga de nivel de aplicación. El emigrante de conexión 310 es capaz de emigrar una conexión de la unidad de equilibrio de carga 106 a un huésped 108, de tal manera que la terminación original en la unidad de equilibrio de carga 106 es transparente a un cliente 102 que solicita y a aplicaciones 306 del huésped 108 que recientemente termina. El tunelista 312 puede utilizar un esquema de encapsulación para la tunelización de paquetes que no introducen una carga general a cada paquete de túnel. La funcionalidad del tunelista 312 también se puede utilizar en situaciones que no involucran una migración de conexión. Además, el emigrante de conexión 310 y/o tunelista 312 además se puede utilizar en implementaciones de equilibrio que no son de carga. Las implementaciones ilustrativas para el emigrante de conexión 310, así como para el tunelista 312, se describen más adelante, en particular en la sección intitulada "Migración de Conexión Ilustrativa con Tunelización Opcional y/o Equilibrio de Carga de Nivel de Aplicación". Cualquier implementación de una unidad de equilibrio de carga 106 puede incluir una o más de las funciones ilustradas. Aunque se ilustra en forma separada, cada una de las funciones de los bloques 302-314 en realidad pueden ser interrelacionadas con, traslaparse con, y/o ser inclusivas de otras funciones. Por ejemplo, la información de salud y/o carga del manejador de salud y carga 314 se puede utilizar el clasificador 304. También, el emigrante de conexión 310 y el tunelista 312 trabajan en conjunto con el expedidor 302 y clasificador 304. Ciertas otras interacciones y traslapantes ilustrativos se describen más adelante. En una implementación descrita, el huésped 108 corre y proporciona acceso a una o más aplicaciones 316. En general, las aplicaciones 316 incluyen programas de entrega de archivo, programas de administración de sitio web/servidor, programas de acceso remoto, programas de correo electrónico, programas de acceso de base de datos, etc. Específicamente, las aplicaciones 316 pueden incluir, pero no se limitan a, servidores web tales como Internet Information Server® (US) de Microsoft® Corporation, servidores terminales tales como Microsoft® Terminal Server™, y productos de pared de fuego y proxi tales como Internet Security and Acceleration Server™ (ISA). Aunque los ejemplos específicos de la aplicación 316 en la oración precedente se refieren a productos de Microsoft™, el equilibrio de carga de red como se describe aquí no está limitado a ningún vendedor particular, aplicación o sistema operativo.

Aspecto Ilustrativo para Equilibrio de Carga de Red Flexible Esta sección ilustra como las implementaciones de equilibrio de red descritas aquí y en otras secciones proporcionan un aspecto flexible al equilibrio de carga de red. Esta sección principalmente hace referencia a las Figuras 4-9B. Como se observó anteriormente, la funcionalidad de equilibrio de carga de red puede ser escalada reemplazando un primer equilibrador de carga de red con un segundo equilibrador de carga de red más grande y más potente. Las capacidades de hardware del segundo equilibrador de carga de red replican todas las capacidades de hardware del primer equilibrador de carga de red, excepto que se proporciona una capacidad mayor. Esto es un aspecto inflexible que puede ser muy ineficiente, en especial cuando solamente un aspecto de equilibrio de carga de red está limitando el funcionamiento y precipitando una actualización de un equilibrador de carga de red. La Figura 4 muestra una infraestructura de equilibrio de carga de red ilustrativa que tiene funcionalidad separada de clasificación y de envío. Las funcionalidades separadas de clasificación y envió están representadas por el clasificador 304 y el expedidor 302, respectivamente. Aunque las funciones de clasificación y de envío se describen más adelante, especialmente en la sección intitulada "Clasificación, Envío y Enrutamiento de Solicitud Ilustrativo", se presenta una descripción inicial aquí como un ejemplo de interacción entre la funcionalidad e infraestructura de carga de red y los huéspedes 108.

En una implementación descrita, el expedidor 302 corresponde a, y es el punto extremo de la red para la dirección (o direcciones) de IP virtuales (VIP). El expedidor 302 es un componente de nivel relativamente bajo que hace decisiones de política simplificadas y/o elementales, si hay alguna, cuando enruta paquetes a un destino adicional o final. El expedidor 302 consulta una tabla de enrutamiento para determinar este destino. El clasificador 304 puebla la tabla de enrutamiento basándose en uno o más factores (por ejemplo, información de estado de huésped), los cuales se describen más adelante en otras secciones aquí. Los clientes 102 y huéspedes 108 también corresponden a direcciones de red indicadas. Específicamente, el cliente 102 (1) corresponde a la dirección C1, el cliente 102 (2) corresponde a la dirección C2 el cliente 102 (m) corresponde a la dirección Cm. También, el huésped 109 (1) corresponde a la dirección H1, el huésped 108 (2) corresponde a la dirección H2 el huésped 108 (n) corresponde a la dirección Hn. En la Figura 4 se muestran 5 trayectorias de comunicación (1)-(5). La trayectoria de comunicación (1) es entre el cliente 102 (1) y el expedidor 302, y la trayectoria de comunicación (5) es entre el expedidor 302 y el huésped 108 (1). Las trayectorias de comunicación (2)-(4) son entre el expedidor 302 y clasificador 304. Para simplificar este ejemplo, la conexión asociada con las trayectorias de comunicación (1)-(5) es una conexión de TCP HTTP. Además, el equilibrio de carga en este ejemplo se refiere al enrutamiento de conexiones de entrada a por lo menos el huésped cargado 108, por lo menos sin ninguna consideración explícita de equilibro de carga de nivel de aplicación. Las trayectorias de comunicación (1)-(5) indican como el expedidor 302 y el clasificador 304 equilibran la carga de una conexión de TCP de HTTP individual de cliente 102 (1). En (1), el cliente 102 (1) inicia la conexión de TCP enviando un paquete de SYN de TCP dirigido a la dirección de VIP. La infraestructura de enrutamiento de la red 104 enruta este paquete al expedidor 302 a través del enrutador/conmutador 202 (1), el cual es el enrutador/conmutador 202 "más cercano" al expedidor 302. En (2), el expedidor 302 consulta una tabla de enrutamiento, la cual puede ser interna al expedidor 302 o de otra manera accesible del mismo, con el fin de buscar esta conexión. Esta conexión puede ser identificada en la tabla de enrutamiento a través de la 4-tupla (registro) de TCP/IP (es decir, dirección de IP fuente, puerto de TCP fuente, dirección de IP de destino, puerto de TCP de destino). Ya que este es primer paquete de la conexión, no hay ninguna entra en la tabla de enrutamiento. El expedidor 302, por lo tanto, aplica la acción de "ruta por omisión', la cual va a enviar este paquete al clasificador 304. En (3), el clasificador 304 consulta su memoria caché (por ejemplo, consolidada) de la información de estado huésped para los huéspedes 108 (1 ), 108 (2) ... 108(n). El clasificador 304 concluye que el huésped 108 (1) está disponible y el último huésped 108 está cargado en este instante para este ejemplo. El clasificador 304 también "aploma" una ruta en la tabla de enrutamiento consultada por el expedidor 302 para esta conexión de TCP. Por ejemplo, el clasificador 304 agrega una entrada de ruta o instruye al expedidor 302 a agregar una entrada de ruta a la tabla de enrutamiento que diseña la conexión de TCP (por ejemplo, identificada por la 4-tupla de TCP) a un huésped de destino específico 108, el cual es el huésped 108 (1) en este ejemplo. Más particularmente, la entrada de ruta especifica la dirección de red de H1 del huésped 108 (1). En (4), el clasificador 304 envía el paquete de SYN de TCP de regreso al expedidor 302. Alternativamente, el clasificador 304 puede enviar este paquete de SYN y el TCP inicial al huésped 108 (1) sin utilizar el expedidor 302. Otras opciones disponibles al clasificador 304 se describen más adelante. En (5), el expedidor 302 puede tener acceso a una entrada de ruta para la conexión representada por el paquete SYN, de manera que envía el paquete al huésped 108 (1) en la dirección H1. el expedidor 302 también envía todos los paquetes subsecuentes del cliente 102 (1) para esta conexión directamente al huésped 108 (1). En otras palabras, el expedidor 302 puede evitar la interacción adicional con el clasificador 304 para esta conexión. Uno o una combinación de mecanismos, los cuales se describen más adelante, se pueden utilizar para eliminar la entrada de ruta cuando la conexión cesa. Para la trayectoria de comunicación (5) en muchos ambiente de protocolo, el expedidor 302 no puede simplemente enviar los paquetes de cliente 102 (1) como tales al huésped 108 (1) en la dirección de red H , ya que estos paquetes están dirigidos a la dirección de VIP, la cual está alojada por el mismo expedidor 302. Más bien, el expedidor 302 puede emplear una o más de las siguientes opciones ilustrativas: 1. El expedidor 302 realiza la Traducción de Dirección de Red (NAT), (i) sobrescribiendo la dirección de IP huésped (cliente 102 (1)) (C1) y el número de puerto con la dirección de IP y el número de puerto generado por NAT del expedidor 302, y (ii) sobrescribiendo la dirección de IP de destino (VIP) con la dirección de IP (H1) del huésped (108 (1)). 2. El expedidor 302 realiza una "NAT Media" sobrescribiendo la dirección de IP de destino (VIP) con la dirección de IP (H1) del huésped (108 (1)), de manera que la dirección de IP fuente (cliente 102 (1)) (C1) y el número de puerto se conserva. 3. - El expedidor 302 "tuneliza" los paquetes recibidos del cliente 102 (1) del expedidor 302 al huésped 108 (1). Específicamente en este ejemplo, la tunelización puede ser efectuada encapsulando cada paquete dentro de un nuevo paquete de IP que está dirigido al huésped 108 (1). El software que está al pendiente del equilibrio de cliente de red en el huésped 108 (1) reconstruye el paquete original como es recibido en el expedidor 302 del cliente 102 (1). Este paquete original después es indicado en una interfase virtual en el huésped 108 (1) (por ejemplo, la dirección de VIP que corresponde al expedidor 302 y está unidad a esta interfase virtual en el huésped 108 (1)). Las implementaciones ilustrativas de dicha tunelización se describen más adelante con referencia al tunelista 312, en especial para escenarios de migración de conexión y particularmente en la sección intitulada Migración de Conexión Ilustrativa con Tunelización Opcional y/o Equilibrio de Carga de Nivel de Aplicación". Aunque las Figura 4-9B muestran dos funciones separadas específicas, principalmente clasificar y enviar, se debe entender que otras funciones, tales como aquellas del enrutador de solicitud 306, rastreador de sesión 308, un emigrante de conexión 310 y manejador de salud y carga 314, también pueden ser escalados independientemente (por ejemplo, factorizados en forma independiente", como se describirá más adelante. Además, se debe observar que una o más de dos funciones pueden ser separadas y escaladas independientemente en diferentes momentos y/o simultáneamente. También, aunque TCP/IP se utilice para claridad en muchos ejemplos en estas y otras secciones, los principios de equilibrio de carga de red descritos aquí son aplicables a otros protocolos de transmisión y/o comunicación. En la forma ilustrativa de la Figura 4, las funciones de equilibrio de carga de red (tales como aquellas mostradas en la Figura 3) pueden ser separadas una de la otra para propósitos de escalabilidad. También pueden ser separados y duplicados en varias configuraciones para una disponibilidad incrementada. Las configuraciones ilustrativas para escalabilidad y/o disponibilidad se describen más adelante con referencia a las Figura 6-9B después de describir el método de la Figura 5. La Figura 5 es un diagrama de flujo 500 que ilustra un método ilustrativo para escalar una infraestructura de equilibrio de carga de red en diferentes configuraciones. El diagrama de flujo 500 incluye tres bloques 502-506. Aunque las acciones del diagrama de flujo 500 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, las Figuras 1-4 y 6-9B se utilizan en particular para ¡lustrar ciertos aspectos y ejemplos del método. En el bloque 502, la infraestructura de equilibrio de carga de red se opera en una primera configuración. Por ejemplo, cada configuración puede relacionarse con uno o más de una selección, proporción, y/o interrelación de diferentes funcionalidad de equilibrio de carga; un número de y/o tipos de diferentes dispositivos; una organización y/o una disposición de diferentes componentes; una distribución y/o asignación de recursos; etc. En el bloque 504, la infraestructura de equilibrio de carga de red está escalada. Por ejemplo, las funcionalidades de equilibrio de carga separadas pueden ser expandidas y/o concomitantemente contraída en una base individual y/o independiente. En el bloque 506, la infraestructura de equilibrio de carga de red escalada se opera en una segunda configuración. Como se observó anteriormente, un equilibrador de carga de red monolítico puede ser escalado incrementando la funcionalidad de equilibrio de carga de red en su totalidad suplantando el hardware de equilibrio de carga de red previo con hardware de equilibrio de carga de red más potente. En contradicción, la infraestructura de equilibrio de carga de red escalada puede permitir que las (sub-)funciones de equilibrio de carga de red sean escaladas individual y/o independientemente. También pueden permitir que las funciones de equilibrio de carga de red sean escaladas conjuntamente o en forma individual entre diferentes números de dispositivos. Más adelante se proporcionan ejemplos de escalada orientada a dispositivos, componentes y recursos. La Figura 6 ilustra una primera configuración de infraestructura de equilibrio de carga de red ilustrativa a partir de una perspectiva de dispositivo. En esta primera configuración de infraestructura de equilibrio de carga de red de dispositivo orientado, se ilustra en tres dispositivos 602 (1), 602 (2), y 602 (3). Sin embargo, alternativamente se pueden emplear uno, dos o más de tres dispositivos 502. Como se ilustra, un expedidor 302 (1 ), un clasificador 304 (1), y un huésped 108 (1) están residentes en y se ejecutan en el dispositivo 602 (1 ). Un expedidor 302 (2), un clasificador 304 (2), y un huésped 108 (2) están residentes en y se ejecutan en el dispositivo 602 (2). También, un expedidor 302 (3), un clasificador 304.(3), y un huésped 108 (3) están residentes en y se ejecutan en el dispositivo 602 (3). De esta manera, en esta primera configuración de infraestructura de equilibrio de carga de red del dispositivo orientado, un expedidor 302, clasificador 304 y huésped 108 respectivos están compartiendo los recursos de cada dispositivo 602 respectivo. Durante operación, los expedidores 302 son los puntos extremos de red para la dirección(es) de VIP. Cualquier clasificador 304 puede aplomar una ruta para una conexión a cualquier huésped 108, dependiendo de la información del estado del huésped. Por ejemplo, el clasificador 304 (2) puede aplomar una ruta para una nueva conexión de entrada del huésped 108 (3). De acuerdo con una nueva entrada de ruta para esta conexión, el expedidor 302 (2) envía paquetes subsecuentes al huésped 108 (3). En una configuración de infraestructura de equilibrio de carga de red de dispositivo orientado, alternativa, a la cual se puede escalar la primera ilustrada, se puede agregar un cuarto dispositivo 602 (4) (no explícitamente mostrado en la Figura 6) que incluye un expedidor 302 (4), un clasificador 304 (4), y un huésped 108 (4). Por otro lado, si la funcionalidad de clasificación suficiente ya está presente con los clasificadores 304 (1-3), pero una funcionalidad de envío adicional puede beneficiar el manejo de solicitud de los huéspedes 108, se puede agregar un cuarto dispositivo 602 (4) que incluye un expedidor 302 (4) y opcionalmente un huésped 108 (4). Para esta configuración escalada, otro clasificador 304 (1, 2 o 3) puede aplomar rutas para el expedidor 302 (4) a cualquiera de los huéspedes 108 (1, 2 o 3) y el huésped 108 (4) si está presente. La primera configuración de infraestructura de equilibrio de carga de red ilustrativa de dispositivo orientado de la Figura 6 especialmente puede ser apropiada para situaciones de alojamiento más pequeñas, en donde dispositivos separados para la infraestructura de equilibrio de carga de red no son técnica y/o económicamente importantes o viables. Sin embargo, a medida que las obligaciones de alojamiento se expanden a un número mayor (y/o una demanda mayor en el mismo número) de huéspedes 108 o si la carga de red en los huéspedes 108 es importante, la primera configuración de infraestructura de equilibrio de carga de red ilustrativa del dispositivo orientado puede ser escalada para adaptarse a esta expansión, como se representa por una segunda configuración de infraestructura de equilibrio de carga de red ilustrativa del dispositivo orientado de la Figura 7. La Figura 7 ilustra una segunda configuración de infraestructura de equilibrio de carga de red ilustrativa a partir de una perspectiva de dispositivo. En esta configuración de infraestructura de equilibrio de carga de red del dispositivo orientado, también se ilustran tres dispositivos 602 (1), 602 (2) y 602 (3). Otra vez, se pueden emplear alternativamente uno, dos, o más tres dispositivos 602. Como se ¡lustra, el expedidor 302 (1) y el clasificador 304 (1 ) están residentes en y se ejecutan en el dispositivo 602 (1 ). El expedidor 302 (2) y el clasificador 304 (2) están residentes en y se ejecutan en el dispositivo 602 (2). También, el expedidor 302 (3) y el clasificador 304 (3) están residentes en y se ejecutan en el dispositivo 602 (3). De esta manera, en esta segunda configuración de infraestructura de equilibrio de carga de red de dispositivo orientado, cada expedidor 302 y clasificador 304 respectivos no están compartiendo los recursos de cada dispositivo 602 respectivo con un huésped 108. Además, la infraestructura de equilibrio de carga de red puede se le puede dar servicio a través de cualquier número de huéspedes 108. Durante operación, los expedidores 302 otra vez están en los puntos extremos de la red para la dirección(es) de VIP. También, cualquier clasificador 304 puede aplomar una ruta para una conexión a cualquier huésped 108, dependiendo de la información de estado de huésped. Por ejemplo, el clasificador 304 (3) puede aplomar una ruta para una nueva conexión de entrada al huésped 108 (2). De acuerdo con una nueva entrada de ruta para esta conexión, el expedidor 302 (3) envía paquetes subsecuentes al huésped 108 (2).

De esta manera, la infraestructura de equilibrio de carga de red como se realiza en software, por ejemplo, puede ser escalada moviendo la infraestructura de equilibrio de carga de red (o una parte de la misma) de los dispositivos que están compartidos con los huéspedes 108 a los dispositivos que no están compartidos con los huéspedes 108. También, como se dijo anteriormente en la Figura 6, otro dispositivo 602 (4) puede ser agregado a la infraestructura de equilibrio de carga de red para proporcionar funcionalidad de envío, funcionalidad de clasificación adicional, funcionalidad adicional de ambos tipos, etc.

Las Figuras 8A y 8B ilustran primera y segunda configuraciones de infraestructura de equilibrio de carga de red ilustrativa a partir de una perspectiva de componentes. Como se ilustra, la primera configuración de infraestructura de equilibrio de carga de red ilustrativa en el componente orientado 800 incluye cuatro componentes. La segunda configuración de infraestructura de equilibrio de carga de red ilustrativa de componente orientado 850 incluye seis componentes. Una segunda configuración 850 alternativa incluye el séptimo componente como se indica por el bloque de lineas desvanecidas, que se describe más adelante. Específicamente, la primera configuración de infraestructura de equilibrio de carga de red ilustrativa de componente orientado 800 (o primera configuración 800) incluye, (i) dos expedidores 302 (1 ) y 302 (2) y (ii) dos clasificadores 304 (i) y 304 (2). La segunda configuración de infraestructura de equilibrio de carga de red ilustrativa de componente orientado 850 (o segunda configuración 850) incluye (i) cuatro expedidores 302 (1), 302 (2), 302 (3) y 302 (4) y (ii) dos clasificadores (304 (1) y 304 (2), De esta manera, la primera configuración 800 es escalada a la segundo configuración 850 agregando dos componentes, los cuales son componentes de envío en este ejemplo. En una implementación descrita, cada componente funcional relacionado con el equilibrio de carga de red respectivo corresponde a un dispositivo respectivo (no explícitamente mostrado en la Figura 8A u 8B). Sin embargo, cada componente alternativamente puede corresponder a parte de un dispositivo o más de un dispositivo. Por ejemplo, los expedidores 302 (1 ) y 302 (2) pueden ser distribuidos a través de tres dispositivos. O el expedidor 302 (1) y el clasificador 304 (1 ) puede corresponder a un primer dispositivo, y el expedidor 302 (2) y el clasificador 304 (2) pueden corresponder a un segundo dispositivo. Se agregan dos componentes funcionales relacionados con el equilibrio de carga de red para escalar la primera configuración 800 a la segunda configuración 850. Sin embargo, un componente (o más de dos) alternativamente puede ser agregado para escalar la infraestructura de equilibrio de carga de red. Además, dos o más tipos diferentes de componentes funcionales pueden ser escalados "simultáneamente". Por ejemplo, como se ilustra por el bloque de líneas desvanecidas, otro componente de clasificación (por ejemplo, clasificador 304 (3)) también puede ser agregado cuando se escala la primera configuración 800 a la segunda configuración 850. Además, la escala de dos o más diferentes tipos de componentes funcionales se puede realizar en proporciones similares (por ejemplo, equivalente) o diferentes entre sí. Como se ilustra, la adición de componentes de expedidor 302 (3) y 302 (4) aunque no la adición de ningún componente clasificador 304 o aunque la adición de un componente clasificador individual 304 (3), representan una escalada a proporciones diferentes. Sin embargo, dos componentes de clasificador 304 (3) y 304 (4) (el último de éstos no está explícitamente ¡lustrado en la Figura 8B) pueden ser agregados mientras que los dos componentes de expedidor 302 (3) y 302 (4) se agregan para una escalada a proporciones similares. Sin embargo, cada componente funcional relacionado con el equilibrio de carga de red individual puede consumir una cantidad diferente de recursos de infraestructura de equilibrio de carga de red disponibles, como se describe con referencia a las Figuras 9A y 9B. Las Figuras 9A y 9B ilustran primera y segunda configuraciones de infraestructura de equilibrio de carga de red ilustrativas a partir de una perspectiva de recursos. La primera configuración de infraestructura de equilibrio de carga de red ilustrativa de recursos orientados 900 (o primera configuración 900) incluye una primera distribución o asignación de recursos para una unidad de equilibrio de carga 106. Una segunda configuración de infraestructura de equilibrio de carga de red ilustrativa de recursos orientados 950 (o segunda configuración 950) incluye una segunda distribución de recursos para la unidad de equilibrio de carga 106. Como se ilustra, la primera configuración 900 incluye una distribución de recursos del 70%-30%, y una segunda configuración 950 incluye una distribución de recursos de 40%-60%. Dichos recursos puede incluir recursos de dispositivo totales (por ejemplo, el número dispositi o), recursos de procesamiento (por ejemplo, número de ciclos de procesador), recursos de memoria (por ejemplo, porción de memoria caché, memoria principal, etc.), recursos de achura de banda y/o interfase de red (por ejemplo, bits por segundo y/o tarjetas de interfase de red físicas (NJCs)), etc.

Específicamente para la primera configuración 900, el expedidor 302 consume un 70% de los recursos de la unidad de equilibrio de carga 106, mientras que el clasificador 304 consume un 30% de estos recursos. Después de volver a asignar durante un procedimiento de escalada para producir la segunda configuración 950, el expedidor 302 consume un 40% de los recursos de la unidad de equilibrio de carga 106, mientras que el clasificador 304 consume un 60% de estos recursos. En una situación ilustrativa, la primera configuración 900 puede facilitar un mejor rendimiento del equilibrio de carga de red cuando se están manejando menos transacciones más largas por los huéspedes asociados (no mostrado en las Figuras 9A y 9B), ya que la funcionalidad de clasificación se utiliza en la comunicación inicial para una conexión y se utiliza una funcionalidad de envío después. La segunda configuración 950, por otro lado, puede facilitar un mejor funcionamiento de equilibrio de carga de red cuando se están manejando más transacciones, más cortas por los huéspedes asociados, ya que la funcionalidad de clasificación se utiliza para un porcentaje mayor del número total de paquetes canalizados a través de la infraestructura de equilibrio de carga de red. En esta situación, si también se está empleando la funcionalidad de enrutamiento de solicitud, entonces el enrutador(es) 306 de solicitud también se le distribuye un porcentaje de recursos de cómputo totales. La distribución de recursos entre las tres funcionalidades se puede ajustar, mientras se manejan conexiones (por ejemplo, se ajustan "en el vuelo") dependiendo del consumo y/o déficits de recursos actuales. Como se indicó anteriormente con referencia a las Figuras 2 y 3, cada unidad de equilibrio de carga 106 puede corresponder a toda o a una parte de una infraestructura de equilibrio de carga total 106. Para cualquier unidad de equilibrio de carga física, lógica, o arbitrariamente definida o estipulada 106, sus recursos se pueden volver a distribuir durante un procedimiento de escalada. Más específicamente, una distribución entre diferentes funciones separadas con relación al equilibrio de carga de red de una unidad de equilibrio de carga 106 puede ser alterada en un procedimiento de escalada. Además, más de dos diferentes funciones, así como otras funciones relacionadas con el equilibrio de carga de red que no están específicamente ilustradas en las Figuras 9A y 9B, se les pueden asignar diferentes porcentajes de recursos. El porcentaje de recursos de sistema totales distribuidos a todas las funciones de equilibrio de carga también puede verse alterado en un procedimiento de escalada. Como un ejemplo de energía de procesamiento general, el porcentaje de la energía de procesamiento total que se dedica al equilibrio de carga puede ser gradualmente incrementado a medida que la cantidad de tráfico que necesita ser equilibrado en su carga se incrementa. El software de equilibrio de carga de red opcionalmente puede realizar la verificación para analizar y determinar si los recursos deben volver ha ser asignados. Por ejemplo, el software de equilibrio de carga de red puede verificar la utilización del procesador de diferentes funciones relacionadas por el equilibrio de carga de red. La reasignación real también opcionalmente puede ser realizada en forma automática por el software de equilibrio de carga de red en un modo fuera de línea o en linea. Se debe entender que una capacidad de escalada de la infraestructura de equilibrio de carga de red (por ejemplo, como se realizó parcialmente en software) como se describe aquí, puede referirse a diferentes instalaciones y no necesariamente a un cambio a una sola instalación. En un ejemplo de recursos orientados, la infraestructura de equilibrio de carga de red como se describe aquí, puede ser configurada de acuerdo con una distribución de recursos en un ambiente de instalación y puede ser configurada de acuerdo con otra distribución de recursos diferentes en otro ambiente de instalación teniendo diferentes parámetros operacionales. Además, las capacidades, características, opciones, etc., descritas anteriormente con respecto a la escalada también son aplicables para la "escalada". En otras palabras, los recursos dedicados a la infraestructura de equilibrio de carga de red (o sus sub-f unciones) también pueden ser reducidos.

Manejo Ilustrativo de Salud y Carga Esta sección describe cómo la información de estado de huésped, tal como la información de salud y/o carga, puede ser reunida y utilizada en el equilibrio de carga de red. Esta sección principalmente hace referencia a las Figuras 10-18 e ilustra la funcionalidad de salud y carga de manera que se proporciona a través de un manejador de salud y carga 314 (de la Figura 3). Como se describió anteriormente con referencia a la Figura 3, cada huésped 108 aloja una o más aplicaciones 316. El manejador de salud y carga 314 utiliza información salud y/o carga que se refiere a aplicaciones 316 y/o huéspedes 108 para ciertas implementaciones descritas del equilibrio de carga de red. La Figura 10 ilustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de estado de huésped (HSI) 1006. Cada huésped 108 (1), 108 (2) ... 108 (n) incluye una o más aplicaciones 316 (1), 316 (2) ... 316 (n), respectivamente. Estos huéspedes 108 generalmente y estas aplicaciones 316 específicamente pueden cambiar los estados de vez en cuando. Por ejemplo, los huéspedes 108 y las aplicaciones 316 pueden estar aceptando nuevas conexiones o no aceptar nuevas conexiones. También, pueden manejar rápidamente solicitudes de cliente o manejar lentamente solicitudes de cliente. Además, pueden tener muchos recursos en reserva o pocos recursos no usados. Todos o cualquier parte de estos datos, u otros datos, pueden comprender información de estado de huésped 1006. En general, la información de estado de huésped 1006 proporciona una indicación del estado de cierto aspecto de los huéspedes 108 y/o aplicaciones 316 que están corriendo en el mismo. En una implementación descrita, cada huésped 108 (1), 108 (2) ... 108 (n) incluye un determinador 1002 (1 ), 1002 (2) ... y (1002 (n) de información de estado de huésped (HSI), respectivamente. Cada huésped 108 (1), 108 (2) ... 108 (n) también incluye un diseminador 1004 (1 ), 1004 (2) ... y 1004 (n) de información de estado de huésped (HSI), respectivamente. Cada determinador 1002 de información de estado de huésped y/o diseminador 1004 de información de estado de huésped puede ser parte de la infraestructura de equilibrio de carga (LBI) 106. Cada determinador 1002 de información de estado de huésped determina la información de estado de huésped 1006 para su huésped 108 respectivo y/o aplicaciones 316 respectivas, que están corriendo en el mismo. A continuación haciendo referencias 12-14 y particularmente a la Figura 13A, se describen técnicas ilustrativas para determinar dicha información de estado de huésped 1006. Cada diseminador 1004 de información de estado de huésped disemina la información de estado de huésped 1006 para su huésped 108 y/o aplicaciones 316 respectivas a la infraestructura de equilibrio de carga 106 (por ejemplo, aquellas porciones de la infraestructura de equilibrio de carga 106 que no están ubicadas en los huéspedes 108). Las técnicas ilustrativas para diseminar dicha información de estado de huésped 1006 se describen más delante con referencia a las Figuras 12-17, y en particular las Figuras 13B y 15-17. Específicamente, cada diseminador 1004 de información de estado de huésped disemina la información de estado de huésped 1006 (directa o indirectamente) a cada unidad de equilibrio de carga (LBU) 106 de la infraestructura de equilibrio de carga 106 que incluye por lo menos un manejador de salud y carga 314 y/o clasificador 304. La infraestructura de equilibrio de carga 106 se refiere a la información de estado de huésped 1006 cuando se implemente el equilibrio de carga de red. Por ejemplo, como se indica por la lógica 1008, la infraestructura de equilibrio de carga 106 es capaz de hacer decisiones de equilibrio de carga en respuesta a la información de estado de huésped 1006. Durante la operación en (1), los determinadores 1002 de información de estado de huésped determina la información de estado de huésped 1006 para los huéspedes 108 y/o aplicaciones 316 respectivas. En (1) y (2), los diseminadores 1004 de información de estado de huésped diseminan la información de estado de huésped 1006 de los huéspedes 108 a la infraestructura de equilibrio de carga 106. Por ejemplo, la información de estado de huésped 1006 puede ser diseminada a unidades de equilibrio de carga individuales 106. En (3) la lógica 1008 hace decisiones de equilibrio de carga de red en respuesta a la información de estado de huésped 1006. En (4), las conexiones son enviadas a huéspedes objetivo 108, basándose en estas decisiones de equilibrio de carga de red. La Figura 11 es un diagrama de flujo 1100 que ilustra un método ilustrativo para el equilibrio de carga de red que involucra información de estado de huésped. El diagrama de flujo 1100 incluye tres bloques 1102-1106. Aunque las acciones del diagrama de flujo 1100 puede ser realizadas en otros ambientes y con una variedad de esquemas de software, las Figuras 1-3 y 10 son utilizadas en particular para ilustrar ciertos aspectos y ejemplos del método. En el bloque 1102, la información de estado de huésped es enviada de los huéspedes a las unidades de equilibrio de carga. Por ejemplo, la información de estado de huésped 1006 puede ser enviada de los huésped 108 a las unidades de equilibrio de carga 106. En el bloque 1104, la información de estado de huésped es recibida de los huéspedes en las unidades de equilibrio de carga. Por ejemplo, las unidades de equilibrio de carga 16 pueden recibir información de estado de huésped 1006 de los huéspedes 108. En el bloque 1106, se hacen decisiones de equilibrio de carga en respuesta a la información del estado de huésped recibida. Por ejemplo, la lógica 1008 en las unidades de equilibrio de carga 106 pueden hacer decisiones para el equilibrio de carga de red en respuesta a la información de estado de huésped 1006. De esta manera, en la Figura 10, la infraestructura de equilibrio de carga 106 reúne información de estado de cliente 1006 de los huéspedes 108 (y/o aplicaciones 316 de los mismos) y equilibra la carga de las solicitudes de entrada que son dirigidas a los huéspedes 108 en respuesta a la información de estado de huésped 1006. Como se describe más adelante con referencia a las Figuras 12-18, esta información de estado de huésped 1006 puede ser de aplicación especifica. Como también se discute más adelante, los ejemplos de la información de estado de cliente 1006 incluye información de salud y/o carga.

La Figura 12 ilustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de salud y/o carga (HLI) 1206. Los huéspedes 108 (1), 108 (2) ... 108 (n) y se acoplan a la unidades de equilibrio de carga 106 (1), 106 (2) ... 106 (u) a través de un enlace de comunicación 1210, tal como una red. Como se ilustra, los huéspedes 108 comunican información de salud y carga 1206 a las unidades de equilibrio de carga 106 utilizando el enlazamiento de comunicación 1210. La comunicación bidireccional de la información de salud y carga 1206, como se indicó por la flecha con doble punta, se refiere a una comunicación de dos direcciones a partir de las unidades de equilibrio de carga 106 hacia los huéspedes 108 que proporciona cierta integridad, coherencia, corrección, etc., de manera que los huéspedes 108 y/o unidades de equilibrio de carga 106 pueden fallar independientemente uno del otro. Dichas comunicaciones de dos direcciones de las unidades de equilibrio de carga 106 a los huéspedes 108 se describen más adelante con referencia particular a la Figura 15. La información de salud refleja si un huésped y/o aplicación dada es capaz de manejar solicitudes de cliente. La información de carga refleja el número, cantidad, y/o nivel de solicitudes de cliente que el huésped y/o aplicación dada es capaz de manejar en un momento particular. En otras palabras, la carga puede reflejar directa y/o inversamente un número disponible, cantidad y/o nivel de capacidad total del huésped y/o aplicación dada. Como se observó anteriormente, las implementaciones descritas con referencia a las Figuras 12-18 se enfocan en la información de salud y/o carga; sin embargo, esas implementaciones también son aplicables a una información de estado general para los huéspedes (incluyendo sus aplicaciones). En una ¡mplementación descrita, cada huésped 108 (1 ), 108 (2) ... 108 (n) incluye un componente de infraestructura de salud y carga (H&LI) respectivo 1202 (1), 1202 (2) ... 1202 (n). cada componente de infraestructura de 1202 opcionalmente puede ser una porción de la infraestructura de equilibrio de carga 106 que está residente en y se ejecuta en cada huésped 108. La información de salud y carga 1206 puede ser realizada en software. Cuando funciona, cada infraestructura de salud y carga 1202 (1), 1202 (2) ... 1202 (n) crea y mantiene una tabla de salud y carga respectiva (H&L) 204 (1), 1204 (2) ... 1204 (n). Estas tablas de salud y carga 1204 pueden incluir entradas de aplicación específica. La información de salud y carga 1206 que está almacenada en las tablas de salud y carga 1004 puede ser independiente de la infraestructura de equilibrio de carga 106. Por ejemplo, administradores, diseñadores, etc., pueden especificar criterios para la información de salud y carga 1206 en un tiempo de configuración. Además, las entidades externas a un dispositivo que está o que tiene un huésped 108 pueden contribuir a determinar la información de salud y carga 1206 para las aplicaciones 316 en el dispositivo. Una tabla de salud y carga 1204 ilustrativa se describe más delante con referencia a la Figura 13A. Cada unidad de equilibrio de carga 106 (1), 106 (2) ... 106 (u) incluye una memoria caché de salud y carga consolidada (H&L) respectiva 1208 (1 ), 1208 (2) ... 1209 (u). Cada memoria caché de salud y carga consolidada 1208 incluye la información de cada tabla de salud y carga 1204 (1), 1204 (2) ... 1205 (n). Consecuentemente, cada unidad de equilibrio de carga 106 está provista con un rápido acceso (por ejemplo, en memoria caché) a la información de salud y carga 1206 para cada huésped 108 para el cual las unidades de equilibrio de carga 106 se le carga el tráfico de red de equilibrio. Durante operación, las infraestructuras de salud y carga 1202 empujan la información de salud y carga 1206 de las tablas de salud y carga 1204 a las memorias caché de salud y carga 1208 consolidadas. El mecanismo para proporcionar la información de salud y carga 1206 es dirigida en evento, de manera que los cambios a las tablas de salud y carga 1204 son provistos a las memorias caché de salud y carga consolidadas 1208 en una forma escalable, a tiempo. La Figura 13A es una tabla de salud y carga 1204 ilustrativa como se muestra en la Figura 12. En una implementación descrita, la tabla de salud y carga 1204 incluye múltiples entradas 1302 que cada una está asociada con una aplicación 316 diferente. Cada entrada 1302 puede corresponder a una fila en la tabla de salud y carga 1204 que tiene tres columnas. Estas columnas corresponden aun identificador de aplicación (ID) 1302 (A), caracterización de estado de aplicación 1302 (B), y directorio de equilibrador de carga 1302 (C). Ya que cada entrada 1302 está asociada con una aplicación particular 316, se agrega una fila a medida que cada aplicación es expandida (por ejemplo, a través de un administrador). Similarmente, los campos individuales en las columnas 1302 (A), 1302 (B), y/o 1302 (C) son modificados/actualizados cuando un valor de los mismos cambia. Por ejemplo, cuando un valor de caracterización de estado cambia para una aplicación dada 316, un valor en un campo de la caracterización de estado de aplicación 1302 (B) para la entrada 1302 de la aplicación 316 dada es actualizado. Las adiciones y eliminaciones de entradas 1302 para aplicaciones 316 pueden ser efectuadas con la entrada de un administrador de control en el huésped 108. Por ejemplo, una porción de administrador de control de un sistema operativo sabe cuando una aplicación 316 es iniciada y se detiene, debido a que está activamente involucrado en el inicio y detención de aplicaciones 316. Por lo tanto, un administrador de control puede identificar que ha iniciado, por lo menos en parte, una aplicación 316, y el administrador de control puede establecer que ha detenido, por lo menos en parte, la aplicación 316. Por lo tanto, a la infraestructura de salud y carga 1202 se le puede informar del inicio y detención de las aplicaciones 316 a través del administrador de control. Por lo tanto, ninguna comunicación explícita de las aplicaciones 316 tiene que ser provista a la infraestructura de salud y carga 1202. Un ejemplo de un administrador de control es el Administrador de Control de Servicio (SCM) de Windows® Operating System de Microsoft® Corporation. El identificador de aplicación 1302 (A) identifica la información que se utiliza para identificar únicamente la aplicación 316 a la cual está asociada la entrada 1302. El identificador de aplicación 1302 (A) puede incluir uno o más de lo siguiente para la aplicación asociada 316: la dirección de IP virtual y puerto, la dirección de IP física y puerto, el protocolo utilizado, y cualquier información específica del protocolo. El protocolo puede ser HTTP, IPsec, SOAP, etc. La información de protocolo específico puede ser un patrón de URL o cadena para delinear más la aplicación asociada con la entrada 1302. De esta manera, el identificador de aplicación 1302 (A) más particularmente se refiere a un punto extremo de aplicación específica en un huésped 108 particular. Otros identif icadores de aplicación alternativamente pueden ser empleados. Por ejemplo, para reducir la anchura de banda de la comunicación, el identificador de aplicación 1302 (A) puede tener un número de 32 bits que traza la información ilustrativa anterior en la infraestructura de salud y carga 1202 y en las unidad de equilibrio de carga 106. Además, cualquiera de los campos en la entrada 1302 en realidad puede contener un identificador globalmente único (GUID) que se utiliza como una llave para buscar la información verdadera para el campo. La caracterización de estado de aplicación 1302 (B) incluye información que refleja el estado de la aplicación 316 a la cual está asociada la entrada 1302. La caracterización de estado de aplicación 1302 (B) incluye lo siguiente para la aplicación asociada 316: salud de aplicación, carga de aplicación y capacidad de aplicación. La salud de aplicación es un valor casi boleano que indica si está funcionando una aplicación. La salud de aplicación puede ser saludable, fallida o desconocida. La salud de aplicación es un valor relativamente instantáneo y se comunica con una latencia relati amente baja (por ejemplo, de aproximadamente 1 segundo o pocos segundos) a las unidades de equilibrio de carga 106 cuando el valor de salud de aplicación cambia. La carga de aplicación es un valor que indica que tanto está ocupada una aplicación dada, de esta manera directa o inversamente cuanta carga adicional se puede manejar en la aplicación dada. La carga de aplicación es un valor que cambia relativamente en forma lenta o promediada que puede ser mitigado con un mecanismo de inducción de histéresis; si se desea, para eliminar picos pasajeros de carga incrementada o reducida. Se comunica relativa e infrecuentemente a unidades de equilibrio de carga 106 (por ejemplo, aproximadamente 1 a 4 veces por minuto). El valor de la carga de aplicación es dado con respecto a la capacidad de aplicación. La capacidad de aplicación es un valor que indica la capacidad máxima de la aplicación. Se selecciona en una forma genérica para ser importante en un contexto dado, pero sigue siendo suficientemente flexible para otros contextos. La capacidad de aplicación es un número unido menor que la unidad (por ejemplo, 0-99) que es determinable en un momento de configuración. Se puede basar en energía de procesamiento, tamaño/velocidad de memoria, acceso de red, alguna combinación de éstos, etc. La capacidad de aplicación expresa capacidades relativas entre otras aplicaciones del mismo tipo en un grupo de huéspedes 108 (1, 2 ... n). De esta manera, con relación a la capacidad de aplicación, la carga de aplicación gana importancia. La carga de aplicación para una aplicación dada es un porcentaje de capacidad de aplicación para la aplicación dada. Alternativamente, la carga de aplicación puede ser expresada como un número menor que la unidad, a partir del cual el porcentaje puede ser determinado junto con el valor de la capacidad de aplicación. El directorio de equilibrador de carga 1302 (C) incluye información que refleja el estado deseado y/o esperado del directorio establecido por la infraestructura de salud y carga 1202 para las unidades de equilibrio de carga 106 con respecto a una aplicación 316 a la cual está asociada la entrada 1302. El directorio de equilibrador de carga 1302 (C) incluye lo siguiente para la aplicación asociada 316: el estado de equilibrio de carga objetivo y el estado de equilibrio de carga real o actual. El estado de equilibrio de carga objetivo refleja el estado del directorio a las unidades de equilibrio de carga 106 según deseado por la infraestructura de salud y carga 1202. El estado de equilibrio de carga actual refleja que la infraestructura de salud de carga 1202 entiende el estado actual del directorio a las unidades de equilibrio de carga 106 que será grabado en las unidades de equilibrio de carga 106. El estado de equilibrio de carga actual de esta manera refleja el directorio de equilibrio de carga que la infraestructura de salud y carga 1202 espera de las unidades de equilibrio de carga 106 que actualmente operan bajo como se indica utilizando un protocolo de comunicación. Dicho protocolo de comunicación ilustrativo se describe más adelante con referencia a la Figura 15. La interacción y relación entre el estado de equilibrio de carga objetivo y el estado de equilibrio de carga actual también se esclarece haciendo referencia a la Figura 15. El estado de equilibrio de carga objetivo y estado de equilibrio de carga actual cada uno puede tener un valor de activo, inactivo, o de drenaje. Un directorio activo indica que son bienvenidas nuevas solicitudes/conexiones y pueden ser activadas en la aplicación en donde se asocian con la entrada 1302. Un directorio inactivo indica que ningún paquete adicional debe ser enviado a la aplicación asociada. Un directorio de drenaje indica que ningún paquete para las nuevas solicitudes/conexiones debe ser enviado a la aplicación asociada, pero esos paquetes para solicitudes/conexiones existentes deben continuar siendo enviados a la aplicación asociada. En una implementación descrita, la versión definitiva de la información de salud y carga 1206 respectiva se almacena en tablas de salud y carga 1204 que están ubicadas en cada huésped 108 respectivo de múltiples huéspedes 108. Con esta implementación, si un huésped 108 tiene una caída o falla, la información de salud y carga 1206 que está perdida pertenece a aquellas aplicaciones 1316 que también caen. Una medida de alta disponibilidad por lo tanto es ganada automáticamente sin duplicar datos. Sin embargo, la versión definitiva de información de salud y carga 1206 alternativamente puede ser almacenada en cualquier parte. Otras de estas opciones de almacenamiento incluyen las mismas unidades de equilibrio de carga 106, un huésped 108 que (como su única tarea o junto con obligaciones de hospedaje) almacena y mantiene la información de salud y carga 1206 para múltiples huéspedes 108 (incluyendo todos los otros), otro dispositivo separado y/o externo, etc. Si la versión definitiva de información de salud y carga 1206 se almacena y se mantiene en cualquier parte además de ser distribuida a través de los huéspedes 108 (1, 2, ... n), dicha información de salud y carga 1206 puede ser almacenada en forma redundante (por ejemplo, también almacenarse en un dispositivo de duplicación, en respaldo, etc.) para propósitos de alta disponibilidad. Los escenarios proxi ilustrativos para almacenar información de salud y carga se describen más adelante con referencia a las Figuras 17A y 17B. La Figura 17A está dirigida a un escenario proxi para tablas de salud y carga 1204, y la Figura 17B está dirigida a un escenario proxi para memorias caché de salud y carga 1208 consolidadas. La Figura 13B es una memoria caché de salud y carga 1208 consolidada ilustrativa como se muestra en la Figura 12. En un implementación descrita, cada memoria caché de salud y carga consolidada 1208 en cada unidad de equilibrio de carga 106 incluye por lo menos parte de la información almacenada en cada tabla de salud y carga 1204 para cada infraestructura de salud y carga 1202 en cada huésped 108. La información de salud y carga en memoria caché puede ser organizada en cualquier forma en la memoria caché de salud y carga consolidad 1208. Como se ¡lustra, la memoria caché de salud y carga consolidad 1208 incluye una memoria caché para cada huésped 108 (1 ), 108 (2) ... 108 (n) que replica parte o toda la información en la tabla de salud y carga 1204 de cada huésped 108 (1, 2 ... n) respectivo. Específicamente, la memoria caché de salud y carga consolidada 1208 incluye una memoria caché para el huésped #1 1204 (1), una memoria caché para el huésped #2 1304 (2) una memoria caché para el huésped #n 1304 ( (n). De esta manera, la memoria caché de salud y carga consolidada 1208 ilustrada, está organizada a un amplio nivel por el huésped 109 (1, 2 ... n), con cada memoria caché individual 1304 incluyendo entradas de aplicación especifica para el huésped 108 (1, 2 ... n) respectivo correspondiente. Alternativamente, la memoria caché de salud y carga consolidada 1208 puede ser organizada a un amplio nivel por el tipo de aplicación 316, con bloques individuales que están dirigidos a un tipo de aplicación específico además dividido por el huésped 108 (1, 2 ... n). También se pueden emplear otros formatos de estructura de datos. La Figura 14 es un diagrama de flujo que ilustra un método ilustrativo para el equilibrio de carga de red que coloca información de salud y carga. El diagrama de flujo 1400 incluye 8 bloques 1402-1416. Aunque las acciones del diagrama de flujo 1400 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, las Figuras 1-3 y 12-13B se utilizan en particular para ilustrar ciertos aspectos y ejemplos del método. Por ejemplo, las acciones de los dos bloques 1402-1404 se realizan por un huésped 108, y las acciones de 6 bloques 1406-1416 se realizan por una unidad de equilibrio de carga 106. En el bloque 1402, la información de salud y carga en un huésped se determina. Por ejemplo, la información de salud y carga 1206 para las aplicaciones 316 (2) puede ser determinada por la infraestructura de salud y carga 1202 (2) y almacenarse en la tabla de salud y carga 1204 (2) en el huésped 108 (2). En el bloque 1404, la información de salud y carga determinada es diseminada a las unidades de equilibrio de carga. Por ejemplo, la infraestructura de salud y carga 1202 (2) puede enviar información de salud y carga 1206 para las aplicaciones 316 (2) a las unidades de equilibrio de carga 106 (1, 2 ... u). Como se indica por la flecha 1418, las acciones de los bloques 1402 y 1404 se repiten, de manera que la salud y carga (aplicación) puede ser continuamente verificada y actualizada a medida que ocurren cambios. En el bloque 1406, la información de salud y carga es recibida de los huéspedes. Por ejemplo, la unidad de equilibrio de carga 106 (1) puede recibir información de salud y carga 1206 de múltiples huéspedes 108 (1, 2 ... n), que incluye información de salud y carga 1206 para las aplicaciones 316 (2) del huésped 108 (2). En el bloque 1408, la información de salud y carga recibida se almacena en memoria caché. Por ejemplo, la unidad de equilibrio de carga 106 (1) puede almacenar información de salud y carga 1206 de los huéspedes 108 (1, 2 ... n) en la memoria caché de salud y carga consolidada 1208 (1). Con referencia a la implementación de la Figura 13B de una memoria caché de salud y carga consolidada 1208 (1) , la información de salud y carga 1206 para las aplicaciones 316 (2) del huésped 108 (2) puede ser almacenada en la memoria caché para el huésped #2 1304 (2). Como se indica por la fecha 1420, las acciones de los bloques 1406 y 1408 se repiten, de manera que la información de salud y carga (aplicación) puede ser continuamente recibida y actualizada a medida que ocurren cambios. Como se indica por la flecha desvanecida 1422, las unidades de equilibrio de carga 106 también pueden manejar comunicaciones de cliente 102 mientras manejan emisiones de salud y carga (aplicación). En el bloque 1410, se recibe un paquete solicitando una nueva conexión. Por ejemplo, la unidad de equilibrio de carga 106 (1) puede recibir un paquete de SYN de TCP del cliente 102 (2) a través de la red 104. En el bloque 1412, se consulta la información de salud y carga en la memoria caché. Por ejemplo, la unidad de equilibrio de carga 106 (1) puede consultar la memoria caché de salud y carga consolidada 1208 (1). Más particularmente, la unidad de equilibrio de carga 106 (1) puede consultar entradas que están asociadas con la aplicación a la cual el paquete de SYN de TCP se dirige a través de las memorias caché para los huéspedes "2 ... #n 1304 (1 , 2 ... n). En el bloque 1414, se selecciona un huésped en respuesta a la información de salud y carga en memoria caché. Por ejemplo, la unidad de equilibrio de carga 106 (1) puede seleccionar al huésped 108 (2) teniendo aplicaciones 316 (2) en respuesta a la información de salud y carga 1206 que está en memoria caché en la memoria caché de salud y carga con carga consolidada 1208 (1). La aplicación seleccionada 316 (y huésped 108) debe estar saludable y ser capaz de aceptar una carga adicional (por ejemplo, posiblemente la última aplicación cargada entre aquellas aplicaciones que son del tipo de aplicación al cual se dirige el paquete de SYN de TCP). La consulta de la información de salud y carga de la memoria caché (en el bloque 1412) y la selección del huésped en respuesta a la información de salud y carga en memoria caché (en el bloque 1414) se puede realizar antes de la recepción de un paquete de solicitud de nueva conexión especifico y/o utilizando un esquema en lotes. También, la selección puede ser de acuerdo con cualquiera de muchos esquemas. Por ejemplo, se puede utilizar un esquema a base de señal o a base de circuito cíclico. Con cualquier esquema, la selección puede involucrar una carga de cargas relativas entre las opciones de aplicación. Esta consulta y selección, junto con los esquemas a base de señal y de circuito cíclico, se describen más adelante con referencia a la Figura 18 y en la sección intitulada "Clasificación, Envío y Enrutamiento de Solicitud Ilustrativos", especialmente con respecto a la clasificación de funcionalidad. Después de que el huésped objetivo es seleccionado en el bloque 1414, el paquete de solicitud de nueva conexión puede ser enviado al mismo. En el bloque 1516, el paquete recibido del cliente es enviado al huésped seleccionado. Por ejemplo, el paquete de SYN de TCP es enviado de la unidad de equilibrio de carga 106 (1) al huésped seleccionado 108 (2). El envió de este paquete inicial puede ser efectuado directamente por un clasificador 304 o por un expedidor 302, como se describen también más adelante en la sección intitulada "Clasificación, Envío y Enrutamiento de Solicitud Ilustrativos". Para una implementación descrita, la infraestructura de salud y carga 1202 está residente en y se distribuye a través de múltiples huéspedes 108 así como estando ubicada en un unidades de equilibrio de carga 106 (según representado por el manejador de salud y carga 314). La infraestructura de salud y carga 1202 tiene tres responsabilidades. Primero, expone puntos de audio para obtener actualizaciones de estado de aplicación para caracterizaciones de estado de aplicación 1302 (B) de las tablas de salud y carga 1204. En segundo lugar, sintetiza la información de estado de aplicación para determinar que unidades de equilibrio de carga 106 debe hacer, que se modaliza en el directorio de equilibrador de carga 1302 (C). En tercero, la infraestructura de salud y carga 1202 comunica este directorio de los huéspedes 108 a las unidades de equilibrio de carga 106.

El contenido de -directorio del directorio de equilibrador de carga 1302 (C) efectivamente es una versión digerida de la información para caracterizaciones de estado de aplicación 1302 (B). Sin embargo, las unidades de equilibrio de carga 106 también pueden recibir la información de partida de caracterizaciones de estado de aplicación 1302 (B) así como este directorio procesado. La comunicación del contenido de éstos y otros campos de las tablas de las tablas de salud y carga 1204 se logra utilizando un protocolo de mensaje que se describe más adelante con referencia a la Figura 15. La Figura 15 ilustra un protocolo de mensaje 1500 ilustrativo para las comunicaciones relacionadas con la información de salud y carga que se ilustran en la Figura 12 entre huéspedes 108 y las unidades de equilibrio de carga 106. En general, se utiliza un mecanismo accionado por evento para empujar cambios a las tablas de salud y carga 1204 de los huéspedes 108 a las unidades de equilibrio de carga 106. En otras palabras, para una implementación descrita, la información es transmitida de los huéspedes 108 a las unidades de equilibrio de carga 106 cuando las tablas de salud y carga 1204 se actualizan. Esto evita enviar periódicamente una instantánea de todas las tablas de salud y carga 1204, que reduce el consumo de anchura de banda de la red por la infraestructura de salud y carga 1202. El protocolo de mensaje 1500 puede ser implementado utilizando cualquier mecanismo de transporte de mensaje disponible. Dichos mecanismos incluyen transmisión de multidífusión confiable, transmisión de punto a punto (por ejemplo, protocolo de datagrama de usuario (UDP)), etc. Como se ilustra, el protocolo de mensaje 1500 incluye 7 tipos de mensaje 1502-1514: Un mensaje de latido 1502, un mensaje de adiós 1504, un mensaje de cambio de fila 1506, un mensaje de obtener instantánea de tabla 1508, un mensaje de enviar instantánea de tabla en 1510, un mensaje de postular estado de tabla 1512, y un mensaje de postular erróneo 1514. Se debe observar que, con la excepción de las filas 1516 y 1518, ninguna relación temporal entre los diferentes tipos de mensajes 1502-1504 es implicada por la ilustración. Por ejemplo, un mensaje de cambio de fila 1506 típicamente no sigue a un mensaje de adiós 1504. El mensaje de latido 1502 indica que un huésped particular 108 está funcionando y proporciona algún error verificando el contenido de una tabla de salud y carga particular correspondiente 1204 con respecto a una memoria caché particular correspondiente para el huésped particular 1304 en la memoria caché de salud y carga consolidada 1208. Cada infraestructura de salud y carga 1202 en cada huésped 108 envía un mensaje de latido directa o indirectamente a cada memoria caché de salud y carga consolidada 1208 en cada unidad de equilibrio de carga 106. Los mensajes de latido 1502 dirigen el problema de envejecimiento para datos en las memorias caché de salud y carga consolidadas 1208 que surgen, en parte, debido a que una instantánea de toda la tabla de salud y carga 1204 periódicamente no es transmitida a cada unidad de equilibrio de carga 106. Haciendo referencia a la Figura 16 que se describe más adelante, se describe un esquema de transmisión para mensajes de latido 1502. Los mensajes de latido 1502 incluyen un identificador para el huésped, datos de verificación de error, y opcionalmente un nombre de DNS. El identificador del huésped puede ser un número único (por ejemplo, 32,000) que se selecciona en el momento de la configuración. Los datos de verificación de error pueden ser una suma de verificación, un número de secuencia de cambio de estado, un número de generación, un valor de CRC, etc., que permite que una unidad de equilibrio de carga 106 de recepción valide que contenidos de esta memoria caché de salud y carga consolidadas 1208 se comportan con los contenidos de la tabla de salud y carga 1204 del huésped 108 que transmite. Si se emplea un aspecto de número de generación, entonces se pueden utilizar múltiples IDs de generación con cada ID de generación asignada a un "grupo" de aplicaciones. Después, los mensajes pueden ser referidos a un número de grupo o un par de número de grupo/ID de generación, dependiendo del contexto. Los datos de verificación de error (o, más en general, un indicador de contenido) pueden ser un valor individual para la tabla de salud y carga 1204 total, o pueden ser múltiples valores determinados en una base por entrada 1302. El nombre DNS opcionalmente puede ser enviado (por ejemplo, cada "x" latido) para verificar o actualizar la dirección de red correcta actual para el huésped. El mensaje de adiós 1504 es enviado de un huésped particular 108 a las unidades de equilibrio de carga 106 para indicar que el huésped 108 particular está paneando la detención. El mensaje de adiós 1504 incluye un identificador de huésped que puede ser indexado/trazado a una dirección de red para el huésped 108 particular. El mensaje de adiós 15 04 se utiliza para limpiar, interrupciones intencionales por los huéspedes 108 para precipitar una "limpieza rápida". Sin embargo, un mensaje de adiós 1504 se pierde, se guarda en memoria caché eventualmente se envejecen las entradas del huésped 108 particulares debido a que los mensajes de latido 1502 ya no son enviados. El mensaje de cambio de fila 1506 se envía de un huésped 108 particular a las unidades de equilibrio de carga 106 para indicar que la salud y/o carga para una aplicación dada 316 del huésped 108 particular ha cambiado. El mensaje de cambio de fila 1506 incluye un identificador de huésped, un identificador de aplicación, una operación, y datos para la operación. Los identificadores de huésped ilustrativos se describieron anteriormente con respecto a los mensajes de latido 1502 y los mensajes de adiós 1504. Los identificadores de aplicación ilustrativos se describieron anteriormente con respecto al identificador de aplicación 1302 (A) de una entrada 1302 de aplicación asociada de las tablas de salud y carga 1204. La operación de cambio de fila puede ser agregada, eliminada o actualizada. En otras palabras, los datos para la operación pueden ser agregados a (para una operación de adición) o un reemplazo para (para una operación de actualización) información ya presente en las memorias caché de salud y carga consolidadas 1208 en las unidades de equilibrio de carga 106. Para una operación de eliminación, no se necesita proporcionar ningún dato. El protocolo de mensaje 1500 se define de manera que se pueden estipular múltiples operaciones para ser realizadas para un solo mensaje de cambio de fila 1506. De esta manera, para un identif icador de huésped particular, los grupos de un identif icador de aplicación, operación y datos de operación pueden ser repetidos para múltiples aplicaciones 316 del huésped 108 que se identifica por el identificador de huésped particular. El mensaje 1508 de obtener instantánea de tabla es enviado de una unidad de equilibrio de carga 106 particular para una memoria caché de salud y carga consolidada particular 1208 a un solo huésped 108 o huéspedes 108. Este mensaje 1508 de obtener instantánea de tabla solicita que la infraestructura de salud y carga 1202 en los huéspedes 108 proporcione una instantánea de la tabla de salud y carga respectiva 1204 para el huésped 108 respectivo. Este mensaje incluye una identificación de la solicitud de unidad de equilibrio de carga 106 y se puede utilizar por una unidad de equilibrio de carga 106 (i) después de que ha fallado y después se recupera; (i¡) después de que un huésped 108 falla, se recupera y comienza a enviar mensajes de latido 1502 otra vez; (iii) si un mensaje de cambio de fila 1506 es enviado a la unidad de equilibrio de carga 106, pero el mensaje se pierde, de manera que su memoria caché de salud y carga consolidada 1208 está fuera de sincronización con la tabla de salud y carga 1204 respectiva para el huésped respectivo 108; y (iv), etc. Para la tercera situación (iii), la falta de sincronización entre la memoria caché de salud y carga consolidada 1208 y la tabla de salud y carga 1204 respectiva para el huésped 108 respectivo se descubre por un mensaje de latido subsecuente 1502 del huésped 108 respectivo ya que el "verificar error" indicará que la memoria caché de salud y carga consolidada 1208 está fuera de fecha. La unidad de equilibrio de carga 106 después puede enviar un mensaje de obtener instantánea de tabla 1508, de manera que pueda actualizar su memoria caché de salud y carga consolidada 1208. De esta manera, para cualquiera de las tres situaciones ilustrativas (i, ii, iii) la unidad de equilibrio de carga 106 subsecuentemente reconstituye su memoria caché de salud y carga consolidada 1208 utilizando obtener instantánea de tabla 1508. El paso obtener instantánea de tabla 1508 puede ser enviado repentinamente a cada huésped 108 en una forma de punto a punto o se puede enviar una vez a muchos huéspedes 108 en una forma de multidif usión. El mensaje de enviar instantánea de tabla 15 10 es enviado de un huésped 108 individual a una unidad de equilibrio de carga 106 particular después de que el huésped 108 individual ha recibido un mensaje de obtener instantánea de tabla 1508 de la unidad de equilibro de carga particular 106 como se indica por la flecha 1516. Los contenidos de un mensaje de enviar instantánea de tabla 1510 se preparan por la infraestructura de salud y carga 1202 que incluye todas o por lo menos múltiples filas de la tabla se salud y carga 1204 del huésped 108 individual, de manera que la unidad de equilibrio de carga 106 particular puede volver a construir su memoria caché de salud y carga consolidada 1208. El mensaje 1510 de enviar instantánea de tabla puede ser un mensaje separadamente diseñado, 0 puede ser equivalente a una secuencia de operaciones de adición en un mensaje de cambio de fila 1506. El mensaje de postular estado de tabla 1512 y el mensaje de postular error 1514 se refieren al estado de equilibrio de carga objetivo y al estado de carga actual del directorio de equilibrador de carga 1302 (C) de una entrada 1302 en una tabla de salud y carga 1204. El estado de equilibrio de carga objetivo es el directorio que la infraestructura de salud y carga 1202 desea para que las unidades de equilibrio de carga 106 operen. El estado de equilibrio de carga actual es el directorio en el que la infraestructura de salud y carga 1202 espera o cree que las unidades de equilibrio de carga 106 actualmente están operando de acuerdo con. En general, los dos estados de equilibrio de carga son idénticos. Sin embargo, el estado de equilibrio de carga objetivo puede diferir del estado de equilibrio de carga actual durante un periodo de transición para un cambio de directorio de estado. Por ejemplo, el estado de equilibrio de carga objetivo y el estado de equilibrio de carga actual ambos inicialmente se fijan como activos. Un problema con el huésped 108 y/o una aplicación 316 del mismo se detecta y el directorio de estado de equilibrio de carga objetivo es conmutado al drenaje. Este directorio de drenaje es comunicado a las unidades de equilibrio de carga 106 utilizando un mensaje de cambio de fila 1506.

Existe un retraso antes de que este cambio de directorio sea observado en todas las memorias caché de salud y carga consolidadas 1208 de todas las unidades de equilibrio de carga 106. Durante este periodo de transición, el estado de equilibrio de carga objetivo se está drenando, mientras que el estado de equilibrio de carga actual sigue activo en la tabla de salud y carga 1204 del huésped 108. Antes de cambiar el estado de equilibrio de carga actual al drenaje, la infraestructura de salud y carga 1202 desea asegurar que las memorias caché de salud y carga consolidadas 1208 en realidad han sido actualizadas a un nuevo estado de directorio de drenaje. Para verificar que las memorias caché de salud y carga consolidadas 1208 de las unidades de equilibrio de carga 106 han sido actualizadas a un nuevo directorio de estado, la infraestructura de salud y carga 1202 envía un mensaje de postular estado de tabla 1512 a las unidades de equilibrio de carga 106. El mensaje de postular estado de tabla 1512 es enviado en algún momento (por ejemplo, un periodo de retraso predeterminado) después de la transmisión de un mensaje de cambio de fila 1506 indicando que el directorio de estado va a ser cambiado. El mensaje de postular estado de tabla 1512, en este ejemplo, indica que el estado de tabla debe ser drenado. Como se indica por la flecha desvanecida 1518, una unidad de equilibrio de carga 106 responde a este mensaje de postular estado de tabla 1512 si su memoria caché de salud y carga consolidada 1208 difiere del directorio de estado postulado. Si el directorio en la memoria caché de salud y carga consolidada 1208 difiere del directorio de estado postulado, entonces esa unidad de equilibrio 106 envía un mensaje de postular error 1514 a la infraestructura de salud y carga 1206 del huésped 108 que emitió el mensaje de postular estado de tabla 1512. Esta infraestructura de salud y carga 1202 periódicamente después vuelve a enviar el mensaje de postular estado de tabla 1512 hasta que no se recibe ningún mensaje de postular error 1514 de las memorias caché de salud y carga consolidada 1208. En ese punto, la infraestructura de salud y carga 1202 envía un mensaje de cambiar fila 1506 con el estado de equilibrio de carga actual nuevo. En este sentido, las memorias caché de salud y carga consolidadas 1208 son los determinadores definitivos del estado de equilibrio de carga actual, y la infraestructura de salud y carga 1202 es el determinador definitivo del estado de equilibrio de carga objetivo. La Figura 16 ilustra un esquema de transmisión de mensaje ilustrativo para las comunicaciones que se ilustran en la Figura 12 entre los huéspedes 108 y las unidades de equilibrio de carga 106. El esquema de transmisión de mensaje ilustrativo puede reducir la anchura de banda consumidas por los mensajes de latido 1502 en el enlace de comunicación 1210. El esquema de transmisión de mensaje de la Figura 16 particularmente está adaptado a los mensajes de latido 1502, pero también se puede utilizar para otros mensajes del protocolo de mensaje 1500. Un grupo de huéspedes 108 (1), 108 (2), 108 (3) ... 109 (11), y 108 (12) se ilustra junto con las unidades de equilibrio de carga 106 (1), 106 (2) ... 106 (u). Cada línea representa un enlace de membresía o inclusión entre el grupo de huéspedes 108 (1, 2 ... 12). El grupo de huéspedes 108 (1, 2 ... 12) forma una membresía de nodos que trabajan conjuntamente para propagar información de latido a las unidades de equilibrio de carga 106. Aunque se muestran 12 huéspedes, más o menos pueden ser parte de un grupo dado de huéspedes. También, un grupo total de huéspedes 108 que se les da servicio una infraestructura de equilibrio de carga 106 puede ser dividido en 1, 2, 3 o más grupos de huéspedes. En una implementación descrita, la membresía de nodos para el grupo de huéspedes 108 (1, 2 ... 12) elige un líder que es responsable de transmitir mensajes de latido 1502 a las unidades de equilibrio de carga 106. Cada huésped 108 (sin conducción) en un grupo de huéspedes 108 (1, 2 ... 12) envía sus mensajes de latido 1502 al líder elegido. El huésped 108 (4) es el líder elegido en este ejemplo. Con la membresía de nodos, la información de latido para cada huésped 108 en el grupo de huéspedes 108 (1, 2 ... 12) se propaga al huésped líder de grupo 108 (4). El huésped 108 (4) reúne la información de latido y la consolida a un mensaje de latido consolidado 1602. Los mensajes de latido consolidados 1602 (1), 1602 (2) ... 1602 (u) después son enviados a unidades de equilibrio de carga respectivas 1606 (1), 1606 (2) ... 1606 (u). Estos mensajes de latido consolidados 1602 opcionalmente pueden ser comprimidos para reducir más el consumo de anchura de banda. Como otra alternativa, el huésped líder 108 (4) solamente puede enviar cambios en la membresía de grupo a las memorias caché de salud y carga consolidadas 1208. En otras palabras, en este modo, las memorias caché de salud y carga consolidadas 1208 principalmente tienen que ver no solamente con los cambios de estado en la membresía. Es la responsabilidad del huésped líder 108 (4) asegurar que el primer hola sea enviado cuando un huésped 108 queda en línea y que un mensaje de adiós 1504 sea enviado cuando ese huésped 108 quede fuera de línea. Además, un huésped 108 periódicamente puede especificar que un mensaje de latido 1502 va a ser "enviado". Esto indica al huésped líder 108 (4) a enviarlo a las memorias caché de salud y carga consolidadas 1208 aunque no represente un cambio de membresía. Los mensajes de latido 1502 (incluyendo los mensajes de latidos consolidados 1602) se utilizan por las unidades de equilibrio de carga 106 cuando sus memorias caché de salud y carga consolidadas 1208 están no sincronizadas con las tablas de salud y carga 1204. Esa falta de sincronización puede surgir, por ejemplo, de una caída u otra falla de memoria caché de salud y carga consolidada 1208 y/o de una unidad de equilibrio de carga 106. Como se describió anteriormente, cada mensaje de latido 1502 incluye datos de verificación de error que se pueden utilizar para verificar la equivalencia entre una memoria caché de salud y carga consolidada 1208 y las tablas de salud y carga 1204. Si no se descubre ninguna equivalencia con respecto a un huésped 108 particular y/o una aplicación 316 del mismo, el nombre de DNS del huésped 108 particular es adquirido de los mensajes de latido 1502. El nombre de DNS se utiliza por la memoria caché de salud y carga consolidada 1208 para enviar un mensaje de obtener instantánea de tabla 1508 al huésped 108 particular con el fin de obtener información de carga y salud actualizada 1206 en la forma de un mensaje de enviar instantánea de tabla 1510. Un mensaje de obtener instantánea de tabla igual o diferentes 1508 es enviado a cada huésped 108 para el cual se descubre que no hay ninguna equivalencia. Finalmente, la información de salud y carga 1206 en la memoria caché de salud y carga consolidada 1208 es equivalente a la información de salud y carga 1206 en las tablas de salud y carga 1204 como verificable por nuevos mensajes de latido 1502. De esta manera, una memoria caché de salud y carga consolidada fallida 1208 puede ser sacada a una operación sin equivocación manual utilizando el protocolo de mensajes 1500 y un esquema de verificación de equivalencia. La Figura 17A y la Figura 17B muestran escenarios de almacenamiento proxi de información de salud y carga ilustrativos para las tablas de salud y carga 1204 y para las memorias caché de salud y carga consolidadas 1208, respectivamente. En las implementaciones descritas anteriormente con referencia a las Figuras 12-16, los huéspedes 108 incluyen la infraestructura de salud y carga 1202. Sin embargo, otras implementaciones pueden implicar huéspedes que no incluyen y la infraestructura de salud y carga 1202. Por ejemplo, un huésped puede estar corriendo una versión de aplicaciones y/o un sistema operativo para el cual la infraestructura de salud y carga y está implementada o por razones de política no puede ser instalada en el huésped. Consecuentemente, estos tipos de huéspedes no tienen infraestructura de salud y carga 1202 ejecutándose en los mismos. El huésped 1702 es un huésped que no ejecuta la infraestructura de salud y carga 1202. Sin embargo, el huésped 1702 puede utilizar una infraestructura de salud y carga 1202 que está ejecutándose en uno o más proxis, tal como el proxi 1704. El proxi 1704 tiene residente en el mismo y ejecutándose en el mismo, una infraestructura de salud y carga 1202, la cual incluye una tabla de salud y carga 1204. El huésped 1702 puede utilizar la funcionalidad de la infraestructura de salud y carga 1202 proporcionando información de salud y carga 1206 a la tabla de salud y carga 1204 para aplicaciones que están corriendo en el huésped 1702. Alternativamente, un proxi 1704 puede deducir la salud y carga en el huésped 1702 realizando acciones de verificación externas. El proxi 1704 se ilustra como el proxi 1704 (1) y 1704 (2) para redundancia y la alta disponibilidad resultante. En implementaciones descritas anteriormente con referencia a las Figuras 12-16 y más adelante con referencia a la figura 18, el equilibrio de carga es efectuado con unidades de equilibrio de carga 106 que incluyen memorias caché de salud y carga consolidadas 1208. Sin embargo, otras implementaciones pueden implicar el equilibrio de carga que no incluye las memorias caché de salud y carga consolidadas 1208. Por ejemplo, el equilibrio de carga puede ser efectuado a través de hardware de equilibrio de carga monolítico u otra infraestructura de equilibrio de carga que no puede almacenar o de otra manera incluir una memoria caché de salud y carga consolidada 1208. El equilibrador de carga 1706 refleja dicho dispositivo o dispositivos de equilibrio de carga que no tienen una memoria caché de salud y carga consolidada 1208. Sin embargo, el equilibrador de carga 1706 puede utilizar una memoria caché de salud y carga consolidada 1208 que existe en uno o más proxis, tal como el proxi 1708. El proxi 1708 incluye una memoria caché de salud y carga consolidada 1208, que almacena información de salud y carga 1206 para aplicaciones alojadas que son servidas por el equilibrador de carga 1706. El equilibrador de carga 1706 puede utilizar la información de salud y carga 1206 de la memoria caché de salud y carga consolidada 1208 cuando se realizan funciones de equilibrio de carga accesando dicha información utilizando interfases de programación de aplicación (APIs) nativas a y soportadas por el equilibrador de carga 1706. Alternativamente, la memoria caché de salud y carga consolidada 1208 puede invocar a las APIs para empujar la información de salud y carga 1206, Incluyendo los directorios, al equilibrador de carga 1706. el proxl 1708 se ilustra como el proxi 1708 (1 ) y 1708 (2) para redundancia y la alta disponibilidad resultante. La Figura 18 ilustra un procedimiento de distribución de punto extremo de aplicación objetivo ilustrativo que Involucra un clasificador 304 y un manejador de salud y carga 314 de una unidad de equilibrio de carga 106. Después de que el manejador de salud y carga 314 ha adquirido una memoria caché de salud y carga consolidada 1208, la información de salud y carga 1206 del mismo es utilizada en la selección de puntos extremos de aplicación para nuevas solicitudes/conexiones. Como se describió anteriormente con referencia a la Figura 13B, la memoria caché de salud y carga consolidada 1208 incluye Información de salud y carga 1206 en memoria caché para múltiples huéspedes 108. Para facilitar la creación y actualización de la memoria caché de salud y carga consolidada 1208 de la información de salud y carga 1206 que origina de múltiples huéspedes 108, la información de salud y carga 1206 está organizada de manera que puede ser accesada por el identificador de cada huésped 108. Sin embargo, la información de salud y carga 1206 de ahí también está organizada de manera que puede ser accesada por el tipo de aplicación 316 con el fin de facilitar la selección de punto extremo de aplicación. En otras palabras, el manejador de salud y carga 314 es capaz de accesar la información de salud y carga 1206 en una base por aplicación 316 a través de la información de salud y carga 1206 para múltiples huéspedes 108. Una vez que la información de salud y carga 1206 para una aplicación dada 316 ha sido accesada para cada huésped 108, la distribución de solicitudes de conexión de entrada puede ser realizada de acuerdo con dicha información de salud y carga 1206. Por ejemplo, se pueden distribuir posibles puntos extremos para la aplicación dada 316 a solicitudes de conexión de entrada mediante la selección de los puntos extremos de la aplicación dada 316 con consideración de la capacidad de carga relativa disponible entre puntos extremos saludables para la aplicación dada 316. En una implementación deseada, el clasificador 304 hace una solicitud de distribución de punto extremo de aplicación objetivo 1802 al manejador de salud y carga 314. Como se ilustra, la solicitud de distribución de punto extremo de aplicación objetivo ilustrada 1802 incluye (i) una dirección de IP virtual y puerto, (ii) un protocolo,, y (iii) información de especificación de protocolo. La solicitud de distribución de punto extremo de aplicación objetivo 1802 por lo tanto identifica un tipo de aplicación 316 al cual se dirigen las solicitudes de conexión de entrada.

El manejador de salud y carga 314 recibe la solicitud de distribución de punto extremo de aplicación objetivo 1802 y selecciona por lo menos un punto extremo físico que corresponde al tipo identificado de aplicación 316 utilizando cualquiera o más de los mecanismos de selección. Para reducir la latencia, el manejador de salud y de carga 314 selecciona una distribución de puntos extremos de aplicación que serán utilizados a través de un número de solicitudes de conexión de entrada. Esta distribución es provista del manejador de salud y carga 314 al clasificador 304 utilizando una respuesta de distribución de punto extremo de aplicación objetivo 1804. Como se ilustra, la respuesta de distribución de punto extremo de aplicación objetivo 1804 incluye una distribución de direcciones IP físicas y puertos (tales como los puntos extremos IP1, IP2 e IP3) para el tipo Identificado de aplicación 316. La distribución para la respuesta de distribución de punto extremo de aplicación objetivo 1804 puede ser completada utilizando uno o más esquemas de distribución. A manera de ejemplo, se ilustran un esquema de distribución de señal 1806 y un esquema de distribución de porcentaje 1808. El esquema de distribución de señal 1806 es un esquema de distribución a base de unidad, y el esquema de distribución de porcentaje 1808 es un esquema de distribución a base de tiempo. El esquema de distribución de señal 1806 distribuye señales para cada punto extremo saludable IP1, IP2 e IP3 que responde a sus relaciones de carga y capacidad relativas. Para el ejemplo ilustrado, de la capacidad disponible total, IP1 tiene un 40% de capacidad disponible, IP2 tiene un 35% de capacidad disponible, y IP3 tiene un 25% de capacidad disponible. De esta manera, el número total de señales se divide a lo largo de estos porcentajes. El número total de señales puede ser provisto como parte de la solicitud de distribución de punto extremo de aplicación objetivo 1802 o se determina a través del manejador de salud y carga 314. Cualquier valor para el número total de señales puede ser utilizado, tal como 10, 45, 100, 250, 637, 1000, etc. Este valor puede ser fijado en dependencia del número de solicitudes de conexión por segundo y la velocidad/frecuencia a la cual la salud y/o carga de aplicación está cambiando. El clasificador 304 "utiliza" / consume una señal cuando responde a cada solicitud de conexión con una distribución de punto extremo de aplicación hasta que las señales son terminadas; el clasificador 304 después solicita otra distribución de señales utilizando la solicitud de distribución de punto extremo de aplicación objetivo 1802. El esquema de distribución de porcentajes 1808 determina una capacidad relativa disponible en una forma similar. Sin embargo, en lugar de señales, estas capacidades relativas disponibles determinadas por punto de extremo de aplicación son provistas al clasificador 304 junto con un cronómetro de duración 1810. el clasificador 304 asigna los puntos extremos de aplicación objetivo a solicitudes de conexión de entrada de acuerdo con estos porcentajes de capacidad relativa disponibles hasta la espiración del cronómetro 1810. Para el esquema de distribución de porcentaje 1808, el clasificador 304 mantiene un registro corriendo de asignaciones de punto extremo de aplicación para adherirse a los porcentajes distribuidos y mantiene un rastreo de tiempo en el cronómetro 1810. Cuando el cronómetro expira, el clasificador 304 después solicita otra distribución de porcentaje utilizando la solicitud de distribución de punto extremo de aplicación de objetivo 1802. Se debe observar que el esquema de distribución de señal 1806 también puede utilizar un límite de tiempo. Si las señales distribuidas son demasiado antiguas, estas deben ser desechadas y deben adquirir nuevas. De otra manera, el clasificador 304 puede consumir señales añejadas que fueron previamente distribuidas basándose en la información de salud y carga que actualmente está demasiado fuera de actualización. El uso de distribución de punto extremo de aplicación por el clasificador 304 se describe más adelante en la sección intitulada "clasificación, Envío y Enrutamiento de Solicitud Ilustrativo".

Rastreo de Sesión Ilustrativo Esta sección describe como la información de estado huésped, tal como la información de sesión, puede ser reunida para y utilizada en el equilibrio de carga de red. Esta sección principalmente hace referencia a las Figuras 19-24 e ilustra la funcionalidad de conservación definida de sesión tal como aquella provista por el rastreador de sesión 308 (de la figura 3). Como se describió anteriormente con referencia las Figuras 1-3, cada huésped 108 aloja una o más aplicaciones 316 que proporcionan servicios a los clientes 102. El rastreador de sesión 308 utiliza la información de sesión que refiere a contextos para las conexiones establecidas entre las aplicaciones 316 y los clientes 102 para ciertas implementaciones descritas del equilibrio de carga de red. La Figura 19 ¡lustra un aspecto de equilibrio de carga de red ilustrativo que involucra información de sesión 1902. En la conexión [1], el cliente 102 (1) se muestra haciendo una nueva conexión con el huésped 108 (2) a través de la infraestructura de equilibrio de carga 106. La infraestructura de equilibrio de carga 106 puede estar compuesta de una o más unidades de equilibrio de carga 106. Cuando la solicitud de conexión llega la infraestructura de equilibrio de carga 106, la solicitud típicamente es enrutada a un huésped 108 utilizando la funcionalidad de equilibrio de carga de red en respuesta a la información de salud y/o carga de los huéspedes 108 y/o aplicaciones 316 de los mismos (no explícitamente mostrado en la Figura 19). Cuando se hace la conexión [1], se establece una sesión entre el cliente 102 (1) y la aplicación 316 que da servicio, la cual está en el huésped 108 (2) en este ejemplo. La sesión proporciona un contexto para el intercambio de comunicación entre el cliente 102 (1) y el huésped 108 (2). La información para el contexto de sesión es almacenada en el huésped 108 (2). Cuando se completa la conexión [1], el contexto de sesión puede no ser usado de nuevo. Por otro lado, el contexto de sesión puede útil otra vez si el cliente 102 (1) intenta iniciar otra conexión con os huéspedes 108 para el servicio provisto por la aplicación 316. Si esta otra conexión no es enrutada al mismo huésped 108 (2) que almacena ese contexto de sesión, entonces el cliente 102 (1) tiene que establecer el nuevo contexto de sesión, lo cual puede ser consumidor de tiempo, con intensos datos/procesamiento, y/o frustrante para el usuario del cliente 102 (1). Con el equilibrio de carga de red a base de la información de salud y/o carga, no hay probabilidad mayor que la oportunidad aleatoria de que la segunda conexión será enrutada a 108 (2). Sin embargo, si la infraestructura de equilibrio de carga 106 tiene acceso a un mapeo entre la información de sesión y los huéspedes 108, la infraestructura de equilibrio de carga 106 puede enrutar solicitudes de conexión que se refieren a sesiones previamente establecidas al huésped 108 apropiado. Alguna información de sesión puede ser inferida de los contenidos de paquetes que fluyen a través de la infraestructura de equilibrio de carga 106. Sin embargo, este aspecto es impreciso y casual por un número de razones. En primer lugar, el establecimiento y terminación de la sesión es meramente inferido. En segundo lugar, algunas sesiones no son "oficialmente" terminadas con una indicación apropiada que es incluida en un paquete. Por ejemplo, algunas sesiones simplemente salen fuera de tiempo. En tercer lugar, los paquetes que son transmitidos del huésped 108 (2) al cliente 102 (1) pueden tomar una trayectoria que no incluye infraestructura de equilibrio de carga 106, lo cual evita alguna curiosidad de dichos paquetes por la infraestructura de equilibrio de carga 106 para la información de sesión. Como se muestra en la Figura 19, los huéspedes 108 proporcionan información de sesión (SI) de 1902 a la infraestructura de equilibrio de carga 106. Al utilizar la información de sesión 1902 de los huéspedes 108, ün conservador de afinidad de sesión 1904 puede conservar la afinidad entre una sesión establecida y el huésped 108 en donde se estableció la sesión. La información de sesión 1902 incluye un enlace entre o un mapeo de cada sesión establecido entre un cliente 102 y un huésped 108 particular de ese huésped particular 108. Este mapeo es accesible al conservador de afinidad de sesión 1904 como parte del mapeo de información de huésped-sesión 1906. Ejemplos más específicos de la información de sesión 1902 se proporcionan más adelante, especialmente con referencia a las Figuras 20, 22, 23A y 23B. En ciertas implementaciones descritas para el rastreo de sesión, la naturaleza lógica de los clientes 102 es pertinente. Como se observó anteriormente con referencia a la Figura 1, un cliente 102 puede ser un dispositivo específico y/o un usuario específico de un dispositivo. Consecuentemente, la afinidad de sesión para un usuario del cliente 102 que está entrando a los huéspedes 108 de diferentes dispositivos se puede seguir conservando. Las continuaciones de sesión utilizando información de sesión 1902 por lo tanto pueden ser efectuadas en escenarios proxi (por ejemplo, aquellos de algunos proveedores de servicio de Internet (ISPs)). Continuando con el ejemplo de conexión [1], la sesión establecida en el huésped 108 (2) es provista a la infraestructura de equilibrio de carga 106 como la información de sesión 1902. Específicamente, un enlace/mapeo entre (i) el contexto de sesión del cliente 102 (1) y el huésped 108 (2) y (ii) un identificador para el huésped 108 (2) se crea en el mapeo de información de huésped-sesión 1906. Cuando una solicitud de conexión para la conexión [2] subsecuentemente llega al mismo contexto de sesión, el conservador de afinidad de sesión 1904 ubica este contexto en un mapeo de información de huésped-sesión 1906 y determina que el huésped 108 (2) está asociado con este contexto de sesión del enlace/mapeo. En respuesta al mapeo del huésped 108 (2) al contexto de sesión solicitado según determinado por el conservador de afinidad de sesión 1904 del mapeo de información de huésped-sesión 1906, la conexión [2] es enrutada al huésped 108 (2). En este sentido, la afinidad de sesión de conservación es una prioridad mayor para la infraestructura de equilibrio de carga 106 que las decisiones de equilibrio de carga de red a base de salud y carga de aplicación. Sin embargo, la salud y/o carga pueden ser un factor de equilibrio de carga de red más importante que el rastreo de sesión cuando, por ejemplo, la carga es extremadamente pesada o cuando la aplicación de sesión relevante y/o huésped está en una condición de falla. Muchos tipos de conexiones pueden estar relacionadas con la sesión. Los ejemplos incluyen: una conexión de TCP, una sesión de seguridad de capa de transporte (TLS)/SSL, una sesión de PPTP, una sesión de IPSec/L2TP, una sesión de ISA, una sesión a base de galleta de HTTP, una sesión de servidor terminal, una sesión definida por el administrador, etc. A manera de ejemplo, una conexión de TCP se considera que es una sesión de paquete de TCP. También, un modelo para definir sesiones por un administrador puede ser enumerado y soportado. Además, también pueden ser soportadas sesiones a base de dirección de IP de cliente que son delineadas por el tiempo. Este es un soporte de sesión relativamente no inteligente, pero es esperado por algunos usuarios. Una solicitud de conexión de un cliente 102 varía por el tipo de sesión deseada. Por ejemplo, para sesiones del tipo "conexión de TCP", la solicitud de conexión comprende un paquete de TCP. Para sesiones de tipo de "sesión de SSL", la solicitud de conexión comprende una conexión de TCP. Otras solicitudes de conexión corresponden a otros tipos de sesión. Estos ejemplos también muestran como pueden existir capas de sesión. A un nivel de sesión más bajo, un contexto de sesión para una conexión de TCP puede incluir una 4-tupla de TCP, un número de sesión, el número de bits enviados/recibidos, etc. A un nivel de sesión más alto, un contexto de sesión para una sesión de SSL puede incluir una ID de sesión de 32 bits, una clave pública del cliente 102 que es provista al huésped 108, y así sucesivamente. La Figura 20 ilustra un aspecto de equilibrio de carga ilustrativo que involucra información de sesión de comunicación utilizando notificaciones 2006 y mensajes 2008. Se muestran múltiples unidades de equilibrio de carga 106 (1 ), 106 (2) ... 106 (u) y múltiples huéspedes 108 (1), 108 (2) ... 108 (n). Cada huésped respectivo 108 (1), 108 (2) ... 108 (n) incluye una o más aplicaciones respectivas 316 (1), 316 (2) ... 316 (n), las cuales están residentes ahí y se ejecutan ahí. Las notificaciones 2006 se utilizan para proporcionar información de sesión de las aplicaciones 316, y los mensajes 2008 se utilizan para proporcionar información de sesión de los huéspedes 108 a las unidades de equilibrio de carga 106. Como se ilustra, cada huésped respectivo 108 (1 ), 108 (2) ... 108 (n) incluye una infraestructura de rastreo de sesión respectiva (STI) 2002 (1), 2002 (2) ... 2002 (n). Cada infraestructura de rastreo de sesión respectiva 2002 (1), 2002 (2) ... 2002 (n) incluye una tabla de sesión respectiva 2014 (1), 2014 (2) ... 2014 (n) (aunque solamente la tabla de sesión 2014 (1) explícitamente se ilustra en la Figura 19). Cada unidad de equilibrio de carga respectiva 106 (1 ), 106 (2) ... 196 (u) incluye una funcionalidad de enrutamiento de tráfico respectiva (TRF) 2012 (1 ), 2012 (2) ... 2012 (u). La funcionalidad de enrutamiento de tráfico 2012 puede comprender, por ejemplo, clasificar y/o solicitar la funcionalidad de enrutamiento, tal como aquella provista por el clasificador 304 y el enrutador de solicitud 306, respectivamente. Distribuido a través de las unidades de equilibrio de carga 106 (1), 106 (2) ... 106 (u) se encuentra un administrador de rastreo de sesión distribuido 2010. En una implementación descrita, la funcionalidad de enrutamiento de tráfico 2012 y el administrador de rastreo de sesión distribuido 2010 son parte de la infraestructura de equilibrio de carga 106. La infraestructura de rastreo de sesión 2002 también puede ser "por ejemplo, remoto" parte de la infraestructura de equilibrio de carga 106. Se emplea una API 2004 para proporcionar información de sesión de aplicaciones 316 a la infraestructura de rastreo de sesión 2002. Al utilizar la API 2004, las aplicaciones 316 son facultadas para notificar a la infraestructura de rastreo de sesión 2002 de información de sesión, incluyendo varios cambios de la misma. Más específicamente, cada aplicación 316 es capaz de proporcionar, y la infraestructura de rastreo de sesión 2002 es capaz de aceptar, notificaciones 2006. Una notificación de que una sesión ha sido establecida (o notificación de establecimiento de sesión 2006 (E)) es provista de la aplicación 316 cuando una sesión es recientemente establecida o abierta. La notificación de establecimiento de sesión 2006 (E) incluye un identificador de sesión y opcionalmente un identificador de aplicación 316. Una notificación de que una sesión ha sido terminada (o la notificación de terminación de sesión 2006 (T)) es provista de la aplicación 316 cuando una sesión es terminada o cerrada. La notificación de terminación de sesión 206 (T) también incluye el identificador de sesión y opcionalmente el identificador de aplicación 316. Cuando una infraestructura de rastreo de sesión 2002 acepta una notificación de establecimiento de sesión 2006 (E), inserta una entrada en la tabla de sesión 2014 para la nueva sesión. Una tabla de sesión 2014 ilustrativa se describe más adelante con referencia a la Figura 23A. Cuando una infraestructura de rastreo de sesión 2002 acepta una notificación de terminación de sesión 2006 (T) remueve la entrada y la tabla de sesión 2014 para la sesión antigua. La tabla de sesión 2014 (1) es una fuente autoritativa para la información de sesión 1902 con respecto a las aplicaciones 315 (1) en el huésped 108 (1). Sin embargo, generalmente existe demasiada latencia para requerir que la funcionalidad de enrutamiento de tráfico 2012 haga contacto con un huésped 108 para tener acceso a las tablas de sesión 2014 después de recibir cada solicitud de conexión de entrada teniendo una referencia de sesión. La información de sesión 1902, por lo tanto, se almacena en memoria caché en las unidades de equilibrio de carga 106. En las unidades de equilibrio de carga 106, el administrador de rastreo de sesión distribuida 2010 guarda en memoria caché la información de sesión 1902 como parte de sus responsabilidades de administración de rastreo de sesión. En general, el administrador de rastreo de sesión distribuida 2010 es una aplicación distribuida y/o servicio virtual que reside parcialmente en cada unidad de equilibrio de carga 106. Para cada sesión lógica, el administrador de rastreo de sesión distribuida 2010 mantiene por lo menos una copia en memoria caché de la información de sesión para el mismo en una forma confiable y escalable que rápidamente puede ser utilizada para encontrar el tráfico a medida que las solicitudes de conexión de entrada que tienen una referencia de sesión son recibidas por la infraestructura de equilibrio de carga 106. Las comunicaciones entre los huéspedes 108 y las unidades de equilibrio de carga 106 son efectuadas como un protocolo confiable que asegura que los mensajes 2008 enviados de un huésped 108 llegan a la unidad de equilibrio de carga 106 pretendida. Cada huésped 108 está unido por lo menos a una unidad de equilibrio de carga 106 específica que es la unidad de equilibrio de carga 106 destinada para los mensajes 2008. Esta unión es creada accesando una dirección de IP de una unidad de equilibrio de carga 106 específica a cada huésped 108 para enviar mensajes de rastreo de sesión 2008 entre la infraestructura de rastreo de sesión 2002 y el administrador de rastreo de sesión distribuida 2010. Para facilitar una alta disponibilidad de la infraestructura de equilibrio de carga 106, si una unidad de equilibrio de carga 106 falla, la otra unidad de equilibrio de carga 106 asume la dirección de IP de la unidad de equilibrio de carga 106 con falla. La detección de falla para la suposición de dirección de IP puede lograrse utilizando un esquema de latido o de verificación de vitalidad. De esta manera, los mensajes 2008 comunican la información de sesión 1902 de la infraestructura de rastreo de sesión 2002 al administrador de rastreo de sesión distribuida 2010. Por ejemplo, cuando la infraestructura de rastreo de sesión 2002 acepta una notificación de establecimiento de sesión 2006 (E), y también envía un mensaje de sesión 2002 (U) al administrador de rastreo de sesión distribuida 2010. El mensaje de sesión de carga 2008 (U) incluye el identif icador de sesión, un identificador de huésped, y opcionalmente otra información. Los contenidos para un mensaje de sesión de carga 2008 (U) se describen más adelante con referencia a la Figura 23B con respecto a la información que puede ser almacenada para cada sesión por una implementación del administrador de rastreo de sesión distribuida 2010. Cuando la infraestructura de rastreo de sesión 2002 acepta una notificación de terminación de sesión 2006 (T), también envía un mensaje de descarga de sesión 2008 (D) al administrador de rastreo de sesión distribuida 2010. Los mensajes 2008 pueden ser enviados antes, durante, o después de la infraestructura de rastreo de sesión 2002 apropiadamente modifican la tabla de sesión 214 en respuesta a las notificaciones 2006. La Figura 21 es un diagrama de flujo 2100 que ¡lustra un método ilustrativo para el equilibrio de carga de red que involucra información de sesión de comunicación utilizando notificaciones y mensajes. El diagrama de flujo 2100 incluye 15 bloques 2102-2130. Aunque las acciones del diagrama de flujo 2100 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, las Figuras 1-3 y 19-20 se utilizan en particular para ilustrar ciertos aspectos y ejemplos del método. Por ejemplo, las acciones de cuatro bloques 2102-2104 y 2118- 2120 se realizan a través de una aplicación 316, las acciones de seis bloques 2106-2110 y 2122-2126 se realizan por la infraestructura de rastreo de sesión 2002, y las acciones de cinco bloques 2112-2116 y 2128-2130 se realizan a través de un administrador de rastreo de sesión distribuida 2010. Las acciones de ocho de estos bloques 2102-2116 principalmente están dirigidas a abrir una sesión, y las acciones de siete de estos bloques 2118-2130 principalmente están dirigidas a cerrar una sesión. En el bloque 2102, se abre una sesión. Por ejemplo, la aplicación 316 puede abrir una sesión con un cliente 102. en el bloque 2104, se proporciona una notificación de establecimiento de sesión. Por ejemplo, la aplicación 316 puede proporciona una notificación de establecimiento de sesión 2006 (E) a la infraestructura de rastreo de sesión 2002 utilizando API 2004 como una consecuencia de y/o junto con la abertura de la sesión. En el bloque 2106, la notificación de establecimiento de sesión es aceptada. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede aceptar la notificación de establecimiento de sesión 2006 (E) de la aplicación 316 de acuerdo con la API 2004. En el bloque 2108, se inserta una entrada en una tabla de sesión. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede insertar una entrada en la tabla de sesión 2014 para la sesión abierta. Ejemplos de dicha inserción se describe más adelante especialmente con referencia a la Figura 23A. En el bloque 2110, se envía un mensaje de carga de sesión. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede enviar un mensaje de carga de sesión 2008 (U) al administrador de rastreo de sesión distribuida 2010 utilizando un protocolo de comunicación confiable. En el bloque 2112, el mensaje de carga de sesión es recibido. Por ejemplo, el administrador de rastreo de sesión distribuida 2010 puede recibir un mensaje de carga de sesión 2008 (U) de la infraestructura de rastreo de sesión 2002 de acuerdo con el protocolo de comunicación confiable. En el bloque 2114, se crea una entrada de información de sesión. Por ejemplo, el administrador de rastreo de sesión distribuida 2010 puede crear una entrada de información de sesión para la información de sesión 1902 guardada en memoria caché en una o más unidades de equilibrio de carga 106. Ejemplos de dicha creación y subsecuente adición se describe más adelante en especial con referencia a las Figuras 22 y 23B. En el bloque 2116, el tráfico de red es enrutado con la información de sesión. Por ejemplo, la funcionalidad de enrutamiento de tráfico 2012 junto con el administrador de rastreo de sesión distribuida 2010 puede utilizar la información de sesión 1902 guardada en memoria caché, incluyendo la entrada de información de sesión creada, para enrutar la solicitudes de conexión de entrada que tienen una referencia de dirección. Un ejemplo de dicho enrutamiento de tráfico se describe más adelante especialmente con referencia a la Figura 24. Más adelante se describen ejemplos adicionales en la sección intitulada "Clasificación, Envío y Enrutamiento de Solicitud Ilustrativos".

En el bloque 2118, la sesión se cierra. Por ejemplo, la aplicación 316 puede cerrar la sesión con el cliente 102. En el bloque 2120, se proporciona una notificación de terminación de sesión. Por ejemplo, la aplicación 316 puede proporcionar una notificación de terminación de sesión 2006 (T) a la infraestructura de rastreo de sesión 2002 utilizando la API 2004 como una consecuencia de y/o junto con el cierre de la sesión. En el bloque 2122, se acepta la notificación de terminación de sesión. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede aceptar la notificación de terminación de sesión 2006 (T) de la aplicación 316 de acuerdo con la API 2004. En el bloque 2124, la entrada en la tabla de sesión es removida. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede remover la entrada en la tabla de sesión 2014 para la sesión cerrada. En el bloque 2126, se envía un mensaje de descarga de sesión. Por ejemplo, la infraestructura de rastreo de sesión 2002 puede enviar un mensaje de descarga de sesión 2008 (D) al administrador de rastreo de sesión distribuida 2010 utilizando el protocolo de comunicación confiable. En el bloque 2128, el mensaje de descarga de sesión es recibido. Por ejemplo, el administrador de rastreo de sesión distribuida 2010 puede · residir el mensaje de descarga de sesión 2008 (D) de la infraestructura de rastreo de sesión 2002 de acuerdo con el protocolo de comunicación confiable. En el bloque 2130, se destruye la entrada de información de sesión. Por ejemplo, el administrador de rastreo de sesión distribuida 2010 puede destruir la entrada de información de sesión en la información de sesión 1902 guardada en memoria caché en cualquiera de las unidades de equilibrio de carga 106 que tengan la entrada de información de sesión. Ejemplos de dicha destrucción y subsecuente elimina se describen más adelante en especial con referencia a las Figuras 22 y 23B. La Figura 22 ilustra un aspecto ilustrativo para administrar información de sesión en múltiples unidades de equilibrio de cargar 106. Cada unidad de equilibrio de carga respectiva 106 (1 ), 106 (2) ... 106 (u) incluye una parte respectiva 2202 (1), 2202 (2) ... 2202 (u) de un administrador de átomo distribuido (DAM) 2202. El DAM 2202 es una implementación ilustrativa del administrador de rastreo de sesión distribuida 2010. Cada porción DAM respectiva 2202 (1), 2202 (2) ... 2202 (u) incluye una parte respectiva 2206 (1), 2206 (2) ... 2206 (u) de una tabla de DAM (DAMT) 2206. El DAM 2202 es una aplicación distribuida o servicio virtual que administra la información de sesión 1902 en una forma confiable y escalable, de manera que la funcionalidad de enrutamiento de tráfico 2012 puede utilizarla para conservar la afinidad de la sesión. Por ejemplo, la funcionalidad de enrutamiento de tráfico 2012 puede accesar al DAM 2202 utilizando una API (no mostrada específicamente) para buscar o haber buscado la DAM 2206. La función llama a 2204, la operación de DAM 2202, y otros aspectos de la Figura 22 se describen más adelante después de la descripción de las Figuras 23A y 23B. La Figura 23A es una tabla de sesión 2014 ilustrativa como se muestra en la Figura 20. La tabla de sesión 2014 incluye las entradas "v" 2302 (1), 2302 (2) ... 2302 (v). Cada entrada 2302 es insertada en la infraestructura de rastreo de sesión 2002 en respuesta a una notificación de establecimiento de sesión 2006 (E) que es aceptada de una aplicación 316. Cada entrada 2302 es removida por la infraestructura de rastreo de sesión 2002 que responde a una notificación de terminación de sesión 2006 (T) que es aceptada de la aplicación 316. Como se describió anteriormente, cada notificación de establecimiento de sesión 2006 (E) incluye un identificador de sesión y opcionalmente un identificador de aplicación 316. Cada entrada respectiva 2302 (1 ), 2302 (2) ... 2302 (v) en la tabla de sesión 2014 incluye campos respectivos de (i) un identificador de sesión 2302 (11), 2302 (21) ... 2302 (vi) y (ii) un tipo de sesión y/o aplicación 2302 (1T), 2302 (2T) ... 2302 (vT). El tipo de sesión y/o aplicación 2302 (T) puede ser "TCP", "IPSEC", "Servidor de Termina", "galleta de HTTP", un tipo de aplicación como se observó anteriormente, etc. El identificador de sesión 2302 (I) puede ser "<dirección de IP puente, puerto de TCP fuente, dirección de IP de destino, puerto de TCP de destino>", "IP de cliente = 172.30.189.122", "usuario = 'usuariojoe'", "galleta = '{b7595cc9-e68b-4eb0-9bf1-bb717b31d447}"', otra identificación de aplicación específica para una sesión, etc. Para tipos de conexión/sesión de TCP, el identif icador de sesión 2302 (I) alternativamente puede ser una versión canónica de la 4-tupla de TCP (para IPv4 o IPv6). Otros valores para los campos del identificador de sesión 2302 (I) y tipo de aplicación/sección 2302 (T) alternativamente pueden ser utilizados. La Figura 23B es una tabla de administración de átomo distribuido (DAM) (DAMT) ilustrativo 2206 como se muestra en la Figura 22. La tabla de DAM 2206 incluye "w" entradas 2304 (1), 2304 (2) ... 2304 (w). Cada entrada de información de sesión 2304 es creada por el DAM 2202 en respuesta a un mensaje de carga de sesión 2008 (U) que es recibido de la infraestructura de rastreo de sesión 2002. Cada entrada de información de sesión 2304 es destruida en respuesta a un mensaje de descarga de sesión 2008 (D) que es recibido de la infraestructura de rastreo de sesión 2002. Como describe más adelante, las entradas de información de sesión 304 de las tablas de DAM 2206 en realidad puede ser manipulada por el DAM 2202 utilizando las llamadas de función 2204. Como se describió anteriormente, el mensaje de carga de sesión 2008 (U) incluye el identificador de sesión, un identificador de huésped, y opcionalmente otra información. Cada entrada de información de sesión respectiva 2304 (1), 2304 (2) ... 2304 (w) en la tabla de DAM 2206 incluye campos respectivos de (i) clave 2304 (1K), 2340 (2K) ... 2304 (wK), (ii) datos 2304 (1 D, 2304 (2D) ... 2304 (wD), y (iii) metadatos 2304 (1 M), 2304 (2M) ... 2304 (wM). Por ejemplo, los valores para los campos de la clave 2304 (K) pueden ser cadenas alfanuméricas, y los valores para los campos de datos 2304 (D) pueden ser bits binarios. Los valores para las claves 2304 (K) pueden ser bits binarios también. La clave 2304 (K) puede corresponder al identificador de sesión 2302 (I). Los datos 2304 (D) pueden corresponder al identificador de huésped, tal como una dirección de red del huésped 108 en la cual existe el contexto de sesión. Los metadatos 2304 (M) pueden corresponder a otra información opcional. Ejemplos de tales metadatos 2304 (M) incluyen datos que son utilizados internamente por el DAM 2202 para resolver colisiones de átomos y para rastrear la actividad del átomo (por ejemplo, a través de un mecanismo de un tiempo fuera). (Esta caracterización de entradas 2304 como atómicas se describe más completamente en el siguiente párrafo). Más específicamente, los metadatos 2304 (M) incluyen, entre otras cosas, la identificación de la identidad (por ejemplo, la instancia de funcionalidad de enrutamiento de tráfico 2012, que agrega la entrada de información de sesión 2304 a la tabla de DAM 2206. En una implementación descrita, cada entrada de información de sesión 2304 es atómica en el sentido de que DAM 2202 puede agregar, eliminar, copiar, etc., las entradas 2304 como un todo, pero DAM 2202 ordinariamente no puede modificar una porción de ninguna entrada total 2304. De esta manera, las entradas atómicas 2304 son agregadas, eliminadas, copiadas, o de otra manera manipuladas, etc., a través de las tablas de DAM 2606 mediante el DAM 2202 con el fin de implementar disponibilidad y escalabilidad para una ¡mplementación de conservación de actividad de sesión. Las llamadas de función 2204 (de la Figura 22) se pueden utilizar por el DAM 2202 para manipular las entradas atómicas 2304 de la tabla de DAM 2206. Las llamadas de función 2204 pueden ser comunicadas de una unidad de equilibrio de carga 106 a una o más de las otras unidades de equilibrio de carga 106 en una forma de punto a punto o de multidif usión . Estas llamadas de función incluyen agregar el átomo 2204 (A), eliminar el átomo 2204 (D), consultar el átomo 2204 (U), y regresar el átomo 2204 (R). La adición del átomo 2204 (A) toma la forma de agregar átomos (clave, datos) y se utiliza para agregar una entrada atómica 2304 a una o más tablas de DAM 2206. Por lo tanto, una llamada de función de átomo de adición 2204 (A) puede ser formulada como Agregar Atomo ( < i d e n ti f icador de sesión>, dirección de IP huésped). El átomo de eliminación 2204 (D) toma la forma de Eliminar Atomo (Clave) y se utiliza para eliminar una entrada Atómica 2304 en una o más tablas de DAM 2206. Las llamadas de función de eliminar átomo 2204 (D) pueden ser dirigidas a aquellas tablas de DAM 2206 conocidas por tener una copia de la sesión que es identificada por la clave 2304 (K) o pueden ser multidifundidas a todas las tablas de DAM 2206 para asegurar que cualquier copia es eliminada. El átomo de consulta 2204 (Q) toma la forma de consultar átomo (clave) y se utiliza por una porción de DAM 2202 particular cuando un identificación de sesión, referenciado por una solicitud de conexión de entrada, es localizado en la tabla de DAM 2206 local particular de la porción de DAM 2202 particular. Las llamadas de función de consultar átomo 2204 (Q) son enviadas a una o más de las otras porciones de DAM 2202 (incluyendo posiblemente todas).

En respuesta, cada porción de DAM 2202 verifica su tabla de DAM local 2206 para el identificador de clave/sesión. Si la clave es localizada por otra porción de DAM 2202, esta otra porción de DAM 2202 contesta con un átomo de regreso 2204 (R). El átomo de regreso 2204 (R) toma la forma de regresar átomo (clave, datos) y se utiliza para contestar a una llamada de función de átomo de consulta 2204 (Q). Las llamadas de función de átomo de regreso 2204 (R) se utilizan cuando una porción de DAM 2202 tiene una entrada atómica solicitada 2304 en su tabla de DAM 2206 local identificada por una clave 2304 (K) especificada en la llamada de función de átomo de consulta 2204 (Q). Las llamadas de función de átomo de regreso 2204 (R) pueden ser dirigidas de regreso a la porción de DAM 2202 que emiten la llamada de función de átomo de consulta 2204 (Q). Las llamadas de función de átomo de adición 2204 (A) se utilizan en respuesta a los mensajes de carga de sesión 2008 (U) y/o para replicar una entrada atómica 2304 a una o más de las otras tablas de DAM 2206. Dicha replicación puede ser para redundancia y/o estabilidad. Las llamadas de función de átomo de eliminación 2204 (D) se utilizan en respuesta a los mensajes de descarga de sesión 2008 (D) y también pueden ser enviadas a una o más de las otras tablas de DAM 2206. Después de que se elimina una entrada atómica 2304, la entrada atómica 2304 puede introducir un estado de "zombi", de manera que permanece con el DAM 2202, y opcionalmente en realidad sigue almacenado con la tabla de DAM 2206 con una indicación de zombi en el campo de metadatos 2304 (M) de la entrada atómica 2304. De esta manera, una vez que se elimina una entrada atómica 2304, puede permanecer en el DAM 2202 y la tabla de DAM 2206 en un estado zombi de manera que los paquetes para esta sesión (ahora muertos y cerrados) son dirigidos al huésped 108 de contexto de sesión para un tratamiento apropiado, de protocolo específico. Por ejemplo, los paquetes de TCP recibidos después de que se ha interrumpido una conexión de TCP, son dirigidos al huésped 108 que terminó la conexión. Este huésped 108 puede responder apropiadamente, tal vez enviando un RST o enviando un FIN-ACK. El tiempo que la entrada atómica 2304 gasta en este estado zombi coincide con (lo más estrecha y razonablemente posible) con el tiempo muerto de protocolo específico del protocolo de comunicación confiable que se está empleando. Una llamada de función de átomo de consulta 2204 (Q) se utiliza para obtener una entrada atómica 2304 cuando una primera unidad de equilibrio de carga 106 recibe una solicitud de conexión de entrada que hace referencia a una sesión que no está almacenada en la tabla de DAM local 2206 del DAM 2202 de la primera unidad de equilibrio de carba 106. Se debe observar que otras porciones de DAM 2202 pueden ser consultadas simultáneamente en una llamada de función de átomo de consulta 2204 (Q) de difusión o secuencialmente hasta que se recibe una llamada de función de átomo de regreso positiva 2204 (R). Una llamada de función de átomo de regreso 2204 (R) se utiliza por una porción de DAM 2202 de una segunda unidad de equilibrio de carga 106 para proporcionar una entrada atómica 2304 a la porción de DAM 2202 de la primera unidad de equilibrio de carga 106, cuando la entrada atómica 2304 tiene una clave 2304 (K) que es especificada por el identificador de clave/sesión en una llamada de función de átomo de consulta 2204 (Q), que se emitió previamente por la porción de DAM 2202 de la primera unidad de equilibrio de carga 106. Se debe observar que otros componentes, tales como la funcionalidad de enrutamiento de tráfico 2012, también puede ser capaz de funciones de llamada 2204, especialmente una llamada de función de átomo de consulta 2204 (Q), de acuerdo con una API o similar. Las porciones de DAM 2202 y las tablas de DAM 2206 pueden ser organizadas y administradas en una miríada de formas. Las formas ilustrativas se refieren a replicación/redundancia, almacenamiento en memoria caché local después de adquisición, verificación para selección de localización, etc. Se pueden emplear 0, 1, 2, o más niveles de replicación hasta la replicación completa. Con un nivel de cero de replicación, cada entrada atómica 2304 es almacenada en el DAM 2202 que recibe un mensaje de carga de sesión 2008 (U) para el mismo sin replicación a otras porciones de DAM 2202. Como un primer nivel de replicación, cada entrada atómica 2304 es almacenada en el DAM 2202 que recibe un mensaje de carga de sesión 2008 (U) para el mismo, y también se agrega (copia) a otra porción de DAM 2202 utilizando una llamada de función de átomo de adición 2204 (A). Esto maneja un nivel de falla para una unidad de equilibrio de carga 106. Similarmente, con un segundo nivel de replicación, cada entrada atómica 2304 es almacenada en el DAM 2202 que recibe un mensaje de carga de sesión 2008 (U) para el mismo, y también se agrega a otras dos porciones de DAM 2202. En general, una, dos, etc., y otras porciones de DAM 2202 a las cuales una porción de DAM dada 2202 copia entradas atómicas 2304, es predeterminada o seleccionada en forma aleatoria. También se pueden emplear tercero, cuarto, etc., niveles de replicación. Además, la replicación completa puede ser empleada teniendo cada entrada atómica 2304 que está almacenada en el DAM 2202 que recibe un mensaje de carga de sesión 2008 (U) para el mismo también agregado a otra porción de DAM 2202. Varios factores se ven impactados por la selección del nivel de replicación: a medida que el nivel de replicación se incrementa, la disponibilidad se incrementa y la latencia se reduce. Por otro lado, el tráfico de red y el uso de memoria ambos se incrementan a medida que el nivel de replicación se incrementa. Cuando no se emplea una replicación total, se puede presentar el almacenamiento en memoria caché local después de la adquisición. Por ejemplo, cuando una porción de DAM 2202 no ubica un ¡dentificador de sesión referenciado en su parte de la tabla de DAM 2206, la porción de DAM 2202 emite una llamada de función de átomo de consulta 2204 (Q) para obtener la entrada atómica 2304 asociada con el identificador de sesión referenciado a través de una llamada de función de átomo de regreso 2204 (R). En lugar de descartar la entrada atómica obtenida 2304 después de uso, la porción de DAM 2202 almacena en memoria caché la entrada atómica obtenida 2304 en su parte de la tabla de DAM 2206. Esta opción ofrece un comercio entre los factores enumerados anteriormente. Como otra opción cuando se emplea la replicación total, se puede presentar la verificación de la selección de ubicación. La primera entrada atómica 2304 para una sesión es almacenada en la porción de DAM 2202 que recibe el mensaje de carga de sesión 2008 (U). La copia o copias replicadas son enviadas a través de las llamadas de función de átomo de adición 2204 (A) a las porciones de DAM 2202 específicas utilizando una función de verificación. De la escala total de posibles valores de verificación, a cada porción de DAM 2202 se le asigna un subgrupo de esto. Cada ¡dentificador de sesión es verificado utilizando alguna función de verificación para llegar a un valor de verificación. Este valor de verificación es trazado a las porciones de DAM 2202 asignadas. La porción de DAM 2202 que primero es agregada a la entrada atómica 2304 entonces replica la entrada atómica 2304 a la porción de DAM 2202 asignada.

Con la verificación para la selección de ubicación, por lo menos una porción de DAM 2202 que tiene una entrada atómica deseada 2304 localmente almacenada en memoria caché en su tabla de DAM 2206, es reconocible del identif icador de sesión. Por lo tanto, una llamada de función de átomo de consulta 2204 (Q) puede ser dirigida a las porciones de DAM 2202 conocida. Esto usualmente reduce el tráfico de red y/o latencia. Esta verificación para selección de ubicación puede ser utilizada con 1, 2, 3 o más niveles de replicación cada uno en la escala de valores de verificación trazándose a una, dos, tres, etc., diferentes porciones de DAM 2202, respectivamente. Además, la verificación para la selección de ubicación puede ser utilizada con almacenamiento en memoria caché local después de adquisición. La Figura 24 es un diagrama de flujo 2400 que muestra un método ilustrativo para manejar la información de sesión en múltiples unidades de equilibrio de carga. El diagrama de flujo 2400 incluye 8 bloques 2402-2416. Aunque las acciones del diagrama de flujo 2400 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, se utilizan las Figuras 1-3, 19, 20, 22, y 23B en particular para ilustrar ciertos aspectos y ejemplos del método. En el bloque 2402, se analiza una solicitud de conexión de entrada con una referencia de sesión. Por ejemplo, la funcionalidad de enrutamiento de tráfico 2012 puede recibir una solicitud de conexión de entrada que hace referencia a una sesión previamente abierta/establecida de un tipo particular. En el bloque 2404, se busca una tabla de DAM local utilizando la referencia de sesión. Por ejemplo, para una unidad de equilibrio de carga 106 dada y una funcionalidad de enrutamiento de tráfico 2012 dada, la porción de DAM 2202 de los mismos puede buscar su tabla de DAM 2206 correspondiente buscando la referencia de sesión. En el bloque 2406, se determina si la referencia de sesión coincide con una clave de la tabla de DAM local. Por ejemplo, la porción de DAM 2202 puede buscar campos de clave 2304 (K) de múltiples entradas 2304 de la tabla de DAM 2202 para determinar si la referencia de sesión coincide con cualquiera de los valores de los campos de clave 2304 (K). Si es así, el diagrama de flujo 2400 continúa al bloque 2412. Por otro lado, si la referencia de sesión no coincide con ninguna clave, el diagrama de flujo 2400 continua al bloque 2408. En el bloque 2408, se hace una llamada de función de átomo de consulta. Por ejemplo, la porción de DAM 2202 puede hacer una llamada de función de átomo de consulta 2204 (Q) que incluye la referencia/identificador de sesión como la clave. La llamada de función de átomo de consulta 2204 (Q) puede ser enviada a por lo menos otra porción de DAM 2202. El número, selección, orden, etc., de posibles porciones de DAM de destino 2202 para el átomo de consulta 2204 (Q) puede depender de las opciones (por ejemplo, nivel de replicación, verificación para selección de ubicación, almacenamiento en memoria caché local después de adquisición, punto a punto contra multidifusión, etc.) empleadas por el DAM 2202.

En el bloque 2410, se recibe un átomo regresado. Por ejemplo, la información de una llamada de función de átomo regresado 2204 (R) que es emitida por otra porción de DAM 2202, puede ser recibida. La otra porción de DAM 2202 exitosamente ubicó una entrada atómica 2304 en su tabla de DAM correspondiente 2206, la entrada atómica localizada 2304 teniendo una clave que coincide con la referencia de sesión. La información de la llamada de función de átomo regresado 2204 (R) incluye valores del campo de clave 2304 (K) y el campo de datos 2304 (D) para la entrada atómica localizada 2304. Estos valores corresponden al identificador de sesión de la sesión y la dirección de red del huésped 108 que tiene afinidad con la sesión. En el bloque 2412, se extrae una entrada atómica. La entrada atómica es extraída de la tabla DAM local si encuentra localmente una coincidencia (en los bloques 2404 y 2406) o del átomo regresado si se encuentra una coincidencia en cualquier parte (en los bloques 2408 y 2410). Por ejemplo, una entrada atómica 2304 puede ser extraída de la tabla de DAM 2206 de la porción de DAM 2202 o de la información recibida por una llamada de función de átomo de regreso 2204 (R). La entrada atómica extraída 2304 puede ser almacenada en memoria caché en la tabla de DAM local 2206 si se recibió como resultado de la llamada de función de átomo de regreso 2204 (R). En el bloque 2414, el huésped que tiene afinidad de sesión con la sesión de referencia es determinado de la entrada atómica. Por ejemplo, un valor de campo de datos 2304 (D) de la entrada atómica extraída 2304 puede ser determinado, permitiendo así una dirección de red del huésped de afinidad 108. En el bloque 2416, la solicitud de conexión de entrada es enrutada al huésped determinado. Por ejemplo, la funcionalidad de enrutamiento de tráfico 2012 y la funcionalidad de envío pueden enrutar a la solicitud de conexión de entrada que tiene la referencia de sesión hacia el huésped determinado y de afinidad 108. Las funcionalidades ilustrativas de clasificación, enrutamiento de solicitud y envío se describen en la siguiente sección.

Clasificación, Envío y Enrutamiento de Solicitud Ilustrativos Esta sección describe como el enrutamiento de tráfico puede ser implementado para el equilibrio de carga de red, incluyendo con respecto a la alta disponibilidad de dicha función de enrutamiento de tráfico. La funcionalidad -de enrutamiento de tráfico puede incluir la funcionalidad de clasificar y/o enrutar la solicitud, especialmente junto con la funcionalidad de envío. Esta sección principalmente hace referencia a la Figura 25-31. Ilustra la funcionalidad de un enrutador de solicitud 306 (de la Figura 3), una interrelación entre la sesión de rastreo y utilizar la información de salud y carga cuando hay enrutamiento de tráfico, implementaciones operacionales para interacciones de enrutamiento de tráfico con información de sesión y/o información de salud y carga, procedimientos de falla para alta disponibilidad de infraestructura de equilibrio de carga de red (incluyendo fallas en el manejo de los componentes de clasificación, envío, y/o enrutamiento de solicitud), configuraciones de infraestructura de equilibrio de carga de red adicionales, etc. La Figura 25 ilustra una infraestructura de equilibrio de carga de red ilustrativa que tiene la funcionalidad de enrutamiento de solicitud como es realizada por el enrutador de solicitud 306 (H/S). Como se observó anteriormente con referencia a la funcionalidad de enrutamiento de tráfico 2012, el enrutamiento de tráfico puede estar relacionado con la clasificación (por ejemplo, con el envío) y/o enrutamiento de solicitud. La clasificación, junto con el envío, a nivel de paquete se describió anteriormente con referencia particular a la Figura 4. El enrutamiento de solicitud se describe aquí con referencia particular a la Figura 25. El enrutamiento a nivel de solicitud ocurre a un nivel más alto que aquel del enrutamiento a nivel de paquete. En general, un enrutador de solicitud 306 actúa como un proxi para una aplicación 316 que corre en un huésped 108. El enrutador de solicitud 306 termina las conexiones de TCP, analiza (tal vez parcialmente) cada solicitud de un cliente 102, y vuelve a someter cada solicitud al huésped 108. El enrutador de solicitud 306 puede realizar el pre- procesamiento en la conexión, tal como una descodificación críptica de SSL. También, el enrutador de solicitud 306 puede elegir absorbencia en las solicitudes (por ejemplo, el enrutador de solicitud puede mantener una memoria caché de respuesta), y puede "arbitrariamente" modificar solicitudes antes de enviarlas a los huésped 108.

Los enrutadores de solicitud 106 usualmente son de aplicación específica, y más bien pueden ser de extremo abierto ya que son capaces de realizarse. A manera de ejemplo solamente, una clase individual de enrutadores de solicitud 306, enrutadores de solicitud HTTP/SSL (H/S), es dirigida en la siguiente descripción. Como se ¡lustra, un cliente 102 que tiene una dirección de red C1 se comunica a través de la red 104 con los huéspedes 108 (1) y 108 (2) teniendo direcciones de red H1 y H2, respectivamente. Las comunicaciones son efectuadas a través de la infraestructura de equilibrio de carga que incluye un enrutador de solicitud HTTP/SSL 306 (H/S). El enrutador de solicitud HTTP/SSL 306 (H/S) termina el tráfico de HTTP y SSL, descodifica crípticamente el tráfico SSL, examina cada solicitud de HTTP del cliente 102, aplica reglas de aplicación específica para clasificar cada solicitud y para determinar el mejor punto extremo para esa solicitud mientras se toma en cuenta la información de salud y carga de punto extremo de la aplicación, y presenta la solicitud al punto extremo. La presentación de solicitud al punto extremo utiliza una conexión de TCP separada de aquella de una originada por el cliente 102 (la última conexión es terminada en el enrutador de solicitud de HTTP/SSL 306 (H/S)). Estas acciones pueden ser consideradas como lógicamente equivalentes a las acciones realizadas por un clasificador 304, pero surge una diferencia en que estas acciones y en el enrutador de solicitud HTTP/SSL 306 (H/S) están ocurriendo al nivel de solicitud lógico para cada solicitud dentro de la conexión de TCP. El enrutador de solicitud de HTTP/SSL 306 (H/S), y los enrutadores de solicitud 306 en general, pueden utilizar la misma (i) salud y carga de aplicación y (ii) infraestructura de rastreo de sesión que se utiliza por los clasificadores 304. El enrutador de solicitud HTTP/SSL 306 (H/S) está actuando como un intermediario entre el cliente 102 y dos huéspedes 108 (1) y 108 (2). Está manejando dos solicitudes del cliente 102 a través de una sola conexión de TCP. En una implementación descrita, el enrutamiento de solicitud resultante involucra un número de acciones. Primero, el cliente 102 establece una conexión [1] de http o https al enrutador de solicitud de solicitud HTTP/SSL 306 (H/S) y envía una solicitud #1 2502 (1). Segundo lugar, el enrutador de solicitud HTTP/SSL 306 (H/S) termina la sesión de SSL (si el tráfico es SSL codificado crípticamente), analiza la solicitud #1 2502 (1 ) y examina el contenido de la solicitud #1 2502 (1 ). Tomando en cuenta la salud y carga de aplicación así como la información de sesión, el enrutador de solicitud de HTTP/SSL 304 (H/S) determina que el huésped 108 (1) es el "mejor" huésped para esta solicitud particular #1 2502 (1) en este ejemplo. En tercer lugar, el enrutador de solicitud HTTP/SSL 306 (H/S) establece una conexión de TCP secundaria [2] al huésped 108 (1). Esta segunda conexión de TCP no está conectada mediante una fuente de una dirección de VIP a través de la red 104; más bien, está en fuente a partir de una dirección (no mostrada en la Figura 25) que está dedicada al enrutador de solicitud 306 (H/S) para asegurar que las respuestas 2504 del huésped(es) 108 lleguen al enrutador de solicitud 306 correcto. (Puede haber múltiples enrutadores de solicitud 396 que están activos, aunque sólo un enrutador de solicitud 306 (H/S) se muestra en la Figura 25 para claridad). Alternativamente, se puede utilizar una conexión existente [2] al huésped 108(1). El enrutador de solicitud de HTTP/SSL 306 (H/S) después envía, por ejemplo, una versión no codificada crípticamente de la solicitud #1 2502(1 ) al huésped 108 (1). En cuarto lugar, el huésped 108 (1) contesta con una respuesta #| 2504(1 ). En quinto lugar, el enrutador de solicitud de HTTP/SSL 306 (H/S) codifica crípticamente esta respuesta #1 2504 (1) y la envía de regreso al cliente 102 a través de la conexión de TCP [1]. En sexto lugar, el cliente 102 envía otra solicitud, solicitud #2 2502 (2). La solicitud #2 1502 (2) es manejada en forma similar al manejo de la solicitud #1 2502 (1), excepto que el enrutador de solicitud de solicitud HTTP/SSL 306 (H/S) selecciona al huésped 108 (2). La diferente selección puede ser porque el huésped 108 (1) ahora está fallando o está más pesadamente cargado, ya que la solicitud #2 2502 (2) se dirige a un URL diferente que el de la solicitud #1 2502 (1 ), y así sucesivamente. En otro aspecto, el enrutador de solicitud HTTP/SSL 306 (H/S) establece otra conexión de TCP secundaria, pero esta conexión de TCP secundaria [3] es al huésped 108 (2). La solicitud #2 2502 (2) no codificada crípticamente es enrutada al huésped 108 (2), y se recibe de ahí una respuesta #2 2504 (2) como resultado. Una versión codificada crípticamente de la respuesta #2 2504 (2) después es enviada al cliente 102 del enrutador de solicitud de HTTP/SSL 306 (H/S). En séptimo lugar, el cliente 102 cierra la conexión de TCP [1] con el enrutador de solicitud de HTTP/SSL 306 (H/S). El enrutador de solicitud de HTTP/SSL 306 (H/S) (en un futuro cercano) cierra las conexiones [2] y [3] que hizo con los huéspedes 108 (1) y 108 (2), respectivamente, a favor del cliente 102. La conexión de TCP [2] alternativamente puede ser cerrada después de que el enrutador de solicitud de HTTP/SSL 306 (H/S) decide abrir/utilizar la conexión de TCP [3] para la solicitud #2 2502 (2). Ya que un enrutador de solicitud de HTTP/SSL 306 (H/S) termina la conexión de http/https, el enrutador de solicitud de HTTP/SSL 306 (H/S) puede hacerse más que enrutar solicitudes. Por ejemplo, el enrutador de solicitud de HTTP/SSL 306 (H/S) potencialmente puede mantener su propia memoria caché de respuestas (por ejemplo, con un mecanismo de fuera de banda para invalidar la memoria caché). Como se observó en el ejemplo anterior, el enrutador de solicitud de HTTP/SSL 306 (H/S) potencialmente también puede enrutar diferentes tipos de solicitudes a diferentes grupos de huéspedes 108 basándose en, por ejemplo, el URL solicitado. En forma inversa, el enrutador de solicitud de HTTP/SSL 306 (H/S) potencialmente puede agregar solicitudes de muchas conexiones de cliente de vida corta y enviarlas a través de pocas conexiones de TCP de larga duración a los huéspedes 108. Dicha agregación de conexión puede reducir la carga general de procesamiento de la conexión de TCP en los huéspedes 108. Los enrutadores de solicitud de otras clases pueden corresponder a otros protocolos ilustrativos además de HTTP. Por ejemplo, un enrutador de solicitud puede ser un enrutador de solicitud de SOAP. Los enrutadores de solicitud de SOAP funcionan análogamente a un enrutador de solicitud de HTTP/SSL 306 (H/S). Sin embargo, los enrutadores de solicitud de SOAP se especializan en enrutar tráfico de SOAP. Los enrutadores de solicitud de SOAP entienden a los encabezados de SOAP y hacen decisiones de enrutamiento basándose en los encabezados de SOAP así como salud y carga de aplicación. Tanto la clasificación como el envío a nivel de paquete (o enrutamiento a nivel de paquete) y enrutamiento a nivel de solicitud pueden proporcionar alguna forma de equilibrio de carga de siete capas. El equilibrio de carga de siete capas se describe más adelante en la sección intitulada "Migración de Conexión Ilustrativa con Tunelización opcional y/o equilibrio de carga a nivel de aplicación". El enrutamiento a nivel de paquete proporciona acceso de solo lectura a la porción inicial de datos de conexión de TCP de un cliente, y el enrutamiento a nivel solicitud proporciona lectura y modificación de acceso a toda una corriente de datos. El enrutamiento a nivel de paquete típicamente tiene varias ventajas sobre el enrutamiento a nivel de solicitud. Estas ventajas incluyen transparencia (paquetes de cliente son entregados a huéspedes como tales, conservando las direcciones de IP de fuente y de destino y números de puerto), baja carga general de procesamiento (generalmente, el envío de tráfico involucra una consulta de ruta), una baja latencia (los paquetes individuales son enviados, y los paquetes no son formados de cola una vez que se ha termina el destino de conexión de TCP); y una alta disponibilidad (en general, una falla en un expedidor no termina la conexión de TCP). El enrutamiento a nivel solicitud, por otro lado, típicamente tiene la siguientes ventajas sobre el enrutamiento a nivel de paquete: una habilidad para examinar toda una corriente de datos que fluye hacia y del cliente; y una habilidad para transformar una corriente de datos, y aún para dividir la corriente de datos entre múltiples huéspedes o agregar las corrientes de datos de múltiples clientes. La Figura 26 es un diagrama de flujo 2600 que muestra un método ilustrativo para enrutar paquetes de entrada con respecto a (i) información de sesión y (ii) información de salud y carga. El diagrama de flujo 2600 incluye ocho bloques 1602-2616. Aunque las acciones del diagrama de flujo 2600 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, las Figuras 1-3, 12, 18-20, 22 y 23B son utilizadas en particular para ilustrar ciertos aspectos y ejemplos del método. En el bloque 2602, se recibe un paquete de entrada. Por ejemplo, un paquete de un cliente 102 puede ser recibido en un expedidor 302 de una unidad de equilibrio de carga 106. En el bloque 2604, se determina si el paquete recibido es para una sesión preexistente. Por ejemplo, el expedidor 302 puede consultar una tabla de DAM local 2606 () para determinar que el paquete recibido ya es parte de una sesión de TCP/IP. Además, el expedidor 302 puede consultar la tabla de DAM local 2206 () y determinar que el paquete recibido ya no es parte de una sesión de TCP/IP. En este caso, el expedidor 302 proporciona el paquete recibido a un clasificador 304, en cual verifica una afinidad de sesión de nivel más alto para el paquete recibido si tiene una referencia de sesión. Ejemplos para estas acciones se describieron anteriormente con referencia particular a la Figura 24, y más adelante con referencia particular a las Figuras 27 y 28. Si el paquete recibido es para una sesión preexistente (según determinado en el bloque 2604), entonces el flujo continúa en el bloque 2606. En el bloque 2606, un huésped que tiene afinidad con la sesión preexistente, es determinado. Por ejemplo, un huésped con afinidad 108 puede ser determinado a partir del DAM local 2206 () y/o del DAM totalmente distribuido 2206 a través del expedidor 302 o clasificador 304. En el bloque 2608, se determina si el huésped con afinidad es saludable. Por ejemplo, el clasificador 304 puede consultar una memoria caché de salud y carga consolidada 1208 para determinar si el huésped con afinidad 108 es saludable, especialmente para aquellos paquetes recibidos que son parte de sesiones que son de un nivel lógico más alto que el de las sesiones de TCP/IP. Las acciones de este bloque pueden ser logradas junto con un manejador de salud y carga 314. Si el huésped con afinidad es saludable (según determinado en el bloque 2608), entonces el flujo continúa al bloque 2610. En el bloque 2610, el paquete recibido es enrutado al huésped con afinidad. Por ejemplo, el expedidor 302 (para sesiones de TCP/IP) o el clasificador 304 (para sesiones de nivel más alto) puede enrutar el paquete hacia el huésped 108 con afinidad. En una implementación alternativa, el clasificador 304 puede regresar el paquete recibido al expedidor 302 para enrutarlo al huésped 108 con afinidad aún para paquetes recibidos que son parte de sesiones de nivel más alto. Por otro lado, si el huésped con afinidad no es saludable (según determinado en el bloque 2608), entonces el flujo continúa en el bloque 2612. También, si por otro lado el paquete recibido no es para una sesión preexistente (según determinado en el bloque 2604, entonces el flujo continúa en el bloque 2612. En el bloque 2612, un huésped es seleccionado en respuesta a la información de salud y carga. Por ejemplo, el clasificador 304 puede seleccionar un huésped 108 de y/o utilizando una distribución de aplicación relacionada con salud y carga (por ejemplo, de una respuesta de distribución de punto extremo de aplicación objetivo 1804) que ese obtiene del manejador de salud y carga 314. Los ejemplos para estas acciones se describieron anteriormente con referencia particular a las Figuras 19 y 18, y se describen más adelante con referencia particular a la Figura 30. En el bloque 2614, el paquete recibido es enrutado al huésped seleccionado. Por ejemplo, el clasificador 304 puede enrutar (opcionalmente a través del expedidor 302) el paquete al huésped 108 seleccionado. En el bloque 2616, se aploma una ruta para una trayectoria de conexión al huésped seleccionado. Por ejemplo, el clasificador 304 puede agregar una entrada de información de sesión a la tabla de DAM 2206, en especial en la tabla de DAM 2206 () que es local al expedidor 302 que proporcionó el paquete recibido al clasificador 304. Esta entrada de información de sesión puede ser replicada de acuerdo con la política de redundancia instituida para un DAM 2202 (por ejemplo, de un rastreador de sesión 308). Las acciones del bloque 2614 y aquellas del bloque 2616 pueden ser realizadas en el orden específicamente ilustrado, las acciones del bloque 2616 siendo realizadas antes del bloque 2614, las acciones parcial o totalmente traslapando el cualquier orden, y así sucesivamente. Se debe observar que las acciones realizadas por el clasificador 304, como se describió anteriormente, pueden ser realizadas alternativamente por un enrutador de solicitud 306 (o más en general la funcionalidad de enrutamiento de tráfico 2012). Además del enrutamiento a nivel de paquete y a nivel de solicitud, también se puede utilizar la funcionalidad de enrutamiento de tráfico como se describe aquí (por ejemplo, la funcionalidad de enrutamiento de tráfico 2012, un enrutador de solicitud 306, un par de emisor 302/clasíf icador 304, etc.) para implementar la funcionalidad de pared de fuego (firewall). Por lo tanto, un aspecto de la funcionalidad de enrutamiento de tráfico puede incluir bloquear tráfico, en lugar de automáticamente enrutar el tráfico hacia el huésped 108 correcto. Por ejemplo, un clasificador 304 puede inspeccionar el tráfico y disminuirlo si se considera inseguro. La Figura 27 ¡lustra un flujo de enrutamiento de tráfico ilustrativo en ausencia de fallas. Como se ilustra, un o más interruptores 202 al pendiente del equilibrio de carga (LBA) se encuentran enfrente de la infraestructura de equilibrio de carga restante 106 (no indicada en forma separada). Las funcionalidades de envío y clasificación son. distribuidas a través de tres dispositivos o nodos. Un primer dispositivo incluye el expedidor 302 (1) y el clasificador 304 (1). Un segundo dispositivo incluye el clasificador 304 (2). Un tercer dispositivo incluye el expedidor 302 (2). Con el clasificador 304 (2) ejecutándose en el segundo dispositivo y el expedidor 302 (2) ejecutándose en el tercer dispositivo cada dispositivo puede ser especialmente sintonizado para sus funciones respectivas. Por ejemplo, el hardware, software, firmware, y alguna combinación de éstos, etc., del segundo dispositivo y el tercer dispositivo pueden ser adaptados para soportar la funcionalidad deseada sin un provisionamiento excesivo. De esta manera, el tercer dispositivo que incluye el expedidor 302 (2) puede ser similar a un conmutador y/o enrutador desde una perspectiva de capacidad de hardware, el segundo dispositivo que incluye el clasificador 304 (2) puede ser más semejante a un servidor y/o computadora personal a partir de una perspectiva de capacidad de hardware.

Aunque mostrados como tres dispositivos que están proporcionando funcionalidad a través de cuatro componentes, las configuraciones alternativas a nivel lógico y/o de dispositivo para la funcionalidad de envío y clasificación son aplicables al flujo de enrutamiento de tráfico ilustrativo que se describe aquí para Figura 27. También, aunque los destinos de enrutamiento se muestran como huéspedes 108, las descripciones aquí de implementaciones de enrutamiento alternativamente pueden ser aplicadas en forma más general a un siguiente destino del nodo para el paquete y no necesariamente a un nodo final que consume el paquete. Una realización del DA 2202 del rastreador de sesión 308 se utiliza para implementar la tabla de DAM 2206. Sin embargo, los conservadores de afinidad de sesión 1904 en general también son aplicables al flujo de enrutamiento de tráfico ilustrativo de la Figura 27. El expedidor 302 (1) incluye la porción de tabla de DAM 2206 (1 ), y el expedidor 302 (2) incluye la porción de tabla del DAM 2206 (2). Los paquetes de entrada son enrutados al huésped 108 (1) o al huésped 108 (2). En una implementación descrita, el DAM 2202 es una tabla en memoria, distribuida de "átomo" 2304 (por ejemplo, pares de palabra clave-valor, con metadatos opcionales) teniendo información de sesión. El DAM 2202 y la tabla de DAM 2206 se describieron anteriormente con referencia particular a las Figuras 22-24. Cualquier nodo en el grupo de clasificadores 304 puede agregar, consultar y eliminar átomos 2304. El DAM 2202 mantiene una tabla de DAM 2206 altamente disponible que incluye rutas activas (por ejemplo, nivel de TCP/IP) así como información de sesión de nivel más alto. Ejemplos de sesiones de nivel más alto incluyen: una sesión de TLS/SSL, una sesión de PPTP, una sesión de IPSec/L2TP, una sesión de ISA, una sesión a base de galleta de HTTP, etc. Además, el DAM 2202 puede incluir entradas de información de sesión en la tabla de DAM 2206 que se dirigen hacia a otras sesiones que no son de TCP/IP, tales como RTP, UDO, etc. En (1), los conmutadores 202 que están al pendiente del equilibrio de carga (LBA) dirigen a un paquete de entrada hacia el expedidor 302 (1 ). En (2), el expedidor 302 (1) consulta su tabla de enrutamiento interna, la tabla de DAM 2206 (1). Cuando el expedidor 302 (1) no encuentra una entrada atómica 2304 para este paquete, envía el paquete a su clasificador asignado y/o asociado, clasificador 304 (1 ). En (3), el clasificador 304 (1) reconoce que el paquete de este ejemplo es un primer paquete de una nueva sesión (por ejemplo, un paquete de SYN para una conexión de TCP). El clasificador 304 (1), por lo tanto, trata al paquete como un inicio de una nueva conexión de TCP de un cliente 108. Al utilizar la información de salud y de carga de un manejador de salud y carga 314 (no explícitamente ilustrado), el clasificador 304 (1) determina que el huésped (108) (1) debe recibir esta conexión. El clasificador 304 (1) actualiza la tabla de DAM 2206 (1 ) que sirve como la tabla de enrutamiento local para el expedidor 302 (1), y también inserta una entrada atómica 2304 representando la ruta hacia el DAM 2206 completo. Estos pueden ser operaciones separadas, una sola operación en donde las sesiones a nivel de TCP/IP de la tabla de DAM 2206 son ubicadas en los expedidores 302, etc. El DAM 2202 internamente replica esta ruta a uno o más de otros miembros del grupo de clasificadores 304 de acuerdo con su política de redundancia estipulada. El clasificador 304 (1) opcionalmente puede comunicarse con el huésped 108 (1) para confirmar la creación de la nueva sesión antes de que actualice la tabla de DAM 2206 (1) del expedidor 302 (1 ) y el DAM 2202/tabla de DAM 2206 completo. En (4), el expedidor 302 (1) directamente envía paquetes subsecuentes para esta conexión al huésped 108 (1) sin interactuar con el clasificador 304 (1). El DAM 2202 puede ser utilizado para enmascarar, por lo menos en parte, la falla de un expedidor 302, un clasificador 304, o un par de expedidor/clasificador 302/304. El DAM 2202 también puede ser utilizado, por lo menos en parte, para conservar la conectividad de cliente si los conmutadores 202 que están al pendiente del equilibrio de carga LBA) inadvertidamente comienzan a enviar paquetes para una conexión establecida a un expedidor diferente 302. La Figura 28 ilustra un flujo de enrutamiento de tráfico ilustrativo en presencia de fallas. En contraste al flujo de enrutamiento de tráfico ilustrativo o "libre de falla" de la Figura 27, una falla ha ocurrido en una porción de la infraestructura de equilibrio de carga de red 106 (no específicamente identificada) de la Figura 28. Específicamente, el primer dispositivo, en donde el expedidor 302 (1) y el clasificador 304 (1) son residentes y se ejecutan, fallan después de que establece la conexión que se ilustra en la Figura 27. Esta falla es enmascarada, por lo menos en parte, por el DAM 2202. En (1) los conmutadores que están al pendiente de la carga de equilibrio 202 (LBA) detectan la falla del expedidor 302 (1) y empiezan a enviar paquetes para la conexión a algún otro expedidor 302 en el grupo. En este ejemplo, el otro expedidor 302 es el expedidor 302 (2). Aunque la Figura 28 ilustra una situación de falla, los conmutadores que están al pendiente del equilibrio de carga 202 (LBA) también pueden enviar este tráfico al expedidor 302 (2) a un si el expedidor 302 (1 ) está disponible. Este cambio que no es inducido por ninguna falla de los expedidores 302 puede ocurrir, por ejemplo, ya que los conmutadores 202 que están al pendiente del equilibrio de carga (LBA) no conservan la afinidad de este tráfico al expedidor 302 (1). Cualquiera de los varios factores pueden hacer que los conmutadores 202 dirijan (mal) el tráfico a un expedidor diferente, sin afinidad 302. Por ejemplo, el tráfico para la misma sesión de nivel más alto puede llegar a los conmutadores 202 de una dirección de IP de fuente diferente o puerto fuente cuando la fuente está por atrás de un grupo de servidores proxi. Las acciones de las notas (2)-(5) se aplican tanto a la falla como a las situaciones de "tráfico mal dirigido".

En (2), el expedidor 302 (2) consulta su tabla de enrutamiento, la tabla de DAM 2206 (2). Cuando no encuentra una ruta para este paquete, envía el paquete a su clasificador 304 (2). En (3), el clasificador 304 (2) reconoce que este paquete es un paquete de TCP de "sesión media", el clasificador 304 (2) consulta al DAM 2202 para la ruta de este paquete. El DAM 2202 responde con la ruta para la conexión de una entrada atómica 2304 que está asociada con el mismo. En (4), el clasificador 304 (2) aploma la ruta en el expedidor 302 (2). Un protocolo ilustrativo para aplomar rutas se describe más adelante. En (5), los paquetes subsecuentes para esta conexión que son dirigidos al expedidor 302 (2), son enrutados directamente al huésped correcto, el cual es el huésped 108 (1) en este ejemplo, sin consultar al clasificador 304 (2). En general, un protocolo de aplomo de ruta para combinaciones entre los clasificadores 304 y los expedidores 302 incluye instrucciones para agregar y remover rutas. Más específicamente, una instrucción de agregar ruta es enviada de un clasificador 304 a un expedidor 302 con el fin de aplomar una ruta del expedidor 302 a un huésped de destino 108 para una conexión dada. A manera de ejemplo, se puede proporcionar una instrucción de agregar ruta al expedidor 302 (2) del clasificador 304 (2) como se indica en (4) en la Figura 28. La ruta (por ejemplo, una clave y valor correspondiente) se agrega a la tabla de DAM local 2206 (2) para tener un rápido acceso al expedidor 302 (2) en futuro. En este ejemplo, el clasificador 304 (2) es un dispositivo separado del expedidor 302 (2), de manera que el protocolo de aplome de ruta puede ser un protocolo entre dispositivos. Sin embargo, el protocolo de aplomo de ruta también se puede utilizar para comunicaciones entre dispositivos. En una implementación descrita, el clasificador 304 (2) incluye un inventario de conexión 2802. Con el inventario de conexión 2802, el clasificador 304 (2) mantiene el rastreo de las sesiones de cualquiera de los expedidores 302 (tal como el expedidor 302 (2)) para el cual el clasificador 304 (2) aploma las rutas. Para que el clasificador 304 (2) mantenga el rastreo de las sesiones, incluyendo sus cesaciones, el expedidor 302 (2) envía paquetes finales para sesiones (tales como paquete TCP FIN) al clasificador 304 (2). El clasificador 304 (2) después elimina una entrada en el inventario de conexión 2802 que corresponde a la sesión y envía una instrucción de eliminar ruta al expedidor 302 (2). Después de recibir la instrucción de eliminar ruta, el expedidor 302 (2) remueve la ruta correspondiente en la tabla de DAM 2206 (2). De esta manera, la funcionalidad de clasificación junto con la funcionalidad de rastreo de sesión puede controlar las tablas de ruta, y las rutas de las mismas, que se utilizan por la funcionalidad de envío. Consecuentemente, la funcionalidad de envío que se separa en un diferente dispositivo puede ser efectuada utilizando hardware de alta velocidad, pero relativamente simple. Alternativamente, los clasificadores 304 pueden basarse en las comunicaciones con/de los huéspedes 108, en lugar de (p además de) paquetes de inicio de sesión (tales como TCP-SYN) y de terminación (tales como TCP-FIN) interceptados, para determinar los tiempos de vida de las sesiones. En otras palabras, los clasificadores 304 alternativa o adicionalmente pueden recibir y utilizar mensajes de sesión (carga/descarga) 2008 (U/D) como se describió anteriormente en la sección intitulada "Rastreo de Sesión Ilustrativo". La Figura 29 ilustra procedimientos de falla ilustrativos adicionales para alta disponibilidad de la infraestructura de equilibrio de carga de red 106. Se describen procedimientos de fallas para dos diferentes fallas, falla 2902 y falla 2906. Como se ilustra, la infraestructura de equilibrio de carga de red 106 (no indicada en forma separada) incluye cinco componentes: expedidor 302 (1), expedidor 302 (2), expedidor 302 (3), clasificador 304 (1), y clasificador 304 (2). En una implementación descrita, cada uno de estos cinco componentes 302 (1 ), 302 (2), 302 (3), 304 (1), y 304 (2) corresponde a un dispositivo individual. Sin embargo, procedimientos de falla similares se aplican a ambientes en donde diferentes componentes de equilibrio de carga comparten dispositivos. También, se pueden aplicar procedimientos de falla similares o análogos a ambientes que tengan otros números, combinaciones, estacadas, etc. de componentes. Inicialmente en [1], el enrutador/conmutador(es) 202 dirige un paquete de entrada que tal vez sea para una nueva conexión al expedidor 302 (1 ). Ya que el expedidor 302 (1) no tiene una ruta para esta conexión en su tabla de enrutamiento local, envía el paquete al clasificador 304 (1) como se indica por la doble flecha desvanecida en (1). El clasificador 304 (1) primero verifica la información de sesión con referencia al rastreo de sesión 308 para una posible afinidad de sesión de nivel más alto. En este ejemplo, el paquete no tiene afinidad con una sesión existente, de manera que el clasificador 304 (1) selecciona un huésped 108 con referencia a información de salud y carga con referencia al manejo de salud y carga 314. Específicamente, el clasificador 304 (1) selecciona al huésped 108 (1) en este ejemplo. Asumir que el paquete es para una conexión de TCP/IP, esta sesión de TCP/IP, enlazada al huésped 108 (1), es agregada al DAM 2202 utilizando una llamada de función de agregar átomo 2204 (A) por el clasificador 304 (1). El paquete inicial se envía al huésped 108 (1) por el clasificador 304 (1) o el expedidor 302 (1). El clasificador 304 (1 ) también aploma una ruta en la tabla de enrutamiento local del expedidor 302 (1). Los paquetes subsecuentes son enviados al huésped 108 (1) por el expedidor 302 (1) sin interacción adicional con el clasificador 304 (1). En algún momento durante la conexión [1], existe una falla 2902 en el expedidor 302 (1). Con el enrutador/conmutador(es) 202 que está al pendiente del equilibrio de carga (LBA), se detecta esta falla 2902. Como resultado, en el punto 2904, el enrutador/conmutador(es) 202 dirige paquetes posteriores que pudieron haber sido enviados al expedidor 302 (1.) a lo largo de la conexión [1] a otro expedidor 302, el cual es el expedidor 302 (2) en este ejemplo. El expedidor 302 (2) de esta manera recibe paquetes futuros a lo largo de una conexión [2]. Ya que el expedidor 302 (2) no tiene una entrada en su tabla de enrutamiento local para los paquetes que fueron anteriormente dirigidos al expedidor 302 (1), el expedidor 302 (2) envía el primer paquete recibido de la conexión [2] al clasificador en donde se asignó/asoció. En este ejemplo, el expedidor 302 (2) es asignado al clasificador 304 (2) como se indica por la doble flecha desvanecida en (2). El clasificador 304 (2) utiliza una llamada de función de átomo de consulta 2204 (Q) para obtener la entrada atómica 2304 (no explícitamente mostrado) del DAM 2202 que está asociado con la conexión de TCP/IP existente. Esta entrada atómica 2304 es provista a través del DAM 2202 del rastreo de sesión 308 a través de una llamada de función de átomo de regreso 2204 (R). El clasificador 304 (2) extrae al huésped 108 (1) que tiene afinidad con esta conexión de TCP/IP de la entrada atómica regresada 2304. El clasificador 304 (2) envía el primer paquete recibido para la conexión [2] al huésped 108 (1) y también aploma una ruta en la tabla de enrutamiento local del expedidor 302 (2). Los paquetes subsecuentes son enviados al huésped 108 (1) por el expedidor 302 (2) sin interacción adicional con el clasificador 304 (2). Las descripciones anteriores se enfocan predominantemente en fallas de componentes individuales del expedidor 302, sin embargo, los componentes del clasificador 304 también pueden fallar. Por ejemplo, en algún punto, existe una falla 2906 en el clasificador 304 (2). El expedidor 302 (2) detecta la falla 2906 cuando intenta consumir servicio de clasificación o a través de una notificación de una falta de alguna indicación de cura tal como un indicador de tipo latido. Para manejar la falla 2906, al expedidor 302 (2) se le vuelve a asignar o se le vuelve a asociar un clasificador 304 diferente, el cual es el clasificador 304 (1 ) en este ejemplo. Se proporciona una funcionalidad de clasificación futura al expedidor 302 (2) por el clasificador 304 (1) como se indica por la doble flecha desvanecida en (3). La Figura 30 ilustra una implementación operacional ilustrativa de la interacción de enrutamiento de tráfico con información de salud y carga. El expedidor 302 y el clasificador 304 ¡nteractúan con el manejador de salud y carga 314 con el fin de enrutar paquetes a los huéspedes 108 (1 ), 108 (2) ... 108 (n). Aunque un expedidor 302 y un clasificador 304 se ilustran, la implementación operacional ilustrativa también es aplicable a un enrutador de solicitud 306 (o funcionalidad de enrutamiento de tráfico 2012 en general). Como se ilustra, el huésped 108 (1) incluye puntos extremos de aplicación IP1, IP3, y IP4 para la aplicación #1, aplicación #1 y aplicación #2, respectivamente. El huésped 108 (2) incluye puntos extremos de aplicación IP2 y IP6 para la aplicación #1 y aplicación #2, respectivamente. El huésped 108 (n) incluye el punto extremo de aplicación IP 5 para la aplicación #2. Estos huéspedes 108 (1), 108 (2) ... 108 (n) y los puntos extremos de aplicación IP1, IP2, IP3, IP4, IP5 e IP6 son verificados por el manejador de salud y carga 314 (por ejemplo, utilizando la infraestructura de salud y carga 1202, memoria caché de salud y carga 1208 consolidada, etc.). En una ¡mplementación descrita, en (1) el clasificador 304 solicita una o más distribuciones de punto extremo de aplicación (por ejemplo, a través de por lo menos una solicitud de distribución de punto extremo de aplicación objetivo 1802) en un ambiente que utiliza un esquema de distribución 1806. El manejador de salud y carga 314, en este ejemplo, responde proporcionando distribuciones de señal 3002 (por ejemplo, a través de por lo menos una respuesta de distribución de punto extremo de aplicación objetivo 1804). Específicamente, una distribución de señal para la aplicación #1 3002 (1) y una distribución de señal para la aplicación #2 3002 (2) están disponibles para el clasificador 304. La distribución de señal para la aplicación #1 3002 (1 ) inicialmente proporciona 40 señales para IP1 , 35 señales para IP2 y 25 señales para IP3. La distribución de señal para la aplicación #2 3002 (2) proporciona 10 señales para IP4, 72 señales para IP5 y 18 señales para IP6. Para cada nueva conexión que se le asigna a un enrutamiento a un punto extremo de aplicación por el clasificador 304, se consume una señal por el clasificador 304. En (2), el expedidor 302 recibe un paquete de entrada inicial para una nueva conexión. Ya que no está presente ningún enrutamiento para esta nueva conexión en la porción de tabla de DAM 2206 del expedidor 302, el expedidor 302 envía el paquete inicial al clasificador 304 en (3). En (4), el clasificador 304 (por ejemplo, después de determinar que el paquete inicial no incluye una referencia de sesión para una sesión de nivel más alto) selecciona un punto extremo de aplicación (y de esta manera un huésped 108) en respuesta a la información de salud y carga. Específicamente, para una nueva conexión que se le va dar servicio por parte de la aplicación #1 el clasificador 304 puede seleccionar cualquiera de IP1, IP2 e IP3 si sigue existiendo una señal para el punto extremo respectivo. El clasificador 304 puede consumir señales en cualquiera de muchas maneras posibles. Por ejemplo, el clasificador 304 puede utilizar un aspecto de circuito cíclico sin considerar el número de señales por punto extremo. Alternativamente, el clasificador 304 simplemente puede comenzar a partir de IP1 y progresar a través de IP3, mientras consume todas las señales para cada punto extremo antes de moverse al siguiente punto extremo en un aspecto lineal. También, el clasificador 304 puede consumir una señal a partir del grupo de señales de punto extremo definido que actualmente tiene el número mayor de señales en cualquier momento. Al utilizar el último aspecto, el clasificador 304 selecciona IP1. También se pueden emplear otros aspectos. Como se ilustra, el clasificador 304 consume una señal para el punto extremo de aplicación IP2. Consecuentemente, el grupo de señales para IP2 se reduce de 35 señales a 34 señales a medida que se consume una señal. También, el paquete inicial para una nueva conexión que va a ser enrutado al punto extremo de aplicación IP2. En (5A), el paquete inicial es enviado del clasificador 304 al punto extremo de aplicación IP2 del huésped 108 (2). Antes, durante, o después de este envío, el clasificador 304 en (5B) aploma una ruta para esta conexión en la porción de tabla de DAM local 2206. el clasificador 304 también puede agregar una entrada atómica 304 para esta sesión en la tabla de DAM 2206 para propósitos de distribución y replicación. En (6), se envían futuros paquetes para esta conexión/sesión el expedidor 302 al punto extremo de aplicación IP2 del huésped 108 (2) utilizando la tabla de enrutamiento local del expedidor 302 como se realiza por la porción de tabla de DAM local 2206 en la Figura 30. La Figura 31 muestra mecanismos de alta disponibilidad ilustrativos para la infraestructura de equilibrio de carga de red 106. Específicamente, la detección de falla ilustrativa 3104, el manejo de falla ilustrativa 3106 y la recuperación de falla ilustrativa 3108, se muestran. Estos mecanismos de alta disponibilidad ilustrativos se describen con respecto a diferentes componentes de la infraestructura de equilibrio de carga de red 106. Los componentes de infraestructura de equilibrio de carga de red 106 incluyen un expedidor 302, un clasificador 304, un enrutador de solicitud 306, un rastreador de sesión 308, y un manejador de salud y carga 314. Entre 3102 (A), el expedidor 302 experimenta una falla local. En 3104 (A), por lo menos un conmutador que está al pendiente del equilibrio de carga detecta la falla. Para manejar la falla local 3102 (A), los paquetes se vuelven a dirigir a otros expedidores en 3106 (A) por el conmutador que está al pendiente del equilibrio de carga. Para recuperar la falla del expedidor 302, las rutas que fueron almacenadas localmente en el expedidor 302 se vuelven a diseñar entre 3108 (A) en el expedidor(es) a donde volvieron a dirigir los paquetes utilizando un administrador de rastreo de sesión distribuida y una tabla del mismo tal como un DAM y una tabla de DAM del mismo. El administrador de rastreo de sesión distribuida, por lo tanto, puede incluir redundancias de datos de uno o más niveles. En 3102 (B), el clasificador 304 experimenta una falla local. En 3104 (B), por lo menos un expedidor detecta la falla. Para manejar la falla local 3102 (B), los paquetes se vuelven a dirigir a otro clasif icador(es) en 3106 (B) por el expedidor que detecta la falla. Para recuperar de la falla del clasificador 304, la información de sesión que fue almacenada localmente del clasificador 304 se vuelve a diseñar en 3108 (B) en el clasif icador(es) a donde se volvieron a dirigir los paquetes utilizando DAM. Esta información de sesión, por ejemplo, puede ser la información de sesión un nivel más alto que las conexiones de línea de base de TCP/IP. También, dicha información de sesión puede ser considerada como parte de la infraestructura de rastreo de sesión que está residente en el mismo dispositivo como el clasificador 304. En 3102 (C), el enrutador de solicitud 306 experimenta una falla local. En 3104 (C), por lo menos un expedidor y/o conmutador que está al pendiente de equilibrio de carga detectan la falla. Para manejar la falla local 3102 (C), los paquetes se vuelven a dirigir a otro enrutador(es) de solicitud en 3106 (C) por el expedidor y/o el conmutador que está al pendiente del equilibrio de carga. Las solicitudes lógicas reales individuales en donde está trabando el enrutador de solicitud 306 después de la ocurrencia de la falla local 3102 (C) pueden ser menos perdidas a menos que cada solicitud lógica individual sea replicada con la solicitud que está siendo trabajada. Para recuperar de la falla del enrutador de solicitud 306, la información de sesión y/o rutas que fueron almacenadas localmente en el enrutador de sesión 306 se vuelven a diseñar en 3108 (C) en el enrutador(es) de solicitud al cual se volvieron a dirigir los paquetes (y de esta manera nuevas solicitudes lógicas). En volver a diseñar la información de sesión puede ser efectuado utilizando el DAM. Otra vez, dicha información de sesión puede ser considerada como parte de la infraestructura de rastreo de sesión que está residente en el mismo dispositivo como el enrutador de solicitud 306. En 3102 (D), el rastreador de sesión 308 experimente una falla local. En 3104 (D), por lo menos un expedidor y/o clasificador detecta la falla. Por ejemplo, si el rastreador de sesión 308 está residente en el mismo dispositivo como un clasificador, entonces un expedidor u otro clasificador puede detectar la falla. Si el rastreador de sesión 308 está residente en un dispositivo separado, entonces un clasificador puede detectar la falla. Para manejar la falla local 3102 (D), se instituye redundancia de datos de uno o más niveles y la distribución de múltiples dispositivos en 3106 (D) para la información de sesión rastreada. Se debe observar que la redundancia y distribución están instituidas antes de la falla en 3102 (D). Para recuperar la falla del rastreador de sesión 308, la información de sesión de las tablas de DAM puede volver a ser distribuida y replicada en 3108 (D) a través de por lo menos dos dispositivos (si no ha sido ya distribuida y suficientemente replicadas) con el fin de manejar un segundo nivel de falla. En 3102 (E), el manejador de salud y carga 314 experimenta una falla local. En 3104 (E), por lo menos un clasificador y/o enrutador de solicitud detectan la falla. Por ejemplo, un componente que está recibiendo información de salud y carga del manejador de salud y carga 314 puede detectar una falla si el manejador de salud y carga 314 no responde, especialmente si el manejador de salud y carga 314 está residente en un dispositivo diferente de aquel del componente de consulta. Para manejar la falla local 3102 (E), la redundancia de datos de salud y carga almacenados en memoria caché y el manejo de falla intrínseco se emplean en 3106 (E) para la información de salud y carga. Por ejemplo, cada manejador de salud y carga 314 puede incluir una memoria caché de información de salud y carga consolidada 1208 que duplica la información en las tablas de salud y carga 1203 en múltiples huéspedes 108. También, los consumidores de la información de salud y carga 1206 de un manejador de salud y carga 314 dado pueden ser ubicados en un mismo dispositivo como el manejador de salud y carga 314, de manera que el manejador de salud y carga 314 es intrínsecamente aceptable. En forma similar, la versión autoritaria de una porción respectiva de información de salud y carga 1206 está ubicada en un huésped 108 respectivo, de manera que la falla del huésped 108 ejecuta la pérdida de la porción respectiva la información de salud y carga aceptable. Para recuperar la falla del manejador de salud y carga 314, un componente de equilibrio de carga de red dado que consume la información de salud y carga puede consultar un manejador de salud y carga diferente, ya que cada manejador de salud y carga incluye una memoria caché consolidada de la información del manejador de salud y carga. También, cuando el manejador de salud y carga 314 otra vez es accesible, el protocolo de mensaje 1500 se puede utilizar en 3108 (E) para volver a diseñar su memoria caché consolidada de información de salud y carga. Al utilizar estos mecanismos ilustrativos de alta disponibilidad, las fallas de los componentes de la infraestructura de equilibrio de carga de red 106 pueden ser detectadas, manejadas y recuperadas con el fin de enmascarar dichas fallas en los clientes 102.

Migración de Conexión Ilustrativa con Tunelización Opcional y/o Equilibrio de Carga de Nivel de Aplicación Esta sección describe como la manipulación de conexión, tal como la migración de conexión, puede ser utilizada en el equilibrio de carga de red. Esta sección principalmente hace referencias a las Figuras 32-39 e ilustra la funcionalidad de migración de conexión de tal como es provista por el emigrante de conexión 310 (de la Figura 3). Como se describió anteriormente con referencia a las Figuras 3 y 4, cada conexión de entrada en la infraestructura de equilibrio de carga 106 puede ser terminada. Después, la conexión puede ser emigrada a un huésped 108, de manera que la conexión después es terminada en el huésped 108. El emigrante de conexión 310 es capaz de realizar esta migración de conexión y puede ser ubicado parcialmente en los huéspedes 108 para efectuar la migración. Dicha migración de conexión puede ser realizada junto con el equilibrio de carga de nivel de aplicación por un clasificador 304 y/o utilizar la tunelización a través del tunelista 312. La Figura 32 ilustra un aspecto ilustrativo para el equilibrio de carga de red de nivel de aplicación con migración de conexión. El equilibrio de carga de nivel de aplicación, o capa 7, pertenece a hacer decisiones de equilibrio de carga con respecto a una aplicación que va a manejar una conexión. Para realizar el equilibrio de carga de nivel de aplicación, la infraestructura de equilibrio de carga 106 usualmente toma en cuenta una porción de datos de una conexión. A menos que se emplea un enrutamiento de solicitud, un clasificador 304 típicamente toma un pico en la porción inicial de una conexión y después emigra la conexión, junto con el emigrante de conexión 310, a un huésped 108 seleccionado. Para el equilibrio de carga de nivel de aplicación en un ambiente a base de TCP en general, los clasificadores 304 miran en la porción inicial de los datos de TCP de un cliente cuando se decide enviar la conexión de TCP del cliente. De esta manera, la lógica de nivel de aplicación examina los datos del cliente y hace decisiones de equilibrio de carga basándose en esos datos. Por ejemplo, si una conexión es una conexión de HTTP "no codificada crípticamente", un clasificador 304 puede hacer una mirada en el encabezado de HTTP de la primera solicitud de HTTP en la conexión, y puede enrutar las decisiones basándose en la misma porción del contenido del encabezado (por ejemplo, URL, una galleta, etc. Aunque el equilibrio de carga de nivel de aplicación, migración de conexión y tunelización son aplicables a otros protocolos, se utiliza predominante TCP/IP en estos ejemplos. Como se ilustra, la infraestructura de equilibrio 106 (no específicamente indicada) incluye un expedidor 302, un clasificador 304, un tunelista 312, y un emigrante de conexión 310 (y posiblemente, por ejemplo, un enrutador/conmutador que está al pendiente al pendiente del equilibrio de carga 202 (LBA)). El expedidor 302 corresponde a la dirección de IP virtual y envía paquetes a los huéspedes 108 de acuerdo con las selecciones del huésped a través del clasificador 304. Aunque no específicamente mostrado en la Figura 32 por claridad, los huéspedes 108 también incluyen una funcionalidad de emigrante de conexión 310 y una funcionalidad de tunelista 312. En una ímplementación descrita, el expedidor 302, clasificador 304 y emigrante de conexión 310 (en el clasificador 304 y en los huéspedes 108), junto con el software de protocolo de TCP en el clasificador 308 y huéspedes 108, cooperan para proporcionar migración de conexión. La migración de conexión ilustrada en la Figura 32 es para una conexión del cliente 102 (1) que inicialmente se terminó en el clasificador 304. Después de la migración de conexión, la conexión del cliente 102 (1) es terminada en el huésped 108 (1). Una vez que la conexión es terminada en el huésped 108 (1), los paquetes para la conexión pueden ser tunelizados utilizando el tunelista 312 (en el expedidor 302 y huésped 108 (1)). En (1), el cliente 102 (1) envía un paquete de SYN al expedidor 302 para dar señal del inicio de una nueva conexión de TCP. En (2), el expedidor 302 envía este paquete al clasificador 304. En (3), el clasificador 304 acepta la conexión de TCP a favor de un huésped 108 (cuya identidad aún no es conocida ya que el huésped 108 () objetivo real ya ha sido seleccionado). En términos de protocolo de TCP, el clasificador 304 envía un paquete de SYN-ACK al cliente 102 (1). En (4), el cliente 102 (1) comienza a enviar datos. (El paquete inicial de SYN también puede contener datos). Los datos son procesados por el clasificador 304, el cual puede consultar la lógica de aplicación específica. La lógica de aplicación especifica puede relacionarse con el huésped 108 que es capaz de manejar o manejar mejor que tipos de solicitudes o conexiones existen. De esta manera el clasificador 304 utiliza los datos, así como la información de salud y carga de aplicación del manejador de salud y carga 314 y opcionalmente la información de sesión de aplicación del rastreador de sesión 308, para terminar a un huésped 108 que es mejor o el más adecuado para manejar esta conexión del cliente 102 (1). En este ejemplo, se selecciona el huésped 108 (1). En (5), el clasificador 304 envía un "objeto binario grande" que represente el estado de la conexión de TCP al huésped 108 (1). Este estado de conexión es agregado en cooperación de una pila de TCP en el clasificador 304 a través del emigrante de conexión 310. El objeto binario grande contiene datos del cliente 102 (1) que ha sido reconocido por el clasificador 304 y parámetros de TCP, tales como 4-tupla de TCP/IP, números de secuencia iniciales, etc. En (6), un componente del emigrante de conexión 310 en el huésped 108 (1) (no explícitamente mostrado en la Figura 32) "inyecta" esta conexión a una pila de TCP en el huésped 108 (1) utilizando el estado de la conexión de TCP del objeto grande binario recibido del clasificador 304. Esta inyección de estado de conexión se realiza en cooperación con la pila de TCP en el huésped 108 (1), haciendo que aparezcan aplicaciones 316 en el huésped 108 (1) en donde esta conexión fue originalmente aceptada por el mismo huésped 108 (1). El cliente 102 (1) no está al pendiente de la migración de conexión. En (7), el clasificador 304, junto con la pila de TCP en el clasificador 304, limpia el estado interno mantenido para esta conexión. Esta limpieza del estado interno en el clasificador 304 se realiza silenciosamente de manera que el cliente 102(1) no queda notificado de que el estado de conexión está siendo interrumpido. El clasificador 304 también agrega una ruta en la tabla de enrutamiento local del expedidor 302 que indica que el huésped 108 (1) sea el destino para los paquetes de esta conexión. En (8), subsecuentes paquetes para la conexión son enrutados por el expedidor 302 al huésped 108 (1) sin diversión a o a través del clasificador 304. Estos paquetes pueden ser tratados igual por el expedidor 302 como aquellos paquetes para las conexiones que son clasificadas y enrutadas sin utilizar migración de conexión. Estos paquetes subsecuentes opcionalmente pueden ser tunelizados del expedidor 302 al huésped 108 (1) utilizando el tunelista 312. El tunelista 312 también se ilustra (utilizando líneas desvanecidas) en el emigrante de conexión 310 en el clasificador 304, ya que ciertos parámetros usados por el tunelista 312 pueden ser determinados durante una migración de conexión y/o asociarse con una conexión que está siendo emigrada. Las implementaciones ilustrativas para el tunelista 312 se describen más adelante con particular referencia a las Figuras 38 y 39. La Figura 33 es un diagrama de flujo 3300 que ilustra un método ilustrativo para la emigración de una conexión de un primer dispositivo a un segundo dispositivo. El diagrama de flujo 3300 incluye siete bloques 3302-3314. Aunque las Figuras 32 y 34-37 se enfocan principalmente en la migración de conexión en un ambiente de equilibrio de carga de red, la migración de conexión como se describe aquí puede ser efectuada entre dos dispositivos en general, cada uno incluyendo una funcionalidad de migración de conexión, tal como aquella para el emigrante de conexión 310. En el bloque 3302, se acepta una conexión en un primer dispositivo. Por ejemplo, un primer dispositivo puede terminar una conexión de entrada de acuerdo con uno o más protocolos de una porción de pila de protocolo de una pila de red. En el bloque 3304, los datos son recibidos de la conexión en el primer dispositivo. Por ejemplo, estos datos pueden ser recibidos en un paquete inicial que solicita la conexión o en uno o más paquetes que son recibidos subsecuentemente a una aceptación de la conexión. En el bloque 3306, un estado de conexión para la conexión aceptada es agregado de una pila de protocolo (o en general de una pila de red) en el primer dispositivo. Por ejemplo, un estado de protocolo de uno o más protocolos de la pila de protocolo puede ser compilado y agregado con cualquiera de los datos recibidos que han sido reconocidos. En el bloque 3308, el estado de conexión es enviado del primer dispositivo a un segundo dispositivo. Por ejemplo, la información agregada del estado de conexión puede ser enviada utilizando un protocolo confiable a un segundo dispositivo. En el bloque 3310, el estado de conexión para la conexión que está siendo emigrada es recibido del primer dispositivo en el segundo dispositivo. En el bloque 3312, el estado de conexión es inyectado a una pila de protocolo (o en general a la pila de red) del segundo dispositivo. Por ejemplo, la conexión puede volver a ser hidratada utilizando los protocolos de la pila de protocolo del segundo dispositivo, de manera que los programas anteriores el nivel de pila de protocolo no están al pendiente de esa conexión que es una conexión emigrada. Más específicamente el estado de protocolo puede ser infundido en la pila de protocolo. Los datos agregados del estado de conexión también son incorporados en el segundo dispositivo. En el bloque 3314, la conexión se continúa en el segundo dispositivo. Por ejemplo, la conexión puede ser continuada en el segundo dispositivo como si la conexión no hubiera sido previamente terminada. La Figura 34 ilustra un aspecto ilustrativo a la migración de conexión desde la perspectiva de un dispositivo de origen 3400, la migración de conexión en el dispositivo de origen 3400 es efectuada, por lo menos en parte, por el emigrante de conexión 310. en una implementación descrita, el dispositivo de origen 3400 es un dispositivo que es parte de la infraestructura de equilibrio de carga de red 106. Por ejemplo, el dispositivo de origen 3400 puede comprender un clasificador 304, posiblemente junto con un expedidor 302, un enrutador de solicitud 306 etc. Como se ilustra, el dispositivo de origen 3400 incluye como partes de su pila de red, una interfase de red física (PNI) 3410, un mini puerto de PNI 3408, una interfase de protocolo-hardware 3406, una pila de protocolo 3404, y una capa de receptáculo 3402. El dispositivo de origen 3400 también incluye una funcionalidad de equilibrio de carga 106, tal como un clasificador 304 en un nivel de aplicación y el emigrante de conexión 310. Específicamente, el emigrante de conexión 310 incluye una unidad intermedia de emigrante 3414 y un suplemento emigrante 3412. El emigrante de conexión 310 es capaz de descarga una conexión de un dispositivo de origen 3400. En una implementación descrita, la interfase de red física 3410 puede ser una tarjeta de interfase de red (NIC) (por ejemplo, una NIC de Ethernet), una interfase inalámbrica, etc. Aunque solamente se muestra una interfase de red física 3410, un dispositivo dado en realidad puede tener múltiples de estas interfases de red físicas 3410 es decir, el dispositivo de origen 3400 puede ser de multialojación. Cada interfase de red física 3410 típicamente corresponde una o más direcciones de red físicas. El mini puerto de PNI 3408 es un módulo de software que tiene y se interconecta con la realización de hardware específica de la interfase de red física 3410. La interfase de protocolo-hardware 3406 es una capa que incluye una o más interfases respectivas entre uno o más protocolos respectivos y el mini puerto de PNI 3408. La pila de protocolo 3404 incluye uno o más módulos respectivos que cada uno es dirigido a uno o más protocolos respectivos. Ejemplos de dichos protocolos se describen más adelante con referencia a las Figuras 36 y 37. En un contexto pasajero, la pila de protocolo 3404 incluye un estado de protocolo 3420 para cada conexión que existe en el dispositivo de origen 3400. Una capa de receptáculo 3402 yace entre un programa, tal como una funcionalidad de equilibrio de carga 106 y una pila de protocolo 3404. La capa de receptáculo 3402 proporciona APIs entre la funcionalidad de equilibrio de carga 106 y la pila de protocolo 3404, y permite que programas registren conexiones, entre otras cosas. La unidad intermedia de emigrante 3414, o más generalmente la unidad emigrante 3414, está ubicada en la capa de interfase de protocolo-hardware 3406. El suplemento emigrante 3412 está localizado en forma transparente en la pila de protocolo 3404 y la capa de receptáculo 3402. Cuando un paquete inicial (no mostrado) que solicita una nueva conexión es presentado al dispositivo de origen 3400, el paquete es dirigido hacia arriba desde la interfase de red física 3410, al mini puerto de PNI 3408, a través de la capa de interfase de protocolo-hardware 3406, y a la pila de protocolo 3404. A medida que el paquete atraviesa uno o más de los protocolos de la pila de protocolo 3404, el estado de protocolo 3420 es creado ahí. También, como resultado de este paquete inicial o como una consecuencia de la funcionalidad de equilibrio de carga 106 aceptando la conexión para mirar la solicitud, los datos 3416 llegan al dispositivo de origen 3400. Durante operación la unidad intermedia emigrante 3414 divierte una copia de datos 3416 a la lógica del emigrante de conexión 310. Cuando la funcionalidad de equilibrio de carga 106 emite una llamada de función de conexión emigrante, la llamada de función de emigrante es pasada a una capa muy superior de la pila de protocolo 3404, de manera que puede comenzar la agregación de estado de conexión 3418. El estado de protocolo 3420 es compilado de uno o más protocolos de la pila de protocolo 3404. En una implementación de TCP/IP, el estado de protocolo 3420 puede incluir (i) puertos de TCP.de destino y fuente y direcciones de IP (por ejemplo, 4-tupla de TCP/IP), (i¡) un estado de ventana de TCP, (Mi) números de secuencia iniciales, (iv) información de tiempo fuera, (v) ID de fragmento de IP, (iv) información de enrutamiento, y (vii) etc. La agregación de estado de conexión 3418 también agrega datos 3416 que han sido divertidos al emigrante de conexión 310 y que ya han sido reconocidos del dispositivo de origen 3400 (por ejemplo, a través de la funcionalidad de equilibrio de carga 106. Este estado de conexión agregado 3418 incluye un estado de protocolo 34 20 y datos 3416 (y opcionalmente otra información relacionada con la conexión). El estado de conexión agregado 3418 después es enviado como un objeto grande binario 3422 lejos del dispositivo de origen 3400 hacia un dispositivo objetivo. El objeto binario grande 3422 puede ser enviado del dispositivo de origen 3400 hacia un dispositivo objetivo usando un protocolo confiable. "Confiable" puede implicar, por ejemplo, que el objeto grande binario 3422 es recibido intacto en el dispositivo objetivo aún si si se pierden o corrompen paquetes individuales que constituyen el objeto grande binario 3422. Este objeto grande binario 3422 también puede ser agrupado con un identificador de flujo si la conexión va a ser tunelizada subsecuentemente con el tunelista 312.

Los ¡dentificadores de flujo con lá tunelización se describen más adelante con referencia particular a las Figuras 38 y 39. La Figura 35 ilustra un aspecto ilustrativo de la migración de conexión desde la perspectiva de un dispositivo objetivo 3500. El dispositivo objetivo 3500 es similar al dispositivo de origen 3400, con respecto a las varias capas/módulos ilustrados, incluyendo el emigrante de conexión 310. Sin embargo, como se ilustra por lo menos una aplicación 316, a un nivel de aplicación, está i nterconectada la capa receptáculo 3402. El dispositivo objetivo 3500, de esta manera, puede comprender un huésped 108. También, el emigrante de conexión 310 es capaz de cargar una conexión del dispositivo de origen 3400. En una implementación descrita, la aplicación 316 es el destino del paquete de inicio de conexión recibido en el dispositivo de origen 3400. Del dispositivo de origen 3400, el dispositivo objetivo 3500 recibe el objeto grande binario 3422. El objeto grande binario 3422 incluye el estado de conexión asociado con la conexión que es emigrada hacia el dispositivo objetivo 3500 y opcionalmente un identif icador de flujo.. Este estado de conexión incluye el estado de protocolo 3420 y datos reconocidos 3416 (y posiblemente otra ¡pformación relacionada con la conexión). Durante operación, cuando el objeto grande binario 3422 llega a la capa de interfase de protocolo-hardware 3406, la unidad intermedia emigrante 3414 lo reconoce como un objeto binario grande para la migración de conexión y lo divierte. El estado conexión es inyectado en 3502 para crear la apariencia de la aplicación 316 que la conexión fue originalmente terminada en el dispositivo objetivo 3500. Específicamente el estado de protocolo 3420 del estado de conexión inyectado 3502 es infundido en la pila de protocolo 3404. En una implementación descrita, el estado de protocolo 3420 es infundido primero en protocolos de nivel más alto y después en protocolos de nivel más bajo de la pila de protocolo 3404. Después de que el estado de protocolo 3420 es infundido en la pila de protocolo 3404, los datos 3416 pueden ser indicados en la aplicación 316. Estos datos 3416 pueden ser provistos a la aplicación 316 como si fueran parte de una conexión reciente y localmente terminada. Después de que se completa la inyección de estado de conexión 3502, la conexión iniciada por el paquete recibido en el dispositivo de origen 3400 es exitosamente emigrada de ahí hacia el dispositivo objetivo 3500. Los paquetes subsecuentes para la conexión pueden ser enviados directamente al dispositivo objetivo 3500 sin pasar a través del dispositivo de origen 3400, o por lo menos solamente con un simple enrutamiento y sin ningún análisis de nivel de aplicación aplicado a éste. Opcionalmente, estos paquetes pueden ser tunelizados de manera que la unidad intermedia emigrante 3414 efectivamente opera como un NIC virtual a base de software que está unido a la dirección IP virtual. En otras palabras, el controlador intermedio emigrante 3414 (de la Figura 35) puede comprender un adaptador de red virtual que está unido a la dirección de destino de paquetes no encapsulados. La Figura 36 ilustra un aspecto ilustrativo de un procedimiento de descarga 3600 para una migración de conexión. El procedimiento de descarga de migración 3600 ilustra detalles ilustrativos adicionales para una migración de conexión a través de un dispositivo de origen 3400. Como se ilustra, la pila de protocolo 3404 general incluye una pila de TCP 3404 (T), una pila de IP 3404 (I), y una pila de protocolo de resolución de dirección (ARP) 3404 (A). Sin embargo, se pueden emplear alternativamente otras pilas de protocolo específicas 3404 (). A manera de ejemplo, la capa de interfase de protocolo-hardware 3406 puede ser realizada como una capa a base de especificación de interfase de unidad de red (NDIS) en un ambiente de sistema operativo (OS) de Microsoft® Windows®. También, la capa de receptáculo 3402 puede ser realizada como una capa de Winsock™ en una ambiente de sistema operativo de Microsoft® Windows®. En una implementación descrita, la unidad intermedia emigrante 3414 incluye interfases de protocolo-hardware 3406 en las uniones en la pila ARP 3404 (A) y en el mini puerto de PNI 3408. La unidad intermedia emigrante 3414 sirve como un objetivo de descarga en un procedimiento de descarga de migración 3600. El objetivo de descarga es un mini puerto de interfase de protocolo-hardware 3406 como se ilustra en este ejemplo. En un procedimiento de carga de migración 3700 (como se muestra en la Figura 37), la unidad intermedia emigrante 3414 sirve como un derivador de carga.

Más específicamente, la unidad intermedia emigrante 3414 está unidad a cada inferíase de red física 3410 a través de la cual se puede emigrar una conexión de TCP. La unidad intermedia emigrante 3414 usualmente opera como una unidad de paso, pasando paquetes hacia arriba o hacia abajo en la pila de red sin de otra manera interactuar con los paquetes. Sin embargo, la unidad intermedia emigrante 3414 interactúa con paquetes relacionados con la migración de conexión (opcionalmente incluyendo paquetes subsecuentemente tunelizados. Las responsabilidades de la unidad intermedia emigrante 3414 incluye: (i) la aceptación de solicitudes de descarga emigrante; (ii) la agregación de la información de estado de protocolo que está relacionada con la conexión de TCP que emigra como compilada de las pilas de protocolo específicas 3404 (), junto con datos reconocidos para producir la información de estado de conexión; y (iii) la transmisión del estado de conexión agregado a un dispositivo objetivo 3500 para un procedimiento de carga de migración 3700. Un protocolo de cables confiable para dicha transmisión puede ser compartido con aquel utilizado por los componentes de rastreo de sesión 2002 y 2010 para enviar y recibir mensajes de información de sesión 2008 (por ejemplo, como se describió anteriormente con referencia a la Figura 20). Otra responsabilidad de la unidad intermedia emigrante 3414 (por ejemplo, en un procedimiento de carga de migración 3700) es iniciar la carga de las conexiones emigradas que recibe de otros dispositivos y almacenar en memoria intermedia cualquiera de los paquetes de entrada relacionados con la conexión de migración mientras que está en el procedimiento que se esta cargando. Para cargar la conexión, la unidad intermedia emigrante 3414 emigra una solicitud de carga a suplemento emigrante 3412. El suplemento emigrante 3412 emite una llamada de inyección a la pila de protocolo 3404 en la pila de TCP 3404 (A) para iniciar la conexión de la porción de pila de protocolo 3404 de la pila de red. El suplemento emigrante 3412 expone una interfase de cliente a la pila de TCP 3404 (T) y expone una interfase de proveedor a la capa de receptáculo 3402. El suplemento emigrante 3412 juega dos papeles: (i) iniciar el procedimiento de descarga de migración de conexión 3600 en un dispositivo de origen 3400, y subsecuentemente el procedimiento de carga de migración 3700 en un dispositivo objetivo 3500, y (ii) mediar el procedimiento de clasificación entre un programa de aplicación huésped 316, un programa de clasificador de equilibrio de carga 304, y la capa de receptáculo 3402. El suplemento emigrante 3412 y la unidad intermedia emigrante 3414 ambos se describen con referencia a las Figuras 3637. Para un procedimiento de descarga de migración ilustrativo 3600, la migración de una conexión de TCP se realiza después de que el clasificador 304 clasifica la conexión de TCP de entrada utilizando 1, 2 o más paquetes del mismo. El procedimiento de descarga de migración 3600 se describe en los puntos <1> al <7>. En <1>, se realiza una inicialización antes de las operaciones de clasificación. La fila de protocolo 3404 hace consultas en la capa de interfase de protocolo de un hardware 3406 para determinar que capacidades de descarga, si hay, están disponibles. La unidad intermedia emigrante 3414 indica que la descarga de migración de conexión está disponible y propaga la consulta al mini puesto de PNI 3408. Si se proporciona una habilidad de descarga de chimenea de TCP por una interfase de red física 3410, el mini puerto de PNI 3408 también así lo indica. La descarga de chimenea de TCP habilita cierto procesamiento de TCP/IP que sea descargado al hardware de la interfase de red física 3410 e involucra alguna compilación del estado de protocolo 3420. Consecuentemente, alguna lógica de compilación y agregación puede ser compartida entre los dos mecanismos de descarga. En <2>, una vez que se ha clasificado una conexión de TCP el clasificador 304 inicia una migración de conexión de TCP hacia un huésped 108 seleccionado. Específicamente, un comando de migración indicando un dispositivo objetivo 3500 es emitido a través de la capa de receptáculo 3402 al suplemento emigrante 3412. En <3>, el suplemento emigrante 3412 inicia una migración de conexión de TCP para compilar el estado de protocolo de TCP. Específicamente, el suplemento emigrante 3412 invoca una API de descarga emigrante de inicio de TCP (o más generalmente una llamada de función de conexión emigrante o comando de conexión emigrante). Esta rutina compila el estado relevante para la conexión de TCP especificado que se utiliza para volver a iniciar la conexión en el dispositivo objetivo 3500. El estado de protocolo compilado 3420 incluye el estado de las capas de pila intermedias, incluyendo la pila de TCP 3404 (T), la pila IP 3404 (I), y la pila de ARP 3404 (A). En <4>, una vez que la pila de protocolo 3404 a compilado el estado de protocolo 3420 para que la conexión de TCP sea emigrada, invoca una API de descarga emigrante de inicio en el mini puerto en donde está unida; en este ejemplo ese mini puerto es la unidad intermedia emigrante 3414. Sin embargo, en la práctica, puede haber otras unidades intermedias insertadas entre la pila de protocolo 3404 y la unidad intermedia emigrante 3414, tal como IP QoS. Si es así, aquellas unidades IM pueden participar en la migración, si es relevante, compilando/agregando su estado a la información de estado de conexión para que la conexión sea emigrada. Las unidades intermedias continúan propagando la Mamada de descarga emigrante de inicio en la pila de red, que finalmente da como resultado la ejecución de un manejador de descarga emigrante en la unidad intermedia emigrante 3414. En este punto, la unidad intermedia emigrante 3414 también agrega cualquier dato reconocido con el estado de conexión restante para la transferencia de la conexión de TCP al dispositivo objetivo 3500. En <5>, después de almacenar/copiar la información de estado de conexión para que la conexión de TCP sea emigrada, la unidad intermedia emigrante 3414 notifica a la pila de red que la emigración está en sus etapas finales invocando una API completa de descarga emigrante de inicio. Esta API completa de descarga emigrante de inicio sigue la trayectoria inversa de la pila de red, a través de las mismas unidades intermedias (si hay alguna) y finalmente a la pila de protocolo 3404. Ya que cada capa procesa esta llamada, la información de estado que está asociada con la conexión emigrada puede ser liberada. Hasta que el procesamiento de esta llamada se complete, cada capa puede enviar notificaciones de actualización a la pila de red para actualizar cualquier parte del estado de conexión que haya cambiado desde que se inició la emigración. En <6>, cuando la rutina de completar descarga emigrante de inicio llega a la pila de TCP 3404 (T), el TCP con cuidado cierra (es decir, no envía ningún restablecimiento al cliente 108) la conexión, llenando todo el estado asociado con la conexión emigrada, y propaga la llamada completa de descarga emigrante de inicio al suplemento emigrante 3412. En este punto, la pila de red está libre de cualquier conocimiento residual de la conexión de TCP emigrada, En <7>, cuando la llamada completa de descarga emigrante de inicio regresa a la unidad intermedia emigrante 3414 (a través de la porción de suplemento emigrante 3412 del emigrante de conexión 310), la emigración de la conexión de TCP del dispositivo de origen 3400 al dispositivo objetivo 3500 puede comenzar con la transferencia del estado de conexión al mismo. El estado de conexión puede ser transferido asincrónica y confiablemente. Una vez que se inicia la emigración, el dispositivo de origen 3400 también es responsable de asegurar que los datos subsecuentes del cliente 108 sean enviados al dispositivo objetivo 3500. Consecuentemente, aún después de que la conexión es exitosamente emigrada al objetivo, el originador retiene cierta cantidad de estado para la conexión (por ejemplo, una entrada de tabla de enrutamiento) con el fin de enrutar apropiadamente paquetes subsecuentes hacia el objetivo. Cuando la conexión es terminada, el objetivo notifica al originador que puede purgar cualquier estado residual que permanezca en la conexión emigrada. Además, como una consecuencia de la naturaleza asincrónica de la migración de conexión, los paquetes de datos para la conexión emigrante que son enviados por el dispositivo de origen 3400 (o un expedidor designado por el si hay un dispositivo separado) puede iniciar la llegada en el dispositivo objetivo 3500 antes de que el dispositivo objetivo 3500 reciba el estado de conexión emigrado. La unidad intermedia emigrante 3414 en el dispositivo objetivo 3500 es responsable de guardar en memoria intermedia aquellos paquetes hasta que la conexión emigrada asociada es establecida en el dispositivo objetivo 3500. La Figura 37 ilustra un aspecto ilustrativo de un procedimiento de carga 3700 para una migración de conexión. El procedimiento de descarga de migración 3800 ilustra detalles ilustrativos adicionales para una migración de conexión a través del dispositivo objetivo 3500. Cuando una conexión emigrada llega al dispositivo objetivo 3500, es reenviada a la unidad intermedia emigrante 3414 para procesamiento. Después de unir y asimilar el estado de conexión emigrado, la unidad intermedia emigrante 3414, junto con el suplemento emigrante 3412, inyectan la conexión emigrada a la pila de red local en una forma transparente a la aplicación 316. Para un procedimiento de carga de migración ilustrativo 3700 la migración de una conexión de TCP en los puntos <1> al <8> se describe. En <1>, como se describió anteriormente con referencia al procedimiento de descarga de migración 3600, se realiza una inicialización antes de las operaciones de alojamiento de aplicación. Específicamente, la pila de protocolo 3404 hace consultas con respecto a que capacidades de descarga, si hay, están disponibles. La unidad intermedia emigrante 3414 llena la consulta de soporte de migración de conexión de TCP para indicar que la descarga de migración de conexión está disponible y también propaga la consulta al mini puerto de PDI 3408 para capacidades de descarga de chimenea de TCP, posibles. En <2>, cuando los datos de migración de conexión llegan al dispositivo objetivo 3500, la información de migración de conexión (por ejemplo, un objeto grande binario unido 3422) es suministrada a la unidad intermedia emigrante 3414. La unidad intermedia emigrante 3414 vuelve a ensamblar el estado de conexión, coincide con cualquier dato asociado que haya llegado durante la migración, y prepara la carga a través de la pila de red. Cualquier dato del cliente 102 que llegue durante el procedimiento de carga, la conexión emigrada es almacenada en memoria intermedia por la unidad intermedia emigrante 3414. Después de terminar exitosamente la migración, los datos serán entregados a la aplicación 316. En <3>, para iniciar la carga de la conexión emigrada a la pila de red local, la unidad intermedia emigrante 3414 notifica al suplemento emigrante 3412 que ha llegado una solicitud de conexión emigrada. La unidad intermedia emigrante 3414 también entrega el estado de conexión (o por lo menos el estado de protocolo 3420) al suplemento emigrante 3412. En <4>, el soporte emigrante 3412 inicia la carga de la conexión emigrada invocando una rutina de inyección de inicio de TCP (o más en general una rutina de estado de protocolo de infusión) y proporcionando el estado de protocolo emigrado 3420 a la pila de TCP 3404 (T). En <5>, el TCP/IP recrea la conexión emigrada a través de la pila de protocolo 3404 utilizando el estado de protocolo provisto 3420. Este estado de protocolo 3420 puede incluir uno o más del estado de transporte (TCP), estado de trayectoria (IP), estado vecino y cercano (ARP), etc. En <6>, si la conexión emigrada se vuelve a establecer exitosamente en el dispositivo objetivo 3500, el TCP inicia un evento de conexión a una porción de cliente del suplemento emigrante 3412 para indicar que se ha establecido una nueva conexión. Existe una multitud de posibles razones de falla, pero las razones comunes pueden incluir la falta de un oyente correspondiente, falla de enrutamiento, etc. En estos casos, cuando la pila de red no es capaz de volver a establecer la conexión emigrada, ningún evento de conexión es indicado y se especifica un estado de falla en la llamada completa de inyección de inicio. El emigrante de conexión 310 es responsable de limpiar la migración y de enviar una notificación de reestablecimiento al cliente para abandonar la conexión. En <7>, el suplemento emigrante 3412 actúa como un proveedor para propagar el evento de conexión en la capa de receptáculo 3402, con el fin de indicar a la aplicación oyente 316 que se ha establecido una nueva conexión. Si la aplicación 316 acepta la conexión, procesa las solicitudes y responde a través de operaciones normales de receptáculo de lectura y escritura; la aplicación 316 puede no estar al pendiente de que conexión fue emigrada. Si la conexión no es aceptada por la aplicación 316, TCP termina la conexión, pero no envía una notificación de reestablecimiento al cliente 102. Otra vez, se especifica un estado de falla en la llamada completa e inyección de inicio, y el emigrante de conexión 310 es responsable de limpiar la migración y de enviar una notificación de restablecimiento al cliente 102 para abandonar la conexión. Surge una situación especial cuando la aplicación 316 y el clasificador 304 son co-ubicados en el mismo dispositivo: El suplemento emigrante 3412 puede hacer referencia entre ellos. Cuando ambas clases de programas residen en el mismo huésped 108, ambos pueden estar escuchando la misma dirección(es) de IP y puertos. Sin embargo, el TCP típicamente tiene un oyente por un sola dirección de IP y puerto. Consecuentemente, el suplemento emigrante 3412 puede oscurecer una configuración en donde dos programas se estén escuchando en la misma dirección IP y puerto multiplexando los dos receptáculos en solo oyente en la capa de TCP. En tal caso, cuando llegan eventos de conexión a la porción de cliente del suplemento emigrante 3412, el suplemento emigrante 3412 como un proveedor determina en donde el receptáculo oyente entrega la notificación de conexión en la capa de receptáculo 3402. Si hay solamente un receptáculo escuchando la dirección de IP y puerto correspondientes, entonces ese receptáculo recibe el evento de conexión. Si hay más de un receptáculo escuchando, entonces el receptor depende del contexto en donde se indicó el evento de conexión. Si el evento de conexión es una nueva conexión para una dirección de IP virtual, entonces el evento de conexión es entregado al clasificador 304; si el evento de conexión es para una dirección de IP dedicada (no una dirección de IP equilibrada en carga) o el resultado de la carga de una conexión emigrada, entonces el evento de conexión es entregado a la aplicación objetivo 316. En <8>, una vez que la inyección de la conexión emigrada se completa, el TCP notifica al suplemento emigrante 34 12 invocando al manejador completo de inyección de inicio provisto. Se proporciona un código de estado para notificar al suplemento emigrante 3412 si la conexión fue o no exitosamente cargada. Si la carga de conexión emigrada falla, el emigrante de conexión 310 es responsable de limpiar la migración y de notificar al cliente 102 que la conexión ha sido abandonada enviándole un restablecimiento. Si la conexión emigrada fue exitosamente inyectada a la pila de red local, la unidad intermedia emigrante 3414 puede comenzar a entregar cualesquiera datos guardados en memoria intermedia del cliente 102 pasando los paquetes recibidos a través de la trayectoria de recepción de paquetes de la interfase de protocolo-hardware 3406. Cuando una conexión emigrada se termina (ya que la carga falló, ya que la conexión emigrada es subsecuentemente cerrada a través de medios normales, etc.), el dispositivo objetivo 3500 notifica al dispositivo de origen 3400. El dispositivo de origen 3400 utiliza estas notificaciones para limpiar eficiente y confiablemente el estado de prolongado para conexiones emigradas, incluyendo entradas de tabla de enrutamiento. Por lo tanto, para representar conexiones exitosamente emigradas que terminan arbitrariamente en el fututo, el suplemento emigrante 3412 puede verificar su actividad y notificar a la unidad intermedia emigrante 3414 cuando sus receptáculos se cierran. La Figura 38 muestra un aspecto ilustrativo para la tunelización de paquetes entre un expedidor 302 y un huésped 108. Los paquetes encapsulados 3808 pueden ser tunelizados del expedidor 302 al huésped 108 sin incurrir en una carga general para cada paquete transmitido. Como se describe más adelante, la tunelización es efectuada utilizando un identificador de flujo 3814 y tablas de mapa de encapsulación 3806 y 3810 de tunelistas 312 (F) y 312 (H), respectivamente, del expedidor 302 y huésped 108, respectivamente.

El ¡dentif ¡cador de flujo 3814 es insertado en paquetes encapsulados 3808. Como se observó anteriormente con referencia a la Figura 32, los paquetes de una conexión que llegan subsecuentes a una migración de conexión pueden ser enrutador por el expedidor 302 al huésped 108 (1) utilizando la tunelización a través de un tunelista 312. En (8) (de la Figura 32), el expedidor 302 envía dichos paquetes subsecuentes del expedidor 302 que tiene una dirección de red de "F" al huésped 108 (1) teniendo una dirección de red "H1". Como se describió anteriormente con referencia a la Figura 4, el expedidor 302 puede realizar la NAT, NAT media, tunelización, etc., con el fin de enrutar los paquetes de entrada al huésped 108 (1). Dichos paquetes de entrada incluyen una dirección de IP de destino de la dirección de IP virtual ("VIP") y una dirección de IP fuente de "C1" para paquetes que llegan del cliente 102 (1). Los paquetes que son enrutados al huésped 108 (1) tienen una dirección de IP de destino de H1 y una dirección fuente de C1 (para NAT medio) o "F" (para NAT completo). Esta re-escritura de las direcciones puede interferir con algunos protocolos que esperan que tanto el cliente 102 (1) como el huésped 108 (1) tengan vistas idénticas de las direcciones de fuente y de destino. Además, por lo menos con respecto al NAT completo, las trayectorias de regreso del huésped 108 (1) al cliente 102 (1) que no corren a través del expedidor 302 son prohibitivas, ya que el huésped 108 (1) no conoce la dirección del cliente 102 (1). Son deseables las trayectorias directas del huésped 108 (1) al cliente 102 (1) en situaciones en donde el tráfico del huésped 108 (1) al cliente 102 (1) es especialmente alto y/o significativamente más grande que el tráfico en la dirección opuesta (por ejemplo, cuando el huésped 108 (1) proporciona medios de corriente al cliente 102 (1)).

La tunelización a través de los tunelistas 312 como se describe aquí puede proporcionar vistas idénticas con respecto a las direcciones de fuente y de destino (y puerto) para los cliente 102 y aplicaciones 316 en los huéspedes 108. A manera de ejemplo y con referencia a las Figuras 34 y 35, el tunelista 312 en cada expedidor 302 y huésped 108 pueden operar como parte de o junto con una unidad intermedia emigrante 3414 de un emigrante de conexión 310.

En una implementación descrita para la Figura 38, el emigrante de conexión 310 proporciona un mapa de encapsulación 3812 entre un identificador de flujo 3814 y 4-tupla de TCP/IP 3804. El emigrante de conexión 310 puede ser asociado con un clasificador 304, y un emigrante de conexión 310 (opcionalmente junto con un clasificador 304) puede ser ubicado en el mismo dispositivo como el expedidor 302. Alternativamente, el emigrante de conexión 310 (así como el clasificador 304) puede ser ubicado en un dispositivo diferente del expedidor 302. El mapa de encapsulación 3812 alternativamente puede ser provisto por o junto con la funcionalidad del tunelista 312 que, por ejemplo, está ubicada en y/o está asociada con un clasificador 304. Al ser trazado en 4-tupla de TCP/IP 3804 en el mapa de encapsulación 3812, el identif icador de flujo 3814 sirve para identificar un flujo de paquetes encapsulados 3808 para una conexión particular. 4-tupla de TCP/IP 3804 incluye direcciones de red (y puertos, etc.) para la fuente y el destino para una conexión particular de acuerdo con un protocolo de TCP/IP, o cualquier protocolo similar o análogo. El identificador de flujo 3814 es de 32 bits en una implementación descrita, ya que esto permite que el identificador de flujo sea codificado en los campos de puerto de fuente y destino del encabezado de segmento de TCP en el paquete tunelizado, que permite que el paquete tunelizado sea transmitido sin ninguna carga de espacio de tunelización. En el destino, la 4-tupla de TCP/IP puede ser determinada viendo la 4-tupla que está enlazada al identificador de flujo como extraído de los campos de puerto de fuente y destino. Sin embargo, los identif icadores de flujo 3814 de otras longitudes alternativamente pueden ser utilizados, en especial para otros protocolos tales como RTP de internet, etc. Cada identificador de flujo 3814 puede identificar una única conexión del dispositivo que está originando la tunelización (el cual es el expedidor 302 en este ejemplo). Los identif icadores de flujo 3814 pueden ser generados usando cualquier mecanismo, tal como un contador de conexión de incremento. Alternativamente, el Número de Secuencia Inicial (ISN) del receptor de TCP/IP generado por el emigrante de conexión puede servir como identificadores de flujo 3814. Además, la 4-tupla de TCP/IP 3804 generalmente es más un par de fuente/destino. Cada valor de fuente y cada valor de destino del par de fuente/destino individual puede incluir un identificador de nodo de red (por ejemplo, dirección de red, puerto, alguna combinación de los mismos, etc.) para la fuente y el destino, respectivamente, de un paquete dado que se propaga en una conexión particular. El emigrante de conexión 310 proporciona un mapa de encapsulacion 3812 al huésped 108. El tunelista 312 (H) en el huésped 108 almacena el mapa de encapsulacion 3812 en la tabla de mapa de encapsulacion 3810 como una entrada de mapa de encapsulacion 3810 (1). El tunelista 312 (H) después puede utilizar el identificador de flujo 3814 para trazar e identificar la corrección particular que corresponde a 4-tupla de TCP/IP 3804. El mapa de encapsulacion 3812 opcionalmente puede ser provisto al huésped 108 como parte de un objeto grande binario agrupado 3422 en una operación de migración de conexión. El expedidor 302 también incluye un componente tunelista 312 (F) con una tabla de mapa de encapsulacion 3806. La tabla de mapa de encapsulacion 3806 almacena una entrada de mapa de encapsulacion 3806 (1) que enlaza/diseña la 4-tupla de TCP/IP 3804 para una conexión particular a un identificador de flujo 3814. El tunelista 312 (F) también recibe la información de mapa para la entrada de mapa de encapsulacion 3806 (1 ) del emigrante de conexión 310 (por ejemplo, como un mapa de encapsulacion 3812. Aunque solamente se muestra una entrada de mapa de encapsulacion 3806 (1) y 3810 (1), cada tabla de mapa de encapsulación 3806 y tabla de mapa de encapsulación 3810 puede tener múltiples de estas series. Estas tablas de mapa de encapsulación 3806 y 3810 pueden ser combinadas con otra información, tal como tablas para información de sesión del rastreador de sesión 308. Un dispositivo de transmisión (tal como el expedidor 302) y un dispositivo de recepción (tal como el huésped 108) de paquetes encapsulados 3808 solamente tunelizan entre sí, sus tablas de mapa de encapsulación probablemente tienen las mismas entradas de mapa de encapsulación. De otra manera, la tabla de mapa de encapsulación 3806 y la tabla de mapa de encapsulación 3810 probablemente tienen un grupo total diferente de entradas de mapa de encapsulación 3806 () y de entradas de mapa de encapsulación 3810 (), respectivamente. Durante operación, un paquete de entrada 3802 para una conexión particular es recibido en el expedidor 302. La conexión particular está asociada con 4-tupla de TCP/IP 3804. El paquete de entrada 3802 incluye 4-tupla de TCP/IP 3804 con una dirección de IP fuente (de un cliente 102), una dirección de IP de destino (IP virtual), un puerto de TCP fuente (del cliente 102) y un puerto de TCP de destino. El tunelista 312 (F) acepta el paquete de entrada 3802 para tunelizarse al huésped 108. Al utilizar 4-tupla de TCP/IP 3804, el tunelista 312 (F) tiene acceso a la tabla de mapa de encapsulación 3806 para localizar la entrada de mapa de encapsulación 3806 (1 ). El identificador de flujo 3814 es extraído de la entrada de mapa de encapsulación 3806 (1) como estando enlazada/trazado a la 4-tupla de TCP/IP 3804. Para crear el paquete encapsulado 3808, el tunelista 312 (F) inserta al identificador de flujo 3814 a las porciones de puerto de fuente y de destino del encabezado de 4-tupla de TCP/IP. Estas dos porciones de TCO son de 16 bits cada una, lo cual permite que se inserte un identificador de flujo 3814, de 32 bits. También, para la porción de dirección de IP fuente del encabezado de 4-tupla de TCP/IP, el tunelista 312(F) inserta la dirección de IP "F" del expedidor 302. Para la porción de dirección de IP de destino del encabezado de 4-tupla de TCP/IP, el tunelista 312(F) inserta la dirección de IP "H" del huésped 108. El expedidor 302 enruta/transmite el paquete encapsulado 3808 al huésped 108, y el huésped 108 recibe los paquetes encapsulados 3808 del expedidor 302. El componente de tunelista 312 (H) en huésped 108 detecta que el paquete encapsulado 3808 es un paquete tunelizado que va ha ser desencapsulado. El identificador de flujo 3814 es extraído del paquete encapsulado 3808 y utilizado para buscar la 4-tupla de TCP/IP correspondiente 3804 que está enlazada al mismo en la entrada de mapa de encapsulación 3810 (1) de la tabla de mapa de encapsulación 3810. La 4-tupla de TCP/IP 3804 se utiliza por el tunelista 312 (H) para recrear el encabezado de 4-tupla de TCP/IP 3804 como originalmente se recibió en el paquete de entrada 3802 en el expedidor 302. Específicamente, la dirección IPF del expedidor 302 es reemplazada con la dirección de IP fuente, y la dirección de IPH del huésped 108 es reemplazada con la dirección de IP de destino. Además, el identif icador de flujo 3814 es reemplazado por el puerto de TCP fuente y el puerto de TCP de destino. El paquete desencapsulado después es indicado en la pila de red del huésped 108 para la aplicación objetivo 316. En general, una porción de un encabezado de paquete, incluyendo una porción de un par de fuente/destino, para un paquete dado que necesariamente no se utiliza para comunicar al paquete dado, se puede utilizar para llevar un identif icador de flujo 3814. Al pre-proporcionar por lo menos un par de fuente/destino en el huésped 108, un identif icador de flujo 3814 puede ser empleado para tunelizar (por ejemplo, encapsular y/o desencapsular) paquetes sin incurrir en una carga general de encapsulación sobre cada paquete. Además, los paquetes de tamaño completo con respecto a un protocolo dado pueden ser tunelizados sin ser separados o divididos. La Figura 39 es un diagrama de flujo 3900 que muestra un método ilustrativo para la tunelizacion de paquetes entre un primer dispositivo y un segundo dispositivo. Por ejemplo, el primer dispositivo y el segundo dispositivo pueden corresponder a un dispositivo de origen 3400 y un dispositivo objetivo 3500, respectivamente, de la infraestructura de equilibrio de carga 106 y un grupo de huésped 108, respectivamente. Sin embargo, la tunelización puede ser empleada en implementaciones que no son de equilibrio de carga. El diagrama de flujo 3900 incluye 12 bloques 3902-3924. Aunque las acciones del diagrama de flujo 3900 pueden ser realizadas en otros ambientes y con una variedad de esquemas de software, se utilizan en particular las Figuras 1-3, 32, 34, 35 y 38 para ilustrar ciertos aspectos y ejemplos de método. En el bloque 3902, se envía un mapa de un ¡dentificador de flujo a 4-tupla de TCP/IP a un dispositivo objetivo a partir de un dispositivo de origen. Por ejemplo, el dispositivo de origen 3400 puede enviar un mapa de encapsulacion 3812 que enlaza un ¡dentificador de flujo 3814 a 4-tupla de TCP/IP 3804. En el bloque 3914, el mapa del ¡dentificador de flujo al 4-tupla de TCP/IP es recibido en el dispositivo objetivo del dispositivo de origen. Por ejemplo, el dispositivo objetivo 3500 recibe el mapa de encapsulacion 3812 que enlaza al ¡dentificador de flujo 3814 a 4-tupla de TCP/IP 3804 a partir del dispositivo de origen 3400. Alternativamente, el dispositivo objetivo 3500 puede recibir el mapa de encapsulacion 3812 de otro dispositivo. Como se indica por la flechas desvanecidas 3826 y 3928, las acciones de los bloques 3904-3912 y de los bloques 3916-3924 pueden ocurrir en cierto momento después de las acciones de los bloques 3902 y 3914, respectivamente. En el bloque 3904, un paquete de entrada es recibido en el dispositivo de origen de un cliente. Por ejemplo, un paquete de entrada 3802 que tiene un encabezado con 4-tupla de TCP/IP 3804, puede ser recibido en el dispositivo de origen 3400 de un cliente 102. En el bloque 3906, un identificador de flujo está buscando una conexión que corresponda al paquete del cliente utilizando la 4-tupla de TCP/IP del paquete de entrada. Por ejemplo, el identificador de flujo 3814 puede ser buscado para la conexión con el cliente 102 utilizando 4-tupla de TCP/IP 3804 que está diseñada en el mismo en una entrada de mapa de ehcapsulación 3806 (1 ) de una tabla de mapa de encapsulación 3806. En el bloque 3908, el IP de destino y el IP de fuente del paquete de entrada son reemplazados con una dirección de IP de origen del dispositivo de origen y una dirección de IP objetivo del dispositivo objetivo, respectivamente. Por ejemplo, el dispositivo de origen 3400 puede reemplazar las porciones de dirección de IP de la porción de 4-tupla de TCP/IP 3804 de un encabezado de paquete de entrada 3802 con direcciones de IP de dispositivo de origen 3400 y dispositivo objetivo 3500. En el bloque 3910, el puerto de fuente y el puerto de destino del paquete de entrada son reemplazados con el identificador de flujo, por ejemplo, el dispositivo de origen 3400 puede reemplazar los puertos de TCP de fuente y de destino de la porción de 4-tupla de TCP/IP 3804 del encabezado del paquete de entrada 3802 con el identificador de flujo 3814. En el bloque 3912, el paquete encapsulado es enviado del dispositivo de origen al dispositivo objetivo. Por ejemplo, el dispositivo de origen 3400 puede enviar un paquete encapsulado 3808 al dispositivo objetivo 3500. En el bloque 3916, el paquete encapsulado es recibido en el dispositivo objetivo del dispositivo de origen. Por ejemplo el dispositivo objetivo 3500 puede recibir el paquete encapsulado 3808 del dispositivo de origen 3400. En el bloque 3918, la 4-tupla de TCP/IP es buscada para la conexión correspondiente al paquete recibido del cliente utilizando el identificador de flujo. Por ejemplo, un dispositivo objetivo 3500 puede tener acceso a una tabla de mapa de encapsulacion 3810 en una entrada de mapa de encapsulacion 3810 (1) que diseña al identificador de flujo 3814 a 4-tupla de TCP/IP 3804. En el bloque 3920, la dirección de IP de origen y la dirección de IP objetivo son reemplazadas con una dirección de IP fuente y la dirección de IP de destino, respectivamente, utilizando la 4-tupla de TCP/IP buscada. Por ejemplo, el dispositivo objetivo 3500 puede reemplazar las direcciones de IP del dispositivo de origen 3400 y el dispositivo objetivo 3500 en el paquete encapsulado 3808 con la dirección IP fuente y la dirección de IP de destino de 4-tupla de TCP/IP 3804 como se obtuvo de la tabla de mapa de encapsulacion 3810. En el bloque 3922, el identificador de flujo es reemplazado con el puerto fuente y el puerto de destino del paquete de entrada utilizando la 4-tupla de TCP/IP buscada. Por ejemplo, el dispositivo objetivo 3500 puede reemplazar al identificador de flujo 3814 en el paquete encapsulado 3808 con el puerto de TCP fuente y el puerto de TCP de destino de 4-tupla de TCP/IP 3804. En el bloque 3924, el paquete de cliente es indicado en una aplicación en el dispositivo objetivo. Por ejemplo, una versión desencapsulada del paquete encapsulado 3808, o el paquete de entrada 3802, es indicada a la aplicación 316 del dispositivo objetivo 3500. Las acciones, aspectos, características, componentes, etc., de las Figuras 1-39 son ilustradas en los diagramas que se dividen en bloques múltiples. Sin embargo, el orden, las interconexiones, la representación, etc., en las Figuras 1-39 se describen y/o se muestran no como una limitación, y cualquier número de los bloques puede ser combinado, arreglado, aumentado, omitido, etc., en cualquier forma para implementar uno o más sistemas, métodos, dispositivos, procedimientos, medios, APIs, aparatos, disposiciones, etc., para el equilibrio de carga de red. Además, aunque la descripción de la presente incluye referencias a implementaciones específicas (y el ambiente operativo ilustrativo de la Figura 40), las implementaciones ilustradas y/o descritas pueden ser implementadas en cualquier hardware, software, firmware adecuado, o combinación de los mismos y utilizando cualquier organización de red adecuada, protocolo de transporte/comunicación, interfases de programación de aplicación (APIs), arquitecturas de cliente-servidor, etc.

Ambiente Operativo Ilustrativo para Computadora u Otro dispositivo La Figura 40 ilustra un ambiente operativo de cómputo ilustrativo 4000 (o dispositivo general) que es capaz de (completa o parcialmente) implementar por lo menos un sistema, dispositivo, aparato, componente, disposición, protocolo, aspecto, método, procedimiento, medios, API, alguna combinación de éstos, etc., para el equilibrio de carga de red descrito aquí. El ambiente operativo 4000 puede ser utilizado en las arquitecturas de computadora y red descritas más adelante en una situación independiente. El ambiente operativo ilustrativo 4000 es el único ejemplo de un ambiente y no está destinado a sugerir ninguna limitación del alcance de uso o funcionalidad del dispositivo aplicable (incluyendo computadora, nodo de red, dispositivo de entretenimiento, aparato móvil, dispositivo electrónico general), como arquitecturas. Ningún ambiente operativo 4000 (o su dispositivo) puede ser interpretado como teniendo alguna dependencia o requerimiento relacionado con alguna o alguna combinación de componentes ilustrados en la Figura 40. Además, el equilibrio de carga de red puede ser implementado con numerosos otros ambientes o configuraciones de dispositivo de propósito general o de propósito especial (incluyendo un sistema de cómputo). Ejemplos de dispositivos, sistemas, ambientes, y/o combinaciones bien conocidos que pueden ser adecuados para utilizarse aquí incluyen, pero no se limitan a, computadoras personales, computadoras de servidor, clientes mínimos, clientes máximos, asistentes digitales personales (PDAs) o teléfonos móviles, relojes, dispositivos portátiles, sistemas de multiprocesador, sistemas a base de microprocesador, cajas de TV por cable, electrónica de consumidor programable, máquinas de videojuegos, consolas de juegos, unidades para jugar portátiles, PCs de red, minicomputadoras, macrocomputadoras, nodos de red, ambientes de cómputo de procesamiento distribuido o múltiple que incluyen cualquiera de los sistemas o dispositivos anteriores, alguna combinación de éstos, etc. Las implementaciones para el equilibrio de carga de red pueden describirse en el contexto general de instrucciones ejecutables por un procesador. En general, las instrucciones ejecutables por un procesador incluyen rutinas, programas, protocolos, objetos, interfases, componentes, estructuras de datos, etc., que realizan y/o permiten tareas particulares y/o implementan tipos de datos abstractos particulares. El equilibrio de carga de red, como se describe en ciertas implementaciones aquí, también puede ser practicado en ambientes de procesamiento distribuido, en donde las tareas son realizadas por dispositivos de procesamiento enlazados remotamente que están conectados a través de un enlace de comunicaciones y/o red. Especialmente en un ambiente de cómputo distribuido, las instrucciones ejecutables por procesador pueden ser ubicadas en medios de almacenamiento separados, ejecutarse por diferentes procesadores, y/o propagarse a través de medios de transmisión. El ambiente operativo 4000 ilustrativo incluye un dispositivo de cómputo de propósito general en la forma de una computadora 4002, la cual puede comprender cualquier dispositivo (por ejemplo, electrónico) con capacidades de cómputo/procesamiento. Los componentes de la computadora 4002 pueden incluir, pero no se limitan a, uno o más procesadores o unidades de procesamiento 4004, una memoria de sistema 4006, un colector común de sistema 4008 que acopla varios componentes del sistema incluyendo el procesador 4004 a la memoria de sistema 4006. Los procesadores 4004 no están limitados por los materiales a partir de los cuales se forman o los mecanismos de procesamiento empleados ahí. Por ejemplo, los procesadores 4004 pueden estar compuestos de semiconductores y/o transistores (por ejemplo, circuitos integrados electrónicos (ICs)). En dicho contexto, las instrucciones ejecutables por un procesador pueden ser instrucciones electrónicamente ejecutables. En forma alternativa, los mecanismos de o para los procesadores 4004, y de esta manera de o para la computadora 4002, pueden incluir, pero no se limitan a, cómputo cuántico, cómputo óptico, cómputo mecánico (por ejemplo, utilizando nanoteconología), etc. El colector común de sistema 4008 representa uno o más de cualquiera de los muchos tipos de estructuras de colector común de cables o inalámbricas, incluyendo un colector común de memoria o un controlador de memoria, una conexión de punto a punto, una fábrica de conmutación, un conector común periférico, un puerto gráfico acelerado, y un procesador o conector común local utilizando cualquiera de una variedad de arquitecturas de conducto común. A manera de ejemplo, dichas arquitecturas pueden incluir un conductor común de Arquitectura estándar industrial (ISA), un conductor común de arquitectura de microcanal (MCA), un conector común de ISA mejorado (EISA), un conductor común local de Asociación de Estándares de Videoelectrónica (VESA), un colector común de interconexiones de componente periféricos (PCI) conocido también como un conector común de mezanine, alguna combinación de éstos, etc. La computadora 4002 típicamente incluye una variedad de medios accesibles por el procesador. Dichos medios pueden ser cualquiera medios disponibles que sean accesibles por la computadora 4002 u otro dispositivo (por ejemplo electrónico), e incluyen tanto medios volátiles como no volátiles, medios removibles como no removibles, medios de almacenamiento y de transmisión. La memoria de sistema 4006 incluye medios de almacenamiento accesibles por procesador en la forma de memoria volátil, tal como memoria de acceso aleatorio (RAM) 4040, y/o memoria no volátil, tal como memoria de solo lectura (ROM), 4012. Un sistema de entrada/salida básico (BIOS) 4014, conteniendo las rutinas básicas que ayudan a transferir la información entre elementos dentro de la computadora 4002, tal como durante el arranque, típicamente está almacenado en la ROM 4012. La RAM 4010 típicamente contiene datos y/o módulos/instrucciones de programa son inmediatamente accesibles a y/o actualmente operan por la unidad de procesamiento 4004.

La computadora 4002 también puede incluir otros medios de almacenamiento removibles/no removibles y/o volátiles/no volátiles. A manera de ejemplo, la Figura 40 ilustra una unidad de disco duro una disposición de unidad de disco 4016 para leer de y escribir a (típicamente) medio magnético no removible, no volátil (no mostrado en forma separada); una unidad de disco magnético 4018 para leer de y escribir a (típicamente) un disco magnético removible, no volátil 4020 (por ejemplo, un "disco flexible"); y una unidad de disco óptico 4022 para leer de y/o escribir a (típicamente) un disco óptico no volátil, removible 4024, tal como un CD, DVD, u otro medio óptico. La unidad de disco duro 4016, la unidad de disco magnético 4018, y la unidad de disco óptico 4022 cada uno están conectados al colector común de sistema 4008 a través de una o más interfases de medios de almacenamiento 4026. Alternativamente, la unidad de disco duro 4016, la unidad de disco magnético 4018 y la unidad de disco óptico 4022 pueden ser conectadas al colector común de sistema 4008 a través de una o más de una o más de otras interfases separados o combinadas (no mostradas). Las unidades de disco y sus medios accesibles por un procesador asociado proporcionan almacenamiento no volátil de instrucciones ejecutables por un procesador, tales como estructuras de datos, módulos de programa, y otros datos para la computadora 4002. Aunque la computadora 4002 ilustrativa muestra un disco duro 4016, un disco magnético removible 4020, y un disco óptico removible 4024 se debe apreciar que otros tipos de medios accesibles por un procesador pueden almacenar instrucciones que son accesibles por un dispositivo, tales como casetes magnéticos u otros dispositivos de almacenamiento magnético, memoria flash, disco compactos (CDs), discos versátiles digitales (DVDs) u otro almacenamiento óptico, RAM, ROM, memorias de solo lectura programables eléctricamente borrables (EEPROM), etc. Dichos medios también pueden incluir el así llamado de propósito especial o circuitos integrados de IC de cables duros. En otras palabras, se pueden utilizar cualquiera de los medios accesibles por un procesador para realizar el medio de almacenamiento del ambiente operativo 4000 ilustrativo. Cualquier número de módulos de programa (u otras unidades o grupos de instrucciones/código) puede ser almacenado en un disco duro 4016, disco magnético 4020, disco óptico 4024, ROM 4012 y/o RAM 4040, incluyendo a manera de ejemplo general, un sistema operativo 4028, uno o más programas de aplicación 4030 u otros módulos de programa 4032 y datos de programa 4034. Un usuario puede introducir comandos y/o información a la computadora 4002 a través de dispositivos de entrada tales como un teclado 4036 y un dispositivo de señalamiento 4038 (por ejemplo, un "ratón"). Otros dispositivos de entrada 4040 (no específicamente mostrados) pueden incluir un micrófono, una palanca de juegos, una almohadilla de juegos, una antena, puerto en serie, explorador, y/o similares. Estos y otros dispositivos de entrada están conectados a la unidad de procesamiento 4004 a través de interfases de entrada/salida 4042 que están acopladas al colector común de sistema 4008. Sin embargo, los dispositivos de entrada y/o dispositivos de salida más bien pueden ser conectados a través de otra interfase y estructuras de colector común, tales como un puerto paralelo, un puerto de juegos, un puerto de conector común en serie universal (USV), un puerto infrarrojo, una interfase de IEEE 1394 ("Firewire"), una interfase inalámbrica IEEE 802.11, una interfase inalámbrica de Bluetooth®, etc. Un monitor/pantalla de visión 4044 u otro tipo de dispositivo de presentación también puede ser conectado al colector común de sistema 4008 a través de una interfase, tal como un adaptador de vídeo 4046. El adaptador de vídeo 4046 (u otro componente) puede ser o puede incluir una tarjeta de gráficos para procesar cálculos de gráficos intensos y para manejar requerimientos de presentación a demanda. Típicamente, una tarjeta de gráficos incluye una unidad de procesamiento de gráficos (GPU), RAM de video (VRAM), etc., para facilitar la presentación de gráficos y realizar las operaciones de gráficos. Además del monitor 4044, otros dispositivos periféricos de salida pueden incluir componentes tales como bocinas (no mostradas) y una impresora 4048, la cual puede ser conectada a la computadora 4002 a través de interfases de entrada/salida 4042. La computadora 4002 puede operar en un ambiente en red utilizando conexiones lógicas a una o más computadoras remotas, tales como un dispositivo de cómputo remoto 4050. A manera de ejemplo, el dispositivo de cómputo remoto 4050 puede ser una computadora personal, una computadora portátil (por ejemplo, computadora pequeña, computadora de tableta, PDA, estación móvil, etc.), una computadora de tamaño de bolsillo, un reloj, un dispositivo de juegos, un servidor, un enrutador, una computadora de red, un dispositivo de par en par, otro nodo de red, u otro tipo de dispositivo como se listó anteriormente, etc. Sin embargo, el dispositivo de cómputo remoto 4050 se ilustra como una computadora portátil que puede incluir muchos o todos los elementos y características descritas aquí con respecto a la computadora 4002. Las conexiones lógicas entre la computadora 4002 y la computadora remota 4050 están ilustradas como una red de área local (LAN) 4052 y una red de área amplia general (WAN) 4054. Dichos ambientes en red son lugares comunes en oficinas, redes de computadora de empresas, ¡ntranets, Internet, redes telefónicas fijas y móviles, redes inalámbricas ad-hoc y de infraestructura, otras redes inalámbricas, redes de juegos, algunas de sus combinaciones, etc. Dichas conexiones de redes y comunicaciones son ejemplos de medios de transmisión. Cuando se implementa en un ambiente en red de LAN, la computadora 4002 usualmente se conecta a la LAN 4052 a través de una interfase de red o adaptador 4056. Cuando se implementa en un ambiente en red de WAN, la computadora 4002 típicamente incluye un módem 4058 u otro medio para establecer comunicaciones a través de la WAN 4054. El módem 4058, el cual puede ser interno o externo a la computadora 4002 puede ser conectado al colector común de sistema 4008 a través de interfases de entrada/salida 4042 o cualquier otro mecanismo apropiado. Se debe apreciar que las conexión de red ilustradas son ilustrativas y que se pueden emplear otros medios para establecer enlaces de comunicaciones entre las computadoras 4002 y 4050. Además, se puede emplear otro tipo de hardware que específicamente esté diseñado para servidores. Por ejemplo, se pueden utilizar tarjetas de aceleración de SSL para descargar cálculos de SSL. Además, especialmente en un ambiente operativo de equilibrio de carga de red, se pueden instalar y utilizar en los dispositivos de servidor clasificadores de hardware y/o de paquete de descarga en las interfases de red o adaptadores 4056 (por ejemplo, en tarjetas de interfase de red). En un ambiente en red, tal como aquel ilustrado en el sistema operativo 4000, los módulos de programa u otras instrucciones que son representadas con relación a la computadora 4002, o sus porciones pueden almacenarse total o parcialmente en un dispositivo de almacenamiento de medio o remoto. A manera de ejemplo, los programas de aplicación remotos 4060 residen en un componente de memoria de la computadora remota 4050, pero se pueden utilizar o de otra manera son accesibles a través de la computadora 4002. También, para propósitos de ilustración, los programas de aplicación 4030 y otras instrucciones ejecutables por un procesador, tal como el sistema operativo 4028 se ¡lustran aquí como bloques discretos, pero se reconocen como programas, componentes, y otras instrucciones que residen en varios momentos en diferentes componentes de almacenamiento del dispositivo de cómputo 4002 (y/o dispositivo de cómputo remoto 4050). Y se ejecutan por el procesador 4004 de la computadora 4002 (y/o aquellos del dispositivo de cómputo remoto 4050). Aunque los sistemas, medios, dispositivos, métodos, procedimientos, aparatos, técnicas, esquemas, aspectos, disposiciones y otras implementaciones han sido descritos en el lenguaje específico a características estructurales, lógicas algorítmicas y funcionales y/o diagramas, se debe entender que la invención definida en las reivindicaciones anexas necesariamente no está limitada a características específicas o los diagramas descritos, más bien, las características y diagramas específicos se describen como formas ilustrativas para ¡mplementar la presente invención.

Claims

REIVINDICACIONES 1. - Uno o más medios accesibles por procesador que comprenden instrucciones ejecutables por procesador que, cuando se ejecutan, dirigen a un dispositivo para realizar acciones que comprenden: aceptar una conexión; agregar un estado de conexión para la conexión a partir de una pila de protocolo; y enviar el estado de conexión. 2. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, en donde la acción de aceptar comprende una acción de: enviar un paquete de reconocimiento en respuesta a un paquete de solicitud de conexión. 3. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, que comprende las instrucciones ejecutables por procesador que, cuando se ejecutan, dirigen al dispositivo para realizar una acción adicional de: recibir datos para la conexión; en donde la acción de agregar comprende la acción de: agregar el estado de conexión a partir de un estado de protocolo de la pila de protocolo y los datos. 4. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, en donde la acción de agregar comprende la acción de: compilar un estado de protocolo a partir de la pila de protocolo. 5. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 4, en donde la acción de compilar comprende una acción de: compilar el estado de protocolo a partir de la pila de protocolo comenzando a un nivel más alto de la pila de protocolo. 6. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 4, en donde la acción de compilar comprende una acción de: compilar el estado de protocolo a partir de la pila de protocolo en una porción de pila de protocolo de control de transmisión (TCP) y una porción de pila de protocolo internet (IP). 7. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, en donde la acción de enviar comprende las acciones de: unir el estado de conexión con un identificador de flujo que corresponde a la conexión para producir un objeto grande binario; y transmitir el objeto grande binario de un dispositivo de origen a un dispositivo objetivo. 8. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, en donde la acción de enviar comprende las acciones de: unir el estado de conexión con un identificador de flujo que corresponde a la conexión para producir un objeto grande binario; y transmitir el objeto grande binario de un dispositivo de origen a un dispositivo objetivo en una forma confiable, de manera que el objeto grande binario puede ser recibido intacto en el dispositivo objetivo aún si uno o más paquetes que comprenden el objeto grande binario se pierden o se corrompen. 9. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, que comprende instrucciones ejecutables pro procesador que, cuando se ejecutan, dirigen al dispositivo para realizar otras acciones que comprende: seleccionar un identificador de flujo para la conexión que responden a un contador de conexión; y enviar el identificador de flujo para identificar paquetes que corresponden a la conexión. 10. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 1, en donde la acción de enviar comprende una acción de: enviar el estado de conexión a un dispositivo objetivo; en donde las instrucciones ejecutables por procesador, cuando se ejecutan, dirigen al dispositivo para realizar una acción adicional que comprende: enviar paquetes subsecuentes para la conexión al dispositivo objetivo usando un identificador de flujo para encapsular los paquetes subsecuentes. 11. - Uno o más medios accesibles por procesador que comprenden instrucciones ejecutables por procesador que, cuando se ejecutan, dirigen a un dispositivo para realizar acciones que comprenden: recibir un estado de conexión para una conexión; inyectar el estado de conexión para la conexión a una pila de red; y continuar la conexión utilizando el estado de conexión inyectado. 12. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, en donde la acción de continuar comprende una acción de: continuar la conexión indicando los paquetes recibidos a una aplicación de acuerdo con el estado de conexión inyectado. 13. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, en donde: la acción de recibir comprende una acción de: recibir el estado de conexión, el estado de conexión teniendo un estado de protocolo y datos para la conexión; y la acción de inyectar comprende una acción de: inyectar el estado de protocolo a una porción de pila de protocolo de la pila de red. 14. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 13, en donde la acción de inyectar el estado de conexión además comprende una acción de: indicar los datos para la conexión a la pila de red hacia una aplicación. 15. Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, en'donde la acción de inyectar comprende una acción de: infundir un estado de protocolo del estado de conexión a una porción de pila de protocolo de la pila de red. 16. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 15, en donde la acción de de infundir comprende una acción de: infundir el estado de protocolo a la pila de protocolo empezando a un nivel más alto de la pila de protocolo. 17. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 15, en donde la acción de infundir comprende una acción de: infundir el estado de protocolo a la pila de protocolo en una porción de pila de protocolo de control de transmisión (TCP) y una porción de pila de protocolo internet (IP). 18. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, en donde la acción de recibir comprende las acciones de: recibir un objeto grande binario de un dispositivo de origen a un dispositivo objetivo, el objeto grande binario incluyendo el estado de conexión y un identif icador de flujo que corresponde a la conexión; y separar el estado de conexión y el identificador de flujo a un nivel de la pila de red que está por debajo de una porción de pila de protocolo de la pila de red. 19.- Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, que comprende las instrucciones ejecutables por procesador que, cuando se ejecutan, dirigen al dispositivo para realizar las acciones adicionales que comprenden: recibir un mapa de encapsulacion; y almacenar el mapa de encapsulacion recibido en una tabla de mapa de encapsulacion que puede ser accesado de acuerdo con el identif icador de flujo. 20.- Uno o más medios accesibles por procesador de acuerdo con la reivindicación 11, en donde la acción de recibir una acción de: recibir el estado de conexión de un dispositivo de origen; en donde las instrucciones ejecutables por procesador, cuando se ejecutan, dirigen al dispositivo para realizar una acción más de: recibir del dispositivo de origen, paquetes encapsulados que tienen un identificador de flujo; y des-encapsular los paquetes encapsulados utilizando una entrada de mapa de encapsulacion que enlaza al identificador de flujo a un par de fuente/destino. 21.- Uno o más medios accesibles por procesador que comprenden instrucciones ejecutables por procesador que comprenden por lo menos parte de una aplicación, en donde las instrucciones ejecutables por procesador, cuando se ejecutan, permiten que la aplicación inicie una migración de conexión emitiendo una llamada de función de emigrar conexión a una capa de receptáculo, de manera que la capa de receptáculo propaga la llamada de función de emigrar conexión a una pila de protocolo, la llamada de función de emigrar conexión precipitando, en la pila de protocolo, una compilación del estado de protocolo de la pila de protocolo. 22.- Uno o más medios accesibles por procesador de acuerdo con la reivindicación 21, en donde la aplicación comprende por lo menos uno de una aplicación general, una aplicación huésped, y una aplicación de equilibrio de carga. 23.- Un dispositivo que comprende: un emigrante de conexión que está configurado para emigrar conexiones lejos del dispositivo; el emigrante de conexión capaz de precipitar una compilación de estado de protocolo para una conexión a través de una pila de protocolo; el emigrante de conexión adaptado para agregar el estado de protocolo compilado con datos para la conexión a un estado de conexión agregado de la conexión; el emigrante de conexión además capaz de hacer que el estado de conexión agregado sea enviado hacia un dispositivo objetivo. 24. - El dispositivo de acuerdo con la reivindicación 23, en donde el emigrante de conexión es realizado por lo menos parcialmente en software. 25. - El dispositivo de acuerdo con la reivindicación 23, en donde el dispositivo además comprende: un clasificador que es capaz de aceptar la conexión, el clasificador adaptado para emitir un comando de emigrar conexión al emigrante de conexión. 26. - El dispositivo de acuerdo con la reivindicación 25, en donde los datos, los cuales son agregados con el estado de protocolo compilado al estado de conexión agregado, comprenden datos que han sido reconocidos por el clasificador. 27. - El dispositivo de acuerdo con la reivindicación 23, en donde el emigrante de conexión comprende: un suplemento emigrante que está ubicado arriba de la pila de protocolo en una pila de red del dispositivo; y un controlador intermedio emigrante que está ubicado por abajo de la pila de protocolo en la pila de red del dispositivo. 28. - El dispositivo de acuerdo con la reivindicación 27, en donde: el suplemento emigrante está ubicado entre la pila de protocolo y la capa de receptáculo de la pila de red del dispositivo; y el controlador intermedio emigrante está localizado entre la pila de protocolo y por lo menos un mini puerto de la pila de red del dispositivo. 29. - El dispositivo de acuerdo con la reivindicación 28, en donde el controlador intermedio emigrante está ubicado en la capa de interfase de protocolo-hardware de la pila de red del dispositivo. 30. - El dispositivo de acuerdo con la reivindicación 27, en donde: el suplemento emigrante está adaptado para recibir un comando de conexión de emigrante y para propagar el comando de conexión de emigrante a la pila de protocolo; y el controlador intermedio emigrante está adaptado para divertir una copia de los datos para la conexión para la agregación subsecuente con el estado de protocolo compilado. 31.- El dispositivo de acuerdo con la reivindicación 27, en donde el controlador intermedio emigrante está adaptado para unir el estado de conexión agregado y un identif icador de flujo para conectarse a un objeto grande binario. 32. - El dispositivo de acuerdo con la reivindicación 23, en donde la conexión comprende una conexión de protocolo de control de transmisión/protocolo internet (TCP/IP), y el estado de protocolo compilado incluye información relacionada con una conexión de TCP/IP. 33. - El dispositivo de acuerdo con la reivindicación 23, en donde el dispositivo además comprende: la pila de protocolo, la pila de protocolo adaptada para compilar el estado de protocolo para conectarse al estado de protocolo compilado que responde a un comando de conexión de emigrante. 34.- Un dispositivo que comprende: un emigrante de conexión que está configurado para emigrar conexiones a través del dispositivo; el emigrante de conexión adaptado para interceptar un estado de conexión para una conexión que es enviada de un dispositivo de origen, el estado de conexión incluyendo un estado de protocolo y datos; el emigrante de conexión además está adaptado para inyectar el estado de conexión a una pila de red del dispositivo; el emigrante de conexión capaz de precipitar una infusión del estado de protocolo para la conexión a través de una pila de protocolo de la pila de red. 35.- El dispositivo de acuerdo con la reivindicación 34, en donde el emigrante de conexión comprende por lo menos parte de la infraestructura de equilibrio de carga que está residente en y se ejecuta en el dispositivo. 36.- El dispositivo de acuerdo con la reivindicación 34, en donde el dispositivo además comprende: una aplicación que está alojada en el dispositivo; en donde el emigrante de conexión además está configurado para emigrar conexiones a través del dispositivo en una forma que es transparente a la aplicación. 37.- El dispositivo de acuerdo con la reivindicación 34, en donde los datos incluidos en el estado de conexión comprenden datos que fueron reconocidos en el dispositivo de origen. 38. - El dispositivo de acuerdo con la reivindicación 34, en donde el emigrante de conexión comprende: un suplemento de emigrante que está ubicado por arriba de la pila de protocolo en la pila de red del dispositivo; y un controlador intermedio emigrante que está ubicado por abajo de la pila de protocolo en la pila de red del dispositivo. 39. - El dispositivo de acuerdo con la reivindicación 38, en donde: el suplemento de emigrante está ubicado entre la pila de protocolo y la capa de receptáculo de la pila de red del dispositivo; y el controlador intermedio emigrante está ubicado entre la pila de protocolo y por lo menos un mini puerto de la pila de red del dispositivo. 40. - El dispositivo de acuerdo con la reivindicación 38, en donde: el suplemento emigrante está adaptado para ser notificado por el controlador intermedio emigrante de un procedimiento de carga de migración y está adaptado para iniciar una rutina de infusión de estado de protocolo con la pila de protocolo; y el controlador intermedio emigrante está adaptado para detectar la llegada del estado de conexión para la conexión, para divertir el estado de conexión lejos de una porción inferior de la pila de protocolo, y para notificar al suplemento de emigrante del procedimiento de carga de migración. 41. - El dispositivo de acuerdo con la reivindicación 38, en donde el controlador intermedio emigrante está adaptado para desunir un objeto grande binario recibido que incluye el estado de conexión para la conexión y un identif icador de flujo que corresponde a la conexión. 42. - El dispositivo de acuerdo con la reivindicación 34, en donde el dispositivo además comprende: la pila de protocolo, la pila de protocolo incluyendo una capa de protocolo de control de transmisión (TCP) y una capa de protocolo internet (IP). 43. - El dispositivo de acuerdo con la reivindicación 34, en donde el dispositivo además comprende: la pila de protocolo, la pila de protocolo adaptada para infundir el estado de protocolo para la conexión a través de la pila de protocolo que responde a la iniciación de una rutina de estado de protocolo. 44. - Una disposición para la manipulación de conexión, que comprende: medios de migración para emigrar conexiones de un dispositivo de origen a un dispositivo objetivo transfiriendo un estado de conexión siendo emigrado del dispositivo de origen al dispositivo objetivo; y medios de tunelización para tunelizar paquetes para conexiones emigradas en un formato encapsulado del dispositivo de origen al dispositivo objetivo. 45. - La disposición de acuerdo con la reivindicación 44, en donde los medios de migración comprende: medios de agregación para agregar el estado de conexión de un estado de protocolo y de datos reconocidos para la conexión que son emigrados. 46. - La disposición de acuerdo con la reivindicación 45, en donde los medios de agregación comprenden: medios de compilación para compilar el estado de protocolo de una pila de protocolo. 47. - La disposición de acuerdo con la reivindicación 44, en donde los medios de tunelización comprenden: medios de encapsulación para encapsular los paquetes para las conexiones emigradas, utilizando identif icadores de flujo que reemplazan por lo menos una parte de pares de información de dirección fuente/destino de los paquetes. 48. - La disposición de acuerdo con la reivindicación 44, en donde los medios de tunelización comprenden: medios de mapa para trazar pares de información de dirección fuente/destino a identificadores de flujo individuales, pares de información de dirección fuente/destino respectivos que identifican conexiones emigradas respectivas. 49. - La disposición de acuerdo con la reivindicación 44, en donde los medios de migración comprenden: medios de controlador para unir el estado de conexión con un identificador de flujo que se utiliza para encapsular paquetes de la conexión que es emigrada. 50. - La disposición de acuerdo con la reivindicación 44, en donde los medios de migración comprenden: medios de inyección para inyectar una porción de estado de protocolo del estado de conexión para la conexión que está siendo emigrada hacia una porción de pila de protocolo de una pila de red. 51. - La disposición de acuerdo con la reivindicación 44, en donde los medios de tunelización comprenden: medios de desencapsulación para desencapsular los paquetes tunelizados para las conexiones emigradas utilizando identificadores de flujo que se enlazan por lo menos a una parte de los pares de información de dirección fuente/destino de los paquetes. 52.- La disposición de acuerdo con la reivindicación 44, en donde los medios de tunelización comprenden: medios de mapa para trazar identificadores de flujo individuales a los pares de información de dirección fuente/destino, los pares respectivos de dirección fuente/destino identificando las conexiones emigradas respectivas. 53.- La disposición de acuerdo con la reivindicación 44, en donde los medios de migración comprenden: medios de controlador para divertir los paquetes tunelizados para las conexiones emigradas en el formato encapsulado y dirigirlos a los medios de tunelización. 54.- La disposición de acuerdo con la reivindicación 44, en donde la disposición comprende por lo menos un dispositivo. 55.- La disposición de acuerdo con la reivindicación 44, en donde la disposición comprende por lo menos uno o más medios accesibles por procesador. 56.- Un dispositivo que comprende: un tunelista que está configurado para tunelizar paquetes lejos del dispositivo; el tunelista teniendo acceso a una tabla de mapa de encapsulación, la tabla de mapa de encapsulación incluyendo una pluralidad de entradas de mapa de encapsulación, cada entrada de mapa de encapsulación enlazando por lo menos una porción de un par de fuente/destino a un identificador de flujo; el tunelista adaptado para aceptar un paquete teniendo un par particular de fuente/destino; el tunelista capaz de ver un identificador de flujo particular en una entrada de mapa de encapsulación particular utilizando por lo menos una porción del par particular de fuente/destino; en donde el tunelista además está adaptado para encapsular el paquete reemplazando parte del paquete con el identificador de flujo particular. 57. - El dispositivo de acuerdo con la reivindicación 56, en donde el tunelista se realiza por lo menos parcialmente en software. 58. - El dispositivo de acuerdo con la reivindicación 56, en donde el dispositivo además comprende: un emisor que es capaz de recibir el paquete de un cliente, el emisor adaptado para proporcionar el paquete al tunelista. 59.- El dispositivo de acuerdo con la reivindicación 56, en donde el tunelista además está adaptado para encapsular el paquete reemplazando por lo menos parte del par particular de fuente/destino del paquete con el identificador de flujo particular. 60. - El dispositivo de acuerdo con la reivindicación 56, en donde el identificador de flujo comprende 32 bits. 61. - El dispositivo de acuerdo con la reivindicación 56, en donde el par particular de fuente/destino comprende un par particular de información de dirección de fuente/destino. 62. - Un dispositivo que comprende: un tunelista que está configurado para tunelizar paquetes hacia el dispositivo; el tunelista teniendo acceso a una tabla de mapa de encapsulación, la tabla de mapa de encapsulación incluyendo una pluralidad de entradas de mapa de encapsulación, cada entrada de mapa de encapsulación enlazando un identif icador de flujo a por lo menos una porción de un par fuente/destino; el tunelista adaptado para aceptar un paquete encapsulado teniendo un identif icador de flujo particular; el tunelista capaz de ver un par particular de fuente/destino en una entrada de mapa de encapsulación particular utilizando el identif icador de flujo particular; en donde el tunelista además está adaptado pata desencapsular el paquete encapsulado reemplanzando al identificador de flujo particular con por lo menos parte del par particular de fuente/destino. 63. - El dispositivo de acuerdo con la reivindicación 62, en donde el tunelista comprende un controlador intermedio emigrante que está adaptado para interceptar al paquete encapsulado para prevenir que el paquete encapsulado sea provisto a una pila de protocolo del dispositivo. 64. - El dispositivo de acuerdo con la reivindicación 62, en donde el dispositivo además comprende: una pila de protocolo; en donde el tunelista además está adaptado para desencapsular el paquete encapsulado reemplazando el identificador de flujo particular con por lo menos parte del par particular de fuente/destino para producir un paquete desencapsulado; el tunelista capaz de indicar el paquete desencapsulado a la pila de protocolo. 65. - El dispositivo de acuerdo con la reivindicación 64, en donde el tunelista comprende un adaptador de red virtual que está unido a una dirección de destino del paquete desencapsulado. 66. - El dispositivo de acuerdo con la reivindicación 62, en donde el dispositivo comprende un huésped de un grupo de huéspedes. 67. - El dispositivo de acuerdo con la reivindicación 62, en donde el par particular de fuente/destino corresponde a un 4-tupla de protocolo de control de transmisión/protocolo internet (TCP/IP); y en donde el tunelista además está adaptado para desencapsular el paquete encapsulado reemplazado el identif icador de flujo particular con un puerto de TCP fuente y un puerto de TCP de destino del 4-tupla de TCP/IP. 68. - Uno o más medios áccesibles por procesador que comprende instrucciones ejecutables por procesador que, cuando de ejecutan, dirigen a un dispositivo a realizar acciones que comprenden: obtener por lo menos una porción de un par fuente/destino de un paquete de entrada; accesar una tabla de mapa de encapsulación usando por lo menos la porción obtenida del par fuente/destino para ubicar una entrada de mapa de encapsulación; extraer un identificador de flujo de la entrada de mapa de encapsulación ubicada; y reemplazar la entrada del paquete de entrada con el identif icador de flujo extraído para producir un paquete encapsulado. 69. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, que comprende las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo para realizar una acción adicional que comprende: recibir el paquete de entrada de un cliente. 70. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, que comprende las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo para realizar una acción adicional que comprende: enrutar el paquete encapsulado a un huésped. 71. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, en donde el par fuente/destino del paquete de entrada comprende un par de dirección de fuente/destino del paquete de entrada. 72. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, en donde por lo menos una porción de las instrucciones ejecutables por un procesador comprenden por lo menos parte de la infraestructura de equilibrio de carga. 73.- Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, en donde la acción de reemplazar comprende una acción de: reemplazar por lo menos parte del par fuente/destino con el identif icador de flujo extraído para producir el paquete encapsulado. 74.- Uno o más medios accesibles por procesador de acuerdo con la reivindicación 68, en donde: la acción de obtener comprende una acción de: obtener por lo menos una porción de un 4-tupla de protocolo de control de transmisión/protocolo internet (TCP/IP) del paquete de entrada; y la acción de reemplazar comprende una acción de: reemplazar un puerto de TCP fuente y un puerto de TCP de destino del paquete de entrada con el identificador de flujo extraído. 75. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 74, que comprenden las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo a realizar una acción adicional que comprende: reemplazar una dirección de IP fuente y una dirección de IP de destino del paquete de entrada con una dirección de IP de un dispositivo de origen y una dirección de IPde un dispositivo objetivo, respectivamente. 76. - Uno o más medios accesibles por procesador que comprenden las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo a realizar acciones comprenden: obtener un identificador de flujo de un paquete encapsulado; tener acceso a una tabla de mapa de encapsulación usando el identificador de flujo obtenido para ubicar una entrada de mapa de encapsulación; extraer por lo menos una porción de un par de fuente/destino de la entrada de mapa de encapsulación localizada, el par de fuente/destino identificando un flujo de paquetes para una conexión; y reemplazar el identif icador de flujo del paquete encapsulado con por lo menos una porción extraída del par de fuente/destino para producir un paquete desencapsulado para la conexión. 77. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, que comprenden las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo a realizar una acción adicional que comprende: recibir el paquete encapsulado de la infraestructura de equilibrio de carga. 78. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, que comprenden las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo a realizar una acción adicional que comprende: indicar el paquete desencapsulado a una pila de protocolo. 79. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 78, en donde la acción de indicar comprende una acción de: indicar el paquete desencapsulado a través de un adaptador de red virtual que está unido a una dirección de destino del paquete desencapsulado. 80. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, que comprenden las instrucciones ejecutables por un procesador que, cuando se ejecutan, dirigen al dispositivo a realizar acciones adicionales que comprenden: recibir un mapa de encapsulación; y almacenar el mapa de encapsulación como la entrada de mapa de encapsulación en la tabla de mapa de encapsulación. 81. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde por lo menos una porción de las instrucciones ejecutables por procesador comprende por lo menos parte de un controlador intermedio emigrante que está colocado por abajo de una porción de pila de protocolo de una pila de red. 82. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde el par de fuente/destino de la entrada de mapa de encapsulación localizada comprende un par de información de dirección fuente/destino de la entrada de mapa de encapsulación localizada. 83. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde el flujo de paquetes para la conexión comprende una conexión que ha sido emigrada. 84. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde la acción de extraer comprende una acción de: extraer una dirección de protocolo internet (IP) fuente, una dirección de IP de destino, un puerto de protocolo de control de transmisión (TCP) fuente, y un puerto de TCP de destino de la entrada de mapa de encapsulación licalizada. 85. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde la acción de reemplazar comprende una acción de: reemplazar el identificador de flujo del paquete encapsulado con un puerto de protocolo de control de transmisión (TCP) fuente y un puerto de TCP de destino de la entrada de mapa de encapsulación localizada para producir el paquete desencapsulado para la conexión . 86. - Uno o más medios accesibles por procesador de acuerdo con la reivindicación 76, en donde la acción de reemplazar comprende una acción de: reemplazar una dirección de protocolo internet (IP) de origen y una dirección de IP de destino del paquete encapsulado con una dirección de IP fuente y una dirección de IP de destino, respectivamente, de la entrada de mapa de encapsulación localizada para producir el paquete desencapsulado para la conecxión.