Mas clientes de Microsoft quieren Linux

Más clientes de Microsoft quieren Linux

El gigante de la informática pagará u$s100 millones al fabricante Novell en concepto de cuotas adicionales de suscripción. Es por la fuerte demanda del SUSE Linux, que se asocia con el software propietario Windows de Microsoft tras un acuerdo firmado en 2006

El pago se haría el 1 de noviembre, según ha anunciado la empresa, y se sumará a los u$s240 millones entregados a Novell por Microsoft en 2006 como parte de una larga serie de acuerdos sobre aspectos tecnológicos y empresariales para que los productos de ambas compañías funcionen juntos para clientes corporativos que utilicen servidores con ambos sistemas operativos.

Así, Microsoft, el mayor fabricante de software del mundo, compra certificados de Novell y después vende suscripciones a clientes de Windows que quieren ayuda al hacer que sus computadoras funcionen bien con máquinas con Linux.

Linux es la variante de software de código abierto más popular. A diferencia del propietario, el de código abierto permite a los desarrolladores compartir el código en el que basan los programas y añadir funciones, mientras que los usuarios sólo pagan por las aplicaciones a medida, el mantenimiento y el servicio técnico.

Novell ha indicado que también gastaría una suma no especificada de dinero para ofrecer nuevas herramientas, asistencia, formación y recursos a los suscriptores.

El trato despertó en su momento una gran polémica en la comunidad del código abierto porque, entre otras, cosas incluía una cláusula según la cual ninguna de las dos empresas demandaría a los clientes de la otra por violación de patentes.

Esta cláusula se consideró un respaldo a la afirmación de Microsoft de que posee patentes de propiedad intelectual sobre varios programas de código abierto, una argumentación rechazada por Novell y otros miembros de la comunidad del código abierto.

Además, los críticos creen que el acuerdo perjudica a la posición de patentes de Linux y le da a Microsoft un argumento para convencer a las empresas de que utilicen sus productos en vez de software libre.

En su momento, un grupo de software que posee los derechos de gran parte del código con el que funciona Linux amenazó con castigar a Novell por ese acuerdo, antes de optar finalmente por no tomar acciones contra la empresa.

Fuente: EFE

Modelo OSI

Introducción a la Comunicación en los Sistemas Distribuidos

En un sistema de un solo procesador la comunicación supone implícitamente la existencia de la memoria compartida:

• Ej.: problema de los productores y los consumidores, donde un proceso escribe en un buffer compartido y otro proceso lee de él.

En un sistema distribuido no existe la memoria compartida y por ello toda la naturaleza de la comunicación entre procesos debe replantearse.

Los procesos, para comunicarse, deben apegarse a reglas conocidas como protocolos.

Para los sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la forma de varias capas y cada capa tiene sus propias metas y reglas.

Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseño al respecto; una importante opción es la “llamada a un procedimiento remoto”.

También es importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre dos procesos.

Protocolos con Capas

Debido a la ausencia de memoria compartida, toda la comunicación en los sistemas distribuidos se basa en la transferencia de mensajes[25, Tanenbaum].

Cuando el proceso “A” quiere comunicarse con el proceso “B”:

• Construye un mensaje en su propio espacio de direcciones.
• Ejecuta una llamada al sistema para que el S. O. busque el mensaje y lo envíe a través de la red hacia “B”.
• Para evitar el caos, “A” y “B” deben coincidir en el significado de los bits que se envíen.

Los puntos de acuerdo necesarios incluyen lo siguiente:

• ¿Cuántos voltios hay que utilizar para un bit “0” y cuántos para un bit “1”?.
• ¿Cómo sabe el receptor cuál es el último bit del mensaje?.
• ¿Cómo puede detectar si un mensaje ha sido dañado o perdido, y qué debe hacer si lo descubre?.
• ¿Qué longitud tienen los números, cadenas y otros elementos de datos y cuál es la forma en que están representados?.

