Arquitectura: organización del middleware:

- Wrappers: Uso de legado para construir un middleware.

Problema: Es muy probable que la interfaz que ofrece un componente heredado no sea adecuada
para todas las aplicaciones.
Solución: Un envoltorio (wrapper) o adaptador ofrece una interfaz aceptable para una aplicación
cliente. Sus funciones se transforman en las disponibles en el componente.

Wrapper, complejidad con N aplicaciones, bróker, complejidad con N, aplicación wrapper broker
Organización de Middleware:
Los wrappers: uso de delegado para construir un middleware.
problemas
Aplicaciones sueltas, ofrecen una interfaz que no se puede integrar con otra. La solución es
desarrollar una especie de envoltorios o wrappers.
Aplicación 1 y 2 se pueden comunicar gracias a los wraper, atraves de estas envolturas se puede
hacer para comunicar entre aplicaciones.
Otra forma es usando un bróker, donde los wrapers apuntan a una sola aplicación, en lugar de que
ellas se conecten entre si, se comunicaran por un Broker, si se quieren comunicar las aplicaciones
usaran el bróker.

Interceptores: El middleware contiene soluciones que son buenas para la mayoría de las aplicaciones
-> es posible que desee adaptar su comportamiento para aplicaciones específicas.
Interceptar el flujo habitual de control:
Interceptores: Permiten desarrollar un middleware adaptable, el middleware permite tener
interfaces similares para diferentes aplicaciones, si dos aplicaciones se comunican por middleware,
entonces la comunicación ente la aplicación y el middleware, se intercepta.
Hay algunas aplicaciones que necesitan un comportamiento especial, pa eso usamos
interceptores, si una aplicación se comunica con el middleware y si quiero adaptarlo, la
comunicación entre la aplicación y el middleware, se intercepta y luego se modifica.

Arquitectura de sistemas:
Arquitectura centralizadas: Modelo cliente-servidor básico.
Características:

 Hay procesos que ofrecen servicios (servidores)

 Hay procesos que utilizan servicios (clientes)
 Los clientes y servidores pueden estar en diferentes maquinas
 Los clientes siguen el modelo de solicitud / respuesta con respecto al uso de los servidores.

Arquitecturas centralizadas: Arquitecturas multiniveles.

Algunas organizaciones tradicionales
 De un solo nivel: configuración terminal tonto / mainframe
 Configuración de dos niveles: clientes / servidor único
 Tres niveles: cada capa en una maquina separada
1. ArquitecC: AR multinivel:
 S

Se tiene un servidor potente (mainframe) llamado terminal tonto, se accede a ellos a través de
terminales, físicos o lógicos, ese era una estación de trabajo, pero todo el proceso se hacía en el
servidor, luego salieron emuladores de terminal, por ellos se puede hacer un telnet y mostrara una
pantalla donde usaras el servidor. AS400 RS1000 todo esta en el servidor, una sola capa.
En empresas donde el numero de empleados es alto, 5000 empleados y se necesita 5000 destoks o
equipos, en total 25 000 000 millones de dólares, por ello, usan un esquema tipo mainframe, donde
tienen un disco y memoria pequeña, dando un espacio virtual, THIN CLIENT es similar al mainframe
Configuraciones tradicionales de dos niveles:

- Ser cliente y servidor al mismo tiempo

Comunicación, el cliente realiza una petición al servidor de aplicación que solicita la información
al servidor BD, se devuelve la información se espera la información se devuelve la respuesta,
todo esto es un tiempo de espera de respuesta.

Arquitecturas descentralizadas: Sistema peer to peer:

Organizaciones alternativas:
- Distribución Vertical: Proviene de dividir las aplicaciones distribuidas en tres capas lógicas y
ejecutar los componentes de cada capa en un servidor (maquina) diferente.
- Distribución horizontal: Un cliente o servidor puede dividirse físicamente en partes
lógicamente equivalentes, pero cada parte operando en su propia parte del conjunto de
datos completo.
- Arquitecturas peer-to-peet: Los procesos son todos iguales: Las funciones que deben
llevarse a cabo están representadas por cada proceso, entonces cada proceso actuara como
cliente y como servidor al mismo tiempo (es decir, como sirvientes).
Arquitectura descentralizada: Sistemas p2p estructurados:
Esencia:
Utilice un índice sin semántica: cada ítem de datos está asociado de forma únicas con una clave, que
a su vez se utiliza como índices.
Práctica común: use como clave una función hash. Clave (ítem de datos) = hash (valor del ítem de
datos): El sistema P2P ahora es responsable de almacenar pares (clave, valor).
Ejemplo simple: hipercubo
Nodo existente

Arquitectura descentralizada: sistema p2p estructurado ejemplo CHORD:

Principio:

 Los nodos están organizados lógicamente en un anillo. Cada nodo tiene un identificador de
m bits
 Cada item de datos se convierte en una clave de m bits
 El item de datos con la clave k se almacena en el nodo con el identificador más pequeño
id>=k, llamado sucesor de la clave k.
 El anillo se extiende con varios enlaces “atajos” a otros nodos.
ILUCTRACION: CHORD
- Considere la organización de varios nodos en un anillo lógico.
 A cada nodo se le asigna un identificador aleatorio de m bits
 A Cada entidad se le asigna una clave de m bits única.
 La entidad con la clave k cae bajo la jurisdicción del nodo con el id mas pequeño id>= k
