Comunicación de procesos

La perspectiva de la comunicación

Conceptos básicos de la comunicación

Técnicas de comunicación

Modelos de comunicación

TCP/IP Suite

Direcciones

Sockets

Comportamiento de bloqueo y no bloqueo de sockets

Detección y corrección de errores

Protocolos para aplicaciones específicas

Comunicación con lógica de negocio

Técnicas para facilitar la localización entre componentes

Requerimientos de transparencia para la comunicación

Unidireccional

Petición y respuesta

Bidireccional

Metodologías de direccionamiento

Llamada de procedimiento remoto (RPC)

Invocación de método remoto (RMI)

Unicast

Broadcast

Multicast

Anycast

OSI

TCP/IP

La IP

El TCP

La conexión TCP

El UDP

Comparación TCP y UDP

Escoger entre TCP y UDP

Herárquica vs plana

Capa de enlace

Capa de red

Dirección IP

Dirección IPV4

Dirección IPV6

Traducción entre IP y MAC

Capa de transporte

Puertos conocidos

API

API: UDP

API: TCP

Unión

Bloqueo y no bloqueo

Manejo de no bloqueo

Punto muerto de comunicación

Uno de los dos procesos debe poder recibir un mensaje

El otro debe poder enviar un mensaje

El que envía debe saber la dirección del que recibe

Debe haber un sistema de transmición al que ambos se conecten

Tiene aplicaciones limitadas

Las comunicaciones siempre son mas complejas por:

Los procesos no estan en locaciones conocidas; algunos procesos solo se ejecutan cuando se lo pide; puede que muchos procesos esten involucrados; la comunicación casi siempre es bidireccional; aspectos de la aplicación específica; los sistemas son dinámicos; en la red se pueden perder mensajes

Mecanismo más básico para la comunicación entre una pareja de procesos

Un proceso realiza una petición a otro proceso, este realiza la computación necesaria y devuelve un mensaje con la información al proceso que la pidió

En muchos sistemas se necesita que la información pase de un proceso a otro y viceversa

E-commerce, banco en línea, tienda en línea y juegos multijugador

Solo el proceso al que se le envía la información puede ver lo que se le envió

Un solo mensaje es enviado a todos los procesos

Un mensaje es enviado a un grupo de procesos y el que envía no sabe cuantos procesos recibieron el mensaje

Se puede lograr con el uso del mecanismo broadcast y UDP

Un mensaje es enviado a un solo recipiente de un grupo de procesos

Se puede lograr con UDP

Se puede lograr con TCP

Los procedimientos que toman papel están en diferentes programas

Permite que la localización de los procesos se haga automaticamente

Muy potente para la creación de aplicaciones modulares basadas en componentes

Es la versión orientada a objetos de RPC, pues se invoca a un metodo remoto

Java lo hizo primero con java interfaces

Es necesario porque asi las interfaces del lado del cliente se compilan de manera independiente del servidor

Este modelo consta de 7 capas en donde cada una tiene su función y no le importa las del resto de capas

1. Física: transmisión de bits por link

2. Enlace de datos: Comunicación entre dispositivos

3. Red: Comunicación entre computadoras por envio de paquetes

4. Transporte: Comunicación entre procesos

5. Sesión: Gestión del flujo de la comunicación

6. Presentación: Conversión de datos enre plataformas y formatos

7. Aplicación: Protocolo para necesidades de aplicaciones

Este modelo consta de 4 capas que comprimen las 7 capas del modelo OSI

1. Enlace: Transmisión de bits por un medio (100BASE-TX, Ethernet)

2. Internet: Envío de paquetes (IP, ICMP)

3. Transporte: Por segmento (TCP, UDP)

4. Aplicación: Gestión de mensajes y de datos (FTP, NTP, HTTP, SMTP, SSH)

Protocolo de la capa de red

Se utilizan dos versiones: IPV4 e IPV6

Las dos con 32 bits de largo pero con diferentes bits en las direcciones de envio y de destino

IPV4: 32 bits dirección de envío y de destino

IPV6: 128 bits dirección de envío y de destino

Protocolo orientado a la conexión

Es una comunicación unicast

Tiene 6 banderas: URG, ACK, PSH, RST, SYN y FIN

Es preparada con la creación de sockets en cada componente y se usa: escuchar, conectar y aceptar

Primero envía un SYN, del otro lado se envía un ACK y otro SYN y por último del otro lado se vuelve envíar un ACK

