CAPITULO III

La Interface SOCKET



El Paradigma de E/S de UNIX y la E/S de la Red


En primer lugar hemos de distinguir entre  los protocolos de interface y el TCP/IP, debido a que los estándares no especifican exactamente cómo es que interactúan los programas de aplicación con el software de protocolo.

A pesar de la carencia de un estándar, veremos la interface del UNIX BSD como se emplea el TCP/IP en programación. En particular, la interface Winsock proporciona la funcionalidad socket para MsWindows.

Veamos pues cómo empezó todo este “jaleo”:

Unix fue desarrollado y diseñado como un sistema operativo  de tiempo compartido para computadoras uniprocesador. Se trata, como ya es sabido, de un S.O. orientado a proceso, en el que cada programa de aplicación se ejecuta como un proceso de nivel de usuario. Derivados de los MULTICS, los primitivos sistemas de E/S de UNIX siguen un paradigma conocido como “Open-Read-Write-Close”: antes de que un proceso de usuario pueda ejecutar operaciones de E/S, llama a Open para especificar el archivo o dispositivo que se va a utilizar (recuerdese la independencia de dispositivo de UNIX) y obtiene el permiso. La llamada a Open devuelve un pequeño entero (el descriptor de archivo) que el proceso utiliza al ejecutar las operaciones de E/S en el archivo abierto. Una vez abierto un objeto, se pueden hacer las llamadas a Read y/o Write. Tanto Read como Write toman tres argumentos (descriptor de archivo, dirección del buffer y nº de bytes a transferir). Una vez completadas estas operaciones el proceso llama a Close.

Originalmente, todas las operaciones UNIX se agrupaban como se ha descrito anteriormente, y una de las primeras implementaciones de TCP/IP también utilizó éste paradigma. Pero el grupo que añadió los protocolos TCP/IP al BSD decidió que, como los protocolos de red eran más complejos que los dispositivos convencionales de E/S, la interacción entre los programas de usuaio y los protocolos de red debías ser más compleja. En particular, la interface de protocolo debía permitir a los programadores crear un código de servidor que esperaba las conexiones pasivamente, así como también un código cliente que formara activamente las conexiones. Para manejas datagramas, se decidió abandonar este paradigma.

 

La abstracción de SOCKET


La base para la E/S de red en UNIX se centra en una abstracción conocida como socket.

El socket es la generalización del mecanismo de acceso a archivos de UNIX que proporciona un punto final para la comunicación. Al igual que con el acceso a archivos, los programas de aplicación requieren que el S.O. cree un socket cuando se necesite. El S.O. devuelve un entero que el programa de aplicación utiliza para hacer referencia al socket recientemente creado. La diferencia principal entre los descriptores de archivo y los descriptores de socket es que el sistema operativo enlaza un descriptor de archivo a un archivo o dispositivo del sistemacuando la aplicación llama a Open, pero  puede crear sockets sin enlazarlos a direcciones de destino específicas.

Básicamente, el socket es una API en la que el servidor espera en un puerto predefinido y el cliente puede utilizar sin embargo un puerto dinámico.

EJEMPLOS:

·       Creación de un socket:

             resultado = socket (pf, tipo, protocolo)

El argumento PF especifica la familia de protocolo que se va utilizar con el socket (v.q. PF_INET para TCP/IP). El argumento tipo especifica el tipo de comunicación que se desea (v.q.SOCK_DGRAM para servicio de entrega de datagramas sin conexion, o SOCK_STREAM para servicio de entrega confiable de flujo).

·       Envío de datos:

             write (socket, buffer, lenght)

·       Especificación de una dirección local:

             bind (socket, localaddr, addrlen)

Inicialmente, un socket se crea sin ninguna asociación hacia direcciones locales o de destino. Para los protocolos TCP/IP, esto significa que ningún número de puerto de protocolo local se ha asignado y que ningún puerto de destino o dirección IP se ha especificado. En muchos casos, los programas de aplicación no se preocupan por las direcciones locales que utilizan, ni están dispuestos a permitir que el software de protocolo elija una para ellos. Sin embargo, los procesos del servidor que operan en un puerto “bien conocido” deben ser capaces de especificar dicho puerto para el sistema. Una vez que se ha creao un socket, el servidor utiliza una llamada del sistema BIND (enlace) para establecer una dirección local para ello.

BIND tiene la forma que se ha descrito arriba.

Indice     Capitulo I     Capitulo II     Capitulo IV

1