MXPA05013575A

MXPA05013575A - Metodo y sistema para descargar actualizaciones.

Info

Publication number: MXPA05013575A
Application number: MXPA05013575A
Authority: MX
Inventors: Jason F Mackay
Original assignee: Microsoft Corp
Priority date: 2004-12-14
Filing date: 2005-12-13
Publication date: 2006-06-15
Also published as: AU2005239708B2; CA2529966C; RU2405260C2; BRPI0505512B1; JP2006172472A; EP1672490A2; CA2529966A1; CN1790266A; US20060130037A1; KR20060067842A; BRPI0505512A; RU2005138840A; EP1672490A3; CN1790266B; US7716660B2; KR101201147B1; AU2005239708A1; EP1672490B1; JP5349733B2

Abstract

Las modalidades de la presente invencion proporcionan la habilidad, a un proveedor de servicio, de distribuir actualizaciones de software a varios diferentes receptores que utilizan en ambiente de par a par. La invencion aqui descrita puede ser utilizada para actualizar cualquier tipo de software, incluyendo, pero no limitandose a software de operacion, software de programacion, software anti-virus, software de base de datos, etc. El uso de un ambiente de par a par con seguridad agregada proporciona la habilidad de reducir al minimo el tiempo de descarga para cada par y tambien reduce la cantidad de anchura de banda de egreso que debe ser provista por el proveedor de software para que los receptores (pares) puedan obtener la actualizacion.

Description

METODO Y SISTEMA PARA DESCARGAR ACTUALIZACIONES CAMPO DE LA INVENCION En general, la presente invención se refiere a actualizaciones de computadora y, en particular, a un sistema y método para obtener e instalar actualizaciones utilizando un ambiente de red de par a par.

ANTECEDENTES DE LA INVENCION Las computadoras, y en particular, el software de computadora, son frecuentemente actualizados por un usuario que descarga un parche de software desde un huésped, tal como el proveedor de software, a través de una red, tal como Internet. Actualmente, los parches son descargados en su totalidad desde una fuente individual e instalados en la máquina de descargar para actualizar el software a un estado actual. Mientras esta técnica es operacional tiene varias desventajas. Primero, el proveedor de software que pone el parche a disponibilidad para descargar debe proporcionar una cantidad suficiente de anchuras de banda de egresos para permitir a múltiples clientes descargar actualizaciones al mismo tiempo. Para los proveedores de software con un gran número de clientes, tal anchura de banda de egreso puede hacerse muy costosa. Segundo, un cliente debe descargar el parche completo desde una fuente antes de instalar el parche y actualizar el software. Mientras este puede ser aceptable para parches de pequeño tamaño, para un parche de mayor tamaño, el tiempo necesario para descargar el parche completo desde una fuente puede ser inaceptable. Tercero, si el software proporcionado no ha hecho amplia la banda de egreso disponible para la descarga (particularmente difícil y costosa cuando un parche de prioridad superior, tal como una actualización de seguridad, es liberado), un cliente puede ser temporalmente prohibido de descargar el parche. Los avances recientes en redes de par a par han proporcionado la habilidad de descargar diferentes partes de un gran archivo desde una pluralidad de pares. Por ejemplo, la Figura 1 ilustra un diagrama de bloque de un ambiente de par a par típico para descargar un archivo específico. Para descargar un archivo específico, un cliente 101 solicita el archivo específico desde un huésped ?03. En respuesta, el huésped transmite una lista de par que identifica una pluralidad de pares que hace disponible descargar diferentes piezas de estos archivos solicitados. Por ejemplo, un archivo de vídeo puede estar subdividido en una pluralidad de piezas, aquellas piezas divididas en sub-piezas, y aquellas piezas divididas en sub-sub-piezas. Cada par que ha descargado previamente el archivo de vídeo, ya sea desde una fuente o desde múltiples otros pares, puede hacer disponible para descarga por otros pares, tal como el cliente 101, una o más de estas sub-sub-piezas del archivo completo. La lista de par transmitida por el huésped 103 al cliente 101 identifica cada una de las sub-sub-piezas del archivo específico solicitado y un par asociado que hace disponible para descargar estas sub-sub-piezas. El cliente 101, con el recibo de la lista de pares del huésped 103, recoge un par para cada una de las sub-sub-piezas de las cuales descarga esa sub-sub-pieza. Con las identificaciones de pares, el cliente 101 descarga cada una de las sub-sub-piezas desde los pares seleccionados hasta que todas sub-sub-piezas del archivo específico han sido descargadas. Al descargar las piezas de diferentes pares, múltiples descargas pueden ser conducidas simultáneamente. Mientras se descarga cada sub-sub-pieza, el cliente 101 puede decidir si desea o no hacerse un par que hace disponible para descargar esa sub-sub-pieza (es decir, compartir esa sub-sub-pieza). Si el cliente decide que desea compartir esa sub-sub-pieza, el cliente 101 identifica al huésped 103 la sub-sub-pieza que está deseando compartir. Aunque los ambientes de par a par, tal como esos descritos con respecto a la Figura 1, proporcionan la habilidad a un cliente para descargar un archivo específico que solicita, tal como un archivo de vídeo, no existe actualmente una técnica para la determinación de que archivo puede necesitar un cliente. Por ejemplo, haciendo referencia de nuevo a descargar parches de software, antes de solicitar un parche, un cliente puede no saber solo que actualizaciones están disponibles, sino que actualizaciones necesita el cliente. Incluso, no existe actualmente característica de seguridad para prometer una computadora de descarga de ser comprometida al identificar que está compartiendo antes de ese material siendo completamente integrado en la computadora de descarga. Además, no existe método a través del cual múltiples parches en una memoria caché local del cliente pueden ser priorizados por el proveedor de software cuando el cliente necesita reclamar el espacio de memoria caché local. Por consiguiente, existe una necesidad de un sistema y método que permitan a un cliente identificar actualización en el software necesarias y descargar de forma segura aquellas actualizaciones utilizando un ambiente de par a par.