Protocolo en el que no se establece una conexión lógica

No es necesario que sea unicast, pues puede ser broadcast

No necesita un saludo de manos como TCP, es de baja latencia y utiliza menos ancho de banda

Protocolos que utilizan UDP: IFTP, DNS, SNMP

TCP: los datos son segmentos, esta orientado a la conexión donde el saludo de mano es necesario, con alta fiabilidad, con control de flujo, con control de congestión, solo soporta unicast, con números de secuencia, con reordenamiento y sin duplicado, con manejo de mensajes, no se mantiene datos en el buffer, y buena eficiencia

UDP: los datos son segmentos, no mantiene una conexión, no es muy fiable, no tiene control de flujo ni de congestión, soporta más comunicación que unicast, no lleva números de secuencia, no se ordenan los mensajes y pueden llegar duplicados, no se manejan mensajes, mantiene solo datos del siguiente pedido en el buffer, y es más eficiente que TCP

Todo depende de las necesidades de la conexión

Si se necesita fiabilidad, llevar un registro de la comunicación y usar un protocolo de más capas, entonces se escoge TCP

Si se necesita comunicación broadcast, menos latencia, menos uso de ancho de banda, transmisión en tiempo real y si la comunicación es unidireccional entonces se escoge UDP

La dirección plana no tiene un estructura ni patrón

La dirección jerárquica tiene una estructura o patrón como un número de teléfono el cual tiene código de área, código internacional y el número en sí

Solo debe identificar los dispositivos físicos por el uso de la dirección MAC

Existen dos versiones debido a que la demanda aumentó de una forma muy rápida (IPV4 e IPV6)

Tiene ua extención de 4 bytes y consta de 4 números decimales

Cada número no puede ser mayor que 254, pues la dirección 255.255.255.255 es la máscara de red

Tiene una extención de 16 bytes y consta de 8 números hexadecimales

El ARP traduce la IP en una dirección MAC

Funciona por medio de puertos

Al enviar algo a una dirección IP se ve el puerto y se puede saber que proceso es el destinatario

5 Remote Job Entry

7 Echo

20 File Transfer Protocol (FTP) data

21 File Transfer Protocol (FTP) command

23 Telnet

25 Simple Mail Transfer Protocol (SMTP)

53 Domain Name System (DNS)

69 Trivial File Transfer Protocol (TFTP)

80 HyperText Transfer Protocol (HTTP)

88 Kerberos (authentication system)

110 Post Office Protocol version 3 (POP3)

111 ONC Remote Procedure Call (SUN RPC)

115 Simple File Transfer Protocol (SFTP)118 Structured Query Language (SQL) services

123 Network Time Protocol (NTP)

264 Border Gateway Multicast Protocol (BGMP), routing

389 Lightweight Directory Access Protocol (LDAP)

513 Rlogin (remote access)

520 Routing Information Protocol (RIP)

521 Routing Information Protocol Next Generation (RIPng)

530 Remote Procedure Call (RPC)

546 Dynamic Host Configuration Protocol v6 Client (DHCPv6)

547 Dynamic Host Configuration Protocol v6 Server (DHCPv6)

944 Network File Service (NFS)

976 Network File Service (NFS) over IPv6

2483 Oracle database service

3306 MySQL database system

3690 Subversion (SVN) version control system

3702 Web Services Dynamic Discovery (WS-Discovery)

5353 Multicast DNS (mDNS)

8080 HTTP (alternate), e.g. when running a webserver as a non-root user

8332 Bitcoin JSON-RPC server

Librería usada por programadores para usar los protocolos de comunicación TCP y UDP desde alguna aplicación

Para usarla de manera correcta es importante conocer el nivel bajo de las comunicaciones

Existe una secuencia la cual se sigue para usar el protocolo UDP desde la API de Socket

Existe una secuencia la cual se sigue para usar el protocolo TCP desde la API de Socket

Se crea un socket, se mapea el proceso al puerto, se usa el sendto para enviar datos a otro proceso, se usa recvfrom para recibir datos y por último closeocket para cerrar el socket en uso

Se crea un socket, se mapea el proceso al puerto, se escucha, conecta y acepta para preparar una conexión, se usa send para enviar información, recv para recibir información, shutdown para cerrar la conexión y por último, closesocket para cerrar el socket en uso

Es una asociación entre un proceso y un puerto

