Capítulo 4 El API de sockets

Capítulo 4 El API de sockets

Este capítulo introduce la primera herramienta de programación para implementar comunicaciones entre procesos: el API de sockets.

Como el lector podrá recordar del Capítulo 2, el API de sockets es un mecanismo que proporciona un nivel bajo de abstracción para IPC. Se presenta en este punto por su simplicidad. Aunque los programadores de aplicaciones apenas tienen que codificar en este nivel, la comprensión del API de sockets es importante al menos por dos razones. En primer lugar, los mecanismos de comunicación proprocionados en estratos superiores se construyen sobre el API de sockets; o sea, se implementan utilizando las operaciones proporcionadas por el API de sockets. En segundo lugar, para aquellas aplicaciones en las que es primordial el tiempo de respuesta o que se ejecutan sobre una plataforma con recursos limitados, el API de sockets puede ser el mecanismo de IPC más apropiado, o incluso el único disponible.

4.1 Antecedentes

El API de sockets aparece por primera vez a principios de la década de los 80 como una biblioteca de programación que proporcionaba la funcionalidad de IPC en una versión del sistema operativo UNIX conocida como Unix de Berkeley (BSD 4.2). Actualmente los principales sistemas operativos dan soporte al API de sockets. En los sistemas basados en UNIX tales como BSD o Linux, el API es parte del núcleo, o kernel, del sistema operativo. En los sistemas operativos de computadores personales tales como MS-DOS, Windows NT (y sus variantes), Mac-OS y OS/2, el API se proporciona como bibliotecas de programación. (En los sistemas Windows, a esta API se la conoce como Winsock). Java, un lenguaje diseñado teniendo en cuenta la programación de aplicaciones en red, proporciona el API de sockets como parte de las clases básicas del lenguaje. Todas estas interfaces de programación de sockets comparten el mismo modelo de paso de mensajes y una sintaxis muy similar.

En este capítulo, se usará como caso representativo el API de sockets de Java.

Socket (en castellano, enchufe) es un término tomado del campo de las comunicaciones telefónicas. En los primeros días de la telefonía (anteriores al siglo XX), cuando una persona quería hacer una llamada a otra tenía que ser a través de un operador, el cual manualmente establecía una conexión introduciendo los dos extremos de un cable dentro de dos receptáculos específicos, cada uno asignado a uno de los dos interlocutores, sobre un panel de sockets (enchufes). La desconexión también la realizaba el operador manualmente. Esta metáfora fue la base del API de sockets para comunicación entre procesos.

4.2 La metáfora del socket en IPC

Inspirándose en la terminología de la telefonía, el diseñador del API de sockets ha proporcionado una construcción de programación denominada socket. Cuando un proceso desea comunicarse con otro, debe crear una instancia de tal construcción (véase la Figura 4.1). Sin embargo, a diferencia de la telefonía primitiva, la comunicación entre los interlocutores puede ser orientada a conexión o sin conexión. Por claridad, primero se presentará el API de sockets sin conexión.

Figura 4.1 El modelo conceptual del API de sockets.

4.3 El API de sockets datagrama

Como el lector podrá recordar del Capítulo 1 de este libro o de cualquier otro sitio, hay dos protocolos fundamentales en el nivel de transporte de la arquitectura de Internet: el protocolo de datagrama de usuario (UDP, User Datagram Protocol) y el protocolo de control de transmisión (TCP, Transmission Control Protocol).

El protocolo de datagrama de usuario (UDP) permite que un paquete se transporte (es decir, se envíe o se reciba en el nivel de transporte) utilizando comunicaciones sin conexión. El paquete de datos transportado de esta manera se denomina datagrama. Conforme a la comunicación sin conexión, cada datagrama transportado es dirigido y encaminado individualmente y puede llegar al receptor en cualquier orden. Por ejemplo, si el proceso 1 en la máquina A envía sucesivamente mensajes transportados en los datagramas m1 y m2 al proceso 2 en la máquina B, los datagramas pueden transportarse sobre la red por diferentes rutas, y pueden llegar al proceso receptor en cualquiera de los dos órdenes posibles: m1-m2 o m2-m1.

El protocolo de control de transmisión (TCP) está orientado a conexión y transporta un flujo de datos sobre una conexión lógica establecida entre el emisor y el receptor. Gracias a la conexión, se garantiza que los datos mandados desde un emisor a un receptor van a ser recibidos en el mismo orden que se enviaron. Por ejemplo, si el proceso 1 en la máquina A manda sucesivamente mensajes transportados en m1, m2 al proceso 2 que ejecuta en la máquina B, el proceso receptor puede asumir que los mensajes se le entregarán en el orden m1-m2 y no m2-m1.

El API de sockets de Java, como el resto de interfaces de programación de sockets, proporciona construcciones de programación de sockets que hacen uso tanto del protocolo UDP como TCP. Los sockets que utilizan UDP para el transporte son conocidos como sockets datagrama, mientras que los que usan TCP se denominan sockets stream. Debido a su relativa simplicidad, en primer lugar se presentarán los sockets datagrama.

El socket datagrama sin conexión

Puede parecer sorprendente, pero los sockets datagrama pueden dar soporte tanto a una comunicación sin conexión como a una orientada a conexión en el nivel de aplicación (véase la Figura 4.2). Esto se debe a que, aunque los datagramas se envían o reciben sin la noción de conexiones en el nivel de transporte, el soporte en tiempo de ejecución del API de sockets puede crear y mantener conexiones lógicas para los datagramas intercambiados entre dos procesos, como se mostrará en la próxima sección.

Figura 4.2 Socket datagrama sin conexión y orientado a conexión.

En Java, el API de sockets datagrama proporciona dos clases:

1. La clase DatagramSocket para los sockets

2. La clase DatagramPacket para los datagramas intercambiados

Un proceso que

...