COMPENDIO DE LA INVENCION Las modalidades de la presente invención proporcionan la habilidad a un proveedor de software de distribuir actualizaciones de software a varios diferentes clientes que utilizan un ambiente de par a par. La invención aquí descrita puede ser utilizada para actualizar cualquier tipo de software, incluyendo, pero no limitándose a, software de operación, software de programación, software antivirus, software de base datos, etc. El uso de un ambiente de par a par con seguridad agregada proporciona la habilidad de reducir al tiempo mínimo de descarga para cada par y también reducir la cantidad de anchura de banda de egreso que debe ser proporcionada por el proveedor de software para permitir a sus clientes (pares) obtener la actualización. De acuerdo con un primer aspecto de la presente invención, se proporciona un método para actualizar el primer dispositivo de cómputo. El método recibe una lista de actualizaciones disponibles, y determina si cualquiera de las actualizaciones en la lista es necesaria. Si cualquiera de las actualizaciones es necesaria, se recibe una lista de dispositivo de cómputo que identifica piezas de la actualización y dispositivos de cómputo de los cuales se pueden obtener aquellas piezas. Aquellas piezas después son descargadas desde los dispositivos de cómputo, en donde al menos dos de la pluralidad de piezas son descargadas de diferentes dispositivos de cómputo. Una vez que las piezas han sido descargadas, el software del primer dispositivo de cómputo es actualizado utilizando las piezas descargadas. De acuerdo con otro aspecto de la presente invención, se proporciona un método para proporcionar una lista de par a un cliente para descargar actualizaciones de software. El método transmite una lista que identifica una actualización disponible y recibe una solicitud de lista de par para la actualización disponible. En respuesta, se genera una lista par que identifica una pluralidad de pares, en donde cada par identificado se hace disponible para descargar al menos una porción de la actualización disponible. Esa lista par después es transmitida. De acuerdo con otro aspecto de la presente invención, un sistema de computadora que tiene un medio legible por computadora incluyendo un programa ejecutable por computadora en él para realizar el método de obtener una actualización es proporcionado. El sistema de computadora recibe una lista de actualizaciones disponibles e identifica una actualización necesaria de la lista de actualizaciones disponibles. Después una lista de par es solicitada y recibida para actualización necesaria. La lista par recibida identifica una pluralidad de piezas de la actualización necesaria, e identifica para cada pieza, uno o más dispositivos de cómputo que hacen esa pieza disponible para descarga. El sistema de computadora después descarga cada una de las piezas desde los dispositivos de cómputo identificados.

BREVE DESCRIPCION DE LOS DIBUJOS Los aspectos anteriores y muchas de las ventajas pendientes de esta invención se harán más evidentemente apreciadas mientras lo mismo se entiende mejor por referencia a la siguiente descripción detalla, cuando se toma en conjunto con los dibujos acompañantes, en donde: La Figura 1 ilustra un diagrama de bloque de un ambiente de par a par típico para descargar un archivo específico; Las Figuras 2A-2C ilustran un diagrama de estado para descargar una actualización de software que utiliza un ambiente de par a par, de acuerdo con una modalidad de la presente invención; La Figura 3 es un diagrama de bloque de una lista de opciones de actualización que identifican diferentes opciones para actualizaciones necesarias que pueden ser generadas por un huésped, de acuerdo con una modalidad de la presente invención; La Figura 4 ilustra un diagrama de bloque de una lista de par que identifica pares para una actualización necesaria en respuesta a una solicitud para una lista par de un cliente, de acuerdo con una modalidad de la presente invención; La Figura 5 es un diagrama de flujo ilustrativo de una rutina de actualización de software de cliente para actualizar software de un cliente, de acuerdo con una modalidad de la presente invención; La Figura 6 ilustra un diagrama de flujo de una subrutina de descarga que puede ser ejecutada como parte de una rutina de actualización de software de cliente para descargar piezas de una actualización necesaria desde diferentes pares, de acuerdo con una modalidad de la presente invención; La Figura 7 ¡lustra un diagrama de flujo de una subrutina de prioridad para expandir tamaño de memoria caché en un sistema de cliente para permitir una descarga de un parche, de acuerdo con una modalidad de la presente invención; y La Figura 8 ilustra una rutina de huésped para hacer disponibles actualizaciones que utilizan un ambiente de par a par, de acuerdo con una modalidad de la presente invención.

DESCRIPCION DETALLADA DE LA MODALIDAD PREFERIDA Las modalidades de la presente invención proporcionan la habilidad a un proveedor de software denominado aquí como un huésped, para distribuir piezas de actualizaciones de software a varios diferentes receptores (denominados aquí como pares). Un par, como se denomina aquí, incluye cualquier tipo de dispositivo de cómputo que hace disponible para descargar una porción (pieza) de una actualización de software. Por ejemplo, un par puede ser, pero no está limitado a, un dispositivo de cómputo individual, un servidor, un dispositivo de cómputo huésped, un dispositivo de cómputo de cliente, etc. Los pares con piezas de una actualización de software hacen cada pieza disponibles a otros pares para descargarse. Mientras los pares adicionales obtienen las mismas piezas de software, hacen demasiadas piezas disponibles para descargar por otros pares. De esa forma, mientras el número de pares que contienen una pieza crece, el número de sitios de descarga disponibles para pieza aumenta. Las Figuras 2A-2C ilustran un diagrama de estado para descargar una actualización de software que utiliza un ambiente de par a par, de acuerdo con una modalidad de la presente invención. El ambiente de par a par 200 proporciona la habilidad a un cliente 201 de identificar actualizaciones necesarias y obtener una lista de pares desde un huésped 203 desde el cual puede obtener porciones de esas actualizaciones.