Es necesario el uso de los puertos porque no se sabe siempre que PID tendra un proceso por lo que la información no le puede llegar directamente

Afecta la forma en la que el sistema operativo trata al socket que algún proceso quiera usar pero que no va a poder terminar inmediatamente

Si no se bloquea pueden darse errores de que no se terminó lo que se esperaba

Si se obtiene un error de codigo WOULD_BLOCK se prepara un timer para que la aplicación lo vuelva a intentar despues de un tiempo y que pueda completar todos sus procesos

Ocurre cuando un grupo de procesos se queda esperando recursos que estan siendo utilizados por otros procesos y no consiguen hacer ningún progreso porque nunca se sueltan los recursos necesarios

Los protocolos comunicación esta diseñados para poder detectar errores en la transmisión

Para la corrección de errores son necesarios códigos FEC los cuales son importantes cuando los mensajes son de mucho valor

En estos es necesario considerar el número de bits de error que el código podrá corregir

Para poder corregirlos es necesario agregar bits los cuales son redundantes

Es necesario cuando una aplicación se comunica directamente en la capa de transporte

Este no es lo mismo que un protocolo de capas de aplicación, pues estos son hechos para protocolos estándares de comunicación

Este se construirá en las facilidades brindadas por el protocolo de comunicación subyasente

Cuando se desarrolla una aplicación distribuida es necesario integrar las comunicaciones con la lógica del negocio

Esto aumenta la complejidad al desarrollo pero no se debe comprometer la calidad e la lógica del negocio diseñada e implementada

Se suelen desarrollar las dos partes de forma separada hasta que esten en una forma más madura y ahí juntarlas

El que localiza suele ser el cliente, pues es el que envía las peticiones al servidor y este contesta

Para que el componente activo encuentre al pasivo se suelen usar algunas técnicas

Propaganda de servicio: se envia un mensaje broadcast informando que ese servicio está ahí

Broadcast local: se envía un mensaje broadcast preguntando donde esta el servicio

Programación dura: se evita porque solo se preselecciona una direccon IP

Preguntar al usuario: se le pide al usuario ingresar los detalles de la dirección del servidor

Encontrar archivo: se lee un archivo donde se encuentra la información del servidor

Servicio de nombre: mantiene en una base de datos los servicios y sus locaciones

Middleware: colección de servicios entre software y plataformas para proporcionar transparencia

Muchas formas de transparencia son necesarias al hablar desde el punto de vista de la comunicación

Transparencia de acceso: no debe ser visible para la aplicación el lazo entre la red y el dispositivo

Transparencia de localización: los recursos deben ser localizados de manera automática

Transparencia de red: se trata de esconder las características físicas de la red

Transparencia de distribución: se debe esconder la separación entre componentes

Transparencia de fallos: si los datos no llegan, es necesario que automáticamente sean reenviados

Transparencia de escala: debe ser eficiente en términos del uso de recursos de la red

Glosario

Protocolo: Reglas para un sistema de comunicación particular.

Unicast: Un mensaje es enviado a un solo proceso.

Broadcast: Un mensaje es enviado a todos los procesos.

Multicast: Un mensaje es enviado a un grupo de procesos.

Anycast: Un mensaje es enviado a un solo proceso de un grupo de procesos.

RPC: Llamada de procesamiento remoto.

RMI: Invocación de método remoto.

SYN: Mensaje de solicitud de sincronización.

ACK: Confirmación de que se recibió un SYN.

IFTP: Protocolo de transferencia de archivos triviales.

DNS: Sistema de nombre de dominio.

SNMP: Protocolo de manejo de red simple.

ARP: Protocolo de resolución de direcciones.

API: Interfaz de programación de aplicación.

Paul Alejandro Bonilla Cevallos

Referencias

Anthony, R. (2016). Systems Programming: Designing and Developing Distributed Applica ons. Morgan Kaufmann Publishers. Capítulo 3 (pág 108 – pág 201)

Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. (2008). Procesos. Recuperado de http://cs.uns.edu.ar/~ldm/data/so/apuntes/03-procesos.pdf

Rosales, F. (2012). SISTEMAS OPERATIVOS SINCRONIZACIÓN Y COMUNICACIÓN ENTRE PROCESOS. Recuperado de Universidad Politecnica de España https://www.cartagena99.com/recursos/alumnos/apuntes/sincronizacion-y-comunicacion.pdf