Modos de direccionamiento de los procesos de nuestros clientes

Como vimos en el modelo ISO son necesarias siete capas con el consecuente

encabezado de cada una de ellas en el mensaje, cosa que analizar y construir estos

encabezados lleva tiempo. Si bien esto en las redes de área amplia no es significante,

si lo es en una LAN.

Para el caso CLIENTE-SERVIDOR, se utiliza un protocolo solicitud-respuesta

(request/reply), en vez del OSI (TCP/IP). El cliente envía un request pidiendo un servicio

y el server lo recibe, realiza el trabajo y devuelve los datos pedidos o un código de

error. Lo principal es su sencillez y su eficiencia.

Sencillez : No se tiene que establecer ninguna conexión sino hasta que esta se

utilice, y el mensaje de respuesta sirve como agradecimiento a la solicitud.

Eficiencia : Las capas del protocolo son menos y por lo tanto mas eficiente, si

todas las máquinas fuesen idénticas, solo se necesitarían tres niveles: La Física, La de

Enlace (ambas manejadas por Hardware), la de Solicitud/Respuesta (en lugar de la de

sesión).

Las capas 3 y 4 no se utilizan pues no es necesario el ruteo ni tampoco se establecen

conexiones. No existe administración de la sesión puesto que no existe y tampoco

se utilizan las capas superiores.

Debido a que esta estructura es sencilla, se pueden reducir los servicios de

comunicación que presta el micronúcleo a dos llamadas a sistema:

- SEND (dest, &mptr): envía el mensaje que apunta mptr al proceso destino y

bloquea al proceso llamador hasta que se envíe el mensaje;

- RECEIVE (addr, &mptr): que hace que se bloquee el que realizó la llamada,

hasta que llegue un mensaje, cuando llega este se copia en el buffer que apunta

mptr y quien hizo la llamada se desbloquea. El parámetro addr, determina la

dirección a la cual escucha el receptor.

21.2. - Direccionamiento

Hay varios métodos para el direccionamiento de los procesos:

1) Integrar machine.number al código del proceso cliente : machine indica el

número de máquina dentro de la red y number, el número de proceso dentro de

esa máquina. Pero este método no posee la transparencia que se busca ya que

se está identificando que existen varias máquinas trabajando. A parte si se descompone

esa máquina (server) se pierde el servicio pues los programas compilados

tienen integrado ese número de máquina para ese servicio. Una

variación de este esquema, utiliza machine.local_id.

2) Dejar que los procesos elijan direcciones al azar y localizarlos mediante

21-1

transmisiones : En una LAN que soporte transmisiones, el emisor puede transmitir

un paquete especial de localización con la dirección del proceso destino,

todos los núcleos de las máquinas en la red reciben este mensaje y verifican si

la dirección es la suya; en caso de que lo sea, regresa un mensaje "aquí estoy"

con su dirección en la red (número de máquina). El núcleo emisor utiliza entonces

esa dirección y la captura para uso posterior. Si bien esto cumple con las

premisas, genera una carga adicional en el sistema.

3) Generar un servidor de nombres : Cada vez que se ejecute un cliente en su

primer intento por utilizar un servidor, el cliente envía una solicitud al servidor de

nombres (nombre en ASCII) para pedirle el número de la máquina donde se

localiza el servidor. Una vez obtenida la dirección se puede enviar la solicitud

de manera directa. El problema de este método es que es un componente

centralizado y si bien se puede duplicar, presenta problemas en el mantenimiento

de la consistencia.

Un método totalmente distinto, utiliza un hardware especial, dejando que los

procesos elijan su dirección en forma aleatoria.

Sin embargo en vez de localizarlo mediante transmisiones en toda la red, los

chip de interfase de la red se diseñan de modo que permitan a los procesos almacenar

direcciones de procesos en ellos. Entonces las tramas usarían direcciones de procesos

en vez de direcciones de máquinas. Al recibir cada trama, el chip de interfase de la red

solo tendría que examinar la trama para saber si el proceso destino se encuentra en

esa máquina. En caso afirmativo, la aceptaría, de lo contrario no.

21.3. - PRIMITIVAS BLOQUEANTES vs NO BLOQUEANTES

21.3.1. - SEND BLOQUEANTES (Primitivas sincrónicas)

Mientras que se envía el mensaje el proceso emisor se bloquea, de manera

análoga el RECEIVE. En algunos casos el receptor puede especificar de quiénes quiere

recibir el mensaje y queda bloqueado hasta que reciba el mensaje de él. La CPU está

muerta, desperdiciando tiempo.

21.3.2. - SEND NO BLOQUEANTES (Primitivas asincrónicas)

Regresa de inmediato el control a quien hizo la llamada (send) antes de enviar

el mensaje. La ventaja de esto es que puede trabajar en forma paralela con el envío del

mensaje. Sin embargo existe la desventaja de no poder usar el buffer hasta que no se

envíe la totalidad del mensaje. Una forma de solucionar esto es que el S.O. copie este

buffer a una área propia y luego envíe el mensaje, liberando el buffer. Aquí se desperdicia

tiempo en la copia.

21.3.3. - SEND SIN BLOQUEO CON INTERRUPCIÓN

El emisor es interrumpido cuando el mensaje fue enviado y el buffer está disponible.

No se requiere de una copia, lo que ahorra tiempo, pero las interrupciones a

nivel usuario dificultan mucho la programación. Maximiza el paralelismo.

21-2

En condiciones normales la primera opción es la mejor, no maximiza el

paralelismo pero es fácil de comprender e implantar y no requiere el manejo del buffer

en el núcleo.

...