PDF de programación - Programación de aplicaciones distribuidas usando sockets

Programación de aplicaciones distribuidas usando

sockets

1a Versión: José Luis Díaz. Octubre 1994.

2a Versión: José Ramón Arias. Nov. 1998, Oct. 1999, Oct. 2000.

Índice general

1. Programación de aplicaciones distribuidas usando sockets
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.
1.2.
Implementación en el sistema operativo . . . . . . . . . . . .
1.3. Conceptos de diseño . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Dirección final genérica . . . . . . . . . . . . . . . . .
1.3.2. Utilización del API para TCP/IP . . . . . . . . . . . .
1.4. Programación con el interfaz de sockets
. . . . . . . . . . . .
1.5. Uso de los sockets . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1. Creación del socket: socket() . . . . . . . . . . . . . .
1.5.2. Asignar una dirección al socket: bind() . . . . . . . .
1.5.3. Conexión en sockets tipo stream . . . . . . . . . . . . .
1.5.4. Conexión en sockets tipo datagram . . . . . . . . . . .
1.5.5. Transferencia de información en sockets tipo stream:
write() y read() . . . . . . . . . . . . . . . . . . . .
1.5.6. Transferencia de información en sockets tipo datagram:
sendto() y recvfrom() . . . . . . . . . . . . . . . . .
1.5.7. Cerrar la conexión: close() y shutdown() . . . . . . .
1.6. Ejemplo con sockets tipo stream . . . . . . . . . . . . . . . . .
1.6.1. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7. Desarrollo de aplicaciones. Tipos de servidores . . . . . . . . .
1.7.1. Concurrencia real . . . . . . . . . . . . . . . . . . . . .
1.7.2. Concurrencia aparente . . . . . . . . . . . . . . . . . .
1.8. Otras funciones interesantes . . . . . . . . . . . . . . . . . . .
1.8.1. Obtener el IP de un nodo: gethostbyname() . . . . .
1.8.2. Obtener el nombre de un nodo: gethostbyaddr() . . .
1.8.3. Obtener servicios y puertos por su nombre . . . . . . .
1.9. Análisis del interfaz de sockets . . . . . . . . . . . . . . . . .

2
2
2
3
5
5
6
7
8
10
15
19

19

21
22
24
24
25
27
28
31
37
38
39
39
41

1

Capítulo 1

Programación de aplicaciones
distribuidas usando sockets

1.1.

Introducción

En 1981 en la Universidad de California en Berkeley diseñaron para su
sistema operativo, el BSD Unix, un interfaz para permitir a los programas
acceder y comunicarse a través de una red de comunicaciones.

Ese interfaz, conocido como el interfaz de sockets, se incorporó a la ver-
sión 4.1 del sistema operativo. Como ese sistema operativo fue adoptado por
varios fabricantes de estaciones de trabajo como Sun Microsystems Inc., Tek-
tronix Inc. o Digital Equipment Corp., el interfaz de sockets estuvo disponible
en gran cantidad de máquinas. El interfaz fue tan ampliamente aceptado que
se convirtió en un estándar de facto.

El UNIX System V usa en su lugar el Transport Level Interface (TLI). No
obstante el uso de los sockets está tan extendido que es habitual que cualquier
implementación de UNIX disponga de este interfaz por compatibilidad con
el BSD.

1.2.

Implementación en el sistema operativo

Una de las ideas iniciales en el diseño de los sockets era utilizar las fun-
ciones que suministra el sistema operativo Unix siempre que fuera posible
y, añadir nuevas llamadas al sistema si era difícil encajar los requerimien-
tos de la programación en red con las funciones existentes en el operativo.
(Consultar [1] para una explicación más detallada).

En Unix, cuando una aplicación desea realizar operaciones de entra-
da/salida, llama a la función open para crear un descriptor de fichero que
se usará luego para acceder al fichero. El sistema operativo implementa los
descriptores de ficheros como un array de punteros a estructuras internas
de datos. Para cada proceso, el sistema mantiene una tabla de descriptores

2

Figura 1.1: Estructura de datos de un socket en el sistema operativo

de ficheros separada. Cuando un proceso abre un fichero, el sistema coloca
un puntero a las estructuras de datos internas de ese fichero en la tabla de
descriptores de ficheros de ese proceso y le devuelve al proceso el índice del
puntero en esa tabla. Ese índice es el descriptor del fichero y es lo único que
el proceso tiene que recordar cuando quiere acceder al fichero.

El interfaz de los sockets añade una nueva abstracción para la comuni-
cación a través de la red, el socket. Cada socket activo se identifica por un
entero denominado su descriptor de socket. El sistema operativo Unix
coloca los descriptores de sockets en la misma tabla de descriptores que los
ficheros. De esta manera, una aplicación no puede tener un descriptor de
fichero con el mismo valor que un descriptor de socket.

