IPC Interprocess Comunication

La comunicacin entre procesos, en ingls IPC (Inter-process Communication) es una funcin bsica de los sistemas operativos. Los procesos pueden comunicarse entre s a travs de compartir espacios de memoria, ya sean variables compartidas o buffers, o a travs de las herramientas provistas por las rutinas de IPC. La IPC provee un mecanismo que permite a los procesos comunicarse y sincronizarse entre s, normalmente a travs de un sistema de bajo nivel de paso de mensajes que ofrece la red subyacente. La comunicacin se establece siguiendo una serie de reglas (protocolos de comunicacin). Los protocolos desarrollados para internet son los mayormente usados: IP (capa de red), protocolo de control de transmisin (capa de transporte) y protocolo de transferencia de archivos , protocolo de transferencia de hipertexto (capa de aplicacin). CAPA DE APLICACION CAPA DE TRANSPORTE CAPA DE RED

Los procesos pueden estar ejecutndose en una o ms computadoras conectadas a una red. Las tcnicas de IPC estn divididas dentro de mtodos para: paso de mensajes, sincronizacin, memoria compartida y llamadas de procedimientos remotos (RPC). El mtodo de IPC usado puede variar dependiendo del ancho de banda y latencia (el tiempo desde el pedido de informacin y el comienzo del envi de la misma) de la comunicacin entre procesos, y del tipo de datos que estn siendo comunicados. El sistema operativo provee mnimamente dos primitivas, enviar y recibir, normalmente llamadas send y receive. Asimismo, debe implementarse un enlace de comunicacin entre los procesos de la comunicacin. Este enlace puede ser unidireccional o multidireccional segn permita la comunicacin en solo uno o en varios sentidos. La comunicacin puede ser: Sncrona: Quien enva permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otro ejercicio. Asncrona: Quien enva contina con su ejecucin inmediatamente despus de enviar el mensaje al receptor. Persistente: El receptor no tiene que estar operativo al mismo tiempo que se realiza la comunicacin, el mensaje se almacena tanto tiempo como sea necesario para poder ser entregado (Ej.: e-Mail).

Momentnea: El mensaje se descarta si el receptor no est operativo al tiempo que se realiza la comunicacin. Por lo tanto no ser entregado. Directa: Las primitivas enviar y recibir explicitan el nombre del proceso con el que se comunican. Ejemplo: enviar (mensaje, A) enva un mensaje al proceso A. Es decir se debe especificar cual va a ser el proceso fuente y cual va a ser el proceso Destino.

Las operaciones bsicas Send y Receive se definen de la siguiente manera: Send (P, mensaje); enva un mensaje al proceso P (P es el proceso destino). Receive (Q, mensaje); espera la recepcin de un mensaje por parte del proceso Q (Q es el proceso fuente). Nota: Receive puede esperar de un proceso cualquiera, un mensaje, pero el Send s debe especificar a quin va dirigido y cul es el mensaje. Indirecta: Es aquella donde la comunicacin est basada en una herramienta o instrumento ya que el emisor y el perceptor estn a distancia. Simtrica: Todos los procesos pueden enviar o recibir. Tambin llamada bidireccional para el caso de dos procesos. Asimtrica: Un proceso puede enviar, los dems procesos solo reciben. Tambin llamada unidireccional. Suele usarse para hospedar servidores en Internet. Con uso de buffers explcito o automtico: El transmisor se bloquea hasta que el receptor recibe el mensaje (capacidad cero).

En numerosas aplicaciones hay una necesidad clara para que estos procesos se comuniquen para el intercambio de datos o informacin de control. Hay unos cuantos mtodos para hacer lo anterior. Se pueden considerar los siguientes:

Tubera (Pipes) Seales (Signals) Colas de Mensajes Semforos Memoria Compartida Sockets

Tubera (Pipes) Consiste en una cadena de procesos conectados de forma tal que la salida de cada elemento de la cadena es la entrada del prximo. Es comn el uso de buffer de datos entre elementos consecutivos. Las tuberas (pipes) estn implementadas en forma muy eficiente en los sistemas operativos multitarea, iniciando todos los procesos al mismo tiempo, y atendiendo automticamente los requerimientos de lectura de datos para cada proceso cuando los datos son escritos por el proceso anterior. De esta manera el planificador de

