La comunicación entre procesos (comúnmente IPC, del inglés Inter-Process Communication) es una función básica de los sistemas operativos. Los procesos pueden comunicarse entre sí a través de compartir espacios de memoria, ya sean variables compartidas o buffers, o a través 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 través de un sistema de bajo nivel de paso de mensajes que ofrece la red subyacente.
La comunicación se establece
siguiendo una serie de reglas (protocolos de comunicación).
Los protocolos desarrollados
para internet son los mayormente usados: IP (capa de red),
protocolo de control de transmisión (capa de transporte)
y protocolo de transferencia de archivos , protocolo de transferencia
de hipertexto (capa de aplicación).
Los procesos pueden estar
ejecutándose en una o más computadoras conectadas a una red. Las técnicas
de IPC están divididas dentro de métodos para: paso de mensajes,
sincronización, memoria compartida y llamadas de procediemientos remotos (RPC).
El método de IPC usado puede variar
dependiendo del ancho de banda y latencia (el tiempo desde el pedido de
información y el comienzo del envío de la misma) de la comunicación entre
procesos, y del tipo de datos que están siendo comunicados. El sistema
operativo provee mínimamente dos primitivas, enviar y recibir, normalmente
llamadas send y receive. Asimismo, debe implementarse un enlace
de comunicación entre los procesos de la comunicación. Este enlace puede ser
unidireccional o multidireccional según permita la comunicación en solo uno o
en varios sentidos.
RPC
(Remote Procedure Call / llamada a
un procedimiento remoto) Permitir que los programas
realicen llamadas a funciones
localizadas en otras máquinas. Los programadores no se tienen que preocupar por
los detalles de la programación de la red. Conceptualmente simple.
Desde el punto de vista de un programador
la llamada a una función remota es y funciona de la misma manera que lo
haría si la llamada fuese local. En este sentido, se logra transparencia.
Cada función pasa a tener dos
partes: cliente, la máquina local donde se implementa la interface
(prototipo de una función) para invocar las funciones remotas. Servidor,
implementación de las funciones propiamente dichas.
-Paso de parámetros
No debería de existir ningún
problema si dos máquinas son homogéneas, sin embargo la realidad no suele ser
ésta. Pueden surgir problemas de diferentes codificación de
caracteres (ej.: mainframe IBM: EBCDIC, IBM PC: ASCII) o diferentes tipos
de ordenación de bytes
(ej.: Intel: little endian, Sun SPARC: big endian).
Como solución a estos problemas es
importante lograr un acuerdo del protocolo usado.
La parte encargada de generar los
mensajes no debe de presuponer el uso de un lenguaje de
programación específico
Comunicación orientada a mensajes
Las comunicaciones RPC se basan en
la idea que el receptor está operativo para poder invocar una cierta
función, no podemos suponer que el receptor siempre estará operativo y
esperando a comunicarse. La solución es definir la comunicación en término de
paso de mensajes.
Mensajes momentáneos vs. mensajes
persistentes
Momentáneos: no soportan el envío
de mensajes persistentes.
Sockets
Sistema fuertemente acoplado a las
redes TCP/IP
Sockets API:
1.
socket: crea una nueva comunicación.
2. bind:
añade la dirección local al socket.
3. listen:
queda en espera de conexiones.
4. accept: queda
bloqueado hasta la llegada de un pedido de conexión.
5. connect:
pedido de establecimiento de conexión.
6. send: enviar
datos por la conexión.
7. receive:
recibir datos por la conexión.
8. close:
desvincula el socket la dirección local.