Para crear un descriptor de socket se le añade al sistema operativo una
nueva llamada al sistema: la función socket. Con esta función se crea un
socket. Cuando un proceso crea un socket, el sistema coloca un puntero a
las estructuras internas de ese socket en la tabla de descriptores de ficheros
de ese proceso y le devuelve al proceso el índice de esa tabla. Ese índice es
el descriptor de socket. Para rellenar los detalles específicos del socket será
necesario realizar llamadas a otras funciones del API.

En la figura 1.1 podemos ver una representación simplista de un socket

en el interior del sistema operativo.

1.3. Conceptos de diseño

Un socket, desde el punto de vista funcional, se define como un punto
terminal al que pueden “enchufarse” dos procesos para comunicar entre sí.
Para que dos procesos pudieran comunicar hubo que dotar al sistema de una
serie de funciones que permitieran a esos procesos acceder a los dispositivos

3

Tabla de descriptoresFamilia de Protocolo: PF_INETServicio: SOCK_STREAMDirección Final: ....1:2:3:4:0:Estructura de datos para un socket de red. Cuando se consideró cómo añadir funciones al sistema operativo para
suministrar acceso a las comunicaciones, surgieron dos posibilidades:

Definir funciones que soportaran específicamente el protocolo TCP/IP.

Definir funciones que soportaran cualquier tipo de protocolo de comu-
nicaciones y parametrizarlas cuando se quisiera utilizar TCP/IP.

En el momento del desarrollo del interfaz, el protocolo TCP/IP no estaba
tan ampliamente divulgado como ahora y existían otras posibilidades para
establecer comunicaciones entre dos máquinas. Por esta razón, los diseñado-
res optaron por la segunda opción: mantener la generalidad del interfaz.1

Al desvincular el interfaz de sockets de un protocolo de comunicaciones
determinado, se hará necesario especificar ese protocolo cuando se usen esas
funciones. De esta manera, cada vez que se quiera utilizar el interfaz de
sockets, será necesario especificar:

Familia de Protocolo. Hay que indicar qué tipo de protocolo se va a utili-
zar para realizar las distintas comunicaciones. Los protocolos TCP/IP
constituyen una única familia representada por la constante PF_INET.
En el caso de comunicaciones entre procesos en la misma máquina
usando el sistema de ficheros, tendríamos la familia de protocolos iden-
tificada como PF_UNIX.

Tipo de servicio. El interfaz permite seleccionar el tipo de servicio que se
desea siempre y cuando el protocolo seleccionado sea capaz de suminis-
trar distintos tipos de servicio. Aquí por tipo de servicio nos estamos
refiriendo a cosas como comunicación orientada a la conexión o bien a
comunicación orientada a los datagramas.

Familia de direcciones finales. Cada familia de protocolos especifica la
dirección final de una comunicación de una manera distinta. La di-
rección final de una comunicación es el “punto” a través del cual un
proceso envía o recibe datos. Por ejemplo en IP, una dirección final se
especifica usando la dirección IP de la máquina y el número de puer-
to de protocolo que usará el programa. En el caso de usar la familia
de protocolos UNIX la dirección final será el nombre de un fichero.
El interfaz permite que las direcciones finales se puedan expresar con
distintos formatos aún dentro de la propia familia de protocolos. Cada
una de esas posibles representaciones correspondería a una familia de
direcciones.

1Quizás la incorporación del interfaz de sockets y de todas las aplicaciones que se
desarrollaron sobre dicho interfaz haya sido una de las principales causas de la enorme
popularidad de TCP/IP en estos días. La otra quizás sea que era gratis.

4

1.3.1. Dirección final genérica

Para gestionar esta múltiple variedad de direcciones finales posibles2, el
interfaz define un formato de dirección final generalizada. En ese formato,
una dirección final consta de dos elementos:

1. Una constante que identifica la familia de direcciones a utilizar.

2. La representación de la dirección final en esa familia de direcciones

concreta.

En la práctica, ésta dirección final genérica que define el interfaz de los

sockets se convierte en una estructura C con dos campos:

struct sockaddr {

u_short sa_family; /* Familia de la dirección */
char

sa_data[14]; /* Dirección final especifica

para esa familia */

};

Todas las funciones del interfaz de sockets que necesiten recibir como
parámetro una dirección final, recibirán un puntero a una estructura de tipo
sockaddr. En la práctica no todas las familias de direcciones encajan en esa
estructura porque no todas usan 14 bytes para representar una dirección
final. En esos casos es necesario utilizar otras estructuras más adecuadas
para la familia de direcciones con la que se trabaje.

1.3.2. Utilización del API para TCP/IP

Vamos a ver con más detenimiento como se particularizan las generali-

zaciones del interfaz de sockets para el protocolo TCP/IP.

En el caso de la familia de protocolos el valor a indicar, como ya hemos

visto, será la constante predefinida PF_INET (“Protocol Family Internet”).

En cuanto a la especificación del tipo de servicio deseado, los protocolos
de la familia Internet solo admiten dos tipos de servicio: el orientado a cone-
xión (TCP) y el orientado a los datagramas (UDP). Para identificar ambos
tipos de servicio cuando se crea un socket se usan