corto plazo va a dar el uso de la CPU a cada proceso a medida que pueda ejecutarse minimizando los tiempos muertos. Para mejorar el rendimiento, la mayora de los sistemas operativos implementan las tuberas usando buffers, lo que permite al proceso proveedor generar ms datos que lo que el proceso consumidor puede atender inmediatamente.

Seales (signals) Una seal podra ser generada por una interrupcin de teclado o una condicin de error como el proceso de intentar acceder a un lugar que no existe en la memoria virtual. Las seales pueden ser sincrnicas generadas por un error en una aplicacin, pero la mayora de las seales son asncronas. Las seales pueden ser destinadas a un proceso cuando el sistema detecta un evento de software, como por ejemplo un usuario que utiliza un interrumpt o stop o kill a una solicitud de otro proceso. Las seales tambin pueden venir directamente del ncleo del sistema operativo cuando un evento de hardware como un error de bus o de una instruccin ilegal es encontrado. El sistema define un conjunto de seales que pueden ser destinados a un proceso. La mayora de las seales causan la terminacin del proceso de recepcin, si no se toman medidas por el proceso en respuesta a la seal. Algunas seales paran el proceso de recepcin y otras seales pueden ser ignoradas. Cada seal tiene una accin predeterminada, que es uno de los siguientes: La seal se descarta despus de ser recibida El proceso se termina despus de la seal es recibida Un archivo central se escribe, entonces el proceso se termina El proceso se detiene despus de que la seal se recibe

Colas de mensajes Las colas de mensajes permiten a uno o ms procesos escribir mensajes, que sern ledos por uno o ms procesos lectores. Cada vez que un proceso intenta escribir un mensaje en la cola de escritura sus identificadores efectivos de usuario y grupo son comparados con el modo en la estructura de datos ipc_perm de esta cola. Si el proceso puede escribir en la cola entonces el mensaje puede ser copiado desde el espacio de direcciones del proceso a una estructura de datos msg y ser puesto al final de la cola. Cada mensaje es etiquetado con un tipo especfico de aplicacin, acordado entre los procesos cooperantes. Sin embargo, quizs no haya espacio suficiente para el mensaje. En este caso el proceso ser aadido a esta cola de espera de esta cola y el planificador ser llamado para que ejecute otro proceso. Ser despertado cuando uno o ms mensajes hayan sido ledos de la cola.

La lectura de la cola es un proceso similar. De nuevo, los derechos de acceso del proceso a la cola de escritura son chequeados. Un proceso lector puede elegir entre coger el primer mensaje de la cola sin importar el tipo o seleccionar mensajes de un determinado tipo. Si no hay mensajes que cumplan este criterio el proceso lector es aadido a la cola de espera de lectura y se ejecuta el planificador. Cuando un mensaje sea escrito a la cola este proceso ser despertado y ejecutado de nuevo.

Semforos Los semforos son una construccin de programacin diseado por E.W. Dijkstra a finales de 1960. El modelo de Dijkstra fue la operacin de los ferrocarriles, pensemos en un tramo de ferrocarril en el que hay una sola pista sobre la cual slo se permite un tren a la vez. La proteccin de esta pista es un semforo. Un tren que debe esperar antes de entrar en la pista hasta que el semforo est en un estado que permite viajar. Cuando el tren entra en la pista, el semforo cambia de estado para evitar que otros trenes entren en la pista. Un tren que est dejando a esta seccin de la pista debe volver a cambiar el estado de los semforos para permitir que otro tren para entrar. En su forma ms simple un semforo es una zona en memoria cuyo valor puede ser comprobado y establecido por ms de un proceso. La comprobacin y establecimiento es, ms all de como un proceso est implicado, ininterrumpible o atmico; una vez que ha comenzado nada puede detenerlo. El resultado de la operacin de comprobacin y establecimiento es la suma del valor actual del semforo y el valor establecido, que puede ser positivo o negativo. Dependiendo del resultado de la operacin de comprobacin y establecimiento un proceso quizs tenga que suspenderse hasta que el valor del semforo sea cambiado por otro proceso. Los semforos pueden ser utilizados para implementar regiones crticas, reas de cdigo crticas que un proceso solo debiera ejecutar en un determinado momento. Digamos que usted tuviera muchos procesos cooperando leyendo y escribiendo registros en un nico fichero de datos. Usted querra que los accesos al fichero estuvieran estrictamente coordinados. Usted podra utilizar un semforo con un valor inicial de 1 y, alrededor del cdigo de operacin del fichero, situar dos operaciones de semforos, la primera para comprobar y decrementar el valor del semforo, y la segunda para comprobar e incrementarlo. El primer proceso que acceda al fichero debera intentar decrementar el valor del semforo y si tuviese xito, el valor del semforo ser 0. Este proceso puede ahora continuar y usar el fichero de datos pero si otro proceso que deseara usar el fichero en ese momento intentara decrementar el valor del semforo fallara ya que el resultado debera ser -1. Este proceso deber ser suspendido hasta que el primer proceso haya terminado con el fichero. Cuando el primer proceso ha terminado con el fichero incrementar el valor del semforo, ponindolo de nuevo a 1. Ahora del proceso en espera puede ser reanudado y esta vez su intento de modificar el semforo tendr xito. Los semforos pueden ser operados como unidades individuales o como elementos de un conjunto. Un conjunto de semforos se compone de una estructura de control y un conjunto de semforos individuales. Un conjunto de semforos puede contener hasta 25 elementos. En una manera similar a las colas de mensajes, el conjunto de semforos se debe inicializar con semget (); el creador del semforo puede cambiar su propiedad o permisos mediante semctl (), y operaciones de los semforos se llevan a cabo a travs de la semop () funcin.