La ISO (Organización Internacional de Estándares) desarrolló un modelo de referencia que (ver Figura 8.1 [25, Tanenbaum]):

• Identifica en forma clara los distintos niveles.
• Estandariza los nombres de los niveles.
• Señala cuál nivel debe realizar cuál trabajo.

Este modelo se denomina “modelo de referencia para interconexión de sistemas abiertos” (ISO OSI o modelo OSI) [26, Tanenbaum].

El “modelo OSI” está diseñado para permitir la comunicación de los sistemas abiertos:

• Son aquellos preparados para comunicarse con cualquier otro sistema abierto mediante reglas estándar:
• Establecen el formato, contenido y significado de los mensajes recibidos y enviados.
• Constituyen los protocolos, que son acuerdos en la forma en que debe desarrollarse la comunicación (ver Figura 8.2 [25, Tanenbaum]).

El “modelo OSI” distingue entre dos tipos generales de protocolos:

• Orientados hacia las conexiones:
• Antes de intercambiar los datos, el emisor y el receptor:
• Establecen en forma explícita una conexión.
• Probablemente negocien el protocolo a utilizar.
• Al finalizar, deben terminar la conexión.
• El teléfono es un sistema de comunicación orientado hacia la conexión.
• Sin conexión:
• No es necesaria una configuración de antemano.
• El emisor transmite el primer mensaje cuando está listo.
• El depósito de una carta en un buzón es una comunicación sin conexión.

Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste de un conjunto de operaciones para definir el servicio que la capa está preparada para ofrecer a sus usuarios.

El protocolo de la capa “n” utiliza la información de la capa “n”.

Cada protocolo de capa se puede cambiar independientemente de los demás:

• Esto es de fundamental importancia.
• Confiere gran flexibilidad.

La colección de protocolos utilizados en un sistema particular se llama una “suite de protocolo” o “pila de protocolo”.

Transmission Control Protocol (TCP)

TCP (Transmission-Control-Protocol, en español Protocolo de Control de Transmisión) es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 - 1974 por Vint Cerf y Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP, SSH y FTP.

+	Bits 0 - 3				4 - 7				8 - 15								16 - 31
0	Puerto Origen																Puerto Destino
32	Número de Secuencia
64	Número de Acuse de Recibo (ACK)
96	longitud cabecera TCP				Reservado				Flags								Ventana
128	Suma de Verificación (Checksum)																Puntero Urgente
160	Opciones + Relleno (opcional)
224	Datos

Las aplicaciones envían flujos de bytes a la capa TCP para ser enviados a la red. TCP divide el flujo de bytes llegado de la aplicación en segmentos de tamaño apropiado (normalmente esta limitación viene impuesta por la unidad máxima de transferencia (MTU) del nivel de enlace de datos de la red a la que la entidad está asociada) y le añade sus cabeceras. Entonces, TCP pasa el segmento resultante a la capa IP, donde a través de la red, llega a la capa TCP de la entidad destino. TCP comprueba que ningún segmento se ha perdido dando a cada uno un número de secuencia, que es también usado para asegurarse de que los paquetes han llegado a la entidad destino en el orden correcto. TCP devuelve un asentimiento por bytes que han sido recibidos correctamente; un temporizador en la entidad origen del envío causará un timeout si el asentimiento no es recibido en un tiempo razonable, y el (presuntamente desaparecido) paquete será entonces retransmitido. TCP revisa que no haya bytes dañados durante el envío usando un checksum; es calculado por el emisor en cada paquete antes de ser enviado, y comprobado por el receptor.

• Puerto de origen (16 bits): Identifica el puerto a través del que se envía.
• Puerto destino (16 bits): Identifica el puerto del receptor.
• Número de secuencia (32 bits): Sirve para comprobar que ningún segmento se ha perdido, y que llegan en el orden correcto. Su significado varía dependiendo del valor de SYN:

• Si el flag SYN está activo (1), entonces este campo indica el número inicial de secuencia (con lo cual el número de secuencia del primer byte de datos será este número de secuencia más uno).
• Si el flag SYN no está activo (0), entonces este campo indica el número de secuencia del primer byte de datos.

• Número de acuse de recibo (ACK) (32 bits): Si el flag ACK está puesto a activo, entonces en este campo contiene el número de secuencia del siguiente byte que el receptor espera recibir.
• Longitud de la cabecera TCP (4 bits): Especifica el tamaño de la cabera TCP en palabras de 32-bits. El tamaño mínimo es de 5 palabras, y el máximo es de 15 palabras (lo cual equivale a un tamaño mínimo de 20 bytes y a un máximo de 60 bytes). En inglés el campo se denomina “Data offset”, que literalmente sería algo así como “desplazamiento hasta los datos”, ya que indica cuántos bytes hay entre el inicio del paquete TCP y el inicio de los datos.
• Reservado (4 bits): Bits reservados para uso futuro, deberían ser puestos a cero.
• Bits de control (flags) (8 bits): Son 8 flags o banderas. Cada una indica “activa” con un 1 o “inactiva” con un 0.

• CWR o “Congestion Window Reduced” (1 bit): Este flag se activa (se pone a 1) por parte del emisor para indicar que ha recibido un paquete TCP con el flag ECE activado. El flag ECE es una extensión del protocolo que fue añadida a la cabecera en el RFC 3168. Se utiliza para el control de la congestión en la red.
• ECE o “ECN-Echo” (1 bit): Indica que el receptor puede realizar notificaciones ECN. La activación de este flag se realiza durante la negociación en tres pasos para el establecimiento de la conexión. Este flag también fue añadido a la cabecera en el RFC 3168.
• URG o “urgent” (1 bit, ver URG): Si está activo significa que el campo “Urgente” es significativo, si no, el valor de este campo es ignorado.
• ACK o “acknowledge” (1 bit, ver ACK): Si está activo entonces el campo con el número de acuse de recibo es válido (si no, es ignorado).
• PSH o “push” (1 bit, ver PSH): Activa/desactiva la función que hace que los datos de ese segmento y los datos que hayan sido almacenados anteriormente en el buffer del receptor deben ser transferidos a la aplicación receptora lo antes posible.
• RST o “reset” (1 bit, ver Flag RST): Si llega a 1, se resetea la conexión.
• SYN o “synchronize” (1 bit, ver SYN): Activa/desactiva la sincronización de los números de secuencia.
• FIN (1 bit, ver FIN): Si se activa es porque no hay más datos a enviar por parte del emisor, esto es, el paquete que lo lleva activo es el último de una conexión.

• Ventana (16 bits): Es el tamaño de la ventana de recepción, que especifica el número de bytes que el receptor está actualmente esperando recibir.
• Suma de verificación (checksum) (16 bits): Es una suma de verificación utilizada para comprobar si hay errores tanto en la cabecera como en los datos.
• Puntero urgente (16 bits): Si el flag URG está activado, entonces este campo indica el desplazamiento respecto al número de secuencia qu indica el último byte de datos marcados como “urgentes”.
• Opciones (número de bits variable): La longitud total del campo de opciones ha de ser múltiplo de una palabra de 32 bits (si es menor, se ha de rellenar al múltiplo más cercano), y el campo que indica la longitud de la cabecera ha de estar ajustado de forma adecuada.
• Datos (número de bits variable): No forma parte de la cabecera, es la carga (payload), la parte con los datos del paquete TCP. Pueden ser datos de cualquier protocolo de nivel superior en el nivel de aplicación; los protocolos más comunes para los que se usan los datos de un paquete TCP son HTTP, telnet, SSH, FTP, etcétera.

Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Una negociación en cuatro pasos (4-way handshake) es usada para la desconexión. Durante el establecimiento de la conexión, algunos parámetros como el número de secuencia son configurados para asegurar la entrega ordenada de los datos y la robustez de la comunicación.