1. MECANISMOS IPC DEL SISTEMA BSC
PROTOCOLOS Y CONEXIONES:
Cuando hablamos de comunicación mediante conectores, estamos haciendo referencia a una interfaz o servicio con la capa de transporte (el nivel 4 del modelo OSI). La división de capas de un sistema es transparente al usuario, que puede trabajar con ellas sin necesidad de conocer sus detalles de implementación.
La interfaz de acceso a la capa de transporte no esta aislada de las capas inferiores, por lo que es necesario conocer algunos detalles de estas como la familia o dominio de la conexión y el tipo de conexión.
- La familia de la conexión engloba conectores que tienen características comunes (protocolos, convenios para formar nombres...)
- El tipo de conexión nos indica si el circuito por el que se van a comunicar los procesos es virtual (orientado a la conexión) o datagrama (no orientado a la conexión). En el primer caso se buscan enlaces libres que unan los ordenadores a conectar. Los datagramas por el contrario trabajan con paquetes que pueden seguir rutas distintas, por lo que no realizan conexiones permanentes.
DIRECCIONES DE RED
La forma de construir direcciones depende de los protocolos que se empleen en la capa de transporte y de red, sin embargo, hay llamadas al sistema que necesitan un puntero a una estructura de dirección de conector para trabajar. Esta estructura se define en el fichero de cabecera <sys/socket.h>.
La dirección la contienen 14 bytes. Su significado depende de la familia de conectores que se esté empleando.
MODELO CLIENTE - SERVIDOR
Este modelo es muy empleado para construir aplicaciones en una red.
SERVIDOR: Es un proceso que se esta ejecutando en un nodo de la red y que gestiona el acceso a un determinado recurso.
CLIENTE: Es un proceso que se ejecuta en el mismo o en diferente nodo y que realiza peticiones al servidor. Las peticiones están originadas por la necesidad de acceder al recurso que gestiona el servidor.
Es servidor se mantiene a la espera de peticiones, hasta que el cliente realiza una. La cumple y vuelve al estado inicial. Basándonos en esto podemos considerar dos tipos de servidores:
- Interactivos: El servidor atiende a la petición a parte de recogerla. Puede originar tiempos de espera largos si el servidor es lento.
- Concurrentes: El servidor recoge la petición de servicio, pero en lugar de atenderlas crea otros procesos que lo hacen. Esto solo se puede aplicar en sistemas multiprocesos como UNIX. Con este sistema aumenta la velocidad por lo que es recomendable para las aplicaciones donde los tiempos de servicio son variables.
ESQUEMA GENERAL DE UN SERVIDOR Y DE UN CLIENTE
2. LLAMADAS PARA EL MANEJO DE CONECTORES
Para el servidor:
Socket: Apertura del canal.Bind: Publicidad de la dirección.
Listen: Disposición para aceptar conexiones.
Accept: Aceptar una conexión. Bloquea el proceso hasta que se recibe una petición de conexión.
Para el cliente:
Socket: Apertura del canal.Connect: Petición de conexión.
Close: Cierra el canal.
Para ambos:
Read: Lectura de la petición de servicio para el servidor, y lectura de la respuesta para el cliente.Write: Envío de los datos al cliente por parte del servidor y petición de servicio del cliente.
APERTURA DE UN PUNTO TERMINAL EN UN CANAL (SOCKET)
La llamada par abrir un canal bidireccional de comunicaciones es socket.
Esta crea un punto terminal para conectarse a un canal y devuelve un descriptor. El descriptor del conector devuelto se usará en llamadas posteriores a funciones de la interfaz. El parámetro "af" determina que familia de direcciones o conectores vamos a emplear.
Las principales familias son:
AF_UNÍX: Comunica procesos que se ejecutan en una misma máquina.AF_INET: Son los protocolos de internet. Utiliza algunos como TCP o UDP.
El parámetro "type" indica la semántica de la comunicación para el conector y puede tomar los valores:
SOCK_STREAM: Orientado a la conexión. Es un circuito virtual.SOCK_DGRAM: Protocolo de tipo datagrama.
SOCK_RAW: Sólo puede ser utilizado por usuarios con permisos de superusuario, ya que facilita el acceso directo a los protocolos internos de la red.
SOCK_SEQPACKET Y SOCK_RDM: Protocolos no orientados a conexión que proporcionan un envío fiable y secuencial de datagramas. El segundo aún no esta implantado. Sí para un conector hubiese más de un protocolo se especificaría mediante el argumento "protocolo".
NOMBRE DE UN CONECTOR (BIND)
La llamada bind nos sirve para unir un conector con una dirección de red. Hace que el conector cuyo descriptor es sfd se una a la dirección de conector especificada en la estructura apuntada por addr, addrlen indica el tamaño de la dirección.
Si la llamada funciona correctamente devuelve el valor 0, y si no es así devuelve -1 y en errno estará el código del error producido.
DISPONIBILIDAD PARA RECIBIR PETICIONES DE SERVICIO (LISTEN)
El servidor indica que esta disponible para recibir peticiones con la llamada listen. El tipo de conector a de ser SOCK_STREAM y esta llamada suele ejecutarse en el proceso servidor tras socket y bind.
En los servidores interactivos mientras se esta atendiendo a un cliente pueden llegar peticiones de otros, por lo que es importante la cola de conexiones que habilita el listen. Si esta llamada funciona correctamente emite el valor 0 y en caso contrario el -1.
PETICIÓN DE CONEXIÓN (CONNECT)
La llamada connect es necesaria para establecer una conexión.
Para conectores SOCK_DGRAM: Connect especifica la dirección del conector remoto pero no se conecta con él. Además solo se podrán recibir mensajes procedentes de la dirección especificada.
Para conectores SOCK_STREAM: Connect intenta contactar con el ordenador remoto con objeto de realizar una conexión entre el conector remoto y el conector local. La llamada permanece bloqueada hasta que la conexión se completa.
Como en anteriores casos si la llamada se ejecuta correctamente devuelve 0 y si no -1.
ACEPTACIÓN DE UNA CONEXIÓN (ACCEPT)
La llamada accept nos sirve para que los procesos descriptores puedan leer peticiones de servicio.
Se usa con conectores orientados a conexión. Extrae la primera petición de conexión que hay en cola, creada con una llamada previa la listen. Luego crea un nuevo conector con las mismas propiedades que sfd y reserva un nuevo descriptor de fichero (nsfd) para él.
Accept permanece bloqueada hasta que reciba una nueva petición de conexión cuando no la tiene.
La llamada select puede usarse para ver si el conector tiene pendiente alguna petición de conexión.
Si la llamada funciona correctamente devolverá un numero entero no negativo que se debe interpretar como un descriptor del conector aceptado, en caso de error devolverá el valor -1.
LECTURA O RECEPCIÓN DE MENSAJES DE UN CONECTOR
Cuando el canal de comunicaciones está iniciado y el servidor y el cliente disponen de un conector con el canal, contamos con 5 llamadas al sistema para leer datos o mensajes de un conector. Estas llamadas son read, readv, recv, recvfrom, y recvmsg.
El funcionamiento de la llamada read tiene el mismo interfaz que para el manejo de ficheros. Para conectores su comportamiento es igual exceptuando que obviamente el descriptor de ficheros en realidad un descriptor de conector.
Las otras cuatro llamadas son variaciones de read que sólo funcionan con conectores.
ESCRITURA O ENVIO DE MENSAJES A UN CONECTOR.
Como ocurría para el read, tenemos 5 llamadas para escribir datos en un conector. Write, writev, send, sedto, sedmsg.
La llamada write se comporta también como cuando se usa con ficheros con la salvedad de que el descriptor de ficheros es en realidad un descriptor de conector.
Writev es una generalización de write y se puede utilizar para fichero y para conector. Las otras tres devuelven el total de bytes escritos en el conector.
CIERRE DEL CANAL (CLOSE)
Para desconectar un proceso de un conector podemos utilizar close. Esta llamada cierra el conector en ambos sentidos.
Bajate esta documentación en un archivo Acrobat Reader