Memoria compartida La memoria compartida permite a uno o ms procesos comunicarse por medio de la memoria que aparece en todos su espacios virtuales de direcciones. Las pginas de la memoria virtual se referencan por entradas en la tabla de pginas de cada uno de los procesos que comparten tablas de pginas. No tienen que estar en la misma direccin en toda la memoria virtual de los procesos. Como con todos los objetos IPC System V, el acceso a reas de memoria es controlado a travs de chequeo de derechos de acceso. Una vez que la memoria est siendo compartida, no hay comprobacin de como los procesos la utilizan. Esto debe recaer en otros mecanismos, por ejemplo los semforos System V, para sincronizar el acceso a memoria.

Figure 5.4: Memoria Compartida IPC System V Cada nueva rea creada de memoria compartida est representada por una estructura de datos shmid_ds. Estas son guardadas en el vector shm_segs. La estructura de datos shmid_ds describe lo grande que es el rea de memoria compartida, cuantos procesos estn usndola e informacin sobre esa memoria que est siendo mapeada dentro de sus espacios de direcciones. Es el creador de la memoria compartida el que controla los permisos de acceso a esa memoria y si la clave es pblica o privada. Si tiene suficientes derechos de acceso puede tambin fijar la memoria compartida en memoria fsica. Cada proceso que desee compartir la memoria debe engancharse a esa memoria virtual por medio de llamadas al sistema. Esto crea una nueva estructura de datos vm_area_struct que describe la memoria compartida para este proceso. El proceso puede elegir en su espacio virtual de direcciones donde va la memoria virtual o puede dejar a Linux que elija un rea libre lo suficientemente grande. La nueva

estructura vm_area_struct se coloca en la lista de vm_area_struct que es apuntada por la shmid_ds. Los punteros vm_next_shared y vm_prev_shared son usados para enlazarlos a ambos unidos. La memoria virtual no es creada actualmente durante el enganche; sucede cuando el primer proceso intenta acceder a ella. La primera vez que un proceso accede a un de las pginas de memoria virtual compartida, tiene lugar un fallo de pgina. Cuando Linux corrige este fallo de pgina encuentra la estructura de datos vm_area_struct describindola. Esta contiene punteros a rutinas de tratamiento para este tipo de memoria virtual compartida. El cdigo de tratamiento de fallos de pgina de memoria compartida busca en las entradas de tablas de pginas de esta shmid_ds para ver si existe alguna para esta pgina de memoria virtual compartida. Si no existe, asignar una pgina fsica y crear una entrada en la tabla de pginas para ella. Tan pronto como entra en la tabla de pginas del proceso en curso, esta entrada es guardada en la shmid_ds. Esto significa que cuando el siguiente proceso que intenta acceder a esta memoria obtiene un fallo de pgina, el cdigo de tratamiento de fallos de pgina de memoria virtual usar esta pgina recientemente creada tambin para este proceso. Por tanto, el primer proceso que accede a una pgina de memoria compartida hace que esta sea creada y los posteriores accesos por otros procesos hacen que esa pgina sea aadida a sus espacios virtuales de direcciones. Cuando los procesos no desean compartir ms la memoria virtual, se desencadenan de ella. Como otros procesos estn usando todava la memoria el desencadenado solo afecta al proceso actual. Su vm_area_struct es eliminada de la estructura de datos shmid_ds y desasignada. La tabla de pginas del proceso actual es actualizada para anular el rea de memoria virtual que era utilizada para compartir. Cuando el ltimo proceso que comparta la memoria se suelta de ella, las pginas de memoria compartida actualmente en memoria fsica son liberadas, de la misma forma que lo es la estructura de datos shmid_ds de esta memoria compartida.