Haciendo referencia primero a la Figura 2A, en un estado inicial, el cliente 201 solicita desde un huésped una lista de actualizaciones que están disponibles desde el huésped 203. En una modalidad alternativa, el huésped 203 puede, en tiempos periódicos, publicar una lista de actualización disponible que es obtenida por un cliente 201. El huésped 203, con la recepción de una solicitud de una lista de actualizaciones disponibles, envía lista de actualizaciones disponibles al cliente 201. El cliente 201 se revisa asimismo para determinar su estado actual y compara ese estado con la lista de actualizaciones disponibles para determinar que actualizaciones son necesarias. Con una determinación de actualizaciones necesarias, el cliente 201 solicita una lista de opciones de actualización para las actualizaciones necesarias desde el huésped 203. El huésped 203 con el recibo de una solicitud de opciones de actualización para actualizaciones necesarias construye una lista de opciones de actualización. Para asuntos de privacidad de un cliente, en una modalidad de la presente invención, una cantidad mínima de información de cliente es pasada del cliente al huésped. Por ejemplo, justo como se discutió, el huésped proporciona una lista de actualizaciones disponibles y el cliente decide cuales son necesarias. En una modalidad alternativa, un cliente podría proporcionar un huésped con una identificación de su estado actual, o información que corresponde a varios estados de información, y el huésped podría informar al cliente de actualizaciones necesarias. 1 o Haciendo referencia a la Figura 3, una lista de opciones de actualización que identifica diferentes operaciones para actualizaciones necesarias que puede ser generada por un huésped, de acuerdo con una modalidad de la presente invención, es descrita. La lista de opciones de actualización 300 identifica, para actualización solicitada por el cliente 201, tal como ACTUALIZACION 1 301, las diferentes opciones disponibles para obtener esa actualización. Adicionalmente, la lista de opciones de actualización 300 puede incluir opciones de actualización para diferentes actualizaciones solicitadas. Por ejemplo, asumiendo que el cliente 201 solicitó opciones de actualización para ACTUALIZACION1 301 y ACTUALIZACION? 303, la lista de opciones de actualización 300 podría incluir una identificación para cada una de las actualizaciones solicitadas 301, 303 y una identificación de las opciones diferentes disponibles para obtener esa actualización. Por ejemplo, la ACTUALIZACION 1 301 puede incluir una identificación de un Parche Completo 1 305, un Parche Delta 1.1 307, un Parche Delta 1.2 309, y un Parche Delta 1.3 311. De forma similar, la ACTUALIZACIÓN? 303 puede incluir una identificación de un Parche Completo 7 313, un Parche Delta 7.1 7.1 315, un Parche Delta 7.2 317, un Parche Delta 7.3 319. El Parche Completol 305, es una actualización completa que puede ser instalada para traer el software desde un estado existente a un estado actual. Cada parche delta puede ser utilizado para traer el software desde un estado existente conocido hasta un estado actual sin tener que utilizar el parche completo. El software que va a ser actualizado frecuentemente está en uno de varios diferentes estados conocidos que pueden ser identificados. De esa forma, para cada uno de aquellos estados conocidos un parche delta puede ser utilizado para modificar ese software para traerlo a un estado actual. Por ejemplo, el parche De Ita 1.1 307 puede ser utilizado para traer una versión de software de un estado existente conocido a un estado actual. Con el fin de permitir al cliente 201 determinar si puede utilizar uno de los parches delta para actualizar el software, cada parche delta incluye una lista de archivos y un valor de mezcla esperado para esos archivos. El valor de mezcla esperado puede ser utilizado para determinar si el parche delta es apropiado para el software existente. Por ejemplo, el parche Delta1.1 307 incluye un Archivo 1.1 320 con un valor de mezcla esperado 321, un Archivo1.1 322 con un valor de mezcla esperado 323, y un Archivo 1.3 324 con un valor de mezcla esperado 325. Un cliente, al recibir la lista de opciones de actualización 300, puede mezclar el estado actual de los archivos que van a ser actualizados en el sistema del cliente 201 y determinar si los valores de mezcla concuerdan con los valores de mezcla esperados contenidos en la lista de actualización. Si los valores de mezcla concuerdan, entonces el parche delta correspondiente puede ser utilizado para actualizar el sistema del cliente. Al utilizar un parche delta, tal como Delta1.1 307, en vez de utilizar un parche completo, tal como Parche Completol 305, resulta en una descarga más pequeña debido a que es una actualización parcial en vez de una actualización completa. Haciendo referencia ahora a la Figura 2B, una vez que el huésped 203 ha generado la lista de opciones de actualización solicitada, la lista de opciones de actualización es transmitida al cliente 201. El cliente 201, selecciona de la lista de opciones de actualización el parche para cada actualización que traerá el estado del cliente 201 a un estado actual. Como se discutió anteriormente, el cliente puede seleccionar un parche completo o un parche delta apropiado para las actualizaciones que son necesarias. Como se apreciará por un experto en la técnica, una o más actualizaciones necesarias pueden ser seleccionadas de la lista de opciones de actualización. Con la selección de cada uno de los parches apropiados, el cliente 201 solicita una lista par para las actualizaciones necesarias. El huésped 203, en respuesta a recibir una solicitud para una lista par para actualizaciones necesarias, construye la lista de par solicitada y transmite esa lista par al cliente 20 . El huésped mantiene una lista par maestra que identifica cada par que hace porciones de actualización disponibles para descarga. Si una actualización nunca ha sido descargada desde el huésped, una lista par inicial puede solo identificar el huésped como siendo un par disponible. En tal situación, el cliente sería el primero en descargar la actualización y seleccionaría el huésped como parche y descargaría el archivo completo desde el huésped. Como se discute más adelante, una vez que el cliente ha descargado e instalado la actualización, identifica al huésped que está siendo disponible para descargar (compartir) una o más de las porciones de la actualización. De esa forma, el huésped agregaría ese a la lista par maestra para las porciones de la actualización que el cliente compartirá. Mientras los clientes adicionales descargan la actualización desde el huésped, el par, o ambos, y los identifica como ahora haciendo porciones de la actualización disponible para descarga, el número disponible de pares crece. La Figura 4 ¡lustra un diagrama de bloque de una lista par que identifica pares para una actualización necesaria en respuesta a una solicitud por una lista par desde un cliente, de acuerdo con una modalidad de la presente invención. Continuando con el ejemplo anterior, asumiendo que un cliente 201 solicitó el parche Delta1.1 401, y Parche Completo7 403, la lista par 400 incluirá detalles de cada uno de esos parches e identificación de pares para aquellos parches. Los valores de mezcla también son incluidos para verificar la autenticidad de parches descargados. Por ejemplo, el parche Delta1.1 401 incluye una mezcla delta y un valor de prioridad para ese parche. Como se discutirá en detalle más adelante, el valor de mezcla para el parche puede ser utilizado para confirmar la validez de la mezcla antes de la instalación. Adicionalmente, para cada archivo de un parche, tal como Archivo1.1 405 y Archivo1.2 407, se incluye una mezcla delta. Similar a la mezcla delta del parche, la mezcla delta para el archivo puede ser utilizada para verificar la autenticidad del archivo. El valor de prioridad del parche puede ser utilizado para determinar si las piezas de un parche van a ser mantenidas en una memoria caché de la computadora de cliente o eliminadas. En una modalidad alternativa, el valor de prioridad puede no estar incluido en el parche. En tal modalidad, las piezas son guardadas a la memoria caché y mientras el espacio de almacenamiento adicional se hace necesario, la computadora de cliente puede solicitar una lista de prioridad para las piezas que actualmente están localizadas en la memoria caché (ver Figura 7). Esto proporciona la habilidad al huésped de controlar dinámicamente las prioridades de piezas con el tiempo. Adicionalmente, cada archivo, tal como Archivo1.1 405, puede estar dividido en piezas, tal como Piezal 409 y Pieza2 411. Cada pieza de un archivo además puede estar dividida en sub-piezas, y esas sub-piezas divididas en sub-sub-piezas. Por ejemplo, la Piezal 409 puede estar dividida en sub-piezas, tal como Subpieza1.1 413 y Subpieza1.2 415. De forma similar, esas sub-piezas además pueden estar divididas en sub-sub-piezas, tal como Subsubpiezal .1.1 417 y Subsubpiezal .1.2 419. Como se apreciará por un experto en la técnica, la división en piezas, sub-piezas, y sub-sub-piezas, puede ser tomada en cualquier nivel de división, y la granularidad de sub-sub-pieza como se describe aquí, es solo para propósitos de explicación. El nivel más pequeño de división, tal como sub-sub-pieza, incluye una identificación de uno o más pares que hacen la pieza disponible para descarga. Por ejemplo, la Subsubpiezal 417 incluye una identificación de dos pares que hacen esa pieza disponible para descarga. En particular, la Subsubpieza 1.1.1 417 puede ser descarga desde el Parí 421 o Par4 425. Cada par que hace una sub-sub-pieza disponible para descarga es identificado por una dirección, tal como una dirección de protocolo de Internet. La lista de par 400 puede incluir una identificación de todos los pares que hacen una sub-sub-pieza disponible para descarga, una porción de los pares que hace sub-sub-pieza disponible para descarga, o un par para cada sub-sub-pieza. Adicionalmente, para cada par enlistado en la lista de par, se puede proporcionar información adicional. Por ejemplo, la información adicional sobre un par puede incluir, pero no está limitada, la banda de egreso del par, la clasificación del par (que tan confiable es el par), las afiliaciones de pares de compañías u organizaciones, la historia de uso de pares del sistema de descarga de par a par, etc. La lista de par también puede incluir un grupo de comandos de actualización 427, que proporciona instrucciones como cómo instalar el mismo parche delta. Haciendo referencia de nuevo a la Figura 2B, el cliente 201, con el recibo de una lista de par, selecciona pares de las sub-sub-piezas identificadas en la lista de par. La selección de par y piezas será descrita en mayor detalle más adelante con respecto a la Figura 6. Con la selección de sub-sub-piezas y pares de los cuales aquellas piezas van a ser descargadas, el cliente 201 abre varios canales de comunicaciones con los diferentes pares y comienza a descargar las diferentes piezas de las actualizaciones simultáneamente. La técnica de descargar diferentes piezas de una actualización de diferentes pares aumenta la velocidad con la cual una actualización puede ser obtenida y con ello disminuye el tiempo de descarga total. Adicionalmente, al proporcionar actualizaciones a través de un ambiente de par a par, se reduce la anchura de la banda de egreso necesaria por el huésped 203. Utilizando las modalidades de la presente invención, mientras el cliente contacta al huésped, descarga una actualización, y comienza a compartir piezas de aquellas actualizaciones con otros clientes (es decir, otros pares), la anchura de banda de egresos fuera del huésped 203 reduce mientras los clientes están obteniendo piezas de la actualización desde otros pares en vez del huésped. La técnica controla púas extremas a demanda de contenido específico mucho más efectivas que servicios de archivo tradicional que puede ser más costoso y con peor falla completamente bajo la carga. Haciendo referencia ahora a la Figura 2C, mientras se completa la descarga de cada sub-sub-pieza, esa sub-sub-pieza es mezclada y comparada con el valor de mezcla incluido en la lista de par para confirmar que la sub-sub-pieza no ha sido alterada. Una vez que todas las sub-sub-piezas para un parche particular han sido descargas y autentificadas, aquellas piezas son ensambladas para recrear el parche. Adicionalmente, una copia de una o más de las sub-sub-piezas descargadas es mantenida en una memoria caché. Aquellas copias pueden ser hechas disponibles para descargarse por otros pares. El parche ensamblado es instalado para actualizar el cliente a un estado actual. Con el término de la instalación, el sistema de computadora de cliente puede ser reiniciado si es necesario. Una vez que la instalación de los parches y o inicio de la computadora de cliente 201 (si es necesario) han sido completados, el cliente 201 transmite al huésped 203 una identificación de la sub-sub-pieza que están almacenadas en la memoria caché. Tal identificación puede ser un valor de mezcla de cada sub-sub-pieza almacenada. El huésped 203, con la recepción de una identificación de sub-sub-pieza guarda en memoria caché, actualiza la lista par maestra agregando al cliente como un par que hace aquellas piezas disponibles para descarga. La lista de par maestra incluye una lista de cada par que mantiene una pieza de un parche está hecha disponible para descarga por otros clientes. La Figura 5 es un diagrama de flujo que ilustra una rutina de actualización de software de cliente para actualizar software de un cliente, de acuerdo con una modalidad de la presente invención. La rutina de actualización de software de cliente 500 comienza en el bloque 501 y en el bloque 503 la solicitud del cliente y obtiene una lista de actualización. Como se discutió anteriormente, la lista de actualización incluye una identificación de actualizaciones que son disponibles para descarga. Utilizando esa lista, en el bloque 505, el cliente compara el estado de su sistema existente con las actualizaciones disponibles. Basándose en esa comparación en el bloque de decisión 507, se hace una determinación de que actualizaciones son necesarias para traer al sistema existente al cliente a un estado actual. Si se determina en el bloque de decisión 507 que las actualización son necesarias, en el bloque de decisión 509, se hace una determinación de si un parche delta para la actualización necesaria está disponible. Como se discutió anteriormente, una determinación de si un parche delta está disponible para una actualización necesaria puede ser averiguado al solicitar opciones de actualización para una actualización necesaria y recibir una lista de diferentes opciones de actualización. La lista de diferentes opciones de actualización incluye una identificación de parches delta y valores de mezcla esperados para archivos que serán actualizados por el parche delta. Al comparar los valores de mezcla esperados del parche delta con los valores de mezcla de los archivos en el cliente, se puede hacer una determinación por el cliente de si un parche delta .está disponible. En una modalidad alternativa, la lista de actualizaciones disponibles también puede incluir opciones de actualización para cada actualización disponible, con ello removiendo la necesidad de obtener subsecuentemente opciones de actualización. Al permitir a un cliente determinar si un parche delta está disponible, como opuesto al cliente que proporciona valores de mezcla de su sistema existente a un huésped, permite al cliente mantener la privacidad con respecto a sí mismo. Si se determina en el bloque de decisión 509 que un parche delta está disponible, el parche delta es agregado a una lista de descarga, como se ilustró por el bloque 511. Sin embargo, si se determina en el bloque 509 que un parche delta no está disponible, en el bloque 513 una identificación de un parche completo para la actualización es agregada a la lista de descarga. En el bloque de decisión 515, se hace una determinación de si las actualizaciones adicionales son necesarias para traer al cliente a un estado actual. Si se determina en el bloque de decisión 515 que las actualizaciones adicionales son necesarias, la rutina de actualización de software de cliente 500 regresa al bloque de decisión 509 y la rutina continúa. Sin embargo, si se determina en el bloque de decisión 515 que las actualizaciones adicionales no son necesarias, en el bloque 517 el cliente solicita una lista par para los parches identificados en la lista de descarga. En respuesta a la solicitud de una lista de par en el bloque 517, en el bloque 519, el cliente recibe una lista de par que incluye una identificación de pares que hace disponible para descargar cada sub-sub-pieza de cada parche identificado en la lista de descarga. Con la recepción de una lista de par, la subrutina de descarga, ilustrada por el bloque 521, es realizada. La subrutina de descarga será descrita en más detalle con respecto a la Figura 6. Con el término de la subrutina de descarga, en el bloque 523, las sub-su b-piezas descargadas son ensambladas para recrear los parches solicitados y aquellos parches son instalados en el sistema de cliente para traer al sistema de cliente a un estado actual. Una vez que la instalación de parches descargados ha sido completada y el sistema de cliente es reinlciado, si es necesario, la rutina de actualización de software de cliente 500 transmite una mezcla de su b-su b-piezas guardadas en memoria caché, como se ¡lustró por el bloque 525. Las sub-sub-piezas guardadas en memoria caché son aquellas piezas que están almacenadas en una memoria caché de un cliente que el cliente hará disponibles para descargar por otros pares. En una modalidad de la presente invención, un cliente es requerido para compartir piezas que ha descargado desde otros pares para asegurar que se mantenga el ambiente de par a par.

Por ejemplo, si un cliente descarga 50 MB de actualizaciones a través de un ambiente de par a par, el cliente puede ser requerido para hacer disponibles para descarga la misma cantidad de datos que por sí mismo ha descargado. En un ambiente real de la presente invención, la mezcla de sub-sub-pieza guardadas en memoria caché no puede ser transmitida, con ello identificando que la participación está disponible, hasta que cada una de las piezas haya sido verificada e instalada. Verificar e instalar parches antes de compartir esos parches puede ser necesario debido a que cuando una lista par es proporcionada a otros pares desde un huésped, la dirección de un par podría ser utilizada con el conocimiento de una falta de par de un parche particular, tal ' como uno siendo descargado, para comprometer la máquina de par. Una vez que la mezcla de sub-sub-piezas guardadas en memoria caché ha sido transmitida al bloque 525, o si es transmitida en el bloque de decisión 507 que ninguna de las actualizaciones son necesarias, la rutina de actualización de software de cliente 500 se completa en el bloque 527. La rutina de actualización de software de cliente 500 puede ser manualmente iniciada, o en la alternativa, programada para correr en una base periódica para asegurar que el cliente es mantenido en un estado actual. Por ejemplo, la rutina de actualización de software de cliente 500 puede ser programada para correr en la tarde o cuando el dispositivo de cómputo de cliente no está siendo utilizado. Adicionalmente, mientras se agrega una característica de seguridad, la lista de actualización disponible, la lista de opciones de actualización, y la lista de par cada uno puede ser digitalmente marcada por el huésped para que no puedan ser alteradas. Los documentos marcados digitalmente son conocidos en la técnica y de esa forma no serán descritos aquí en mayor detalle. La Figura 6 ilustra un diagrama de flujo de una subrutina de descarga que puede ser ejecutada como parte de una rutina de actualización de software de cliente para descargar piezas de un parche desde diferentes pares, de acuerdo con una modalidad de la presente invención. Aunque la subrutina de descarga 600 es descrita con respecto a descargar un parche, se apreciará que cualquier número de parches pueden ser descargados ya sea simultáneamente o en diferentes momentos utilizando la subrutina de descarga 600. La subrutina de descarga 600 comienza en el bloque 601 y en el bloque 603 una lista de par para cada una de las sub-sub-piezas de uno o más parches es recibida. Como se discutió anteriormente, ia lista de par identifica las direcciones de pares que hacen disponibles para descargar diferentes sub-sub-piezas de un parche. Durante la descarga de sub-sub-piezas, la lista de par puede ser periódicamente actualizada (por ejemplo, cada dos minutos) para asegurar que el cliente está solicitando descargas para pares disponibles. Al utilizar esta lista de par, en el bloque de decisión 605, se hace una determinación de si la memoria caché adicional será necesaria para almacenar la sub-sub-piezas del parche antes de la instalación. Se determina en el bloque de decisión 605 que la memoria caché adicional será necesaria, una subrutina de prioridad es ejecutada, como se ilustró por el bloque 607. La subrutina de prioridad para obtener memoria caché adicional será descrita en mayor detalle con respecto a la Figura 7. Sin embargo, si se determina en el bloque de decisión 605 que la memoria caché adicional no es necesaria, en el bloque 609 un archivo de parche que está siendo descargado es seleccionado. En el bloque 611, una pieza del archivo seleccionado es elegida para qué descarga va a comenzar. Al utilizar esta pieza seleccionada, en el bloque de decisión 613 se hace una determinación de si una de las sub-piezas de esa pieza ha terminado de descargarse. Si se determina que una de las sub-piezas de esa pieza no ha terminado de descargar, en el bloque de decisión 615 se hace una determinación si una de las sub-sub-piezas de la sub-pieza ha sido descargada. Si se determina en el bloque de decisión 615 que una de las sub-sub-piezas de una sub-pieza no ha sido descargada, en el bloque 617, una sub-sub-pieza de sub-pieza es aleatoriamente seleccionada. En el bloque 619, un par que hace disponible para descarga la sub-sub-pieza aleatoriamente seleccionada también es aleatoriamente seleccionado. Con la selección de una sub-sub-pieza y un par, en el bloque 621, la descarga de la sub-sub-pieza del par seleccionado comienza. Una vez que ha comenzado la descarga de sub-sub-pieza, la subrutina de descarga 600 regresa al bloque 613 y continúa. Haciendo referencia de nuevo al bloque de decisión 615, si se determina que una de las sub-sub-piezas ha completado su descarga, en el bloque 623 una sub-subpieza de una sub-pieza que tiene al menos cantidad de pares para las cuales la sub-pieza está disponible para descarga es seleccionada. Adicionalmente, en el bloque 625, uno de los pares para la sub-sub-pieza seleccionada es aleatoriamente elegido. En el bloque 627, la descarga de la sub-sub-pieza seleccionada del par elegido aleatoriamente es iniciada. Una vez que la descarga de la sub-sub-pieza seleccionada ha comenzado, en el bloque 627, la subrutina de descarga 600 regresa al bloque 613 y continúa. Debido a que múltiples sub-sub-piezas pueden ser descargas al mismo tiempo, con ello disminuyendo el tiempo total necesario para descargar un parche, o múltiples parches, una vez que la descarga ha comenzado en el bloque 621 o bloque 627, la subrutina de descarga 600 continúa al elegir otra pieza y otro par e iniciar esa descarga. De esa forma, una facturación total de banda de egreso para un cliente que está descargando una actualización puede ser realizada y la descarga de una actualización puede ser completada rápidamente. Adicionalmente, mientras la descarga de cada sub-sub-pieza se completa, la autenticidad de esas piezas puede ser verificada al mezclar la sub-sub-pieza y comparar el valor de mezcla con el valor de mezcla incluido en la lista de par. Haciendo referencia ahora al bloque de decisión 613, si se determina que una sub-pieza de una pieza ha terminado de descargarse, en el bloque de decisión 629 se hace una determinación de si todas las piezas de un archivo han determinado de descargarse. Si se determina en el bloque de decisión 629 que todas las piezas de un archivo no han terminado de descargarse, la subrutina de descarga 600 regresa al bloque 611 y recoge otra pieza y el procedimiento continúa. Sin embargo, si se determina en el bloque de decisión 629 que todas las piezas de un archivo han terminado de descargarse, en el bloque de ' decisión 631, una determinación se hace de si todos los archivos para el parche han terminado de descargarse. Si se determina en el bloque de decisión 631 que todos los archivos para el parche no han terminado de descargarse, la subrutina de descarga 600 regresa al bloque 609 y otro archivo que va a ser descargado es seleccionado. Sin embargo, si se determina en el bloque de decisión 631 que todos loa archivos del parche han sido descargados y de esa forma, todas las piezas, sub-piezas y sub-sub-piezas del parche también han sido descargadas la rutina se completa en el bloque 633 y regresa el control a la rutina de actualización de software de cliente 500 (Figura 5). La Figura 7 ilustra un diagrama de flujo de una subrutina de prioridad para expandir el tamaño de memoria caché en un sistema de cliente para habilitar una descarga de un parche, de acuerdo con una modalidad de la presente invención. Una subrutina de prioridad 700 comienza en el bloque 701 y en bloque 703 una lista de todas las sub-sub-piezas guardadas en memoria caché actualmente que son compartidas es transmitida a un huésped. En respuesta a la transmisión de una lista de sub-sub-piezas guardadas en memoria caché que son compartidas, en el bloque 705, las prioridades para cada una de esas sub-sub-piezas es recibida. Las sub-sub-piezas pueden ser asignadas con prioridades basadas en la frecuencia con la que están siendo solicitadas para descarga. Por ejemplo, si se ha publicado una nueva actualización para proporcionar una defensa contra un nuevo virus de computadora, los parches, y de esa forma, las sub-sub-piezas, para esa actualización pueden ser descargados en una frecuencia muy alta. De esa forma, las sub-sub-piezas de esa actualización pueden recibir una prioridad superior. Al recibir las prioridades para sub-sub-piezas guardadas en memoria caché, en el bloque 707, una sub-sub-pieza guardada en memoria caché con una prioridad inferior es eliminada de la memoria caché. En el bloque de decisión 709, se hace una determinación de si está disponible el espacio suficiente en la memoria caché para la actualización una vez que sea eliminado una sub-sub-pieza compartida. Si se determina en el bloque de decisión 709 que está disponible el espacio suficiente, la rutina regresa el control a la subrutina de descarga 600 (Figura 6), Como se ilustro por el bloque 723. Sin embargo, si se determina en el bloque de decisión 709 que no está disponible aún el espacio suficiente, en el bloque de decisión 711, se hace una determinación de si existen otras sub-sub-piezas guardas en memoria caché compartidas que aún no han sido eliminadas. Si se determina en el bloque decisión 711 que aún existen sub-sub-piezas guardas en memoria caché restantes que están compartidas, la subrutina de prioridad 700 regresa al bloque 707 y elimina la siguiente prioridad inferior y el procedimiento continúa. En una modalidad real de la presente invención, algunas sub-sub-piezas guardadas en memoria caché asociadas con partes para actualizaciones particulares pueden ser identificadas mientras no sean eliminables. Por ejemplo, si la sub-sub-pieza está asociada con una actualización que es descargada frecuentemente en extremo, puede ser identificada mientras no es eliminable para asegurar que existen suficientes pares de los cuales la sub-sub-pieza puede ser descargada. Si se determina en el bloque de decisión 711 que no existen sub-sub-piezas guardadas en memoria caché restantes que pueden ser eliminadas, en el bloque de decisión 713 se hace una determinación de si cualquier parche ha sido completamente descargado. Como se discutió anteriormente, múltiples parches pueden ser descargados simultáneamente, de acuerdo con una modalidad de la presente invención. Si uno de esos parches ha sido completamente descargo, en el bloque de decisión 713, se identifica y en el bloque 717 el parche es instalado. La instalación puede resultar en el resto de las descargas siendo pausadas mientras esa actualización está siendo instalada. Sin embargo, la tecnología existente permite las descargas pausadas ser resumidas sin tener que reiniciarse. De esa forma, no existe pérdida sustancial de datos de descargados que resultan de una pausa/reinicio de una descarga. Una vez que el parche descargado ha sido instalado, en el bloque 717, la sub-sub-piezas de ese parche son eliminadas de la memoria caché, como se ilustró por el bloque 719, a menos que estén identificados como no eliminables. Con la eliminación de las descargas, en el bloque de decisión 721, se hace una determinación de si existe espacio suficiente en la memoria caché para descargar la actualización. Si se determina en el bloque de decisión 721 que no existe espacio suficiente en la memoria caché, la subrutina de prioridad 700 regresa al bloque de decisión 713 y determina si existen otros parches que tienen descargas completas y el procedimiento continúa. Regresando de nuevo al bloque de decisión 713, si se determina que no existen parches que tengan descarga completa, en el bloque 715 el tamaño de memoria caché es expandido. Un tamaño de memoria caché puede ser expandido al solicitar a un usuario del sistema de cliente expandir el tamaño de memoria caché. Alternativamente, el tamaño de memoria caché puede ser automáticamente expandido. Una vez que es espacio suficiente en la memoria caché ha sido preparado para descargar actualizaciones, ya sea al eliminar piezas existentes de la memoria caché o expandir el tamaño de memoria caché, la subrutina de prioridad 700 se completa en el bloque 723, regresando el control a la subrutina de descarga 600. La Figura 8 ilustra una rutina de huésped para ser disponibles las actualizaciones al utilizar un ambiente de par a par, de acuerdo con una modalidad de la presente invención. La rutina de huésped 800 comienza en bloque 801 y en el bloque 803 el huésped recibe una solicitud para una lista de actualización. Como se discutió anteriormente, la lista de actualización es una lista de actualizaciones disponibles que es proporcionada por ese huésped para descarga. En el bloque 805, el huésped trasmite la lista de actualización que identifica descargas disponibles. Una vez que la lista de actualización ha sido transmitida, en algún punto posterior en el tiempo, una solicitud para actualizar opciones para una o más actualizaciones disponibles identificadas en la lista de actualización es recibida de un cliente, como se ilustró por el bloque 807. En el bloque 809, una lista de opciones de actualización es generada para las actualizaciones identificadas en la solicitud recibida en el bloque 807. Como se discutió anteriormente, la listade opciones de actualización incluye una identificación de parche que puede ser utilizado para obtener la actualización. Después esa lista es transmitida al cliente que solicitó las opciones de actualización. En el bloque 811, una solicitud de lista de par es recibida para solicitar una lista de par para uno o más de los parches identificados en la lista de opciones transmitida en el bloque 809. El huésped, en el bloque 813, genera y transmite una lista para los parches solicitados. Como se discutió anteriormente, la lista de par identifica, para cada parche, las piezas, sub-piezas, y sub-sub-piezas. Adicionalmente, para cada una de esas sub-sub-piezas uno o más pares y la dirección de esos pares están incluidos para identificar de donde se pueden obtener esas sub-sub-piezas. La lista de par después es transmitida al cliente, y en el bloque 815, una identificación de las sub-sub-piezas que han sido descargadas y almacenadas por ese cliente que ahora está disponible para compartir con otros pares es recibida. La lista recibida es utilizada para actualizar una lista de par maestra 817 que incluye una identificación de todas las sub-sub-piezas para actualizaciones disponibles y los pares que tienen esas sub-sub-piezas disponibles para descarga. La rutina de huésped 800 se completa en el bloque 819. Aunque las modalidades de la invención han sido ilustradas y descritas, se apreciará que varios cambios pueden ser hechos en ella sin apartase del espíritu y alcance de la invención.

Claims

REIVINDICACIONES 1. - Un método para actualizar un primer dispositivo de cómputo, el método comprende: recibir una lista de actualizaciones disponibles; determinar una actualización necesaria de lista de actualizaciones disponibles, en donde la actualización necesaria está segmentada en una pluralidad de piezas; recibir una lista de dispositivos de cómputo, en donde la lista de dispositivos de cómputo identifica, para cada pieza de la pluralidad de piezas, al menos un dispositivo de cómputo que hace la pieza disponible para descarga; descargar cada pieza de la pluralidad de piezas de la pluralidad de dispositivos de cómputo, en donde al menos dos de la pluralidad son descargadas de diferentes dispositivos de cómputo; y actualizar el software del primer dispositivo de cómputo utilizando las piezas descargadas. 2. - El método de acuerdo con la reivindicación 1, que además comprende: recibir una lista de opciones de actualización para la actualización necesaria, en donde cada opción de autorización es segmentada en una pluralidad de piezas; seleccionar una opción de actualización de la lista de opciones de actualización; y en donde recibir una lista de dispositivos de cómputo, incluye recibir una lista de dispositivos de cómputo que identifican, para cada pieza de la opción de actualización seleccionada, al menos un dispositivo de cómputo. 3. - El método de acuerdo con la reivindicación 2, en donde la lista de opciones de actualización incluye, para la actualización necesaria, un parche completo, y al menos y parche delta. 4. - El método de acuerdo con la reivindicación 3, en donde el parche delta incluye un nombre de archivo y un valor de mezclado esperado para un archivo. 5.- El método de acuerdo con la reivindicación 1, en donde determinar una actualización necesaria incluye escanear el primer dispositivo de cómputo para determinar su estado actual, y comparar el estado actual con la lista de actualizaciones disponibles. 6. - El método de acuerdo con la reivindicación 1, en donde la lista de dispositivos de cómputo incluye, para al menos uno de la pluralidad de piezas, una identificación de una pluralidad de dispositivos de cómputo. 7. - El método de acuerdo con la reivindicación 1, en donde los dispositivos de cómputo son identificados por una dirección de protocolo Internet. 8. - El método de acuerdo con la reivindicación 1, en donde actualizar el software incluye: ensamblar las piezas descargadas en un parche; e instalar el parche. 9.- El método de acuerdo con la reivindicación 1, en donde cada pieza descargada es confirmada basándose en una mezcla de la pieza . 10. - El método de acuerdo con la reivindicación 1, que además comprende: proporcionar una identificación de piezas descargadas; y compartir las piezas descargadas identificadas con otros dispositivos de cómputo. 11. - El método de acuerdo con la reivindicación 10, en donde la identificación de piezas descargadas incluye un valor de mezcla de cada pieza descargada. 12. - El método de acuerdo con la reivindicación 1, en donde con un punto predeterminado, las piezas descargadas identificadas no son compartidas. 13. - Un método para proporcionar una lista par a un cliente para descargar actualizaciones de software, el método comprende: transmitir una lista que identifica una actualización disponible; recibir una solicitud de lista par para la actualización disponible; generar una lista par que identifica una pluralidad de pares, en donde cada par identificado se hace disponible para descargar al menos una porción de la actualización disponible; y transmitir la lista par. 14. - El método de acuerdo con la reivindicación 13, en donde la lista que identifica una actualización disponible, identifica una pluralidad de actualizaciones disponibles. 15. - El método de acuerdo con la reivindicación 13, en donde la lista identifica, para la actualización disponible, una pluralidad de opciones de actualización. 16. - El método de acuerdo con. la reivindicación 15, en donde la pluralidad de opciones de actualización incluye un parche completo y al menos un parche delta. 17. -. El método de acuerdo con la reivindicación 13, que además comprende: en respuesta a transmitir una lista que identifica una actualización disponible, recibir una solicitud para opciones de actualización para la actualización disponible; generar una lista que identifica una pluralidad de opciones de actualización para la actualización disponible; y transmitir la lista que identifica una pluralidad de opciones de actualización. 18. - El método de acuerdo con la reivindicación 17, en donde recibir una solicitud de lista de par incluye, recibir una solicitud de lista de par para una de la pluralidad de opciones de actualización. 19. - El método de acuerdo con la reivindicación 13, que además comprende: recibir una identificación de una pieza guardada en memoria caché de la actualización disponible; y actualizar una lista de par maestra para la actualización disponible. 20.- El método de acuerdo con la reivindicación 13, en donde la actualización disponible está dividida en una pluralidad de piezas y en donde la lista de par identifica al menos un par para cada una de la pluralidad de piezas. 21. - El método de acuerdo con la reivindicación 20, en donde un de los pares Identificados es una computadora huésped. 22. - En un sistema de computadora que tiene un medio legible por computadora incluyendo un programa ejecutable por computadora en él para realizar el método para obtener una actualización, el método comprende: recibir una lista de actualizaciones disponibles; identificar una actualización necesaria de la lista de actualizaciones disponibles; solicitar una lista de par para la actualización necesaria; recibir una lista de par para la actualización necesaria, en donde la lista de par identifica una pluralidad de piezas de la actualización necesaria e identifica para cada pieza, un dispositivo de cómputo que hace la pieza disponible para descarga; y descargar cada una de las piezas de los dispositivos de cómputo identificados. 23.- El sistema de computadora de acuerdo con la reivindicación 22, en donde la lista de par identifica para cada una de la pluralidad de piezas, una pluralidad de sub-piezas e identifica para cada sub-pieza, un dispositivo de cómputo que hace esa sub-pleza disponible para descarga. 24.- El sistema de computadora acuerdo con la reivindicación 23, en donde la lista de par identifica para cada una de la pluralidad de subpiezas como una pluralidad de sub-sub-piezas, e identifica para sub-subpieza, un dispositivo de cómputo que hace sub-sub-pieza disponible para descarga. 25.- El sistema de computadora acuerdo con la reivindicación 22, en donde la lista de par identifica un valor de mezcla para cada pieza. 26. - El sistema de computadora acuerdo con la reivindicación 25, en donde descargar incluye: mezclar la pieza descargada para obtener un segundo valor de mezcla; y comparar el primer valor de mezcla y el segundo valor de mezcla para confirmar la validez de la pieza descargada. 27. - El sistema de computadora acuerdo con la reivindicación 22, que además comprende: ensamblar cada una de las piezas descargadas; y instalar la actualización. 28. - El sistema de computadora acuerdo con la reivindicación 27, en donde la lista de par incluye un primer valor de mezcla para la actualización; y en donde el método además incluye: mezclar las piezas ensambladas para obtener un segundo valor de mezcla; y comparar el primer valor de mezcla con el segundo valor de mezcla para confirmar la validez de la actualización. 29.- El sistema de computadora acuerdo con la reivindicación 22, que además comprende: almacenar al menos una de las piezas descargadas en una memoria caché; transmitir una identificación de la pieza guardada en memoria caché; y hacer la pieza guardada en memoria caché disponible para descarga. 30. - El sistema de computadora acuerdo con la reivindicación 22, en donde descargar cada una de las piezas desde los dispositivos de cómputo identificados incluye: confirmar la autenticidad de una pieza descargada. 31. El sistema de computadora acuerdo con la reivindicación 22, en donde descargar cada una de las piezas incluye: elegir aleatoriamente una pieza para descargar; y elegir aleatoriamente un dispositivo de cómputo del cual descargar la pieza. 32. - El sistema de computadora acuerdo con la reivindicación 22, en donde descargar cada una de las piezas incluye: identificar una pieza con un número menor de dispositivo de cómputo que hace a esa pieza disponible para descarga; y descargar la pieza con el número menor de dispositivos de cómputo que hace esa pieza disponible para descarga.