(llamado su sucesor succ(k))
NO SOLUCION: Deje que cada nodo realiza un seguimiento de su vecino y comience la búsqueda
lineal a lo largo del anillo.
NOTACION: Hablaremos del noso p ya que el nodo tiene el identificador p.
Chord finger tablets

 Cada nodo p mantiene finger table FTp[] con a lo mas m entradas:

FTp[i]=succ(p+2elevado(i-1))
Nota: La i-esima apunta al primer nodo que sigue a p en almenos 2 elevado (i-1).
 Para buscar una clave k, el nodo p reenvía la solicitud al nodo 1 con el índice j satisfaciendo.
q = FTp[j]<= k < FTp[j+1]
 Si p < k < FTp[1], la solicitud Tambien se reenvía a FTp[1]

Arquitectura descentralizada: p2p no estructurado.

 Esencia: Cada nodo mantiene una lista ad hoc de vecinos. La superposición resultante se
asemeja a un grafico aleatorio: un borde (u.v) existe solo con una cierta probabilidad
P[(u,v)]
Búsqueda:
 Inundación: el nodo emisor u pasa la solicitud de d a todos los vecinos. La solicitud se
ignora cuando el nodo receptor la ha visto antes. De lo contrario, v busca localmente d
 (recursivamente). Puede estar limitado por un tiempo de vida: un número máximo de
saltos.
 Random Walk: El nodo emisor u pasa la solicitud de d al vecino elegido al azar, v. Si v no
tiene d, reenvía la solicitud a uno de sus vecinos elegidos al azar, y así sucesivamente

P2P no estructurado inundación vs random walk

Modelo: Suponga N nodos y que cada item de datos se replica en r nodos elegidos al azar.
Random walk: P[k] probabilidad de que el item se encuentre después de k intentos:

S(“tamaño de busqueda”) es el numero esperado de nodos que deben ser analizados

Inundación:

 Inuncadion de “d” vecinos elegidos al azar

 Después de k pasos, se habrá alcanzado algo de R(k)= d.(d-1)elevado k-1 (asumiendo que k
es pequeño)
 Con la fracción r/N nodos que tienen el item de datos, si r/N . R(k) >= 1, habremos
encontrado el item de datos.
Comparación:

 Si r/N = 0.001, entonces S=1000

 Con inundación y d = 10; k=4, contactamos 7290 nodos,
 Random walk es más eficiente en la comunicación, pero puede tardar más en encontrar
resultados.

Arquitecturas descentralizadas: P2P no estructurado-Redes Superpunto

Esencia: A veces es Sensato romper la simetría en red peer-to-peer “puras ” o simétricas:

 Al buscar en sistema P2P no estructurados, tener servidores de índices, mejora el

rendimiento
 Decidir donde almacenar los datos a menudo se puede hacer de manera mas eficiente a
través de brokers.
Punto regular, red superpunto, super punto, Organización jerárquica de nodos en una red de
superpunto.
Arquitectura de sistemas- organizaciones descentralizadas:
Sistemas P2P- Ejemplo: Funcionamiento principal de Skype: A quiere ponerse en contacto
con B.
- Tanto A como B están en la internet pública.
 Se establece una conexión TCP entre A y B para paquetes de control.
 La llamada real se realiza mediante paquetes UDP entre puertos negociados.
- A opera detrás de un firewall, mientras que B esta en la internet publica.
 A establece una conexión TCP (para paquetes de control) a un superpunto S
 S establece una conexión TCP (Para retransmitir paquetes de control) a B
 La llamada real se realiza a través de UDP y directamente entre A y B
- Tanto A como B operan detrás de un firewall.
 A se conecta a un superpunto S en línea a través de TCP.
 S configura la conexión TCP a B
 Para la llamada real, se contacta con otro superponto para que actúe como retransmisor R:
 A establece una conexión con R, y también lo hará B.
 Todo el trafico de voz se reenvía a través de las dos conexiones TCP y a través de R.

Arquitecturas hibridas: Sistema de servidores al borde:

Esencia: Sistemas implementados en internet donde los servidores se colocan en el borde de la red:
El limite entre las redes empresariales y la internet real.
visualización de internet como si consintiera en una colección de servidores de borde o laterales.
(ISP, cliente, proveedor de contenido, ISP, red empresarial, internet principal, servidor lateral)

Arquitecturas hídricas: Colaboración- el caso Bittorrent

- Principio: buscar un archivo F
 Búsqueda de un archivo en un directorio global devuelve un archivo trorrent.
 El archivo Torrent contiene una referencia al rastreador: un servidor que mantiene una
cuenta precisa de los nodos activos que tienen (fragmentos de) F.
 P puede unirse al enjambre, obtener un trozo gratis y luego intercambiar una copia de esos
trozos por otro con un par W también en el enjambre.
 Nodo cliente, salida de K en N nodos(una pagina web, BitTorrent servidor web referencia a uns
errvidor de archivos archivo Torrent para F, servidor de archivo, referencia al rastrador lista de
nodos que almacenan F, nodo 1 nodo nodo N)

colaboración- BitTorrent bajo el capo:

Algunos detalles esenciales.

 Un rastreador para el archivo F devuelve el conjunto de sus procesos de descarga: el

enjambre actual
 A se comunica solo con subconjunto del enjambre: el conjunto vecino NA
 Si B pertenece NA entonces también A pertenece NB
 El rastreador actualiza periódicamente los conjuntos de vecinos.
Bloques de intercambio

 Un archivo se divide en partes del mismo tamaño (normalmente cada una de de 256 KB)
 Los pares intercambian bloques de piezas, normalmente unos 16 KB.
 A puede cargar bloques d de la pieza D, solo si tiene la pieza D.
 El vecino B pertenece al conjunto potencial PA de A, si B tiene un bloque que A necesita.
 Si B pernete a PA y A pertenece PB: A y B están en una posición en la que pueden
intercambiar un bloque
Arquitectura de sistemas- Fases BitTorrent
Arquitecrua hibridas: Colaboración- BitTorrent bajo el capó.
Fase Bootstrap o fase arranque: A caba de recibir su primera pieza (a través de un desenganche
optimista: un nodo de NA proporciona desinteresadamente los bloques de una pieza para iniciar un
nodo recién llegado).
Fase de negociación: |PA| > o: siempre hay (en principio un par con quien A puede negociar).
Ultima fase de descarga:
|PA|= o: A depende de los compañeros recién llegados en NA para obtener las ultimas piezas
faltantes. NA solo puede cambiar a través del rastreador.
RESUMEN:

 Los sistemas distribuidos se pueden organizar de muchas maneras. Podemos hacer una
distinción entre arquitectura de software y arquitectura de sistema. Este último considera
dónde se colocan los componentes que constituyen un sistema distribuido en las distintas
máquinas. El primero está más preocupado por la organización lógica del software: cómo
interactúan los componentes, de qué manera pueden estructurarse, cómo pueden hacerse
independientes, etc.
 Una palabra clave cuando se habla de arquitecturas es el estilo arquitectónico. Un estilo refleja el
principio básico que se sigue al organizar la interacción entre los componentes de
software que comprenden un sistema distribuido. Los estilos importantes incluyen
basados en capas, estilos basados en objetos, estilos basados en recursos y estilos en los
que la gestión de eventos es prominente.
 Hay muchas organizaciones diferentes de sistemas distribuidos. Una clase importante es
donde las máquinas se dividen en clientes y servidores. Un cliente envía una solicitud a un
servidor, que luego producirá un resultado que se devuelve al cliente. La arquitectura
cliente- servidor refleja la forma tradicional de modularizar el software en el que un
módulo llama a las funciones disponibles en otro módulo. Al colocar diferentes
componentes en diferentes máquinas, obtenemos una distribución física natural de las
funciones en una colección de máquinas.
 Las arquitecturas cliente-servidor a menudo están altamente centralizadas. En las
arquitecturas descentralizadas, a menudo vemos un papel igual desempeñado por los
procesos que constituyen un sistema distribuido, también conocido como sistemas peer-
to-peer (punto a punto).
 En los sistemas punto a punto, los procesos se organizan en una red superpuesta, que es
una red lógica en la que cada proceso tiene una lista local de otros pares con los que puede
comunicarse. La red superpuesta se puede estructurar, en cuyo caso se pueden
implementar esquemas deterministas para enrutar mensajes entre procesos.
 En redes no estructuradas, la lista de pares es más o menos aleatoria, lo que implica que
los algoritmos de búsqueda deben implementarse para localizar datos u otros procesos.
  En arquitecturas híbridas, se combinan elementos de organizaciones centralizadas y
descentralizadas. Un componente centralizado a menudo se usa para manejar solicitudes
iniciales, por ejemplo, para redirigir a un cliente a un servidor de réplica, que, a su vez,
puede ser parte de una red punto a punto, como es el caso de los sistemas basados en
BitTorrent.

SEMANA 7: APPINVENTOR
SEMANA 8:
Programacion de hilos:
1. Crear clase que implemente la interfaz runnable (método run).
2. Escribir el código de la tarea dentro del método run.
3. Instanciar la clase creada y almacenar la instancia en variable de tipo runnable
4. Crear instancia de la clase Thrread pasando como parámetro al constructor de Thread el
objeto runnable anterior
5. Poner en marcha el hilo de ejecución con el método Start() de la clase Theard
Arquitectura de un servidor multihilo:

• Considere un servidor web

Cree una serie de hilos, y para cada hilo haga
 obtener el mensaje de red del cliente
 obtener datos de URL del disco
 enviar datos a través de la red
• ¿Qué ganamos?
Proceso de un hilo y multihilo:

• ¿Cómo puede este código aprovechar 2 subprocesos?

for(k = 0; k < n; k++)
a[k] = b[k] * c[k] + d[k] * e[k];

• Reescribe este fragmento de como:

do_mult(l, m) {
for(k = l; k < m; k++)
a[k] = b[k] * c[k] + d[k] * e[k];
}
main() {
CreateThread(do_mult, 0, n/2);
CreateThread(do_mult, n/2, n);
}
• ¿Qué ganamos?
INTRODUCCION A LOS HILOS:
Idea básica
Construimos procesadores virtuales en software, además de procesadores físicos:
Procesador: Proporciona un conjunto de instrucciones junto con la capacidad de ejecutar
automáticamente una serie de esas instrucciones.
Hilo: Un procesador de software mínimo en cuyo contexto se pueden ejecutar una serie de
instrucciones. Guardar un contexto de hilo implica detener la ejecución actual y guardar todos los
datos necesarios para continuar la ejecución en una etapa posterior.
Proceso: un procesador de software en cuyo contexto uno o más hilos pueden ser ejecutados.
Ejecutar un hilo, significa ejecutar una serie de instrucciones en el contexto de ese hilo.
Cambio de contexto:
CONTEXTO:
Contexto del procesador: la colección mínima de valores almacenados en los registros de un
procesador utilizado para la ejecución de una serie de instrucciones (por ejemplo, puntero de pila,
registros de direccionamiento, contador de programa)
Contexto del hilo: La colección mínima de valores almacenados en registros y memoria, utilizada
para la ejecución de una serie de instrucciones (es decir, procesador, contexto, estado).
Contexto del proceso: la colección mínima de valores almacenados en registros y memoria,
utilizada para la ejecución de UN hilo (es decir, contexto de hilo, pero ahora también al menos
valores de la unidad de administración de memoria (MMU).

Observaciones:
- Los hilos comparten el mismo espacio de direcciones. El cambio de contexto de un hilo
puede ser realizado completamente independiente del sistema operativo.
- El cambio de contexto de un proceso es generalmente (algo) más costoso ya que implica
poner el sistema operativo en el bucle, es decir, atrapar al kernel.
- Crear y destruir hilos es mucho más económico que hacerlo por procesos.
¿Para qué usar hilos?
Algunas razones simples
Evite el bloqueo innecesario: un proceso de un solo hilo se bloqueará al hacer E/S; en un proceso de
múltiples hilos, el sistema operativo puede cambiar la CPU a otro hilo en ese proceso.
Aprovechar el paralelismo: Los hilos de un proceso de múltiples hilos pueden ser planificados para
ejecutarse en paralelo en un procesador multiprocesador o multinúcleo.
Evitar el cambio de proceso: Estructurar aplicaciones grandes no como una colección de
procesos, sino a través de múltiples hilos.
Evitar los costosos cambios de contexto

ProcesoA ProcesoB
S3: Cambio del espacio
del kernel al
espacio del usuario
 S1: Cambiar desde el espacio
de usuario al espacio
del kernel

Sistema Operativo

S2: Cambio de contexto del

proceso A al proceso B

Compensaciones

 Los hilos utilizan el mismo espacio de direcciones: más propensos a errores

 No hay soporte de OS/HW para proteger los hilos usando la memoria de cada uno
 El cambio de contexto de un hilo puede ser más rápido que el cambio de contexto de
proceso
El costo de un cambio de contexto
Considere un simple manejador de interrupción de reloj
Costos directos: cambio real y código de ejecución del manejador
Costos indirectos: otros costos, principalmente causados por estropear la caché

(MRU LRU, antes del cambo de contexto, después del cambio de contexto, después el cambio de
contexto)
Beneficios:

 Capacidad de respuesta – Puede permitir la ejecución continua si se bloquea parte del

proceso, lo que es especialmente importante para las interfaces de usuario
 Compartición de recursos- Los hilos comparten recursos del proceso, más fácil que la
memoria compartida o el paso del mensaje.
 Economía – Dado que los hilos comparten recursos del proceso al que pertenecen , es más
económico realizar cambios de contexto
 Escalabilidad: - Las ventajas de configuraciones multihilos pueden ser mayores en
arquitecturas multiprocesador.
programación multinúcleo:
• Los sistemas multinúcleo o multiprocesador ejercen presión sobre los programadores, los
desafíos incluyen:
• División de actividades
• Balance
• División de datos
• Dependencia de datos
• Prueba y depuración
• El Paralelismo implica que un sistema puede realizar más de una tarea simultáneamente
• La Concurrencia admite más de una tarea que progresa
• Un solo procesador/core, tiene un planificador que proporciona concurrencia

Concurrencia vs paralelismo:
Ejecución concurrente en un sistema de un solo núcleo:

Paralelismo en un sistema de múltiples núcleos:

• Tipos de paralelismo
• Paralelismo de Datos – distribuye subconjuntos de los mismos datos en varios
núcleos, la misma operación en cada uno
• Paralelismo de tareas – distribución de hilos entre núcleos, cada hilo realiza una
operación única
- Paralelismo de datos y tareas:
Ley de Amdahl:
• Identifica las ganancias de rendimiento al agregar núcleos adicionales a una aplicación que
tiene componentes en serie y en paralelo
• S es la parte serial
• N núcleos de procesamiento
• Es decir, si la aplicación es 75% paralela / 25% serial, pasar de 1 a 2 núcleos da como
resultado una aceleración de 1,6 veces
• A medida que N se acerca al infinito, la aceleración se acerca a 1/S La parte en serie
de una aplicación tiene un efecto de proporcionado en el rendimiento obtenido al
agregar núcleos adicionales
• Pero, ¿la ley tiene en cuenta los sistemas multinúcleo
contemporáneos?
Hilos vs procesos:
HILOS:

 Un hilo no tiene segmento de datos o heap

 Un hilo no puede vivir por sí solo, debe vivir dentro de un proceso.
 Puede haber más de un hilo en un proceso, el primer hilo llama a main y tiene la pila del
proceso
 Si un hilo muere, su espacio de pila es reclamado
 Comunicación entre hilos vía la memoria. Cada hilo puede ejecutarse en un procesador
físico diferente
 Creación y cambio de contexto económicos
PROCESOS:

 Un proceso tiene codigo/datos/heap & otros Segmentos

 Debe haber al menos un hilo en un proceso
 Los hilos dentro de un proceso comparten código/datos/heap, comparten E/S, pero cada
uno tiene su propia pila y registros
 Si un proceso muere, sus recursos son reclamados y todos los hilos mueren
 Comunicación entre procesos a través de SO. Cada proceso puede ejecutarse en un
procesador físico diferente
 Creación y cambio de contexto costoso

HILOS (THREADS):
Aunque normalmente pensamos que un proceso tiene un único flujo de control, en los
sistemas modernos un proceso puede constar de varias unidades de ejecución, llamadas
hilos, cada una de las cuales se ejecuta en el contexto del proceso y comparte el mismo
código y datos globales. Los hilos son un modelo de programación cada vez más importante
debido al requisito de concurrencia en los servidores de red, porque es más fácil compartir
datos entre varios hilos que entre varios procesos, y porque los hilos suelen ser más
eficientes que los procesos. Los hilos múltiples (Multi-threading) también son una forma de
hacer que los programas se ejecuten más rápido cuando hay varios procesadores
disponibles
 Los procesos definen un espacio de direcciones; los hilos comparten el espacio de
direcciones.
 El bloque de control de proceso (PCB) contiene información específica del proceso.
Propietario PID, puntero al heap (monto), prioridad, hilo activo, y punteros a
la información del hilo.
 El bloque de control del hilo (TCB-Thread Control Block) contiene información
específica del hilo
 Puntero a la pila, PC, estado del hilo (ejecutando, …), valores del registro, un
puntero al PCB, …

 Los procesos definen un espacio de direcciones; los hilos comparten el espacio de

direcciones.
 El bloque de control de proceso (PCB) contiene información específica del proceso.
Propietario PID, puntero al heap (monto), prioridad, hilo activo, y punteros a
la información del hilo.
 El bloque de control del hilo (TCB-Thread Control Block) contiene información
específica del hilo
 Puntero a la pila, PC, estado del hilo (ejecutando, …), valores del registro, un
puntero al PCB, …
HILOS DE USUARIO E HILOS DEL KERNEL
Hilos de usuario - gestión realizada por la biblioteca de hilos a nivel de usuario
• Tres bibliotecas de hilos principales:
• POSIX Pthreads
• Windows threads
• Java threads
Hilos del Kernel – Soportados por el kernel
• Ejemplos – prácticamente todos los sistemas operativos de propósito general, incluidos:
 • Windows
• Linux
• Mac OS X
• iOS
• Android
•

Modelo multinúcleo: muchos-a-uno

• Muchos hilos a nivel de usuario asignados a un solo hilo del kernel
• El bloqueo de un hilo hace que todos se
bloqueen
• Es posible que varios hilos no se ejecuten en paralelo en un sistema de varios núcleos
porque solo uno puede estar en el kernel a la vez
• Actualmente, pocos sistemas utilizan este modelo. Ejemplos
• Solaris Green Threads
• GNU portable threads

Process0 Process1

Modelo de multinúcleo uno-a-uno:

• Cada hilo de nivel de usuario se asigna al hilo del kernel
• La creación de un hilo a nivel de usuario crea un hilo del kernel
• Mayor concurrencia que muchos-a-uno
• Número de hilos por proceso a veces restringido por rendimiento
• Ejemplos
• Windows
• Linux
Modelo multihilos: muchos a muchos
• Permite que muchos hilos de nivel de usuario se asignen a muchos hilos del kernel.
• Permite que el sistema operativo cree una cantidad suficiente de hilos del kernel
• Windows con el paquete ThreadFiber
• De lo contrario, no es muy común

Modelo de dos niveles:

• Similar a M:M, excepto que permite acoplar un hilo de usuario a un hilo del kernel.
Biblioteca de hilos
• Una biblioteca de hilos proporciona al programador una API para crear y administrar hilos
• Dos formas principales de implementar:
• Biblioteca completamente en el espacio del usuario
• Biblioteca de nivel de kernel soportada por el sistema operativo
OPEN MP:
• Conjunto de directivas del compilador y una API
para C, C ++, FORTRAN
• Proporciona soporte para programación paralela en
entornos de memoria compartida
• Identifica regiones paralelas – bloques de código que pueden ejecutarse en paralelo

#pragma omp parallel

Crea tantos hilos como núcleos

SEMANA9:
Modelo DE red básico:
(application, presentation, sesión, trrnasporte, network, dtalink, physical, application protocol,
presentation protocol, sessionprotocol, transportprotocol,network protocol, darta, link protocol,
physical protocol)
Inconvenientes
- Enfocado sólo en el paso de mensajes
- Funcionalidad a menudo innecesaria o no deseada
- Viola la transparencia de acceso
Capas de nivel bajo:

Resumen
Capa física: contiene la especificación e implementación de bits, y su transmisión entre emisor y
receptor
Capa de enlace de datos: establece como norma la transmisión de una serie de bits en una trama
para permitir el control de errores y el control de flujo
Capa de red: describe cómo los paquetes en una red de computadoras deben ser enrutados
Observación
Para muchos sistemas distribuidos, la interfaz de nivel más bajo es la capa de red.

Capa de transporte:
Importante
La capa de transporte proporciona las facilidades de comunicación reales para la mayoría de los
sistemas distribuidos.
Protocolos estándar de Internet
TCP: comunicación orientada a la transmisión, confiable y orientada a la conexión
UDP: comunicación de datagramas no confiable (mejor esfuerzo)
Capa middleware:
Observación: El Middleware se inventa para proporcionar servicios comunes y protocolos
que pueden ser usador por diferentes aplicaciones

 Un variado conjunto de protocolos de comunicación

 (Des)ordenamiento de datos, necesario para sistemas integrados
 Protocolos de Nombres, para permitir compartir fácilmente los recursos
 Protocolos de seguridad para comunicación segura
Mecanismos de escalado, como replicación y almacenamiento en caché
Nota: Lo que queda son protocolos verdaderamente específicos de la aplicación... ¿Cómo así?
Un esquema de capas adaptado:

(application, aplication protocol hist-ti-host, protocol, physical, link level protocol hardware,
operating system)

Tipo de comunicacion:
(Synchronize at request submission, Synchronize at requesrrtdelivery, Synchronize at request
delivery, Synchronize at request submission, Synchronize after processing by server, Transmission
interrupt, Storage facility, server, client, request, time, reply
(Sincronizar en el envío de la solicitud, Sincronizar en la entrega de la solicitud, Sincronizar en la
entrega de la solicitud, Sincronizar en el envío de la solicitud, Sincronizar después del
procesamiento por el servidor, Interrupción de la transmisión, Instalación de almacenamiento,
servidor, cliente, solicitud, hora, respuesta)
sincronizar al enviar la solicitud

 Comunicaciones transitoria versus persistente.

 comunicación asíncrona versus comunicación Síncrona

Transitorio versus persistente

Comunicación transitoria: El servidor de comunicaciones descarta el mensaje cuando no se puede

entregar en el siguiente servidor o en el receptor.
Comunicación persistente: Un mensaje se almacena en el servidor de comunicaciones el tiempo que
sea necesario para entregarlo.

Lugares de sincronización

- En el envío de solicitud
- En la entrega de la solicitud
- Después del procesamiento de la solicitud

Cliente/Servidor:
Algunas observaciones
- La computación cliente / servidor se basa generalmente en un modelo de comunicación
transitoria y síncrona
- El cliente y el servidor deben estar activos en el momento de la comunicación.
- El cliente emite una solicitud y se bloquea hasta que recibe una respuesta
- El servidor esencialmente espera solo las solicitudes entrantes y, seguidamente las procesa
Inconvenientes de la comunicación síncrona
- El cliente no puede realizar ningún otro trabajo mientras espera la respuesta
- Las fallas deben manejarse de inmediato: el cliente está esperando
- El modelo puede simplemente no ser apropiado (correo, noticias)

Mensaje:
Middleware orientado a mensajes
Tiene como objetivo de alto nivel la comunicación asincrónica persistente: Los procesos se envían
mensajes entre sí, los cuales son encolados

 El remitente no necesita esperar una respuesta inmediata, por tal motivo puede hacer otras
cosas
 El middleware a menudo garantiza la tolerancia a fallas
Operación básica de RPC:
Observaciones

 Los desarrolladores de aplicaciones están familiarizados con el modelo de procedimientos

 Los procedimientos bien diseñados funcionan de forma aislada (caja negra)
 No hay ninguna razón fundamental para no ejecutar procedimientos sobre máquinas
separadas o diferentes
- conclusión
La comunicación entre el llamador y llamado se puede ocultar mediante el uso de una llamada a
procedimiento
-

Client Callremote procedure Return from call Wait forresult Call local procedure and return results
Llamada del cliente Procedimiento remoto Regreso de la llamada Espere el resultado Llamada al
procedimiento local y devuelve los resultados request (solicitud) reply (respuesta) return
(fromcall).
 1. El cliente llama al proceso. 6. El servidor hace una llamada local;
2. Stub crea el mensaje; llama al sistema devuelve el resultado al Stub.
operativo local. 7. Stub crea el mensaje; llama OS.
3. El sistema operativo envía un mensaje al 8. El sistema operativo envía un mensaje al
sistema operativo remoto. sistema operativo del cliente.
4. El sistema operativo remoto envía un 9. El sistema operativo del cliente envía un
mensaje al código auxiliar. mensaje al código auxiliar.
5. Stub descomprime los parámetros; servidor 10. Resultado de los desempaquetados del
de llamadas. stub del cliente; devuelve al cliente.

Llamada a doit(a,b), esta se hace y está en el proceso cliente, el resguardo del cliente, toma sus dos
parámetros y lo coloca en un mensaje como se ve (tanto a como b) . también el nombre o numero
de procedimiento, porque el servidor puede soportar varias llamadas, y tiene que identificarlas.
Cuando e mensaje llega al servidor, el resguardo lo examina, para ver que procedimiento se necesita
y regresar la llamada adecuada, los parámetros son variables inicializadas desde el menaje entrante,
mientras la maquina cliente y el servidor sean iguales, con parámetros de caracteres iguales, va a
funcionar correctamente. Sin son diferentes, se tomara de manera diferente el tipo de variable.
Algunas maquinas como Intel Pentium, numera bits de derecha a izquierda, mientras otros de
izquierda a derecha.

A es como recibir los datos una maquina Intel.

B como recibe los datos una maquina spark samp
A nivel numero se recibe una cosa totalmente diferente, ya que el ordenamiento en los bits son
diferentes,
Client procedure calls client stub.
Stub builds message; calls local OS.
OS sends message to remote OS.
Remote OS gives message to stub.
Stub unpacks parameters; calls
server.
Server does local call; returns result to stub.
Stub builds message; calls OS. OS sends message to client’s OS. Client’s OS gives message to stub.
10
Client stub unpacks result; returns to client.

RPC: Paso de parámetros

Hay más que simplemente envolver parámetros en un mensaje

 Las máquinas cliente y servidor pueden tener diferentes representaciones de datos (piense
en la forma de ordenar los bytes)
 Envolver un parámetro significa transformar un valor en una secuencia de bytes
 El cliente y el servidor deben acordar la misma codificación:
 ¿Cómo se representan los valores de datos básicos (enteros, flotantes, caracteres) ?
 ¿Cómo se representan los valores de datos complejos? (arreglos)
conclusión
- El cliente y el servidor necesitan interpretar correctamente los mensajes, transformándolos
en representaciones dependientes de la máquina.

RPC: paso de parámetros

Algunos supuestos

 Semántica Copy in/copy out: mientras se ejecuta el procedimiento, no se puede asumir

nada sobre los valores de los parámetros.
 Todos los datos sobre los que se va a operar se pasan por parámetros. Excluye el paso de
referencia a datos (globales)

conclusión
La transparencia de acceso total no se puede realizar.

Un mecanismo de referencia remota mejora la transparencia del acceso

 La referencia remota ofrece acceso unificado a datos remotos

 Las referencias remotas se pueden pasar como parámetro en RPC.
 Nota: a veces se pueden utilizar stubs como referencias
RPCs Asincronos:
Esencia
Intente deshacerse del comportamiento estricto de solicitud-respuesta, pero deje que el cliente
continúe sin esperar respuesta del servidor

El cliente realiza una solicitud de procedimiento remoto al servidor, el cual la recibe y envía la
aceptación de la solicitud al cliente, el cliente no tiene que esperar que el servidor mande respuesta.
Sin embargo, igual hay un tiempo, para que se retorne la respuesta, del servidor al cliente.
(Esquema: todo ese tiempo que estaba procesador, el cliente puede hacer otras cosas no se
bloquea.)
Pueden ser útiles cuando una respuesta esta por devolverse y el cliente no esta preparado, no hace
nada. RPCS asíncronos, el cliente primero llama al servidor y enrtraga una lista de maquinas y
continua el trabajo, la segunda llamada la hace normalmente, sin problemas, hay variables
asíncronas donde el cliente no espera al servidor, el problema, es que el cliente no sabrá si su
petición fue raceptada.

Envio de múltiples RPCs (Multicast RPC)

Envío de una solicitud RPC a un grupo de servidores.

- Cliente Enviar petición a ambos servidores, ambos llaman a un procedimiento local en el

servidor y luego retornan la respuesta, en tiempos diferentes, pero en paralelo.

Escenario: Scenario – A currency services (micro servicios)

El backets en otro lenguaje, cada parte del lenguaje funciona que nadie se comunica, si algo no
funciona todo deja de funcionar. Pros y contra para que se aregle.
Aplicación móvil, tecnología GRPC, proyecto de Google, se basa en http2, formato binario, ya hay
comunicación de convertir, todo mas rápido, se define por protocolo buffer, diseñado para
microservicios, con GRPC 17 errores, no hay más. Total, la comunicación va encrrptado, confiable y
también de cliente servidor, valida los usuarios que se conectan.
Comparative: GRPC, se sabe el origen, muchos lenguajes, compartivilidades, rendimiento, por cada
petición se abre una comunicación puerto, por ese manda todo, es binario, menos uso de cpu.

HTTP2: se envia y se manda, es bidireccional, es stream, fuertemente Tipado, para que vaya optimo
tiene que estar fuertemente TIPADO, comunicación RAPIDA, en cada librería.
Se basa en petición, en stream, muchos datos, un puerto y por ese se pasa todo.
Procolo bufer: copilo código de dirente lenguaje, en alguno el cliente lo llama stap , etc.
- S e quiere migrar a http2,el cliente no podrá ir al mismo paso, para ello esta el RPC gatway
que monta un proxy, hace un mirror del jason, habla entre el proxy, que esta solo en
lenguaje de Go.

Comunicación transitoria orientada a mensajes: sockets

El cliente establece una conexión con el servidor, el servidor tiene un socket, bind, listen y accept,
dentro del accept(del servidor) y el connect(del cliente) se establecerá un punto de sincronización,
Luego el cliente envía un send el cual es recibido por el recive del servidor, este luego lo envía
(send), lo vuelve a recibir y se establece la comunicación, el cliente recibe y cierra, el servidor
también cierra.
Sockets: un punto en el cual una aplicación se conecta a un puerto especifico.

Facilitando el trabajo con los sockets

Observación
Los sockets son de un nivel bastante bajo y los errores de programación se cometen fácilmente. Sin
embargo, la forma en que se utilizan suele ser la misma (como en una configuración cliente-
servidor).
Alternativa: ZeroMQ
Proporciona un mayor nivel de abstracción al emparejar sockets: uno para enviar mensajes en el
proceso P y uno correspondiente en el proceso Q para recibir mensajes. Toda la comunicación es
asincrónica.
Tres patrones
- Request-reply
- Publish-subscribe
- Pipeline
Implementacion de socket en Python, se ve los comentarios, (retorna socket y direcciond e cliente,
recibe data de cliente, retorna la darta enviada pone un antes“*” y cierra la conexion)
(luego tenemos el cliente, conecta con servidor, espera respuesta, recibe respuesta y cierra)

Facilitar trabajo con socket: los socket son bastante bajos y los errores de programacion son
comunes, sin embargo la configuraciion que se sua es la misma.
(como en la configuraciond e cliente servidor)
Alternative:
Alternartive: ZeroMQ: Proporciona un mayor nivel de abstraccion al emparejar sockets: uno para
enviar mensajes en el proceso P y uno corespondiente en el proceso Q, para recibir mensajes.Toda la
comunciacion es asincrónica.
Tres patrones:

 Request-reply.
 Publish-subscribe
 Pipeline
Ç
 MPI (Message-Passing Interface): Cuando se necesita mucha
flexibilidad
Se usa cuando se requiere mucha flexibilidad

Operaciones representativas

Operation Description

MPI bsend Adjunta un mensaje de salida a un búferlocal de envio

MPI send Envía un mensaje y espera hasta que escopiado en un búfer local o remoto

MPI ssend Envía un mensaje hasta que comienza la recepción

MPI sendrecv Envía un mensaje y espera una respuesta

MPI isend Pasa una referencia a un mensaje de salida, y continúa

MPI issend Pasa una referencia a un mensaje de salida, y espera

hasta que inicia la recepción

MPI recv Recibe un mensaje; bloquea si no hay alguno

MPI irecv Verifica si hay algún mensaje de entrada, pero no bloquea

INTRODUCCION A MPI:
- Message-passing interface (MPI) es una especificación estandar para una interfaz de paso
de mensajes
- MPI define la sintaxis y semántica de patrones de comunicación estándar
- Hay tres versiones de MPI
MPI-1 define las operaciones de comunicación estándar y se basa en un modelo
de proceso estático.
MPI-2 proporciona soporte para la gestión dinámica de procesos y E/S(entradas y salidas)
paralelas
 MPI-3 proporciona operaciones colectivas sin bloqueo, entre otras características nuevas
Colección de procesos que intercambian procesos.
Un programa MPI es una colección de procesos que intercambian mensajes

El modelo de programación distribuida

- Cada proceso tiene su propio espacio de direcciones
- Los procesos necesitan comunicarse entre si
- Sincronización
- Intercambio de datos
- La arquitectura física subyacente puede ser memoria distribuida, memoria compartida o
híbrida(block, node,memory)

- MPI es una especificación de

interfaz para la sintaxis y
semántica de operaciones de
comunicaciones no se dice
nada sobre la implementación
- Hay diferentes
implementaciones
- MPICH
- LAM/MPI
- OpenMPI
EJEMPLO:
Message-oriented middleware (MOM) midware orientado a mensajes
Esencia
Comunicación persistente asincrónica a través del soporte de colas de nivel de middleware. Las colas
corresponden a buffers en servidores de comunicaciones

Operación Descripción

put Adjunta un mensaje a una cola especificada

get Bloquea hasta que la cola especificada no esté

vacía y elimina el primer mensaje

poll Verifica una cola especificada de mensajes y

elimina el primero. Nunca bloquea

notify Instala un manejador al que se llamará cuando un

mensaje se coloque en la cola especificada

Modelo general:
Administradores de Colas
Las colas son gestionadas por administradores de colas. Una aplicación puede colocar mensajes
sólo en una cola local. Es posible obtener un mensaje extrayéndolo de una cola local únicamente ⇒
los administradores de colas necesitan enrutar los mensajes.

Look up

contact address of
destination queue
manager
Dentro del OS del manejador de cola origen, va a buscar la dirección de contacto del manejador de
cola destino, luego se envia por la red, hasta la dirección del destino, donde ingresa al OS, llegando a
la dirección de nivel de cola lógica (nombre), con ellos llega al manejador de cola destino. Logical
queue-level
address
(name)
Address lookup
database
 Source queue
manager

Message bróker Local OS

Local OS
Observación
Los sistemas de colas de mensajes asumen un protocolo de mensajería común: todas las
aplicaciones están de acuerdo en el formato del mensaje (es decir, la estructura y la representación
de los datos)
El Broker maneja la heterogeneidad de la aplicación en un sistema MQ (manejador de colas)

 Transforma los mensajes entrantes al formato de destino

 Muy a menudo actúa como un Gateway de aplicaciones
 Puede proporcionar capacidades de enrutamiento basados en el asunto
(capacidades publish-subscribe)

Contact
Message broker: Arquitectura general address
Network

La fuente, el mesabe bróker y el destino, con sus diferentes capas.

Repasar tareas()
- Dinámica rápida, ping pong de preguntas, aclarar conceptos y la segunda hora se dará la
segunda practica calificada.
- Semana10-avanzamos un tema y luego un ping pong de conceptos clave, casos de estudio.
- Inventor - (aplicacion) desarrollar
- Rutina, algoritmo para que se implementa en versión secuencial como en paralela. (caso
de estudio de tareas) (ALGORITMO PARALELOS HILOS O SECUENCIAL)
Source Message broker Destination

Application
Broker plugins Rules

Interface Interface
Queuing
layer
Local OS Local OS Local OS