RPC
(Remote Procedure Call / llamada a un procedimiento remoto) Es un protocolo que un programa puede utilizar para solicitar un servicio de un programa localizado en cualquier computadora en una red sin necesidad de conocer los detalles de la red. Una llamada a procedimiento es tambin conocida a veces como una llamada de funcin o una llamada de subrutina. RPC utiliza el modelo cliente/servidor. El programa solicitante es un cliente y el programa proveedor de servicios es el servidor. Al igual que una llamada a procedimiento local, una RPC es una operacin sincrnica que requiere que el programa solicitante sea suspendido hasta que los resultados del procedimiento remoto sean devueltos. Cuando las instrucciones de programa que utilizan RPC se compilan en un programa ejecutable, un stub se incluye en el cdigo compilado que acta como representante del cdigo de procedimiento remoto. Cuando se ejecuta el programa y

se emite la llamada al procedimiento, el stub recibe la solicitud y reenva a un programa de ejecucin de cliente en el equipo local. El programa de ejecucin de cliente tiene el conocimiento de cmo abordar la aplicacin de equipo y el servidor remota y enva el mensaje a travs de la red que pide el procedimiento remoto. Del mismo modo, el servidor incluye un programa de ejecucin y cdigo auxiliar que la interfaz con el propio procedimiento remoto. Del mismo modo se devuelven los resultados. Comunicacin orientada a mensajes Las comunicaciones RPC se basan en la idea que el receptor est operativo para poder invocar una cierta funcin, no podemos suponer que el receptor siempre estar operativo y esperando a comunicarse. La solucin es definir la comunicacin en trmino de paso de mensajes.

Winsock
Windows Sockets es una interfaz de protocolo-independiente. Aprovecha las capacidades de comunicacin de los protocolos subyacentes. En Windows Sockets 2, un identificador de socket, opcionalmente, se puede utilizar como un identificador de archivo con el archivo estndar de funciones E / S. Windows Sockets se basa los primeros sockets popularizados por Berkeley Software Distribution (BSD). Una aplicacin que utiliza Windows Sockets puede comunicarse con otras implementaciones socket en otros tipos de sistemas. Sin embargo, no todos los servicios de transporte proveen apoyo a todas las opciones disponibles. Los sockets de Windows (Winsock) se iniciaron como un esfuerzo por parte de un grupo de distribuidores para aprovechar la conglomeracin de interfaces socket, o zcalos, basadas en el protocolo TCP/IP. Varios distribuidores haban transportado originalmente sus implementaciones de este protocolo a Windows. El resultado fue que nada trabajaba con lo de los dems. La interfaz de sockets se implement originalmente como un mecanismo conectado en red de comunicacin entre procesos para la versin 4.2 del sistema UNIX de Berkeley. Windows 2000 requiere que todas las aplicaciones que no sean NetBIOS utilicen WinSock si necesitan tener acceso a cualquier servicio TCP/IP. La especificacin de Windows Sockets tiene como objetivo proporcionar una nica API para que desarrolladores de aplicaciones puedan. Por otra parte, en el contexto de una determinada versin de Microsoft Windows, que define una interfaz binaria (ABI) de tal manera que una aplicacin escrita para la API de Windows Sockets puede trabajar con un protocolo de aplicacin conformes de cualquier proveedor de software de red. Esta especificacin define as las llamadas a las bibliotecas y la semntica asociada para que un desarrollador de aplicaciones las pueda programar y un proveedor de software de la red las pueda implementar.

El software de red que se ajusta a esta especificacin de Windows Sockets se considera "compatible con Windows Sockets". A los proveedores de interfaces que son "compatibles con Windows Sockets" se les conoce como "Windows Sockets Proveedores". Para ser compatible con Windows Sockets, un proveedor debe implementar el 100% esta especificacin de Windows Sockets. Las aplicaciones que son capaces de funcionar con cualquier aplicacin protocolo "compatible con Windows Sockets" sern consideradas como "interface de Windows Sockets" y sern referidas como "aplicaciones de Windows Sockets". En concreto, todas las implementaciones de Windows Sockets apoyan el stream (TCP) y datagram (UDP) sockets.

Instrumentos de comunicacin en Java

Java ofrece diferentes mecanismos de comunicacin entre procesos (IPC) para ayudar al programador a desarrollar aplicaciones en las que se requiere procesamiento cooperativo tanto a nivel local como remoto, tales mecanismos son: pipes, memoria compartida y sockets. Invocacin remota de mtodos (RMI) Es un mecanismo de expansin de RPC cuyo objetivo es dar soporte a sistemas orientado a objetos. La idea es tener objetos distribuidos. Para acceder al estado de un objeto slo se realiza a travs de mtodos definidos por un objeto interface. Un objeto ofrece mltiples interfaces. Una interface puede ser implementada por mltiples objetos. La invocacin remota de mtodos de Java es un modelo de objetos distribuidos, diseado especficamente para el lenguaje Java, por lo que mantiene la semntica del modelo de objetos locales de Java, facilitando de esta manera la implantacin y el uso de objetos distribuidos. En el modelo de objetos distribuidos de Java, un objeto remoto es aquel cuyos mtodos pueden ser invocados por objetos que se encuentran en una mquina virtual (MV) diferente. Los objetos de este tipo se describen por una o ms interfaces remotas que contienen la definicin de los mtodos del objeto que es posible invocar remotamente. A travs de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estar accesible a travs de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los mtodos proporcionados por el objeto. La invocacin se compone de los siguientes pasos: Encapsulado (marshalling) de los parmetros (utilizando la funcionalidad de serializacin de Java). Invocacin del mtodo (del cliente sobre el servidor). El invocador se queda esperando una respuesta.

Al terminar la ejecucin, el servidor serializa el valor de retorno (si lo hay) y lo enva al cliente. El cdigo cliente recibe la respuesta y contina como si la invocacin hubiera sido local.

Toda aplicacin RMI normalmente se descompone en 2 partes: Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque. Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

Bibliografa
[1].- Comunicacin entre procesos. 15/09/2011. Disponible en: http://es.wikipedia.org/wiki/Comunicaci%C3%B3n_entre_procesos [2].- Remote Procedure Call (RPC). 15/09/2011. Disponible en: http://searchsoa.techtarget.com/definition/Remote-Procedure-Call [3].- Inter-process comunication. 16/09/2011. Disponible en: http://en.wikipedia.org/wiki/Inter-process_communication [4].- Comunicaciones entre procesos. 16/09/2011. Disponible en: http://www.fismat.umich.mx/mn1/manual/node23.html [5].- Interprocess comunication mechanisms. 16/09/2011. Disponible en: http://tldp.org/LDP/tlk/ipc/ipc.html [6].- Tubera (informtica). 17/09/2011. Disponible en: http://es.wikipedia.org/wiki/Tuber%C3%ADa_%28inform%C3%A1tica%29 [7].- Mecanismos de Comunicaciones Interprocesos. 17/09/2011. Disponible en: http://gemini.udistrital.edu.co/comunidad/estudiantes/dguerrero/ipc/ipc-es.html [8].- Interprocess Comunications. 18/09/2011. Disponible en: http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx #base.using_windows_sockets_for_ipc [9].- Winsock. 18/09/2011. Disponible en: http://es.wikipedia.org/wiki/Winsock [10].- Windows Sockets. 18/09/2011. Disponible en: http://www.sockets.com/winsock.htm [11].- Oscar Alejandro Gonzlez Bustamante. Java avanzado. 18/09/2011. Disponible en: http://www.cic.ipn.mx/anterior/oldsite/ogonzalez/Cursos/java/descarga/cursojavaavan zado/redes/Redes.pdf [12].- Java Remote Method Invocation. 21/09/2011. Disponible en: http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation